[continued from previous message]
| Nr [Deine Stimme] Gruppe/Abstimmungsgegenstand
| ========================================================================
| #1 [ ] Einrichtung von [Gruppenname]
|
| Zur Verarbeitung des Wahlscheines und insbesondere der
| Veroeffentlichung des Ergebnisses ist deine Zustimmung zur Speicherung,
| Auswertung und Veroeffentlichung deiner Stimmdaten (Name und
| E-Mail-Adresse in Verbindung mit dem Stimmverhalten) im Rahmen dieses
| Verfahrens erforderlich. Wenn du im Feld unterhalb dieses Absatzes "JA"
| eintraegst, erklaerst du dich damit einverstanden. In allen anderen
| Faellen wird der Wahlschein mit Ruecksicht auf das deutsche
| Bundesdatenschutzgesetz verworfen und nicht gewertet.
|
| #a [ ] Datenschutzklausel - Zustimmung: Ich bin mit der
| Verarbeitung meiner Daten wie oben beschrieben
| einverstanden
|
| =-=-=-=-=-=-=-=- Alles nach dieser Zeile bitte loeschen =-=-=-=-=-=-=-=-
Es empfiehlt sich, im Wahlschein eine Möglichkeit vorzusehen, den
tatsächlichen Namen anzugeben, da möglicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).
Der fertige CfV ist dann wie gewohnt per E-Mail an <
moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
gehört die Liste der Gruppen dazu, in denen der RfD veröffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschließlich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angehängte Textdatei,
übermittelt werden.
Die Veröffentlichung des CfVs wird üblicherweise länger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von de.admin.news.announce nach dem 4-Augen-Prinzip überprüft wird. Daher
kann - und sollte - der 1. CfV ruhig möglichst frühzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Veröffentlichung ergibt, setzt die Moderation dann
selbst ein.
4.3. Sonderfall: CfV mit persönlichem Wahlschein ------------------------------------------------
Ergänzend zu der üblichen Form der Abstimmung, bei der bereits der CfV
einen Wahlschein enthält, sehen die Einrichtungsregeln in ihrem Teil
6a auch die Möglichkeit einer Abstimmung unter Verwendung persönlicher Wahlscheine vor.
Diese 1998/1999 eingeführte Verfahrensweise [5] soll die Manipulation
von Abstimmungen erschweren, indem sie das normale
Abstimmungsverfahren durch ein Zwei-Schritt-Verfahren ersetzt: der Abstimmungswillige muss zunächst einen persönlichen Wahlschein beim
Votetaker anfordern, der ein kodiertes, eindeutig dem
Abstimmungswilligen zuzuordnendes Merkmal erhält und sodann diesen
persönlichen - und an seine E-Mail-Adresse gekoppelten - Wahlschein
ausgefüllt zurücksenden. Andere Wahlscheine oder die Verwendung einer
anderen E-Mail-Adresse werden nicht akzeptiert.
Diese Vorgehensweise soll u.a. verhindern, dass vorausgefüllte
Wahlscheine verbreitet werden, die durch beliebige Netzteilnehmer ohne
Kenntnis des Verfahrens (oder gar ohne Kenntnis von der Existenz des
Usenets) dann an die Abstimmungsadresse versandt werden. Als
Nebeneffekt wird damit die zur selben Zeit festgeschriebene Forderung,
dass die zur Abstimmung verwendete Adresse gültig sein, d.h. E-Mails entgegennehmen muss, überprüfbar - denn nur wer eine gültige Adresse
als Absender verwendet, kann den Wahlschein erhalten, und nur so - und
mit dieser Adresse - kann er an der Abstimmung teilnehmen.
Da allerdings weiterhin andere Manipulationsmöglichkeiten verbleiben
und der Aufwand für die Durchführung dieses Verfahrens vergleichsweise
hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten
durchgeführt.
In der Abstimmungssoftware Usevote (siehe 4.1.) ist die Durchführung
solcher Verfahren implementiert.
[5] Der Vorschlag und die entsprechende Begründung lassen sich im
Archiv von Google Groups unter
<
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 <
http://www.dana.de/archiv.html> auch im Web veröffentlicht.
Bei der Auswertung sollte der Votetaker im eigenen Interesse die datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, berücksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Veröffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdrückliche Einwilligungserklärungen erforderlich sind.
Danach ist eine Ergebnisveröffentlichung ("Result") vorzubereiten.
Üblich ist es, die Gesamtzahl der gültigen Stimmen und sodann für
jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der
Enthaltungen und ungültigen Stimmabgaben zu nennen. Angenommen ist der Vorschlag, wenn mindestens 50 JA-Stimmen eingegangen sind und die
Anzahl der JA-Stimmen mindestens doppelt so groß ist wie die Anzahl
der NEIN-Stimmen (2/3-Mehrheit).
Zwingend ist zudem die Veröffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ungültige Stimmen sind anzugeben, bei letzteren unter Angabe einer stichwortartigen Begründung für die Nichtwertung. Dies ermöglicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.
In besonderen Fällen kann die Veröffentlichung von Name und/oder
Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dürfte
das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
in denen aus bestimmten Gründen die Verwendung von Pseudonymen
akzeptiert wird.
5. Verfahrensabschluss und Umsetzung
====================================
Mit der Veröffentlichung des Results durch die Moderation von de.admin.news.announce beginnt eine einwöchige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begründung einlegen kann, dass
bei der Durchführung der Abstimmung schwerwiegende Unregelmäßigkeiten
gab. Das können bspw. technische Probleme mit der Abstimmadresse sein,
die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
oder einer der bereits unter 4.5. angerissenen Manipulationsversuche.
Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskräftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die üblicherweise die automatische Einrichtung der neuen
Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* führen, und
die kanonische List der in de.* existierenden Newsgroups entsprechend
ergänzen.
Ansonsten wird die Moderation über eingegangene Einsprüche entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das veröffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
wenn über den Einspruch abschließend entschieden ist.
Das Einrichtungsverfahren ist damit beendet.
6. Sonderfall: Vereinfachtes Verfahren (VV) ===========================================
Nicht jeder marginale Änderungsvorschlag muss zwingend das vorstehend geschilderte umfangreiche Verfahren nach sich ziehen. Für kleinere
Änderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. "Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und Abstimmungsphase zugunsten einer Widerspruchslösung entfallen.
Bei einem VV wird der entsprechende Änderungsvorschlag, der dieselben Anforderungen wie ein RfD erfüllen muss (siehe 3.1.), zur
Veröffentlichung in de.admin.news.announce bei <
moderator@dana.de>
eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darüber
hinaus ausdrücklich darauf hinweisen, dass die vorgeschlagene Änderung
ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer
gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen
muss, per E-Mail an die Moderation von de.admin.news.announce (deren E-Mail-Adresse anzugeben ist) widersprochen wird.
Nach Abschluss der Widerspruchsfrist stellt die Moderation von de.admin.news.announce entweder fest, dass kein Widerspruch
eingegangen ist und der Vorschlag angenommen wurde, oder
veröffentlicht Namen und E-Mail-Adresse der Widerspruchsführer. Im
letzteren Fall ist das VV gescheitert und kann durch den Proponenten
als normales Verfahren mit dem 1. RfD fortgeführt oder aufgegeben
werden.
Wenn der Änderungsvorschlag angenommen wurde, wird er durch die
Moderation von de.admin.news.announce umgesetzt (siehe 5.).
7. Löschungen, Umbenennungen, Status- und Regeländerungen u.ä. ==============================================================
Bereits die Einleitung ("Übersicht") der Einrichtungsregeln weist
darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von Usenet-Gruppen in de.*" trägt und sich die Ausführungen auch (im
wesentlichen nur) mit der Einrichtung neuer Gruppen beschäftigen, sie
aber für alle Änderungen am Gruppenbestand analog gelten und auch für
andere Entscheidungen - und Personenwahlen - entsprechend angewendet
werden können (und regelmäßig auch angewendet werden):
| Diese Spielregeln gelten für die Einrichtung oder Entfernung einer
| Gruppe sowie Änderung ihrer Attribute. Die Attribute einer Gruppe
| sind: Gruppenname, Kurzbeschreibung, Charta und Status (moderiert/
| unmoderiert) sowie bei moderierten Gruppen die Moderatoren.
|
| Es spricht nichts dagegen, auch andere hierarchieweit wirkende
| Entscheidungen nach analogen, nur im Detail abweichenden, Regeln
| herbeizuführen.
|
| Zur Moderatoren-Nachfolge in bestehenden moderierten Gruppen sind
| diese Spielregeln weder zwingend noch die einzigen Regeln.
Die Einrichtungsregeln stammen im Ursprung aus der Zeit der Gründung
und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen
mit einer koordinierten Vorgehensweise bei der Einrichtung neuer
Gruppen beschäftigen. Je größer die Hierarchie wurde (und je stärker
die Nutzerzahlen wieder zurückgingen), desto häufiger wurden dann
Änderungs- und Löschungsverfahren, aber auch Regeländerungen.
Grundsätzlich ist die Vorgehensweise in diesen Fällen den
Einrichtungsverfahren vergleichbar, insbesondere die
Begründungsansätze sind aber freilich andere.
7.1. Gruppenlöschungen
----------------------
Gruppenlöschungen sind das Gegenteil von Neueinrichtungen und kommen dementsprechend auch aus den umgekehrten Gründen wie diese in
Betracht. Sie werden zumeist dann vorgeschlagen, wenn eine Gruppe
nicht mehr oder praktisch nicht mehr genutzt wird und dementsprechend leersteht. So wie eine neue Gruppe oft durch Aufspaltung einer
bestehenden, sehr rege genutzten Gruppe in mehrere Untergruppen
entsteht, sollen so umgekehrt die fast leeren Untergruppen wieder zu
einer gemeinsamen Obergruppe zusammengeführt werden. Ziel ist es
letztlich bei Einrichtungen wie bei Löschungen von Gruppen, eine
thematische Aufteilung zu erreichen, die gerade so fein ist, dass
Gruppen zu intensiv diskutierten Themen nicht überfüllt sind und
Gruppen zu selten diskutierten Themen nicht leer stehen.
* Insofern wird die Begründung eines Löschungsvorschlags in der Regel
primär auf eine statistische Auswertung über einen längeren Zeitraum
(mindestens 12 Monate, im Zweifel aber auch länger) gestützt, um zu
belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung
solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich
sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl
der Postings pro Jahr (!) nicht in den niedrigen zweistelligen
Bereich abrutscht, können niedrige Nutzungszahlen nur ein Hinweis
auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann
oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert
wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur
Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann
gibt es in der Gruppe zumindest noch eine aktive Community, die zwar
selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche
Anlässe reagiert und die Gruppe wieder mit Leben füllt. Das spricht
eher gegen eine Löschung der Gruppe.
[6] <
http://usenet.dex.de/>
* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer -
Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der
zur Löschung vorgeschlagenen Gruppe zukünftig diskutiert werden
sollen. Wenn die Gruppe in einem größeren thematischen Zusammenhang
steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu
benennen, was dann wiederum für eine niedrigere Schwelle zur
Löschung spricht, denn so werden einzelne, mittlerweile weniger
intensiv diskutierte Unterbereiche eines größeren Themas wieder
thematisch zusammengefasst.
Ein Beispiel dafür wäre die Teilhierarchie
de.comp.office-pakete.ms-office.*, die aus den Gruppen
- de.comp.office-pakete.ms-office.excel
- de.comp.office-pakete.ms-office.outlook
- de.comp.office-pakete.ms-office.powerpoint
- de.comp.office-pakete.ms-office.word
- de.comp.office-pakete.ms-office.misc
besteht. Sollte sich herausstellen, dass zwar zu Word und Excel
intensiv diskutiert wird, es aber kaum Fragen zu Powerpoint gibt,
würde eine Löschung der Gruppe
de.comp.office-pakete.ms-office.powerpoint bedeuten, dass das Thema
"Powerpoint" nunmehr in de.comp.office-pakete.ms-office.misc diskutiert
werden kann, zusammen mit anderen, seltener (genutzten und) diskutierten
Komponenten von Microsoft Office wie bspw. OneNote.
Manche Gruppen aber fassen ein weit gespanntes Thema zusammen, für
das ansonsten keine vergleichbare Gruppe besteht, sondern allenfalls
ein bunter Strauß verschiedenster Gruppen zu einzelnen Facetten des
Themas; manche Gruppen sind auch die einzigen oder letzten, die sich
(noch) mit einem solchen Thema befassen. In solchen Fällen ist eine
besonders kritische Prüfung erforderlich, ob sich die Gruppe nicht
wieder beleben lässt, weil dann die Gefahr besteht, dass ermangels
Alternativen das Thema völlig aus dem Usenet verschwindet. Solche
Gruppen sollten daher nur zur Löschung vorgeschlagen werden, wenn
das Thema letztlich bereits aus dem Usenet verschwunden *ist*.
* Wenn die letzte Gruppe einer Teilhierarchie gelöscht wird, stellt
sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie
umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen
Teilhierarchie").
So besteht die Teilhierarchie de.comm.protocols.* aus den beiden
Gruppen
- de.comm.protocols.tcp-ip
- de.comm.protocols.misc
Würde man die Gruppe de.comm.protocols.tcp-ip löschen, könnte man
die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in
de.comm.protocols umbenennen, um so den Namen zu verkürzen und die
Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung
spricht, dass Umbenennungen technisch nicht möglich sind, sondern
nur durch eine Löschung der bestehenden Gruppe und die
Neueinrichtung der Gruppe mit dem geänderten Namen umgesetzt werden
können (siehe 7.2.).
7.2. Umbenennungen
------------------
Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang
mit anderen Änderungen am Gruppenbestand. Dass eine Gruppe ohne
weiteren Anlass bloß an eine andere Stelle im Hierarchiebaum (siehe
2.1.1.) verschoben wird, ist sehr selten.
Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe
nicht möglich ist. Was man organisatorisch als "Umbenennung"
bezeichnet, ist technisch schlicht die (zusätzliche) Einrichtung der
Gruppe mit dem neuen Namen, gefolgt ungefähr eine Woche später von der
Löschung der Gruppe mit dem alten Namen. Dies führt dazu, dass alle
bestehenden Diskussionen auf den Newsservern mit der alten Gruppe
zusammen verschwinden und zudem Nutzer, die nur unregelmäßig in die
Gruppe hineinschauen, sie dann plötzlich nicht mehr finden können.
Eine solche Umbenennung will also wohlüberlegt sein.
7.3. Änderungen von Charta und/oder Kurzbeschreibung ----------------------------------------------------
Neben dem Namen können auch alle anderen Attribute einer Gruppe (für
deren Beschreibung siehe 2.) geändert werden, namentlich die Charta
und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert;
meistens ist eine vorgeschlagene Chartaänderung die Folge einer
Reorganisation, also der Einrichtung oder Löschung anderer Gruppen, so
dass klarstellende Änderungen hinsichtlich des Themenbereichs einer
bestehenden Gruppe notwendig werden oder auch die Namen der gelöschten
oder sonstwie geänderten Newsgroups aus der Charta entfernt werden
müssen. Manchmal ergibt sich aber der Bedarf nach einer Abgrenzung
oder Erweiterung der Charta einer Gruppe auch so, wenn sich bspw. der thematische Fokus verschiebt.
Eine Charta- oder Kurzbeschreibungsänderung ist dabei im wesentlichen
kein technischer Vorgang. Geänderte Kurzbeschreibungen werden ggf.
durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin
nicht auf Newsservern gespeichert werden und daher auch nicht im
Newsreader angezeigt werden können (siehe 2.3.), sondern nur
organisatorische Metainformationen darstellen, werden Chartaänderungen
auch nur durch eine entsprechende Information per Posting in de.admin.news.announce und der betroffenen Gruppe "umgesetzt".
7.4. Statusänderungen
---------------------
Die Umstellung einer bestehenden unmoderierten Newsgroup auf
"moderiert" bzw. einer vormals moderierten Newsgroup auf den Status "unmoderiert" ist nicht unproblematisch. Auch dies hat technische
Gründe; nicht immer erfolgen technische Umstellungen durch
Steuernachrichten wirklich überall auf jedem Newsserver oder gar
überall zur gleichen Zeit. Dies kann dazu führen, dass die Gruppe auf
manchen Servern noch als moderiert geführt wird, auf anderen aber
schon als unmoderiert (oder umgekehrt).
Soll eine bisher unmoderierte Gruppe zukünftig moderiert sein, führt
dies dazu, dass Postings über Newsserver, auf denen die Gruppe noch
als unmoderiert angelegt ist, nur auf anderen solchen Newsservern
erscheinen; auf Newsservern, die die Gruppe schon als "moderiert"
führen, werden diese Postings schlicht verworfen. Wenn umgekehrt eine
bisher moderierte Gruppe zukünftig unmoderiert sein soll, werden
Newsserver, die diese Umstellung (noch) nicht vollzogen werden,
weiterhin eingereichte Postings per E-Mail an die (nicht mehr
bestehende) Moderation weiterleiten, so dass auch dann Beiträge
verloren gehen.
Diese technischen Probleme müssen bereits in der Diskussionsphase berücksichtigt werden und erfordern - in der Regel von denjenigen, die
den Vorschlag vorbringen - zusätzlichen Aufwand, um die Situation im
Auge zu behalten und ggf. die Betreiber von Newsservern an die
notwendige Umstellung zu erinnern.
Ansonsten gelten die unter 2.4. dargestellten zusätzlichen Erwägungen
für die Einrichtung moderierter Gruppen entsprechend.
7.5. Regeländerungen und Personenwahlen
---------------------------------------
Neben Änderungen am Gruppenbestand können - und werden - die
Einrichtungsregeln analog auch für andere Entscheiungen (bspw. die
Änderung der Einrichtungsregeln selbst) herangezogen.
Sie gelten - teilweise modifiziert - auch für Personenwahlen, bspw.
für die Neuwahl der Moderation von de.admin.news.announce [7] oder die
von der amtierenden Moderation in regelmäßigen Abständen
durchgeführten Nachwahlen [8]. In gleicher Weise wäre es auch möglich,
jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren
Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation
einer moderierten Gruppe Mitglieder ausschließen oder neue Mitglieder
aufnehmen und auch die Moderation komplett an andere Personen
übergeben kann. Diese Entscheidung kann dann nur durch ein
Neuwahlverfahren - analog der Einrichtungsregeln - übersteuert werden.
[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die
gleichfalls in de.admin.infos veröffentlicht sind:
| From:
ole-fg@gmx.de (Olaf Schneider),
adrian.suter@schweiz.org (Adrian Suter)
| Newsgroups: de.admin.infos,de.admin.news.misc
| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation
|
| Archive-name: de-admin/dana-neuwahl
| Posting-frequency: weekly
| Last-modified: 1998-05-18
| URL:
http://www.kirchwitz.de/~amk/dai/dana-neuwahl
[8] Diese beruhen auf freiwilliger Übung der derzeit amtierenden
Moderation von de.admin.news.announce und sind daher (nur) in
deren Moderationskonzept (dort Abschnitt 4) festgehalten, das
regelmäßig in de.admin.news.announce veröffentlicht wird:
| From:
moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation
und auch auf den Webseiten der Moderation unter
<
http://dana.de/modkonzept.html> abgerufen werden kann.
8. Quellen
==========
Alle in diesen Erläuterungen genannten Quellen sind hier noch einmal zusammengefasst und um weitere Hinweise ergänzt.
8.1. Grundlegende Informationen
-------------------------------
Folgende Texte sollten einem Proponenten unbedingt bekannt sein:
+ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
| From:
3.14@piology.org (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.alt.admin
| Subject: <2012-01-09> Einrichtung von Usenet-Gruppen in "de.*"
|
| Archive-name: de-admin/einrichtung
| Posting-frequency: weekly
| Last-modified: 2012-01-09
| URL:
http://www.kirchwitz.de/~amk/dai/einrichtung
+ Missverstaendnisse in de.admin.news.groups
| From:
3.14@piology.org (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
|
| Archive-name: de-admin/dang-faq
| Posting-frequency: weekly
| Last-modified: 2009-01-24
| URL:
http://www.kirchwitz.de/~amk/dai/dang-faq
+ Die Newsgruppen der de-Hierarchie (Gruppenliste)
| From: 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:
http://www.kirchwitz.de/~amk/dni/de-newsgruppen
8.2. Weiterführende Hinweise
----------------------------
Folgende Texte sind allgemein oder für spezielle Fragen hilfreich oder
von Interesse:
+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From:
moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation
<
http://dana.de/modkonzept.html>
+ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
| From:
thh@thh.name (Thomas Hochstein)
| Newsgroups: de.admin.infos
| Subject: <2020-08-24> Wichtige Begriffe in de.admin.news.*
|
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Version: 1.5.6
| Last-modified: 2020-08-24
| URL:
https://th-h.de/archives/faqs/dan-glossar.txt
| URL:
http://www.kirchwitz.de/~amk/dai/dan-glossar
+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
<
https://th-h.de/net/usenet/admin/newgroup/#vorschlag>
+ Erste Schritte zur Einrichtung neuer Gruppen
<
https://web.archive.org/web/20070105012315/http://usenet.babylonsounds.com/rfd_howto.html>
+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf Döblitz <
faq@netzverwaltung.net>
| Newsgroups: de.admin.news.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:
http://www.kirchwitz.de/~amk/dai/entscheidung
+ Regeln fuer Newsgruppennamen
| From: "Christian Schulz - GVV" <
gvv@spinfo.uni-koeln.de>
| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
| Date: 2000/07/18
| Message-ID: <
result-regel-newsgruppennamen-18.07.2000@dana.de>
<
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: <2017-08-19> GVV-FAQ
|
| Archive-name: de-admin/gvv-faq
| Posting-frequency: weekly
| Last-modified: 2017-08-19
| URL:
https://votetakers.de/faq.php
| URL:
http://www.kirchwitz.de/~amk/dai/gvv-faq
+ Filtermaßnahmen bei der Durchführung von Abstimmungen
| From:
karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <
Admin-Filtermassnahmen-20110312-2@dana.de>
+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<
https://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
<
http://pages.swcp.com/~dmckeon/mod-faq.html>
+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
<
https://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
<
https://www.big-8.org/wiki/Moderated_Newsgroups>
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
<
https://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
+ Informationen über de.alt.test.moderated
| From: Thomas Hochstein <
thh@thh.name>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2020-08-23>
|
| Posting-frequency: monthly
| Last-modified: 2020-08-23
| URL:
https://th-h.de/net/usenet/faqs/datm-info/
+ Entscheidungen der Moderation von de.admin.news.announce
<
http://www.dana.de/archiv.html>
8.3. Webseiten
--------------
Folgende Webseiten sollten bekannt sein oder können bei der Durchführung des Einrichtungsverfahrens helfen:
+ Webseite der Moderation von de.admin.news.announce
<
http://www.dana.de/>
+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
wöchentlich veröffentlicht in de.admin.news.announce
<
http://www.dana.de/status.html>
+ RfD-Generator
<
http://piology.org/cgi-bin/rfd.pl>
+ GVV-Statusübersicht
<
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 März/April 2011 vollständig überarbeitet und
neu gefasst.
Weitere Änderungen und Ergänzungen nehmen die Maintainer gerne
entgegen. Vorschläge können per E-Mail an <
dana-manual@usenet.th-h.de> gerichtet werden. Im Falle einer öffentlichen Diskussion solcher
Vorschläge ist ein Hinweis an die Maintainer hilfreich.
Das dana-Manual ist auch in einem Git-Repository unter <
https://code.th-h.de/?p=faqs/dana-manual.git> verfügbar und kann über
die Weboberfläche eingesehen oder via "git clone" ausgecheckt werden.
Bei Änderungsvorschlägen sind Git-Patches am einfachsten zu
verarbeiten; natürlich nehmen die Maintainer aber auch jede andere
Form von Anregungen entgegen.
Für Hinweise, Anregungen und Verbesserungsvorschläge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.
9.2. Frühere Fassungen
----------------------
Maintainer bis 2010: Thomas Roessler, Dirk Nimmich
Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
haben außerdem beigetragen:
- Lutz Donnerhacke
- Kristian Köhntopp
- Rolf Krahl
- Martin Recke
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth
Herzlichen Dank!
--
Id: 7051d68 (HEAD -> master, tag: 2.2.6) 2020-08-24 11:57:03 +0200 Thomas Hochstein
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)