[faqs/dana-manual.git] / dana-manual

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.4
Last-modified: (unreleased)
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.*
          ===================================================

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

======================================================================

0. Einleitung
=============

0.1. Zielgruppe und Inhalt
--------------------------

Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
lassen wollen und soll die in den "REGELN FÜR DIE EINRICHTUNG UND
ENTFERNUNG VON USENET-GRUPPEN" [1] (kurz: Einrichtungsregeln)
niedergelegten Regeln zur Einrichtung neuer Gruppen kommentieren und
erläutern. Er gibt dabei notwendig den Blick der Autoren bzw.
Maintainer auf die Verhältnisse in de(.admin.news).* und ihre
Erfahrungen wieder.

[1] Veröffentlicht in de.admin.infos:
|   From: 3.14@piology.org (Boris 'pi' Piwinger)
|   Newsgroups: de.admin.infos,de.alt.admin
|   Subject: <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.* (vgl. Anhang A zu den Einrichtungsregeln).
Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
nachfolgende, mindestens einwöchige Diskussion keinen gar zu heftigen
Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im Überblick
-------------------------------------------

Newsgroups werden nicht auf einem zentralen Server angeboten, sondern
dezentral auf vielen verschiedenen Newsservern geführt, die ihre
Beiträge jeweils untereinander austauschen. Damit das funktionieren
kann und jeder Benutzer dieselben Newsgroups zur Verfügung hat, müssen
sich die Betreiber dieser Vielzahl von Newsservern nach Möglichkeit
auf einen einheitlichen Bestand an Gruppen einigen. Das ist bei
mehreren tausend Newsservern mit manchmal wenigen, manchmal aber auch
Tausenden Benutzern durch Diskussionen im Einzelfall nicht praktikabel
möglich. Daher werden für gepflegte Newsgroups-Hierarchien wie de.*
Listen der Newsgroups geführt, die zur Hierarchie gehören; mit dieser
Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand
abgleichen.

Für de.* wird die 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 muss kurz, knapp und für jeden verständlich sein. "Diskussion
über" oder "Informationen von" sind zum Beispiel notorisch
überflüssige Formulierungen. Hingegen sollten möglichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer möglicherweise suchen werden. Da die
Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von
Newsreadern angezeigt werden), die meist auf 80 Spalten breiten
Terminals gelesen werden, ergibt sich eine Beschränkung für die Länge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt für die Kurzbeschreibung gewöhnlich eine Maximallänge
von 60 Zeichen.

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

Beispiele für Kurzbeschreibungen finden sich in dem bereits genannten
Text "Die Newsgruppen der de-Hierarchie".

2.3. Charta
-----------

Die Charta ist die Beschreibung der Newsgroup und ihres vorgesehenen
Themas schlechthin. Sie soll so kurz wie möglich und nur so
ausführlich wie nötig umreißen, worum es in der Gruppe geht, welche
Themen dort diskutiert werden sollen und welche ggf. nicht und welche
besonderen Konventionen dort - unter Abweichung von den sonstigen
Üblichkeiten im deutschsprachigen Usenet - gelten sollen.

Es ist hilfreich, für das Thema der Gruppe einige Beispiele als nicht
abschließende Aufzählung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen möglicherweise gesucht wird.
Dabei ist aber zu berücksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW veröffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfügung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl möglicherweise Name und
Kurzbeschreibung bei flüchtiger Durchsicht zu dieser Annahme führen
könnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrücklich auszuschließen. Genauso sollte innerhalb der
Charta das Diskussionsthema von anderen, themenverwandten Gruppen
abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
nicht tunlich, weil ansonsten bei jeder Umbenennung oder Löschung der
betreffenden Gruppen eine Chartaänderung nötig würde (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.

oder

| Status
| ------
|
| Die Gruppe ist moderiert.
|
| Moderatoren sind Adam Berthold <adam@berthold.example> und
| Charlotte Dominik <charlotte@dominik.example>.
|
| Die Submissionsadresse lautet <submissionen@domain.example>.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begründung
| -----------   ----------
|
| [Begründung, ggf. untergliedert]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]

Unter <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
einen "RfD-Generator" eingerichtet. Über ein Formular werden die
notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige
Fehler hin überprüft und daraus dann ein Text erzeugt, der als RfD
eingereicht werden kann.

3.2. Einreichung des RfD
------------------------

Der fertige RfD ist dann per E-Mail an <moderator@dana.de> an die
Moderation von de.admin.news.announce einzureichen. Neben dem
eigentlichen Text sollte dabei auch die Liste der Gruppen übermittelt
werden, in denen der RfD veröffentlicht werden soll. Der RfD kann auch
bereits einschließlich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehängte Textdatei, übermittelt
werden.

Üblicherweise wird die Moderation den Eingang des RfD bestätigen und
ihn in den wöchentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation veröffentlicht wird. Danach wird ein
Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
überprüft, ggf. Rücksprache mit dem oder den Proponenten nimmt und ihn
schließlich in de.admin.news.announce und den übrigen Gruppen
veröffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, können diese in der Regel mit dem
Verfahrensbetreuer diskutiert und geklärt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben
üblicherweise bereits längerfristige Erfahrungen mit de.* und dem
Einrichtungsverfahren gesammelt und können daher im Zweifel Tips und
Hinweise geben oder beratend tätig werden.

Siehe auch:

+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <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
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 muss 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 unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begründung
| -----------   ----------
|
| [kurze Begründung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| Abstimmungsmodalitäten
| ----------------------
|
| Votetaker      : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein     : Untenstehendes Formular ist zu verwenden. Möglich sind
|                  bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gültigen Fassung, die in de.admin.infos
| und unter <http://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| veröffentlicht sind. Sie erläutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Gezählt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestätigt. Das Ergebnis wird
| nach dem Ende der Wahl veröffentlicht. Namen, E-Mail-Adresse und
| Inhalt der Stimmabgabe aller Abstimmenden werden im Ergebnis genannt.
| Mit Rücksicht auf das deutsche Datenschutzrecht ist daher die
| gesonderte Zustimmung zur Speicherung und Veröffentlichung der
| abgegebenen Stimme entsprechend Hinweis im Wahlschein nötig.
|
| =-=-=-=-=-=-=-=- 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
<https://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.

Für Hinweise, Anregungen und Verbesserungsvorschläge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frühere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
haben außerdem beigetragen:

- Lutz Donnerhacke
- Kristian Köhntopp
- Rolf Krahl
- Martin Recke
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth

Herzlichen Dank!
-- 
Id: $Format:%t %d %ai %an$