Xref: utcsri news.answers:229775
Path: utcsri!utnut!elk.ncren.net!uio.no!border2.nntp.ams.giganews.com!nntp.giganews.com!news.musoftware.de!wum.musoftware.de!fu-berlin.de!krell.zikzak.de!gateway.krell.zikzak.de!not-for-mail
From: faqs@roxel.ms.sub.org (Dirk Nimmich)
Newsgroups: de.admin.infos,de.answers,news.answers
Subject: <2001-04-29> Erlaeuterungen zur Einrichtung neuer Gruppen in de.*
Supersedes: <de-admin-infos/dana-manual/20090402-1@krell.zikzak.de>
Followup-To: de.admin.news.regeln
Date: 8 Apr 2009 22:00:10 -0000
Organization: Moderation von de.admin.infos
Lines: 739
Sender: de-admin-infos@spamfence.net
Approved: news-answers-request@MIT.EDU,de-admin-infos@spamfence.net
Expires: Thu, 09 Jul 2009 22:00:08 +0000
Message-ID: <de-admin-infos/dana-manual/20090409-1@krell.zikzak.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: krell.zikzak.de 1239228012 23177 127.0.0.1 (8 Apr 2009 22:00:12 GMT)
X-Complaints-To: usenet@krell.zikzak.de
Summary: A newuser's guide on how to create new newsgroups in the German-language Usenet hierarchy de.*. In German.
X-PGP-Sig: 2.6.3in Subject,Message-ID,Date,From,Newsgroups,Approved,Supersedes
	iQCVAwUBSd0eavd1G0T+jcJhAQElVgQAqxS1/B9whwNSM6nvFoE/hM2UjgkqdblN
	Ioeo6jheU7pXZIdS3JSrPSEw9rFRf2LLEi0yb8Jd64ZtGsXMdJwKThUNKBwDFwBI
	IHxhbKEDw19F3t4gazXKBF9YNArK5QxU1L+5MyoBHNLJxj2oRG4MqONbHSDYKTRt
	MGMUeXrNF+I=
	=N9Ni

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Last-modified: 2001-04-29
URL: http://www.afaik.de/usenet/faq/dana-manual/
URL: http://www.kirchwitz.de/~amk/dai/dana-manual

  Erläuterungen zur Einrichtung neuer Gruppen in der »de-Hierarchie«
  Von Thomas Roessler. Nach einem Entwurf von Dirk Nimmich
  $Revision: 1.33 $
  ____________________________________________________________

  Inhaltsverzeichnis

  1. Einleitung

     1.1 Adressatenkreis
     1.2 Was ist ein RfD?

  2. Vor dem RfD

  3. Formulierung eines RfD

     3.1 Aufbau
     3.2 Wahl des Gruppennamens
     3.3 Die Kurzbeschreibung
     3.4 Der Status
     3.5 Die Charta
     3.6 Die Begründung
     3.7 Muster
        3.7.1 RfD für eine unmoderierte Gruppe
        3.7.2 RfD für eine moderierte Gruppe
        3.7.3 Der RfD-Generator

  4. Einsenden des RfD an die Moderation

  5. Nach der Veröffentlichung

  6. Die Abstimmung

     6.1 Inhalt eines CfV
     6.2 Ein Muster-CfV
     6.3 Technische Voraussetzungen für die Durchführung
     6.4 Unabhängige Wahlleiter

  7. Schlußbemerkungen

     7.1 Literatur
     7.2 Glossar
     7.3 Die Mentoren
     7.4 Danksagungen

  ______________________________________________________________________

  1.  Einleitung

  1.1.  Adressatenkreis

  Dieser Text richtet sich an diejenigen, die eine Newsgroup in der »de-
  Hierarchie« einrichten wollen.  Er versucht, einen Teil der gerade für
  »Neulinge« häufig frustrierenden Standardargumentation in
  de.admin.news.groups vorwegzunehmen und die in dem Posting
  »Einrichtung von Usenet-Gruppen in "de.*"« (Archive-Name: de-
  newusers/einrichtung) niedergelegten Richtlinien zur Einrichtung neuer
  Gruppen zu erläutern.

  Jedem Unerfahrenen, der eine Wahl in der »de-Hierarchie« durchführen
  will, sei empfohlen, sich vorher mit einer möglichst weit gediehenen
  Beschreibung seines Vorschlags an <mentoren@dana.de> zu richten. Unter
  dieser Adresse ist eine Gruppe von Freiwilligen zu erreichen, die
  bereit sind, den Proponenten bei der Abfassung des endgültigen RfDs zu
  beraten und während des weiteren Procederes zu begleiten.

  Natürlich gibt es keinerlei Zwang, auf dieses Angebot einzugehen; es
  handelt sich lediglich um eine Möglichkeit, sich Anregungen und
  Anmerkungen zu seinem Vorschlag einzuholen, bevor man sich damit an
  die Öffentlichkeit wendet.

  Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der
  Unterhierarchie de.alt:  Dort wird eine Gruppe in de.alt.admin
  vorgeschlagen.  Ergab die dortige Diskussion keinen gar zu heftigen
  Gegenwind, wird die Gruppe eingerichtet.


  1.2.  Was ist ein RfD?

  Ein RfD (kurz für »Request for Discussion«) ist der formale Aufruf zur
  Diskussion, der am Anfang jedes Verfahrens zur Einrichtung,
  Umbenennung etc. einer Gruppe in der »de-Hierarchie« steht.  Er wird
  in de.admin.news.announce veröffentlicht und dient als Grundlage der
  nachfolgenden Diskussion in de.admin.news.groups, während der er auf
  inhaltliche Qualität und Akzeptanz abgeklopft und verfeinert wird.  Am
  Ende dieser Diskussion steht üblicherweise der Aufruf zu einer
  Abstimmung (»Call for Votes« oder kurz »CfV« genannt), in der die
  Akzeptanz des Vorschlags festgestellt wird.

  Vom Ausgang dieser Abstimmung hängt die Annahme des Vorschlags ab.
  Nach den Regeln bedarf es zur Annahme einer Gruppe einer
  Zweidrittelmehrheit.  Die aktuellen Wahlregeln werden regelmäßig u. a.
  in de.admin.infos unter dem Subject »Einrichtung von Usenet-Gruppen in
  "de.*"« gepostet.


  2.  Vor dem RfD

  Bevor man mit der Arbeit an einem RfD beginnt, sollte man sich selbst
  immer die Frage stellen, ob die gewünschte Änderung wirklich benötigt
  wird; bei der Neueinrichtung einer Gruppe sollte man insbesondere auf
  die folgenden Punkte achten:

  1. Existiert bereits eine deutschsprachige Gruppe zum Thema?  Es ist
     nicht sinnvoll, eine zweite Gruppe zur Diskussion ein und desselben
     Themas einzurichten; ein entsprechender Vorschlag würde
     zwangsläufig scheitern.  Existiert andererseits eine Gruppe, in der
     das gewünschte Thema diskutiert wird, ist diese Gruppe aber
     überfüllt, so ist es unter Umständen sinnvoll, diese Gruppe in
     mehrere Gruppen aufzuspalten.

  2. Besteht im Netz Interesse am Thema?  Öffentliche Selbstgespräche
     sind auf Dauer ermüdend.  Im eigenen Interesse sollte man zunächst
     versuchen festzustellen, ob das gewünschte Thema überhaupt im Netz
     diskutiert wird.  Gibt es in verschiedenen Gruppen wiederkehrende
     Diskussionen, die sich auf das gewünschte Thema beziehen?  Gibt es
     Mailinglisten, die sich mit dem Thema auseinandersetzen?

  3. Existiert schon ein Vorschlag?  Es ist wenig sinnvoll, eine weitere
     Diskussion zu beginnen, wenn die Einrichtung einer Gruppe zum
     gewünschten Thema bereits im Gespräch ist.  Anstatt einen formellen
     Vorschlag einzureichen, sollte man sich in de.admin.news.groups
     aktiv an der laufenden Diskussion beteiligen.  In der Gruppe
     de.admin.news.announce wird regelmäßig der Status der laufenden
     Verfahren veröffentlicht.

  4. Gab es kürzlich einen ähnlichen Vorschlag?  Viele regelmäßige Leser
     von de.admin.news.groups reagieren mit Unwillen, wenn Vorschläge,
     über die gerade erst in epischer Breite diskutiert und abgestimmt
     wurde, wieder vorgebracht werden. Es wird allgemein empfohlen, vor
     der Wiedervorlage eines abgelehnten Vorschlages eine Denkpause von
     mindestens sechs Monaten einzulegen.

  Ist man nach der Überprüfung dieser Punkte der Ansicht, daß eine neue
  Gruppe im allgemeinen Interesse liegt, sollte man sich nach
  Verbündeten umsehen: Es schadet nicht, wenn ein Vorschlag während der
  Diskussion von einer ganzen Reihe von Leuten, die an dem
  vorgeschlagenen Thema Interesse haben und später in der Gruppe posten
  würden, unterstützt wird.


  3.  Formulierung eines RfD

  3.1.  Aufbau

  Ein RfD für die Neueinrichtung einer Gruppe besteht aus einem
  Namensvorschlag für die Gruppe, dem Status der Gruppe (moderiert oder
  unmoderiert), einer zugehörigen Kurzbeschreibung und einer Charta.
  Als Grundlage für die Diskussion sollte ferner der Hintergrund des
  Vorschlags erläutert werden.  In dieser Erläuterung sollte man
  insbesondere auf die oben genannten Punkte eingehen; andernfalls muß
  man damit rechnen, daß sie als »Standardfragen« in der Diskussion
  wieder auftauchen.

  Ein RfD sollte üblicherweise nur einen einzelnen Gruppenvorschlag
  behandeln - es verwirrt nur, wenn eine Gruppe über das
  Fortpflanzungsverhalten der Pflastersteine unter Berücksichtigung des
  besonderen Einflusses des Sonnenlichts im gleichen Thread diskutiert
  wird wie eine Gruppe, die dem Diskurs über die gesellschaftlichen
  Auswirkungen des Fernsehens dient.  Eine Ausnahme von dieser Regel
  stellt die schon oben angesprochene Aufspaltung von Gruppen dar: Hier
  sollte man Sammel-RfDs und -CfVs veranstalten.  Eine Sammelabstimmung
  ist so zu verfassen, daß jede Entscheidung auch einzeln zur Abstimmung
  kommen könnte.  Eine Ausnahme gibt es bei der Aufteilung einer Gruppe:
  Die Umbenennung einer Gruppe in Gruppe.misc bei Annahme mindestens
  einer Untergruppe kann automatisch erfolgen.


  3.2.  Wahl des Gruppennamens

  Der Name besteht aus mehreren durch Punkte getrennten Segmenten.  Die
  einzelnen Segmente dürfen nicht länger als 30 Zeichen werden und
  müssen mindestens je einen Buchstaben enthalten. Zu beachten ist
  dabei, daß sich unterschiedliche Segmentnamen auf gleicher Ebene
  schon vor dem 15. Zeichen unterscheiden müssen. Erlaubte Zeichen
  innerhalb eines Segments sind die Kleinbuchstaben (a-z), die
  arabischen Ziffern (0-9) sowie das Plus- (+) und das Minus-Zeichen
  (-).

  Der Name sollte so aussagekräftig wie möglich sein und sich dabei in
  die bestehende Namenshierarchie einpassen:

     de.alt
        ist eine Unterhierarchie, in der eigene Regeln gelten.  Die
        Einrichtung von Gruppen in dieser Unterhierarchie wird hier
        nicht behandelt.

     de.admin
        beschäftigt sich mit der administrativen Seite des Usenet, also
        im wesentlichen mit dem Mail- und Newsaustausch im Netz und der
        Fortentwicklung der de-Newsgroups.

     de.comm
        dient der Diskussion über Kommunikation und
        Kommunikationstechnik. Diese Unterhierarchie hat eine noch
        weiter differenzierte Struktur: de.comm.anbieter.* ist Themen
        rund um Sprachtelekommunikationsanbietern zugedacht, während
        de.comm.provider.* die Anbieter von Internet und
        Internetdiensten meint; de.comm.geraete.* dient der Diskussion
        über die zur Kommunikation benötigten Geräte, de.comm.technik.*
        der über die dahinterliegende Technik; de.comm.infosystems.*
        behandelt Informationssysteme wie das World Wide Web (WWW),
        WAIS oder Hyper-G; de.comm.internet.* ist mit einigen Aspekten
        des Internets befaßt; de.comm.protocols.* beschäftigt sich mit
        Kommunikationsprotokollen und de.comm.software.* mit
        Kommunikationssoftware.

     de.comp
        dreht sich um Computer und alles, was damit zu tun hat.  Auch
        diese Unterhierarchie ist weitergehend gegliedert: In
        de.comp.os.* wird über Betriebssysteme gesprochen, Hardware
        diskutiert man in de.comp.sys.* (Komplettsysteme) bzw.
        de.comp.hardware.* (Einzelteile), und Programmiersprachen als
        solche werden in de.comp.lang.* debattiert. Daneben gibt es
        noch de.comp.datenbanken.* für Datenbankmanagementsysteme,
        de.comp.office-pakete.* für integrierte Büroanwendungen und
        de.comp.text.* zum Diskutieren über Textformate und
        Texterzeuger.

     de.markt
        ist der Kleinanzeigenbereich des deutschsprachigen Usenet: Hier
        werden nicht-kommerzielle Angebote und Gesuche ausgetauscht.

     de.org
        dient verschiedenen »Organisationen« als Diskussionsforum.  In
        de.admin.news.groups ist allerdings die Auffassung recht weit
        verbreitet, daß neue Gruppen nach Möglichkeit in
        themenspezifischen Unterhierarchien eingerichtet werden sollten
        (wie beispielsweise de.org.politik.spd).

     de.rec
        beschäftigt sich mit Freizeitaktivitäten aller Art.
        Unterhierarchien sind de.rec.spiele (Spiele aller Art),
        de.rec.music (Musik), de.rec.sport (Sport), de.rec.sf (Science
        Fiction), de.rec.tiere (die lieben Haustiere). Auch hier
        vertreten einige Teilnehmer von de.admin.news.groups die
        Ansicht, daß neue Gruppen möglichst nicht mehr direkt unter
        de.rec.*  eingerichtet werden sollten, um die Übersichtlichkeit
        nicht zu gefährden.

     de.sci
        ist den Wissenschaften gewidmet, wobei bei der Einrichtung neuer
        Gruppen in dieser Hierarchie immer wieder Streit aufkommt, was
        denn überhaupt eine Wissenschaft sei.  In der Praxis scheint
        sich bisher die Meinung durchgesetzt zu haben, daß die Lehrpläne
        von Universitäten im deutschsprachigen Raum einen ganz guten
        Überblick bieten.  Direkt unterhalb von de.sci werden
        üblicherweise ganze Fachbereiche untergebracht.  Einzelne
        Spezialgebiete haben dort nichts zu suchen; sie sollten als
        Untergruppen dem entsprechenden Fach zugeordnet werden
        (Beispiel: de.sci.medizin.allergie).

     de.soc
        handelt von gesellschaftlichen Dingen.

     de.talk
        dient dem gemütlichen Plausch über mehr oder minder
        Weltbewegendes.  Von purem Unsinn (de.talk.bizarre) bis hin zu
        des Menschen wichtigster Nebensache (de.talk.liebesakt) ist
        alles vertreten.

     de.etc
        schließlich stellt das Auffangbecken dar, wenn ein Thema nicht
        in eine der anderen Unterhierarchien paßt.

  Man sollte außerdem versuchen, im Gruppennamen möglichst keine
  kryptischen oder mehrdeutigen Abkürzungen zu verwenden. Wenn diese gar
  nicht zu vermeiden sind, sollte man sie in der Kurzbeschreibung,
  spätestens aber in der Charta auflösen.


  3.3.  Die Kurzbeschreibung

  Die Kurzbeschreibung ist zum einen in den regelmäßigen Postings zu
  finden, die den Systemadministratoren helfen, die Auswahl der auf
  ihren Systemen bereitgehaltenen Gruppen auf dem neuesten Stand zu
  halten.  Andererseits zeigen viele Newsprogramme diese
  Kurzbeschreibung auch an, um den Leser an das Thema der Gruppe zu
  erinnern und somit von Fehlpostings abzuhalten.  Sie ist (neben dem
  Namen) häufig das erste, was ein potentieller Leser von einer Gruppe
  zu Gesicht bekommt.

  Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
  ab: Sie muß kurz, knapp und für jeden verständlich sein. »Diskussion
  über« oder »Informationen von« sind zum Beispiel notorisch
  überflüssige Formulierungen. Da die Kurzbeschreibung in Gruppenlisten
  auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die
  meist auf 80 Spalten breiten Terminals gelesen werden, ergibt sich
  eine Beschränkung für die Länge der Kurzbeschreibung: Gruppenname, ein
  8er-Tabulator und Kurzbeschreibung sollten in weniger als 80 Zeichen
  passen. Als Richtwert gilt für die Kurzbeschreibung gewöhnlich  eine
  Maximallänge von 60 Zeichen.

  Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze
  Kurzbeschreibung anzeigen, wird er sich üblicherweise auf den Anfang
  der Kurzbeschreibung beschränken. Daraus folgt, daß die wichtigsten
  Punkte in einer Kurzbeschreibung an deren Anfang stehen sollten. Um
  Komplikationen zu vermeiden, sollten Kurzbeschreibungen keine Umlaute
  und sonstige Sonderzeichen enthalten; der Zeichenvorrat ist »US-
  ASCII«. Per Konvention endet jede Kurzbeschreibung mit einem
  Satzendezeichen (Punkt, Frage- oder Ausrufezeichen).


  3.4.  Der Status

  Man unterscheidet zwischen moderierten und unmoderierten Gruppen.
  Artikel für eine unmoderierte Gruppe werden vom Newsreader dem lokalen
  Server übergeben, der sie mittels der üblichen Mechanismen an seine
  »Nachbarn« weiterleitet. Artikel für eine moderierte Gruppe werden
  zunächst zur Bestätigung per Mail an eine Moderation geschickt, die
  sie dann veröffentlicht.

  Moderierte Gruppen eignen sich vor allem für Ankündigungen.  Beispiele
  hierfür sind de.admin.news.announce, die sich auf die Aufrufe zu
  Diskussion und Abstimmung beschränkt und damit auch für diejenigen
  lesbar bleibt, die nicht die Zeit haben, den Diskussionen im einzelnen
  zu folgen, oder de.rec.orakel, in der sich allwöchentlich eine Auswahl
  der besten Fragen und Antworten des Internet-Orakels findet.

  Ein weiterer Grund für eine moderierte Gruppe kann sein, daß (bei
  einem wissenschaftlichen Thema zum Beispiel) ein gewisses
  Mindestniveau der Diskussion gewahrt werden soll.  Als Beispiele seien
  hier nur die internationalen sci.*.research-Gruppen genannt.

  Ist man zu dem Ergebnis gekommen, daß man eine moderierte Gruppe
  einrichten will, sollte man sich über die folgenden Punkte klar
  werden:

  1. Wer soll moderieren?  Es ist für gewöhnlich sinnvoll, bereits vor
     der Veröffentlichung des Vorschlags mindestens einen Kandidaten für
     die Moderation zu haben.  Diesen sollte man im RfD nennen.

  2. Wohin mit den Followups?  Viele moderierte Gruppen dienen als
     Ankündigungsgruppen - de.admin.news.announce ist wieder nur ein
     Beispiel.  Über die Ankündigungen wird üblicherweise auch
     diskutiert.  Dies kann entweder in einer speziellen Gruppe
     geschehen (für de.admin.news.announce ist das normalerweise
     de.admin.news.groups) oder in einer allgemeineren Diskussionsgruppe
     (Postings in de.rec.orakel haben üblicherweise ein Followup-To:
     de.talk.jokes.d im Header).  Existiert noch keine unmoderierte
     Gruppe, in der die Diskussionen stattfinden können, sollte man
     gegebenenfalls im gleichen RfD die Einrichtung einer solchen zur
     Diskussion stellen.


  3.5.  Die Charta

  Die Charta ist die Beschreibung der Newsgroup schlechthin.  Hier wird
  in etwa ein bis zwei Absätzen in Form vollständiger Sätze erklärt,
  womit eine Newsgroup sich beschäftigt, welche Themen erwünscht sind,
  welche Themen nicht erwünscht sind, welche besonderen Konventionen
  gelten, etc.

  Beispiel für eine gelungene Charta ist diejenige von de.rec.outdoors:

       Die Gruppe dient der Diskussion aller Arten von
       Freizeitbeschäftigungen abseits der Zivilisation sowie der damit
       verbundenen Themen wie Ausrüstung, gesetzliche Bestimmungen,
       Erlebnisberichte, Freiluftküche und dergleichen. Nicht Thema der
       Gruppe ist das klassische Campen mit Gardinen im Hauszelt.


  3.6.  Die Begründung

  Hier hat man Gelegenheit, die Netzöffentlichkeit davon zu überzeugen,
  daß die vorgeschlagene Newsgroup sinnvoll ist und nicht nur Leser,
  sondern auch Autoren finden wird.  Man sollte begründen, warum man
  selbst die Gruppe für sinnvoll hält, und seine Überlegungen zur
  Einordnung der Gruppe in die de-Hierarchie darlegen.  Man sollte
  darauf eingehen, wo bereits über das Thema diskutiert wird - andere
  Newsgroups, Mailinglisten, die überlaufen, und dergleichen.

  Wird der Vorschlag von einer größeren Gruppe von Nutzern unterstützt
  (soll beispielsweise eine überquellende Diskussionsliste in eine
  Newsgroup umgewandelt werden), sollte man das hier erwähnen.


  3.7.  Muster

  In diesem Abschnitt finden sich Muster für die formale Gestaltung von
  RfDs für moderierte und unmoderierte Gruppen.


  3.7.1.  RfD für eine unmoderierte Gruppe

                      1. Diskussionsaufruf
                      ====================

       zur Einrichtung der neuen Gruppe


       [Gruppenname]   [Kurzbeschreibung]


       Status:  Die Gruppe ist unmoderiert.

       Charta
       ------

       [Charta]


       Hintergrund
       -----------

       [Begruendung]


  3.7.2.  RfD für eine moderierte Gruppe

                 1. Diskussionsaufruf
                 ====================

  zur Einrichtung der neuen Gruppe

  [Gruppenname]   [Kurzbeschreibung] <mode@ra.tor> (Moderated)

  Diskussionen sollen in der Gruppe

  [Gruppenname]   [Kurzbeschreibung]

  gefuehrt werden.


  Status
  ------

  Die Gruppe ist moderiert.  Als Moderatoren werden Martina Oderat
  <m.ode@rator.de> und Peter Roponent <p.ropo@nent.de> vorgeschlagen.

  Charta
  ------

  [Charta]

  Die Postings in [Gruppenname] sind mit einer Headerzeile

   Followup-To: [Diskussionsgruppe]

  zu versehen.


  Hintergrund
  -----------

  [Begruendung]


  3.7.3.  Der RfD-Generator

  Unter dem URL <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi'
  Piwinger ein Formular abgelegt, das die genannten RfD-Bestandteile
  abfragt, die Eingaben auf einige Fehler hin überprüft und daraus dann
  einen Text erzeugt, der sich an den Muster-RfDs orientiert.


  4.  Einsenden des RfD an die Moderation

  Die Moderation von de.admin.news.announce ist unter der Adresse
  <moderator@dana.de> zu erreichen; ihr schickt man den fertigen RfD
  samt der Liste der Gruppen zu, in denen er veröffentlicht werden soll.
  Dazu gehören immer de.admin.news.announce und de.admin.news.groups.
  Hinzu kommen für gewöhnlich dem Vorschlag thematisch naheliegende
  Gruppen, deren Leserschaft an der Diskussion über die Einrichtung der
  geplanten Gruppe ein natürliches Interesse haben.

  Die Moderation wird den RfD anhand der hier beschriebenen Punkte
  überprüfen und beim Autor per Mail Rückfragen stellen, um ggfs.
  Mißverständnisse auszuräumen.  Ist alles klar, postet sie den Artikel
  in den genannten Gruppen.


  5.  Nach der Veröffentlichung

  Nachdem die Moderation den RfD veröffentlicht hat, findet in
  de.admin.news.groups die Diskussion über den Vorschlag statt.  Die
  Antragsteller sollten die Diskussion verfolgen und auf Einwände und
  Kritik eingehen, ihre Begründung verfeinern.  Häufig wird die
  Diskussion sinnvolle Ergänzungen zum ursprünglichen Vorschlag bringen,
  die man in einen neuen Vorschlag einarbeiten kann.

  Hat die Diskussion zu weitgehenden Änderungen am Vorschlag geführt,
  sollte man etwa zwei Wochen nach dem ersten Diskussionsaufruf einen
  zweiten RfD in den gleichen Gruppen veröffentlichen, der den
  modifizierten Vorschlag und eine Begründung, warum man welche
  Vorschläge aufgenommen oder verworfen hat, enthält. Dieser zweite RfD
  erscheint als Followup auf den ersten und hat wie dieser ein Followup-
  To auf de.admin.news.groups gesetzt. Besteht weiterer
  Diskussionsbedarf, können auch mehrere weitere RfDs veröffentlicht
  werden; auch diese erscheinen dann in dem Thread, der durch den ersten
  RfD eröffnet wurde, und zwar jeweils als Followup auf den
  vorangegangenen RfD.


  6.  Die Abstimmung

  6.1.  Inhalt eines CfV

  Ist die Diskussion in de.admin.news.groups so weit fortgeschritten,
  daß der Proponent der Meinung ist, mit seinem Vorschlag weitgehend
  Zustimmung zu erhalten, geht es darum, die Abstimmung über diesen
  Vorschlag in die Wege zu leiten. Formell wird diese Abstimmung durch
  einen CfV eingeleitet, der sich im großen und ganzen an dem letzten
  RfD als Abstimmungsgegenstand orientieren soll. Zusätzlich enthält ein
  CfV noch Informationen über die Wahlfrist und die Adresse oder
  Adressen, an die die Wahlscheine geschickt werden sollen, sowie einen
  Wahlschein und Beispiele für Abstimmöglichkeiten.

  Die Frist zur Abgabe der Stimme beträgt in der Regel drei bis vier
  Wochen, gerechnet von der Veröffentlichung in de.admin.news.announce.
  In der Mitte der Frist sollte ein zweiter CfV veröffentlicht werden,
  in dem die Personen, die ihre Stimme bereits abgegeben haben, zur
  Kontrolle mit ihrer E-Mail-Adresse (ohne das Votum) aufgelistet
  werden.

  Alle CfVs sollen in den Gruppen, in denen auch der letzte RfD gepostet
  wurde, erscheinen und werden als Followups in demselben Thread
  veröffentlicht, der durch den ersten RfD ausgelöst wurde.


  6.2.  Ein Muster-CfV

                          1. Aufruf zur Wahl
                          ==================

  zur Einrichtung der neuen Gruppe

  <Gruppenname>   <Kurzbeschreibung>

  Status:  Die Gruppe ist {moderiert|unmoderiert}.

  Charta
  ------
  <Charta>

  Modalitäten
  -----------
    Sinn einer Usenet-Abstimmung ist es festzustellen, wer eine
    vorgeschlagene Gruppe tatsächlich nutzen möchte.  Uninteressierte
    Personen zur Teilnahme an der Abstimmung aufzufordern, schadet diesem
    Ziel.  Bitte verbreite diesen CfV nicht weiter.  Verweise die Leute
    stattdessen auf den offiziellen CfV, der in de.admin.news.announce
    gepostet wurde.  Die Verbreitung von vorausgefüllten oder anderweitig
    veränderten CfV wird allgemein als Wahlfälschung angesehen.  Im
    Zweifel wende Dich an den Wahlleiter.

    Die Stimmen müssen bis zum <Datum> eingehen.  Ausschlaggebend
    ist hierbei das *Eintreffen* der Stimme, nicht das Absendedatum!
    Bitte benutze den Wahlschein, der am Ende dieses CfV angebracht
    ist. Wahlberechtigt ist jede natürliche Person, die in der Lage
    ist, E-Mail an die Abstimmungsadresse zu schicken.

    Es gelten die derzeitigen Wahlregeln, die in de.admin.infos
    veröffentlicht sind.

  Wie gewählt wird
  ----------------

    Trage in die Felder des Wahlscheins unten Deine Stimme (JA, NEIN
    oder ENTHALTUNG) ein und schicke den Wahlschein dann an den
    Vote-Account <email@adres.se> (Reply-To:-Header ist gesetzt.)  Es
    werden nur Stimmen berücksichtigt, die per Mail an diesen Account
    gerichtet sind.  Öffentliche Stimmabgaben (Postings) sind ungültige
    Stimmen und werden nicht berücksichtigt.


    Deine Entscheidung bedeutet dabei:

    JA         - Ich bin für diesen Vorschlag.
    NEIN       - Ich bin gegen diesen Vorschlag.
    ENTHALTUNG - Ich enthalte mich oder ich ziehe meine Stimme zurück

                 Enthaltungen gelten nicht im Sinne einer gültig
                 abgegebenen Stimme; sie dienen vornehmlich dazu,
                 eine zuvor abgegebene Stimme zurückzuziehen.

    Der Wahlleiter wird auf Deine Stimme mit einer persönlichen
    Bestätigung via E-Mail reagieren. Wenn Du innerhalb von ein paar
    Tagen nichts hörst, versuche es noch einmal.

    Solltest Du Deine Meinung ändern, so wähle einfach
    neu. Willst Du dabei Deine Stimme annullieren, so entscheide
    ENTHALTUNG. Gehen mehrere Stimmen ein, gilt die jeweils zuletzt
    abgeschickte (Date:-Eintrag der Mail).

    Bitte beachte, daß die Stimme Deinen echten Namen enthalten
    muß, kein Pseudonym. Sollte Dein Newsreader den Namen nicht
    automatisch im From:-Header eintragen, trage ihn bitte nochmal im
    Wahlzettel ein.  Andernfalls ist Deine Stimme ungültig.

    In der Mitte der Wahlperiode wird ein zweiter CfV gepostet, der
    eine Auflistung aller Personen enthält, von denen bis zu diesem
    Zeitpunkt eine gültige Stimme eingegangen ist.

    Die Ergebnisse der Wahl werden nach Ablauf der Wahlfrist
    öffentlich gepostet, wobei jede einzelne Stimme, zur Kontrolle
    für alle, aufgelistet wird. Solltest Du begründete Bedenken gegen
    die Veröffentlichung Deines Realnamens haben, melde Dich bitte beim
    Wahlleiter (<e-mail@ad.res.se>).


  -=-=-=-=-=-= Alles vor dieser Zeile löschen =-=-=-=-=-=-

  Wahlschein fuer die {Einrichtung|Umbenennung|Entfernung} von
  <Gruppenname>

  Dein Realname, falls nicht im From:-Header:

  Wenn Du keinen Real-Namen veröffentlicht haben willst, wende Dich
  mit einer Begründung an <e-mail@ad.res.se>

  [Deine Stimme]  Abstimmungsgegenstand
  ----------------------------------------------------------------------
  [            ]  Einrichtung von <Gruppenname>

  -=-=-=-=-=-= Alles nach dieser Zeile löschen =-=-=-=-=-=-


  6.3.  Technische Voraussetzungen für die Durchführung

  Für die Abstimmung selbst benötigt man einen E-Mail-Account, der die
  Wahlscheine entgegennimmt. Dieser sollte nach Möglichkeit nicht mit
  der »normalen« E-Mail-Adresse des Abstimmungsleiters identisch sein,
  damit keine Mißverständnisse auftreten oder Wahlscheine in der
  sonstigen Post verloren gehen.

  Jede abgegebene Stimme soll - nach Möglichkeit automatisch - bestätigt
  werden. Aus der Nachricht sollte außerdem hervorgehen, wie die Stimme
  gezählt wurde, damit der Absender eine falsch gezählte Stimme wieder
  ändern oder diese widerrufen kann, wenn er vor Ablauf der Wahlfrist
  seine Meinung ändert.

  Es wird außerdem empfohlen, den Account zur Entgegennahme der
  Wahlscheine zur Reduzierung der Antwortlaufzeiten auf einem Internet-
  Host einzurichten.


  6.4.  Unabhängige Wahlleiter

  Wer sich nicht die Mühe machen will, nicht die Möglichkeiten dazu hat,
  die Wahl abzuhalten, oder der Meinung ist, die Wahl besser durch
  Unabhängige durchführen zu lassen, kann sich auch an die German
  Volunteer Votetakers (GVV) wenden.  Diese führen dann die Abstimmung
  einschließlich zweitem CfV und Veröffentlichung des Ergebnisses durch.

  Dazu fragt man bei den GVV unter der Adresse <gvv@dana.de> an, wer
  bereit ist, den CfV zu übernehmen. Dem Freiwilligen, der sich dann
  meldet, schickt man den soweit wie möglich fertigen CfV (d. h., ohne
  die Abstimmadresse und ohne Frist für die Stimmabgabe). Der GVV wird
  die fehlenden Angaben ergänzen, den Wahlschein auf Maschinenlesbarkeit
  prüfen und sonst wahrscheinlich nichts ändern, sondern den CfV direkt
  bei der Moderation einreichen. Mit dem weiteren Ablauf hat man dann
  nichts mehr zu tun.


  7.  Schlußbemerkungen

  7.1.  Literatur

  Folgende Texte sollten dem Proponenten auf jeden Fall bekannt sein:

     <Datum> Einrichtung von Usenet-Gruppen in "de.*"
        Dieser Text beschreibt die Richtlinien für die Einrichtung einer
        Newsgroup in der de.*-Hierarchie, insbesondere die üblichen
        Abstimmungsmodalitäten. Er wird wöchentlich in de.admin.infos
        gepostet.

     <Datum> Die Newsgruppen der de.*-Hierarchie
        Hier findet sich eine Beschreibung der bereits eingerichteten
        Newsgroups in de.*  (ohne de.alt.*). Das Posting findet sich
        allwöchentlich in de.newusers.infos.

     <Datum> Die Newsgruppen der de.alt.*-Hierarchie
        Darin sind die bestehenden Newsgruppen der de.alt-Hierarchie
        aufgeführt und beschrieben. Auch dieser Text kann der Newsgroup
        de.newusers.infos entnommen werden.

     <Datum> Missverstaendnisse in de.admin.news.groups
        Dieser Text beschreibt typische Argumentationen in
        de.admin.news.groups. Er wird nach de.admin.infos gepostet.


  7.2.  Glossar

     CfV
        Call for Votes, Aufruf zur Wahl. Leitet die Abstimmung über eine
        Entscheidung ein bzw. dient zur Erinnerung an diese Abstimmung.

     dana
        Akronym für de.admin.news.announce

     GVV
        German Volunteer Votetakers, Freiwillige Abstimmungsleiter; zu
        erreichen unter der E-Mail-Adresse <gvv@dana.de>.

     RfD
        Request for Discussion, Aufruf zur Diskussion. Leitet die
        Diskussion um eine Entscheidung ein bzw. bringt sie wieder in
        Gang.


  7.3.  Die Mentoren

  Die Liste der derzeit aktiven Mentoren, die sich bereit erklärt haben,
  anderen bei der Erstellung von RfDs und CfVs zu helfen und bei der
  Durchführung von Wahlverfahren zu beraten:

  Dirk Nimmich
  Michael Ottenbruch
  Boris `pi' Piwinger
  Alexander Stielau
  Adrian Suter
  Oliver B. Warzecha

  Eine aktuelle Liste kann man unter
  <http://www.dana.de/mod/mentoren.html> im WWW finden.  Anfragen
  sollten aber an die Sammeladresse <mentoren@dana.de> geschickt werden.


  7.4.  Danksagungen

  Zu diesem Text und seiner Entstehung haben beigetragen:

  Lutz Donnerhacke <lutz@as-node.jena.thur.de>
  Kristian Köhntopp <kristian@koehntopp.de>
  Rolf Krahl <rolf.krahl@gmx.net>
  Dirk Nimmich <nimmich@uni-muenster.de>
  Martin Recke <mr94@husemann.in-berlin.de>
  Thomas Roessler <roessler@sobolev.rhein.de>
  Heiko Schlichting <heiko@fu-berlin.de>
  Adrian Suter <adrian.suter@schweiz.org>
  Hans-Christoph Wirth <hansi@dianoia.mayn.de>

