From Newsgroup: news.answers

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.10
Last-modified: 2025-04-13
URL: https://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

ErlEuterungen 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. Vornberlegungen
1.1. Bedarf fnr eine neue Gruppe
1.2. Status quo: bestehende Gruppen und frnhere VorschlEge
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. SonderfElle

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

4. Abstimmungsphase
4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung
4.2. Inhalt und Aufbau eines CfV
4.3. Sonderfall: CfV mit pers%nlichem Wahlschein
4.4. Abstimmungsphase
4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E.
7.1. Gruppenl%schungen
7.2. Umbenennungen
7.3. -nderungen von Charta und/oder Kurzbeschreibung
7.4. StatusEnderungen
7.5. RegelEnderungen und Personenwahlen

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

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

[1] Ver%ffentlicht 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 ErlEuterungen genannten Quellen findet
sich noch einmal in Abschnitt 8.)

Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
nachfolgende, mindestens einw%chige Diskussion keinen gar zu heftigen Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im #berblick -------------------------------------------

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

Fnr de.* wird die kanonische Liste der bestehenden Newsgroups von der Moderation von de.admin.news.announce gefnhrt, die jeden Monat auch
eine entsprechende, digital signierte Steuernachricht (checkgroups)
versendet, mit der die meisten Newsserverbetreiber ihren
Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
Fnr die Aufstellung dieser Liste sind vielerlei M%glichkeiten denkbar;
in de.* entscheiden die Benutzer nber ihren Inhalt. -nderungen am Gruppenbestand - Neueinrichtung, L%schung oder Umbenennung von Gruppen
- werden in einem formalisierten Verfahren diskutiert und dann zur
Abstimmung gestellt.

Jedem Einrichtungsvorschlag sollte eine #berlegungsphase vorangehen,
in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
Status, Charta) einschlie#lich ihrer Einordnung in den bestehenden, hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden k%nnen. Am Ende dieser Vornberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe hei#en soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegennber bestehenden Gruppen abgrenzt. Mit der
Ver%ffentlichung dieses Vorschlags in de.admin.news.announce als Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
die in de.admin.news.groups gefnhrt wird, wird der Vorschlag auf
inhaltliche QualitEt und Akzeptanz abgeklopft und ggf. verEndert oder verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der Vorschlag abstimmungsreif erscheint. Die Ver%ffentlichung eines Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die Diskussionsphase und leitet in die Abstimmungsphase nber, 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 lEsst sich in folgende Phasen unterteilen,
die im Folgenden dann nEher erlEutert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information nber den status quo, BedarfsabschEtzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines f%rmlichen Einrichtungsvorschlag (RfD)
* Einreichung des RfD bei der Moderation von de.admin.news.announce

Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
enden die Vorbereitungen; das Verfahren wird in die Statusnbersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erhElt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prnft
den RfD (und die weiteren VerfahrensbeitrEge) auf Vereinbarkeit mit
den Regeln, nimmt die n%tigen Ver%ffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) fnr sich im Verlauf
des Verfahrens ergebende Fragen zur Verfngung.

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

0.3.2. Diskussionsphase

* Beginn mit Ver%ffentlichung des 1. RfD in de.admin.news.announce,
de.admin.news.groups und weiteren betroffenen Newsgroups
* %ffentliche Diskussion des Vorschlags in de.admin.news.groups
* Mindestdauer: 14 Tage
* Einreichung beliebig vieler weiterer RfDs mit geEnderten VorschlEgen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der nbrigen Teilnehmer zu ergrnnden; -nderungsvorschlEge k%nnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten er%rtert, alle
Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen m%chte oder
ob er den Vorschlag zurnckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten ver%ffentlichen RfD im Wesentlichen
nbereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
Rnckzug des Vorschlags oder Verfall durch Nichtbetreiben nber fnnf
Wochen) oder der Ver%ffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Ver%ffentlichung des 1. CfV in de.admin.news.announce und
den nbrigen Gruppen
* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
E-Mail bestEtigt
* Mindestdauer: 3 Wochen, H%chstdauer: 1 Monat (~ 4 Wochen)
* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
Abstimmenden
* einw%chige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgefnhrt, der die CfVs zur Ver%ffentlichung einreicht, die
Stimmen per E-Mail sammelt, bestEtigt und auszEhlt und am Ende das
Ergebnis der Abstimmung zur Ver%ffentlichung einreicht. Diese Aufgabe
kann der Proponent nbernehmen, er muss es aber nicht; da die
Durchfnhrung und AuszEhlung einer Abstimmung einen gewissen
technischen und organisatorischen Aufwand erfordert und auch Erfahrung
im Umgang mit ZweifelsfEllen - auch Manipulationsversuchen -
wnnschenswert ist, besteht die M%glichkeit, einen erfahrenen
Usenet-Teilnehmer um die #bernahme der Abstimmungsleitung zu bitten.
Einige Freiwillige haben sich zu diesem Zweck als "German Volunteer
Votetakers" (GVV) zusammengeschlossen.

Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und letztlich mit der Ver%ffentlichung des Ergebnisses. Daran schlie#t
sich ein einw%chiger Einspruchszeitraum an, in dem Regelverst%#e durch
einen Einspruch bemEngelt werden k%nnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskrEftig.

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 gnltigen 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. Vornberlegungen
==================

1.1. Bedarf fnr eine neue Gruppe
--------------------------------

Ganz am Anfang der #berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zunEchst die Frage, ob die angedachte Gruppe denn auch
tatsEchlich ben%tigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuknnftigen 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 nberfnllt ist.

Die zuknnftige NutzungsintensitEt der vorgeschlagenen Gruppe wird
dabei regelmE#ig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

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

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

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
zuknnftig einigerma#en intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tatsEchliche gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
und ob sie dies im Usenet tun m%chten. Es mag sehr wichtige Themen
geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
oder die anderswo diskutiert werden, ohne dass bei den Interessenten
der Wunsch besteht, ihre Diskussionen im Usenet zu fnhren. Die
mehrheitliche Ansicht geht nberdies dahin, dass es nicht sinnvoll ist,
fnr "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es nberwiegend als
wnnschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und f%rdern.

Siehe auch:

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
<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 frnhere VorschlEge ----------------------------------------------------------

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

Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
m%glicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
eine solche Gruppe, die dann spEter wieder aus der Gruppenliste
entfernt wurde? Aus diesen #berlegungen ergeben sich Hinweise auf die Erfolgsaussichten des Vorschlags und m%glicherweise auch Anregungen
fnr seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche -nderungen in Inhalt oder Begrnndung erneut einzubringen.

[3] Am bekanntesten dnrfte 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
Befnrworter 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 fnhrt oft zu besseren Ergebnissen als einsames Grnbeln im stillen KEmmerlein.

Auch in der Diskussion ist es f%rderlich, einen Vorschlag nicht
alleine argumentativ zu stntzen; nicht nur deshalb, weil eine Mehrzahl
von Interessenten, die sich auch selbst in die Diskussion einbringt, nberzeugender ein dauerhaftes Interesse signalisiert als ein
Einzelner. Auch aus psychologischen Grnnden ist es angenehmer, die
eigene Position nicht alleine vertreten zu mnssen.

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

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

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

| Ein CfV kann nicht ver%ffentlicht werden, wenn einer der folgenden
| Punkte noch unklar ist:
|
| o Name der Gruppe
| o Kurzbeschreibung der Gruppe
| o Charta der Gruppe
| o Status der Gruppe (moderiert oder unmoderiert)
| o der Name des Moderators im Falle einer moderierten Gruppe

Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
sich daher auch die Frage nach der Einordnung der neuen Gruppe in die bestehende Struktur der Hierarchie de.*, und in der Charta sollte
nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
auch die Abgrenzung zu thematisch Ehnlichen Gruppen ihren Platz
finden.

Sinnvoll ist es daher, sich zunEchst Gedanken nber 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
nberlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
demnach hei#en soll (2.1.); dann fehlt nur noch eine knackige
Zusammenfassung fnr die Kurzbeschreibung (2.2.).

Falls eine moderierte Newsgroup vorgeschlagen wird, mnssen auch der
oder die vorgesehenen Moderatoren feststehen; nberdies sollte ein
Konzept fnr die Moderation vorliegen und die technischen
Voraussetzungen hinreichend geklErt sein.

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

2.1.1. Einordnung

ZunEchst sollte die prospektive Gruppe sich in die bestehende
Namenshierarchie in de.* einpassen. de.* besteht nEmlich aus
thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
immer feineren thematischen VerEstelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollstEndig
logisch stringent, und regelmE#ig wird es nicht nur einen denkbaren
Platz geben, an den eine neue Gruppe passen wnrde.

Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
bemnhen, den bestm%glichen Ort fnr die neue Gruppe zu finden. Dazu
geh%rt sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.

Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
Einrichtungsregeln auszeichnet und daher nicht Thema dieser
ErlEuterungen 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 beschEftigen sich mit den
- im Usenet umfEnglich 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

* GerEte (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 schlie#lich:
de.comm.infosystems.* - WWW samt Webseitenerstellung
de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)

* de.comp.*
Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
so dazugeh%rt. Auch sie ist demnach umfangreich weiter
untergliedert, neben verschiedenen Einzelgruppen namentlich in

* Hardware:
de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks
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.* beschEftigt sich mit
FreizeitaktivitEten ("recreational activities") aller Art und
enthElt neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien
zu den Themen Musik h%ren und machen, Sport(arten), Spielen aller
Art, am Brett wie am Computer, Science Fiction und Fantasy,
Fernseh(seri)en, Filme und Heimkino und (Haus-)Tiere.

* de.sci.*
Die Unterhierarchie de.sci.* ist fnr 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 fnr Smalltalk
und entspannten Plausch als Diskussion und Informationsaustausch
vorgesehen; viele der verbliebenen Gruppen wnrden aber ebenso gut
nach de.soc.* passen.

* de.org.*
Die - gleichfalls kleine - Teilhierarchie de.org.* ist fnr
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 geh%ren das Bahnwesen, Autos und andere Fahrzeuge,
Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
Notfallrettung und MilitErwesen oder auch die Haushaltsfnhrung.

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 aussagekrEftig und allgemeinverstEndlich,
aber zugleich auch so kurz wie m%glich gewEhlt werden. Kryptische oder mehrdeutige Abknrzungen sollte man m%glichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, spEtestens aber in der Charta erlEutert werden.

Fnr die Wahl des Gruppennamens sind zudem technisch geprEgte
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 dnrfen nicht lEnger als 30 Zeichen werden und
mnssen mindestens je einen Buchstaben enthalten. Zu beachten ist
dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene
schon vor dem 15. Zeichen unterscheiden mnssen.

* 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 LEnge des Gruppennamens 71 Zeichen nicht
nberschreiten.

[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 ErgEnzung zum Gruppennamen das Thema kurz umrei#en. Im Gegensatz zur Charta, der ausfnhrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
gEngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelmE#ig versandten Steuernachrichten, die den aktuellen Gruppenbestand von de.*
enthalten.

Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muss kurz, knapp und fnr jeden verstEndlich sein. "Diskussion
nber" oder "Informationen von" sind zum Beispiel notorisch
nberflnssige Formulierungen. Hingegen sollten m%glichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer m%glicherweise suchen werden. Da die
Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die meist auf 80 Spalten breiten
Terminals gelesen werden, ergibt sich eine BeschrEnkung fnr die LEnge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt fnr die Kurzbeschreibung gew%hnlich eine MaximallEnge
von 60 Zeichen.

Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze Kurzbeschreibung anzeigen, wird er sich nblicherweise auf den Anfang
der Kurzbeschreibung beschrEnken. 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 fnr Kurzbeschreibungen finden sich in dem bereits genannten
Text "Die Newsgruppen der de-Hierarchie".

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

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

Es ist hilfreich, fnr das Thema der Gruppe einige Beispiele als nicht abschlie#ende AufzEhlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen m%glicherweise gesucht wird.
Dabei ist aber zu berncksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW ver%ffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfngung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl m%glicherweise Name und
Kurzbeschreibung bei flnchtiger Durchsicht zu dieser Annahme fnhren
k%nnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrncklich auszuschlie#en. Genauso sollte innerhalb der
Charta das Diskussionsthema von anderen, themenverwandten Gruppen
abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
nicht tunlich, weil ansonsten bei jeder Umbenennung oder L%schung der betreffenden Gruppen eine ChartaEnderung n%tig wnrde (siehe 7.3.).

Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
gelten sollen als sonst im Netz nblich sollte auch dies in der Charta
vermerkt werden. Zu denken wEre bspw. an die (ausdrnckliche) Akzeptanz
anonymer BeitrEge oder von Inseraten. Gleichfalls sollten vorgesehene ungewohnte technische Ma#nahmen - zu denken wEre hier bspw. an die EingangsbestEtigung von Postings per E-Mail durch die sog. Reflektoren
in den Testgruppen - durch die Charta legitimiert werden. In allen
diesen FEllen sollte einerseits berncksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdrncklich abgelehnt wird, sowohl wegen der unn%tigen VerlEngerung der Charta als auch, weil dies den Eindruck vermitteln
k%nnte, die entsprechenden Regeln und Konventionen hEtten nur dort
Geltung, wo sie ausdrncklich 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 Grnnde haben und zudem als feststehende Gewohnheiten betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut begrnndeten SonderfEllen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie m%glich gehalten werden; weitergehende ErlEuterungen und solche Regeln, die sich voraussichtlich hEufiger
Endern werden, geh%ren nicht in die Charta, sondern sollten Gegenstand
einer (regelmE#ig geposteten und nach M%glichkeit auch im WWW
bereitgestellten) Einfnhrung, 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 ErwEhnung finden;
die einzelnen angedachten Tags geh%ren dann in eine anderweitig
bereitgestellte ErlEuterung. Auch das Moderationskonzept einer
moderierten Gruppe geh%rt schon aufgrund seiner LEnge 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 Gefnhl fnr die Abfassung einer guten Charta zu
bekommen. Solche Beispiele finden sich in dem bereits genannten Text
"Die Newsgruppen der de-Hierarchie".

2.4. Status
-----------

Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status "moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
dann ohne weiteres in der Newsgroup ver%ffentlicht und weltweit
verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
stattdessen versendet der Newsserver, bei dem das Posting eingespeist
wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
mehrk%pfige Moderation). Diese entscheidet dann nber die
Ver%ffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
#bersichtlichkeit und h%heren inhaltlichen QualitEt, weil BeitrEge
vorgefiltert werden k%nnen; ihr Nachteil ist die zwangslEufig
entstehende Verz%gerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn bestEtigen muss. Sie eignen sich daher vor
allem fnr Anknndigungen oder FAQs. Ein Beispiel hierfnr ist de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen ver%ffentlicht werden, so dass die Gruppe auch fnr
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige #berprnfung der
Ver%ffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte ver%ffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer h%heren inhaltlichen QualitEt dienen und erm%glicht
vor allem den Ausschluss von bewussten St%rern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegrnndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden Verz%gerungen vor Ver%ffentlichung eines Beitrags den Fluss der
Diskussion st%ren und an Ver%ffentlichung ihrer BeitrEge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschEtzen; 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 BeitrEge so zeitnah wie
m%glich zu prnfen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zusEtzliche Angaben zur Moderation zu machen;
dazu geh%ren der oder die vorgesehene(n) Moderator(en) und die Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
fnr die Newsgroup zur Freigabe weitergeleitet werden sollen. Au#erdem
muss die Kurzbeschreibung entsprechend ergEnzt werden. Schlie#lich
sollte fnr die Durchfnhrung der Moderation sinnvollerweise ein Konzept vorliegen und die technischen Voraussetzungen geschaffen und getestet
sein.

* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
Ver%ffentlichung des Vorschlags seine entsprechende Bereitschaft
erklErt haben; in der Regel wird es sich empfehlen, ein mehrk%pfiges
Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
auch im Falle eines mehrw%chigen Urlaubs oder gar eines dauerhaften
Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
interessiert sein mag - die Moderation handlungsfEhig bleibt und
BeitrEge weiterhin ver%ffentlicht werden k%nnen. Fnr moderierte
Diskussionsgruppen wird regelmE#ig ein ausreichend gro#es Team
zwingend vorzusehen sein, damit BeitrEge zumindest tagsnber zeitnah
ver%ffentlicht werden k%nnen.

Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
Einreichungen bewerten zu k%nnen, von den zu erwartenden
Diskussionsteilnehmern akzeptiert werden und schlie#lich absehbar
fnr lEngere Zeit fnr diese TEtigkeit zur Verfngung stehen. Erfahrung
im Usenet und ggf. die notwendigen technischen Kenntnisse zur
Durchfnhrung der Moderation sind hilfreich.

* Wenn die (erste) Moderation personell feststeht, stellt sich als
nEchstes die Frage, welche E-Mail-Adresse fnr Einreichungen
("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
in jedem Newsserver oder an einer zentralen Stelle (den Relays fnr
moderators.isc.org) in der Konfiguration vermerkt werden, sollte
sich also so selten wie m%glich Endern; au#erdem sollte die Adresse
zuverlEssig erreichbar sein und ggf. die M%glichkeit fnr
ausreichende Spamfilterung bieten; langjEhrig aktive und regelmE#ig
ver%ffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
Spam an.

Daneben sollte eine weitere Adresse ver%ffentlicht werden, nber die
der Moderator oder die Moderation kontaktiert werden k%nnen, ohne
dass eine Ver%ffentlichung erfolgt, um bspw. fnr Anfragen erreichbar
sein.

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

* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
welchen Kriterien BeitrEge akzeptiert oder zurnckgewiesen werden, ob
sie ggf. verEndert ver%ffentlicht werden k%nnen und wie mit
Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
mehrk%pfigen Moderation stellt dies eine einheitliche Handhabung
sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
werden und danach (regelmE#ig) ver%ffentlicht werden.

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

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
M%glichkeit, einen per E-Mail nbersandten Beitrag unter Beibehaltung
der wesentlichen Informationen auch im Header - aber unter Wegfall
mancher und ErgEnzung anderer Headerzeilen - als Posting zu
ver%ffentlichen. Insbesondere dann, wenn mehr als eine Person -
parallel - an der Moderation beteiligt sein soll (was sich
mittlerweile als Regelfall etabliert haben dnrfte), empfiehlt es
sich, das entsprechende Zusammenwirken auch technisch zu
unterstntzen. In der Regel wird die Moderation einer Newsgroup also
die Installation entsprechender Software auf dem eigenen Rechner
oder sogar die Einrichtung auf einem nbers 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 Verfngung zu stellen. Die Auswahl und Erprobung der
vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
Kontaktaufnahmen sollten aber spEtestens parallel zum laufenden
Einrichtungsverfahren erfolgen; Tests k%nnen bspw. in der Newsgroup
de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<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 nber 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. SonderfElle
----------------

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

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

Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe fnr
Ausrnstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
eingerichtet werden. Dies geschieht regelmE#ig durch Umbenennung der
bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
also auch dazu Informationen enthalten.

* Einrichtung einer neuen Teilhierarchie

Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
vorgeschlagen werden soll, sondern direkt mehrere, thematisch
zusammenhEngende, also auf diese Weise eine neue Teilhierachie
entsteht.

Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
"de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
mit K%dern zu tun haben. Die entsprechenden Informationen - Name,
Kurzbeschreibung, Charta - mnssen 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 fnr
alle Gruppen die notwendigen Informationen bereitstellen.

Zu berncksichtigen ist, dass VorschlEge grundsEtzlich nicht "en
bloc" zur Abstimmung gestellt werden k%nnen; vielmehr ist nber jeden
Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
Teil 7 folgende Vorgaben:

| #bertragbarkeit: Stimmen k%nnen nicht auf einen anderen
| Abstimmungsvorschlag nbertragen werden. Eine Stimme zEhlt nur fnr
| GENAU DEN Vorschlag, fnr den sie abgegeben wurde. Insbesondere
| darf eine Stimme fnr oder gegen eine Newsgruppe mit einem
| bestimmten Namen NICHT als Stimme fnr 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 gezEhlt
| werden. #ber jede Gruppe wird einzeln abgestimmt, Verknnpfungen
| von Wahlen sind nicht m%glich.

* Diskussion mehrerer Alternativen

Ziel der Diskussion sollte es regelmE#ig sein, am Ende der
Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
Das schlie#t nicht aus, in der Diskussion zunEchst mehrere denkbare
Alternativen vorzuschlagen; die Diskussion sollte aber schlie#lich
zu einem mehrheitsfEhigen Vorschlag fnhren. Ggf. kann dazu auch ein
unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
sich ausschlie#ende Alternativen zur Abstimmung zu stellen sollte
nach M%glichkeit vermieden werden, weil die Abstimmung sonst
einerseits schnell sehr kompliziert wird und andererseits die Gefahr
besteht, dass entweder kein Vorschlag eine Mehrheit erhElt (obwohl
die Mehrzahl der Abstimmenden durchaus generell fnr eine Einrichtung
der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
VorschlEgen angenommen wird, das so niemand gewollt hat.

Die fnr die Abstimmung in diesem Fall zu beachtenden Regeln fnr
"kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
und lauten folgenderma#en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h%chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird nber die Einrichtung jeder einzelnen Gruppe gemE# den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zusEtzlich 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 VerhEltnis Zustimmung : Ablehnung aufweist.

Siehe dazu auch:

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf D%blitz <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 Vornberlegungen abgeschlossen sind, kann das "offizielle" Einrichtungsverfahren mit der Abfassung eines f%rmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prnfung ver%ffentlicht wird.

3.1. Inhalt und Aufbau eines RfD
--------------------------------

3.1.1. Inhalt

Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
2. dargestellten notwendigen Informationen und einer Begrnndung des Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit fnr die bzw. dem Erfolg der
vorgeschlagenen neuen Gruppe zu nberzeugen.

#blicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begrnndung, die den Hintergrund fnr den Vorschlag und die #berlegungen insbesondere zu den bereits oben unter 1. ("Vornberlegungen")
genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
Monaten vorzunehmen ("Trafficnachweis"). Au#erdem enthElt der RfD
natnrlich 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 fnr die Kommunikation mit der Moderation von de.admin.news.announce und fnr
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.

Schlie#lich ist auch zu entscheiden, in welchen Gruppen der RfD
ver%ffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zusEtzlich 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 eingeschrEnkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natnrlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
stattfinden oder in denen man sich Interessen an der neuen Gruppe
erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
m%glich und nur so lang wie n%tig sein sollte; dies schon deshalb,
weil in nbermE#ig viele Gruppen verteilte Postings heutzutage
m%glicherweise als Spam ausgefiltert werden.

Eine Ver%ffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im EinverstEndnis mit deren Moderation. In Gruppen au#erhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.E. kann der Proponent nach Ver%ffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") ver%ffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden k%nnen.

3.1.2. Formale Gestaltung

Fnr die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich #blichkeiten entwickelt. Es empfiehlt
sich auch hier, einige Eltere 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 / Begrnndung
| ----------- ----------
|
| [Begrnndung, 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 nbermittelt
werden, in denen der RfD ver%ffentlicht werden soll. Der RfD kann auch
bereits einschlie#lich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehEngte Textdatei, nbermittelt
werden.

#blicherweise wird die Moderation den Eingang des RfD bestEtigen und
ihn in den w%chentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation ver%ffentlicht wird. Danach wird ein Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
nberprnft, ggf. Rncksprache mit dem oder den Proponenten nimmt und ihn schlie#lich in de.admin.news.announce und den nbrigen Gruppen
ver%ffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, k%nnen diese in der Regel mit dem Verfahrensbetreuer diskutiert und geklErt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben nblicherweise bereits lEngerfristige Erfahrungen mit de.* und dem Einrichtungsverfahren gesammelt und k%nnen daher im Zweifel Tips und
Hinweise geben oder beratend tEtig 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: <2022-08-26> Moderationskonzept der derzeitigen Moderation
<https://dana.de/modkonzept.html>

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

Nachdem die Moderation den RfD ver%ffentlicht hat, findet in de.admin.news.groups die Diskussion nber den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf EinwEnde und Kritik eingehen und ggf. ihre
Begrnndung verfeinern.

HEufig wird die Diskussion sinnvolle ErgEnzungen zum ursprnnglichen
Vorschlag bringen, die in einen neuen, geEnderten Vorschlag
eingearbeitet werden k%nnen. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur Ver%ffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begrnndung, warum welche VorschlEge aufgenommen oder
verworfen wurden, enthElt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, k%nnen auch mehrere weitere RfDs ver%ffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unn%tig verlEngert oder verz%gert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu ver%ffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden VerbesserungsvorschlEge 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 VorschlEge und
-nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen geEnderten Vorschlag als
weiteren RfD zu ver%ffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
m%glichst konstruktiv gefnhrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer ausschlie#lich erfreulich sein wird; de.admin.news.groups ist auch
insofern ein Spiegel des Usenets als es dort neben gutwilligen
Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden Teilnehmern auch starrk%pfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. #berleitung zur Abstimmung oder Rnckzug des Vorschlags -----------------------------------------------------------

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

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgnltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten ver%ffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen nbereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
-nderungen zu ver%ffentlichen.

Nach M%glichkeit sollte am Ende der Diskussion nur noch ein einziger, einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls mnssen aber
fnr 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 nber einen Vorschlag findet per E-Mail statt. Die
abgegebenen Stimmen werden wEhrend des Abstimmungszeitraums an die E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszEhlt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer ver%ffentlicht. Die Durchfnhrung 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 Durchfnhrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu nberlassen.

4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung ----------------------------------------------------------

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

* Fnr die Durchfnhrung der Abstimmung ben%tigt man einen
E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
nach M%glichkeit nicht mit der "normalen" E-Mail-Adresse des
Abstimmungsleiters identisch sein, damit keine MissverstEndnisse
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 fnhren,
dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
von Webhosting- oder Internetzugangsanbietern.

Siehe dazu auch:

+ Zu Abstimmadressen und Filtermassnahmen
| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
| Filterma#nahmen bei der Durchfnhrung 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 dafnr geeignete Software zu verwenden,
die PlausibilitEtsprnfungen vornimmt, BestEtigungen per E-Mail
versenden kann und Auswertungen automatisch erstellt.

Die verbreitetste Softwarel%sung dafnr ist UseVote; mehr
Informationen dazu und eine Downloadm%glichkeit gibt es auf
<http://www.usevote.de/>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
haben sich einige regelmE#ige Teilnehmer in de.admin.news.* dazu
bereiterklErt, ungefilterte Abstimmungsaccounts einzurichten und die
eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.E.
zu erm%glichen. Dazu zEhlen (Stand 04/2011) u.a.

- Ralph Angenendt <ihr.name@strg-alt-entf.org>
- Ralf D%blitz <doeblitz@doeblitz.net>
- Karsten Dnsterloh <kd-usenet@tprac.de>
- Michael Grimm <trashcan@odo.in-berlin.de>
- Emil Schuster <emil@wieslauf.sub.de>

Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
abzustimmen.

* Daneben besteht auch die M%glichkeit, die Abstimmung gar nicht
selbst durchzufnhren, sondern damit einen Dritten zu beauftragen,
der weitergehende technische M%glichkeiten oder gr%#ere Erfahrungen
mit der Durchfnhrung von Abstimmungen hat. #berdies ist es zwar
zulEssig und auch der von den Einrichtungsregeln ursprnnglich
vorgesehene Regelfall, dass der Proponent auch die Abstimmung
durchfnhrt, manchmal ist es aber erwnnscht, damit einen unabhEngigen
Dritten zu beauftragen.

Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
erfahrene Votetaker haben sich nberdies 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, fnr ihn die Abstimmung durchzufnhren. In den letzten
Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
Mitglieder der GVV durchgefnhrt.

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 fnr 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 fnr die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.

Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
h%chstens einen Monat betragen. #blicherweise wird diese Frist nicht ausgesch%pft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV ver%ffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es nblich, Abstimmungen
um Mitternacht enden zu lassen. Daher k%nnten sich bei einer
Abstimmungsdauer von einem Monat und Ver%ffentlichung des 1. CfV bspw.
um 16:30 Uhr unn%tige Diskussionen ergeben, ob damit nicht die
H%chstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) nberschritten wird.

Schlie#lich muss der CfV mit dem letzten RfD im wesentlichen
nbereinstimmen, wie Teil 6 der Einrichtungsregeln festhElt:

| 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
| nbereinstimmen.

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 AbstimmungsmodalitEten; an diesen
dnrfen keine nber die Behebung von Schreibfehlern o.E. hinausgehenden -nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor diskutierte. Eine -nderung der Begrnndung - soweit sie nberhaupt im
CfV wiederholt wird - ist hingegen regelmE#ig unproblematisch.

#blich ist es, auf Basis des letzten ver%ffentlichen RfD einen CfV zu entwerfen. Dabei kann der Begrnndungsteil geknrzt werden oder ganz
entfallen und durch einen Verweis auf die gefnhrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefngt werden dann die AbstimmungsmodalitEten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele fnr
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unnblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nEmlich als nberflnssig; bei komplexeren Abstimmungen hingegen wnrde
die Darstellung aller m%glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma#en unnbersichtlich und aufwendig,
dass regelmE#ig darauf verzichtet wird. Wenn jedoch die einzelnen Abstimmungsm%glichkeiten dargestellt werden, dann mnssen sowohl die Abstimmungsm%glichkeiten fnr wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu vermeiden.

Beispiele fnr CfVs finden sich in de.admin.news.announce. Eine
m%gliche Gestaltung wEre folgende:

| 1. CfV (Abstimmungsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begrnndung
| ----------- ----------
|
| [kurze Begrnndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| AbstimmungsmodalitEten
| ----------------------
|
| Votetaker : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein : Untenstehendes Formular ist zu verwenden. M%glich sind
| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gnltigen Fassung, die in de.admin.infos
| und unter <https://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| ver%ffentlicht sind. Sie erlEutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Hinweise zur Abstimmung und
| Informationen zur Datenverarbeitung (Art. 13 DSGVO)
| ---------------------------------------------------
|
| GezEhlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestEtigt; die komplette
| Abstimmungs-E-Mail und die Stimmdaten - Name, E-Mail-Adresse und Inhalt
| der Stimmabgabe - werden bis vier Wochen nach endgnltigem Abschluss des
| Verfahrens (Umsetzung nach Ablauf der Einspruchsfrist) beim Votetaker
| gespeichert und zur Erstellung des Ergebnisses verarbeitet.
|
| #blicherweise erfolgt eine SammelbestEtigung der bis dahin abgegebenen
| Stimmen durch Ver%ffentlichung von Namen und E-Mail-Adressen aller
| Abstimmungsteilnehmer in einem 2. CfV. Auch im nach Ende der Abstimmung
| ver%ffentlichten Ergebnis werden Namen, E-Mail-Adresse und Inhalt der
| Stimmabgabe fnr alle Abstimmenden genannt.
|
| Auf Anfrage k%nnen die gespeicherten Daten an die Moderation von
| de.admin.news.announce nbermittelt werden.
|
| Speicherung, Verarbeitung und Ver%ffentlichung sowie ggf. #bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die fnr
| eine Wertung und Ver%ffentlichung der Stimmabgabe entsprechend des
| Hinweises im Wahlschein notwendig ist. Die Einwilligung kann jederzeit
| durch Mitteilung per E-Mail an den Votetaker mit Wirkung fnr die Zukunft
| widerrufen werden. Die Wertung und Ver%ffentlichung 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#e Auswertung der Abstimmung nachweisen
| zu k%nnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft nber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - L%schung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - EinschrEnkung der Datenverarbeitung gemE# Art. 18 DSGVO
| - Datennbertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zustEndigen Aufsichtsbeh%rde nach Art. 77 DSGVO
|
| Diese Rechte k%nnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| ZustEndige Aufsichtsbeh%rde ist in diesem Fall [Aufsichtsbeh%rde].
|
| =-=-=-=-=-=-=-=- 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 M%glichkeit vorzusehen, den
tatsEchlichen Namen anzugeben, da m%glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
geh%rt die Liste der Gruppen dazu, in denen der RfD ver%ffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlie#lich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehEngte Textdatei,
nbermittelt werden.

Die Ver%ffentlichung des CfVs wird nblicherweise lEnger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von de.admin.news.announce nach dem 4-Augen-Prinzip nberprnft wird. Daher
kann - und sollte - der 1. CfV ruhig m%glichst frnhzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Ver%ffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Sonderfall: CfV mit pers%nlichem Wahlschein ------------------------------------------------

ErgEnzend zu der nblichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthElt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die M%glichkeit einer Abstimmung unter Verwendung pers%nlicher Wahlscheine vor.

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

Diese Vorgehensweise soll u.a. verhindern, dass vorausgefnllte
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 gnltig sein, d.h. E-Mails entgegennehmen muss, nberprnfbar - denn nur wer eine gnltige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.

Da allerdings weiterhin andere Manipulationsm%glichkeiten verbleiben
und der Aufwand fnr die Durchfnhrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgefnhrt.

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

[5] Der Vorschlag und die entsprechende Begrnndung 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
---------------------

WEhrend der drei- oder vierw%chigen (maximal aber einmonatigen) Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach M%glichkeit einigerma#en
zeitnah, am besten automatisiert - per E-Mail bestEtigt werden; in
dieser BestEtigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse fnr den Abstimmenden registriert wurden.
Fnr Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die BestEtigung versandt werden, um sicherzustellen, dass diese Stimme auch tatsEchlich vom angegebenen
Absender stammte (und die Abstimmadresse replyfEhig ist, d.h. E-Mail
dort empfangen werden kann). Au#erdem sollte in der BestEtigung
angegeben sein, wie eine Stimme nachtrEglich geEndert oder komplett zurnckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet ver%ffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es nblich, einen 2. CfV zu ver%ffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die Stimmabgaben!) enthElt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ungnltig gewertet werden. Weil auch der 2.
CfV im Rahmen der nblichen Bearbeitungszeiten regelmE#ig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen ver%ffentlicht werden
wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei
Tage vor dem geplanten Ver%ffentlichungszeitraum einzureichen.

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

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

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

Dabei werden zunEchst die JA- und NEIN-Stimmen sowie Enthaltungen
gezEhlt. 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 Rncksprache 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 genngen (Angabe eines falschen oder nicht
vollstEndigen Namens, nicht replyfEhige Abstimmadresse), dnrfen nicht
gewertet werden. Der Votetaker sollte auch die M%glichkeit von Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
IdentitEten, Weitergabe des Wahlscheins au#erhalb der Gruppen, in
denen er ver%ffentlicht wurde, Beeinflussung der Abstimmung durch "Campaigning") im Auge behalten und entsprechende #berprnfungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern geklErt 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 frnheren ZweifelsfEllen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung nber den konkret entschiedenen
Einzelfall hinaus haben und nicht spEter revidiert wurden, unter <https://www.dana.de/archiv.html> auch im Web ver%ffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, berncksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver%ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrnckliche EinwilligungserklErungen erforderlich sind.

Danach ist eine Ergebnisver%ffentlichung ("Result") vorzubereiten.
#blich ist es, die Gesamtzahl der gnltigen Stimmen und sodann fnr
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungnltigen 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 Ver%ffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungnltige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begrnndung fnr die Nichtwertung. Dies erm%glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen FEllen kann die Ver%ffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dnrfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Grnnden die Verwendung von Pseudonymen
akzeptiert wird.

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

Mit der Ver%ffentlichung des Results durch die Moderation von de.admin.news.announce beginnt eine einw%chige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begrnndung einlegen kann, dass
bei der Durchfnhrung der Abstimmung schwerwiegende UnregelmE#igkeiten
gab. Das k%nnen bspw. technische Probleme mit der Abstimmadresse sein,
die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
oder einer der bereits unter 4.5. angerissenen Manipulationsversuche.

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskrEftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die nblicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* fnhren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergEnzen.

Ansonsten wird die Moderation nber eingegangene Einsprnche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das ver%ffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
wenn nber den Einspruch abschlie#end entschieden ist.

Das Einrichtungsverfahren ist damit beendet.

6. Sonderfall: Vereinfachtes Verfahren (VV) ===========================================

Nicht jeder marginale -nderungsvorschlag muss zwingend das vorstehend geschilderte umfangreiche Verfahren nach sich ziehen. Fnr kleinere
-nderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. "Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und Abstimmungsphase zugunsten einer Widerspruchsl%sung entfallen.

Bei einem VV wird der entsprechende -nderungsvorschlag, der dieselben Anforderungen wie ein RfD erfnllen muss (siehe 3.1.), zur
Ver%ffentlichung in de.admin.news.announce bei <moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darnber
hinaus ausdrncklich darauf hinweisen, dass die vorgeschlagene -nderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.

Nach Abschluss der Widerspruchsfrist stellt die Moderation von de.admin.news.announce entweder fest, dass kein Widerspruch
eingegangen ist und der Vorschlag angenommen wurde, oder
ver%ffentlicht Namen und E-Mail-Adresse der Widerspruchsfnhrer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgefnhrt oder aufgegeben
werden.

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

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E. ==============================================================

Bereits die Einleitung ("#bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" trEgt und sich die Ausfnhrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschEftigen, sie
aber fnr alle -nderungen am Gruppenbestand analog gelten und auch fnr
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden k%nnen (und regelmE#ig auch angewendet werden):

| Diese Spielregeln gelten fnr 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
| herbeizufnhren.
|
| 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 Grnndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschEftigen. Je gr%#er die Hierarchie wurde (und je stErker
die Nutzerzahlen wieder zurnckgingen), desto hEufiger wurden dann
-nderungs- und L%schungsverfahren, aber auch RegelEnderungen.

GrundsEtzlich ist die Vorgehensweise in diesen FEllen den
Einrichtungsverfahren vergleichbar, insbesondere die
BegrnndungsansEtze sind aber freilich andere.

7.1. Gruppenl%schungen
----------------------

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

* Insofern wird die Begrnndung eines L%schungsvorschlags in der Regel
primEr auf eine statistische Auswertung nber einen lEngeren Zeitraum
(mindestens 12 Monate, im Zweifel aber auch lEnger) gestntzt, um zu
belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
Bereich abrutscht, k%nnen niedrige Nutzungszahlen nur ein Hinweis
auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
AnlEsse reagiert und die Gruppe wieder mit Leben fnllt. Das spricht
eher gegen eine L%schung der Gruppe.

[6] <http://usenet.dex.de/>

* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
zur L%schung vorgeschlagenen Gruppe zuknnftig diskutiert werden
sollen. Wenn die Gruppe in einem gr%#eren thematischen Zusammenhang
steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
benennen, was dann wiederum fnr eine niedrigere Schwelle zur
L%schung spricht, denn so werden einzelne, mittlerweile weniger
intensiv diskutierte Unterbereiche eines gr%#eren Themas wieder
thematisch zusammengefasst.

Ein Beispiel dafnr wEre die Teilhierarchie
de.comp.office-pakete.ms-office.*, die ursprnnglich 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,
wnrde eine L%schung 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, fnr
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 FEllen ist eine
besonders kritische Prnfung erforderlich, ob sich die Gruppe nicht
wieder beleben lEsst, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema v%llig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur L%schung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

* Wenn die letzte Gruppe einer Teilhierarchie gel%scht wird, stellt
sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
Teilhierarchie").

So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
Gruppen

- de.comm.protocols.tcp-ip
- de.comm.protocols.misc

Wnrde man die Gruppe de.comm.protocols.tcp-ip l%schen, k%nnte man
die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
de.comm.protocols umbenennen, um so den Namen zu verknrzen und die
Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
spricht, dass Umbenennungen technisch nicht m%glich sind, sondern
nur durch eine L%schung der bestehenden Gruppe und die
Neueinrichtung der Gruppe mit dem geEnderten Namen umgesetzt werden
k%nnen (siehe 7.2.).

7.2. Umbenennungen
------------------

Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
mit anderen -nderungen am Gruppenbestand. Dass eine Gruppe ohne
weiteren Anlass blo# an eine andere Stelle im Hierarchiebaum (siehe
2.1.1.) verschoben wird, ist sehr selten.

Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht m%glich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zusEtzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefEhr eine Woche spEter von der
L%schung der Gruppe mit dem alten Namen. Dies fnhrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmE#ig in die
Gruppe hineinschauen, sie dann pl%tzlich nicht mehr finden k%nnen.
Eine solche Umbenennung will also wohlnberlegt sein.

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

Neben dem Namen k%nnen auch alle anderen Attribute einer Gruppe (fnr
deren Beschreibung siehe 2.) geEndert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene ChartaEnderung die Folge einer
Reorganisation, also der Einrichtung oder L%schung anderer Gruppen, so
dass klarstellende -nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gel%schten
oder sonstwie geEnderten Newsgroups aus der Charta entfernt werden
mnssen. 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 KurzbeschreibungsEnderung ist dabei im wesentlichen
kein technischer Vorgang. GeEnderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden k%nnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden ChartaEnderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. StatusEnderungen
---------------------

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

Soll eine bisher unmoderierte Gruppe zuknnftig moderiert sein, fnhrt
dies dazu, dass Postings nber Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
fnhren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuknnftig 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 BeitrEge
verloren gehen.

Diese technischen Probleme mnssen bereits in der Diskussionsphase berncksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zusEtzlichen 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 zusEtzlichen ErwEgungen
fnr die Einrichtung moderierter Gruppen entsprechend.

7.5. RegelEnderungen und Personenwahlen
---------------------------------------

Neben -nderungen am Gruppenbestand k%nnen - und werden - die
Einrichtungsregeln analog auch fnr andere Entscheiungen (bspw. die
-nderung der Einrichtungsregeln selbst) herangezogen.

Sie gelten - teilweise modifiziert - auch fnr Personenwahlen, bspw.
fnr die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmE#igen AbstEnden
durchgefnhrten Nachwahlen [8]. In gleicher Weise wEre es auch m%glich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlie#en oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
nbergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - nbersteuert werden.

[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos ver%ffentlicht sind:
| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter)
| Newsgroups: de.admin.infos,de.admin.news.misc
| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
|
| Archive-name: de-admin/dana-neuwahl
| Posting-frequency: weekly
| Last-modified: 1998-05-18
| URL: 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
regelmE#ig in de.admin.news.announce ver%ffentlicht wird:
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2022-08-26> 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 ErlEuterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise ergEnzt.

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. Weiterfnhrende Hinweise
----------------------------

Folgende Texte sind allgemein oder fnr 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: <2022-08-26> 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 D%blitz <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

+ Filterma#nahmen bei der Durchfnhrung 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 nber 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 k%nnen bei der Durchfnhrung des Einrichtungsverfahrens helfen:

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

+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
w%chentlich ver%ffentlicht in de.admin.news.announce
<https://www.dana.de/status.html>

+ GVV-Statusnbersicht
<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 MErz/April 2011 vollstEndig nberarbeitet und
neu gefasst.

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

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

Fnr Hinweise, Anregungen und VerbesserungsvorschlEge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frnhere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprnnglichen Fassung dieses Textes und seiner Entstehung
haben au#erdem beigetragen:

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

Herzlichen Dank!
--
Id: 48a99bd (HEAD -> master, tag: 2.2.10) 2025-04-13 11:56:51 +0200 Thomas Hochstein

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.answers

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.10
Last-modified: 2025-04-13
URL: https://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

ErlEuterungen 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. Vornberlegungen
1.1. Bedarf fnr eine neue Gruppe
1.2. Status quo: bestehende Gruppen und frnhere VorschlEge
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. SonderfElle

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

4. Abstimmungsphase
4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung
4.2. Inhalt und Aufbau eines CfV
4.3. Sonderfall: CfV mit pers%nlichem Wahlschein
4.4. Abstimmungsphase
4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E.
7.1. Gruppenl%schungen
7.2. Umbenennungen
7.3. -nderungen von Charta und/oder Kurzbeschreibung
7.4. StatusEnderungen
7.5. RegelEnderungen und Personenwahlen

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

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

[1] Ver%ffentlicht 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 ErlEuterungen genannten Quellen findet
sich noch einmal in Abschnitt 8.)

Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
nachfolgende, mindestens einw%chige Diskussion keinen gar zu heftigen Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im #berblick -------------------------------------------

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

Fnr de.* wird die kanonische Liste der bestehenden Newsgroups von der Moderation von de.admin.news.announce gefnhrt, die jeden Monat auch
eine entsprechende, digital signierte Steuernachricht (checkgroups)
versendet, mit der die meisten Newsserverbetreiber ihren
Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
Fnr die Aufstellung dieser Liste sind vielerlei M%glichkeiten denkbar;
in de.* entscheiden die Benutzer nber ihren Inhalt. -nderungen am Gruppenbestand - Neueinrichtung, L%schung oder Umbenennung von Gruppen
- werden in einem formalisierten Verfahren diskutiert und dann zur
Abstimmung gestellt.

Jedem Einrichtungsvorschlag sollte eine #berlegungsphase vorangehen,
in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
Status, Charta) einschlie#lich ihrer Einordnung in den bestehenden, hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden k%nnen. Am Ende dieser Vornberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe hei#en soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegennber bestehenden Gruppen abgrenzt. Mit der
Ver%ffentlichung dieses Vorschlags in de.admin.news.announce als Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
die in de.admin.news.groups gefnhrt wird, wird der Vorschlag auf
inhaltliche QualitEt und Akzeptanz abgeklopft und ggf. verEndert oder verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der Vorschlag abstimmungsreif erscheint. Die Ver%ffentlichung eines Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die Diskussionsphase und leitet in die Abstimmungsphase nber, 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 lEsst sich in folgende Phasen unterteilen,
die im Folgenden dann nEher erlEutert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information nber den status quo, BedarfsabschEtzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines f%rmlichen Einrichtungsvorschlag (RfD)
* Einreichung des RfD bei der Moderation von de.admin.news.announce

Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
enden die Vorbereitungen; das Verfahren wird in die Statusnbersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erhElt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prnft
den RfD (und die weiteren VerfahrensbeitrEge) auf Vereinbarkeit mit
den Regeln, nimmt die n%tigen Ver%ffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) fnr sich im Verlauf
des Verfahrens ergebende Fragen zur Verfngung.

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

0.3.2. Diskussionsphase

* Beginn mit Ver%ffentlichung des 1. RfD in de.admin.news.announce,
de.admin.news.groups und weiteren betroffenen Newsgroups
* %ffentliche Diskussion des Vorschlags in de.admin.news.groups
* Mindestdauer: 14 Tage
* Einreichung beliebig vieler weiterer RfDs mit geEnderten VorschlEgen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der nbrigen Teilnehmer zu ergrnnden; -nderungsvorschlEge k%nnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten er%rtert, alle
Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen m%chte oder
ob er den Vorschlag zurnckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten ver%ffentlichen RfD im Wesentlichen
nbereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
Rnckzug des Vorschlags oder Verfall durch Nichtbetreiben nber fnnf
Wochen) oder der Ver%ffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Ver%ffentlichung des 1. CfV in de.admin.news.announce und
den nbrigen Gruppen
* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
E-Mail bestEtigt
* Mindestdauer: 3 Wochen, H%chstdauer: 1 Monat (~ 4 Wochen)
* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
Abstimmenden
* einw%chige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgefnhrt, der die CfVs zur Ver%ffentlichung einreicht, die
Stimmen per E-Mail sammelt, bestEtigt und auszEhlt und am Ende das
Ergebnis der Abstimmung zur Ver%ffentlichung einreicht. Diese Aufgabe
kann der Proponent nbernehmen, er muss es aber nicht; da die
Durchfnhrung und AuszEhlung einer Abstimmung einen gewissen
technischen und organisatorischen Aufwand erfordert und auch Erfahrung
im Umgang mit ZweifelsfEllen - auch Manipulationsversuchen -
wnnschenswert ist, besteht die M%glichkeit, einen erfahrenen
Usenet-Teilnehmer um die #bernahme der Abstimmungsleitung zu bitten.
Einige Freiwillige haben sich zu diesem Zweck als "German Volunteer
Votetakers" (GVV) zusammengeschlossen.

Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und letztlich mit der Ver%ffentlichung des Ergebnisses. Daran schlie#t
sich ein einw%chiger Einspruchszeitraum an, in dem Regelverst%#e durch
einen Einspruch bemEngelt werden k%nnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskrEftig.

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 gnltigen 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. Vornberlegungen
==================

1.1. Bedarf fnr eine neue Gruppe
--------------------------------

Ganz am Anfang der #berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zunEchst die Frage, ob die angedachte Gruppe denn auch
tatsEchlich ben%tigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuknnftigen 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 nberfnllt ist.

Die zuknnftige NutzungsintensitEt der vorgeschlagenen Gruppe wird
dabei regelmE#ig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

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

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

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
zuknnftig einigerma#en intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tatsEchliche gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
und ob sie dies im Usenet tun m%chten. Es mag sehr wichtige Themen
geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
oder die anderswo diskutiert werden, ohne dass bei den Interessenten
der Wunsch besteht, ihre Diskussionen im Usenet zu fnhren. Die
mehrheitliche Ansicht geht nberdies dahin, dass es nicht sinnvoll ist,
fnr "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es nberwiegend als
wnnschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und f%rdern.

Siehe auch:

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
<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 frnhere VorschlEge ----------------------------------------------------------

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

Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
m%glicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
eine solche Gruppe, die dann spEter wieder aus der Gruppenliste
entfernt wurde? Aus diesen #berlegungen ergeben sich Hinweise auf die Erfolgsaussichten des Vorschlags und m%glicherweise auch Anregungen
fnr seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche -nderungen in Inhalt oder Begrnndung erneut einzubringen.

[3] Am bekanntesten dnrfte 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
Befnrworter 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 fnhrt oft zu besseren Ergebnissen als einsames Grnbeln im stillen KEmmerlein.

Auch in der Diskussion ist es f%rderlich, einen Vorschlag nicht
alleine argumentativ zu stntzen; nicht nur deshalb, weil eine Mehrzahl
von Interessenten, die sich auch selbst in die Diskussion einbringt, nberzeugender ein dauerhaftes Interesse signalisiert als ein
Einzelner. Auch aus psychologischen Grnnden ist es angenehmer, die
eigene Position nicht alleine vertreten zu mnssen.

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

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

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

| Ein CfV kann nicht ver%ffentlicht werden, wenn einer der folgenden
| Punkte noch unklar ist:
|
| o Name der Gruppe
| o Kurzbeschreibung der Gruppe
| o Charta der Gruppe
| o Status der Gruppe (moderiert oder unmoderiert)
| o der Name des Moderators im Falle einer moderierten Gruppe

Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
sich daher auch die Frage nach der Einordnung der neuen Gruppe in die bestehende Struktur der Hierarchie de.*, und in der Charta sollte
nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
auch die Abgrenzung zu thematisch Ehnlichen Gruppen ihren Platz
finden.

Sinnvoll ist es daher, sich zunEchst Gedanken nber 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
nberlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
demnach hei#en soll (2.1.); dann fehlt nur noch eine knackige
Zusammenfassung fnr die Kurzbeschreibung (2.2.).

Falls eine moderierte Newsgroup vorgeschlagen wird, mnssen auch der
oder die vorgesehenen Moderatoren feststehen; nberdies sollte ein
Konzept fnr die Moderation vorliegen und die technischen
Voraussetzungen hinreichend geklErt sein.

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

2.1.1. Einordnung

ZunEchst sollte die prospektive Gruppe sich in die bestehende
Namenshierarchie in de.* einpassen. de.* besteht nEmlich aus
thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
immer feineren thematischen VerEstelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollstEndig
logisch stringent, und regelmE#ig wird es nicht nur einen denkbaren
Platz geben, an den eine neue Gruppe passen wnrde.

Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
bemnhen, den bestm%glichen Ort fnr die neue Gruppe zu finden. Dazu
geh%rt sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.

Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
Einrichtungsregeln auszeichnet und daher nicht Thema dieser
ErlEuterungen 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 beschEftigen sich mit den
- im Usenet umfEnglich 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

* GerEte (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 schlie#lich:
de.comm.infosystems.* - WWW samt Webseitenerstellung
de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)

* de.comp.*
Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
so dazugeh%rt. Auch sie ist demnach umfangreich weiter
untergliedert, neben verschiedenen Einzelgruppen namentlich in

* Hardware:
de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks
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.* beschEftigt sich mit
FreizeitaktivitEten ("recreational activities") aller Art und
enthElt neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien
zu den Themen Musik h%ren und machen, Sport(arten), Spielen aller
Art, am Brett wie am Computer, Science Fiction und Fantasy,
Fernseh(seri)en, Filme und Heimkino und (Haus-)Tiere.

* de.sci.*
Die Unterhierarchie de.sci.* ist fnr 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 fnr Smalltalk
und entspannten Plausch als Diskussion und Informationsaustausch
vorgesehen; viele der verbliebenen Gruppen wnrden aber ebenso gut
nach de.soc.* passen.

* de.org.*
Die - gleichfalls kleine - Teilhierarchie de.org.* ist fnr
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 geh%ren das Bahnwesen, Autos und andere Fahrzeuge,
Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
Notfallrettung und MilitErwesen oder auch die Haushaltsfnhrung.

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 aussagekrEftig und allgemeinverstEndlich,
aber zugleich auch so kurz wie m%glich gewEhlt werden. Kryptische oder mehrdeutige Abknrzungen sollte man m%glichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, spEtestens aber in der Charta erlEutert werden.

Fnr die Wahl des Gruppennamens sind zudem technisch geprEgte
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 dnrfen nicht lEnger als 30 Zeichen werden und
mnssen mindestens je einen Buchstaben enthalten. Zu beachten ist
dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene
schon vor dem 15. Zeichen unterscheiden mnssen.

* 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 LEnge des Gruppennamens 71 Zeichen nicht
nberschreiten.

[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 ErgEnzung zum Gruppennamen das Thema kurz umrei#en. Im Gegensatz zur Charta, der ausfnhrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
gEngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelmE#ig versandten Steuernachrichten, die den aktuellen Gruppenbestand von de.*
enthalten.

Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muss kurz, knapp und fnr jeden verstEndlich sein. "Diskussion
nber" oder "Informationen von" sind zum Beispiel notorisch
nberflnssige Formulierungen. Hingegen sollten m%glichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer m%glicherweise suchen werden. Da die
Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die meist auf 80 Spalten breiten
Terminals gelesen werden, ergibt sich eine BeschrEnkung fnr die LEnge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt fnr die Kurzbeschreibung gew%hnlich eine MaximallEnge
von 60 Zeichen.

Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze Kurzbeschreibung anzeigen, wird er sich nblicherweise auf den Anfang
der Kurzbeschreibung beschrEnken. 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 fnr Kurzbeschreibungen finden sich in dem bereits genannten
Text "Die Newsgruppen der de-Hierarchie".

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

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

Es ist hilfreich, fnr das Thema der Gruppe einige Beispiele als nicht abschlie#ende AufzEhlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen m%glicherweise gesucht wird.
Dabei ist aber zu berncksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW ver%ffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfngung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl m%glicherweise Name und
Kurzbeschreibung bei flnchtiger Durchsicht zu dieser Annahme fnhren
k%nnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrncklich auszuschlie#en. Genauso sollte innerhalb der
Charta das Diskussionsthema von anderen, themenverwandten Gruppen
abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
nicht tunlich, weil ansonsten bei jeder Umbenennung oder L%schung der betreffenden Gruppen eine ChartaEnderung n%tig wnrde (siehe 7.3.).

Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
gelten sollen als sonst im Netz nblich sollte auch dies in der Charta
vermerkt werden. Zu denken wEre bspw. an die (ausdrnckliche) Akzeptanz
anonymer BeitrEge oder von Inseraten. Gleichfalls sollten vorgesehene ungewohnte technische Ma#nahmen - zu denken wEre hier bspw. an die EingangsbestEtigung von Postings per E-Mail durch die sog. Reflektoren
in den Testgruppen - durch die Charta legitimiert werden. In allen
diesen FEllen sollte einerseits berncksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdrncklich abgelehnt wird, sowohl wegen der unn%tigen VerlEngerung der Charta als auch, weil dies den Eindruck vermitteln
k%nnte, die entsprechenden Regeln und Konventionen hEtten nur dort
Geltung, wo sie ausdrncklich 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 Grnnde haben und zudem als feststehende Gewohnheiten betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut begrnndeten SonderfEllen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie m%glich gehalten werden; weitergehende ErlEuterungen und solche Regeln, die sich voraussichtlich hEufiger
Endern werden, geh%ren nicht in die Charta, sondern sollten Gegenstand
einer (regelmE#ig geposteten und nach M%glichkeit auch im WWW
bereitgestellten) Einfnhrung, 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 ErwEhnung finden;
die einzelnen angedachten Tags geh%ren dann in eine anderweitig
bereitgestellte ErlEuterung. Auch das Moderationskonzept einer
moderierten Gruppe geh%rt schon aufgrund seiner LEnge 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 Gefnhl fnr die Abfassung einer guten Charta zu
bekommen. Solche Beispiele finden sich in dem bereits genannten Text
"Die Newsgruppen der de-Hierarchie".

2.4. Status
-----------

Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status "moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
dann ohne weiteres in der Newsgroup ver%ffentlicht und weltweit
verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
stattdessen versendet der Newsserver, bei dem das Posting eingespeist
wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
mehrk%pfige Moderation). Diese entscheidet dann nber die
Ver%ffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
#bersichtlichkeit und h%heren inhaltlichen QualitEt, weil BeitrEge
vorgefiltert werden k%nnen; ihr Nachteil ist die zwangslEufig
entstehende Verz%gerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn bestEtigen muss. Sie eignen sich daher vor
allem fnr Anknndigungen oder FAQs. Ein Beispiel hierfnr ist de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen ver%ffentlicht werden, so dass die Gruppe auch fnr
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige #berprnfung der
Ver%ffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte ver%ffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer h%heren inhaltlichen QualitEt dienen und erm%glicht
vor allem den Ausschluss von bewussten St%rern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegrnndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden Verz%gerungen vor Ver%ffentlichung eines Beitrags den Fluss der
Diskussion st%ren und an Ver%ffentlichung ihrer BeitrEge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschEtzen; 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 BeitrEge so zeitnah wie
m%glich zu prnfen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zusEtzliche Angaben zur Moderation zu machen;
dazu geh%ren der oder die vorgesehene(n) Moderator(en) und die Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
fnr die Newsgroup zur Freigabe weitergeleitet werden sollen. Au#erdem
muss die Kurzbeschreibung entsprechend ergEnzt werden. Schlie#lich
sollte fnr die Durchfnhrung der Moderation sinnvollerweise ein Konzept vorliegen und die technischen Voraussetzungen geschaffen und getestet
sein.

* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
Ver%ffentlichung des Vorschlags seine entsprechende Bereitschaft
erklErt haben; in der Regel wird es sich empfehlen, ein mehrk%pfiges
Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
auch im Falle eines mehrw%chigen Urlaubs oder gar eines dauerhaften
Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
interessiert sein mag - die Moderation handlungsfEhig bleibt und
BeitrEge weiterhin ver%ffentlicht werden k%nnen. Fnr moderierte
Diskussionsgruppen wird regelmE#ig ein ausreichend gro#es Team
zwingend vorzusehen sein, damit BeitrEge zumindest tagsnber zeitnah
ver%ffentlicht werden k%nnen.

Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
Einreichungen bewerten zu k%nnen, von den zu erwartenden
Diskussionsteilnehmern akzeptiert werden und schlie#lich absehbar
fnr lEngere Zeit fnr diese TEtigkeit zur Verfngung stehen. Erfahrung
im Usenet und ggf. die notwendigen technischen Kenntnisse zur
Durchfnhrung der Moderation sind hilfreich.

* Wenn die (erste) Moderation personell feststeht, stellt sich als
nEchstes die Frage, welche E-Mail-Adresse fnr Einreichungen
("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
in jedem Newsserver oder an einer zentralen Stelle (den Relays fnr
moderators.isc.org) in der Konfiguration vermerkt werden, sollte
sich also so selten wie m%glich Endern; au#erdem sollte die Adresse
zuverlEssig erreichbar sein und ggf. die M%glichkeit fnr
ausreichende Spamfilterung bieten; langjEhrig aktive und regelmE#ig
ver%ffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
Spam an.

Daneben sollte eine weitere Adresse ver%ffentlicht werden, nber die
der Moderator oder die Moderation kontaktiert werden k%nnen, ohne
dass eine Ver%ffentlichung erfolgt, um bspw. fnr Anfragen erreichbar
sein.

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

* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
welchen Kriterien BeitrEge akzeptiert oder zurnckgewiesen werden, ob
sie ggf. verEndert ver%ffentlicht werden k%nnen und wie mit
Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
mehrk%pfigen Moderation stellt dies eine einheitliche Handhabung
sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
werden und danach (regelmE#ig) ver%ffentlicht werden.

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

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
M%glichkeit, einen per E-Mail nbersandten Beitrag unter Beibehaltung
der wesentlichen Informationen auch im Header - aber unter Wegfall
mancher und ErgEnzung anderer Headerzeilen - als Posting zu
ver%ffentlichen. Insbesondere dann, wenn mehr als eine Person -
parallel - an der Moderation beteiligt sein soll (was sich
mittlerweile als Regelfall etabliert haben dnrfte), empfiehlt es
sich, das entsprechende Zusammenwirken auch technisch zu
unterstntzen. In der Regel wird die Moderation einer Newsgroup also
die Installation entsprechender Software auf dem eigenen Rechner
oder sogar die Einrichtung auf einem nbers 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 Verfngung zu stellen. Die Auswahl und Erprobung der
vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
Kontaktaufnahmen sollten aber spEtestens parallel zum laufenden
Einrichtungsverfahren erfolgen; Tests k%nnen bspw. in der Newsgroup
de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<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 nber 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. SonderfElle
----------------

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

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

Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe fnr
Ausrnstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
eingerichtet werden. Dies geschieht regelmE#ig durch Umbenennung der
bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
also auch dazu Informationen enthalten.

* Einrichtung einer neuen Teilhierarchie

Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
vorgeschlagen werden soll, sondern direkt mehrere, thematisch
zusammenhEngende, also auf diese Weise eine neue Teilhierachie
entsteht.

Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
"de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
mit K%dern zu tun haben. Die entsprechenden Informationen - Name,
Kurzbeschreibung, Charta - mnssen 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 fnr
alle Gruppen die notwendigen Informationen bereitstellen.

Zu berncksichtigen ist, dass VorschlEge grundsEtzlich nicht "en
bloc" zur Abstimmung gestellt werden k%nnen; vielmehr ist nber jeden
Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
Teil 7 folgende Vorgaben:

| #bertragbarkeit: Stimmen k%nnen nicht auf einen anderen
| Abstimmungsvorschlag nbertragen werden. Eine Stimme zEhlt nur fnr
| GENAU DEN Vorschlag, fnr den sie abgegeben wurde. Insbesondere
| darf eine Stimme fnr oder gegen eine Newsgruppe mit einem
| bestimmten Namen NICHT als Stimme fnr 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 gezEhlt
| werden. #ber jede Gruppe wird einzeln abgestimmt, Verknnpfungen
| von Wahlen sind nicht m%glich.

* Diskussion mehrerer Alternativen

Ziel der Diskussion sollte es regelmE#ig sein, am Ende der
Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
Das schlie#t nicht aus, in der Diskussion zunEchst mehrere denkbare
Alternativen vorzuschlagen; die Diskussion sollte aber schlie#lich
zu einem mehrheitsfEhigen Vorschlag fnhren. Ggf. kann dazu auch ein
unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
sich ausschlie#ende Alternativen zur Abstimmung zu stellen sollte
nach M%glichkeit vermieden werden, weil die Abstimmung sonst
einerseits schnell sehr kompliziert wird und andererseits die Gefahr
besteht, dass entweder kein Vorschlag eine Mehrheit erhElt (obwohl
die Mehrzahl der Abstimmenden durchaus generell fnr eine Einrichtung
der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
VorschlEgen angenommen wird, das so niemand gewollt hat.

Die fnr die Abstimmung in diesem Fall zu beachtenden Regeln fnr
"kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
und lauten folgenderma#en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h%chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird nber die Einrichtung jeder einzelnen Gruppe gemE# den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zusEtzlich 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 VerhEltnis Zustimmung : Ablehnung aufweist.

Siehe dazu auch:

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf D%blitz <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 Vornberlegungen abgeschlossen sind, kann das "offizielle" Einrichtungsverfahren mit der Abfassung eines f%rmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prnfung ver%ffentlicht wird.

3.1. Inhalt und Aufbau eines RfD
--------------------------------

3.1.1. Inhalt

Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
2. dargestellten notwendigen Informationen und einer Begrnndung des Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit fnr die bzw. dem Erfolg der
vorgeschlagenen neuen Gruppe zu nberzeugen.

#blicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begrnndung, die den Hintergrund fnr den Vorschlag und die #berlegungen insbesondere zu den bereits oben unter 1. ("Vornberlegungen")
genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
Monaten vorzunehmen ("Trafficnachweis"). Au#erdem enthElt der RfD
natnrlich 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 fnr die Kommunikation mit der Moderation von de.admin.news.announce und fnr
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.

Schlie#lich ist auch zu entscheiden, in welchen Gruppen der RfD
ver%ffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zusEtzlich 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 eingeschrEnkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natnrlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
stattfinden oder in denen man sich Interessen an der neuen Gruppe
erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
m%glich und nur so lang wie n%tig sein sollte; dies schon deshalb,
weil in nbermE#ig viele Gruppen verteilte Postings heutzutage
m%glicherweise als Spam ausgefiltert werden.

Eine Ver%ffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im EinverstEndnis mit deren Moderation. In Gruppen au#erhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.E. kann der Proponent nach Ver%ffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") ver%ffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden k%nnen.

3.1.2. Formale Gestaltung

Fnr die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich #blichkeiten entwickelt. Es empfiehlt
sich auch hier, einige Eltere 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 / Begrnndung
| ----------- ----------
|
| [Begrnndung, 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 nbermittelt
werden, in denen der RfD ver%ffentlicht werden soll. Der RfD kann auch
bereits einschlie#lich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehEngte Textdatei, nbermittelt
werden.

#blicherweise wird die Moderation den Eingang des RfD bestEtigen und
ihn in den w%chentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation ver%ffentlicht wird. Danach wird ein Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
nberprnft, ggf. Rncksprache mit dem oder den Proponenten nimmt und ihn schlie#lich in de.admin.news.announce und den nbrigen Gruppen
ver%ffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, k%nnen diese in der Regel mit dem Verfahrensbetreuer diskutiert und geklErt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben nblicherweise bereits lEngerfristige Erfahrungen mit de.* und dem Einrichtungsverfahren gesammelt und k%nnen daher im Zweifel Tips und
Hinweise geben oder beratend tEtig 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: <2022-08-26> Moderationskonzept der derzeitigen Moderation
<https://dana.de/modkonzept.html>

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

Nachdem die Moderation den RfD ver%ffentlicht hat, findet in de.admin.news.groups die Diskussion nber den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf EinwEnde und Kritik eingehen und ggf. ihre
Begrnndung verfeinern.

HEufig wird die Diskussion sinnvolle ErgEnzungen zum ursprnnglichen
Vorschlag bringen, die in einen neuen, geEnderten Vorschlag
eingearbeitet werden k%nnen. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur Ver%ffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begrnndung, warum welche VorschlEge aufgenommen oder
verworfen wurden, enthElt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, k%nnen auch mehrere weitere RfDs ver%ffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unn%tig verlEngert oder verz%gert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu ver%ffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden VerbesserungsvorschlEge 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 VorschlEge und
-nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen geEnderten Vorschlag als
weiteren RfD zu ver%ffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
m%glichst konstruktiv gefnhrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer ausschlie#lich erfreulich sein wird; de.admin.news.groups ist auch
insofern ein Spiegel des Usenets als es dort neben gutwilligen
Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden Teilnehmern auch starrk%pfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. #berleitung zur Abstimmung oder Rnckzug des Vorschlags -----------------------------------------------------------

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

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgnltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten ver%ffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen nbereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
-nderungen zu ver%ffentlichen.

Nach M%glichkeit sollte am Ende der Diskussion nur noch ein einziger, einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls mnssen aber
fnr 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 nber einen Vorschlag findet per E-Mail statt. Die
abgegebenen Stimmen werden wEhrend des Abstimmungszeitraums an die E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszEhlt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer ver%ffentlicht. Die Durchfnhrung 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 Durchfnhrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu nberlassen.

4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung ----------------------------------------------------------

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

* Fnr die Durchfnhrung der Abstimmung ben%tigt man einen
E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
nach M%glichkeit nicht mit der "normalen" E-Mail-Adresse des
Abstimmungsleiters identisch sein, damit keine MissverstEndnisse
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 fnhren,
dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
von Webhosting- oder Internetzugangsanbietern.

Siehe dazu auch:

+ Zu Abstimmadressen und Filtermassnahmen
| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
| Filterma#nahmen bei der Durchfnhrung 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 dafnr geeignete Software zu verwenden,
die PlausibilitEtsprnfungen vornimmt, BestEtigungen per E-Mail
versenden kann und Auswertungen automatisch erstellt.

Die verbreitetste Softwarel%sung dafnr ist UseVote; mehr
Informationen dazu und eine Downloadm%glichkeit gibt es auf
<http://www.usevote.de/>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
haben sich einige regelmE#ige Teilnehmer in de.admin.news.* dazu
bereiterklErt, ungefilterte Abstimmungsaccounts einzurichten und die
eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.E.
zu erm%glichen. Dazu zEhlen (Stand 04/2011) u.a.

- Ralph Angenendt <ihr.name@strg-alt-entf.org>
- Ralf D%blitz <doeblitz@doeblitz.net>
- Karsten Dnsterloh <kd-usenet@tprac.de>
- Michael Grimm <trashcan@odo.in-berlin.de>
- Emil Schuster <emil@wieslauf.sub.de>

Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
abzustimmen.

* Daneben besteht auch die M%glichkeit, die Abstimmung gar nicht
selbst durchzufnhren, sondern damit einen Dritten zu beauftragen,
der weitergehende technische M%glichkeiten oder gr%#ere Erfahrungen
mit der Durchfnhrung von Abstimmungen hat. #berdies ist es zwar
zulEssig und auch der von den Einrichtungsregeln ursprnnglich
vorgesehene Regelfall, dass der Proponent auch die Abstimmung
durchfnhrt, manchmal ist es aber erwnnscht, damit einen unabhEngigen
Dritten zu beauftragen.

Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
erfahrene Votetaker haben sich nberdies 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, fnr ihn die Abstimmung durchzufnhren. In den letzten
Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
Mitglieder der GVV durchgefnhrt.

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 fnr 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 fnr die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.

Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
h%chstens einen Monat betragen. #blicherweise wird diese Frist nicht ausgesch%pft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV ver%ffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es nblich, Abstimmungen
um Mitternacht enden zu lassen. Daher k%nnten sich bei einer
Abstimmungsdauer von einem Monat und Ver%ffentlichung des 1. CfV bspw.
um 16:30 Uhr unn%tige Diskussionen ergeben, ob damit nicht die
H%chstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) nberschritten wird.

Schlie#lich muss der CfV mit dem letzten RfD im wesentlichen
nbereinstimmen, wie Teil 6 der Einrichtungsregeln festhElt:

| 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
| nbereinstimmen.

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 AbstimmungsmodalitEten; an diesen
dnrfen keine nber die Behebung von Schreibfehlern o.E. hinausgehenden -nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor diskutierte. Eine -nderung der Begrnndung - soweit sie nberhaupt im
CfV wiederholt wird - ist hingegen regelmE#ig unproblematisch.

#blich ist es, auf Basis des letzten ver%ffentlichen RfD einen CfV zu entwerfen. Dabei kann der Begrnndungsteil geknrzt werden oder ganz
entfallen und durch einen Verweis auf die gefnhrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefngt werden dann die AbstimmungsmodalitEten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele fnr
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unnblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nEmlich als nberflnssig; bei komplexeren Abstimmungen hingegen wnrde
die Darstellung aller m%glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma#en unnbersichtlich und aufwendig,
dass regelmE#ig darauf verzichtet wird. Wenn jedoch die einzelnen Abstimmungsm%glichkeiten dargestellt werden, dann mnssen sowohl die Abstimmungsm%glichkeiten fnr wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu vermeiden.

Beispiele fnr CfVs finden sich in de.admin.news.announce. Eine
m%gliche Gestaltung wEre folgende:

| 1. CfV (Abstimmungsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begrnndung
| ----------- ----------
|
| [kurze Begrnndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| AbstimmungsmodalitEten
| ----------------------
|
| Votetaker : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein : Untenstehendes Formular ist zu verwenden. M%glich sind
| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gnltigen Fassung, die in de.admin.infos
| und unter <https://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| ver%ffentlicht sind. Sie erlEutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Hinweise zur Abstimmung und
| Informationen zur Datenverarbeitung (Art. 13 DSGVO)
| ---------------------------------------------------
|
| GezEhlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestEtigt; die komplette
| Abstimmungs-E-Mail und die Stimmdaten - Name, E-Mail-Adresse und Inhalt
| der Stimmabgabe - werden bis vier Wochen nach endgnltigem Abschluss des
| Verfahrens (Umsetzung nach Ablauf der Einspruchsfrist) beim Votetaker
| gespeichert und zur Erstellung des Ergebnisses verarbeitet.
|
| #blicherweise erfolgt eine SammelbestEtigung der bis dahin abgegebenen
| Stimmen durch Ver%ffentlichung von Namen und E-Mail-Adressen aller
| Abstimmungsteilnehmer in einem 2. CfV. Auch im nach Ende der Abstimmung
| ver%ffentlichten Ergebnis werden Namen, E-Mail-Adresse und Inhalt der
| Stimmabgabe fnr alle Abstimmenden genannt.
|
| Auf Anfrage k%nnen die gespeicherten Daten an die Moderation von
| de.admin.news.announce nbermittelt werden.
|
| Speicherung, Verarbeitung und Ver%ffentlichung sowie ggf. #bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die fnr
| eine Wertung und Ver%ffentlichung der Stimmabgabe entsprechend des
| Hinweises im Wahlschein notwendig ist. Die Einwilligung kann jederzeit
| durch Mitteilung per E-Mail an den Votetaker mit Wirkung fnr die Zukunft
| widerrufen werden. Die Wertung und Ver%ffentlichung 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#e Auswertung der Abstimmung nachweisen
| zu k%nnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft nber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - L%schung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - EinschrEnkung der Datenverarbeitung gemE# Art. 18 DSGVO
| - Datennbertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zustEndigen Aufsichtsbeh%rde nach Art. 77 DSGVO
|
| Diese Rechte k%nnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| ZustEndige Aufsichtsbeh%rde ist in diesem Fall [Aufsichtsbeh%rde].
|
| =-=-=-=-=-=-=-=- 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 M%glichkeit vorzusehen, den
tatsEchlichen Namen anzugeben, da m%glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
geh%rt die Liste der Gruppen dazu, in denen der RfD ver%ffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlie#lich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehEngte Textdatei,
nbermittelt werden.

Die Ver%ffentlichung des CfVs wird nblicherweise lEnger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von de.admin.news.announce nach dem 4-Augen-Prinzip nberprnft wird. Daher
kann - und sollte - der 1. CfV ruhig m%glichst frnhzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Ver%ffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Sonderfall: CfV mit pers%nlichem Wahlschein ------------------------------------------------

ErgEnzend zu der nblichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthElt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die M%glichkeit einer Abstimmung unter Verwendung pers%nlicher Wahlscheine vor.

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

Diese Vorgehensweise soll u.a. verhindern, dass vorausgefnllte
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 gnltig sein, d.h. E-Mails entgegennehmen muss, nberprnfbar - denn nur wer eine gnltige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.

Da allerdings weiterhin andere Manipulationsm%glichkeiten verbleiben
und der Aufwand fnr die Durchfnhrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgefnhrt.

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

[5] Der Vorschlag und die entsprechende Begrnndung 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
---------------------

WEhrend der drei- oder vierw%chigen (maximal aber einmonatigen) Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach M%glichkeit einigerma#en
zeitnah, am besten automatisiert - per E-Mail bestEtigt werden; in
dieser BestEtigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse fnr den Abstimmenden registriert wurden.
Fnr Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die BestEtigung versandt werden, um sicherzustellen, dass diese Stimme auch tatsEchlich vom angegebenen
Absender stammte (und die Abstimmadresse replyfEhig ist, d.h. E-Mail
dort empfangen werden kann). Au#erdem sollte in der BestEtigung
angegeben sein, wie eine Stimme nachtrEglich geEndert oder komplett zurnckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet ver%ffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es nblich, einen 2. CfV zu ver%ffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die Stimmabgaben!) enthElt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ungnltig gewertet werden. Weil auch der 2.
CfV im Rahmen der nblichen Bearbeitungszeiten regelmE#ig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen ver%ffentlicht werden
wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei
Tage vor dem geplanten Ver%ffentlichungszeitraum einzureichen.

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

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

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

Dabei werden zunEchst die JA- und NEIN-Stimmen sowie Enthaltungen
gezEhlt. 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 Rncksprache 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 genngen (Angabe eines falschen oder nicht
vollstEndigen Namens, nicht replyfEhige Abstimmadresse), dnrfen nicht
gewertet werden. Der Votetaker sollte auch die M%glichkeit von Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
IdentitEten, Weitergabe des Wahlscheins au#erhalb der Gruppen, in
denen er ver%ffentlicht wurde, Beeinflussung der Abstimmung durch "Campaigning") im Auge behalten und entsprechende #berprnfungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern geklErt 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 frnheren ZweifelsfEllen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung nber den konkret entschiedenen
Einzelfall hinaus haben und nicht spEter revidiert wurden, unter <https://www.dana.de/archiv.html> auch im Web ver%ffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, berncksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver%ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrnckliche EinwilligungserklErungen erforderlich sind.

Danach ist eine Ergebnisver%ffentlichung ("Result") vorzubereiten.
#blich ist es, die Gesamtzahl der gnltigen Stimmen und sodann fnr
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungnltigen 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 Ver%ffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungnltige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begrnndung fnr die Nichtwertung. Dies erm%glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen FEllen kann die Ver%ffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dnrfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Grnnden die Verwendung von Pseudonymen
akzeptiert wird.

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

Mit der Ver%ffentlichung des Results durch die Moderation von de.admin.news.announce beginnt eine einw%chige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begrnndung einlegen kann, dass
bei der Durchfnhrung der Abstimmung schwerwiegende UnregelmE#igkeiten
gab. Das k%nnen bspw. technische Probleme mit der Abstimmadresse sein,
die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
oder einer der bereits unter 4.5. angerissenen Manipulationsversuche.

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskrEftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die nblicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* fnhren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergEnzen.

Ansonsten wird die Moderation nber eingegangene Einsprnche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das ver%ffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
wenn nber den Einspruch abschlie#end entschieden ist.

Das Einrichtungsverfahren ist damit beendet.

6. Sonderfall: Vereinfachtes Verfahren (VV) ===========================================

Nicht jeder marginale -nderungsvorschlag muss zwingend das vorstehend geschilderte umfangreiche Verfahren nach sich ziehen. Fnr kleinere
-nderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. "Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und Abstimmungsphase zugunsten einer Widerspruchsl%sung entfallen.

Bei einem VV wird der entsprechende -nderungsvorschlag, der dieselben Anforderungen wie ein RfD erfnllen muss (siehe 3.1.), zur
Ver%ffentlichung in de.admin.news.announce bei <moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darnber
hinaus ausdrncklich darauf hinweisen, dass die vorgeschlagene -nderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.

Nach Abschluss der Widerspruchsfrist stellt die Moderation von de.admin.news.announce entweder fest, dass kein Widerspruch
eingegangen ist und der Vorschlag angenommen wurde, oder
ver%ffentlicht Namen und E-Mail-Adresse der Widerspruchsfnhrer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgefnhrt oder aufgegeben
werden.

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

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E. ==============================================================

Bereits die Einleitung ("#bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" trEgt und sich die Ausfnhrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschEftigen, sie
aber fnr alle -nderungen am Gruppenbestand analog gelten und auch fnr
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden k%nnen (und regelmE#ig auch angewendet werden):

| Diese Spielregeln gelten fnr 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
| herbeizufnhren.
|
| 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 Grnndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschEftigen. Je gr%#er die Hierarchie wurde (und je stErker
die Nutzerzahlen wieder zurnckgingen), desto hEufiger wurden dann
-nderungs- und L%schungsverfahren, aber auch RegelEnderungen.

GrundsEtzlich ist die Vorgehensweise in diesen FEllen den
Einrichtungsverfahren vergleichbar, insbesondere die
BegrnndungsansEtze sind aber freilich andere.

7.1. Gruppenl%schungen
----------------------

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

* Insofern wird die Begrnndung eines L%schungsvorschlags in der Regel
primEr auf eine statistische Auswertung nber einen lEngeren Zeitraum
(mindestens 12 Monate, im Zweifel aber auch lEnger) gestntzt, um zu
belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
Bereich abrutscht, k%nnen niedrige Nutzungszahlen nur ein Hinweis
auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
AnlEsse reagiert und die Gruppe wieder mit Leben fnllt. Das spricht
eher gegen eine L%schung der Gruppe.

[6] <http://usenet.dex.de/>

* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
zur L%schung vorgeschlagenen Gruppe zuknnftig diskutiert werden
sollen. Wenn die Gruppe in einem gr%#eren thematischen Zusammenhang
steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
benennen, was dann wiederum fnr eine niedrigere Schwelle zur
L%schung spricht, denn so werden einzelne, mittlerweile weniger
intensiv diskutierte Unterbereiche eines gr%#eren Themas wieder
thematisch zusammengefasst.

Ein Beispiel dafnr wEre die Teilhierarchie
de.comp.office-pakete.ms-office.*, die ursprnnglich 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,
wnrde eine L%schung 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, fnr
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 FEllen ist eine
besonders kritische Prnfung erforderlich, ob sich die Gruppe nicht
wieder beleben lEsst, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema v%llig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur L%schung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

* Wenn die letzte Gruppe einer Teilhierarchie gel%scht wird, stellt
sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
Teilhierarchie").

So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
Gruppen

- de.comm.protocols.tcp-ip
- de.comm.protocols.misc

Wnrde man die Gruppe de.comm.protocols.tcp-ip l%schen, k%nnte man
die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
de.comm.protocols umbenennen, um so den Namen zu verknrzen und die
Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
spricht, dass Umbenennungen technisch nicht m%glich sind, sondern
nur durch eine L%schung der bestehenden Gruppe und die
Neueinrichtung der Gruppe mit dem geEnderten Namen umgesetzt werden
k%nnen (siehe 7.2.).

7.2. Umbenennungen
------------------

Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
mit anderen -nderungen am Gruppenbestand. Dass eine Gruppe ohne
weiteren Anlass blo# an eine andere Stelle im Hierarchiebaum (siehe
2.1.1.) verschoben wird, ist sehr selten.

Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht m%glich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zusEtzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefEhr eine Woche spEter von der
L%schung der Gruppe mit dem alten Namen. Dies fnhrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmE#ig in die
Gruppe hineinschauen, sie dann pl%tzlich nicht mehr finden k%nnen.
Eine solche Umbenennung will also wohlnberlegt sein.

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

Neben dem Namen k%nnen auch alle anderen Attribute einer Gruppe (fnr
deren Beschreibung siehe 2.) geEndert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene ChartaEnderung die Folge einer
Reorganisation, also der Einrichtung oder L%schung anderer Gruppen, so
dass klarstellende -nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gel%schten
oder sonstwie geEnderten Newsgroups aus der Charta entfernt werden
mnssen. 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 KurzbeschreibungsEnderung ist dabei im wesentlichen
kein technischer Vorgang. GeEnderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden k%nnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden ChartaEnderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. StatusEnderungen
---------------------

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

Soll eine bisher unmoderierte Gruppe zuknnftig moderiert sein, fnhrt
dies dazu, dass Postings nber Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
fnhren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuknnftig 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 BeitrEge
verloren gehen.

Diese technischen Probleme mnssen bereits in der Diskussionsphase berncksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zusEtzlichen 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 zusEtzlichen ErwEgungen
fnr die Einrichtung moderierter Gruppen entsprechend.

7.5. RegelEnderungen und Personenwahlen
---------------------------------------

Neben -nderungen am Gruppenbestand k%nnen - und werden - die
Einrichtungsregeln analog auch fnr andere Entscheiungen (bspw. die
-nderung der Einrichtungsregeln selbst) herangezogen.

Sie gelten - teilweise modifiziert - auch fnr Personenwahlen, bspw.
fnr die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmE#igen AbstEnden
durchgefnhrten Nachwahlen [8]. In gleicher Weise wEre es auch m%glich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlie#en oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
nbergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - nbersteuert werden.

[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos ver%ffentlicht sind:
| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter)
| Newsgroups: de.admin.infos,de.admin.news.misc
| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
|
| Archive-name: de-admin/dana-neuwahl
| Posting-frequency: weekly
| Last-modified: 1998-05-18
| URL: 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
regelmE#ig in de.admin.news.announce ver%ffentlicht wird:
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2022-08-26> 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 ErlEuterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise ergEnzt.

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. Weiterfnhrende Hinweise
----------------------------

Folgende Texte sind allgemein oder fnr 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: <2022-08-26> 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 D%blitz <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

+ Filterma#nahmen bei der Durchfnhrung 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 nber 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 k%nnen bei der Durchfnhrung des Einrichtungsverfahrens helfen:

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

+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
w%chentlich ver%ffentlicht in de.admin.news.announce
<https://www.dana.de/status.html>

+ GVV-Statusnbersicht
<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 MErz/April 2011 vollstEndig nberarbeitet und
neu gefasst.

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

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

Fnr Hinweise, Anregungen und VerbesserungsvorschlEge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frnhere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprnnglichen Fassung dieses Textes und seiner Entstehung
haben au#erdem beigetragen:

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

Herzlichen Dank!
--
Id: 48a99bd (HEAD -> master, tag: 2.2.10) 2025-04-13 11:56:51 +0200 Thomas Hochstein

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.answers

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.10
Last-modified: 2025-04-13
URL: https://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

ErlEuterungen 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. Vornberlegungen
1.1. Bedarf fnr eine neue Gruppe
1.2. Status quo: bestehende Gruppen und frnhere VorschlEge
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. SonderfElle

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

4. Abstimmungsphase
4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung
4.2. Inhalt und Aufbau eines CfV
4.3. Sonderfall: CfV mit pers%nlichem Wahlschein
4.4. Abstimmungsphase
4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E.
7.1. Gruppenl%schungen
7.2. Umbenennungen
7.3. -nderungen von Charta und/oder Kurzbeschreibung
7.4. StatusEnderungen
7.5. RegelEnderungen und Personenwahlen

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

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

[1] Ver%ffentlicht 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 ErlEuterungen genannten Quellen findet
sich noch einmal in Abschnitt 8.)

Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
nachfolgende, mindestens einw%chige Diskussion keinen gar zu heftigen Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im #berblick -------------------------------------------

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

Fnr de.* wird die kanonische Liste der bestehenden Newsgroups von der Moderation von de.admin.news.announce gefnhrt, die jeden Monat auch
eine entsprechende, digital signierte Steuernachricht (checkgroups)
versendet, mit der die meisten Newsserverbetreiber ihren
Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
Fnr die Aufstellung dieser Liste sind vielerlei M%glichkeiten denkbar;
in de.* entscheiden die Benutzer nber ihren Inhalt. -nderungen am Gruppenbestand - Neueinrichtung, L%schung oder Umbenennung von Gruppen
- werden in einem formalisierten Verfahren diskutiert und dann zur
Abstimmung gestellt.

Jedem Einrichtungsvorschlag sollte eine #berlegungsphase vorangehen,
in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
Status, Charta) einschlie#lich ihrer Einordnung in den bestehenden, hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden k%nnen. Am Ende dieser Vornberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe hei#en soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegennber bestehenden Gruppen abgrenzt. Mit der
Ver%ffentlichung dieses Vorschlags in de.admin.news.announce als Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
die in de.admin.news.groups gefnhrt wird, wird der Vorschlag auf
inhaltliche QualitEt und Akzeptanz abgeklopft und ggf. verEndert oder verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der Vorschlag abstimmungsreif erscheint. Die Ver%ffentlichung eines Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die Diskussionsphase und leitet in die Abstimmungsphase nber, 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 lEsst sich in folgende Phasen unterteilen,
die im Folgenden dann nEher erlEutert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information nber den status quo, BedarfsabschEtzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines f%rmlichen Einrichtungsvorschlag (RfD)
* Einreichung des RfD bei der Moderation von de.admin.news.announce

Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
enden die Vorbereitungen; das Verfahren wird in die Statusnbersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erhElt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prnft
den RfD (und die weiteren VerfahrensbeitrEge) auf Vereinbarkeit mit
den Regeln, nimmt die n%tigen Ver%ffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) fnr sich im Verlauf
des Verfahrens ergebende Fragen zur Verfngung.

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

0.3.2. Diskussionsphase

* Beginn mit Ver%ffentlichung des 1. RfD in de.admin.news.announce,
de.admin.news.groups und weiteren betroffenen Newsgroups
* %ffentliche Diskussion des Vorschlags in de.admin.news.groups
* Mindestdauer: 14 Tage
* Einreichung beliebig vieler weiterer RfDs mit geEnderten VorschlEgen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der nbrigen Teilnehmer zu ergrnnden; -nderungsvorschlEge k%nnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten er%rtert, alle
Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen m%chte oder
ob er den Vorschlag zurnckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten ver%ffentlichen RfD im Wesentlichen
nbereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
Rnckzug des Vorschlags oder Verfall durch Nichtbetreiben nber fnnf
Wochen) oder der Ver%ffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Ver%ffentlichung des 1. CfV in de.admin.news.announce und
den nbrigen Gruppen
* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
E-Mail bestEtigt
* Mindestdauer: 3 Wochen, H%chstdauer: 1 Monat (~ 4 Wochen)
* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
Abstimmenden
* einw%chige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgefnhrt, der die CfVs zur Ver%ffentlichung einreicht, die
Stimmen per E-Mail sammelt, bestEtigt und auszEhlt und am Ende das
Ergebnis der Abstimmung zur Ver%ffentlichung einreicht. Diese Aufgabe
kann der Proponent nbernehmen, er muss es aber nicht; da die
Durchfnhrung und AuszEhlung einer Abstimmung einen gewissen
technischen und organisatorischen Aufwand erfordert und auch Erfahrung
im Umgang mit ZweifelsfEllen - auch Manipulationsversuchen -
wnnschenswert ist, besteht die M%glichkeit, einen erfahrenen
Usenet-Teilnehmer um die #bernahme der Abstimmungsleitung zu bitten.
Einige Freiwillige haben sich zu diesem Zweck als "German Volunteer
Votetakers" (GVV) zusammengeschlossen.

Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und letztlich mit der Ver%ffentlichung des Ergebnisses. Daran schlie#t
sich ein einw%chiger Einspruchszeitraum an, in dem Regelverst%#e durch
einen Einspruch bemEngelt werden k%nnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskrEftig.

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 gnltigen 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. Vornberlegungen
==================

1.1. Bedarf fnr eine neue Gruppe
--------------------------------

Ganz am Anfang der #berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zunEchst die Frage, ob die angedachte Gruppe denn auch
tatsEchlich ben%tigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuknnftigen 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 nberfnllt ist.

Die zuknnftige NutzungsintensitEt der vorgeschlagenen Gruppe wird
dabei regelmE#ig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

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

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

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
zuknnftig einigerma#en intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tatsEchliche gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
und ob sie dies im Usenet tun m%chten. Es mag sehr wichtige Themen
geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
oder die anderswo diskutiert werden, ohne dass bei den Interessenten
der Wunsch besteht, ihre Diskussionen im Usenet zu fnhren. Die
mehrheitliche Ansicht geht nberdies dahin, dass es nicht sinnvoll ist,
fnr "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es nberwiegend als
wnnschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und f%rdern.

Siehe auch:

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
<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 frnhere VorschlEge ----------------------------------------------------------

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

Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
m%glicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
eine solche Gruppe, die dann spEter wieder aus der Gruppenliste
entfernt wurde? Aus diesen #berlegungen ergeben sich Hinweise auf die Erfolgsaussichten des Vorschlags und m%glicherweise auch Anregungen
fnr seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche -nderungen in Inhalt oder Begrnndung erneut einzubringen.

[3] Am bekanntesten dnrfte 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
Befnrworter 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 fnhrt oft zu besseren Ergebnissen als einsames Grnbeln im stillen KEmmerlein.

Auch in der Diskussion ist es f%rderlich, einen Vorschlag nicht
alleine argumentativ zu stntzen; nicht nur deshalb, weil eine Mehrzahl
von Interessenten, die sich auch selbst in die Diskussion einbringt, nberzeugender ein dauerhaftes Interesse signalisiert als ein
Einzelner. Auch aus psychologischen Grnnden ist es angenehmer, die
eigene Position nicht alleine vertreten zu mnssen.

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

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

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

| Ein CfV kann nicht ver%ffentlicht werden, wenn einer der folgenden
| Punkte noch unklar ist:
|
| o Name der Gruppe
| o Kurzbeschreibung der Gruppe
| o Charta der Gruppe
| o Status der Gruppe (moderiert oder unmoderiert)
| o der Name des Moderators im Falle einer moderierten Gruppe

Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
sich daher auch die Frage nach der Einordnung der neuen Gruppe in die bestehende Struktur der Hierarchie de.*, und in der Charta sollte
nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
auch die Abgrenzung zu thematisch Ehnlichen Gruppen ihren Platz
finden.

Sinnvoll ist es daher, sich zunEchst Gedanken nber 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
nberlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
demnach hei#en soll (2.1.); dann fehlt nur noch eine knackige
Zusammenfassung fnr die Kurzbeschreibung (2.2.).

Falls eine moderierte Newsgroup vorgeschlagen wird, mnssen auch der
oder die vorgesehenen Moderatoren feststehen; nberdies sollte ein
Konzept fnr die Moderation vorliegen und die technischen
Voraussetzungen hinreichend geklErt sein.

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

2.1.1. Einordnung

ZunEchst sollte die prospektive Gruppe sich in die bestehende
Namenshierarchie in de.* einpassen. de.* besteht nEmlich aus
thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
immer feineren thematischen VerEstelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollstEndig
logisch stringent, und regelmE#ig wird es nicht nur einen denkbaren
Platz geben, an den eine neue Gruppe passen wnrde.

Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
bemnhen, den bestm%glichen Ort fnr die neue Gruppe zu finden. Dazu
geh%rt sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.

Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
Einrichtungsregeln auszeichnet und daher nicht Thema dieser
ErlEuterungen 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 beschEftigen sich mit den
- im Usenet umfEnglich 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

* GerEte (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 schlie#lich:
de.comm.infosystems.* - WWW samt Webseitenerstellung
de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)

* de.comp.*
Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
so dazugeh%rt. Auch sie ist demnach umfangreich weiter
untergliedert, neben verschiedenen Einzelgruppen namentlich in

* Hardware:
de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks
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.* beschEftigt sich mit
FreizeitaktivitEten ("recreational activities") aller Art und
enthElt neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien
zu den Themen Musik h%ren und machen, Sport(arten), Spielen aller
Art, am Brett wie am Computer, Science Fiction und Fantasy,
Fernseh(seri)en, Filme und Heimkino und (Haus-)Tiere.

* de.sci.*
Die Unterhierarchie de.sci.* ist fnr 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 fnr Smalltalk
und entspannten Plausch als Diskussion und Informationsaustausch
vorgesehen; viele der verbliebenen Gruppen wnrden aber ebenso gut
nach de.soc.* passen.

* de.org.*
Die - gleichfalls kleine - Teilhierarchie de.org.* ist fnr
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 geh%ren das Bahnwesen, Autos und andere Fahrzeuge,
Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
Notfallrettung und MilitErwesen oder auch die Haushaltsfnhrung.

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 aussagekrEftig und allgemeinverstEndlich,
aber zugleich auch so kurz wie m%glich gewEhlt werden. Kryptische oder mehrdeutige Abknrzungen sollte man m%glichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, spEtestens aber in der Charta erlEutert werden.

Fnr die Wahl des Gruppennamens sind zudem technisch geprEgte
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 dnrfen nicht lEnger als 30 Zeichen werden und
mnssen mindestens je einen Buchstaben enthalten. Zu beachten ist
dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene
schon vor dem 15. Zeichen unterscheiden mnssen.

* 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 LEnge des Gruppennamens 71 Zeichen nicht
nberschreiten.

[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 ErgEnzung zum Gruppennamen das Thema kurz umrei#en. Im Gegensatz zur Charta, der ausfnhrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
gEngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelmE#ig versandten Steuernachrichten, die den aktuellen Gruppenbestand von de.*
enthalten.

Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muss kurz, knapp und fnr jeden verstEndlich sein. "Diskussion
nber" oder "Informationen von" sind zum Beispiel notorisch
nberflnssige Formulierungen. Hingegen sollten m%glichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer m%glicherweise suchen werden. Da die
Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die meist auf 80 Spalten breiten
Terminals gelesen werden, ergibt sich eine BeschrEnkung fnr die LEnge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt fnr die Kurzbeschreibung gew%hnlich eine MaximallEnge
von 60 Zeichen.

Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze Kurzbeschreibung anzeigen, wird er sich nblicherweise auf den Anfang
der Kurzbeschreibung beschrEnken. 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 fnr Kurzbeschreibungen finden sich in dem bereits genannten
Text "Die Newsgruppen der de-Hierarchie".

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

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

Es ist hilfreich, fnr das Thema der Gruppe einige Beispiele als nicht abschlie#ende AufzEhlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen m%glicherweise gesucht wird.
Dabei ist aber zu berncksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW ver%ffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfngung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl m%glicherweise Name und
Kurzbeschreibung bei flnchtiger Durchsicht zu dieser Annahme fnhren
k%nnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrncklich auszuschlie#en. Genauso sollte innerhalb der
Charta das Diskussionsthema von anderen, themenverwandten Gruppen
abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
nicht tunlich, weil ansonsten bei jeder Umbenennung oder L%schung der betreffenden Gruppen eine ChartaEnderung n%tig wnrde (siehe 7.3.).

Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
gelten sollen als sonst im Netz nblich sollte auch dies in der Charta
vermerkt werden. Zu denken wEre bspw. an die (ausdrnckliche) Akzeptanz
anonymer BeitrEge oder von Inseraten. Gleichfalls sollten vorgesehene ungewohnte technische Ma#nahmen - zu denken wEre hier bspw. an die EingangsbestEtigung von Postings per E-Mail durch die sog. Reflektoren
in den Testgruppen - durch die Charta legitimiert werden. In allen
diesen FEllen sollte einerseits berncksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdrncklich abgelehnt wird, sowohl wegen der unn%tigen VerlEngerung der Charta als auch, weil dies den Eindruck vermitteln
k%nnte, die entsprechenden Regeln und Konventionen hEtten nur dort
Geltung, wo sie ausdrncklich 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 Grnnde haben und zudem als feststehende Gewohnheiten betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut begrnndeten SonderfEllen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie m%glich gehalten werden; weitergehende ErlEuterungen und solche Regeln, die sich voraussichtlich hEufiger
Endern werden, geh%ren nicht in die Charta, sondern sollten Gegenstand
einer (regelmE#ig geposteten und nach M%glichkeit auch im WWW
bereitgestellten) Einfnhrung, 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 ErwEhnung finden;
die einzelnen angedachten Tags geh%ren dann in eine anderweitig
bereitgestellte ErlEuterung. Auch das Moderationskonzept einer
moderierten Gruppe geh%rt schon aufgrund seiner LEnge 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 Gefnhl fnr die Abfassung einer guten Charta zu
bekommen. Solche Beispiele finden sich in dem bereits genannten Text
"Die Newsgruppen der de-Hierarchie".

2.4. Status
-----------

Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status "moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
dann ohne weiteres in der Newsgroup ver%ffentlicht und weltweit
verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
stattdessen versendet der Newsserver, bei dem das Posting eingespeist
wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
mehrk%pfige Moderation). Diese entscheidet dann nber die
Ver%ffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
#bersichtlichkeit und h%heren inhaltlichen QualitEt, weil BeitrEge
vorgefiltert werden k%nnen; ihr Nachteil ist die zwangslEufig
entstehende Verz%gerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn bestEtigen muss. Sie eignen sich daher vor
allem fnr Anknndigungen oder FAQs. Ein Beispiel hierfnr ist de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen ver%ffentlicht werden, so dass die Gruppe auch fnr
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige #berprnfung der
Ver%ffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte ver%ffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer h%heren inhaltlichen QualitEt dienen und erm%glicht
vor allem den Ausschluss von bewussten St%rern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegrnndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden Verz%gerungen vor Ver%ffentlichung eines Beitrags den Fluss der
Diskussion st%ren und an Ver%ffentlichung ihrer BeitrEge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschEtzen; 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 BeitrEge so zeitnah wie
m%glich zu prnfen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zusEtzliche Angaben zur Moderation zu machen;
dazu geh%ren der oder die vorgesehene(n) Moderator(en) und die Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
fnr die Newsgroup zur Freigabe weitergeleitet werden sollen. Au#erdem
muss die Kurzbeschreibung entsprechend ergEnzt werden. Schlie#lich
sollte fnr die Durchfnhrung der Moderation sinnvollerweise ein Konzept vorliegen und die technischen Voraussetzungen geschaffen und getestet
sein.

* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
Ver%ffentlichung des Vorschlags seine entsprechende Bereitschaft
erklErt haben; in der Regel wird es sich empfehlen, ein mehrk%pfiges
Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
auch im Falle eines mehrw%chigen Urlaubs oder gar eines dauerhaften
Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
interessiert sein mag - die Moderation handlungsfEhig bleibt und
BeitrEge weiterhin ver%ffentlicht werden k%nnen. Fnr moderierte
Diskussionsgruppen wird regelmE#ig ein ausreichend gro#es Team
zwingend vorzusehen sein, damit BeitrEge zumindest tagsnber zeitnah
ver%ffentlicht werden k%nnen.

Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
Einreichungen bewerten zu k%nnen, von den zu erwartenden
Diskussionsteilnehmern akzeptiert werden und schlie#lich absehbar
fnr lEngere Zeit fnr diese TEtigkeit zur Verfngung stehen. Erfahrung
im Usenet und ggf. die notwendigen technischen Kenntnisse zur
Durchfnhrung der Moderation sind hilfreich.

* Wenn die (erste) Moderation personell feststeht, stellt sich als
nEchstes die Frage, welche E-Mail-Adresse fnr Einreichungen
("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
in jedem Newsserver oder an einer zentralen Stelle (den Relays fnr
moderators.isc.org) in der Konfiguration vermerkt werden, sollte
sich also so selten wie m%glich Endern; au#erdem sollte die Adresse
zuverlEssig erreichbar sein und ggf. die M%glichkeit fnr
ausreichende Spamfilterung bieten; langjEhrig aktive und regelmE#ig
ver%ffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
Spam an.

Daneben sollte eine weitere Adresse ver%ffentlicht werden, nber die
der Moderator oder die Moderation kontaktiert werden k%nnen, ohne
dass eine Ver%ffentlichung erfolgt, um bspw. fnr Anfragen erreichbar
sein.

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

* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
welchen Kriterien BeitrEge akzeptiert oder zurnckgewiesen werden, ob
sie ggf. verEndert ver%ffentlicht werden k%nnen und wie mit
Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
mehrk%pfigen Moderation stellt dies eine einheitliche Handhabung
sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
werden und danach (regelmE#ig) ver%ffentlicht werden.

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

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
M%glichkeit, einen per E-Mail nbersandten Beitrag unter Beibehaltung
der wesentlichen Informationen auch im Header - aber unter Wegfall
mancher und ErgEnzung anderer Headerzeilen - als Posting zu
ver%ffentlichen. Insbesondere dann, wenn mehr als eine Person -
parallel - an der Moderation beteiligt sein soll (was sich
mittlerweile als Regelfall etabliert haben dnrfte), empfiehlt es
sich, das entsprechende Zusammenwirken auch technisch zu
unterstntzen. In der Regel wird die Moderation einer Newsgroup also
die Installation entsprechender Software auf dem eigenen Rechner
oder sogar die Einrichtung auf einem nbers 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 Verfngung zu stellen. Die Auswahl und Erprobung der
vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
Kontaktaufnahmen sollten aber spEtestens parallel zum laufenden
Einrichtungsverfahren erfolgen; Tests k%nnen bspw. in der Newsgroup
de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<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 nber 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. SonderfElle
----------------

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

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

Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe fnr
Ausrnstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
eingerichtet werden. Dies geschieht regelmE#ig durch Umbenennung der
bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
also auch dazu Informationen enthalten.

* Einrichtung einer neuen Teilhierarchie

Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
vorgeschlagen werden soll, sondern direkt mehrere, thematisch
zusammenhEngende, also auf diese Weise eine neue Teilhierachie
entsteht.

Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
"de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
mit K%dern zu tun haben. Die entsprechenden Informationen - Name,
Kurzbeschreibung, Charta - mnssen 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 fnr
alle Gruppen die notwendigen Informationen bereitstellen.

Zu berncksichtigen ist, dass VorschlEge grundsEtzlich nicht "en
bloc" zur Abstimmung gestellt werden k%nnen; vielmehr ist nber jeden
Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
Teil 7 folgende Vorgaben:

| #bertragbarkeit: Stimmen k%nnen nicht auf einen anderen
| Abstimmungsvorschlag nbertragen werden. Eine Stimme zEhlt nur fnr
| GENAU DEN Vorschlag, fnr den sie abgegeben wurde. Insbesondere
| darf eine Stimme fnr oder gegen eine Newsgruppe mit einem
| bestimmten Namen NICHT als Stimme fnr 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 gezEhlt
| werden. #ber jede Gruppe wird einzeln abgestimmt, Verknnpfungen
| von Wahlen sind nicht m%glich.

* Diskussion mehrerer Alternativen

Ziel der Diskussion sollte es regelmE#ig sein, am Ende der
Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
Das schlie#t nicht aus, in der Diskussion zunEchst mehrere denkbare
Alternativen vorzuschlagen; die Diskussion sollte aber schlie#lich
zu einem mehrheitsfEhigen Vorschlag fnhren. Ggf. kann dazu auch ein
unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
sich ausschlie#ende Alternativen zur Abstimmung zu stellen sollte
nach M%glichkeit vermieden werden, weil die Abstimmung sonst
einerseits schnell sehr kompliziert wird und andererseits die Gefahr
besteht, dass entweder kein Vorschlag eine Mehrheit erhElt (obwohl
die Mehrzahl der Abstimmenden durchaus generell fnr eine Einrichtung
der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
VorschlEgen angenommen wird, das so niemand gewollt hat.

Die fnr die Abstimmung in diesem Fall zu beachtenden Regeln fnr
"kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
und lauten folgenderma#en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h%chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird nber die Einrichtung jeder einzelnen Gruppe gemE# den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zusEtzlich 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 VerhEltnis Zustimmung : Ablehnung aufweist.

Siehe dazu auch:

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf D%blitz <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 Vornberlegungen abgeschlossen sind, kann das "offizielle" Einrichtungsverfahren mit der Abfassung eines f%rmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prnfung ver%ffentlicht wird.

3.1. Inhalt und Aufbau eines RfD
--------------------------------

3.1.1. Inhalt

Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
2. dargestellten notwendigen Informationen und einer Begrnndung des Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit fnr die bzw. dem Erfolg der
vorgeschlagenen neuen Gruppe zu nberzeugen.

#blicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begrnndung, die den Hintergrund fnr den Vorschlag und die #berlegungen insbesondere zu den bereits oben unter 1. ("Vornberlegungen")
genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
Monaten vorzunehmen ("Trafficnachweis"). Au#erdem enthElt der RfD
natnrlich 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 fnr die Kommunikation mit der Moderation von de.admin.news.announce und fnr
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.

Schlie#lich ist auch zu entscheiden, in welchen Gruppen der RfD
ver%ffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zusEtzlich 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 eingeschrEnkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natnrlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
stattfinden oder in denen man sich Interessen an der neuen Gruppe
erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
m%glich und nur so lang wie n%tig sein sollte; dies schon deshalb,
weil in nbermE#ig viele Gruppen verteilte Postings heutzutage
m%glicherweise als Spam ausgefiltert werden.

Eine Ver%ffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im EinverstEndnis mit deren Moderation. In Gruppen au#erhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.E. kann der Proponent nach Ver%ffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") ver%ffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden k%nnen.

3.1.2. Formale Gestaltung

Fnr die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich #blichkeiten entwickelt. Es empfiehlt
sich auch hier, einige Eltere 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 / Begrnndung
| ----------- ----------
|
| [Begrnndung, 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 nbermittelt
werden, in denen der RfD ver%ffentlicht werden soll. Der RfD kann auch
bereits einschlie#lich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehEngte Textdatei, nbermittelt
werden.

#blicherweise wird die Moderation den Eingang des RfD bestEtigen und
ihn in den w%chentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation ver%ffentlicht wird. Danach wird ein Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
nberprnft, ggf. Rncksprache mit dem oder den Proponenten nimmt und ihn schlie#lich in de.admin.news.announce und den nbrigen Gruppen
ver%ffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, k%nnen diese in der Regel mit dem Verfahrensbetreuer diskutiert und geklErt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben nblicherweise bereits lEngerfristige Erfahrungen mit de.* und dem Einrichtungsverfahren gesammelt und k%nnen daher im Zweifel Tips und
Hinweise geben oder beratend tEtig 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: <2022-08-26> Moderationskonzept der derzeitigen Moderation
<https://dana.de/modkonzept.html>

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

Nachdem die Moderation den RfD ver%ffentlicht hat, findet in de.admin.news.groups die Diskussion nber den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf EinwEnde und Kritik eingehen und ggf. ihre
Begrnndung verfeinern.

HEufig wird die Diskussion sinnvolle ErgEnzungen zum ursprnnglichen
Vorschlag bringen, die in einen neuen, geEnderten Vorschlag
eingearbeitet werden k%nnen. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur Ver%ffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begrnndung, warum welche VorschlEge aufgenommen oder
verworfen wurden, enthElt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, k%nnen auch mehrere weitere RfDs ver%ffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unn%tig verlEngert oder verz%gert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu ver%ffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden VerbesserungsvorschlEge 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 VorschlEge und
-nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen geEnderten Vorschlag als
weiteren RfD zu ver%ffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
m%glichst konstruktiv gefnhrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer ausschlie#lich erfreulich sein wird; de.admin.news.groups ist auch
insofern ein Spiegel des Usenets als es dort neben gutwilligen
Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden Teilnehmern auch starrk%pfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. #berleitung zur Abstimmung oder Rnckzug des Vorschlags -----------------------------------------------------------

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

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgnltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten ver%ffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen nbereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
-nderungen zu ver%ffentlichen.

Nach M%glichkeit sollte am Ende der Diskussion nur noch ein einziger, einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls mnssen aber
fnr 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 nber einen Vorschlag findet per E-Mail statt. Die
abgegebenen Stimmen werden wEhrend des Abstimmungszeitraums an die E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszEhlt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer ver%ffentlicht. Die Durchfnhrung 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 Durchfnhrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu nberlassen.

4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung ----------------------------------------------------------

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

* Fnr die Durchfnhrung der Abstimmung ben%tigt man einen
E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
nach M%glichkeit nicht mit der "normalen" E-Mail-Adresse des
Abstimmungsleiters identisch sein, damit keine MissverstEndnisse
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 fnhren,
dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
von Webhosting- oder Internetzugangsanbietern.

Siehe dazu auch:

+ Zu Abstimmadressen und Filtermassnahmen
| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
| Filterma#nahmen bei der Durchfnhrung 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 dafnr geeignete Software zu verwenden,
die PlausibilitEtsprnfungen vornimmt, BestEtigungen per E-Mail
versenden kann und Auswertungen automatisch erstellt.

Die verbreitetste Softwarel%sung dafnr ist UseVote; mehr
Informationen dazu und eine Downloadm%glichkeit gibt es auf
<http://www.usevote.de/>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
haben sich einige regelmE#ige Teilnehmer in de.admin.news.* dazu
bereiterklErt, ungefilterte Abstimmungsaccounts einzurichten und die
eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.E.
zu erm%glichen. Dazu zEhlen (Stand 04/2011) u.a.

- Ralph Angenendt <ihr.name@strg-alt-entf.org>
- Ralf D%blitz <doeblitz@doeblitz.net>
- Karsten Dnsterloh <kd-usenet@tprac.de>
- Michael Grimm <trashcan@odo.in-berlin.de>
- Emil Schuster <emil@wieslauf.sub.de>

Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
abzustimmen.

* Daneben besteht auch die M%glichkeit, die Abstimmung gar nicht
selbst durchzufnhren, sondern damit einen Dritten zu beauftragen,
der weitergehende technische M%glichkeiten oder gr%#ere Erfahrungen
mit der Durchfnhrung von Abstimmungen hat. #berdies ist es zwar
zulEssig und auch der von den Einrichtungsregeln ursprnnglich
vorgesehene Regelfall, dass der Proponent auch die Abstimmung
durchfnhrt, manchmal ist es aber erwnnscht, damit einen unabhEngigen
Dritten zu beauftragen.

Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
erfahrene Votetaker haben sich nberdies 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, fnr ihn die Abstimmung durchzufnhren. In den letzten
Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
Mitglieder der GVV durchgefnhrt.

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 fnr 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 fnr die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.

Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
h%chstens einen Monat betragen. #blicherweise wird diese Frist nicht ausgesch%pft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV ver%ffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es nblich, Abstimmungen
um Mitternacht enden zu lassen. Daher k%nnten sich bei einer
Abstimmungsdauer von einem Monat und Ver%ffentlichung des 1. CfV bspw.
um 16:30 Uhr unn%tige Diskussionen ergeben, ob damit nicht die
H%chstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) nberschritten wird.

Schlie#lich muss der CfV mit dem letzten RfD im wesentlichen
nbereinstimmen, wie Teil 6 der Einrichtungsregeln festhElt:

| 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
| nbereinstimmen.

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 AbstimmungsmodalitEten; an diesen
dnrfen keine nber die Behebung von Schreibfehlern o.E. hinausgehenden -nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor diskutierte. Eine -nderung der Begrnndung - soweit sie nberhaupt im
CfV wiederholt wird - ist hingegen regelmE#ig unproblematisch.

#blich ist es, auf Basis des letzten ver%ffentlichen RfD einen CfV zu entwerfen. Dabei kann der Begrnndungsteil geknrzt werden oder ganz
entfallen und durch einen Verweis auf die gefnhrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefngt werden dann die AbstimmungsmodalitEten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele fnr
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unnblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nEmlich als nberflnssig; bei komplexeren Abstimmungen hingegen wnrde
die Darstellung aller m%glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma#en unnbersichtlich und aufwendig,
dass regelmE#ig darauf verzichtet wird. Wenn jedoch die einzelnen Abstimmungsm%glichkeiten dargestellt werden, dann mnssen sowohl die Abstimmungsm%glichkeiten fnr wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu vermeiden.

Beispiele fnr CfVs finden sich in de.admin.news.announce. Eine
m%gliche Gestaltung wEre folgende:

| 1. CfV (Abstimmungsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begrnndung
| ----------- ----------
|
| [kurze Begrnndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| AbstimmungsmodalitEten
| ----------------------
|
| Votetaker : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein : Untenstehendes Formular ist zu verwenden. M%glich sind
| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gnltigen Fassung, die in de.admin.infos
| und unter <https://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| ver%ffentlicht sind. Sie erlEutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Hinweise zur Abstimmung und
| Informationen zur Datenverarbeitung (Art. 13 DSGVO)
| ---------------------------------------------------
|
| GezEhlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestEtigt; die komplette
| Abstimmungs-E-Mail und die Stimmdaten - Name, E-Mail-Adresse und Inhalt
| der Stimmabgabe - werden bis vier Wochen nach endgnltigem Abschluss des
| Verfahrens (Umsetzung nach Ablauf der Einspruchsfrist) beim Votetaker
| gespeichert und zur Erstellung des Ergebnisses verarbeitet.
|
| #blicherweise erfolgt eine SammelbestEtigung der bis dahin abgegebenen
| Stimmen durch Ver%ffentlichung von Namen und E-Mail-Adressen aller
| Abstimmungsteilnehmer in einem 2. CfV. Auch im nach Ende der Abstimmung
| ver%ffentlichten Ergebnis werden Namen, E-Mail-Adresse und Inhalt der
| Stimmabgabe fnr alle Abstimmenden genannt.
|
| Auf Anfrage k%nnen die gespeicherten Daten an die Moderation von
| de.admin.news.announce nbermittelt werden.
|
| Speicherung, Verarbeitung und Ver%ffentlichung sowie ggf. #bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die fnr
| eine Wertung und Ver%ffentlichung der Stimmabgabe entsprechend des
| Hinweises im Wahlschein notwendig ist. Die Einwilligung kann jederzeit
| durch Mitteilung per E-Mail an den Votetaker mit Wirkung fnr die Zukunft
| widerrufen werden. Die Wertung und Ver%ffentlichung 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#e Auswertung der Abstimmung nachweisen
| zu k%nnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft nber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - L%schung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - EinschrEnkung der Datenverarbeitung gemE# Art. 18 DSGVO
| - Datennbertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zustEndigen Aufsichtsbeh%rde nach Art. 77 DSGVO
|
| Diese Rechte k%nnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| ZustEndige Aufsichtsbeh%rde ist in diesem Fall [Aufsichtsbeh%rde].
|
| =-=-=-=-=-=-=-=- 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 M%glichkeit vorzusehen, den
tatsEchlichen Namen anzugeben, da m%glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
geh%rt die Liste der Gruppen dazu, in denen der RfD ver%ffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlie#lich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehEngte Textdatei,
nbermittelt werden.

Die Ver%ffentlichung des CfVs wird nblicherweise lEnger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von de.admin.news.announce nach dem 4-Augen-Prinzip nberprnft wird. Daher
kann - und sollte - der 1. CfV ruhig m%glichst frnhzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Ver%ffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Sonderfall: CfV mit pers%nlichem Wahlschein ------------------------------------------------

ErgEnzend zu der nblichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthElt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die M%glichkeit einer Abstimmung unter Verwendung pers%nlicher Wahlscheine vor.

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

Diese Vorgehensweise soll u.a. verhindern, dass vorausgefnllte
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 gnltig sein, d.h. E-Mails entgegennehmen muss, nberprnfbar - denn nur wer eine gnltige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.

Da allerdings weiterhin andere Manipulationsm%glichkeiten verbleiben
und der Aufwand fnr die Durchfnhrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgefnhrt.

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

[5] Der Vorschlag und die entsprechende Begrnndung 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
---------------------

WEhrend der drei- oder vierw%chigen (maximal aber einmonatigen) Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach M%glichkeit einigerma#en
zeitnah, am besten automatisiert - per E-Mail bestEtigt werden; in
dieser BestEtigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse fnr den Abstimmenden registriert wurden.
Fnr Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die BestEtigung versandt werden, um sicherzustellen, dass diese Stimme auch tatsEchlich vom angegebenen
Absender stammte (und die Abstimmadresse replyfEhig ist, d.h. E-Mail
dort empfangen werden kann). Au#erdem sollte in der BestEtigung
angegeben sein, wie eine Stimme nachtrEglich geEndert oder komplett zurnckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet ver%ffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es nblich, einen 2. CfV zu ver%ffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die Stimmabgaben!) enthElt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ungnltig gewertet werden. Weil auch der 2.
CfV im Rahmen der nblichen Bearbeitungszeiten regelmE#ig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen ver%ffentlicht werden
wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei
Tage vor dem geplanten Ver%ffentlichungszeitraum einzureichen.

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

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

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

Dabei werden zunEchst die JA- und NEIN-Stimmen sowie Enthaltungen
gezEhlt. 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 Rncksprache 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 genngen (Angabe eines falschen oder nicht
vollstEndigen Namens, nicht replyfEhige Abstimmadresse), dnrfen nicht
gewertet werden. Der Votetaker sollte auch die M%glichkeit von Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
IdentitEten, Weitergabe des Wahlscheins au#erhalb der Gruppen, in
denen er ver%ffentlicht wurde, Beeinflussung der Abstimmung durch "Campaigning") im Auge behalten und entsprechende #berprnfungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern geklErt 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 frnheren ZweifelsfEllen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung nber den konkret entschiedenen
Einzelfall hinaus haben und nicht spEter revidiert wurden, unter <https://www.dana.de/archiv.html> auch im Web ver%ffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, berncksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver%ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrnckliche EinwilligungserklErungen erforderlich sind.

Danach ist eine Ergebnisver%ffentlichung ("Result") vorzubereiten.
#blich ist es, die Gesamtzahl der gnltigen Stimmen und sodann fnr
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungnltigen 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 Ver%ffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungnltige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begrnndung fnr die Nichtwertung. Dies erm%glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen FEllen kann die Ver%ffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dnrfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Grnnden die Verwendung von Pseudonymen
akzeptiert wird.

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

Mit der Ver%ffentlichung des Results durch die Moderation von de.admin.news.announce beginnt eine einw%chige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begrnndung einlegen kann, dass
bei der Durchfnhrung der Abstimmung schwerwiegende UnregelmE#igkeiten
gab. Das k%nnen bspw. technische Probleme mit der Abstimmadresse sein,
die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
oder einer der bereits unter 4.5. angerissenen Manipulationsversuche.

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskrEftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die nblicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* fnhren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergEnzen.

Ansonsten wird die Moderation nber eingegangene Einsprnche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das ver%ffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
wenn nber den Einspruch abschlie#end entschieden ist.

Das Einrichtungsverfahren ist damit beendet.

6. Sonderfall: Vereinfachtes Verfahren (VV) ===========================================

Nicht jeder marginale -nderungsvorschlag muss zwingend das vorstehend geschilderte umfangreiche Verfahren nach sich ziehen. Fnr kleinere
-nderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. "Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und Abstimmungsphase zugunsten einer Widerspruchsl%sung entfallen.

Bei einem VV wird der entsprechende -nderungsvorschlag, der dieselben Anforderungen wie ein RfD erfnllen muss (siehe 3.1.), zur
Ver%ffentlichung in de.admin.news.announce bei <moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darnber
hinaus ausdrncklich darauf hinweisen, dass die vorgeschlagene -nderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.

Nach Abschluss der Widerspruchsfrist stellt die Moderation von de.admin.news.announce entweder fest, dass kein Widerspruch
eingegangen ist und der Vorschlag angenommen wurde, oder
ver%ffentlicht Namen und E-Mail-Adresse der Widerspruchsfnhrer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgefnhrt oder aufgegeben
werden.

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

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E. ==============================================================

Bereits die Einleitung ("#bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" trEgt und sich die Ausfnhrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschEftigen, sie
aber fnr alle -nderungen am Gruppenbestand analog gelten und auch fnr
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden k%nnen (und regelmE#ig auch angewendet werden):

| Diese Spielregeln gelten fnr 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
| herbeizufnhren.
|
| 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 Grnndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschEftigen. Je gr%#er die Hierarchie wurde (und je stErker
die Nutzerzahlen wieder zurnckgingen), desto hEufiger wurden dann
-nderungs- und L%schungsverfahren, aber auch RegelEnderungen.

GrundsEtzlich ist die Vorgehensweise in diesen FEllen den
Einrichtungsverfahren vergleichbar, insbesondere die
BegrnndungsansEtze sind aber freilich andere.

7.1. Gruppenl%schungen
----------------------

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

* Insofern wird die Begrnndung eines L%schungsvorschlags in der Regel
primEr auf eine statistische Auswertung nber einen lEngeren Zeitraum
(mindestens 12 Monate, im Zweifel aber auch lEnger) gestntzt, um zu
belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
Bereich abrutscht, k%nnen niedrige Nutzungszahlen nur ein Hinweis
auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
AnlEsse reagiert und die Gruppe wieder mit Leben fnllt. Das spricht
eher gegen eine L%schung der Gruppe.

[6] <http://usenet.dex.de/>

* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
zur L%schung vorgeschlagenen Gruppe zuknnftig diskutiert werden
sollen. Wenn die Gruppe in einem gr%#eren thematischen Zusammenhang
steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
benennen, was dann wiederum fnr eine niedrigere Schwelle zur
L%schung spricht, denn so werden einzelne, mittlerweile weniger
intensiv diskutierte Unterbereiche eines gr%#eren Themas wieder
thematisch zusammengefasst.

Ein Beispiel dafnr wEre die Teilhierarchie
de.comp.office-pakete.ms-office.*, die ursprnnglich 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,
wnrde eine L%schung 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, fnr
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 FEllen ist eine
besonders kritische Prnfung erforderlich, ob sich die Gruppe nicht
wieder beleben lEsst, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema v%llig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur L%schung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

* Wenn die letzte Gruppe einer Teilhierarchie gel%scht wird, stellt
sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
Teilhierarchie").

So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
Gruppen

- de.comm.protocols.tcp-ip
- de.comm.protocols.misc

Wnrde man die Gruppe de.comm.protocols.tcp-ip l%schen, k%nnte man
die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
de.comm.protocols umbenennen, um so den Namen zu verknrzen und die
Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
spricht, dass Umbenennungen technisch nicht m%glich sind, sondern
nur durch eine L%schung der bestehenden Gruppe und die
Neueinrichtung der Gruppe mit dem geEnderten Namen umgesetzt werden
k%nnen (siehe 7.2.).

7.2. Umbenennungen
------------------

Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
mit anderen -nderungen am Gruppenbestand. Dass eine Gruppe ohne
weiteren Anlass blo# an eine andere Stelle im Hierarchiebaum (siehe
2.1.1.) verschoben wird, ist sehr selten.

Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht m%glich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zusEtzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefEhr eine Woche spEter von der
L%schung der Gruppe mit dem alten Namen. Dies fnhrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmE#ig in die
Gruppe hineinschauen, sie dann pl%tzlich nicht mehr finden k%nnen.
Eine solche Umbenennung will also wohlnberlegt sein.

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

Neben dem Namen k%nnen auch alle anderen Attribute einer Gruppe (fnr
deren Beschreibung siehe 2.) geEndert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene ChartaEnderung die Folge einer
Reorganisation, also der Einrichtung oder L%schung anderer Gruppen, so
dass klarstellende -nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gel%schten
oder sonstwie geEnderten Newsgroups aus der Charta entfernt werden
mnssen. 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 KurzbeschreibungsEnderung ist dabei im wesentlichen
kein technischer Vorgang. GeEnderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden k%nnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden ChartaEnderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. StatusEnderungen
---------------------

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

Soll eine bisher unmoderierte Gruppe zuknnftig moderiert sein, fnhrt
dies dazu, dass Postings nber Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
fnhren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuknnftig 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 BeitrEge
verloren gehen.

Diese technischen Probleme mnssen bereits in der Diskussionsphase berncksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zusEtzlichen 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 zusEtzlichen ErwEgungen
fnr die Einrichtung moderierter Gruppen entsprechend.

7.5. RegelEnderungen und Personenwahlen
---------------------------------------

Neben -nderungen am Gruppenbestand k%nnen - und werden - die
Einrichtungsregeln analog auch fnr andere Entscheiungen (bspw. die
-nderung der Einrichtungsregeln selbst) herangezogen.

Sie gelten - teilweise modifiziert - auch fnr Personenwahlen, bspw.
fnr die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmE#igen AbstEnden
durchgefnhrten Nachwahlen [8]. In gleicher Weise wEre es auch m%glich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlie#en oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
nbergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - nbersteuert werden.

[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos ver%ffentlicht sind:
| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter)
| Newsgroups: de.admin.infos,de.admin.news.misc
| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
|
| Archive-name: de-admin/dana-neuwahl
| Posting-frequency: weekly
| Last-modified: 1998-05-18
| URL: 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
regelmE#ig in de.admin.news.announce ver%ffentlicht wird:
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2022-08-26> 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 ErlEuterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise ergEnzt.

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. Weiterfnhrende Hinweise
----------------------------

Folgende Texte sind allgemein oder fnr 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: <2022-08-26> 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 D%blitz <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

+ Filterma#nahmen bei der Durchfnhrung 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 nber 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 k%nnen bei der Durchfnhrung des Einrichtungsverfahrens helfen:

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

+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
w%chentlich ver%ffentlicht in de.admin.news.announce
<https://www.dana.de/status.html>

+ GVV-Statusnbersicht
<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 MErz/April 2011 vollstEndig nberarbeitet und
neu gefasst.

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

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

Fnr Hinweise, Anregungen und VerbesserungsvorschlEge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frnhere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprnnglichen Fassung dieses Textes und seiner Entstehung
haben au#erdem beigetragen:

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

Herzlichen Dank!
--
Id: 48a99bd (HEAD -> master, tag: 2.2.10) 2025-04-13 11:56:51 +0200 Thomas Hochstein

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.answers

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.10
Last-modified: 2025-04-13
URL: https://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

ErlEuterungen 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. Vornberlegungen
1.1. Bedarf fnr eine neue Gruppe
1.2. Status quo: bestehende Gruppen und frnhere VorschlEge
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. SonderfElle

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

4. Abstimmungsphase
4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung
4.2. Inhalt und Aufbau eines CfV
4.3. Sonderfall: CfV mit pers%nlichem Wahlschein
4.4. Abstimmungsphase
4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E.
7.1. Gruppenl%schungen
7.2. Umbenennungen
7.3. -nderungen von Charta und/oder Kurzbeschreibung
7.4. StatusEnderungen
7.5. RegelEnderungen und Personenwahlen

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

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

[1] Ver%ffentlicht 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 ErlEuterungen genannten Quellen findet
sich noch einmal in Abschnitt 8.)

Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
nachfolgende, mindestens einw%chige Diskussion keinen gar zu heftigen Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im #berblick -------------------------------------------

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

Fnr de.* wird die kanonische Liste der bestehenden Newsgroups von der Moderation von de.admin.news.announce gefnhrt, die jeden Monat auch
eine entsprechende, digital signierte Steuernachricht (checkgroups)
versendet, mit der die meisten Newsserverbetreiber ihren
Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
Fnr die Aufstellung dieser Liste sind vielerlei M%glichkeiten denkbar;
in de.* entscheiden die Benutzer nber ihren Inhalt. -nderungen am Gruppenbestand - Neueinrichtung, L%schung oder Umbenennung von Gruppen
- werden in einem formalisierten Verfahren diskutiert und dann zur
Abstimmung gestellt.

Jedem Einrichtungsvorschlag sollte eine #berlegungsphase vorangehen,
in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
Status, Charta) einschlie#lich ihrer Einordnung in den bestehenden, hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden k%nnen. Am Ende dieser Vornberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe hei#en soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegennber bestehenden Gruppen abgrenzt. Mit der
Ver%ffentlichung dieses Vorschlags in de.admin.news.announce als Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
die in de.admin.news.groups gefnhrt wird, wird der Vorschlag auf
inhaltliche QualitEt und Akzeptanz abgeklopft und ggf. verEndert oder verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der Vorschlag abstimmungsreif erscheint. Die Ver%ffentlichung eines Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die Diskussionsphase und leitet in die Abstimmungsphase nber, 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 lEsst sich in folgende Phasen unterteilen,
die im Folgenden dann nEher erlEutert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information nber den status quo, BedarfsabschEtzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines f%rmlichen Einrichtungsvorschlag (RfD)
* Einreichung des RfD bei der Moderation von de.admin.news.announce

Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
enden die Vorbereitungen; das Verfahren wird in die Statusnbersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erhElt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prnft
den RfD (und die weiteren VerfahrensbeitrEge) auf Vereinbarkeit mit
den Regeln, nimmt die n%tigen Ver%ffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) fnr sich im Verlauf
des Verfahrens ergebende Fragen zur Verfngung.

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

0.3.2. Diskussionsphase

* Beginn mit Ver%ffentlichung des 1. RfD in de.admin.news.announce,
de.admin.news.groups und weiteren betroffenen Newsgroups
* %ffentliche Diskussion des Vorschlags in de.admin.news.groups
* Mindestdauer: 14 Tage
* Einreichung beliebig vieler weiterer RfDs mit geEnderten VorschlEgen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der nbrigen Teilnehmer zu ergrnnden; -nderungsvorschlEge k%nnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten er%rtert, alle
Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen m%chte oder
ob er den Vorschlag zurnckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten ver%ffentlichen RfD im Wesentlichen
nbereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
Rnckzug des Vorschlags oder Verfall durch Nichtbetreiben nber fnnf
Wochen) oder der Ver%ffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Ver%ffentlichung des 1. CfV in de.admin.news.announce und
den nbrigen Gruppen
* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
E-Mail bestEtigt
* Mindestdauer: 3 Wochen, H%chstdauer: 1 Monat (~ 4 Wochen)
* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
Abstimmenden
* einw%chige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgefnhrt, der die CfVs zur Ver%ffentlichung einreicht, die
Stimmen per E-Mail sammelt, bestEtigt und auszEhlt und am Ende das
Ergebnis der Abstimmung zur Ver%ffentlichung einreicht. Diese Aufgabe
kann der Proponent nbernehmen, er muss es aber nicht; da die
Durchfnhrung und AuszEhlung einer Abstimmung einen gewissen
technischen und organisatorischen Aufwand erfordert und auch Erfahrung
im Umgang mit ZweifelsfEllen - auch Manipulationsversuchen -
wnnschenswert ist, besteht die M%glichkeit, einen erfahrenen
Usenet-Teilnehmer um die #bernahme der Abstimmungsleitung zu bitten.
Einige Freiwillige haben sich zu diesem Zweck als "German Volunteer
Votetakers" (GVV) zusammengeschlossen.

Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und letztlich mit der Ver%ffentlichung des Ergebnisses. Daran schlie#t
sich ein einw%chiger Einspruchszeitraum an, in dem Regelverst%#e durch
einen Einspruch bemEngelt werden k%nnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskrEftig.

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 gnltigen 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. Vornberlegungen
==================

1.1. Bedarf fnr eine neue Gruppe
--------------------------------

Ganz am Anfang der #berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zunEchst die Frage, ob die angedachte Gruppe denn auch
tatsEchlich ben%tigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuknnftigen 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 nberfnllt ist.

Die zuknnftige NutzungsintensitEt der vorgeschlagenen Gruppe wird
dabei regelmE#ig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

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

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

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
zuknnftig einigerma#en intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tatsEchliche gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
und ob sie dies im Usenet tun m%chten. Es mag sehr wichtige Themen
geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
oder die anderswo diskutiert werden, ohne dass bei den Interessenten
der Wunsch besteht, ihre Diskussionen im Usenet zu fnhren. Die
mehrheitliche Ansicht geht nberdies dahin, dass es nicht sinnvoll ist,
fnr "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es nberwiegend als
wnnschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und f%rdern.

Siehe auch:

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
<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 frnhere VorschlEge ----------------------------------------------------------

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

Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
m%glicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
eine solche Gruppe, die dann spEter wieder aus der Gruppenliste
entfernt wurde? Aus diesen #berlegungen ergeben sich Hinweise auf die Erfolgsaussichten des Vorschlags und m%glicherweise auch Anregungen
fnr seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche -nderungen in Inhalt oder Begrnndung erneut einzubringen.

[3] Am bekanntesten dnrfte 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
Befnrworter 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 fnhrt oft zu besseren Ergebnissen als einsames Grnbeln im stillen KEmmerlein.

Auch in der Diskussion ist es f%rderlich, einen Vorschlag nicht
alleine argumentativ zu stntzen; nicht nur deshalb, weil eine Mehrzahl
von Interessenten, die sich auch selbst in die Diskussion einbringt, nberzeugender ein dauerhaftes Interesse signalisiert als ein
Einzelner. Auch aus psychologischen Grnnden ist es angenehmer, die
eigene Position nicht alleine vertreten zu mnssen.

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

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

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

| Ein CfV kann nicht ver%ffentlicht werden, wenn einer der folgenden
| Punkte noch unklar ist:
|
| o Name der Gruppe
| o Kurzbeschreibung der Gruppe
| o Charta der Gruppe
| o Status der Gruppe (moderiert oder unmoderiert)
| o der Name des Moderators im Falle einer moderierten Gruppe

Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
sich daher auch die Frage nach der Einordnung der neuen Gruppe in die bestehende Struktur der Hierarchie de.*, und in der Charta sollte
nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
auch die Abgrenzung zu thematisch Ehnlichen Gruppen ihren Platz
finden.

Sinnvoll ist es daher, sich zunEchst Gedanken nber 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
nberlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
demnach hei#en soll (2.1.); dann fehlt nur noch eine knackige
Zusammenfassung fnr die Kurzbeschreibung (2.2.).

Falls eine moderierte Newsgroup vorgeschlagen wird, mnssen auch der
oder die vorgesehenen Moderatoren feststehen; nberdies sollte ein
Konzept fnr die Moderation vorliegen und die technischen
Voraussetzungen hinreichend geklErt sein.

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

2.1.1. Einordnung

ZunEchst sollte die prospektive Gruppe sich in die bestehende
Namenshierarchie in de.* einpassen. de.* besteht nEmlich aus
thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
immer feineren thematischen VerEstelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollstEndig
logisch stringent, und regelmE#ig wird es nicht nur einen denkbaren
Platz geben, an den eine neue Gruppe passen wnrde.

Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
bemnhen, den bestm%glichen Ort fnr die neue Gruppe zu finden. Dazu
geh%rt sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.

Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
Einrichtungsregeln auszeichnet und daher nicht Thema dieser
ErlEuterungen 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 beschEftigen sich mit den
- im Usenet umfEnglich 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

* GerEte (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 schlie#lich:
de.comm.infosystems.* - WWW samt Webseitenerstellung
de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)

* de.comp.*
Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
so dazugeh%rt. Auch sie ist demnach umfangreich weiter
untergliedert, neben verschiedenen Einzelgruppen namentlich in

* Hardware:
de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks
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.* beschEftigt sich mit
FreizeitaktivitEten ("recreational activities") aller Art und
enthElt neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien
zu den Themen Musik h%ren und machen, Sport(arten), Spielen aller
Art, am Brett wie am Computer, Science Fiction und Fantasy,
Fernseh(seri)en, Filme und Heimkino und (Haus-)Tiere.

* de.sci.*
Die Unterhierarchie de.sci.* ist fnr 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 fnr Smalltalk
und entspannten Plausch als Diskussion und Informationsaustausch
vorgesehen; viele der verbliebenen Gruppen wnrden aber ebenso gut
nach de.soc.* passen.

* de.org.*
Die - gleichfalls kleine - Teilhierarchie de.org.* ist fnr
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 geh%ren das Bahnwesen, Autos und andere Fahrzeuge,
Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
Notfallrettung und MilitErwesen oder auch die Haushaltsfnhrung.

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 aussagekrEftig und allgemeinverstEndlich,
aber zugleich auch so kurz wie m%glich gewEhlt werden. Kryptische oder mehrdeutige Abknrzungen sollte man m%glichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, spEtestens aber in der Charta erlEutert werden.

Fnr die Wahl des Gruppennamens sind zudem technisch geprEgte
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 dnrfen nicht lEnger als 30 Zeichen werden und
mnssen mindestens je einen Buchstaben enthalten. Zu beachten ist
dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene
schon vor dem 15. Zeichen unterscheiden mnssen.

* 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 LEnge des Gruppennamens 71 Zeichen nicht
nberschreiten.

[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 ErgEnzung zum Gruppennamen das Thema kurz umrei#en. Im Gegensatz zur Charta, der ausfnhrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
gEngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelmE#ig versandten Steuernachrichten, die den aktuellen Gruppenbestand von de.*
enthalten.

Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muss kurz, knapp und fnr jeden verstEndlich sein. "Diskussion
nber" oder "Informationen von" sind zum Beispiel notorisch
nberflnssige Formulierungen. Hingegen sollten m%glichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
interessierte Nutzer m%glicherweise suchen werden. Da die
Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die meist auf 80 Spalten breiten
Terminals gelesen werden, ergibt sich eine BeschrEnkung fnr die LEnge
der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und
Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als
Richtwert gilt fnr die Kurzbeschreibung gew%hnlich eine MaximallEnge
von 60 Zeichen.

Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze Kurzbeschreibung anzeigen, wird er sich nblicherweise auf den Anfang
der Kurzbeschreibung beschrEnken. 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 fnr Kurzbeschreibungen finden sich in dem bereits genannten
Text "Die Newsgruppen der de-Hierarchie".

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

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

Es ist hilfreich, fnr das Thema der Gruppe einige Beispiele als nicht abschlie#ende AufzEhlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen m%glicherweise gesucht wird.
Dabei ist aber zu berncksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW ver%ffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verfngung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl m%glicherweise Name und
Kurzbeschreibung bei flnchtiger Durchsicht zu dieser Annahme fnhren
k%nnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdrncklich auszuschlie#en. Genauso sollte innerhalb der
Charta das Diskussionsthema von anderen, themenverwandten Gruppen
abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
nicht tunlich, weil ansonsten bei jeder Umbenennung oder L%schung der betreffenden Gruppen eine ChartaEnderung n%tig wnrde (siehe 7.3.).

Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
gelten sollen als sonst im Netz nblich sollte auch dies in der Charta
vermerkt werden. Zu denken wEre bspw. an die (ausdrnckliche) Akzeptanz
anonymer BeitrEge oder von Inseraten. Gleichfalls sollten vorgesehene ungewohnte technische Ma#nahmen - zu denken wEre hier bspw. an die EingangsbestEtigung von Postings per E-Mail durch die sog. Reflektoren
in den Testgruppen - durch die Charta legitimiert werden. In allen
diesen FEllen sollte einerseits berncksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdrncklich abgelehnt wird, sowohl wegen der unn%tigen VerlEngerung der Charta als auch, weil dies den Eindruck vermitteln
k%nnte, die entsprechenden Regeln und Konventionen hEtten nur dort
Geltung, wo sie ausdrncklich 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 Grnnde haben und zudem als feststehende Gewohnheiten betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut begrnndeten SonderfEllen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie m%glich gehalten werden; weitergehende ErlEuterungen und solche Regeln, die sich voraussichtlich hEufiger
Endern werden, geh%ren nicht in die Charta, sondern sollten Gegenstand
einer (regelmE#ig geposteten und nach M%glichkeit auch im WWW
bereitgestellten) Einfnhrung, 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 ErwEhnung finden;
die einzelnen angedachten Tags geh%ren dann in eine anderweitig
bereitgestellte ErlEuterung. Auch das Moderationskonzept einer
moderierten Gruppe geh%rt schon aufgrund seiner LEnge 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 Gefnhl fnr die Abfassung einer guten Charta zu
bekommen. Solche Beispiele finden sich in dem bereits genannten Text
"Die Newsgruppen der de-Hierarchie".

2.4. Status
-----------

Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status "moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
dann ohne weiteres in der Newsgroup ver%ffentlicht und weltweit
verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
stattdessen versendet der Newsserver, bei dem das Posting eingespeist
wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
mehrk%pfige Moderation). Diese entscheidet dann nber die
Ver%ffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
#bersichtlichkeit und h%heren inhaltlichen QualitEt, weil BeitrEge
vorgefiltert werden k%nnen; ihr Nachteil ist die zwangslEufig
entstehende Verz%gerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn bestEtigen muss. Sie eignen sich daher vor
allem fnr Anknndigungen oder FAQs. Ein Beispiel hierfnr ist de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen ver%ffentlicht werden, so dass die Gruppe auch fnr
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige #berprnfung der
Ver%ffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte ver%ffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer h%heren inhaltlichen QualitEt dienen und erm%glicht
vor allem den Ausschluss von bewussten St%rern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegrnndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden Verz%gerungen vor Ver%ffentlichung eines Beitrags den Fluss der
Diskussion st%ren und an Ver%ffentlichung ihrer BeitrEge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschEtzen; 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 BeitrEge so zeitnah wie
m%glich zu prnfen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zusEtzliche Angaben zur Moderation zu machen;
dazu geh%ren der oder die vorgesehene(n) Moderator(en) und die Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
fnr die Newsgroup zur Freigabe weitergeleitet werden sollen. Au#erdem
muss die Kurzbeschreibung entsprechend ergEnzt werden. Schlie#lich
sollte fnr die Durchfnhrung der Moderation sinnvollerweise ein Konzept vorliegen und die technischen Voraussetzungen geschaffen und getestet
sein.

* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
Ver%ffentlichung des Vorschlags seine entsprechende Bereitschaft
erklErt haben; in der Regel wird es sich empfehlen, ein mehrk%pfiges
Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
auch im Falle eines mehrw%chigen Urlaubs oder gar eines dauerhaften
Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
interessiert sein mag - die Moderation handlungsfEhig bleibt und
BeitrEge weiterhin ver%ffentlicht werden k%nnen. Fnr moderierte
Diskussionsgruppen wird regelmE#ig ein ausreichend gro#es Team
zwingend vorzusehen sein, damit BeitrEge zumindest tagsnber zeitnah
ver%ffentlicht werden k%nnen.

Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
Einreichungen bewerten zu k%nnen, von den zu erwartenden
Diskussionsteilnehmern akzeptiert werden und schlie#lich absehbar
fnr lEngere Zeit fnr diese TEtigkeit zur Verfngung stehen. Erfahrung
im Usenet und ggf. die notwendigen technischen Kenntnisse zur
Durchfnhrung der Moderation sind hilfreich.

* Wenn die (erste) Moderation personell feststeht, stellt sich als
nEchstes die Frage, welche E-Mail-Adresse fnr Einreichungen
("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
in jedem Newsserver oder an einer zentralen Stelle (den Relays fnr
moderators.isc.org) in der Konfiguration vermerkt werden, sollte
sich also so selten wie m%glich Endern; au#erdem sollte die Adresse
zuverlEssig erreichbar sein und ggf. die M%glichkeit fnr
ausreichende Spamfilterung bieten; langjEhrig aktive und regelmE#ig
ver%ffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
Spam an.

Daneben sollte eine weitere Adresse ver%ffentlicht werden, nber die
der Moderator oder die Moderation kontaktiert werden k%nnen, ohne
dass eine Ver%ffentlichung erfolgt, um bspw. fnr Anfragen erreichbar
sein.

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

* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
welchen Kriterien BeitrEge akzeptiert oder zurnckgewiesen werden, ob
sie ggf. verEndert ver%ffentlicht werden k%nnen und wie mit
Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
mehrk%pfigen Moderation stellt dies eine einheitliche Handhabung
sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
werden und danach (regelmE#ig) ver%ffentlicht werden.

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

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
M%glichkeit, einen per E-Mail nbersandten Beitrag unter Beibehaltung
der wesentlichen Informationen auch im Header - aber unter Wegfall
mancher und ErgEnzung anderer Headerzeilen - als Posting zu
ver%ffentlichen. Insbesondere dann, wenn mehr als eine Person -
parallel - an der Moderation beteiligt sein soll (was sich
mittlerweile als Regelfall etabliert haben dnrfte), empfiehlt es
sich, das entsprechende Zusammenwirken auch technisch zu
unterstntzen. In der Regel wird die Moderation einer Newsgroup also
die Installation entsprechender Software auf dem eigenen Rechner
oder sogar die Einrichtung auf einem nbers 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 Verfngung zu stellen. Die Auswahl und Erprobung der
vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
Kontaktaufnahmen sollten aber spEtestens parallel zum laufenden
Einrichtungsverfahren erfolgen; Tests k%nnen bspw. in der Newsgroup
de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<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 nber 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. SonderfElle
----------------

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

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

Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe fnr
Ausrnstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
eingerichtet werden. Dies geschieht regelmE#ig durch Umbenennung der
bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
also auch dazu Informationen enthalten.

* Einrichtung einer neuen Teilhierarchie

Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
vorgeschlagen werden soll, sondern direkt mehrere, thematisch
zusammenhEngende, also auf diese Weise eine neue Teilhierachie
entsteht.

Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
"de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
mit K%dern zu tun haben. Die entsprechenden Informationen - Name,
Kurzbeschreibung, Charta - mnssen 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 fnr
alle Gruppen die notwendigen Informationen bereitstellen.

Zu berncksichtigen ist, dass VorschlEge grundsEtzlich nicht "en
bloc" zur Abstimmung gestellt werden k%nnen; vielmehr ist nber jeden
Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
Teil 7 folgende Vorgaben:

| #bertragbarkeit: Stimmen k%nnen nicht auf einen anderen
| Abstimmungsvorschlag nbertragen werden. Eine Stimme zEhlt nur fnr
| GENAU DEN Vorschlag, fnr den sie abgegeben wurde. Insbesondere
| darf eine Stimme fnr oder gegen eine Newsgruppe mit einem
| bestimmten Namen NICHT als Stimme fnr 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 gezEhlt
| werden. #ber jede Gruppe wird einzeln abgestimmt, Verknnpfungen
| von Wahlen sind nicht m%glich.

* Diskussion mehrerer Alternativen

Ziel der Diskussion sollte es regelmE#ig sein, am Ende der
Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
Das schlie#t nicht aus, in der Diskussion zunEchst mehrere denkbare
Alternativen vorzuschlagen; die Diskussion sollte aber schlie#lich
zu einem mehrheitsfEhigen Vorschlag fnhren. Ggf. kann dazu auch ein
unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
sich ausschlie#ende Alternativen zur Abstimmung zu stellen sollte
nach M%glichkeit vermieden werden, weil die Abstimmung sonst
einerseits schnell sehr kompliziert wird und andererseits die Gefahr
besteht, dass entweder kein Vorschlag eine Mehrheit erhElt (obwohl
die Mehrzahl der Abstimmenden durchaus generell fnr eine Einrichtung
der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
VorschlEgen angenommen wird, das so niemand gewollt hat.

Die fnr die Abstimmung in diesem Fall zu beachtenden Regeln fnr
"kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
und lauten folgenderma#en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h%chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird nber die Einrichtung jeder einzelnen Gruppe gemE# den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zusEtzlich 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 VerhEltnis Zustimmung : Ablehnung aufweist.

Siehe dazu auch:

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf D%blitz <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 Vornberlegungen abgeschlossen sind, kann das "offizielle" Einrichtungsverfahren mit der Abfassung eines f%rmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prnfung ver%ffentlicht wird.

3.1. Inhalt und Aufbau eines RfD
--------------------------------

3.1.1. Inhalt

Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
2. dargestellten notwendigen Informationen und einer Begrnndung des Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit fnr die bzw. dem Erfolg der
vorgeschlagenen neuen Gruppe zu nberzeugen.

#blicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begrnndung, die den Hintergrund fnr den Vorschlag und die #berlegungen insbesondere zu den bereits oben unter 1. ("Vornberlegungen")
genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
Monaten vorzunehmen ("Trafficnachweis"). Au#erdem enthElt der RfD
natnrlich 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 fnr die Kommunikation mit der Moderation von de.admin.news.announce und fnr
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.

Schlie#lich ist auch zu entscheiden, in welchen Gruppen der RfD
ver%ffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zusEtzlich 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 eingeschrEnkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natnrlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
stattfinden oder in denen man sich Interessen an der neuen Gruppe
erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
m%glich und nur so lang wie n%tig sein sollte; dies schon deshalb,
weil in nbermE#ig viele Gruppen verteilte Postings heutzutage
m%glicherweise als Spam ausgefiltert werden.

Eine Ver%ffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im EinverstEndnis mit deren Moderation. In Gruppen au#erhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.E. kann der Proponent nach Ver%ffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") ver%ffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden k%nnen.

3.1.2. Formale Gestaltung

Fnr die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich #blichkeiten entwickelt. Es empfiehlt
sich auch hier, einige Eltere 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 / Begrnndung
| ----------- ----------
|
| [Begrnndung, 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 nbermittelt
werden, in denen der RfD ver%ffentlicht werden soll. Der RfD kann auch
bereits einschlie#lich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehEngte Textdatei, nbermittelt
werden.

#blicherweise wird die Moderation den Eingang des RfD bestEtigen und
ihn in den w%chentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation ver%ffentlicht wird. Danach wird ein Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
nberprnft, ggf. Rncksprache mit dem oder den Proponenten nimmt und ihn schlie#lich in de.admin.news.announce und den nbrigen Gruppen
ver%ffentlicht.

Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, k%nnen diese in der Regel mit dem Verfahrensbetreuer diskutiert und geklErt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben nblicherweise bereits lEngerfristige Erfahrungen mit de.* und dem Einrichtungsverfahren gesammelt und k%nnen daher im Zweifel Tips und
Hinweise geben oder beratend tEtig 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: <2022-08-26> Moderationskonzept der derzeitigen Moderation
<https://dana.de/modkonzept.html>

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

Nachdem die Moderation den RfD ver%ffentlicht hat, findet in de.admin.news.groups die Diskussion nber den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf EinwEnde und Kritik eingehen und ggf. ihre
Begrnndung verfeinern.

HEufig wird die Diskussion sinnvolle ErgEnzungen zum ursprnnglichen
Vorschlag bringen, die in einen neuen, geEnderten Vorschlag
eingearbeitet werden k%nnen. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur Ver%ffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begrnndung, warum welche VorschlEge aufgenommen oder
verworfen wurden, enthElt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, k%nnen auch mehrere weitere RfDs ver%ffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unn%tig verlEngert oder verz%gert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu ver%ffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden VerbesserungsvorschlEge 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 VorschlEge und
-nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen geEnderten Vorschlag als
weiteren RfD zu ver%ffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
m%glichst konstruktiv gefnhrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer ausschlie#lich erfreulich sein wird; de.admin.news.groups ist auch
insofern ein Spiegel des Usenets als es dort neben gutwilligen
Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden Teilnehmern auch starrk%pfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. #berleitung zur Abstimmung oder Rnckzug des Vorschlags -----------------------------------------------------------

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

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgnltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten ver%ffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen nbereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
-nderungen zu ver%ffentlichen.

Nach M%glichkeit sollte am Ende der Diskussion nur noch ein einziger, einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls mnssen aber
fnr 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 nber einen Vorschlag findet per E-Mail statt. Die
abgegebenen Stimmen werden wEhrend des Abstimmungszeitraums an die E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszEhlt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer ver%ffentlicht. Die Durchfnhrung 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 Durchfnhrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu nberlassen.

4.1. Voraussetzungen fnr die Durchfnhrung einer Abstimmung ----------------------------------------------------------

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

* Fnr die Durchfnhrung der Abstimmung ben%tigt man einen
E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
nach M%glichkeit nicht mit der "normalen" E-Mail-Adresse des
Abstimmungsleiters identisch sein, damit keine MissverstEndnisse
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 fnhren,
dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
von Webhosting- oder Internetzugangsanbietern.

Siehe dazu auch:

+ Zu Abstimmadressen und Filtermassnahmen
| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
| Filterma#nahmen bei der Durchfnhrung 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 dafnr geeignete Software zu verwenden,
die PlausibilitEtsprnfungen vornimmt, BestEtigungen per E-Mail
versenden kann und Auswertungen automatisch erstellt.

Die verbreitetste Softwarel%sung dafnr ist UseVote; mehr
Informationen dazu und eine Downloadm%glichkeit gibt es auf
<http://www.usevote.de/>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
haben sich einige regelmE#ige Teilnehmer in de.admin.news.* dazu
bereiterklErt, ungefilterte Abstimmungsaccounts einzurichten und die
eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.E.
zu erm%glichen. Dazu zEhlen (Stand 04/2011) u.a.

- Ralph Angenendt <ihr.name@strg-alt-entf.org>
- Ralf D%blitz <doeblitz@doeblitz.net>
- Karsten Dnsterloh <kd-usenet@tprac.de>
- Michael Grimm <trashcan@odo.in-berlin.de>
- Emil Schuster <emil@wieslauf.sub.de>

Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
abzustimmen.

* Daneben besteht auch die M%glichkeit, die Abstimmung gar nicht
selbst durchzufnhren, sondern damit einen Dritten zu beauftragen,
der weitergehende technische M%glichkeiten oder gr%#ere Erfahrungen
mit der Durchfnhrung von Abstimmungen hat. #berdies ist es zwar
zulEssig und auch der von den Einrichtungsregeln ursprnnglich
vorgesehene Regelfall, dass der Proponent auch die Abstimmung
durchfnhrt, manchmal ist es aber erwnnscht, damit einen unabhEngigen
Dritten zu beauftragen.

Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
erfahrene Votetaker haben sich nberdies 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, fnr ihn die Abstimmung durchzufnhren. In den letzten
Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
Mitglieder der GVV durchgefnhrt.

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 fnr 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 fnr die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.

Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
h%chstens einen Monat betragen. #blicherweise wird diese Frist nicht ausgesch%pft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV ver%ffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es nblich, Abstimmungen
um Mitternacht enden zu lassen. Daher k%nnten sich bei einer
Abstimmungsdauer von einem Monat und Ver%ffentlichung des 1. CfV bspw.
um 16:30 Uhr unn%tige Diskussionen ergeben, ob damit nicht die
H%chstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) nberschritten wird.

Schlie#lich muss der CfV mit dem letzten RfD im wesentlichen
nbereinstimmen, wie Teil 6 der Einrichtungsregeln festhElt:

| 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
| nbereinstimmen.

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 AbstimmungsmodalitEten; an diesen
dnrfen keine nber die Behebung von Schreibfehlern o.E. hinausgehenden -nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor diskutierte. Eine -nderung der Begrnndung - soweit sie nberhaupt im
CfV wiederholt wird - ist hingegen regelmE#ig unproblematisch.

#blich ist es, auf Basis des letzten ver%ffentlichen RfD einen CfV zu entwerfen. Dabei kann der Begrnndungsteil geknrzt werden oder ganz
entfallen und durch einen Verweis auf die gefnhrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefngt werden dann die AbstimmungsmodalitEten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele fnr
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unnblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nEmlich als nberflnssig; bei komplexeren Abstimmungen hingegen wnrde
die Darstellung aller m%glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma#en unnbersichtlich und aufwendig,
dass regelmE#ig darauf verzichtet wird. Wenn jedoch die einzelnen Abstimmungsm%glichkeiten dargestellt werden, dann mnssen sowohl die Abstimmungsm%glichkeiten fnr wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu vermeiden.

Beispiele fnr CfVs finden sich in de.admin.news.announce. Eine
m%gliche Gestaltung wEre folgende:

| 1. CfV (Abstimmungsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begrnndung
| ----------- ----------
|
| [kurze Begrnndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| AbstimmungsmodalitEten
| ----------------------
|
| Votetaker : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein : Untenstehendes Formular ist zu verwenden. M%glich sind
| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gnltigen Fassung, die in de.admin.infos
| und unter <https://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| ver%ffentlicht sind. Sie erlEutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Hinweise zur Abstimmung und
| Informationen zur Datenverarbeitung (Art. 13 DSGVO)
| ---------------------------------------------------
|
| GezEhlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestEtigt; die komplette
| Abstimmungs-E-Mail und die Stimmdaten - Name, E-Mail-Adresse und Inhalt
| der Stimmabgabe - werden bis vier Wochen nach endgnltigem Abschluss des
| Verfahrens (Umsetzung nach Ablauf der Einspruchsfrist) beim Votetaker
| gespeichert und zur Erstellung des Ergebnisses verarbeitet.
|
| #blicherweise erfolgt eine SammelbestEtigung der bis dahin abgegebenen
| Stimmen durch Ver%ffentlichung von Namen und E-Mail-Adressen aller
| Abstimmungsteilnehmer in einem 2. CfV. Auch im nach Ende der Abstimmung
| ver%ffentlichten Ergebnis werden Namen, E-Mail-Adresse und Inhalt der
| Stimmabgabe fnr alle Abstimmenden genannt.
|
| Auf Anfrage k%nnen die gespeicherten Daten an die Moderation von
| de.admin.news.announce nbermittelt werden.
|
| Speicherung, Verarbeitung und Ver%ffentlichung sowie ggf. #bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die fnr
| eine Wertung und Ver%ffentlichung der Stimmabgabe entsprechend des
| Hinweises im Wahlschein notwendig ist. Die Einwilligung kann jederzeit
| durch Mitteilung per E-Mail an den Votetaker mit Wirkung fnr die Zukunft
| widerrufen werden. Die Wertung und Ver%ffentlichung 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#e Auswertung der Abstimmung nachweisen
| zu k%nnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft nber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - L%schung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - EinschrEnkung der Datenverarbeitung gemE# Art. 18 DSGVO
| - Datennbertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zustEndigen Aufsichtsbeh%rde nach Art. 77 DSGVO
|
| Diese Rechte k%nnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| ZustEndige Aufsichtsbeh%rde ist in diesem Fall [Aufsichtsbeh%rde].
|
| =-=-=-=-=-=-=-=- 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 M%glichkeit vorzusehen, den
tatsEchlichen Namen anzugeben, da m%glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
geh%rt die Liste der Gruppen dazu, in denen der RfD ver%ffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlie#lich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehEngte Textdatei,
nbermittelt werden.

Die Ver%ffentlichung des CfVs wird nblicherweise lEnger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von de.admin.news.announce nach dem 4-Augen-Prinzip nberprnft wird. Daher
kann - und sollte - der 1. CfV ruhig m%glichst frnhzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Ver%ffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Sonderfall: CfV mit pers%nlichem Wahlschein ------------------------------------------------

ErgEnzend zu der nblichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthElt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die M%glichkeit einer Abstimmung unter Verwendung pers%nlicher Wahlscheine vor.

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

Diese Vorgehensweise soll u.a. verhindern, dass vorausgefnllte
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 gnltig sein, d.h. E-Mails entgegennehmen muss, nberprnfbar - denn nur wer eine gnltige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.

Da allerdings weiterhin andere Manipulationsm%glichkeiten verbleiben
und der Aufwand fnr die Durchfnhrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgefnhrt.

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

[5] Der Vorschlag und die entsprechende Begrnndung 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
---------------------

WEhrend der drei- oder vierw%chigen (maximal aber einmonatigen) Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach M%glichkeit einigerma#en
zeitnah, am besten automatisiert - per E-Mail bestEtigt werden; in
dieser BestEtigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse fnr den Abstimmenden registriert wurden.
Fnr Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die BestEtigung versandt werden, um sicherzustellen, dass diese Stimme auch tatsEchlich vom angegebenen
Absender stammte (und die Abstimmadresse replyfEhig ist, d.h. E-Mail
dort empfangen werden kann). Au#erdem sollte in der BestEtigung
angegeben sein, wie eine Stimme nachtrEglich geEndert oder komplett zurnckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet ver%ffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es nblich, einen 2. CfV zu ver%ffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die Stimmabgaben!) enthElt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ungnltig gewertet werden. Weil auch der 2.
CfV im Rahmen der nblichen Bearbeitungszeiten regelmE#ig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen ver%ffentlicht werden
wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei
Tage vor dem geplanten Ver%ffentlichungszeitraum einzureichen.

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

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

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

Dabei werden zunEchst die JA- und NEIN-Stimmen sowie Enthaltungen
gezEhlt. 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 Rncksprache 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 genngen (Angabe eines falschen oder nicht
vollstEndigen Namens, nicht replyfEhige Abstimmadresse), dnrfen nicht
gewertet werden. Der Votetaker sollte auch die M%glichkeit von Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
IdentitEten, Weitergabe des Wahlscheins au#erhalb der Gruppen, in
denen er ver%ffentlicht wurde, Beeinflussung der Abstimmung durch "Campaigning") im Auge behalten und entsprechende #berprnfungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern geklErt 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 frnheren ZweifelsfEllen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung nber den konkret entschiedenen
Einzelfall hinaus haben und nicht spEter revidiert wurden, unter <https://www.dana.de/archiv.html> auch im Web ver%ffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, berncksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver%ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrnckliche EinwilligungserklErungen erforderlich sind.

Danach ist eine Ergebnisver%ffentlichung ("Result") vorzubereiten.
#blich ist es, die Gesamtzahl der gnltigen Stimmen und sodann fnr
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungnltigen 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 Ver%ffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungnltige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begrnndung fnr die Nichtwertung. Dies erm%glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen FEllen kann die Ver%ffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dnrfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Grnnden die Verwendung von Pseudonymen
akzeptiert wird.

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

Mit der Ver%ffentlichung des Results durch die Moderation von de.admin.news.announce beginnt eine einw%chige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begrnndung einlegen kann, dass
bei der Durchfnhrung der Abstimmung schwerwiegende UnregelmE#igkeiten
gab. Das k%nnen bspw. technische Probleme mit der Abstimmadresse sein,
die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
oder einer der bereits unter 4.5. angerissenen Manipulationsversuche.

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskrEftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die nblicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* fnhren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergEnzen.

Ansonsten wird die Moderation nber eingegangene Einsprnche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das ver%ffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
wenn nber den Einspruch abschlie#end entschieden ist.

Das Einrichtungsverfahren ist damit beendet.

6. Sonderfall: Vereinfachtes Verfahren (VV) ===========================================

Nicht jeder marginale -nderungsvorschlag muss zwingend das vorstehend geschilderte umfangreiche Verfahren nach sich ziehen. Fnr kleinere
-nderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. "Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und Abstimmungsphase zugunsten einer Widerspruchsl%sung entfallen.

Bei einem VV wird der entsprechende -nderungsvorschlag, der dieselben Anforderungen wie ein RfD erfnllen muss (siehe 3.1.), zur
Ver%ffentlichung in de.admin.news.announce bei <moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darnber
hinaus ausdrncklich darauf hinweisen, dass die vorgeschlagene -nderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.

Nach Abschluss der Widerspruchsfrist stellt die Moderation von de.admin.news.announce entweder fest, dass kein Widerspruch
eingegangen ist und der Vorschlag angenommen wurde, oder
ver%ffentlicht Namen und E-Mail-Adresse der Widerspruchsfnhrer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgefnhrt oder aufgegeben
werden.

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

7. L%schungen, Umbenennungen, Status- und RegelEnderungen u.E. ==============================================================

Bereits die Einleitung ("#bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" trEgt und sich die Ausfnhrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschEftigen, sie
aber fnr alle -nderungen am Gruppenbestand analog gelten und auch fnr
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden k%nnen (und regelmE#ig auch angewendet werden):

| Diese Spielregeln gelten fnr 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
| herbeizufnhren.
|
| 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 Grnndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschEftigen. Je gr%#er die Hierarchie wurde (und je stErker
die Nutzerzahlen wieder zurnckgingen), desto hEufiger wurden dann
-nderungs- und L%schungsverfahren, aber auch RegelEnderungen.

GrundsEtzlich ist die Vorgehensweise in diesen FEllen den
Einrichtungsverfahren vergleichbar, insbesondere die
BegrnndungsansEtze sind aber freilich andere.

7.1. Gruppenl%schungen
----------------------

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

* Insofern wird die Begrnndung eines L%schungsvorschlags in der Regel
primEr auf eine statistische Auswertung nber einen lEngeren Zeitraum
(mindestens 12 Monate, im Zweifel aber auch lEnger) gestntzt, um zu
belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
Bereich abrutscht, k%nnen niedrige Nutzungszahlen nur ein Hinweis
auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
AnlEsse reagiert und die Gruppe wieder mit Leben fnllt. Das spricht
eher gegen eine L%schung der Gruppe.

[6] <http://usenet.dex.de/>

* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
zur L%schung vorgeschlagenen Gruppe zuknnftig diskutiert werden
sollen. Wenn die Gruppe in einem gr%#eren thematischen Zusammenhang
steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
benennen, was dann wiederum fnr eine niedrigere Schwelle zur
L%schung spricht, denn so werden einzelne, mittlerweile weniger
intensiv diskutierte Unterbereiche eines gr%#eren Themas wieder
thematisch zusammengefasst.

Ein Beispiel dafnr wEre die Teilhierarchie
de.comp.office-pakete.ms-office.*, die ursprnnglich 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,
wnrde eine L%schung 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, fnr
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 FEllen ist eine
besonders kritische Prnfung erforderlich, ob sich die Gruppe nicht
wieder beleben lEsst, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema v%llig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur L%schung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

* Wenn die letzte Gruppe einer Teilhierarchie gel%scht wird, stellt
sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
Teilhierarchie").

So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
Gruppen

- de.comm.protocols.tcp-ip
- de.comm.protocols.misc

Wnrde man die Gruppe de.comm.protocols.tcp-ip l%schen, k%nnte man
die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
de.comm.protocols umbenennen, um so den Namen zu verknrzen und die
Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
spricht, dass Umbenennungen technisch nicht m%glich sind, sondern
nur durch eine L%schung der bestehenden Gruppe und die
Neueinrichtung der Gruppe mit dem geEnderten Namen umgesetzt werden
k%nnen (siehe 7.2.).

7.2. Umbenennungen
------------------

Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
mit anderen -nderungen am Gruppenbestand. Dass eine Gruppe ohne
weiteren Anlass blo# an eine andere Stelle im Hierarchiebaum (siehe
2.1.1.) verschoben wird, ist sehr selten.

Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht m%glich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zusEtzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefEhr eine Woche spEter von der
L%schung der Gruppe mit dem alten Namen. Dies fnhrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmE#ig in die
Gruppe hineinschauen, sie dann pl%tzlich nicht mehr finden k%nnen.
Eine solche Umbenennung will also wohlnberlegt sein.

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

Neben dem Namen k%nnen auch alle anderen Attribute einer Gruppe (fnr
deren Beschreibung siehe 2.) geEndert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene ChartaEnderung die Folge einer
Reorganisation, also der Einrichtung oder L%schung anderer Gruppen, so
dass klarstellende -nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gel%schten
oder sonstwie geEnderten Newsgroups aus der Charta entfernt werden
mnssen. 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 KurzbeschreibungsEnderung ist dabei im wesentlichen
kein technischer Vorgang. GeEnderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden k%nnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden ChartaEnderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. StatusEnderungen
---------------------

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

Soll eine bisher unmoderierte Gruppe zuknnftig moderiert sein, fnhrt
dies dazu, dass Postings nber Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
fnhren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuknnftig 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 BeitrEge
verloren gehen.

Diese technischen Probleme mnssen bereits in der Diskussionsphase berncksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zusEtzlichen 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 zusEtzlichen ErwEgungen
fnr die Einrichtung moderierter Gruppen entsprechend.

7.5. RegelEnderungen und Personenwahlen
---------------------------------------

Neben -nderungen am Gruppenbestand k%nnen - und werden - die
Einrichtungsregeln analog auch fnr andere Entscheiungen (bspw. die
-nderung der Einrichtungsregeln selbst) herangezogen.

Sie gelten - teilweise modifiziert - auch fnr Personenwahlen, bspw.
fnr die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmE#igen AbstEnden
durchgefnhrten Nachwahlen [8]. In gleicher Weise wEre es auch m%glich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlie#en oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
nbergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - nbersteuert werden.

[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos ver%ffentlicht sind:
| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter)
| Newsgroups: de.admin.infos,de.admin.news.misc
| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
|
| Archive-name: de-admin/dana-neuwahl
| Posting-frequency: weekly
| Last-modified: 1998-05-18
| URL: 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
regelmE#ig in de.admin.news.announce ver%ffentlicht wird:
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2022-08-26> 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 ErlEuterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise ergEnzt.

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. Weiterfnhrende Hinweise
----------------------------

Folgende Texte sind allgemein oder fnr 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: <2022-08-26> 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 D%blitz <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

+ Filterma#nahmen bei der Durchfnhrung 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 nber 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 k%nnen bei der Durchfnhrung des Einrichtungsverfahrens helfen:

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

+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
w%chentlich ver%ffentlicht in de.admin.news.announce
<https://www.dana.de/status.html>

+ GVV-Statusnbersicht
<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 MErz/April 2011 vollstEndig nberarbeitet und
neu gefasst.

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

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

Fnr Hinweise, Anregungen und VerbesserungsvorschlEge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

9.2. Frnhere Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der ursprnnglichen Fassung dieses Textes und seiner Entstehung
haben au#erdem beigetragen:

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

Herzlichen Dank!
--
Id: 48a99bd (HEAD -> master, tag: 2.2.10) 2025-04-13 11:56:51 +0200 Thomas Hochstein

--- Synchronet 3.21a-Linux NewsLink 1.2