[continued from previous message]

| de.admin.news.announce �bermittelt werden.
|
| Speicherung, Verarbeitung und Ver�ffentlichung sowie ggf. �bermittlung
| erfolgen aufgrund Einwilligung (Art. 6 Abs. 1 lit. a) DSGVO), die f�r
| 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 f�r 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 ordnungsgem��e Auswertung der Abstimmung nachweisen
| zu k�nnen (Art. 6 Abs. 1 lit. f) DSGVO).
|
| Jeder Abstimmungsteilnehmer hat das Recht auf
| - Auskunft �ber die Datenverarbeitung nach Art. 15 DSGVO
| - Berichtigung unrichtiger Daten nach Art. 16 DSGVO
| - L�schung von Daten unter den Voraussetzungen des Art. 17 DSGVO
| - Einschr�nkung der Datenverarbeitung gem�� Art. 18 DSGVO
| - Daten�bertragbarkeit nach Art. 20 DSGVO
| - Beschwerde bei der zust�ndigen Aufsichtsbeh�rde nach Art. 77 DSGVO
|
| Diese Rechte k�nnen durch E-Mail an den Votetaker geltend gemacht werden.
|
| Zust�ndige 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
tats�chlichen Namen anzugeben, da m�glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

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

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

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

Erg�nzend zu der �blichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enth�lt, sehen die Einrichtungsregeln in ihrem Teil
6a auch die M�glichkeit einer Abstimmung unter Verwendung pers�nlicher Wahlscheine vor.

Diese 1998/1999 eingef�hrte Verfahrensweise [5] soll die Manipulation
von Abstimmungen erschweren, indem sie das normale
Abstimmungsverfahren durch ein Zwei-Schritt-Verfahren ersetzt: der Abstimmungswillige muss zun�chst einen pers�nlichen Wahlschein beim
Votetaker anfordern, der ein kodiertes, eindeutig dem
Abstimmungswilligen zuzuordnendes Merkmal erh�lt und sodann diesen
pers�nlichen - und an seine E-Mail-Adresse gekoppelten - Wahlschein
ausgef�llt zur�cksenden. Andere Wahlscheine oder die Verwendung einer
anderen E-Mail-Adresse werden nicht akzeptiert.

Diese Vorgehensweise soll u.a. verhindern, dass vorausgef�llte
Wahlscheine verbreitet werden, die durch beliebige Netzteilnehmer ohne
Kenntnis des Verfahrens (oder gar ohne Kenntnis von der Existenz des
Usenets) dann an die Abstimmungsadresse versandt werden. Als
Nebeneffekt wird damit die zur selben Zeit festgeschriebene Forderung,
dass die zur Abstimmung verwendete Adresse g�ltig sein, d.h. E-Mails entgegennehmen muss, �berpr�fbar - denn nur wer eine g�ltige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.

Da allerdings weiterhin andere Manipulationsm�glichkeiten verbleiben
und der Aufwand f�r die Durchf�hrung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgef�hrt.

In der Abstimmungssoftware Usevote (siehe 4.1.) ist die Durchf�hrung
solcher Verfahren implementiert.

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

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

W�hrend der drei- oder vierw�chigen (maximal aber einmonatigen) Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar
sein. Jede abgegebene Stimme sollte - nach M�glichkeit einigerma�en
zeitnah, am besten automatisiert - per E-Mail best�tigt werden; in
dieser Best�tigung sollte angegeben sein, welche Stimme(n) und welcher
Name sowie welche Mailadresse f�r den Abstimmenden registriert wurden.
F�r Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu
erfassen; an diese sollte auch die Best�tigung versandt werden, um sicherzustellen, dass diese Stimme auch tats�chlich vom angegebenen
Absender stammte (und die Abstimmadresse replyf�hig ist, d.h. E-Mail
dort empfangen werden kann). Au�erdem sollte in der Best�tigung
angegeben sein, wie eine Stimme nachtr�glich ge�ndert oder komplett zur�ckgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet
wurde, die nicht im Usenet ver�ffentlicht werden soll.)

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

Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
endet die Abstimmung. Versp�tete Stimmen werden nicht mehr gez�hlt.

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

Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgez�hlt.

Dabei werden zun�chst die JA- und NEIN-Stimmen sowie Enthaltungen
gez�hlt. Wenn eine Person mehrere Stimmen abgegeben hat, gilt die
zuletzt abgegebene Stimme. Bei Unklarheiten hinsichtlich des Inhalts
der Stimmabgabe oder des Namens oder der Mailadresse sollte mit dem Abstimmenden R�cksprache gehalten werden. Das gleiche gilt, wenn
mehrere Stimmen offenbar von derselben Person stammen (gleicher Name, unterschiedliche Mailadresse oder umgekehrt), um festzustellen, ob nur
die letzte Stimme zu werten ist oder es sich doch um verschiedene
Personen handelt.

Stimmen, die nicht eindeutig sind, oder die in anderer Weise nicht den Einrichtungsregeln gen�gen (Angabe eines falschen oder nicht
vollst�ndigen Namens, nicht replyf�hige Abstimmadresse), d�rfen nicht
gewertet werden. Der Votetaker sollte auch die M�glichkeit von Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
Identit�ten, Weitergabe des Wahlscheins au�erhalb der Gruppen, in
denen er ver�ffentlicht wurde, Beeinflussung der Abstimmung durch "Campaigning") im Auge behalten und entsprechende �berpr�fungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern gekl�rt werden. Im Einzelfall kann auch die
Meinung der Moderation zu einer umstrittenen Frage eingeholt werden;
es empfiehlt sich, zumindest die Entscheidungen der Moderation aus
vergangenen Jahren zu fr�heren Zweifelsf�llen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung �ber den konkret entschiedenen
Einzelfall hinaus haben und nicht sp�ter revidiert wurden, unter <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, ber�cksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver�ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdr�ckliche Einwilligungserkl�rungen erforderlich sind.

Danach ist eine Ergebnisver�ffentlichung ("Result") vorzubereiten.
�blich ist es, die Gesamtzahl der g�ltigen Stimmen und sodann f�r
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ung�ltigen Stimmabgaben zu nennen. Angenommen ist der Vorschlag, wenn mindestens 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
ung�ltige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begr�ndung f�r die Nichtwertung. Dies erm�glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen F�llen kann die Ver�ffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere d�rfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Gr�nden die Verwendung von Pseudonymen
akzeptiert wird.

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

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

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskr�ftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die �blicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* f�hren, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
erg�nzen.

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

Das Einrichtungsverfahren ist damit beendet.

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

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

Bei einem VV wird der entsprechende �nderungsvorschlag, der dieselben Anforderungen wie ein RfD erf�llen muss (siehe 3.1.), zur
Ver�ffentlichung in de.admin.news.announce bei <[email protected]>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss dar�ber
hinaus ausdr�cklich darauf hinweisen, dass die vorgeschlagene �nderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.

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

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

7. L�schungen, Umbenennungen, Status- und Regel�nderungen u.�. ==============================================================

Bereits die Einleitung ("�bersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" tr�gt und sich die Ausf�hrungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen besch�ftigen, sie
aber f�r alle �nderungen am Gruppenbestand analog gelten und auch f�r
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden k�nnen (und regelm��ig auch angewendet werden):

| Diese Spielregeln gelten f�r die Einrichtung oder Entfernung einer
| Gruppe sowie �nderung ihrer Attribute. Die Attribute einer Gruppe
| sind: Gruppenname, Kurzbeschreibung, Charta und Status (moderiert/
| unmoderiert) sowie bei moderierten Gruppen die Moderatoren.
|
| Es spricht nichts dagegen, auch andere hierarchieweit wirkende
| Entscheidungen nach analogen, nur im Detail abweichenden, Regeln
| herbeizuf�hren.
|
| Zur Moderatoren-Nachfolge in bestehenden moderierten Gruppen sind
| diese Spielregeln weder zwingend noch die einzigen Regeln.

Die Einrichtungsregeln stammen im Ursprung aus der Zeit der Gr�ndung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen besch�ftigen. Je gr��er die Hierarchie wurde (und je st�rker
die Nutzerzahlen wieder zur�ckgingen), desto h�ufiger wurden dann
�nderungs- und L�schungsverfahren, aber auch Regel�nderungen.

Grunds�tzlich ist die Vorgehensweise in diesen F�llen den
Einrichtungsverfahren vergleichbar, insbesondere die
Begr�ndungsans�tze sind aber freilich andere.

7.1. Gruppenl�schungen
----------------------

Gruppenl�schungen sind das Gegenteil von Neueinrichtungen und kommen dementsprechend auch aus den umgekehrten Gr�nden wie diese in
Betracht. Sie werden zumeist dann vorgeschlagen, wenn eine Gruppe
nicht mehr oder praktisch nicht mehr genutzt wird und dementsprechend leersteht. So wie eine neue Gruppe oft durch Aufspaltung einer
bestehenden, sehr rege genutzten Gruppe in mehrere Untergruppen
entsteht, sollen so umgekehrt die fast leeren Untergruppen wieder zu
einer gemeinsamen Obergruppe zusammengef�hrt werden. Ziel ist es
letztlich bei Einrichtungen wie bei L�schungen von Gruppen, eine
thematische Aufteilung zu erreichen, die gerade so fein ist, dass
Gruppen zu intensiv diskutierten Themen nicht �berf�llt sind und
Gruppen zu selten diskutierten Themen nicht leer stehen.

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

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

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

Ein Beispiel daf�r w�re die Teilhierarchie
de.comp.office-pakete.ms-office.*, die urspr�nglich 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,
w�rde 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, f�r
das ansonsten keine vergleichbare Gruppe besteht, sondern allenfalls
ein bunter Strau� verschiedenster Gruppen zu einzelnen Facetten des
Themas; manche Gruppen sind auch die einzigen oder letzten, die sich
(noch) mit einem solchen Thema befassen. In solchen F�llen ist eine
besonders kritische Pr�fung erforderlich, ob sich die Gruppe nicht
wieder beleben l�sst, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema v�llig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur L�schung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.

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

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

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

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

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

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

Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht m�glich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zus�tzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungef�hr eine Woche sp�ter von der
L�schung der Gruppe mit dem alten Namen. Dies f�hrt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelm��ig in die
Gruppe hineinschauen, sie dann pl�tzlich nicht mehr finden k�nnen.
Eine solche Umbenennung will also wohl�berlegt sein.

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

Neben dem Namen k�nnen auch alle anderen Attribute einer Gruppe (f�r
deren Beschreibung siehe 2.) ge�ndert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene Charta�nderung die Folge einer
Reorganisation, also der Einrichtung oder L�schung anderer Gruppen, so
dass klarstellende �nderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gel�schten
oder sonstwie ge�nderten Newsgroups aus der Charta entfernt werden
m�ssen. Manchmal ergibt sich aber der Bedarf nach einer Abgrenzung
oder Erweiterung der Charta einer Gruppe auch so, wenn sich bspw. der thematische Fokus verschiebt.

Eine Charta- oder Kurzbeschreibungs�nderung ist dabei im wesentlichen
kein technischer Vorgang. Ge�nderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden k�nnen (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden Charta�nderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".

7.4. Status�nderungen
---------------------

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

Soll eine bisher unmoderierte Gruppe zuk�nftig moderiert sein, f�hrt
dies dazu, dass Postings �ber Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
f�hren, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zuk�nftig unmoderiert sein soll, werden
Newsserver, die diese Umstellung (noch) nicht vollzogen werden,
weiterhin eingereichte Postings per E-Mail an die (nicht mehr
bestehende) Moderation weiterleiten, so dass auch dann Beitr�ge
verloren gehen.

Diese technischen Probleme m�ssen bereits in der Diskussionsphase ber�cksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zus�tzlichen Aufwand, um die Situation im
Auge zu behalten und ggf. die Betreiber von Newsservern an die
notwendige Umstellung zu erinnern.

Ansonsten gelten die unter 2.4. dargestellten zus�tzlichen Erw�gungen
f�r die Einrichtung moderierter Gruppen entsprechend.

7.5. Regel�nderungen und Personenwahlen
---------------------------------------

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

Sie gelten - teilweise modifiziert - auch f�r Personenwahlen, bspw.
f�r die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelm��igen Abst�nden
durchgef�hrten Nachwahlen [8]. In gleicher Weise w�re es auch m�glich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschlie�en oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
�bergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - �bersteuert werden.

[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos ver�ffentlicht sind:
| From: [email protected] (Olaf Schneider), [email protected] (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
regelm��ig in de.admin.news.announce ver�ffentlicht wird:
| From: [email protected] (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 Erl�uterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise erg�nzt.

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

Folgende Texte sollten einem Proponenten unbedingt bekannt sein:

+ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
| From: [email protected] (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: [email protected] (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 <[email protected]>
| 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. Weiterf�hrende Hinweise
----------------------------

Folgende Texte sind allgemein oder f�r spezielle Fragen hilfreich oder
von Interesse:

+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From: [email protected] (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: [email protected] (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 <[email protected]>
| 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" <[email protected]>
| 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: <[email protected]>
<https://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>

+ GVV-FAQ
| From: Thomas Hochstein <[email protected]>
| 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 Durchf�hrung von Abstimmungen
| From: [email protected] (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: <[email protected]>
<https://dana.de/archiv/2011-03-12-admin-wahlaccounts.txt>

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

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

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

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

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

+ Informationen �ber de.alt.test.moderated
| From: Thomas Hochstein <[email protected]>
| 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 Durchf�hrung des Einrichtungsverfahrens helfen:

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


[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)