Umformatierung, behutsame Aktualisierung.
authorThomas Hochstein <thh@inter.net>
Mon, 15 Mar 2010 21:51:00 +0000 (22:51 +0100)
committerThomas Hochstein <thh@inter.net>
Mon, 15 Mar 2010 21:51:00 +0000 (22:51 +0100)
Signed-off-by: Thomas Hochstein <thh@inter.net>
dana-manual

index 68f31b0..4d243b9 100644 (file)
 Archive-name: de-newusers/dana-manual
 Posting-frequency: weekly
-Last-modified: 2001-04-29
-URL: http://www.afaik.de/usenet/faq/dana-manual/
+Version: 2.0.0
+Last-modified: 2010-03-15
 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 $
-  ____________________________________________________________
+          Erläuterungen zur Einrichtung neuer Gruppen in de.*         
+          ===================================================
 
-  Inhaltsverzeichnis
+Inhaltsverzeichnis
+------------------
 
-  1. Einleitung
+1. Einleitung
 
-     1.1 Adressatenkreis
-     1.2 Was ist ein RfD?
+   1.1 Adressatenkreis
+   1.2 Was ist ein RfD?
 
-  2. Vor dem RfD
+2. Vor dem RfD
 
-  3. Formulierung eines 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
+   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 Danksagungen
+
+======================================================================
+
+1.  Einleitung
+
+1.1.  Adressatenkreis
+
+Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
+internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
+wollen.  Er versucht, einen Teil der gerade für Neulinge auf diesem
+Gebiet häufig frustrierenden Standardargumentation in
+de.admin.news.groups vorwegzunehmen und die in den "REGELN FÜR DIE
+EINRICHTUNG UND ENTFERNUNG VON USENET-GRUPPEN" [1] niedergelegten Regeln
+zur Einrichtung neuer Gruppen zu erläutern.
+
+  [1] Veröffentlich in de.admin.infos:
+|     From: 3.14@piology.org (Boris 'pi' Piwinger)
+|     Newsgroups: de.admin.infos,de.alt.admin
+|     Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
+|     
+|     Archive-name: de-admin/einrichtung
+|     Posting-frequency: weekly
+|     Last-modified: 2005-08-06
+|     URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+
+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 de.* 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.
+
+----------------------------------------------------------------------
+
+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 notwendi
+ist. 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; die entsprechende Übersicht steht auch im
+   World Wide Web unter <http://www.dana.de/status.html> zum Abruf
+   bereit.
+
+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 (oder auch Tagline) 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] <moderator@domain.example> (Moderated)
+| 
+| Diskussionen sollen in der Gruppe
+| 
+| [Gruppenname]   [Kurzbeschreibung]
+| 
+| gefuehrt werden.
+| 
+| 
+| Status
+| ------
+| 
+| Die Gruppe ist moderiert.  Als Moderatoren werden Martina Oderat
+| <moderator@domain.example> und Peter Roponent
+| <proponent@domain.example> 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. Wichtig ist insbesondere auch, daß der
+Account ungefiltert ist, also keine Spamfilter oder Blacklists aktiv
+sind, die ggf. dazu führen, daß legitime Abstimmungs-E-Mail nicht
+angenommen werden. Die meisten kostenlosen Angebote sind daher ebenso
+ungeeignet wie viele Standardaccounts von Webhostinganbietern.
+
+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.
+
+
+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. Maintainer und Danksagungen
+
+Maintainer dieser FAQ: Michael Ottenbruch
+                       Thomas Hochstein
 
-  ______________________________________________________________________
-
-  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.
+Maintainer bis 2010: Thomas Roessler, nach einem Entwurf von Dirk Nimmich
 
-  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.
+Zu diesem Text und seiner Entstehung haben beigetragen:
 
-  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>
+- Lutz Donnerhacke
+- Kristian Köhntopp
+- Rolf Krahl
+- Dirk Nimmich
+- Martin Recke
+- Thomas Roessler
+- Heiko Schlichting
+- Adrian Suter
+- Hans-Christoph Wirth
This page took 0.028305 seconds and 4 git commands to generate.