+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 Gruppen-Einrichtungen wie bei -Löschungen, 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 solchen,
+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.
+
+ 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 zusammen. Dass eine Gruppe
+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
+(noch?) 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,
+die Moderation einer anderen 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: <2010-11-01> Moderationskonzept der derzeitigen Moderation
+ und auch auf den Webseiten der Moderation unter
+ <http://dana.de/modkonzept.html> abgerufen werden kann.
+
+8. Quellen
projects / faqs / dana-manual.git / blobdiff