• <2020-08-24> Erlaeuterungen zur Einrichtung neuer Gruppen in de.* (3/3)

    From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jun 23 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jun 30 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jul 7 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jul 14 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jul 21 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Jul 28 22:00:03 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Aug 4 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Aug 11 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Aug 18 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Aug 25 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Sep 1 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Sep 8 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Sep 15 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Sep 22 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Sep 29 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Oct 6 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Oct 13 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Oct 20 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Oct 27 22:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Nov 3 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Nov 10 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Nov 17 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Nov 24 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Dec 1 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Dec 8 23:00:02 2021
    [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)
  • From Thomas Hochstein / Michael Ottenbru@21:1/5 to All on Wed Dec 15 23:00:02 2021
    [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)