Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.11
Last-modified: (unreleased)
URL: https://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

          Erluterungen 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. Vorberlegungen
   1.1. Bedarf fr eine neue Gruppe
   1.2. Status quo: bestehende Gruppen und frhere Vorschlge
   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. Sonderflle

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 Rckzug des Vorschlags

4. Abstimmungsphase
   4.1. Voraussetzungen fr die Durchfhrung einer Abstimmung
   4.2. Inhalt und Aufbau eines CfV
   4.3. Sonderfall: CfV mit persnlichem Wahlschein
   4.4. Abstimmungsphase
   4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. Lschungen, Umbenennungen, Status- und Regelnderungen u..
   7.1. Gruppenlschungen
   7.2. Umbenennungen
   7.3. nderungen von Charta und/oder Kurzbeschreibung
   7.4. Statusnderungen
   7.5. Regelnderungen und Personenwahlen

8. Quellen
   8.1. Grundlegende Informationen
   8.2. Weiterfhrende Hinweise
   8.3. Webseiten

9. Maintainer und Kontakt
   9.1. Derzeitige Maintainer
   9.2. Frhere 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 fr die Einrichtung, nderung
und Entfernung von Usenet-Gruppen" [1] (kurz: Einrichtungsregeln)
niedergelegten Regeln zur Einrichtung neuer Gruppen kommentieren und
erlutern. Er gibt dabei notwendig den Blick der Autoren bzw.
Maintainer auf die Verhltnisse in de(.admin.news).* und ihre
Erfahrungen wieder.

[1] Verffentlicht in de.admin.infos:
|   From: thh@thh.name (Thomas Hochstein)
|   Newsgroups: de.admin.infos,de.alt.admin
|   Subject: <2021-12-13> Einrichtung, Aenderung und Entfernung von Usenet-Gruppen in de.*
|
|   Archive-name: de-admin/einrichtung
|   Posting-frequency: weekly
|   Last-modified: 2021-12-13
|   URL: https://www.kirchwitz.de/~amk/dai/einrichtung
|   URL: https://th-h.de/archives/faqs/einrichtung.txt

(Eine Liste aller in diesen Erluterungen 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 einwchige 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 gefhrt, die ihre
Beitrge jeweils untereinander austauschen. Damit das funktionieren
kann und jeder Benutzer dieselben Newsgroups zur Verfgung hat, mssen
sich die Betreiber dieser Vielzahl von Newsservern nach Mglichkeit
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
mglich. Daher werden fr gepflegte Newsgroups-Hierarchien wie de.*
Listen der Newsgroups gefhrt, die zur Hierarchie gehren; mit dieser
Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand
abgleichen.

Fr de.* wird die kanonische Liste der bestehenden Newsgroups von der
Moderation von de.admin.news.announce gefhrt, die jeden Monat auch
eine entsprechende, digital signierte Steuernachricht (checkgroups)
versendet, mit der die meisten Newsserverbetreiber ihren
Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
Fr die Aufstellung dieser Liste sind vielerlei Mglichkeiten denkbar;
in de.* entscheiden die Benutzer ber ihren Inhalt. nderungen am
Gruppenbestand - Neueinrichtung, Lschung 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) einschlielich ihrer Einordnung in den bestehenden,
hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden knnen. Am Ende dieser
Vorberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe heien soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegenber bestehenden Gruppen abgrenzt. Mit der
Verffentlichung 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 gefhrt wird, wird der Vorschlag auf
inhaltliche Qualitt und Akzeptanz abgeklopft und ggf. verndert oder
verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der
Vorschlag abstimmungsreif erscheint. Die Verffentlichung 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@thh.name (Thomas Hochstein)
| Newsgroups: de.admin.infos
| Subject: <2024-05-26> Wichtige Begriffe in de.admin.news.*
|
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Version: 1.5.9
| Last-modified: 2024-05-26
| URL: https://th-h.de/archives/faqs/dan-glossar.txt
| URL: https://www.kirchwitz.de/~amk/dai/dan-glossar


0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
----------------------------------------------------------

Das Einrichtungsverfahren lsst sich in folgende Phasen unterteilen,
die im Folgenden dann nher erlutert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information ber den status quo, Bedarfsabschtzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines frmlichen 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 Statusbersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erhlt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prft
den RfD (und die weiteren Verfahrensbeitrge) auf Vereinbarkeit mit
den Regeln, nimmt die ntigen Verffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) fr sich im Verlauf
des Verfahrens ergebende Fragen zur Verfgung.

[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem
    Betreff "dana-Status" wchentlich in de.admin.news.announce
    verffentlicht und im WWW unter <https://www.dana.de/status.html>
    abrufbar.

0.3.2. Diskussionsphase

* Beginn mit Verffentlichung 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 genderten Vorschlgen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der brigen Teilnehmer zu ergrnden; nderungsvorschlge knnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten errtert, 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 mchte oder
ob er den Vorschlag zurckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten verffentlichen RfD im Wesentlichen
bereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
Rckzug des Vorschlags oder Verfall durch Nichtbetreiben ber fnf
Wochen) oder der Verffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Verffentlichung 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 besttigt
* Mindestdauer: 3 Wochen, Hchstdauer: 1 Monat (~ 4 Wochen)
* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
  Abstimmenden
* einwchige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgefhrt, der die CfVs zur Verffentlichung einreicht, die
Stimmen per E-Mail sammelt, besttigt und auszhlt und am Ende das
Ergebnis der Abstimmung zur Verffentlichung einreicht. Diese Aufgabe
kann der Proponent bernehmen, er muss es aber nicht; da die
Durchfhrung und Auszhlung einer Abstimmung einen gewissen
technischen und organisatorischen Aufwand erfordert und auch Erfahrung
im Umgang mit Zweifelsfllen - auch Manipulationsversuchen -
wnschenswert ist, besteht die Mglichkeit, 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 Verffentlichung des Ergebnisses. Daran schliet
sich ein einwchiger Einspruchszeitraum an, in dem Regelverste durch
einen Einspruch bemngelt werden knnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskrftig.

0.3.4. Umsetzung

Wenn der Vorschlag in der Abstimmung angenommen wurde - wozu
mindestens 15 Stimmen JA-Stimmen und zugleich eine Mehrheit von 2/3
der abgegebenen gltigen 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. Vorberlegungen
==================

1.1. Bedarf fr eine neue Gruppe
--------------------------------

Ganz am Anfang der berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zunchst die Frage, ob die angedachte Gruppe denn auch
tatschlich bentigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuknftigen 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 berfllt ist.

Die zuknftige Nutzungsintensitt der vorgeschlagenen Gruppe wird
dabei regelmig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

* Wenn ja: Ist die bisher dafr genutzte Gruppe berfllt (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 vollstndig ist; die
  meisten denkbaren Themen passen in eine oder mehrere bereits
  bestehende Gruppen thematisch hinein.

  Sind die derzeitigen Diskussionsteilnehmer bereit, zuknftig die neu
  einzurichtende Gruppe zu benutzen (oder wnschen 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 zustzlich zu diesem auch das Usenet als Diskussionsmedium zu
  benutzen?

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
  zuknftig einigermaen intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tatschliche
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 mchten. 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 fhren. Die
mehrheitliche Ansicht geht berdies dahin, dass es nicht sinnvoll ist,
fr "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es berwiegend als
wnschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und frdern.

Siehe auch:

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
  <https://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: https://www.kirchwitz.de/~amk/dai/dang-faq

1.2. Status quo: bestehende Gruppen und frhere Vorschlge
----------------------------------------------------------

Die Frage nach dem Bedarf an einer neuen Gruppe fhrt 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 lsst sich das Thema der neuen Gruppe
von den bestehenden themenverwandten Gruppen abgrenzen?

Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
mglicherweise 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 spter wieder aus der Gruppenliste
entfernt wurde? Aus diesen berlegungen ergeben sich Hinweise auf die
Erfolgsaussichten des Vorschlags und mglicherweise auch Anregungen
fr seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche nderungen in Inhalt oder Begrndung erneut einzubringen.

[3] Am bekanntesten drfte das Angebot von Google Groups sein, das
    allerdings nur bis zum Februar 2024 reicht:
    <https://groups.google.com/>

    de.admin.news.announce bei Google Groups:
    <https://groups.google.com/g/de.admin.news.announce>

1.3. Mitinteressenten
---------------------

     "Gemeinsam sind wir stark."

In der Diskussionsphase kommt es weniger auf die Anzahl der
Befrworter 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 fhrt oft zu besseren
Ergebnissen als einsames Grbeln im stillen Kmmerlein.

Auch in der Diskussion ist es frderlich, einen Vorschlag nicht
alleine argumentativ zu sttzen; 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 Grnden ist es angenehmer, die
eigene Position nicht alleine vertreten zu mssen.

Eine Mitwirkung anderer Interessenten kann dabei auf vielfltige Weise
erfolgen. Ein Vorschlag kann durch mehrere Proponenten eingebracht
werden; die Mitwirkung kann sich aber auch auf Untersttzung bei
inhaltlichen und Formulierungsfragen oder der formalen Abwicklung des
Einrichtungsverfahrens oder Beitrge in der Diskussionsphase
beschrnken.

2. Einrichtungsvorschlag
========================

Vor der Einrichtung einer neuen Newsgroup oder dem Beginn der
Abstimmung ber den entsprechenden Vorschlag mssen nach den
Einrichtungsregeln Name und Attribute der vorgeschlagenen Gruppe
feststehen:

| Ein CfV kann nicht verffentlicht 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 zunchst 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 heien soll (2.1.); dann fehlt nur noch eine knackige
Zusammenfassung fr die Kurzbeschreibung (2.2.).

Falls eine moderierte Newsgroup vorgeschlagen wird, mssen auch der
oder die vorgesehenen Moderatoren feststehen; berdies sollte ein
Konzept fr die Moderation vorliegen und die technischen
Voraussetzungen hinreichend geklrt sein.

2.1. Auswahl des Gruppennamens
------------------------------

2.1.1. Einordnung

Zunchst sollte die prospektive Gruppe sich in die bestehende
Namenshierarchie in de.* einpassen. de.* besteht nmlich aus
thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
immer feineren thematischen Verstelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollstndig
logisch stringent, und regelmig wird es nicht nur einen denkbaren
Platz geben, an den eine neue Gruppe passen wrde.

Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
bemhen, den bestmglichen Ort fr die neue Gruppe zu finden. Dazu
gehrt 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
Erluterungen 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 beschftigen sich mit den
  - im Usenet umfnglich 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

  * Gerte (Hardware) und Technik:
  de.comm.geraete.* - Festnetz- und Mobiltelefone und Telefonanlagen
  de.comm.technik.* - Netztechnik (DSL und Mobilfunknetze)
  de.comm.internet.* - Infrastrukturaspekte des Internet
  de.comm.protocols.* - Kommunikationsprotokolle

  * Software:
  de.comm.software.* - Browser, Mail-/Newsreader und -server etc.

  und schlielich:
  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 dazugehrt. Auch sie ist demnach umfangreich weiter
  untergliedert, neben verschiedenen Einzelgruppen namentlich in

  * Hardware:
  de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks
  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.* beschftigt sich mit
  Freizeitaktivitten ("recreational activities") aller Art und
  enthlt neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien
  zu den Themen Musik hren 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 fr 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; Senioren, Schule und
  Studium; Arbeit und Arbeitslosigkeit; Umwelt, Verkehr und
  Wirtschaft; Datenschutz und Zensur.

* de.talk.*
  Die - sehr kleine - Unterhierarchie de.talk.* ist mehr fr Smalltalk
  und entspannten Plausch als Diskussion und Informationsaustausch
  vorgesehen; viele der verbliebenen Gruppen wrden aber ebenso gut
  nach de.soc.* passen.

* de.org.*
  Die - gleichfalls kleine - Teilhierarchie de.org.* ist fr
  Organisationen und Vereine, deren Verlautbarungen und Diskussionen
  um sie herum gedacht. Verblieben ist hier im Wesentlichen die
  Newsgroup zum CCC.

* de.etc.*
  In der de.etc.*-Unterhierarchie sind sonstige Themen
  zusammengefasst, die nicht in eine der anderen Unterhierarchien
  passen. Dazu gehren das Bahnwesen, Autos und andere Fahrzeuge,
  Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
  Notfallrettung und Militrwesen oder auch die Haushaltsfhrung.

Siehe auch:

+ Die Newsgruppen der de-Hierarchie
| From: Thomas Hochstein <thh@thh.name>
| 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: https://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 aussagekrftig und allgemeinverstndlich,
aber zugleich auch so kurz wie mglich gewhlt werden. Kryptische oder
mehrdeutige Abkrzungen sollte man mglichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, sptestens aber in der Charta erlutert werden.

Fr die Wahl des Gruppennamens sind zudem technisch geprgte
Vorgaben [4] zu beachten, die sich auch im WWW unter
<https://dana.de/newsgroup-namen.html> nachlesen lassen:

* Der Name besteht aus mehreren durch Punkte getrennten Segmenten.

* Die einzelnen Segmente drfen nicht lnger als 30 Zeichen werden und
  mssen mindestens je einen Buchstaben enthalten. Zu beachten ist
  dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene
  schon vor dem 15. Zeichen unterscheiden mssen.

* 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 Lnge 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>
    <https://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>

2.2. Kurzbeschreibung
---------------------

Die Kurzbeschreibung soll in Ergnzung zum Gruppennamen das Thema kurz
umreien. Im Gegensatz zur Charta, der ausfhrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
gngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelmig versandten
Steuernachrichten, die den aktuellen Gruppenbestand von de.*
enthalten.

Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muss kurz, knapp und fr jeden verstndlich sein. "Diskussion
ber" oder "Informationen von" sind zum Beispiel notorisch
berflssige Formulierungen. Hingegen sollten mglichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer mglicherweise 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 Beschrnkung fr die Lnge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt fr die Kurzbeschreibung gewhnlich eine Maximallnge
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 beschrnken. 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 fr 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 mglich und nur so
ausfhrlich wie ntig umreien, 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, fr das Thema der Gruppe einige Beispiele als nicht
abschlieende Aufzhlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen mglicherweise gesucht wird.
Dabei ist aber zu bercksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW verffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfgung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl mglicherweise Name und
Kurzbeschreibung bei flchtiger Durchsicht zu dieser Annahme fhren
knnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrcklich auszuschlieen. 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 Lschung der
betreffenden Gruppen eine Chartanderung ntig wrde (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 wre bspw. an die (ausdrckliche) Akzeptanz
anonymer Beitrge oder von Inseraten. Gleichfalls sollten vorgesehene
ungewohnte technische Manahmen - zu denken wre hier bspw. an die
Eingangsbesttigung von Postings per E-Mail durch die sog. Reflektoren
in den Testgruppen - durch die Charta legitimiert werden. In allen
diesen Fllen sollte einerseits bercksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdrcklich abgelehnt wird, sowohl wegen der unntigen
Verlngerung der Charta als auch, weil dies den Eindruck vermitteln
knnte, die entsprechenden Regeln und Konventionen htten nur dort
Geltung, wo sie ausdrcklich 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 Grnde haben und zudem als feststehende Gewohnheiten
betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut
begrndeten Sonderfllen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie mglich gehalten werden; weitergehende
Erluterungen und solche Regeln, die sich voraussichtlich hufiger
ndern werden, gehren nicht in die Charta, sondern sollten Gegenstand
einer (regelmig geposteten und nach Mglichkeit auch im WWW
bereitgestellten) Einfhrung, 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 Erwhnung finden;
die einzelnen angedachten Tags gehren dann in eine anderweitig
bereitgestellte Erluterung. Auch das Moderationskonzept einer
moderierten Gruppe gehrt schon aufgrund seiner Lnge 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 Gefhl fr 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 verffentlicht 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
mehrkpfige Moderation). Diese entscheidet dann ber die
Verffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
bersichtlichkeit und hheren inhaltlichen Qualitt, weil Beitrge
vorgefiltert werden knnen; ihr Nachteil ist die zwangslufig
entstehende Verzgerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn besttigen muss. Sie eignen sich daher vor
allem fr Ankndigungen oder FAQs. Ein Beispiel hierfr ist
de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen verffentlicht werden, so dass die Gruppe auch fr
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige berprfung der
Verffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte verffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer hheren inhaltlichen Qualitt dienen und ermglicht
vor allem den Ausschluss von bewussten Strern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegrndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden
Verzgerungen vor Verffentlichung eines Beitrags den Fluss der
Diskussion stren und an Verffentlichung ihrer Beitrge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschtzen; 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 Beitrge so zeitnah wie
mglich zu prfen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zustzliche Angaben zur Moderation zu machen;
dazu gehren der oder die vorgesehene(n) Moderator(en) und die
Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
fr die Newsgroup zur Freigabe weitergeleitet werden sollen. Auerdem
muss die Kurzbeschreibung entsprechend ergnzt werden. Schlielich
sollte fr die Durchfhrung 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
  Verffentlichung des Vorschlags seine entsprechende Bereitschaft
  erklrt haben; in der Regel wird es sich empfehlen, ein mehrkpfiges
  Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
  auch im Falle eines mehrwchigen Urlaubs oder gar eines dauerhaften
  Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
  interessiert sein mag  - die Moderation handlungsfhig bleibt und
  Beitrge weiterhin verffentlicht werden knnen. Fr moderierte
  Diskussionsgruppen wird regelmig ein ausreichend groes Team
  zwingend vorzusehen sein, damit Beitrge zumindest tagsber zeitnah
  verffentlicht werden knnen.

  Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
  Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
  Einreichungen bewerten zu knnen, von den zu erwartenden
  Diskussionsteilnehmern akzeptiert werden und schlielich absehbar
  fr lngere Zeit fr diese Ttigkeit zur Verfgung stehen. Erfahrung
  im Usenet und ggf. die notwendigen technischen Kenntnisse zur
  Durchfhrung der Moderation sind hilfreich.

* Wenn die (erste) Moderation personell feststeht, stellt sich als
  nchstes die Frage, welche E-Mail-Adresse fr Einreichungen
  ("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
  in jedem Newsserver oder an einer zentralen Stelle (den Relays fr
  moderators.isc.org) in der Konfiguration vermerkt werden, sollte
  sich also so selten wie mglich ndern; auerdem sollte die Adresse
  zuverlssig erreichbar sein und ggf. die Mglichkeit fr
  ausreichende Spamfilterung bieten; langjhrig aktive und regelmig
  verffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
  Spam an.

  Daneben sollte eine weitere Adresse verffentlicht werden, ber die
  der Moderator oder die Moderation kontaktiert werden knnen, ohne
  dass eine Verffentlichung erfolgt, um bspw. fr Anfragen erreichbar
  sein.

* Die Kurzbeschreibung der Gruppe (2.2.) muss im Falle einer moderierten
  Gruppe zwingend mit der Submissionsadresse und dem Schlsselwort
  "(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 Ankndigungen, FAQs o.. enthalten soll, sollte eine
  Gruppe bestimmt werden, in der diese Ankndigungen oder FAQs
  anschlieend ggf. diskutiert werden knnen und in die Antworten dann
  per gesetztem Followup-To:-Header geleitet werden.

* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
  welchen Kriterien Beitrge akzeptiert oder zurckgewiesen werden, ob
  sie ggf. verndert verffentlicht werden knnen und wie mit
  Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
  mehrkpfigen Moderation stellt dies eine einheitliche Handhabung
  sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
  werden und danach (regelmig) verffentlicht werden.

  Entsprechende Beispiele finden sich in bereits bestehenden
  moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der
  de-Hierarchie" enthlt teilweise Verweise darauf.

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
  Mglichkeit, einen per E-Mail bersandten Beitrag unter Beibehaltung
  der wesentlichen Informationen auch im Header - aber unter Wegfall
  mancher und Ergnzung anderer Headerzeilen - als Posting zu
  verffentlichen. Insbesondere dann, wenn mehr als eine Person -
  parallel - an der Moderation beteiligt sein soll (was sich
  mittlerweile als Regelfall etabliert haben drfte), empfiehlt es
  sich, das entsprechende Zusammenwirken auch technisch zu
  untersttzen. 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 Verfgung zu stellen. Die Auswahl und Erprobung der
  vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
  Kontaktaufnahmen sollten aber sptestens parallel zum laufenden
  Einrichtungsverfahren erfolgen; Tests knnen bspw. in der Newsgroup
  de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
  <https://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
  <https://web.archive.org/web/20230324224453/pages.swcp.com/~dmckeon/mod-faq.html>
+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
  <https://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
  <https://www.big-8.org/wiki/Moderated_Newsgroups>
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
  <https://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
+ Informationen ber de.alt.test.moderated
| From: Thomas Hochstein <thh@thh.name>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2024-05-20>
|
| Posting-frequency: monthly
| Last-modified: 2024-05-20
| URL: https://th-h.de/net/usenet/faqs/datm-info/


2.5. Sonderflle
----------------

Die vorstehenden Erluterungen decken den Regelfall der Einrichtung
einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene
Sonderflle:

* 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 fr 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 Grndung der Hierarchie
|   fhrende RfD hat hierzu die notwendigen Angaben bereitzustellen.
|   Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
|   findet hierber eine normale Abstimmung statt.

  Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe fr
  Ausrstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
  werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
  eingerichtet werden. Dies geschieht regelmig 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
  zusammenhngende, 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 Kdern zu tun haben. Die entsprechenden Informationen - Name,
  Kurzbeschreibung, Charta - mssen 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 fr
  alle Gruppen die notwendigen Informationen bereitstellen.

  Zu bercksichtigen ist, dass Vorschlge grundstzlich nicht "en
  bloc" zur Abstimmung gestellt werden knnen; vielmehr ist ber jeden
  Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
  Teil 7 folgende Vorgaben:

| bertragbarkeit: Stimmen knnen nicht auf einen anderen
|   Abstimmungsvorschlag bertragen werden. Eine Stimme zhlt nur fr
|   GENAU DEN Vorschlag, fr den sie abgegeben wurde. Insbesondere
|   darf eine Stimme fr oder gegen eine Newsgruppe mit einem
|   bestimmten Namen NICHT als Stimme fr 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 gezhlt
|   werden. ber jede Gruppe wird einzeln abgestimmt, Verknpfungen
|   von Wahlen sind nicht mglich.

* Diskussion mehrerer Alternativen

  Ziel der Diskussion sollte es regelmig sein, am Ende der
  Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
  Das schliet nicht aus, in der Diskussion zunchst mehrere denkbare
  Alternativen vorzuschlagen; die Diskussion sollte aber schlielich
  zu einem mehrheitsfhigen Vorschlag fhren. Ggf. kann dazu auch ein
  unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
  sich ausschlieende Alternativen zur Abstimmung zu stellen sollte
  nach Mglichkeit vermieden werden, weil die Abstimmung sonst
  einerseits schnell sehr kompliziert wird und andererseits die Gefahr
  besteht, dass entweder kein Vorschlag eine Mehrheit erhlt (obwohl
  die Mehrzahl der Abstimmenden durchaus generell fr eine Einrichtung
  der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
  Vorschlgen angenommen wird, das so niemand gewollt hat.

  Die fr die Abstimmung in diesem Fall zu beachtenden Regeln fr
  "kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
  und lauten folgendermaen:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| hchstens 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
| zustzlich 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 Verhltnis Zustimmung : Ablehnung aufweist.

  Siehe dazu auch:

  + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|   From: Ralf Dblitz <faq@netzverwaltung.net>
|   Newsgroups: de.admin.news.misc,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: https://www.kirchwitz.de/~amk/dai/entscheidung

3. Diskussionsphase
===================

Wenn alle Vorberlegungen abgeschlossen sind, kann das "offizielle"
Einrichtungsverfahren mit der Abfassung eines frmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prfung verffentlicht 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 Begrndung des
Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit fr 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
Begrndung, die den Hintergrund fr den Vorschlag und die berlegungen
insbesondere zu den bereits oben unter 1. ("Vorberlegungen")
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"). Auerdem enthlt der RfD
natrlich 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 fr die
Kommunikation mit der Moderation von de.admin.news.announce und fr
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.

Schlielich ist auch zu entscheiden, in welchen Gruppen der RfD
verffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zustzlich 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 eingeschrnkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natrlich 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
mglich und nur so lang wie ntig sein sollte; dies schon deshalb,
weil in bermig viele Gruppen verteilte Postings heutzutage
mglicherweise als Spam ausgefiltert werden.

Eine Verffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im
Einverstndnis mit deren Moderation. In Gruppen auerhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.. kann der Proponent nach Verffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") verffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden knnen.

3.1.2. Formale Gestaltung

Fr 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 / Begrndung
| -----------   ----------
|
| [Begrndung, ggf. untergliedert]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]

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 verffentlicht werden soll. Der RfD kann auch
bereits einschlielich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehngte Textdatei, bermittelt
werden.

blicherweise wird die Moderation den Eingang des RfD besttigen und
ihn in den wchentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation verffentlicht wird. Danach wird ein
Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
berprft, ggf. Rcksprache mit dem oder den Proponenten nimmt und ihn
schlielich in de.admin.news.announce und den brigen Gruppen
verffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, knnen diese in der Regel mit dem
Verfahrensbetreuer diskutiert und geklrt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben
blicherweise bereits lngerfristige Erfahrungen mit de.* und dem
Einrichtungsverfahren gesammelt und knnen daher im Zweifel Tipps und
Hinweise geben oder beratend ttig 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: <2026-02-01> Moderationskonzept der derzeitigen Moderation
  <https://dana.de/modkonzept.html>

3.3. Diskussionsphase
---------------------

Nachdem die Moderation den RfD verffentlicht 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 Einwnde und Kritik eingehen und ggf. ihre
Begrndung verfeinern.

Hufig wird die Diskussion sinnvolle Ergnzungen zum ursprnglichen
Vorschlag bringen, die in einen neuen, genderten Vorschlag
eingearbeitet werden knnen. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur
Verffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begrndung, warum welche Vorschlge aufgenommen oder
verworfen wurden, enthlt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, knnen auch mehrere weitere RfDs
verffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unntig verlngert oder verzgert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu
verffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden Verbesserungsvorschlge 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 Vorschlge und
nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen genderten Vorschlag als
weiteren RfD zu verffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
mglichst konstruktiv gefhrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer
ausschlielich 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 starrkpfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. berleitung zur Abstimmung oder Rckzug des Vorschlags
-----------------------------------------------------------

Am Ende der Diskussion sollte(n) der/die Proponent(en) sich darber
Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag
voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall,
kann das Verfahren zurckgezogen werden.

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten verffentlichen 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 verffentlichen.

Nach Mglichkeit sollte am Ende der Diskussion nur noch ein einziger,
einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls mssen aber
fr 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 whrend des Abstimmungszeitraums an die
E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszhlt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer verffentlicht. Die
Durchfhrung 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 Durchfhrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu berlassen.

4.1. Voraussetzungen fr die Durchfhrung einer Abstimmung
----------------------------------------------------------

Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen
gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld
prfen:

* Fr die Durchfhrung der Abstimmung bentigt man einen
  E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
  nach Mglichkeit nicht mit der "normalen" E-Mail-Adresse des
  Abstimmungsleiters identisch sein, damit keine Missverstndnisse
  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 fhren,
  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>
|
|   Filtermanahmen bei der Durchfhrung von Abstimmungen
|   =====================================================
    <https://dana.de/archiv/2011-03-12-admin-wahlaccounts.txt>

* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von
  Hand zu bearbeiten, sondern dafr geeignete Software zu verwenden,
  die Plausibilittsprfungen vornimmt, Besttigungen per E-Mail
  versenden kann und Auswertungen automatisch erstellt.

  Die verbreitetste Softwarelsung dafr ist UseVote; mehr
  Informationen dazu und eine Downloadmglichkeit gibt es auf
  <http://www.usevote.de/>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
  haben sich einige regelmige Teilnehmer in de.admin.news.* dazu
  bereiterklrt, 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 ermglichen. Dazu zhlen (Stand 04/2011) u.a.

  - Ralph Angenendt <ihr.name@strg-alt-entf.org>
  - Ralf Dblitz <doeblitz@doeblitz.net>
  - Karsten Dsterloh <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 Mglichkeit, die Abstimmung gar nicht
  selbst durchzufhren, sondern damit einen Dritten zu beauftragen,
  der weitergehende technische Mglichkeiten oder grere Erfahrungen
  mit der Durchfhrung von Abstimmungen hat. berdies ist es zwar
  zulssig und auch der von den Einrichtungsregeln ursprnglich
  vorgesehene Regelfall, dass der Proponent auch die Abstimmung
  durchfhrt, manchmal ist es aber erwnscht, damit einen unabhngigen
  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, fr ihn die Abstimmung durchzufhren. In den letzten
  Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
  Mitglieder der GVV durchgefhrt.

  Siehe dazu auch:

  + GVV-FAQ
|   From: Thomas Hochstein <thh@votetaker.de>
|   Newsgroups: de.admin.infos,de.admin.news.groups
|   Subject: <2025-04-13> GVV-FAQ
|
|   Archive-name: de-admin/gvv-faq
|   Posting-frequency: weekly
|   Last-modified: 2025-04-13
|   URL: https://votetakers.de/faq.php
|   URL: https://www.kirchwitz.de/~amk/dai/gvv-faq

4.2. Inhalt und Aufbau eines CfV
--------------------------------

Auch fr 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 fr 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
hchstens einen Monat betragen. blicherweise wird diese Frist nicht
ausgeschpft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV verffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es blich, Abstimmungen
um Mitternacht enden zu lassen. Daher knnten sich bei einer
Abstimmungsdauer von einem Monat und Verffentlichung des 1. CfV bspw.
um 16:30 Uhr unntige Diskussionen ergeben, ob damit nicht die
Hchstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht)
berschritten wird.

Schlielich muss der CfV mit dem letzten RfD im wesentlichen
bereinstimmen, wie Teil 6 der Einrichtungsregeln festhlt:

| 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 Abstimmungsmodalitten; an diesen
drfen 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 Begrndung - soweit sie berhaupt im
CfV wiederholt wird - ist hingegen regelmig unproblematisch.

blich ist es, auf Basis des letzten verffentlichen RfD einen CfV zu
entwerfen. Dabei kann der Begrndungsteil gekrzt werden oder ganz
entfallen und durch einen Verweis auf die gefhrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefgt werden dann die
Abstimmungsmodalitten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele fr
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nmlich als berflssig; bei komplexeren Abstimmungen hingegen wrde
die Darstellung aller mglichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solchermaen unbersichtlich und aufwendig,
dass regelmig darauf verzichtet wird. Wenn jedoch die einzelnen
Abstimmungsmglichkeiten dargestellt werden, dann mssen sowohl die
Abstimmungsmglichkeiten fr wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu
vermeiden.

Beispiele fr CfVs finden sich in de.admin.news.announce. Eine
mgliche Gestaltung wre folgende:

|             1. CfV (Abstimmungsaufruf)
|             ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname]   [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begrndung
| -----------   ----------
|
| [kurze Begrndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| Abstimmungsmodalitten
| ----------------------
|
| Votetaker      : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein     : Untenstehendes Formular ist zu verwenden. Mglich 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 gltigen Fassung, die in de.admin.infos
| und unter <https://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| verffentlicht sind. Sie erlutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
|                       Hinweise zur Abstimmung und
|           Informationen zur Datenverarbeitung (Art. 13 DSGVO)
|           ---------------------------------------------------
|
| Gezhlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail besttigt; die komplette
| Abstimmungs-E-Mail und die Stimmdaten - Name, E-Mail-Adresse und Inhalt
| der Stimmabgabe - werden bis vier Wochen nach endgltigem Abschluss des
| Verfahrens (Umsetzung nach Ablauf der Einspruchsfrist) beim Votetaker
| gespeichert und zur Erstellung des Ergebnisses verarbeitet.
|
| blicherweise erfolgt eine Sammelbesttigung der bis dahin abgegebenen
| Stimmen durch Verffentlichung von Namen und E-Mail-Adressen aller
| Abstimmungsteilnehmer in einem 2. CfV. Auch im nach Ende der Abstimmung
| verffentlichten Ergebnis werden Namen, E-Mail-Adresse und Inhalt der
| Stimmabgabe fr alle Abstimmenden genannt.
|
| Auf Anfrage knnen die gespeicherten Daten an die Moderation von
| de.admin.news.announce bermittelt werden.
|
| Speicherung, Verarbeitung und Verffentlichung sowie ggf. bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die fr
| eine Wertung und Verffentlichung der Stimmabgabe entsprechend des
| Hinweises im Wahlschein notwendig ist. Die Einwilligung kann jederzeit
| durch Mitteilung per E-Mail an den Votetaker mit Wirkung fr die Zukunft
| widerrufen werden. Die Wertung und Verffentlichung der Stimmdaten
| kann auch durch die erneute Einreichung eines Wahlscheins mit
| "ANNULLIERUNG" (statt "JA" oder "NEIN") als Stimmabgabe beim ersten
| Abstimmungspunkt verhindert werden. Ohne Erteilung der Einwilligung oder
| nach deren Widerruf kann die Stimmabgabe nicht gewertet werden.
|
| Auch ohne Erteilung einer Einwilligung oder nach derem Widerruf erfolgt
| die Speicherung der E-Mail(s) beim Votetaker im einleitend genannten
| Umfang, um ggf. die ordnungsgeme Auswertung der Abstimmung nachweisen
| zu knnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft ber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - Lschung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - Einschrnkung der Datenverarbeitung gem Art. 18 DSGVO
| - Datenbertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zustndigen Aufsichtsbehrde nach Art. 77 DSGVO
|
| Diese Rechte knnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| Zustndige Aufsichtsbehrde ist in diesem Fall [Aufsichtsbehrde].
|
| =-=-=-=-=-=-=-=- 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 Einwilligung 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 die DSGVO
| verworfen und nicht gewertet. Die Einwilligung kann jederzeit mit
| Wirkung fuer die Zukunft widerrufen werden. Dafuer genuegt eine E-Mail
| an den Votetaker. Die Wertung und Veroeffentlichung der Stimmdaten kann
| auch durch die erneute Einreichung eines Wahlscheins mit "ANNULLIERUNG"
| (statt "JA" oder "NEIN") als Stimmabgabe beim ersten Abstimmungspunkt
| verhindert werden.
|
| #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 Mglichkeit vorzusehen, den
tatschlichen Namen anzugeben, da mglicherweise 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
gehrt die Liste der Gruppen dazu, in denen der CfV verffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlielich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehngte Textdatei,
bermittelt werden.

Die Verffentlichung des CfVs wird blicherweise lnger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von
de.admin.news.announce nach dem 4-Augen-Prinzip berprft wird. Daher
kann - und sollte - der 1. CfV ruhig mglichst frhzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Verffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Sonderfall: CfV mit persnlichem Wahlschein
------------------------------------------------

Ergnzend zu der blichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthlt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die Mglichkeit einer Abstimmung unter Verwendung persnlicher
Wahlscheine vor.

Diese 1998/1999 eingefhrte Verfahrensweise [5] soll die Manipulation
von Abstimmungen erschweren, indem sie das normale
Abstimmungsverfahren durch ein Zwei-Schritt-Verfahren ersetzt: der
Abstimmungswillige muss zunchst einen persnlichen Wahlschein beim
Votetaker anfordern, der ein kodiertes, eindeutig dem
Abstimmungswilligen zuzuordnendes Merkmal erhlt und sodann diesen
persnlichen - und an seine E-Mail-Adresse gekoppelten - Wahlschein
ausgefllt zurcksenden. Andere Wahlscheine oder die Verwendung einer
anderen E-Mail-Adresse werden nicht akzeptiert.

Diese Vorgehensweise soll u.a. verhindern, dass vorausgefllte
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 gltig sein, d.h. E-Mails
entgegennehmen muss, berprfbar - denn nur wer eine gltige 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 Manipulationsmglichkeiten verbleiben
und der Aufwand fr die Durchfhrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgefhrt.

In der Abstimmungssoftware Usevote (siehe 4.1.) ist die Durchfhrung
solcher Verfahren implementiert.

[5] Der Vorschlag und die entsprechende Begrndung lassen sich im
    Archiv von Google Groups unter
    <https://groups.google.com/group/de.admin.news.announce/browse_frm/thread/fd056d977d6a5240>
    nachlesen.

4.4. Abstimmungsphase
---------------------

Whrend der drei- oder vierwchigen (maximal aber einmonatigen)
Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach Mglichkeit einigermaen
zeitnah, am besten automatisiert - per E-Mail besttigt werden; in
dieser Besttigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse fr den Abstimmenden registriert wurden.
Fr Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die Besttigung versandt werden, um
sicherzustellen, dass diese Stimme auch tatschlich vom angegebenen
Absender stammte (und die Abstimmadresse replyfhig ist, d.h. E-Mail
dort empfangen werden kann). Auerdem sollte in der Besttigung
angegeben sein, wie eine Stimme nachtrglich gendert oder komplett
zurckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet verffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es blich, einen 2. CfV zu
verffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die
Stimmabgaben!) enthlt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ungltig gewertet werden. Weil auch der 2.
CfV im Rahmen der blichen Bearbeitungszeiten regelmig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen verffentlicht 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 Verffentlichungszeitraum einzureichen.

Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
endet die Abstimmung. Versptete Stimmen werden nicht mehr gezhlt.

4.5. Auswertung und Ergebnis der Abstimmung
-------------------------------------------

Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgezhlt.

Dabei werden zunchst die JA- und NEIN-Stimmen sowie Enthaltungen
gezhlt. 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 Rcksprache 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 gengen (Angabe eines falschen oder nicht
vollstndigen Namens, nicht replyfhige Abstimmadresse), drfen nicht
gewertet werden. Der Votetaker sollte auch die Mglichkeit von
Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
Identitten, Weitergabe des Wahlscheins auerhalb der Gruppen, in
denen er verffentlicht wurde, Beeinflussung der Abstimmung durch
"Campaigning") im Auge behalten und entsprechende berprfungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern geklrt 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 frheren Zweifelsfllen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung ber den konkret entschiedenen
Einzelfall hinaus haben und nicht spter revidiert wurden, unter
<https://www.dana.de/archiv.html> auch im Web verffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die
datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, bercksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Verffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrckliche
Einwilligungserklrungen erforderlich sind.

Danach ist eine Ergebnisverffentlichung ("Result") vorzubereiten.
blich ist es, die Gesamtzahl der gltigen Stimmen und sodann fr
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungltigen Stimmabgaben zu nennen. Angenommen ist der
Vorschlag, wenn mindestens 15 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 Verffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungltige Stimmen sind anzugeben, bei letzteren unter Angabe einer
stichwortartigen Begrndung fr die Nichtwertung. Dies ermglicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen Fllen kann die Verffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere drfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Grnden die Verwendung von Pseudonymen
akzeptiert wird.

5. Verfahrensabschluss und Umsetzung
====================================

Mit der Verffentlichung des Results durch die Moderation von
de.admin.news.announce beginnt eine einwchige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begrndung einlegen kann, dass
bei der Durchfhrung der Abstimmung schwerwiegende Unregelmigkeiten
gab. Das knnen 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 bestandskrftig; 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.* fhren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergnzen.

Ansonsten wird die Moderation ber eingegangene Einsprche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder
schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das
verffentlichte 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 abschlieend 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. Fr kleinere
nderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog.
"Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und
Abstimmungsphase zugunsten einer Widerspruchslsung entfallen.

Bei einem VV wird der entsprechende nderungsvorschlag, der dieselben
Anforderungen wie ein RfD erfllen muss (siehe 3.1.), zur
Verffentlichung in de.admin.news.announce bei <moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darber
hinaus ausdrcklich 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
verffentlicht Namen und E-Mail-Adresse der Widerspruchsfhrer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgefhrt oder aufgegeben
werden.

Wenn der nderungsvorschlag angenommen wurde, wird er durch die
Moderation von de.admin.news.announce umgesetzt (siehe 5.).

7. Lschungen, Umbenennungen, Status- und Regelnderungen u..
==============================================================

Bereits die Einleitung ("bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von
Usenet-Gruppen in de.*" trgt und sich die Ausfhrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschftigen, sie
aber fr alle nderungen am Gruppenbestand analog gelten und auch fr
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden knnen (und regelmig auch angewendet werden):

| Diese Spielregeln gelten fr 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
| herbeizufhren.
|
| 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 Grndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschftigen. Je grer die Hierarchie wurde (und je strker
die Nutzerzahlen wieder zurckgingen), desto hufiger wurden dann
nderungs- und Lschungsverfahren, aber auch Regelnderungen.

Grundstzlich ist die Vorgehensweise in diesen Fllen den
Einrichtungsverfahren vergleichbar, insbesondere die
Begrndungsanstze sind aber freilich andere.

7.1. Gruppenlschungen
----------------------

Gruppenlschungen sind das Gegenteil von Neueinrichtungen und kommen
dementsprechend auch aus den umgekehrten Grnden 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 zusammengefhrt werden. Ziel ist es
letztlich bei Einrichtungen wie bei Lschungen von Gruppen, eine
thematische Aufteilung zu erreichen, die gerade so fein ist, dass
Gruppen zu intensiv diskutierten Themen nicht berfllt sind und
Gruppen zu selten diskutierten Themen nicht leer stehen.

* Insofern wird die Begrndung eines Lschungsvorschlags in der Regel
  primr auf eine statistische Auswertung ber einen lngeren Zeitraum
  (mindestens 12 Monate, im Zweifel aber auch lnger) gesttzt, 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, knnen 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
  Anlsse reagiert und die Gruppe wieder mit Leben fllt. Das spricht
  eher gegen eine Lschung 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 Lschung vorgeschlagenen Gruppe zuknftig diskutiert werden
  sollen. Wenn die Gruppe in einem greren thematischen Zusammenhang
  steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
  benennen, was dann wiederum fr eine niedrigere Schwelle zur
  Lschung spricht, denn so werden einzelne, mittlerweile weniger
  intensiv diskutierte Unterbereiche eines greren Themas wieder
  thematisch zusammengefasst.

  Ein Beispiel dafr wre die Teilhierarchie
  de.comp.office-pakete.ms-office.*, die ursprnglich 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 

  bestand. Sollte sich herausstellen, dass zwar zu Word und Excel
  intensiv diskutiert wird, es aber kaum Fragen zu Powerpoint gibt,
  wrde eine Lschung der Gruppe
  de.comp.office-pakete.ms-office.powerpoint - wie sie Ende 2013
  erfolgte - 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, fr
  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 Fllen ist eine
  besonders kritische Prfung erforderlich, ob sich die Gruppe nicht
  wieder beleben lsst, weil dann die Gefahr besteht, dass ermangels
  Alternativen das Thema vllig aus dem Usenet verschwindet. Solche
  Gruppen sollten daher nur zur Lschung vorgeschlagen werden, wenn
  das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

* Wenn die letzte Gruppe einer Teilhierarchie gelscht 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

  Wrde man die Gruppe de.comm.protocols.tcp-ip lschen, knnte man
  die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
  de.comm.protocols umbenennen, um so den Namen zu verkrzen und die
  Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
  spricht, dass Umbenennungen technisch nicht mglich sind, sondern
  nur durch eine Lschung der bestehenden Gruppe und die
  Neueinrichtung der Gruppe mit dem genderten Namen umgesetzt werden
  knnen (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 mglich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zustzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefhr eine Woche spter von der
Lschung der Gruppe mit dem alten Namen. Dies fhrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmig in die
Gruppe hineinschauen, sie dann pltzlich nicht mehr finden knnen.
Eine solche Umbenennung will also wohlberlegt sein.

7.3. nderungen von Charta und/oder Kurzbeschreibung
----------------------------------------------------

Neben dem Namen knnen auch alle anderen Attribute einer Gruppe (fr
deren Beschreibung siehe 2.) gendert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene Chartanderung die Folge einer
Reorganisation, also der Einrichtung oder Lschung anderer Gruppen, so
dass klarstellende nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gelschten
oder sonstwie genderten Newsgroups aus der Charta entfernt werden
mssen. 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 Kurzbeschreibungsnderung ist dabei im wesentlichen
kein technischer Vorgang. Genderte 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 knnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden Chartanderungen
auch nur durch eine entsprechende Information per Posting in
de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. Statusnderungen
---------------------

Die Umstellung einer bestehenden unmoderierten Newsgroup auf
"moderiert" bzw. einer vormals moderierten Newsgroup auf den Status
"unmoderiert" ist nicht unproblematisch. Auch dies hat technische
Grnde; nicht immer erfolgen technische Umstellungen durch
Steuernachrichten wirklich berall auf jedem Newsserver oder gar
berall zur gleichen Zeit. Dies kann dazu fhren, dass die Gruppe auf
manchen Servern noch als moderiert gefhrt wird, auf anderen aber
schon als unmoderiert (oder umgekehrt).

Soll eine bisher unmoderierte Gruppe zuknftig moderiert sein, fhrt
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"
fhren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuknftig 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 Beitrge
verloren gehen.

Diese technischen Probleme mssen bereits in der Diskussionsphase
bercksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zustzlichen 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 zustzlichen Erwgungen
fr die Einrichtung moderierter Gruppen entsprechend.

7.5. Regelnderungen und Personenwahlen
---------------------------------------

Neben nderungen am Gruppenbestand knnen - und werden - die
Einrichtungsregeln analog auch fr andere Entscheiungen (bspw. die
nderung der Einrichtungsregeln selbst) herangezogen.

Sie gelten - teilweise modifiziert - auch fr Personenwahlen, bspw.
fr die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmigen Abstnden
durchgefhrten Nachwahlen [8]. In gleicher Weise wre es auch mglich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlieen 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 verffentlicht 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: https://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
    regelmig in de.admin.news.announce verffentlicht wird:
|   From: moderator@dana.de (Moderation von de.admin.news.announce)
|   Newsgroups: de.admin.news.announce,de.admin.news.misc
|   Subject: <2026-02-01> Moderationskonzept der derzeitigen Moderation
    und auch auf den Webseiten der Moderation unter
    <https://dana.de/modkonzept.html> abgerufen werden kann.

8. Quellen
==========

Alle in diesen Erluterungen genannten Quellen sind hier noch einmal
zusammengefasst und um weitere Hinweise ergnzt.

8.1. Grundlegende Informationen
-------------------------------

Folgende Texte sollten einem Proponenten unbedingt bekannt sein:

+ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
| From: thh@thh.name (Thomas Hochstein)
| Newsgroups: de.admin.infos,de.alt.admin
| Subject: <2021-12-13> Einrichtung, Aenderung und Entfernung von Usenet-Gruppen in de.*
|
| Archive-name: de-admin/einrichtung
| Posting-frequency: weekly
| Last-modified: 2021-12-13
| URL: https://www.kirchwitz.de/~amk/dai/einrichtung
| URL: https://th-h.de/archives/faqs/einrichtung.txt

+ 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: https://www.kirchwitz.de/~amk/dai/dang-faq

+ Die Newsgruppen der de-Hierarchie (Gruppenliste)
| From: Thomas Hochstein <thh@thh.name>
| 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: https://www.kirchwitz.de/~amk/dni/de-newsgruppen

8.2. Weiterfhrende Hinweise
----------------------------

Folgende Texte sind allgemein oder fr 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: <2026-02-01> Moderationskonzept der derzeitigen Moderation
  <https://dana.de/modkonzept.html>

+ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
| From: thh@thh.name (Thomas Hochstein)
| Newsgroups: de.admin.infos
| Subject: <2024-05-26> Wichtige Begriffe in de.admin.news.*
|
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Version: 1.5.9
| Last-modified: 2024-05-26
| URL: https://th-h.de/archives/faqs/dan-glossar.txt
| URL: https://www.kirchwitz.de/~amk/dai/dan-glossar

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
  <https://th-h.de/net/usenet/admin/newgroup/#vorschlag>

+ Erste Schritte zur Einrichtung neuer Gruppen
  <https://web.archive.org/web/20070105012315/usenet.babylonsounds.com/rfd_howto.html>

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf Dblitz <faq@netzverwaltung.net>
| Newsgroups: de.admin.news.misc,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: https://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>
  <https://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: <2025-04-13> GVV-FAQ
|
| Archive-name: de-admin/gvv-faq
| Posting-frequency: weekly
| Last-modified: 2025-04-13
| URL: https://votetakers.de/faq.php
| URL: https://www.kirchwitz.de/~amk/dai/gvv-faq

+ Filtermanahmen bei der Durchfhrung 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>
  <https://dana.de/archiv/2011-03-12-admin-wahlaccounts.txt>

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
  <https://www.eyrie.org/~eagle/usefor/other/moderators-handbook>

+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
  <https://web.archive.org/web/20230324224453/pages.swcp.com/~dmckeon/mod-faq.html>

+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
  <https://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>

+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
  <https://www.big-8.org/wiki/Moderated_Newsgroups>

+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
  <https://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>

+ Informationen ber de.alt.test.moderated
| From: Thomas Hochstein <thh@thh.name>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2024-05-20>
|
| Posting-frequency: monthly
| Last-modified: 2024-05-20
| URL: https://th-h.de/net/usenet/faqs/datm-info/

+ Entscheidungen der Moderation von de.admin.news.announce
  <https://www.dana.de/archiv.html>

8.3. Webseiten
--------------

Folgende Webseiten sollten bekannt sein oder knnen bei der Durchfhrung des
Einrichtungsverfahrens helfen:

+ Webseite der Moderation von de.admin.news.announce
  <https://www.dana.de/>

+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
  wchentlich verffentlicht in de.admin.news.announce
  <https://www.dana.de/status.html>

+ GVV-Statusbersicht
  <https://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@thh.name>
                       Michael Ottenbruch <dana-manual@ottenbruch.net>

Das dana-Manual wurde im Mrz/April 2011 vollstndig berarbeitet und
neu gefasst.

Weitere nderungen und Ergnzungen nehmen die Maintainer gerne
entgegen. Vorschlge knnen per E-Mail an <dana-manual@usenet.th-h.de>
gerichtet werden. Im Falle einer ffentlichen Diskussion solcher
Vorschlge ist ein Hinweis an die Maintainer hilfreich.

Das dana-Manual ist auch in einem Git-Repository unter
<https://code.virtcomm.de/faqs/dana-manual> verfgbar und kann
ber die Weboberflche eingesehen oder ausgecheckt werden. Bei
nderungsvorschlgen werden Git-Patches bevorzugt; natrlich nehmen
die Maintainer aber auch jede andere Form von Anregungen entgegen.

Fr Hinweise, Anregungen und Verbesserungsvorschlge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frhere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprnglichen Fassung dieses Textes und seiner Entstehung
haben auerdem beigetragen:

- Lutz Donnerhacke
- Kristian Khntopp
- Rolf Krahl
- Martin Recke
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth

Herzlichen Dank!
-- 
Id: 6b8e762  (update) 2026-05-01 12:09:51 +0200 Thomas Hochstein
