Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
-Version: 2.0.0
-Last-modified: 2010-03-15
+Version: 2.2.3
+Last-modified: 2017-07-29
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
+URL: http://th-h.de/archives/faqs/dana-manual.txt
- Erläuterungen zur Einrichtung neuer Gruppen in de.*
+ Erläuterungen zur Einrichtung neuer Gruppen in de.*
===================================================
-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 Danksagungen
+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. Sonderfall: CfV mit persönlichem Wahlschein
+ 4.4. Abstimmungsphase
+ 4.5. Auswertung und Ergebnis der Abstimmung
+
+5. Verfahrensabschluss und Umsetzung
+
+6. Sonderfall: Vereinfachtes Verfahren (VV)
+
+7. Löschungen, Umbenennungen, Status- und Regeländerungen u.ä.
+ 7.1. Gruppenlöschungen
+ 7.2. Umbenennungen
+ 7.3. Änderungen von Charta und/oder Kurzbeschreibung
+ 7.4. Statusänderungen
+ 7.5. Regeländerungen und Personenwahlen
+
+8. Quellen
+ 8.1. Grundlegende Informationen
+ 8.2. Weiterführende Hinweise
+ 8.3. Webseiten
+
+9. Maintainer und Kontakt
+ 9.1. Derzeitige Maintainer
+ 9.2. Frühere Fassungen
======================================================================
-1. Einleitung
+0. Einleitung
+=============
-1.1. Adressatenkreis
+0.1. Zielgruppe und Inhalt
+--------------------------
Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
-wollen. Er versucht, einen Teil der gerade für Neulinge auf diesem
-Gebiet häufig frustrierenden Standardargumentation in
-de.admin.news.groups vorwegzunehmen und die in den "REGELN FÜR DIE
-EINRICHTUNG UND ENTFERNUNG VON USENET-GRUPPEN" [1] niedergelegten Regeln
-zur Einrichtung neuer Gruppen zu erläutern.
-
- [1] Veröffentlich in de.admin.infos:
-| From: 3.14@piology.org (Boris 'pi' Piwinger)
-| Newsgroups: de.admin.infos,de.alt.admin
-| Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
-|
-| Archive-name: de-admin/einrichtung
-| Posting-frequency: weekly
-| Last-modified: 2005-08-06
-| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+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: <2012-01-09> Einrichtung von Usenet-Gruppen in "de.*"
+|
+| Archive-name: de-admin/einrichtung
+| Posting-frequency: weekly
+| Last-modified: 2012-01-09
+| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+
+(Eine Liste aller in diesen Erläuterungen genannten Quellen findet
+sich noch einmal in Abschnitt 8.)
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
+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.
-
-1.2. Was ist ein RfD?
-
-Ein RfD (kurz für "Request for Discussion") ist der formale Aufruf zur
-Diskussion, der am Anfang jedes Verfahrens zur Einrichtung,
-Umbenennung etc. einer Gruppe in de.* steht. Er wird in
-de.admin.news.announce veröffentlicht und dient als Grundlage der
-nachfolgenden Diskussion in de.admin.news.groups, während der er auf
-inhaltliche Qualität und Akzeptanz abgeklopft und verfeinert wird. Am
-Ende dieser Diskussion steht üblicherweise der Aufruf zu einer
-Abstimmung ("Call for Votes" oder kurz "CfV" genannt), in der die
-Akzeptanz des Vorschlags festgestellt wird.
-
-Vom Ausgang dieser Abstimmung hängt die Annahme des Vorschlags ab.
-Nach den Regeln bedarf es zur Annahme einer Gruppe einer
-Zweidrittelmehrheit.
-
-----------------------------------------------------------------------
-
-2. Vor dem RfD
-
-Bevor man mit der Arbeit an einem RfD beginnt, sollte man sich selbst
-immer die Frage stellen, ob die gewünschte Änderung wirklich notwendi
-ist. Bei der Neueinrichtung einer Gruppe sollte man insbesondere auf
-die folgenden Punkte achten:
-
-1. Existiert bereits eine deutschsprachige Gruppe zum Thema? Es ist
- nicht sinnvoll, eine zweite Gruppe zur Diskussion ein und desselben
- Themas einzurichten; ein entsprechender Vorschlag würde
- zwangsläufig scheitern. Existiert andererseits eine Gruppe, in der
- das gewünschte Thema diskutiert wird, ist diese Gruppe aber
- überfüllt, so ist es unter Umständen sinnvoll, diese Gruppe in
- mehrere Gruppen aufzuspalten.
-
-2. Besteht im Netz Interesse am Thema? Öffentliche Selbstgespräche
- sind auf Dauer ermüdend. Im eigenen Interesse sollte man zunächst
- versuchen festzustellen, ob das gewünschte Thema überhaupt im Netz
- diskutiert wird. Gibt es in verschiedenen Gruppen wiederkehrende
- Diskussionen, die sich auf das gewünschte Thema beziehen? Gibt es
- Mailinglisten, die sich mit dem Thema auseinandersetzen?
-
-3. Existiert schon ein Vorschlag? Es ist wenig sinnvoll, eine weitere
- Diskussion zu beginnen, wenn die Einrichtung einer Gruppe zum
- gewünschten Thema bereits im Gespräch ist. Anstatt einen formellen
- Vorschlag einzureichen, sollte man sich in de.admin.news.groups
- aktiv an der laufenden Diskussion beteiligen. In der Gruppe
- de.admin.news.announce wird regelmäßig der Status der laufenden
- Verfahren veröffentlicht; die entsprechende Übersicht steht auch im
- World Wide Web unter <http://www.dana.de/status.html> zum Abruf
- bereit.
-
-4. Gab es kürzlich einen ähnlichen Vorschlag? Viele regelmäßige Leser
- von de.admin.news.groups reagieren mit Unwillen, wenn Vorschläge,
- über die gerade erst in epischer Breite diskutiert und abgestimmt
- wurde, wieder vorgebracht werden. Es wird allgemein empfohlen, vor
- der Wiedervorlage eines abgelehnten Vorschlages eine Denkpause von
- mindestens sechs Monaten einzulegen.
-
-Ist man nach der Überprüfung dieser Punkte der Ansicht, daß eine neue
-Gruppe im allgemeinen Interesse liegt, sollte man sich nach
-Verbündeten umsehen: Es schadet nicht, wenn ein Vorschlag während der
-Diskussion von einer ganzen Reihe von Leuten, die an dem
-vorgeschlagenen Thema Interesse haben und später in der Gruppe posten
-würden, unterstützt wird.
-
-----------------------------------------------------------------------
-
-3. Formulierung eines RfD
-
-3.1. Aufbau
-
-Ein RfD für die Neueinrichtung einer Gruppe besteht aus einem
-Namensvorschlag für die Gruppe, dem Status der Gruppe (moderiert oder
-unmoderiert), einer zugehörigen Kurzbeschreibung und einer Charta. Als
-Grundlage für die Diskussion sollte ferner der Hintergrund des
-Vorschlags erläutert werden. In dieser Erläuterung sollte man
-insbesondere auf die oben genannten Punkte eingehen; andernfalls muß
-man damit rechnen, daß sie als "Standardfragen" in der Diskussion
-wieder auftauchen.
-
-Ein RfD sollte üblicherweise nur einen einzelnen Gruppenvorschlag
-behandeln - es verwirrt nur, wenn eine Gruppe über das
-Fortpflanzungsverhalten der Pflastersteine unter Berücksichtigung des
-besonderen Einflusses des Sonnenlichts im gleichen Thread diskutiert
-wird wie eine Gruppe, die dem Diskurs über die gesellschaftlichen
-Auswirkungen des Fernsehens dient. Eine Ausnahme von dieser Regel
-stellt die schon oben angesprochene Aufspaltung von Gruppen dar: Hier
-sollte man Sammel-RfDs und -CfVs veranstalten. Eine Sammelabstimmung
-ist so zu verfassen, daß jede Entscheidung auch einzeln zur Abstimmung
-kommen könnte. Eine Ausnahme gibt es bei der Aufteilung einer Gruppe:
-Die Umbenennung einer Gruppe in Gruppe.misc bei Annahme mindestens
-einer Untergruppe kann automatisch erfolgen.
-
-
-3.2. Wahl des Gruppennamens
-
-Der Name besteht aus mehreren durch Punkte getrennten Segmenten. Die
-einzelnen Segmente dürfen nicht länger als 30 Zeichen werden und
-müssen mindestens je einen Buchstaben enthalten. Zu beachten ist
-dabei, daß sich unterschiedliche Segmentnamen auf gleicher Ebene schon
-vor dem 15. Zeichen unterscheiden müssen. Erlaubte Zeichen innerhalb
-eines Segments sind die Kleinbuchstaben (a-z), die arabischen Ziffern
-(0-9) sowie das Plus- (+) und das Minus-Zeichen (-).
-
-Der Name sollte so aussagekräftig wie möglich sein und sich dabei in
-die bestehende Namenshierarchie einpassen:
-
- de.alt
- ist eine Unterhierarchie, in der eigene Regeln gelten. Die
- Einrichtung von Gruppen in dieser Unterhierarchie wird hier
- nicht behandelt.
-
- de.admin
- beschäftigt sich mit der administrativen Seite des Usenet, also
- im wesentlichen mit dem Mail- und Newsaustausch im Netz und der
- Fortentwicklung der de-Newsgroups.
-
- de.comm
- dient der Diskussion über Kommunikation und
- Kommunikationstechnik. Diese Unterhierarchie hat eine noch
- weiter differenzierte Struktur: de.comm.anbieter.* ist Themen
- rund um Sprachtelekommunikationsanbietern zugedacht, während
- de.comm.provider.* die Anbieter von Internet und
- Internetdiensten meint; de.comm.geraete.* dient der Diskussion
- über die zur Kommunikation benötigten Geräte, de.comm.technik.*
- der über die dahinterliegende Technik; de.comm.infosystems.*
- behandelt Informationssysteme wie das World Wide Web (WWW),
- WAIS oder Hyper-G; de.comm.internet.* ist mit einigen Aspekten
- des Internets befaßt; de.comm.protocols.* beschäftigt sich mit
- Kommunikationsprotokollen und de.comm.software.* mit
- Kommunikationssoftware.
-
- de.comp
- dreht sich um Computer und alles, was damit zu tun hat. Auch
- diese Unterhierarchie ist weitergehend gegliedert: In
- de.comp.os.* wird über Betriebssysteme gesprochen, Hardware
- diskutiert man in de.comp.sys.* (Komplettsysteme) bzw.
- de.comp.hardware.* (Einzelteile), und Programmiersprachen als
- solche werden in de.comp.lang.* debattiert. Daneben gibt es
- noch de.comp.datenbanken.* für Datenbankmanagementsysteme,
- de.comp.office-pakete.* für integrierte Büroanwendungen und
- de.comp.text.* zum Diskutieren über Textformate und
- Texterzeuger.
-
- de.markt
- ist der Kleinanzeigenbereich des deutschsprachigen Usenet: Hier
- werden nicht-kommerzielle Angebote und Gesuche ausgetauscht.
-
- de.org
- dient verschiedenen "Organisationen" als Diskussionsforum. In
- de.admin.news.groups ist allerdings die Auffassung recht weit
- verbreitet, daß neue Gruppen nach Möglichkeit in
- themenspezifischen Unterhierarchien eingerichtet werden sollten
- (wie beispielsweise de.org.politik.spd).
-
- de.rec
- beschäftigt sich mit Freizeitaktivitäten aller Art.
- Unterhierarchien sind de.rec.spiele (Spiele aller Art),
- de.rec.music (Musik), de.rec.sport (Sport), de.rec.sf (Science
- Fiction), de.rec.tiere (die lieben Haustiere). Auch hier
- vertreten einige Teilnehmer von de.admin.news.groups die
- Ansicht, daß neue Gruppen möglichst nicht mehr direkt unter
- de.rec.* eingerichtet werden sollten, um die Übersichtlichkeit
- nicht zu gefährden.
-
- de.sci
- ist den Wissenschaften gewidmet, wobei bei der Einrichtung neuer
- Gruppen in dieser Hierarchie immer wieder Streit aufkommt, was
- denn überhaupt eine Wissenschaft sei. In der Praxis scheint
- sich bisher die Meinung durchgesetzt zu haben, daß die Lehrpläne
- von Universitäten im deutschsprachigen Raum einen ganz guten
- Überblick bieten. Direkt unterhalb von de.sci werden
- üblicherweise ganze Fachbereiche untergebracht. Einzelne
- Spezialgebiete haben dort nichts zu suchen; sie sollten als
- Untergruppen dem entsprechenden Fach zugeordnet werden
- (Beispiel: de.sci.medizin.allergie).
-
- de.soc
- handelt von gesellschaftlichen Dingen.
-
- de.talk
- dient dem gemütlichen Plausch über mehr oder minder
- Weltbewegendes. Von purem Unsinn (de.talk.bizarre) bis hin zu
- des Menschen wichtigster Nebensache (de.talk.liebesakt) ist
- alles vertreten.
-
- de.etc
- schließlich stellt das Auffangbecken dar, wenn ein Thema nicht
- in eine der anderen Unterhierarchien paßt.
-
-Man sollte außerdem versuchen, im Gruppennamen möglichst keine
-kryptischen oder mehrdeutigen Abkürzungen zu verwenden. Wenn diese gar
-nicht zu vermeiden sind, sollte man sie in der Kurzbeschreibung,
-spätestens aber in der Charta auflösen.
-
-
-3.3. Die Kurzbeschreibung
-
-Die Kurzbeschreibung (oder auch Tagline) ist zum einen in den
-regelmäßigen Postings zu finden, die den Systemadministratoren helfen,
-die Auswahl der auf ihren Systemen bereitgehaltenen Gruppen auf dem
-neuesten Stand zu halten. Andererseits zeigen viele Newsprogramme
-diese Kurzbeschreibung auch an, um den Leser an das Thema der Gruppe
-zu erinnern und somit von Fehlpostings abzuhalten. Sie ist (neben dem
-Namen) häufig das erste, was ein potentieller Leser von einer Gruppe
-zu Gesicht bekommt.
+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 kanonische 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: thh@inter.net (Thomas Hochstein)
+| Newsgroups: de.admin.infos
+| Subject: <2017-07-29> Wichtige Begriffe in de.admin.news.*
+|
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Version: 1.5.2
+| Last-modified: 2017-07-29
+| URL: http://th-h.de/archives/faqs/dan-glossar.txt
+| 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 die CfVs 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. Diese Aufgabe
+kann der Proponent übernehmen, er muss es aber nicht; 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 50 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/net/usenet/admin/newgroup/#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:
+ <https://groups.google.com/>
+
+ de.admin.news.announce bei Google Groups:
+ <https://groups.google.com/forum/#!forum/de.admin.news.announce>
+
+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.provider.* - Telefonie- und Internetanbieter sowie 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: <Datum> Die Newsgruppen der de-Hierarchie
+|
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| 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, 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 Gruppennamens 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 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;
+Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
+genannt. Diese Tagline 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 muß kurz, knapp und für jeden verständlich sein. "Diskussion
+ab: Sie muss 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.
+ü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, daß die wichtigsten
+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).
-
-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
-| ====================
-|
+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 (siehe 7.3.).
+
+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://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups>
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+ <http://web.archive.org/web/20120310123625/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 <2011-03-03>
+|
+| Last-modified: 2011-03-03
+| 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, das 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: Ralf Döblitz <faq@netzverwaltung.net>
+| Newsgroups: de.admin.news.regeln,de.admin.infos
+| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+|
+| Archive-name: de-admin/entscheidung
+| Posting-frequency: weekly
+| Last-modified: 2013-06-09
+| 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.
-|
-| Charta
-| ------
-|
-| [Charta]
-|
-|
-| Hintergrund
-| -----------
-|
-| [Begruendung]
-
-3.7.2. RfD für eine moderierte Gruppe
+oder
-| 1. Diskussionsaufruf
-| ====================
-|
-| zur Einrichtung der neuen Gruppe
-|
-| [Gruppenname] [Kurzbeschreibung] <moderator@domain.example> (Moderated)
-|
-| Diskussionen sollen in der Gruppe
-|
-| [Gruppenname] [Kurzbeschreibung]
-|
-| gefuehrt werden.
-|
-|
| Status
| ------
-|
-| Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat
-| <moderator@domain.example> und Peter Roponent
-| <proponent@domain.example> vorgeschlagen.
-|
+|
+| 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]
-|
-| 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.
-
-----------------------------------------------------------------------
+|
+| 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.
-5. Nach der Veröffentlichung
+Ü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: <2016-10-12> 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
-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
-| ==================
-|
+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 (siehe 4.2.). 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 Regelfall, 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 <thh@votetaker.de>
+| Newsgroups: de.admin.infos,de.admin.news.groups
+| Subject: <2017-05-01> GVV-FAQ
+|
+| Archive-name: de-admin/gvv-faq
+| Posting-frequency: weekly
+| Last-modified: 2017-05-01
+| URL: http://votetakers.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 einen Monat betragen. Üblicherweise wird diese Frist nicht
+ausgeschöpft, sondern stattdessen eine Abstimmungsdauer von vier
+Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
+nach der ein 2. CfV veröffentlicht werden soll, mit "zwei Wochen"
+leichter bestimmbar ist. Zum anderen ist es üblich, Abstimmungen
+um Mitternacht enden zu lassen. Daher könnten sich bei einer
+Abstimmungsdauer von einem Monat und Veröffentlichung des 1. CfV bspw.
+um 16:30 Uhr unnötige Diskussionen ergeben, ob damit nicht die
+Höchstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht)
+überschritten wird.
+
+Schließlich muss der CfV mit dem letzten RfD im wesentlichen
+übereinstimmen, wie Teil 6 der Einrichtungsregeln festhält:
+
+| Nach der Diskussionsperiode kann ein Abstimmungsaufruf -- engl.
+| "Call for Votes" oder kurz CfV -- bei der Moderation eingereicht
+| werden. Dieser muß mit dem letzten RfD im wesentlichen
+| übereinstimmen.
+
+Zweck dieser Regel ist es, zu verhindern, dass etwas anderes zur
+Abstimmung gestellt wurde als zuvor Gegenstand der Diskussion war.
+"Wesentlich" in diesem Sinne sind daher alle Eigenschaften der
+einzurichtenden Gruppe sowie die Abstimmungsmodalitäten; an diesen
+dürfen keine über die Behebung von Schreibfehlern o.ä. hinausgehenden
+Änderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
+gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor
+diskutierte. Eine Änderung der Begründung - soweit sie überhaupt im
+CfV wiederholt wird - ist hingegen regelmäßig unproblematisch.
+
+Ü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 {moderiert|unmoderiert}.
-|
+|
+| [Gruppenname] [Kurzbeschreibung]
+|
+| Status: Die Gruppe ist unmoderiert.
+|
| Charta
| ------
-| <Charta>
-|
-| Modalitäten
-| -----------
-| Sinn einer Usenet-Abstimmung ist es festzustellen, wer eine
-| vorgeschlagene Gruppe tatsächlich nutzen möchte. Uninteressierte
-| Personen zur Teilnahme an der Abstimmung aufzufordern, schadet diesem
-| Ziel. Bitte verbreite diesen CfV nicht weiter. Verweise die Leute
-| stattdessen auf den offiziellen CfV, der in de.admin.news.announce
-| gepostet wurde. Die Verbreitung von vorausgefüllten oder anderweitig
-| veränderten CfV wird allgemein als Wahlfälschung angesehen. Im
-| Zweifel wende Dich an den Wahlleiter.
-|
-| Die Stimmen müssen bis zum <Datum> eingehen. Ausschlaggebend
-| ist hierbei das *Eintreffen* der Stimme, nicht das Absendedatum!
-| Bitte benutze den Wahlschein, der am Ende dieses CfV angebracht
-| ist. Wahlberechtigt ist jede natürliche Person, die in der Lage
-| ist, E-Mail an die Abstimmungsadresse zu schicken.
-|
-| Es gelten die derzeitigen Wahlregeln, die in de.admin.infos
-| veröffentlicht sind.
-|
-| Wie gewählt wird
-| ----------------
-|
-| Trage in die Felder des Wahlscheins unten Deine Stimme (JA, NEIN
-| oder ENTHALTUNG) ein und schicke den Wahlschein dann an den
-| Vote-Account <email@adres.se> (Reply-To:-Header ist gesetzt.) Es
-| werden nur Stimmen berücksichtigt, die per Mail an diesen Account
-| gerichtet sind. Öffentliche Stimmabgaben (Postings) sind ungültige
-| Stimmen und werden nicht berücksichtigt.
-|
-|
-| Deine Entscheidung bedeutet dabei:
-|
-| JA - Ich bin für diesen Vorschlag.
-| NEIN - Ich bin gegen diesen Vorschlag.
-| ENTHALTUNG - Ich enthalte mich oder ich ziehe meine Stimme zurück
-|
-| Enthaltungen gelten nicht im Sinne einer gültig
-| abgegebenen Stimme; sie dienen vornehmlich dazu,
-| eine zuvor abgegebene Stimme zurückzuziehen.
-|
-| Der Wahlleiter wird auf Deine Stimme mit einer persönlichen
-| Bestätigung via E-Mail reagieren. Wenn Du innerhalb von ein paar
-| Tagen nichts hörst, versuche es noch einmal.
-|
-| Solltest Du Deine Meinung ändern, so wähle einfach
-| neu. Willst Du dabei Deine Stimme annullieren, so entscheide
-| ENTHALTUNG. Gehen mehrere Stimmen ein, gilt die jeweils zuletzt
-| abgeschickte (Date:-Eintrag der Mail).
-|
-| Bitte beachte, daß die Stimme Deinen echten Namen enthalten
-| muß, kein Pseudonym. Sollte Dein Newsreader den Namen nicht
-| automatisch im From:-Header eintragen, trage ihn bitte nochmal im
-| Wahlzettel ein. Andernfalls ist Deine Stimme ungültig.
-|
-| In der Mitte der Wahlperiode wird ein zweiter CfV gepostet, der
-| eine Auflistung aller Personen enthält, von denen bis zu diesem
-| Zeitpunkt eine gültige Stimme eingegangen ist.
-|
-| Die Ergebnisse der Wahl werden nach Ablauf der Wahlfrist
-| öffentlich gepostet, wobei jede einzelne Stimme, zur Kontrolle
-| für alle, aufgelistet wird. Solltest Du begründete Bedenken gegen
-| die Veröffentlichung Deines Realnamens haben, melde Dich bitte beim
-| Wahlleiter (<e-mail@ad.res.se>).
-|
-|
-| -=-=-=-=-=-= Alles vor dieser Zeile löschen =-=-=-=-=-=-
-|
-| Wahlschein fuer die {Einrichtung|Umbenennung|Entfernung} von
-| <Gruppenname>
-|
-| Dein Realname, falls nicht im From:-Header:
-|
-| Wenn Du keinen Real-Namen veröffentlicht haben willst, wende Dich
-| mit einer Begründung an <e-mail@ad.res.se>
-|
-| [Deine Stimme] Abstimmungsgegenstand
-| ----------------------------------------------------------------------
-| [ ] Einrichtung von <Gruppenname>
-|
-| -=-=-=-=-=-= Alles nach dieser Zeile löschen =-=-=-=-=-=-
-
-
-6.3. Technische Voraussetzungen für die Durchführung
-
-Für die Abstimmung selbst benötigt man einen E-Mail-Account, der die
-Wahlscheine entgegennimmt. Dieser sollte nach Möglichkeit nicht mit
-der "normalen" E-Mail-Adresse des Abstimmungsleiters identisch sein,
-damit keine Mißverständnisse auftreten oder Wahlscheine in der
-sonstigen Post verloren gehen. Wichtig ist insbesondere auch, daß der
-Account ungefiltert ist, also keine Spamfilter oder Blacklists aktiv
-sind, die ggf. dazu führen, daß legitime Abstimmungs-E-Mail nicht
-angenommen werden. Die meisten kostenlosen Angebote sind daher ebenso
-ungeeignet wie viele Standardaccounts von Webhostinganbietern.
-
-Jede abgegebene Stimme soll - nach Möglichkeit automatisch - bestätigt
-werden. Aus der Nachricht sollte außerdem hervorgehen, wie die Stimme
-gezählt wurde, damit der Absender eine falsch gezählte Stimme wieder
-ändern oder diese widerrufen kann, wenn er vor Ablauf der Wahlfrist
-seine Meinung ändert.
-
-
-6.4. Unabhängige Wahlleiter
-
-Wer sich nicht die Mühe machen will, nicht die Möglichkeiten dazu hat,
-die Wahl abzuhalten, oder der Meinung ist, die Wahl besser durch
-Unabhängige durchführen zu lassen, kann sich auch an die German
-Volunteer Votetakers (GVV) wenden. Diese führen dann die Abstimmung
-einschließlich zweitem CfV und Veröffentlichung des Ergebnisses durch.
-
-Dazu fragt man bei den GVV unter der Adresse <gvv@dana.de> an, wer
-bereit ist, den CfV zu übernehmen. Dem Freiwilligen, der sich dann
-meldet, schickt man den soweit wie möglich fertigen CfV (d. h., ohne
-die Abstimmadresse und ohne Frist für die Stimmabgabe). Der GVV wird
-die fehlenden Angaben ergänzen, den Wahlschein auf Maschinenlesbarkeit
-prüfen und sonst wahrscheinlich nichts ändern, sondern den CfV direkt
-bei der Moderation einreichen. Mit dem weiteren Ablauf hat man dann
-nichts mehr zu tun.
-
-----------------------------------------------------------------------
-
-7. Schlußbemerkungen
-
-7.1. Literatur
-
-Folgende Texte sollten dem Proponenten auf jeden Fall bekannt sein:
-
- <Datum> Einrichtung von Usenet-Gruppen in "de.*"
- Dieser Text beschreibt die Richtlinien für die Einrichtung einer
- Newsgroup in der de.*-Hierarchie, insbesondere die üblichen
- Abstimmungsmodalitäten. Er wird wöchentlich in de.admin.infos
- gepostet.
-
- <Datum> Die Newsgruppen der de.*-Hierarchie
- Hier findet sich eine Beschreibung der bereits eingerichteten
- Newsgroups in de.* (ohne de.alt.*). Das Posting findet sich
- allwöchentlich in de.newusers.infos.
-
- <Datum> Die Newsgruppen der de.alt.*-Hierarchie
- Darin sind die bestehenden Newsgruppen der de.alt-Hierarchie
- aufgeführt und beschrieben. Auch dieser Text kann der Newsgroup
- de.newusers.infos entnommen werden.
-
- <Datum> Missverstaendnisse in de.admin.news.groups
- Dieser Text beschreibt typische Argumentationen in
- de.admin.news.groups. Er wird nach de.admin.infos gepostet.
-
-
-7.2. Glossar
-
- CfV
- Call for Votes, Aufruf zur Wahl. Leitet die Abstimmung über eine
- Entscheidung ein bzw. dient zur Erinnerung an diese Abstimmung.
-
- dana
- Akronym für de.admin.news.announce
-
- GVV
- German Volunteer Votetakers, Freiwillige Abstimmungsleiter; zu
- erreichen unter der E-Mail-Adresse <gvv@dana.de>.
-
- RfD
- Request for Discussion, Aufruf zur Diskussion. Leitet die
- Diskussion um eine Entscheidung ein bzw. bringt sie wieder in
- Gang.
+|
+| [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.
+|
+| =-=-=-=-=-=-=-=- Alles vor dieser Zeile bitte loeschen =-=-=-=-=-=-=-=-
+|
+| 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. Daher
+kann - und sollte - der 1. CfV ruhig möglichst frühzeitig eingereicht
+werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
+Zeitpunkt der Veröffentlichung ergibt, setzt die Moderation dann
+selbst ein.
+
+4.3. Sonderfall: CfV mit persönlichem Wahlschein
+------------------------------------------------
+
+Ergänzend zu der üblichen Form der Abstimmung, bei der bereits der CfV
+einen Wahlschein enthält, sehen die Einrichtungsregeln in ihrem Teil
+6a auch die Möglichkeit einer Abstimmung unter Verwendung persönlicher
+Wahlscheine vor.
+
+Diese 1998/1999 eingeführte Verfahrensweise [5] soll die Manipulation
+von Abstimmungen erschweren, indem sie das normale
+Abstimmungsverfahren durch ein Zwei-Schritt-Verfahren ersetzt: der
+Abstimmungswillige muss zunächst einen persönlichen Wahlschein beim
+Votetaker anfordern, der ein kodiertes, eindeutig dem
+Abstimmungswilligen zuzuordnendes Merkmal erhält und sodann diesen
+persönlichen - und an seine E-Mail-Adresse gekoppelten - Wahlschein
+ausgefüllt zurücksenden. Andere Wahlscheine oder die Verwendung einer
+anderen E-Mail-Adresse werden nicht akzeptiert.
+
+Diese Vorgehensweise soll u.a. verhindern, dass vorausgefüllte
+Wahlscheine verbreitet werden, die durch beliebige Netzteilnehmer ohne
+Kenntnis des Verfahrens (oder gar ohne Kenntnis von der Existenz des
+Usenets) dann an die Abstimmungsadresse versandt werden. Als
+Nebeneffekt wird damit die zur selben Zeit festgeschriebene Forderung,
+dass die zur Abstimmung verwendete Adresse gültig sein, d.h. E-Mails
+entgegennehmen muss, überprüfbar - denn nur wer eine gültige Adresse
+als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
+mit dieser Adresse - kann er an der Abstimmung teilnehmen.
+
+Da allerdings weiterhin andere Manipulationsmöglichkeiten verbleiben
+und der Aufwand für die Durchführung dieses Verfahrens vergleichsweise
+hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
+durchgeführt.
+
+In der Abstimmungssoftware Usevote (siehe 4.1.) ist die Durchführung
+solcher Verfahren implementiert.
+
+[5] Der Vorschlag und die entsprechende Begründung lassen sich im
+ Archiv von Google Groups unter
+ <http://groups.google.com/group/de.admin.news.announce/browse_frm/thread/fd056d977d6a5240>
+ nachlesen.
+
+4.4. Abstimmungsphase
+---------------------
+
+Während der drei- oder vierwöchigen (maximal aber einmonatigen)
+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. Weil auch der 2.
+CfV im Rahmen der üblichen Bearbeitungszeiten regelmäßig nicht sofort,
+sondern erst nach einigen (Stunden oder) Tagen veröffentlicht werden
+wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der
+Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei
+Tage vor dem geplanten Veröffentlichungszeitraum einzureichen.
+
+Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
+endet die Abstimmung. Verspätete Stimmen werden nicht mehr gezählt.
+
+4.5. 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. Diese
+sind, soweit sie eine Bedeutung über den konkret entschiedenen
+Einzelfall hinaus haben und nicht später revidiert wurden, unter
+<http://www.dana.de/archiv.html> auch im Web veröffentlicht.
+
+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 Anzahl der JA- und NEIN-Stimmen, der
+Enthaltungen und ungültigen Stimmabgaben zu nennen. Angenommen ist der
+Vorschlag, wenn mindestens 50 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.5. 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. Sonderfall: Vereinfachtes Verfahren (VV)
+===========================================
+
+Nicht jeder marginale Änderungsvorschlag muss zwingend das vorstehend
+geschilderte umfangreiche Verfahren nach sich ziehen. Für kleinere
+Änderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog.
+"Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und
+Abstimmungsphase zugunsten einer Widerspruchslösung entfallen.
+
+Bei einem VV wird der entsprechende Änderungsvorschlag, der dieselben
+Anforderungen wie ein RfD erfüllen muss (siehe 3.1.), zur
+Veröffentlichung in de.admin.news.announce bei <moderator@dana.de>
+eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darüber
+hinaus ausdrücklich darauf hinweisen, dass die vorgeschlagene Änderung
+ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
+gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
+muss, per E-Mail an die Moderation von de.admin.news.announce (deren
+E-Mail-Adresse anzugeben ist) widersprochen wird.
+
+Nach Abschluss der Widerspruchsfrist stellt die Moderation von
+de.admin.news.announce entweder fest, dass kein Widerspruch
+eingegangen ist und der Vorschlag angenommen wurde, oder
+veröffentlicht Namen und E-Mail-Adresse der Widerspruchsführer. Im
+letzteren Fall ist das VV gescheitert und kann durch den Proponenten
+als normales Verfahren mit dem 1. RfD fortgeführt oder aufgegeben
+werden.
+Wenn der Änderungsvorschlag angenommen wurde, wird er durch die
+Moderation von de.admin.news.announce umgesetzt (siehe 5.).
+
+7. Löschungen, Umbenennungen, Status- und Regeländerungen u.ä.
+==============================================================
+
+Bereits die Einleitung ("Übersicht") der Einrichtungsregeln weist
+darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von
+Usenet-Gruppen in de.*" trägt und sich die Ausführungen auch (im
+wesentlichen nur) mit der Einrichtung neuer Gruppen beschäftigen, sie
+aber für alle Änderungen am Gruppenbestand analog gelten und auch für
+andere Entscheidungen - und Personenwahlen - entsprechend angewendet
+werden können (und regelmäßig auch angewendet werden):
+
+| Diese Spielregeln gelten für die Einrichtung oder Entfernung einer
+| Gruppe sowie Änderung ihrer Attribute. Die Attribute einer Gruppe
+| sind: Gruppenname, Kurzbeschreibung, Charta und Status (moderiert/
+| unmoderiert) sowie bei moderierten Gruppen die Moderatoren.
+|
+| Es spricht nichts dagegen, auch andere hierarchieweit wirkende
+| Entscheidungen nach analogen, nur im Detail abweichenden, Regeln
+| herbeizuführen.
+|
+| Zur Moderatoren-Nachfolge in bestehenden moderierten Gruppen sind
+| diese Spielregeln weder zwingend noch die einzigen Regeln.
+
+Die Einrichtungsregeln stammen im Ursprung aus der Zeit der Gründung
+und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
+mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
+Gruppen beschäftigen. Je größer die Hierarchie wurde (und je stärker
+die Nutzerzahlen wieder zurückgingen), desto häufiger wurden dann
+Änderungs- und Löschungsverfahren, aber auch Regeländerungen.
+
+Grundsätzlich ist die Vorgehensweise in diesen Fällen den
+Einrichtungsverfahren vergleichbar, insbesondere die
+Begründungsansätze sind aber freilich andere.
+
+7.1. Gruppenlöschungen
+----------------------
+
+Gruppenlöschungen sind das Gegenteil von Neueinrichtungen und kommen
+dementsprechend auch aus den umgekehrten Gründen wie diese in
+Betracht. Sie werden zumeist dann vorgeschlagen, wenn eine Gruppe
+nicht mehr oder praktisch nicht mehr genutzt wird und dementsprechend
+leersteht. So wie eine neue Gruppe oft durch Aufspaltung einer
+bestehenden, sehr rege genutzten Gruppe in mehrere Untergruppen
+entsteht, sollen so umgekehrt die fast leeren Untergruppen wieder zu
+einer gemeinsamen Obergruppe zusammengeführt werden. Ziel ist es
+letztlich bei Einrichtungen wie bei Löschungen von Gruppen, eine
+thematische Aufteilung zu erreichen, die gerade so fein ist, dass
+Gruppen zu intensiv diskutierten Themen nicht überfüllt sind und
+Gruppen zu selten diskutierten Themen nicht leer stehen.
+
+* Insofern wird die Begründung eines Löschungsvorschlags in der Regel
+ primär auf eine statistische Auswertung über einen längeren Zeitraum
+ (mindestens 12 Monate, im Zweifel aber auch länger) gestützt, um zu
+ belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
+ solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
+ sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
+ der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
+ Bereich abrutscht, können niedrige Nutzungszahlen nur ein Hinweis
+ auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
+ oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
+ wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
+ Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
+ gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
+ selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
+ Anlässe reagiert und die Gruppe wieder mit Leben füllt. Das spricht
+ eher gegen eine Löschung der Gruppe.
+
+ [6] <http://usenet.dex.de/>
+
+* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
+ Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
+ zur Löschung vorgeschlagenen Gruppe zukünftig diskutiert werden
+ sollen. Wenn die Gruppe in einem größeren thematischen Zusammenhang
+ steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
+ benennen, was dann wiederum für eine niedrigere Schwelle zur
+ Löschung spricht, denn so werden einzelne, mittlerweile weniger
+ intensiv diskutierte Unterbereiche eines größeren Themas wieder
+ thematisch zusammengefasst.
+
+ Ein Beispiel dafür wäre die Teilhierarchie
+ de.comp.office-pakete.ms-office.*, die aus den Gruppen
+
+ - de.comp.office-pakete.ms-office.excel
+ - de.comp.office-pakete.ms-office.outlook
+ - de.comp.office-pakete.ms-office.powerpoint
+ - de.comp.office-pakete.ms-office.word
+ - de.comp.office-pakete.ms-office.misc
+
+ besteht. Sollte sich herausstellen, dass zwar zu Word und Excel
+ intensiv diskutiert wird, es aber kaum Fragen zu Powerpoint gibt,
+ würde eine Löschung der Gruppe
+ de.comp.office-pakete.ms-office.powerpoint bedeuten, dass das Thema
+ "Powerpoint" nunmehr in de.comp.office-pakete.ms-office.misc diskutiert
+ werden kann, zusammen mit anderen, seltener (genutzten und) diskutierten
+ Komponenten von Microsoft Office wie bspw. OneNote.
+
+ Manche Gruppen aber fassen ein weit gespanntes Thema zusammen, für
+ das ansonsten keine vergleichbare Gruppe besteht, sondern allenfalls
+ ein bunter Strauß verschiedenster Gruppen zu einzelnen Facetten des
+ Themas; manche Gruppen sind auch die einzigen oder letzten, die sich
+ (noch) mit einem solchen Thema befassen. In solchen Fällen ist eine
+ besonders kritische Prüfung erforderlich, ob sich die Gruppe nicht
+ wieder beleben lässt, weil dann die Gefahr besteht, dass ermangels
+ Alternativen das Thema völlig aus dem Usenet verschwindet. Solche
+ Gruppen sollten daher nur zur Löschung vorgeschlagen werden, wenn
+ das Thema letztlich bereits aus dem Usenet verschwunden *ist*.
+
+* Wenn die letzte Gruppe einer Teilhierarchie gelöscht wird, stellt
+ sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
+ umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
+ Teilhierarchie").
+
+ So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
+ Gruppen
+
+ - de.comm.protocols.tcp-ip
+ - de.comm.protocols.misc
+
+ Würde man die Gruppe de.comm.protocols.tcp-ip löschen, könnte man
+ die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
+ de.comm.protocols umbenennen, um so den Namen zu verkürzen und die
+ Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
+ spricht, dass Umbenennungen technisch nicht möglich sind, sondern
+ nur durch eine Löschung der bestehenden Gruppe und die
+ Neueinrichtung der Gruppe mit dem geänderten Namen umgesetzt werden
+ können (siehe 7.2.).
+
+7.2. Umbenennungen
+------------------
+
+Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
+mit anderen Änderungen am Gruppenbestand. Dass eine Gruppe ohne
+weiteren Anlass bloß an eine andere Stelle im Hierarchiebaum (siehe
+2.1.1.) verschoben wird, ist sehr selten.
+
+Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
+nicht möglich ist. Was man organisatorisch als "Umbenennung"
+bezeichnet, ist technisch schlicht die (zusätzliche) Einrichtung der
+Gruppe mit dem neuen Namen, gefolgt ungefähr eine Woche später von der
+Löschung der Gruppe mit dem alten Namen. Dies führt dazu, dass alle
+bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
+zusammen verschwinden und zudem Nutzer, die nur unregelmäßig in die
+Gruppe hineinschauen, sie dann plötzlich nicht mehr finden können.
+Eine solche Umbenennung will also wohlüberlegt sein.
+
+7.3. Änderungen von Charta und/oder Kurzbeschreibung
+----------------------------------------------------
+
+Neben dem Namen können auch alle anderen Attribute einer Gruppe (für
+deren Beschreibung siehe 2.) geändert werden, namentlich die Charta
+und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
+meistens ist eine vorgeschlagene Chartaänderung die Folge einer
+Reorganisation, also der Einrichtung oder Löschung anderer Gruppen, so
+dass klarstellende Änderungen hinsichtlich des Themenbereichs einer
+bestehenden Gruppe notwendig werden oder auch die Namen der gelöschten
+oder sonstwie geänderten Newsgroups aus der Charta entfernt werden
+müssen. Manchmal ergibt sich aber der Bedarf nach einer Abgrenzung
+oder Erweiterung der Charta einer Gruppe auch so, wenn sich bspw. der
+thematische Fokus verschiebt.
+
+Eine Charta- oder Kurzbeschreibungsänderung ist dabei im wesentlichen
+kein technischer Vorgang. Geänderte Kurzbeschreibungen werden ggf.
+durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
+nicht auf Newsservern gespeichert werden und daher auch nicht im
+Newsreader angezeigt werden können (siehe 2.3.), sondern nur
+organisatorische Metainformationen darstellen, werden Chartaänderungen
+auch nur durch eine entsprechende Information per Posting in
+de.admin.news.announce und der betroffenen Gruppe "umgesetzt".
+
+7.4. Statusänderungen
+---------------------
+
+Die Umstellung einer bestehenden unmoderierten Newsgroup auf
+"moderiert" bzw. einer vormals moderierten Newsgroup auf den Status
+"unmoderiert" ist nicht unproblematisch. Auch dies hat technische
+Gründe; nicht immer erfolgen technische Umstellungen durch
+Steuernachrichten wirklich überall auf jedem Newsserver oder gar
+überall zur gleichen Zeit. Dies kann dazu führen, dass die Gruppe auf
+manchen Servern noch als moderiert geführt wird, auf anderen aber
+schon als unmoderiert (oder umgekehrt).
+
+Soll eine bisher unmoderierte Gruppe zukünftig moderiert sein, führt
+dies dazu, dass Postings über Newsserver, auf denen die Gruppe noch
+als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
+erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
+führen, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
+bisher moderierte Gruppe zukünftig unmoderiert sein soll, werden
+Newsserver, die diese Umstellung (noch) nicht vollzogen werden,
+weiterhin eingereichte Postings per E-Mail an die (nicht mehr
+bestehende) Moderation weiterleiten, so dass auch dann Beiträge
+verloren gehen.
+
+Diese technischen Probleme müssen bereits in der Diskussionsphase
+berücksichtigt werden und erfordern - in der Regel von denjenigen, die
+den Vorschlag vorbringen - zusätzlichen Aufwand, um die Situation im
+Auge zu behalten und ggf. die Betreiber von Newsservern an die
+notwendige Umstellung zu erinnern.
+
+Ansonsten gelten die unter 2.4. dargestellten zusätzlichen Erwägungen
+für die Einrichtung moderierter Gruppen entsprechend.
+
+7.5. Regeländerungen und Personenwahlen
+---------------------------------------
+
+Neben Änderungen am Gruppenbestand können - und werden - die
+Einrichtungsregeln analog auch für andere Entscheiungen (bspw. die
+Änderung der Einrichtungsregeln selbst) herangezogen.
+
+Sie gelten - teilweise modifiziert - auch für Personenwahlen, bspw.
+für die Neuwahl der Moderation von de.admin.news.announce [7] oder die
+von der amtierenden Moderation in regelmäßigen Abständen
+durchgeführten Nachwahlen [8]. In gleicher Weise wäre es auch möglich,
+jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
+Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
+einer moderierten Gruppe Mitglieder ausschließen oder neue Mitglieder
+aufnehmen und auch die Moderation komplett an andere Personen
+übergeben kann. Diese Entscheidung kann dann nur durch ein
+Neuwahlverfahren - analog der Einrichtungsregeln - übersteuert werden.
+
+[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
+ gleichfalls in de.admin.infos veröffentlicht sind:
+| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter)
+| Newsgroups: de.admin.infos,de.admin.news.misc
+| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
+|
+| Archive-name: de-admin/dana-neuwahl
+| Posting-frequency: weekly
+| Last-modified: 1998-05-18
+| URL: http://www.kirchwitz.de/~amk/dai/dana-neuwahl
+
+[8] Diese beruhen auf freiwilliger Übung der derzeit amtierenden
+ Moderation von de.admin.news.announce und sind daher (nur) in
+ deren Moderationskonzept (dort Abschnitt 4) festgehalten, das
+ regelmäßig in de.admin.news.announce veröffentlicht wird:
+| From: moderator@dana.de (Moderation von de.admin.news.announce)
+| Newsgroups: de.admin.news.announce,de.admin.news.misc
+| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation
+ und auch auf den Webseiten der Moderation unter
+ <http://dana.de/modkonzept.html> abgerufen werden kann.
+
+8. Quellen
+==========
+
+Alle in diesen Erläuterungen genannten Quellen sind hier noch einmal
+zusammengefasst und um weitere Hinweise ergänzt.
+
+8.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: <2012-01-09> Einrichtung von Usenet-Gruppen in "de.*"
+|
+| Archive-name: de-admin/einrichtung
+| Posting-frequency: weekly
+| Last-modified: 2012-01-09
+| 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: <Datum> Die Newsgruppen der de-Hierarchie
+|
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
+
+8.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: <2016-10-12> Moderationskonzept der derzeitigen Moderation
+ <http://dana.de/modkonzept.html>
+
++ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
+| From: thh@inter.net (Thomas Hochstein)
+| Newsgroups: de.admin.infos
+| Subject: <2017-07-29> Wichtige Begriffe in de.admin.news.*
+|
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Version: 1.5.2
+| Last-modified: 2017-07-29
+| URL: http://th-h.de/archives/faqs/dan-glossar.txt
+| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
+
++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
+ <http://th-h.de/net/usenet/admin/newgroup/#vorschlag>
+
++ Erste Schritte zur Einrichtung neuer Gruppen
+ <http://web.archive.org/web/20070105012315/http://usenet.babylonsounds.com/rfd_howto.html>
+
++ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+| From: Ralf Döblitz <faq@netzverwaltung.net>
+| Newsgroups: de.admin.news.regeln,de.admin.infos
+| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+|
+| Archive-name: de-admin/entscheidung
+| Posting-frequency: weekly
+| Last-modified: 2013-06-09
+| 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 <thh@votetaker.de>
+| Newsgroups: de.admin.infos,de.admin.news.groups
+| Subject: <2017-05-01> GVV-FAQ
+|
+| Archive-name: de-admin/gvv-faq
+| Posting-frequency: weekly
+| Last-modified: 2017-05-01
+| URL: http://votetakers.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://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups>
+
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+ <http://web.archive.org/web/20120310123625/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 <2011-03-03>
+|
+| Last-modified: 2011-03-03
+| Posting-frequency: monthly
+
++ Entscheidungen der Moderation von de.admin.news.announce
+ <http://www.dana.de/archiv.html>
+
+8.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/>
+
++ "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>
+
++ GVV-Statusübersicht
+ <http://votetakers.de/status.php>
+
++ Abstimmungssoftware UseVote
+ <http://www.usevote.de/>
+
++ de.* in Graphen
+ <http://usenet.dex.de/>
+
+9. Maintainer und Kontakt
+=========================
+
+9.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.3. Maintainer und Danksagungen
+Für Hinweise, Anregungen und Verbesserungsvorschläge sei insbesondere
+- Stephan Manske
+- 0liver Seyfert
+gedankt.
-Maintainer dieser FAQ: Michael Ottenbruch
- Thomas Hochstein
+9.2. Frühere Fassungen
+----------------------
-Maintainer bis 2010: Thomas Roessler, nach einem Entwurf von Dirk Nimmich
+Maintainer bis 2010: Thomas Roessler, Dirk Nimmich
-Zu diesem Text und seiner Entstehung haben beigetragen:
+Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
+haben außerdem beigetragen:
- Lutz Donnerhacke
- Kristian Köhntopp
- Rolf Krahl
-- Dirk Nimmich
- Martin Recke
-- Thomas Roessler
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth
+
+Herzlichen Dank!
+--
+Id: $Format:%t %d %ai %an$