4.1: Korrektur Liste ungefilteter Accounts
[faqs/dana-manual.git] / dana-manual
index 68f31b0..38374fa 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.1.1
+Last-modified: (unreleased)
 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
+URL: http://th-h.de/faq/dana-manual.txt
+
+          Erläuterungen zur Einrichtung neuer Gruppen in de.*         
+          ===================================================
+
+Inhalt
+------
+
+0. Einleitung
+   0.1. Zielgruppe und Inhalt
+   0.2. Das Einrichtungsverfahren im Überblick
+   0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
+        0.3.1. Vorbereitung
+        0.3.2. Diskussionsphase
+        0.3.3. Abstimmungsphase
+        0.3.4. Umsetzung
+
+1. Vorüberlegungen
+   1.1. Bedarf für eine neue Gruppe
+   1.2. Status quo: bestehende Gruppen und frühere Vorschläge
+   1.3. Mitinteressenten
+
+2. Einrichtungsvorschlag
+   2.1. Auswahl des Gruppennamens
+        2.1.1. Einordnung
+        2.1.2. Namenswahl und technische Vorgaben
+   2.2. Kurzbeschreibung
+   2.3. Charta
+   2.4. Status
+        2.4.1. Pro und contra moderierte Gruppen
+        2.4.2. Einrichtung moderierter Gruppen
+   2.5. Sonderfälle
+
+3. Diskussionsphase
+   3.1. Inhalt und Aufbau eines RfD
+        3.1.1. Inhalt
+        3.1.2. Formale Gestaltung
+   3.2. Einreichung des RfD
+   3.3. Diskussionsphase
+   3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags
+
+4. Abstimmungsphase
+   4.1. Voraussetzungen für die Durchführung einer Abstimmung
+   4.2. Inhalt und Aufbau eines CfV
+   4.3. Abstimmungsphase
+   4.4. Auswertung und Ergebnis der Abstimmung
+
+5. Verfahrensabschluss und Umsetzung
+
+6. Quellen
+   6.1. Grundlegende Informationen
+   6.2. Weiterführende Hinweise
+   6.3. Webseiten
+
+7. Maintainer und Kontakt
+   7.1. Derzeitige Maintainer
+   7.2. Frühere Fassungen
+
+======================================================================
+
+0. Einleitung
+=============
+
+0.1. Zielgruppe und Inhalt
+--------------------------
+
+Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
+internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
+lassen wollen und soll die in den "REGELN FÜR DIE EINRICHTUNG UND
+ENTFERNUNG VON USENET-GRUPPEN" [1] (kurz: Einrichtungsregeln)
+niedergelegten Regeln zur Einrichtung neuer Gruppen kommentieren und
+erläutern. Er gibt dabei notwendig den Blick der Autoren bzw.
+Maintainer auf die Verhältnisse in de(.admin.news).* und ihre
+Erfahrungen wieder.
+
+[1] Veröffentlicht 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
+
+(Eine Liste aller in diesen Erläuterungen genannten Quellen findet
+sich noch einmal in Abschnitt 6.)
+
+Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der
+Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
+Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
+nachfolgende, mindestens einwöchige Diskussion keinen gar zu heftigen
+Gegenwind, wird die Gruppe eingerichtet.
+
+0.2. Das Einrichtungsverfahren im Überblick
+-------------------------------------------
+
+Newsgroups werden nicht auf einem zentralen Server angeboten, sondern
+dezentral auf vielen verschiedenen Newsservern geführt, die ihre
+Beiträge jeweils untereinander austauschen. Damit das funktionieren
+kann und jeder Benutzer dieselben Newsgroups zur Verfügung hat, müssen
+sich die Betreiber dieser Vielzahl von Newsservern nach Möglichkeit
+auf einen einheitlichen Bestand an Gruppen einigen. Das ist bei
+mehreren tausend Newsservern mit manchmal wenigen, manchmal aber auch
+Tausenden Benutzern durch Diskussionen im Einzelfall nicht praktikabel
+möglich. Daher werden für gepflegte Newsgroups-Hierarchien wie de.*
+Listen der Newsgroups geführt, die zur Hierarchie gehören; mit dieser
+Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand
+abgleichen.
+
+Für de.* wird die definitive Liste der bestehenden Newsgroups von der
+Moderation von de.admin.news.announce geführt, die jeden Monat auch
+eine entsprechende, digital signierte Steuernachricht (checkgroups)
+versendet, mit der die meisten Newsserverbetreiber ihren
+Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
+Für die Aufstellung dieser Liste sind vielerlei Möglichkeiten denkbar;
+in de.* entscheiden die Benutzer über ihren Inhalt. Änderungen am
+Gruppenbestand - Neueinrichtung, Löschung oder Umbenennung von Gruppen
+- werden in einem formalisierten Verfahren diskutiert und dann zur
+Abstimmung gestellt.
+
+Jedem Einrichtungsvorschlag sollte eine Überlegungsphase vorangehen,
+in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
+Status, Charta) einschließlich ihrer Einordnung in den bestehenden,
+hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
+mit anderen Interessenten diskutiert werden können. Am Ende dieser
+Vorüberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
+Gruppe heißen soll, was ihre Inhalte sein werden und wie sie sich
+thematisch gegenüber bestehenden Gruppen abgrenzt. Mit der
+Veröffentlichung dieses Vorschlags in de.admin.news.announce als
+Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das
+Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
+die in de.admin.news.groups geführt wird, wird der Vorschlag auf
+inhaltliche Qualität und Akzeptanz abgeklopft und ggf. verändert oder
+verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der
+Vorschlag abstimmungsreif erscheint. Die Veröffentlichung eines
+Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die
+Diskussionsphase und leitet in die Abstimmungsphase über, an deren
+Ende sich zeigt, ob der Vorschlag zur Einrichtung der neuen Gruppe
+angenommen oder abgelehnt wurde. Dementsprechend wird die Gruppe dann
+in die Gruppenliste aufgenommen - oder auch nicht.
+
+Siehe auch:
+
++ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
+| From: bernd@tenuki.de (Bernd Gramlich)
+| Newsgroups: de.admin.infos
+| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
+| 
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Last-modified: 2004-12-06
+| URL: http://www.tmt.de/~gramlich/dan-glossar.html
+| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
+
+
+0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
+----------------------------------------------------------
+
+Das Einrichtungsverfahren lässt sich in folgende Phasen unterteilen,
+die im Folgenden dann näher erläutert werden sollen:
+
+0.3.1. Vorbereitung
+
+* Ideenfindung
+* Information über den status quo, Bedarfsabschätzung
+* Suche nach anderen Interessierten, ggf. interne Diskussion
+* Ausformulierung eines förmlichen Einrichtungsvorschlag (RfD)
+* Einreichung des RfD bei der Moderation von de.admin.news.announce
+
+Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
+enden die Vorbereitungen; das Verfahren wird in die Statusübersicht
+der Moderation von de.admin.news.announce [2] aufgenommen und erhält
+einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prüft
+den RfD (und die weiteren Verfahrensbeiträge) auf Vereinbarkeit mit
+den Regeln, nimmt die nötigen Veröffentlichungen in
+de.admin.news.announce vor und steht dem Proponenten auch als
+Ansprechpartner (und in gewissem Umfang Berater) für sich im Verlauf
+des Verfahrens ergebende Fragen zur Verfügung.
+
+[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem
+    Betreff "dana-Status" wöchentlich in de.admin.news.announce
+    veröffentlicht und im WWW unter <http://www.dana.de/status.html>
+    abrufbar.
+
+0.3.2. Diskussionsphase
+
+* Beginn mit Veröffentlichung des 1. RfD in de.admin.news.announce,
+  de.admin.news.groups und weiteren betroffenen Newsgroups
+* öffentliche Diskussion des Vorschlags in de.admin.news.groups
+* Mindestdauer: 14 Tage
+* Einreichung beliebig vieler weiterer RfDs mit geänderten Vorschlägen
+
+Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
+der übrigen Teilnehmer zu ergründen; Änderungsvorschläge können
+gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
+RfD usw.) aufgenommen werden. Wenn alle Facetten erörtert, alle
+Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
+drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
+Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen möchte oder
+ob er den Vorschlag zurückzieht. Die zur Abstimmung gestellte Fassung
+muss mit dem letzten veröffentlichen RfD im Wesentlichen
+übereinstimmen.
+
+Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
+Rückzug des Vorschlags oder Verfall durch Nichtbetreiben über fünf
+Wochen) oder der Veröffentlichung des 1. CfVs.
+
+0.3.3. Abstimmungsphase
+
+* Beginn mit Veröffentlichung des 1. CfV in de.admin.news.announce und
+  den übrigen Gruppen
+* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
+  E-Mail bestätigt
+* Mindestdauer: 3 Wochen, Höchstdauer: 1 Monat (4 Wochen)
+* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
+* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
+  Abstimmenden
+* einwöchige Einspruchsfrist
+
+Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
+durchgeführt, der den 1. CfV zur Veröffentlichung einreicht, die
+Stimmen per E-Mail sammelt, bestätigt und auszählt und am Ende das
+Ergebnis der Abstimmung zur Veröffentlichung einreicht. Es muss sich
+dabei ausdrücklich nicht um dieselbe Person wie den Proponenten
+handeln; da die Durchführung und Auszählung einer Abstimmung einen
+gewissen technischen und organisatorischen Aufwand erfordert und auch
+Erfahrung im Umgang mit Zweifelsfällen - auch Manipulationsversuchen -
+wünschenswert ist, besteht die Möglichkeit, einen erfahrenen Usenet-
+Teilnehmer um die Übernahme der Abstimmungsleitung zu bitten. Einige
+Freiwillige haben sich zu diesem Zweck als "German Volunteer
+Votetakers" (GVV) zusammengeschlossen.
+
+Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und
+letztlich mit der Veröffentlichung des Ergebnisses. Daran schließt
+sich ein einwöchiger Einspruchszeitraum an, in dem Regelverstöße durch
+einen Einspruch bemängelt werden können. Nach Verstreichen dieses
+Zeitraums wird das Ergebnis der Abstimmung bestandskräftig.
+
+0.3.4. Umsetzung
+
+Wenn der Vorschlag in der Abstimmung angenommen wurde - wozu
+mindestens 60 Stimmen JA-Stimmen und zugleich eine Mehrheit von 2/3
+der abgegebenen gültigen Stimmen ohne die Enthaltungen, also
+mindestens doppelt so viele JA- wie NEIN-Stimmen erforderlich sind -,
+wird das Ergebnis im Anschluss durch die Moderation von
+de.admin.news.announce umgesetzt, indem eine Steuernachricht zur
+Einrichtung der betreffenden Gruppe versandt und diese in die
+kanonische Liste der in de.* vorhandenen Newsgroups aufgenommen wird.
+
+1. Vorüberlegungen
+==================
+
+1.1. Bedarf für eine neue Gruppe
+--------------------------------
+
+Ganz am Anfang der Überlegungen zur Einrichtung einer neuen Newsgroup
+stellt sich zunächst die Frage, ob die angedachte Gruppe denn auch
+tatsächlich benötigt wird und der Vorschlag Aussicht auf Erfolg hat.
+Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
+zukünftigen Nutzung der Gruppe zu rechnen ist, das Thema also im
+Usenet diskutiert werden wird und eine thematisch passende Gruppe
+entweder nicht vorhanden ist oder bereits so rege genutzt wird, dass
+sie überfüllt ist.
+
+Die zukünftige Nutzungsintensität der vorgeschlagenen Gruppe wird
+dabei regelmäßig anhand der derzeitigen Lage beurteilt:
+
+* Gibt es bereits Diskussionen zu dem Thema im Usenet?
+
+* Wenn ja: Ist die bisher dafür genutzte Gruppe überfüllt (so dass man
+  dieses Thema aus ihr abspalten sollte) oder gibt es bislang gar
+  keine Gruppe, in der man das Thema sinnvoll diskutieren kann?
+  Letzteres ist sehr selten, da de.* thematisch vollständig ist; die
+  meisten denkbaren Themen passen in eine oder mehrere bereits
+  bestehende Gruppen thematisch hinein.
+
+  Sind die derzeitigen Diskussionsteilnehmer bereit, zukünftig die neu
+  einzurichtende Gruppe zu benutzen (oder wünschen dies sogar)?
+
+* Wenn nein: Finden anderswo im Netz Diskussionen statt, bspw. in
+  anderen deutschsprachigen Usenet-Hierarchien, in Mailinglisten,
+  Webforen, Communities in sozialen Netzwerken?
+
+  Und sind die Diskutanten bereit, statt des bisher genutzten Mediums
+  oder zusätzlich zu diesem auch das Usenet als Diskussionsmedium zu
+  benutzen?
+
+* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
+  zukünftig einigermaßen intensiven Zuspruch erfahren wird?
+
+Die Erfahrung hat gezeigt, dass die empfundene oder tatsächliche
+gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
+damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
+und ob sie dies im Usenet tun möchten. Es mag sehr wichtige Themen
+geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
+oder die anderswo diskutiert werden, ohne dass bei den Interessenten
+der Wunsch besteht, ihre Diskussionen im Usenet zu führen. Die
+mehrheitliche Ansicht geht überdies dahin, dass es nicht sinnvoll ist,
+für "Orchideenthemen" eigene Newsgroups einzurichten, die dann
+(weitgehend) ungenutzt bleiben; vielmehr wird es überwiegend als
+wünschenswert empfunden, lieber weniger thematisch breiter
+aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
+auf diese Weise den gegenseitigen Austausch beleben und fördern.
+
+Siehe auch:
+
++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
+  <http://th-h.de/infos/usenet/newgroup.php#vorschlag>
+
++ Missverstaendnisse in de.admin.news.groups
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
+| 
+| Archive-name: de-admin/dang-faq
+| Posting-frequency: weekly
+| Last-modified: 2009-01-24
+| URL: http://www.kirchwitz.de/~amk/dai/dang-faq
+
+1.2. Status quo: bestehende Gruppen und frühere Vorschläge
+----------------------------------------------------------
+
+Die Frage nach dem Bedarf an einer neuen Gruppe führt zur Feststellung
+und Beurteilung des status quo: Welche thematisch verwandten Gruppen
+gibt es? Wo sind diese in der Struktur von de.* eingeordnet? Wie
+intensiv werden sie genutzt? Wie lässt sich das Thema der neuen Gruppe
+von den bestehenden themenverwandten Gruppen abgrenzen?
+
+Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
+möglicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
+wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
+Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
+eine solche Gruppe, die dann später wieder aus der Gruppenliste
+entfernt wurde? Aus diesen Überlegungen ergeben sich Hinweise auf die
+Erfolgsaussichten des Vorschlags und möglicherweise auch Anregungen
+für seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
+Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
+wesentliche Änderungen in Inhalt oder Begründung erneut einzubringen.
+
+[3] Am bekanntesten dürfte das Angebot von Google Groups sein:
+    <http://groups.google.com/>
+
+    de.admin.news.announce bei Google Groups:
+    <http://groups.google.com/group/de.admin.news.announce/>
+
+    Erweiterte Suche: <http://groups.google.com/advanced_search>
+
+1.3. Mitinteressenten
+---------------------
+
+     "Gemeinsam sind wir stark."
+
+In der Diskussionsphase kommt es weniger auf die Anzahl der
+Befürworter als vielmehr auf deren Argumente an. Dennoch hilft es,
+einen Vorschlag nicht ganz alleine einzubringen, insbesondere dann,
+wenn man mit dem Procedere in de.admin.news.* noch nicht so vertraut
+ist. Soll der Vorschlag erfolgversprechend sein, wird es ja eine ganze
+Reihe von anderen Interessenten an der vorgeschlagenen neuen Gruppe
+geben. Deren Input ist schon bei der Formulierung des Vorschlags
+hilfreich; Brainstorming und Diskussion mehrerer führt oft zu besseren
+Ergebnissen als einsames Grübeln im stillen Kämmerlein.
+
+Auch in der Diskussion ist es förderlich, einen Vorschlag nicht
+alleine argumentativ zu stützen; nicht nur deshalb, weil eine Mehrzahl
+von Interessenten, die sich auch selbst in die Diskussion einbringt,
+überzeugender ein dauerhaftes Interesse signalisiert als ein
+Einzelner. Auch aus psychologischen Gründen ist es angenehmer, die
+eigene Position nicht alleine vertreten zu müssen.
+
+Eine Mitwirkung anderer Interessenten kann dabei auf vielfältige Weise
+erfolgen. Ein Vorschlag kann durch mehrere Proponenten eingebracht
+werden; die Mitwirkung kann sich aber auch auf Unterstützung bei
+inhaltlichen und Formulierungsfragen oder der formalen Abwicklung des
+Einrichtungsverfahrens oder Beiträge in der Diskussionsphase
+beschränken.
+
+2. Einrichtungsvorschlag
+========================
+
+Vor der Einrichtung einer neuen Newsgroup oder dem Beginn der
+Abstimmung über den entsprechenden Vorschlag müssen nach den
+Einrichtungsregeln Name und Attribute der vorgeschlagenen Gruppe
+feststehen:
+
+|   Ein CfV kann nicht veröffentlicht werden, wenn einer der folgenden
+|   Punkte noch unklar ist:
+| 
+|   o Name der Gruppe
+|   o Kurzbeschreibung der Gruppe
+|   o Charta der Gruppe
+|   o Status der Gruppe (moderiert oder unmoderiert)
+|   o der Name des Moderators im Falle einer moderierten Gruppe
+
+Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
+luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
+sich daher auch die Frage nach der Einordnung der neuen Gruppe in die
+bestehende Struktur der Hierarchie de.*, und in der Charta sollte
+nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
+auch die Abgrenzung zu thematisch ähnlichen Gruppen ihren Platz
+finden.
+
+Sinnvoll ist es daher, sich zunächst Gedanken über das geplante Thema
+der Gruppe und dessen Abgrenzung zu bereits bestehenden Gruppen zu
+machen; daraus ergibt sich die Charta (2.3.). Danach sollte man sich
+überlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
+demnach heißen soll (2.1.); dann fehlt nur noch eine knackige
+Zusammenfassung für die Kurzbeschreibung (2.2.).
+
+Falls eine moderierte Newsgroup vorgeschlagen wird, müssen auch der
+oder die vorgesehenen Moderatoren feststehen; überdies sollte ein
+Konzept für die Moderation vorliegen und die technischen
+Voraussetzungen hinreichend geklärt sein.
+
+2.1. Auswahl des Gruppennamens
+------------------------------
+
+2.1.1. Einordnung
+
+Zunächst sollte die prospektive Gruppe sich in die bestehende
+Namenshierarchie in de.* einpassen. de.* besteht nämlich aus
+thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
+immer feineren thematischen Verästelungen aufweisen. Diese Struktur
+ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollständig
+logisch stringent, und regelmäßig wird es nicht nur einen denkbaren
+Platz geben, an den eine neue Gruppe passen würde.
+
+Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
+bemühen, den bestmöglichen Ort für die neue Gruppe zu finden. Dazu
+gehört sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
+ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
+sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
+angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.
+
+Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
+Einrichtungsregeln auszeichnet und daher nicht Thema dieser
+Erläuterungen ist, bestehen in de.* folgende thematische
+Untergliederungen:
+
+* de.admin.*
+  Die Gruppen der de.admin-Unterhierarchie befassen sich thematisch
+  mit der Selbstverwaltung von de.* und organisatorischen (nicht
+  technischen) Fragen der Administration von Usenet-Systemen,
+  namentlich auch mit deren Missbrauch.
+
+* de.comm.*
+  Die Gruppen der de.comm-Unterhierarchie beschäftigen sich mit den
+  - im Usenet umfänglich vertretenen - Themenbereichen der
+  Kommunikation und Kommunikationstechnik und sind daher noch weiter
+  diversifiziert, im Wesentlichen in die Bereiche
+
+  * Anbieter: 
+  de.comm.anbieter.* - Festnetz- und Mobiltelefonprovider und Tarife
+  de.comm.provider.* - Internetprovider und Onlinedienste
+
+  * Geräte (Hardware) und Technik:
+  de.comm.geraete.* - Festnetz- und Mobiltelefone und Telefonanlagen
+  de.comm.technik.* - Netztechnik (DSL, ISDN, Mobilfunknetze)
+  de.comm.internet.* - Infrastrukturaspekte des Internet
+  de.comm.protocols.* - Kommunikationsprotokolle
+
+  * Software:
+  de.comm.software.* - Browser, Mail-/Newsreader und -server etc.
+
+  und schließlich:
+  de.comm.infosystems.* - WWW samt Webseitenerstellung
+  de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)
+
+* de.comp.*
+  Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
+  ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
+  Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
+  so dazugehört. Auch sie ist demnach umfangreich weiter
+  untergliedert, neben verschiedenen Einzelgruppen namentlich in
+
+  * Hardware:
+  de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks, Handhelds
+  de.comp.hardware.* - Rechner, Laufwerke, Monitore, Netzwerk
+
+  * Betriebssysteme, Anwendungsprogramme und andere Software
+   de.comp.os.* - Windows, Unix, Linux, OS/2, 
+   de.comp.office-pakete.* - MS-Office, Staroffice
+   de.comp.text.* - Textverarbeitung
+   de.comp.datenbanken.* - Datenbanken
+   de.comp.lang.* - Programmiersprachen (C++, Java, Perl, PHP, ...)
+
+* de.rec.*
+  Die Unterhierarchie de.rec.* beschäftigt sich mit
+  Freizeitaktivitäten (recreational activities) aller Art und enthält
+  neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien zu den
+  Themen Musik hören und machen, Sport(arten), Spielen aller Art, am
+  Brett wie am Computer, Science Fiction und Fantasy, Fernseh(seri)en,
+  Filme und Heimkino und (Haus-)Tiere.
+
+* de.sci.*
+  Die Unterhierarchie de.sci.* ist für wissenschaftliche Themen
+  (sciences) vorgesehen und ist vorwiegend anhand der klassischen
+  wissenschaftlichen Themengebiete (Biologie, Chemie, Physik,
+  Mathematik, Medizin, etc. pp.) unterteilt. Teilweise sind aber
+  Themen gerade aus dem gesellschafts- oder sozialwissenschaftlichen
+  Bereich auch in de.soc.* angesiedelt.
+
+* de.soc.*
+  Die Unterhierarchie de.soc.* handelt von gesellschaftlichen Fragen
+  (social issues): Politik und Rechtswesen; Religionen und
+  Weltanschauungen; Kulturen und Subkulturen; Familie,
+  Gleichberechtigung, Senioren, Jugendarbeit, Schule und Studium;
+  Arbeit und Arbeitslosigkeit; Umwelt und Verkehr; Medien und
+  Wirtschaft; Datenschutz und Zensur.
+
+* de.talk.*
+  Die - sehr kleine - Unterhierarchie de.talk.* ist mehr für Smalltalk
+  und entspannten Plausch als Diskussion und Informationsaustausch
+  vorgesehen; viele der verbliebenen Gruppen würden aber ebenso gut
+  nach de.soc.* passen.
+
+* de.org.*
+  Die - gleichfalls kleine - Teilhierarchie de.org.* ist für
+  Organisationen und Vereine, deren Verlautbarungen und Diskussionen
+  um sie herum gedacht. Verblieben sind hier im Wesentlichen
+  Newsgroups zum CCC, zu Mensa und der SPD (bzw. politischen Parteien
+  allgemein).
+
+* de.etc.*
+  In der de.etc.*-Unterhierarchie sind sonstige Themen
+  zusammengefasst, die nicht in eine der anderen Unterhierarchien
+  passen. Dazu gehören das Bahnwesen, Autos und andere Fahrzeuge,
+  Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
+  Notfallrettung und Militärwesen oder auch die Haushaltsführung.
+
+* de.markt.*
+  In de.markt.*, dem Kleinanzeigenbereich des deutschsprachigen
+  Usenets, - und nur hier! - haben private, nicht-kommerzielle
+  Angebote und Gesuche Platz.
+
+Siehe auch:
+
++ Die Newsgruppen der de-Hierarchie
+| From: Daniel Roth <25.8@bluemail.ch>
+| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2011-03-07> Die Newsgruppen der de-Hierarchie
+| 
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| Last-modified: 2011-03-07
+| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
+
+2.1.2. Namenswahl und technische Vorgaben
+
+Der "eigentliche" Name der Gruppe, insbesondere also der letzte
+Namensbestandteil, sollte so aussagekräftig und allgemeinverständlich,
+aber zugleich auch so kurz wie möglich gewählt werden. Kryptische oder
+mehrdeutige Abkürzungen sollte man möglichst nicht verwenden. Wenn
+diese gar nicht zu vermeiden sind, sollten sie in der
+Kurzbeschreibung, spätestens aber in der Charta erläutert werden.
+
+Für die Wahl des Gruppennamens sind zudem technisch geprägte
+Vorgaben [4] zu beachten, die sich auch im WWW unter
+<http://dana.de/newsgroup-namen.html> nachlesen lassen:
+
+* 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>
+  dabei, dass 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 (-).
+
+* Insgesamt soll die Länge des Newsgruppennamens 71 Zeichen nicht
+  überschreiten.
+
+[4] Beschlossen im Jahr 2000: 
+|   From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
+|   Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
+|   Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
+|   Date: 2000/07/18
+|   Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
+    <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
+
+2.2. Kurzbeschreibung
+---------------------
+
+Die Kurzbeschreibung (auch "Tagline" genannt) soll in Ergänzung zum
+Gruppennamen das Thema kurz umreißen. Im Gegensatz zur Charta, der
+ausführlichen thematischen Beschreibung des Gruppeninhalts, wird sie
+in der Regel zusammen mit dem Gruppennamen auf den Newsservern
+vorgehalten und kann in den gängigen Newsreadern angezeigt und ggf.
+auch durchsucht werden. Sie ist auch Bestandteil der regelmäßig
+versandten Steuernachrichten, die den aktuellen Gruppenbestand von
+de.* enthalten.
+
+Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
+ab: Sie muss kurz, knapp und für jeden verständlich sein. "Diskussion
+über" oder "Informationen von" sind zum Beispiel notorisch
+überflüssige Formulierungen. Hingegen sollten möglichst Begriffe in
+der Kurzbeschreibung auftauchen, nach denen an der Gruppe
+interessierte Nutzer möglicherweise suchen werden. 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, dass 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).
+
+Beispiele für Kurzbeschreibungen finden sich in dem bereits genannten
+Text "Die Newsgruppen der de-Hierarchie".
+
+2.3. Charta
+-----------
+
+Die Charta ist die Beschreibung der Newsgroup und ihres vorgesehenen
+Themas schlechthin. Sie soll so kurz wie möglich und nur so
+ausführlich wie nötig umreißen, worum es in der Gruppe geht, welche
+Themen dort diskutiert werden sollen und welche ggf. nicht und welche
+besonderen Konventionen dort - unter Abweichung von den sonstigen
+Üblichkeiten im deutschsprachigen Usenet - gelten sollen.
+
+Es ist hilfreich, für das Thema der Gruppe einige Beispiele als nicht
+abschließende Aufzählung aufzunehmen; so lassen sich auch (weitere)
+Schlagworte unterbringen, nach denen möglicherweise gesucht wird.
+Dabei ist aber zu berücksichtigen, dass die Charta nur in
+entsprechenden Listen im Usenet und auch im WWW veröffentlicht wird,
+aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
+Newsreader zur Verfügung steht.
+
+Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
+diskutiert werden sollen, obwohl möglicherweise Name und
+Kurzbeschreibung bei flüchtiger Durchsicht zu dieser Annahme führen
+könnten, empfiehlt es sich, diese Facetten - oder Themen - in der
+Charta ausdrücklich auszuschließen. Genauso sollte innerhalb der
+Charta das Diskussionsthema von anderen, themenverwandten Gruppen
+abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
+nicht tunlich, weil ansonsten bei jeder Umbenennung oder Löschung der
+betreffenden Gruppen eine Chartaänderung nötig würde.
+
+Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
+gelten sollen als sonst im Netz üblich sollte auch dies in der Charta
+vermerkt werden. Zu denken wäre bspw. an die (ausdrückliche) Akzeptanz
+anonymer Beiträge oder von Inseraten. Gleichfalls sollten vorgesehene
+ungewohnte technische Maßnahmen - zu denken wäre hier bspw. an die
+Eingangsbestätigung von Postings per E-Mail durch die sog. Reflektoren
+in den Testgruppen - durch die Charta legitimiert werden. In allen
+diesen Fällen sollte einerseits berücksichtigt werden, dass eine
+Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
+in der Regel ausdrücklich abgelehnt wird, sowohl wegen der unnötigen
+Verlängerung der Charta als auch, weil dies den Eindruck vermitteln
+könnte, die entsprechenden Regeln und Konventionen hätten nur dort
+Geltung, wo sie ausdrücklich in der Charta stehen. Andererseits darf
+man bei der Formulierung solcher abweichenden Üblichkeiten nicht aus
+den Augen verlieren, dass sowohl technische als auch soziale Vorgaben
+in der Regel gute Gründe haben und zudem als feststehende Gewohnheiten
+betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut
+begründeten Sonderfällen Aussicht auf Erfolg haben werden.
+
+Die Charta sollte so knapp wie möglich gehalten werden; weitergehende
+Erläuterungen und solche Regeln, die sich voraussichtlich häufiger
+ändern werden, gehören nicht in die Charta, sondern sollten Gegenstand
+einer (regelmäßig geposteten und nach Möglichkeit auch im WWW
+bereitgestellten) Einführung, eines Infopostings oder einer FAQ sein.
+So sollte bspw. die thematische Kennzeichnung von Unterthemen im
+Betreff von Postings durch sog. Tags ("[Reisebericht] Meine Tour durch
+Tadschikistan") in der Charta allenfalls generelle Erwähnung finden;
+die einzelnen angedachten Tags gehören dann in eine anderweitig
+bereitgestellte Erläuterung. Auch das Moderationskonzept einer
+moderierten Gruppe gehört schon aufgrund seiner Länge nicht in die
+Charta.
+
+Es empfiehlt sich, einige bestehende Chartas - insbesondere solcher
+Gruppen, die in den letzten 5-10 Jahren eingerichtet wurden - zu
+studieren, um ein Gefühl für die Abfassung einer guten Charta zu
+bekommen. Solche Beispiele finden sich in dem bereits genannten Text
+"Die Newsgruppen der de-Hierarchie".
+
+2.4. Status
+-----------
+
+Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status
+"moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
+dann ohne weiteres in der Newsgroup veröffentlicht und weltweit
+verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
+stattdessen versendet der Newsserver, bei dem das Posting eingespeist
+wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
+mehrköpfige Moderation). Diese entscheidet dann über die
+Veröffentlichung.
+
+2.4.1. Pro und contra moderierte Gruppen
+
+Moderierte Gruppen haben den Vorteil einer meist besseren
+Übersichtlichkeit und höheren inhaltlichen Qualität, weil Beiträge
+vorgefiltert werden können; ihr Nachteil ist die zwangsläufig
+entstehende Verzögerung durch die Weiterleitung jedes Beitrags an
+einen Moderator, der ihn bestätigen muss. Sie eignen sich daher vor
+allem für Ankündigungen oder FAQs. Ein Beispiel hierfür ist
+de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
+Abstimmungen veröffentlicht werden, so dass die Gruppe auch für
+diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
+im einzelnen zu folgen, und eine vorherige Überprüfung der
+Veröffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
+die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
+denen nur FAQs und Infotexte veröffentlicht werden.
+
+Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
+Erhaltung einer höheren inhaltlichen Qualität dienen und ermöglicht
+vor allem den Ausschluss von bewussten Störern, begegnet im Gegenzug
+aber oft dem Vorwurf der Zensur, so unbegründet dieser im Einzelfall
+auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden
+Verzögerungen vor Veröffentlichung eines Beitrags den Fluss der
+Diskussion stören und an Veröffentlichung ihrer Beiträge in Echtzeit
+gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
+allem personelle Aufwand nicht zu unterschätzen; immerhin bedeutet die
+Moderation einer Diskussionsgruppe, dass auf Jahre hinaus eine
+Einzelperson oder Gruppe im Extremfall 24 Stunden am Tag und 7 Tage in
+der Woche erreichbar sein muss, um eingehende Beiträge so zeitnah wie
+möglich zu prüfen und freizugeben.
+
+2.4.2. Einrichtung moderierter Gruppen
+
+Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
+im Einrichtungsverfahren zusätzliche Angaben zur Moderation zu machen;
+dazu gehören der oder die vorgesehene(n) Moderator(en) und die
+Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
+für die Newsgroup zur Freigabe weitergeleitet werden sollen. Außerdem
+muss die Kurzbeschreibung entsprechend ergänzt werden. Schließlich
+sollte für die Durchführung der Moderation sinnvollerweise ein Konzept
+vorliegen und die technischen Voraussetzungen geschaffen und getestet
+sein.
+
+* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
+  vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
+  Veröffentlichung des Vorschlags seine entsprechende Bereitschaft
+  erklärt haben; in der Regel wird es sich empfehlen, ein mehrköpfiges
+  Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
+  auch im Falle eines mehrwöchigen Urlaubs oder gar eines dauerhaften
+  Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
+  interessiert sein mag  - die Moderation handlungsfähig bleibt und
+  Beiträge weiterhin veröffentlicht werden können. Für moderierte
+  Diskussionsgruppen wird regelmäßig ein ausreichend großes Team
+  zwingend vorzusehen sein, damit Beiträge zumindest tagsüber zeitnah
+  veröffentlicht werden können.
+
+  Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
+  Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
+  Einreichungen bewerten zu können, von den zu erwartenden
+  Diskussionsteilnehmern akzeptiert werden und schließlich absehbar
+  für längere Zeit für diese Tätigkeit zur Verfügung stehen. Erfahrung
+  im Usenet und ggf. die notwendigen technischen Kenntnisse zur
+  Durchführung der Moderation sind hilfreich.
+
+* Wenn die (erste) Moderation personell feststeht, stellt sich als
+  nächstes die Frage, welche E-Mail-Adresse für Einreichungen
+  ("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
+  in jedem Newsserver oder an einer zentralen Stelle (den Relays für
+  moderators.isc.org) in der Konfiguration vermerkt werden, sollte
+  sich also so selten wie möglich ändern; außerdem sollte die Adresse
+  zuverlässig erreichbar sein und ggf. die Möglichkeit für
+  ausreichende Spamfilterung bieten; langjährig aktive und regelmäßig
+  veröffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
+  Spam an.
+
+  Daneben sollte eine weitere Adresse veröffentlicht werden, über die
+  der Moderator oder die Moderation kontaktiert werden können, ohne
+  dass eine Veröffentlichung erfolgt, um bspw. für Anfragen erreichbar
+  sein.
+
+* Die Kurzbeschreibung der Gruppe (2.2.) muss im Falle einer moderierten
+  Gruppe zwingend mit der Submissionsadresse und dem Schlüsselwort
+  "(Moderated)" in exakt dieser Schreibweise enden, bspw. so:
+| de.gruppe.mod   Moderierte Gruppe. <moderation@domain.example> (Moderated)
+
+* Falls die zu moderierende Gruppe keine Diskussionsgruppe ist,
+  sondern nur Ankündigungen, FAQs o.ä. enthalten soll, sollte eine
+  Gruppe bestimmt werden, in der diese Ankündigungen oder FAQs
+  anschließend ggf. diskutiert werden können und in die Antworten dann
+  per gesetztem Followup-To:-Header geleitet werden.
+
+* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
+  welchen Kriterien Beiträge akzeptiert oder zurückgewiesen werden, ob
+  sie ggf. verändert veröffentlicht werden können und wie mit
+  Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
+  mehrköpfigen Moderation stellt dies eine einheitliche Handhabung
+  sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
+  werden und danach (regelmäßig) veröffentlicht werden.
+
+  Entsprechende Beispiele finden sich in bereits bestehenden
+  moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der
+  de-Hierarchie" enthält teilweise Verweise darauf.
+
+* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
+  Möglichkeit, einen per E-Mail übersandten Beitrag unter Beibehaltung
+  der wesentlichen Informationen auch im Header - aber unter Wegfall
+  mancher und Ergänzung anderer Headerzeilen - als Posting zu
+  veröffentlichen. Insbesondere dann, wenn mehr als eine Person -
+  parallel - an der Moderation beteiligt sein soll (was sich
+  mittlerweile als Regelfall etabliert haben dürfte), empfiehlt es
+  sich, das entsprechende Zusammenwirken auch technisch zu
+  unterstützen. In der Regel wird die Moderation einer Newsgroup also
+  die Installation entsprechender Software auf dem eigenen Rechner
+  oder sogar die Einrichtung auf einem übers Netz erreichbaren
+  Rechner, bspw. mit einem Webinterface, und deren Bedienung
+  erfordern.
+
+  Das muss nicht zwingend durch die Moderatoren selbst erfolgen; im
+  Zweifel werden aktive Netzteilnehmer bereit sein, eine solche
+  Installation zur Verfügung zu stellen. Die Auswahl und Erprobung der
+  vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
+  Kontaktaufnahmen sollten aber spätestens parallel zum laufenden
+  Einrichtungsverfahren erfolgen; Tests können bspw. in der Newsgroup
+  de.alt.test.moderated erfolgen.
+
+Siehe auch:
+
++ Unknown: NetNews Moderator's Handbook (1994, engl.)
+  <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
+  <http://pages.swcp.com/~dmckeon/mod-faq.html>
++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
+  <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
+  <http://www.big-8.org/wiki/Moderated_Newsgroups>
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+  <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
++ Informationen über de.alt.test.moderated
+| From: Thomas Hochstein <thh@inter.net>
+| Newsgroups: de.alt.test.moderated
+| Subject: Info: de.alt.test.moderated <2010-11-01>
+| 
+| Last-modified: 2010-11-01 
+| Posting-frequency: monthly  
+
+2.5. Sonderfälle
+----------------
+
+Die vorstehenden Erläuterungen decken den Regelfall der Einrichtung
+einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene
+Sonderfälle:
+
+* Aufteilung von Gruppen
+
+  Wenn eine bestehende Newsgroup aufgrund der regen Nutzung in mehrere
+  Gruppen unterteilt werden soll, entsteht daraus in der Regel eine
+  neue Teilhierachie (ein neuer Zweig am Baum der Struktur von de.*).
+  Die Einrichtungsregeln sehen für diesen Fall in Punkt 7 folgendes
+  vor:
+
+| .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie --
+|   sei es durch Umwandlung einer bestehenden Gruppe oder durch
+|   Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc
+|   endende Gruppe eingerichtet. Der zur Gründung der Hierarchie
+|   führende RfD hat hierzu die notwendigen Angaben bereitzustellen.
+|   Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
+|   findet hierüber eine normale Abstimmung statt.
+
+  Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe für
+  Ausrüstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
+  werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
+  eingerichtet werden. Dies geschieht regelmäßig durch Umbenennung der
+  bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
+  also auch dazu Informationen enthalten.
+
+* Einrichtung einer neuen Teilhierarchie
+
+  Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
+  vorgeschlagen werden soll, sondern direkt mehrere, thematisch
+  zusammenhängende, also auf diese Weise eine neue Teilhierachie
+  entsteht.
+
+  Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
+  "de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
+  eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
+  aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
+  mit Ködern zu tun haben. Die entsprechenden Informationen - Name,
+  Kurzbeschreibung, Charta - müssen ebenfalls im Einrichtungsvorschlag
+  enthalten sein.
+
+* Einrichtung mehrerer Gruppen
+
+  In einem Einrichtungsvorschlag sollte nur dann die Einrichtung
+  mehrerer Gruppen zusammengefasst werden, wenn diese in einem inneren
+  Zusammenhang stehen, wenn bspw. eine bestehende Gruppe aufgeteilt
+  werden oder direkt eine komplette neue Teilhierarchie eingerichtet
+  werden soll. In diesem Fall muss der Einrichtungsvorschlag dann für
+  alle Gruppen die notwendigen Informationen bereitstellen.
+
+  Zu berücksichtigen ist, dass Vorschläge grundsätzlich nicht "en
+  bloc" zur Abstimmung gestellt werden können; vielmehr ist über jeden
+  Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
+  Teil 7 folgende Vorgaben:
+
+| Übertragbarkeit: Stimmen können nicht auf einen anderen
+|   Abstimmungsvorschlag übertragen werden. Eine Stimme zählt nur für
+|   GENAU DEN Vorschlag, für den sie abgegeben wurde. Insbesondere
+|   darf eine Stimme für oder gegen eine Newsgruppe mit einem
+|   bestimmten Namen NICHT als Stimme für oder gegen eine Newsgruppe
+|   mit einem anderen Namen oder einer anderen Charta, einem anderen
+|   unmoderiert/moderiert Status oder, falls moderiert, einem anderen
+|   Moderator oder einer anderen Gruppe von Moderatoren gezählt
+|   werden. Über jede Gruppe wird einzeln abgestimmt, Verknüpfungen
+|   von Wahlen sind nicht möglich.
+
+* Diskussion mehrerer Alternativen
+
+  Ziel der Diskussion sollte es regelmäßig sein, am Ende der
+  Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
+  Das schließt nicht aus, in der Diskussion zunächst mehrere denkbare
+  Alternativen vorzuschlagen; die Diskussion sollte aber schließlich
+  zu einem mehrheitsfähigen Vorschlag führen. Ggf. kann dazu auch ein
+  unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
+  sich ausschließende Alternativen zur Abstimmung zu stellen sollte
+  nach Möglichkeit vermieden werden, weil die Abstimmung sonst
+  einerseits schnell sehr kompliziert wird und andererseits die Gefahr
+  besteht, dass entweder kein Vorschlag eine Mehrheit erhält (obwohl
+  die Mehrzahl der Abstimmenden durchaus generell für eine Einrichtung
+  der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
+  Vorschlägen angenommen wird, dass so niemand gewollt hat.
+
+  Die für die Abstimmung in diesem Fall zu beachtenden Regeln für
+  "kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
+  und lauten folgendermaßen:
+
+| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
+| höchstens eine eingerichtet werden soll ("kombiniertes Voting").
+| Dabei wird über die Einrichtung jeder einzelnen Gruppe gemäß den
+| obigen Regeln abgestimmt.
+| 
+| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
+| zusätzlich ein Stichentscheid zwischen all diesen Gruppen statt.
+| Falls in den Einrichtungsfragen mehr als eine Gruppe angenommen
+| wird, so wird davon einzig diejenige eingerichtet, welche im
+| Stichentscheid das beste Verhältnis Zustimmung : Ablehnung aufweist.
+
+  Siehe dazu auch:
+
+  + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+|   From: faq@wortrei.ch (Adrian Suter)
+|   Newsgroups: de.admin.news.regeln,de.admin.infos
+|   Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+|   
+|   Archive-name: de-admin/entscheidung
+|   Posting-frequency: weekly
+|   Last-modified: 2003-12-31
+|   URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
+|   URL: http://www.kirchwitz.de/~amk/dai/entscheidung
+
+3. Diskussionsphase
+===================
+
+Wenn alle Vorüberlegungen abgeschlossen sind, kann das "offizielle"
+Einrichtungsverfahren mit der Abfassung eines förmlichen
+Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
+bei der Moderation von de.admin.news.announce eingereicht und von
+dieser dann nach Prüfung veröffentlicht wird.
+
+3.1. Inhalt und Aufbau eines RfD
+--------------------------------
+
+3.1.1. Inhalt
+
+Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
+2. dargestellten notwendigen Informationen und einer Begründung des
+Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
+Vorschlag und der Notwendigkeit für die bzw. dem Erfolg der
+vorgeschlagenen neuen Gruppe zu überzeugen.
+
+Üblicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
+und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
+Begründung, die den Hintergrund für den Vorschlag und die Überlegungen
+insbesondere zu den bereits oben unter 1. ("Vorüberlegungen")
+genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
+Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
+im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
+Monaten vorzunehmen ("Trafficnachweis"). Außerdem enthält der RfD
+natürlich Namen und Mailadressen des- oder derjenigen, der/die den
+Vorschlag einreichen ("Proponent(en)"). Bei einer Mehrzahl von
+Personen bietet sich ggf. die Einrichtung eines Verteilers für die
+Kommunikation mit der Moderation von de.admin.news.announce und für
+eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.
+
+Schließlich ist auch zu entscheiden, in welchen Gruppen der RfD
+veröffentlicht werden soll; das sind mindestens de.admin.news.announce
+und de.admin.news.groups, zusätzlich sollten aber auch die Gruppen
+aufgenommen werden, die durch das Verfahren vorhersehbar tangiert
+werden, also namentlich die Gruppe(n), die aufgeteilt werden soll(en),
+deren Themenbereiche durch die neue Gruppe eingeschränkt werden oder
+die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
+natürlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
+stattfinden oder in denen man sich Interessen an der neuen Gruppe
+erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
+möglich und nur so lang wie nötig sein sollte; dies schon deshalb,
+weil in übermäßig viele Gruppen verteilte Postings heutzutage
+möglicherweise als Spam ausgefiltert werden.
+
+Eine Veröffentlichung durch die Moderation von de.admin.news.announce
+kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im
+Einverständnis mit deren Moderation. In Gruppen außerhalb von de.*,
+auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
+Webforen o.ä. kann der Proponent nach Veröffentlichung des RfDs einen
+Hinweis auf diesen ("Pointer") veröffentlichen, der u.a. Newsgroups,
+Betreff und auch die Message-ID des RfDs enthalten sollte, damit
+Interessenten den Vorschlag und die Diskussion finden können.
+
+3.1.2. Formale Gestaltung
+
+Für die formale Gestaltung eines RfD gibt es keine verbindlichen
+Vorgaben; allenfalls haben sich Üblichkeiten entwickelt. Es empfiehlt
+sich auch hier, einige ältere RfD in de.admin.news.announce als Muster
+heranzuziehen. Das kann dann bspw. so aussehen:
+
+|             1. RfD (Diskussionsaufruf)
+|             ==========================
+| 
+| zur Einrichtung der neuen Gruppe
+| 
+| [Gruppenname]   [Kurzbeschreibung]
+|
+| Status: Die Gruppe ist unmoderiert.
+
+oder
+
+| Status
+| ------
+|
+| Die Gruppe ist moderiert.
+| 
+| Moderatoren sind Adam Berthold <adam@berthold.example> und
+| Charlotte Dominik <charlotte@dominik.example>.
+| 
+| Die Submissionsadresse lautet <submissionen@domain.example>.
+| 
+| Charta
+| ------
+| 
+| [Charta]
+| 
+| Hintergrund / Begründung
+| -----------   ----------
+| 
+| [Begründung, ggf. untergliedert]
+|
+| Proponent(en)
+| -------------
+| 
+| [Name(n) und Mailadresse(n)]
+
+Unter <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
+einen "RfD-Generator" eingerichtet. Über ein Formular werden die
+notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige
+Fehler hin überprüft und daraus dann ein Text erzeugt, der als RfD
+eingereicht werden kann.
+
+3.2. Einreichung des RfD
+------------------------
+
+Der fertige RfD ist dann per E-Mail an <moderator@dana.de> an die
+Moderation von de.admin.news.announce einzureichen. Neben dem
+eigentlichen Text sollte dabei auch die Liste der Gruppen übermittelt
+werden, in denen der RfD veröffentlicht werden soll. Der RfD kann auch
+bereits einschließlich des Headers (mit Absender, Betreff,
+Gruppenliste etc.), bspw. als angehängte Textdatei, übermittelt
+werden.
+
+Üblicherweise wird die Moderation den Eingang des RfD bestätigen und
+ihn in den wöchentlich geposteten Status aufnehmen, der auch auf den
+Webseiten der Moderation veröffentlicht wird. Danach wird ein
+Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
+überprüft, ggf. Rücksprache mit dem oder den Proponenten nimmt und ihn
+schließlich in de.admin.news.announce und den übrigen Gruppen
+veröffentlicht.
+
+Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
+sind oder Unsicherheit bestehen, können diese in der Regel mit dem
+Verfahrensbetreuer diskutiert und geklärt werden. Die
+Verfahrensbetreuer der Moderation von de.admin.news.announce haben
+üblicherweise bereits längerfristige Erfahrungen mit de.* und dem
+Einrichtungsverfahren gesammelt und können daher im Zweifel Tips und
+Hinweise geben oder beratend tätig werden.
+
+Siehe auch:
+
++ Moderationskonzept der derzeitigen Moderation von d.a.n.a
+| From: moderator@dana.de (Moderation von de.admin.news.announce)
+| Newsgroups: de.admin.news.announce,de.admin.news.misc
+| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
+  <http://dana.de/modkonzept.html>
+
+3.3. Diskussionsphase
+---------------------
+
+Nachdem die Moderation den RfD veröffentlicht hat, findet in
+de.admin.news.groups die Diskussion über den Vorschlag statt. Die
+Proponenten sollten die Diskussion verfolgen und sich an ihr
+beteiligen, dabei auf Einwände und Kritik eingehen und ggf. ihre
+Begründung verfeinern.
+
+Häufig wird die Diskussion sinnvolle Ergänzungen zum ursprünglichen
+Vorschlag bringen, die in einen neuen, geänderten Vorschlag
+eingearbeitet werden können. Wenn dies der Fall ist, kann nach einiger
+Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur
+Veröffentlichung eingereicht werden, der den modifizierten Vorschlag
+und eine Begründung, warum welche Vorschläge aufgenommen oder
+verworfen wurden, enthält. Dieser zweite RfD erscheint als Antwort
+("Followup") auf den ersten.
+
+Besteht weiterer Diskussionsbedarf, können auch mehrere weitere RfDs
+veröffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
+unnötig verlängert oder verzögert werden; es ist aber auch nicht
+sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu
+veröffentlichen. Vielmehr sollte die Diskussion beobachtet und die
+sich herauskristallisierenden Verbesserungsvorschläge gesammelt
+werden; erst wenn sich ein Konsens abzeichnet oder sich jedenfalls die
+Diskussion beruhigt (oder im Kreis zu drehen beginnt), ist in der
+Regel der richtige Zeitpunkt gekommen, die bisherigen Vorschläge und
+Änderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
+stellen und dann auf dieser Basis einen geänderten Vorschlag als
+weiteren RfD zu veröffentlichen.
+
+Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
+möglichst konstruktiv geführt werden. Als Proponent sollte man sich
+jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer
+ausschließlich erfreulich sein wird; de.admin.news.groups ist auch
+insofern ein Spiegel des Usenets als es dort neben gutwilligen
+Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden
+Teilnehmern auch starrköpfige und unfreundliche. Auch dort gilt aber,
+dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.
+
+3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags
+-----------------------------------------------------------
+
+Am Ende der Diskussion sollte(n) der/die Proponent(en) sich darüber
+Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag
+voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall,
+kann das Verfahren zurückgezogen werden.
+
+Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
+der aus seiner/ihrer Sicht nunmehr endgültige Vorschlag feststellt,
+zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
+Vorschlag nur in der Form des letzten veröffentlichen RfDs zur
+Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss
+inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen
+übereinstimmen. Ggf. ist also vor dem Beginn der Abstimmung noch
+einmal ein weiterer RfD mit den letzten vorgesehenen Änderungen zu
+veröffentlichen.
+
+Nach Möglichkeit sollte am Ende der Diskussion nur noch ein einziger,
+einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls müssen aber
+für jede vorgeschlagene Gruppe Name, Kurzbeschreibung, Status und
+Charta (und bei moderierten Gruppen der Moderator und die
+Submissionsadresse) - notfalls in mehreren Varianten - feststehen.
+
+4. Abstimmungsphase
+===================
+
+Die Abstimmung über einen Vorschlag findet per E-Mail statt. Die
+abgegebenen Stimmen werden während des Abstimmungszeitraums an die E-
+Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
+auszählt und am Ende ein Ergebnis der Abstimmung mit Namen, E-Mail-
+Adresse und Stimmabgabe aller Teilnehmer veröffentlicht. Die
+Durchführung der Abstimmung muss nicht zwingend durch den oder die
+Proponenten erfolgen; aufgrund der notwendigen technischen und
+organisatorischen Kenntnisse und Voraussetzungen empfiehlt es sich
+oft, die Durchführung einem erfahrenen Usenet-Teilnehmer oder den
+"German Volunteer Votetakers" (GVV) zu überlassen.
+
+4.1. Voraussetzungen für die Durchführung einer Abstimmung
+----------------------------------------------------------
+
+Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen
+gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld
+prüfen:
+
+* Für die Durchführung der Abstimmung 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 Missverständnisse
+  auftreten oder Wahlscheine in der sonstigen Post verloren gehen.
+  Wichtig ist insbesondere auch, dass der Account ungefiltert ist, also
+  keine Spamfilter oder Blacklists aktiv sind, die ggf. dazu führen,
+  dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
+  von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
+  Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
+  von Webhosting- oder Internetzugangsanbietern.
+
+  Siehe dazu auch:
+
+  + Zu Abstimmadressen und Filtermassnahmen
+|   From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
+|   Organization: Moderation von de.admin.news.announce
+|   Newsgroups: de.admin.news.announce,de.admin.news.regeln
+|   Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
+|   Date: Sat, 12 Mar 2011 23:15:00 +0100
+|   Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
+|   
+|   Filtermaßnahmen bei der Durchführung von Abstimmungen
+|   =====================================================
+
+* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von
+  Hand zu bearbeiten, sondern dafür geeignete Software zu verwenden,
+  die Plausibilitätsprüfungen vornimmt, Bestätigungen per E-Mail
+  versenden kann und Auswertungen automatisch erstellt.
+
+  Die verbreitetste Softwarelösung dafür ist UseVote; mehr
+  Informationen dazu und eine Downloadmöglichkeit gibt es auf
+  <http://www.usevote.de>.
+
+* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
+  haben sich einige regelmäßige Teilnehmer in de.admin.news.* dazu
+  bereiterklärt, ungefilterte Abstimmungsaccounts einzurichten und die
+  eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
+  des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.ä.
+  zu ermöglichen. Dazu zählen u.a.
+
+  - Ralph Angenendt <ihr.name@strg-alt-entf.org>
+  - Ralf Döblitz <doeblitz@doeblitz.net>
+  - Karsten Düsterloh <kd-usenet@tprac.de>
+  - Michael Grimm <trashcan@odo.in-berlin.de>
+  - Emil Schuster <emil@wieslauf.sub.de>
+
+  Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
+  Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
+  abzustimmen.
+
+* Daneben besteht auch die Möglichkeit, die Abstimmung gar nicht
+  selbst durchzuführen, sondern damit einen Dritten zu beauftragen,
+  der weitergehende technische Möglichkeiten oder größere Erfahrungen
+  mit der Durchführung von Abstimmungen hat. Überdies ist es zwar
+  zulässig und auch der von den Einrichtungsregeln ursprünglich
+  vorgesehene Regefall, dass der Proponent auch die Abstimmung
+  durchführt, manchmal ist es aber erwünscht, damit einen unabhängigen
+  Dritten zu beauftragen.
+
+  Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
+  erfahrene Votetaker haben sich überdies zu den "German Volunteer
+  Votetakers" (GVV) zusammengeschlossen und sind unter der Adresse
+  <gvv@dana.de> erreichbar. Jeder Proponent kann unter dieser Adresse
+  - rechtzeitig! - nachfragen, ob ein Mitglied der GVV bereit und in
+  der Lage ist, für ihn die Abstimmung durchzuführen. In den letzten
+  Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
+  Mitglieder der GVV durchgeführt.
+
+  Siehe dazu auch:
+
+  + GVV-FAQ
+|   From: Thomas Hochstein <gvv@gvv.th-h.de>
+|   Newsgroups: de.admin.infos,de.admin.news.groups
+|   Subject: <2011-02-19> GVV-FAQ
+|   
+|   Archive-name: de-admin/gvv-faq
+|   Posting-frequency: weekly
+|   Last-modified: 2011-02-19
+|   URL: http://gvv.th-h.de/faq.php
+|   URL: http://www.kirchwitz.de/~amk/dai/gvv-faq
+
+4.2. Inhalt und Aufbau eines CfV
+--------------------------------
+
+Auch für den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er
+muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name,
+Kurzbeschreibung, Charta, Status, ggf. Moderator) und die für die
+Teilnahme an der Abstimmung notwendigen Informationen, namentlich die
+Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
+den einzelnen Abstimmungspunkten, enthalten. Der Abstimmungszeitraum
+muss mindestens drei Wochen, darf aber höchstens vier Wochen betragen.
+
+Üblich ist es, auf Basis des letzten veröffentlichen RfD einen CfV zu
+entwerfen. Dabei kann der Begründungsteil gekürzt werden oder ganz
+entfallen und durch einen Verweis auf die geführte Diskussion -
+Message-IDs der RfDs - ersetzt werden. Hinzugefügt werden dann die
+Abstimmungsmodalitäten: Votetaker, Abstimmadresse, Abstimmungsende,
+ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
+Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele für
+Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unüblich.
+Bei einfachen Abstimmungen erweist sich eine solche Darstellung
+nämlich als überflüssig; bei komplexeren Abstimmungen hingegen würde
+die Darstellung aller möglichen Abstimmungsvarianten und der
+entsprechenden Ergebnisse solchermaßen unübersichtlich und aufwendig,
+dass regelmäßig darauf verzichtet wird. Wenn jedoch die einzelnen
+Abstimmungsmöglichkeiten dargestellt werden, dann müssen sowohl die
+Abstimmungsmöglichkeiten für wie auch die gegen einen Vorschlag
+dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu
+vermeiden.
+
+Beispiele für CfVs finden sich in de.admin.news.announce. Eine
+mögliche Gestaltung wäre folgende:
+
+|             1. CfV (Abstimmungsaufruf)
+|             ==========================
+| 
+| zur Einrichtung der neuen Gruppe
+| 
+| [Gruppenname]   [Kurzbeschreibung]
+|
+| Status: Die Gruppe ist unmoderiert.
+|
+| Charta
+| ------
+| 
+| [Charta]
+| 
+| Hintergrund / Begründung
+| -----------   ----------
+| 
+| [kurze Begründung, ggf. Verweis auf die Diskussion]
+|
+| Proponent(en)
+| -------------
+| 
+| [Name(n) und Mailadresse(n)]
+|
+| Abstimmungsmodalitäten:
+| =======================
+| 
+| Votetaker      : [Name und Mailadresse]
+| Abstimmadresse : [Mailadresse]
+| Abstimmungsende: Mit Ablauf des [Datum]
+| Wahlschein     : Untenstehendes Formular ist zu verwenden. Möglich sind
+|                  bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
+| 
+| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
+| der bei Beginn der Abstimmung gültigen Fassung, die in de.admin.infos
+| und unter <http://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
+| veröffentlicht sind. Sie erläutern das Wahlverfahren detailliert und
+| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
+| 
+| Gezählt werden nur per E-Mail bei der Abstimmadresse eingegangene
+| Stimmen. Diese werden einzeln per E-Mail bestätigt. Das Ergebnis wird
+| nach dem Ende der Wahl veröffentlicht. Namen, E-Mail-Adresse und
+| Inhalt der Stimmabgabe aller Abstimmenden werden im Ergebnis genannt.
+| Mit Rücksicht auf das deutsche Datenschutzrecht ist daher die
+| gesonderte Zustimmung zur Speicherung und Veröffentlichung der
+| abgegebenen Stimme entsprechend Hinweis im Wahlschein nötig.
+| 
+| WAHLSCHEIN fuer Einrichtung von [Gruppenname]
+| 
+| Dein Realname, falls nicht im FROM-Header:
+| 
+| Wenn du keinen Real-Namen angibst, wird deine Stimme fuer
+| ungueltig erklaert werden.
+| 
+| Nr   [Deine Stimme]  Gruppe/Abstimmungsgegenstand
+| ========================================================================
+| #1   [            ]  Einrichtung von [Gruppenname]
+| 
+| Zur Verarbeitung des Wahlscheines und insbesondere der
+| Veroeffentlichung des Ergebnisses ist deine Zustimmung zur Speicherung,
+| Auswertung und Veroeffentlichung deiner Stimmdaten (Name und
+| E-Mail-Adresse in Verbindung mit dem Stimmverhalten) im Rahmen dieses
+| Verfahrens erforderlich. Wenn du im Feld unterhalb dieses Absatzes "JA"
+| eintraegst, erklaerst du dich damit einverstanden. In allen anderen
+| Faellen wird der Wahlschein mit Ruecksicht auf das deutsche
+| Bundesdatenschutzgesetz verworfen und nicht gewertet.
+| 
+| #a   [            ]  Datenschutzklausel - Zustimmung: Ich bin mit der
+|                      Verarbeitung meiner Daten wie oben beschrieben
+|                      einverstanden
+| 
+| =-=-=-=-=-=-=-=- Alles nach dieser Zeile bitte loeschen =-=-=-=-=-=-=-=-
+
+Es empfiehlt sich, im Wahlschein eine Möglichkeit vorzusehen, den
+tatsächlichen Namen anzugeben, da möglicherweise im E-Mail-Programm
+ein Pseudonym konfiguriert ist.  Der Wahlschein im obigen Beispiel ist
+durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).
+
+Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
+an die Moderation von de.admin.news.announce einzureichen. Auch hier
+gehört die Liste der Gruppen dazu, in denen der RfD veröffentlicht
+werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
+kann bereits einschließlich des Headers (mit Absender,
+Betreff, Gruppenliste etc.), bspw. als angehängte Textdatei,
+übermittelt werden.
+
+Die Veröffentlichung des CfVs wird üblicherweise länger dauern als bei
+den RfD, weil der Abstimmungsaufruf durch die Moderation von
+de.admin.news.announce nach dem 4-Augen-Prinzip überprüft wird. Den
+zutreffenden Endtermin der Abstimmung, der sich aus dem Zeitpunkt der
+Veröffentlichung ergibt, setzt die Moderation dann selbst ein.
+
+4.3. Abstimmungsphase
+---------------------
+
+Während der drei- oder vierwöchigen Abstimmungsphase muss der
+Abstimmungsaccount durchgehend erreichbar sein. Jede abgegebene Stimme
+sollte - nach Möglichkeit einigermaßen zeitnah, am besten
+automatisiert - per E-Mail bestätigt werden; in dieser Bestätigung
+sollte angegeben sein, welche Stimme(n) und welcher Name sowie welche
+Mailadresse für den Abstimmenden registriert wurden. Für Zwecke der
+Abstimmung ist die Adresse im From: der E-Mail zu erfassen; an diese
+sollte auch die Bestätigung versandt werden, um sicherzustellen, dass
+diese Stimme auch tatsächlich vom angegebenen Absender stammte (und
+die Abstimmadresse replyfähig ist, d.h. E-Mail dort empfangen werden
+kann). Außerdem sollte in der Bestätigung angegeben sein, wie eine
+Stimme nachträglich geändert oder komplett zurückgezogen werden kann
+(wenn bspw. eine E-Mail-Adresse verwendet wurde, die nicht im Usenet
+veröffentlicht werden soll.)
+
+In der Mitte der Abstimmungsphase ist es üblich, einen 2. CfV zu
+veröffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
+Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die
+Stimmabgaben!) enthält; dabei kann auch bereits angegeben werden, ob
+Stimmen voraussichtlich als ungültig gewertet werden.
+
+Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
+endet die Abstimmung. Verspätete Stimmen werden nicht mehr gezählt.
+
+4.4. Auswertung und Ergebnis der Abstimmung
+-------------------------------------------
+
+Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgezählt.
+
+Dabei werden zunächst die JA- und NEIN-Stimmen sowie Enthaltungen
+gezählt. Wenn eine Person mehrere Stimmen abgegeben hat, gilt die
+zuletzt abgegebene Stimme. Bei Unklarheiten hinsichtlich des Inhalts
+der Stimmabgabe oder des Namens oder der Mailadresse sollte mit dem
+Abstimmenden Rücksprache gehalten werden. Das gleiche gilt, wenn
+mehrere Stimmen offenbar von derselben Person stammen (gleicher Name,
+unterschiedliche Mailadresse oder umgekehrt), um festzustellen, ob nur
+die letzte Stimme zu werten ist oder es sich doch um verschiedene
+Personen handelt.
+
+Stimmen, die nicht eindeutig sind, oder die in anderer Weise nicht den
+Einrichtungsregeln genügen (Angabe eines falschen oder nicht
+vollständigen Namens, nicht replyfähige Abstimmadresse), dürfen nicht
+gewertet werden. Der Votetaker sollte auch die Möglichkeit von
+Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
+Identitäten, Weitergabe des Wahlscheins außerhalb der Gruppen, in
+denen er veröffentlicht wurde, Beeinflussung der Abstimmung durch
+"Campaigning") im Auge behalten und entsprechende Überprüfungen
+vornehmen. Unklarheiten sollten mit den betroffenen
+Abstimmungsteilnehmern geklärt werden. Im Einzelfall kann auch die
+Meinung der Moderation zu einer umstrittenen Frage eingeholt werden;
+es empfiehlt sich, zumindest die Entscheidungen der Moderation aus
+vergangenen Jahren zu früheren Zweifelsfällen zu Rate zu ziehen.
+
+Bei der Auswertung sollte der Votetaker im eigenen Interesse die
+datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
+er unterliegt, berücksichtigen. Dies gilt insbesondere, sofern zur
+Speicherung, Verarbeitung und vor allem Veröffentlichung der
+personenbezogenen Daten der Abstimmungsteilnehmer ausdrückliche
+Einwilligungserklärungen erforderlich sind.
+
+Danach ist eine Ergebnisveröffentlichung ("Result") vorzubereiten.
+Üblich ist es, die Gesamtzahl der gültigen Stimmen und sodann für
+jeden Abstimmungspunkt die JA- und NEIN-Stimmen sowie die Enthaltungen
+und ungültigen Stimmabgaben zu nennen. Angenommen ist der Vorschlag,
+wenn mindestens 60 JA-Stimmen eingegangen sind und die Anzahl der JA-
+Stimmen mindestens doppelt so groß ist wie die Anzahl der NEIN-Stimmen
+(2/3-Mehrheit).
+
+Zwingend ist zudem die Veröffentlichung einer Liste aller Abstimmenden
+mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
+ungültige Stimmen sind anzugeben, bei letzteren unter Angabe einer
+stichwortartigen Begründung für die Nichtwertung. Dies ermöglicht es
+allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.
+
+In besonderen Fällen kann die Veröffentlichung von Name und/oder
+Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dürfte
+das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
+in denen aus bestimmten Gründen die Verwendung von Pseudonymen
+akzeptiert wird.
+
+5. Verfahrensabschluss und Umsetzung
+====================================
+
+Mit der Veröffentlichung des Results durch die Moderation von
+de.admin.news.announce beginnt eine einwöchige Einspruchsfrist, in der
+jeder Interessierte Einspruch mit der Begründung einlegen kann, dass
+bei der Durchführung der Abstimmung schwerwiegende Unregelmäßigkeiten
+gab. Das können bspw. technische Probleme mit der Abstimmadresse sein,
+die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
+oder einer der bereits unter 4.4. angerissenen Manipulationsversuche.
+
+Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
+Abstimmung bestandskräftig; die Moderation von de.admin.news.announce
+wird dann die entsprechenden digital signierten Steuernachrichten
+versenden, die üblicherweise die automatische Einrichtung der neuen
+Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* führen, und
+die kanonische List der in de.* existierenden Newsgroups entsprechend
+ergänzen.
+
+Ansonsten wird die Moderation über eingegangene Einsprüche entscheiden
+und das Ergebnis der Abstimmung entweder entsprechend anpassen oder
+schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das
+veröffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
+gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
+keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
+der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
+wenn über den Einspruch abschließend entschieden ist.
+
+Das Einrichtungsverfahren ist damit beendet.
+
+6. Quellen
+==========
+
+Alle in diesen Erläuterungen genannten Quellen sind hier noch einmal
+zusammengefasst und um weitere Hinweise ergänzt.
+
+6.1. Grundlegende Informationen
+-------------------------------
+
+Folgende Texte sollten einem Proponenten unbedingt bekannt sein:
+
++ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
+| 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
+
++ Missverstaendnisse in de.admin.news.groups
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
+| 
+| Archive-name: de-admin/dang-faq
+| Posting-frequency: weekly
+| Last-modified: 2009-01-24
+| URL: http://www.kirchwitz.de/~amk/dai/dang-faq
+
++ Die Newsgruppen der de-Hierarchie (Gruppenliste)
+| From: Daniel Roth <25.8@bluemail.ch>
+| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2011-03-07> Die Newsgruppen der de-Hierarchie
+| 
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| Last-modified: 2011-03-07
+| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
+
+6.2. Weiterführende Hinweise
+----------------------------
+
+Folgende Texte sind allgemein oder für spezielle Fragen hilfreich oder
+von Interesse:
+
++ Moderationskonzept der derzeitigen Moderation von d.a.n.a
+| From: moderator@dana.de (Moderation von de.admin.news.announce)
+| Newsgroups: de.admin.news.announce,de.admin.news.misc
+| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
+  <http://dana.de/modkonzept.html>
+
++ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
+| From: bernd@tenuki.de (Bernd Gramlich)
+| Newsgroups: de.admin.infos
+| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
+| 
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Last-modified: 2004-12-06
+| URL: http://www.tmt.de/~gramlich/dan-glossar.html
+| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
+
++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
+  <http://th-h.de/infos/usenet/newgroup.php#vorschlag>
+
++ Erste Schritte zur Einrichtung neuer Gruppen
+  <http://www.babylonsounds.com/usenet/rfd_howto.html>
+
++ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+| From: faq@wortrei.ch (Adrian Suter)
+| Newsgroups: de.admin.news.regeln,de.admin.infos
+| Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+| 
+| Archive-name: de-admin/entscheidung
+| Posting-frequency: weekly
+| Last-modified: 2003-12-31
+| URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
+| URL: http://www.kirchwitz.de/~amk/dai/entscheidung
+
++ Regeln fuer Newsgruppennamen
+| From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
+| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
+| Date: 2000/07/18
+| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
+  <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
+
++ GVV-FAQ
+| From: Thomas Hochstein <gvv@gvv.th-h.de>
+| Newsgroups: de.admin.infos,de.admin.news.groups
+| Subject: <2011-02-19> GVV-FAQ
+| 
+| Archive-name: de-admin/gvv-faq
+| Posting-frequency: weekly
+| Last-modified: 2011-02-19
+| URL: http://gvv.th-h.de/faq.php
+| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq
+
++ Filtermaßnahmen bei der Durchführung von Abstimmungen
+| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
+| Organization: Moderation von de.admin.news.announce
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln
+| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
+| Date: Sat, 12 Mar 2011 23:15:00 +0100
+| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
+
++ Unknown: NetNews Moderator's Handbook (1994, engl.)
+  <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+
++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
+  <http://pages.swcp.com/~dmckeon/mod-faq.html>
+
++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
+  <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+
++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
+  <http://www.big-8.org/wiki/Moderated_Newsgroups>
+
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+  <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
+
++ Informationen über de.alt.test.moderated
+| From: Thomas Hochstein <thh@inter.net>
+| Newsgroups: de.alt.test.moderated
+| Subject: Info: de.alt.test.moderated <2010-11-01>
+| 
+| Last-modified: 2010-11-01 
+| Posting-frequency: monthly  
+
+6.3. Webseiten
+--------------
+
+Folgende Webseiten sollten bekannt sein oder können bei der Durchführung des
+Einrichtungsverfahrens helfen:
+
++ Webseite der Moderation von de.admin.news.announce
+  <http://www.dana.de/status.html>
+
++ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
+  wöchentlich veröffentlicht in de.admin.news.announce
+  <http://www.dana.de/status.html>
+
++ RfD-Generator
+  <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
+
++ Abstimmungssoftware UseVote
+  <http://www.usevote.de>
+
+7. Maintainer und Kontakt
+=========================
+
+7.1. Derzeitige Maintainer
+--------------------------
+
+Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
+                       Michael Ottenbruch <dana-manual@ottenbruch.net>
+
+Das dana-Manual wurde im März/April 2011 vollständig überarbeitet und
+neu gefasst.
+
+Weitere Änderungen und Ergänzungen nehmen die Maintainer gerne
+entgegen. Vorschläge können per E-Mail an <dana-manual@usenet.th-h.de>
+gerichtet werden. Im Falle einer öffentlichen Diskussion solcher
+Vorschläge ist ein Hinweis an die Maintainer hilfreich.
+
+Das dana-Manual ist auch in einem Git-Repository unter
+<http://code.th-h.de/?p=faqs/dana-manual.git> verfügbar und kann über
+die Weboberfläche eingesehen oder via "git clone" ausgecheckt werden.
+Bei Änderungsvorschlägen sind Git-Patches am einfachsten zu
+verarbeiten; natürlich nehmen die Maintainer aber auch jede andere
+Form von Anregungen entgegen.
+
+7.2. Frühere Fassungen
+----------------------
+
+Maintainer bis 2010: Thomas Roessler, Dirk Nimmich
+
+Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
+haben außerdem beigetragen:
+
+- Lutz Donnerhacke
+- Kristian Köhntopp
+- Rolf Krahl
+- Martin Recke
+- Heiko Schlichting
+- Adrian Suter
+- Hans-Christoph Wirth
+
+Herzlichen Dank!
This page took 0.036169 seconds and 4 git commands to generate.