[continued from previous message]
Übersichtlichkeit und höheren inhaltlichen Qualität, weil Beiträge
vorgefiltert werden können; ihr Nachteil ist die zwangsläufig
entstehende Verzögerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn bestätigen muss. Sie eignen sich daher vor
allem für Ankündigungen oder FAQs. Ein Beispiel hierfür ist de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen veröffentlicht werden, so dass die Gruppe auch für
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, und eine vorherige Überprüfung der
Veröffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
denen nur FAQs und Infotexte veröffentlicht werden.
Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer höheren inhaltlichen Qualität dienen und ermöglicht
vor allem den Ausschluss von bewussten Störern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegründet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden Verzögerungen vor Veröffentlichung eines Beitrags den Fluss der
Diskussion stören und an Veröffentlichung ihrer Beiträge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu unterschätzen; immerhin bedeutet die Moderation einer Diskussionsgruppe, dass auf Jahre hinaus eine
Einzelperson oder Gruppe im Extremfall 24 Stunden am Tag und 7 Tage in
der Woche erreichbar sein muss, um eingehende Beiträge so zeitnah wie
möglich zu prüfen und freizugeben.
2.4.2. Einrichtung moderierter Gruppen
Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zusätzliche Angaben zur Moderation zu machen;
dazu gehören der oder die vorgesehene(n) Moderator(en) und die Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
für die Newsgroup zur Freigabe weitergeleitet werden sollen. Außerdem
muss die Kurzbeschreibung entsprechend ergänzt werden. Schließlich
sollte für die Durchführung der Moderation sinnvollerweise ein Konzept vorliegen und die technischen Voraussetzungen geschaffen und getestet
sein.
* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
Veröffentlichung des Vorschlags seine entsprechende Bereitschaft
erklärt haben; in der Regel wird es sich empfehlen, ein mehrköpfiges
Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
auch im Falle eines mehrwöchigen Urlaubs oder gar eines dauerhaften
Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
interessiert sein mag - die Moderation handlungsfähig bleibt und
Beiträge weiterhin veröffentlicht werden können. Für moderierte
Diskussionsgruppen wird regelmäßig ein ausreichend großes Team
zwingend vorzusehen sein, damit Beiträge zumindest tagsüber zeitnah
veröffentlicht werden können.
Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
Einreichungen bewerten zu können, von den zu erwartenden
Diskussionsteilnehmern akzeptiert werden und schließlich absehbar
für längere Zeit für diese Tätigkeit zur Verfügung stehen. Erfahrung
im Usenet und ggf. die notwendigen technischen Kenntnisse zur
Durchführung der Moderation sind hilfreich.
* Wenn die (erste) Moderation personell feststeht, stellt sich als
nächstes die Frage, welche E-Mail-Adresse für Einreichungen
("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
in jedem Newsserver oder an einer zentralen Stelle (den Relays für
moderators.isc.org) in der Konfiguration vermerkt werden, sollte
sich also so selten wie möglich ändern; außerdem sollte die Adresse
zuverlässig erreichbar sein und ggf. die Möglichkeit für
ausreichende Spamfilterung bieten; langjährig aktive und regelmäßig
veröffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
Spam an.
Daneben sollte eine weitere Adresse veröffentlicht werden, über die
der Moderator oder die Moderation kontaktiert werden können, ohne
dass eine Veröffentlichung erfolgt, um bspw. für Anfragen erreichbar
sein.
* Die Kurzbeschreibung der Gruppe (2.2.) muss im Falle einer moderierten
Gruppe zwingend mit der Submissionsadresse und dem Schlüsselwort
"(Moderated)" in exakt dieser Schreibweise enden, bspw. so:
| de.gruppe.mod Moderierte Gruppe. <
moderation@domain.example> (Moderated)
* Falls die zu moderierende Gruppe keine Diskussionsgruppe ist,
sondern nur Ankündigungen, FAQs o.ä. enthalten soll, sollte eine
Gruppe bestimmt werden, in der diese Ankündigungen oder FAQs
anschließend ggf. diskutiert werden können und in die Antworten dann
per gesetztem Followup-To:-Header geleitet werden.
* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
welchen Kriterien Beiträge akzeptiert oder zurückgewiesen werden, ob
sie ggf. verändert veröffentlicht werden können und wie mit
Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
mehrköpfigen Moderation stellt dies eine einheitliche Handhabung
sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
werden und danach (regelmäßig) veröffentlicht werden.
Entsprechende Beispiele finden sich in bereits bestehenden
moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der
de-Hierarchie" enthält teilweise Verweise darauf.
* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
Möglichkeit, einen per E-Mail übersandten Beitrag unter Beibehaltung
der wesentlichen Informationen auch im Header - aber unter Wegfall
mancher und Ergänzung anderer Headerzeilen - als Posting zu
veröffentlichen. Insbesondere dann, wenn mehr als eine Person -
parallel - an der Moderation beteiligt sein soll (was sich
mittlerweile als Regelfall etabliert haben dürfte), empfiehlt es
sich, das entsprechende Zusammenwirken auch technisch zu
unterstützen. In der Regel wird die Moderation einer Newsgroup also
die Installation entsprechender Software auf dem eigenen Rechner
oder sogar die Einrichtung auf einem übers Netz erreichbaren
Rechner, bspw. mit einem Webinterface, und deren Bedienung
erfordern.
Das muss nicht zwingend durch die Moderatoren selbst erfolgen; im
Zweifel werden aktive Netzteilnehmer bereit sein, eine solche
Installation zur Verfügung zu stellen. Die Auswahl und Erprobung der
vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
Kontaktaufnahmen sollten aber spätestens parallel zum laufenden
Einrichtungsverfahren erfolgen; Tests können bspw. in der Newsgroup
de.alt.test.moderated erfolgen.
Siehe auch:
+ Unknown: NetNews Moderator's Handbook (1994, engl.)
<
https://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
<
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/
2.5. Sonderfälle
----------------
Die vorstehenden Erläuterungen decken den Regelfall der Einrichtung
einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene Sonderfälle:
* Aufteilung von Gruppen
Wenn eine bestehende Newsgroup aufgrund der regen Nutzung in mehrere
Gruppen unterteilt werden soll, entsteht daraus in der Regel eine
neue Teilhierachie (ein neuer Zweig am Baum der Struktur von de.*).
Die Einrichtungsregeln sehen für diesen Fall in Punkt 7 folgendes
vor:
| .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie --
| sei es durch Umwandlung einer bestehenden Gruppe oder durch
| Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc
| endende Gruppe eingerichtet. Der zur Gründung der Hierarchie
| führende RfD hat hierzu die notwendigen Angaben bereitzustellen.
| Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
| findet hierüber eine normale Abstimmung statt.
Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe für
Ausrüstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
eingerichtet werden. Dies geschieht regelmäßig durch Umbenennung der
bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
also auch dazu Informationen enthalten.
* Einrichtung einer neuen Teilhierarchie
Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
vorgeschlagen werden soll, sondern direkt mehrere, thematisch
zusammenhängende, also auf diese Weise eine neue Teilhierachie
entsteht.
Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
"de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
mit Ködern zu tun haben. Die entsprechenden Informationen - Name,
Kurzbeschreibung, Charta - müssen ebenfalls im Einrichtungsvorschlag
enthalten sein.
* Einrichtung mehrerer Gruppen
In einem Einrichtungsvorschlag sollte nur dann die Einrichtung
mehrerer Gruppen zusammengefasst werden, wenn diese in einem inneren
Zusammenhang stehen, wenn bspw. eine bestehende Gruppe aufgeteilt
werden oder direkt eine komplette neue Teilhierarchie eingerichtet
werden soll. In diesem Fall muss der Einrichtungsvorschlag dann für
alle Gruppen die notwendigen Informationen bereitstellen.
Zu berücksichtigen ist, dass Vorschläge grundsätzlich nicht "en
bloc" zur Abstimmung gestellt werden können; vielmehr ist über jeden
Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
Teil 7 folgende Vorgaben:
| Übertragbarkeit: Stimmen können nicht auf einen anderen
| Abstimmungsvorschlag übertragen werden. Eine Stimme zählt nur für
| GENAU DEN Vorschlag, für den sie abgegeben wurde. Insbesondere
| darf eine Stimme für oder gegen eine Newsgruppe mit einem
| bestimmten Namen NICHT als Stimme für oder gegen eine Newsgruppe
| mit einem anderen Namen oder einer anderen Charta, einem anderen
| unmoderiert/moderiert Status oder, falls moderiert, einem anderen
| Moderator oder einer anderen Gruppe von Moderatoren gezählt
| werden. Über jede Gruppe wird einzeln abgestimmt, Verknüpfungen
| von Wahlen sind nicht möglich.
* Diskussion mehrerer Alternativen
Ziel der Diskussion sollte es regelmäßig sein, am Ende der
Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
Das schließt nicht aus, in der Diskussion zunächst mehrere denkbare
Alternativen vorzuschlagen; die Diskussion sollte aber schließlich
zu einem mehrheitsfähigen Vorschlag führen. Ggf. kann dazu auch ein
unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
sich ausschließende Alternativen zur Abstimmung zu stellen sollte
nach Möglichkeit vermieden werden, weil die Abstimmung sonst
einerseits schnell sehr kompliziert wird und andererseits die Gefahr
besteht, dass entweder kein Vorschlag eine Mehrheit erhält (obwohl
die Mehrzahl der Abstimmenden durchaus generell für eine Einrichtung
der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
Vorschlägen angenommen wird, das so niemand gewollt hat.
Die für die Abstimmung in diesem Fall zu beachtenden Regeln für
"kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
und lauten folgendermaßen:
| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| höchstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird über die Einrichtung jeder einzelnen Gruppe gemäß den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zusätzlich ein Stichentscheid zwischen all diesen Gruppen statt.
| Falls in den Einrichtungsfragen mehr als eine Gruppe angenommen
| wird, so wird davon einzig diejenige eingerichtet, welche im
| Stichentscheid das beste Verhältnis Zustimmung : Ablehnung aufweist.
Siehe dazu auch:
+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf Döblitz <
faq@netzverwaltung.net>
| Newsgroups: de.admin.news.misc,de.admin.infos
| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten |
| Archive-name: de-admin/entscheidung
| Posting-frequency: weekly
| Last-modified: 2013-06-09
| URL:
http://www.kirchwitz.de/~amk/dai/entscheidung
3. Diskussionsphase
===================
Wenn alle Vorüberlegungen abgeschlossen sind, kann das "offizielle" Einrichtungsverfahren mit der Abfassung eines förmlichen
Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
bei der Moderation von de.admin.news.announce eingereicht und von
dieser dann nach Prüfung veröffentlicht wird.
3.1. Inhalt und Aufbau eines RfD
--------------------------------
3.1.1. Inhalt
Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
2. dargestellten notwendigen Informationen und einer Begründung des Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
Vorschlag und der Notwendigkeit für die bzw. dem Erfolg der
vorgeschlagenen neuen Gruppe zu überzeugen.
Üblicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begründung, die den Hintergrund für den Vorschlag und die Überlegungen insbesondere zu den bereits oben unter 1. ("Vorüberlegungen")
genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
Monaten vorzunehmen ("Trafficnachweis"). Außerdem enthält der RfD
natürlich Namen und Mailadressen des- oder derjenigen, der/die den
Vorschlag einreichen ("Proponent(en)"). Bei einer Mehrzahl von
Personen bietet sich ggf. die Einrichtung eines Verteilers für die Kommunikation mit der Moderation von de.admin.news.announce und für
eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.
Schließlich ist auch zu entscheiden, in welchen Gruppen der RfD
veröffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zusätzlich sollten aber auch die Gruppen
aufgenommen werden, die durch das Verfahren vorhersehbar tangiert
werden, also namentlich die Gruppe(n), die aufgeteilt werden soll(en),
deren Themenbereiche durch die neue Gruppe eingeschränkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
natürlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
stattfinden oder in denen man sich Interessen an der neuen Gruppe
erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
möglich und nur so lang wie nötig sein sollte; dies schon deshalb,
weil in übermäßig viele Gruppen verteilte Postings heutzutage
möglicherweise als Spam ausgefiltert werden.
Eine Veröffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im Einverständnis mit deren Moderation. In Gruppen außerhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.ä. kann der Proponent nach Veröffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") veröffentlichen, der u.a. Newsgroups,
Betreff und auch die Message-ID des RfDs enthalten sollte, damit
Interessenten den Vorschlag und die Diskussion finden können.
3.1.2. Formale Gestaltung
Für die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich Üblichkeiten entwickelt. Es empfiehlt
sich auch hier, einige ältere RfD in de.admin.news.announce als Muster heranzuziehen. Das kann dann bspw. so aussehen:
| 1. RfD (Diskussionsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
oder
| Status
| ------
|
| Die Gruppe ist moderiert.
|
| Moderatoren sind Adam Berthold <
adam@berthold.example> und
| Charlotte Dominik <
charlotte@dominik.example>.
|
| Die Submissionsadresse lautet <
submissionen@domain.example>.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begründung
| ----------- ----------
|
| [Begründung, ggf. untergliedert]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
Unter <
http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
einen "RfD-Generator" eingerichtet. Über ein Formular werden die
notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige
Fehler hin überprüft und daraus dann ein Text erzeugt, der als RfD
eingereicht werden kann.
3.2. Einreichung des RfD
------------------------
Der fertige RfD ist dann per E-Mail an <
moderator@dana.de> an die
Moderation von de.admin.news.announce einzureichen. Neben dem
eigentlichen Text sollte dabei auch die Liste der Gruppen übermittelt
werden, in denen der RfD veröffentlicht werden soll. Der RfD kann auch
bereits einschließlich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angehängte Textdatei, übermittelt
werden.
Üblicherweise wird die Moderation den Eingang des RfD bestätigen und
ihn in den wöchentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation veröffentlicht wird. Danach wird ein Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
überprüft, ggf. Rücksprache mit dem oder den Proponenten nimmt und ihn schließlich in de.admin.news.announce und den übrigen Gruppen
veröffentlicht.
Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
sind oder Unsicherheit bestehen, können diese in der Regel mit dem Verfahrensbetreuer diskutiert und geklärt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben üblicherweise bereits längerfristige Erfahrungen mit de.* und dem Einrichtungsverfahren gesammelt und können daher im Zweifel Tips und
Hinweise geben oder beratend tätig werden.
Siehe auch:
+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From:
moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation
<
http://dana.de/modkonzept.html>
3.3. Diskussionsphase
---------------------
Nachdem die Moderation den RfD veröffentlicht hat, findet in de.admin.news.groups die Diskussion über den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf Einwände und Kritik eingehen und ggf. ihre
Begründung verfeinern.
Häufig wird die Diskussion sinnvolle Ergänzungen zum ursprünglichen
Vorschlag bringen, die in einen neuen, geänderten Vorschlag
eingearbeitet werden können. Wenn dies der Fall ist, kann nach einiger
Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur Veröffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begründung, warum welche Vorschläge aufgenommen oder
verworfen wurden, enthält. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.
Besteht weiterer Diskussionsbedarf, können auch mehrere weitere RfDs veröffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unnötig verlängert oder verzögert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu veröffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden Verbesserungsvorschläge gesammelt
werden; erst wenn sich ein Konsens abzeichnet oder sich jedenfalls die Diskussion beruhigt (oder im Kreis zu drehen beginnt), ist in der
Regel der richtige Zeitpunkt gekommen, die bisherigen Vorschläge und
Änderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen geänderten Vorschlag als
weiteren RfD zu veröffentlichen.
Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
möglichst konstruktiv geführt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer ausschließlich erfreulich sein wird; de.admin.news.groups ist auch
insofern ein Spiegel des Usenets als es dort neben gutwilligen
Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden Teilnehmern auch starrköpfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.
3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags -----------------------------------------------------------
Am Ende der Diskussion sollte(n) der/die Proponent(en) sich darüber Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall,
kann das Verfahren zurückgezogen werden.
Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endgültige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten veröffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen übereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
Änderungen zu veröffentlichen.
Nach Möglichkeit sollte am Ende der Diskussion nur noch ein einziger, einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls müssen aber
für jede vorgeschlagene Gruppe Name, Kurzbeschreibung, Status und
Charta (und bei moderierten Gruppen der Moderator und die
Submissionsadresse) - notfalls in mehreren Varianten - feststehen.
4. Abstimmungsphase
===================
Die Abstimmung über einen Vorschlag findet per E-Mail statt. Die
abgegebenen Stimmen werden während des Abstimmungszeitraums an die E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
auszählt und am Ende ein Ergebnis der Abstimmung mit Namen,
E-Mail-Adresse und Stimmabgabe aller Teilnehmer veröffentlicht. Die Durchführung der Abstimmung muss nicht zwingend durch den oder die
Proponenten erfolgen; aufgrund der notwendigen technischen und organisatorischen Kenntnisse und Voraussetzungen empfiehlt es sich
oft, die Durchführung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu überlassen.
4.1. Voraussetzungen für die Durchführung einer Abstimmung ----------------------------------------------------------
Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen
gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld
prüfen:
* Für die Durchführung der Abstimmung benötigt man einen
E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte
nach Möglichkeit nicht mit der "normalen" E-Mail-Adresse des
Abstimmungsleiters identisch sein, damit keine Missverständnisse
auftreten oder Wahlscheine in der sonstigen Post verloren gehen.
Wichtig ist insbesondere auch, dass der Account ungefiltert ist, also
keine Spamfilter oder Blacklists aktiv sind, die ggf. dazu führen,
dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
von Webhosting- oder Internetzugangsanbietern.
Siehe dazu auch:
+ Zu Abstimmadressen und Filtermassnahmen
| From:
karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <
Admin-Filtermassnahmen-20110312-2@dana.de>
|
| Filtermaßnahmen bei der Durchführung von Abstimmungen
| =====================================================
* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von
Hand zu bearbeiten, sondern dafür geeignete Software zu verwenden,
die Plausibilitätsprüfungen vornimmt, Bestätigungen per E-Mail
versenden kann und Auswertungen automatisch erstellt.
Die verbreitetste Softwarelösung dafür ist UseVote; mehr
Informationen dazu und eine Downloadmöglichkeit gibt es auf
<
http://www.usevote.de/>.
* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
haben sich einige regelmäßige Teilnehmer in de.admin.news.* dazu
bereiterklärt, ungefilterte Abstimmungsaccounts einzurichten und die
eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.ä.
zu ermöglichen. Dazu zählen u.a.
- Ralph Angenendt <
ihr.name@strg-alt-entf.org>
- Ralf Döblitz <
doeblitz@doeblitz.net>
- Karsten Düsterloh <
kd-usenet@tprac.de>
- Michael Grimm <
trashcan@odo.in-berlin.de>
- Emil Schuster <
emil@wieslauf.sub.de>
Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
abzustimmen.
* Daneben besteht auch die Möglichkeit, die Abstimmung gar nicht
selbst durchzuführen, sondern damit einen Dritten zu beauftragen,
der weitergehende technische Möglichkeiten oder größere Erfahrungen
mit der Durchführung von Abstimmungen hat. Überdies ist es zwar
zulässig und auch der von den Einrichtungsregeln ursprünglich
vorgesehene Regelfall, dass der Proponent auch die Abstimmung
durchführt, manchmal ist es aber erwünscht, damit einen unabhängigen
Dritten zu beauftragen.
Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
erfahrene Votetaker haben sich überdies zu den "German Volunteer
Votetakers" (GVV) zusammengeschlossen und sind unter der Adresse
<
gvv@dana.de> erreichbar. Jeder Proponent kann unter dieser Adresse
- rechtzeitig! - nachfragen, ob ein Mitglied der GVV bereit und in
der Lage ist, für ihn die Abstimmung durchzuführen. In den letzten
Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
Mitglieder der GVV durchgeführt.
Siehe dazu auch:
+ 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
4.2. Inhalt und Aufbau eines CfV
--------------------------------
Auch für den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er
muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name, Kurzbeschreibung, Charta, Status, ggf. Moderator) und die für die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.
Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
höchstens einen Monat betragen. Üblicherweise wird diese Frist nicht ausgeschöpft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV veröffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es üblich, Abstimmungen
um Mitternacht enden zu lassen. Daher könnten sich bei einer
Abstimmungsdauer von einem Monat und Veröffentlichung des 1. CfV bspw.
um 16:30 Uhr unnötige Diskussionen ergeben, ob damit nicht die
Höchstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) überschritten wird.
Schließlich muss der CfV mit dem letzten RfD im wesentlichen
übereinstimmen, wie Teil 6 der Einrichtungsregeln festhält:
| Nach der Diskussionsperiode kann ein Abstimmungsaufruf -- engl.
| "Call for Votes" oder kurz CfV -- bei der Moderation eingereicht
| werden. Dieser muss mit dem letzten RfD im wesentlichen
| übereinstimmen.
Zweck dieser Regel ist es, zu verhindern, dass etwas anderes zur
Abstimmung gestellt wurde als zuvor Gegenstand der Diskussion war.
"Wesentlich" in diesem Sinne sind daher alle Eigenschaften der
einzurichtenden Gruppe sowie die Abstimmungsmodalitäten; an diesen
dürfen keine über die Behebung von Schreibfehlern o.ä. hinausgehenden Änderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor diskutierte. Eine Änderung der Begründung - soweit sie überhaupt im
CfV wiederholt wird - ist hingegen regelmäßig unproblematisch.
Üblich ist es, auf Basis des letzten veröffentlichen RfD einen CfV zu entwerfen. Dabei kann der Begründungsteil gekürzt werden oder ganz
entfallen und durch einen Verweis auf die geführte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugefügt werden dann die Abstimmungsmodalitäten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele für
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unüblich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
nämlich als überflüssig; bei komplexeren Abstimmungen hingegen würde
die Darstellung aller möglichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solchermaßen unübersichtlich und aufwendig,
dass regelmäßig darauf verzichtet wird. Wenn jedoch die einzelnen Abstimmungsmöglichkeiten dargestellt werden, dann müssen sowohl die Abstimmungsmöglichkeiten für wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu vermeiden.
Beispiele für CfVs finden sich in de.admin.news.announce. Eine
mögliche Gestaltung wäre folgende:
| 1. CfV (Abstimmungsaufruf)
| ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname] [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begründung
| ----------- ----------
|
| [kurze Begründung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| Abstimmungsmodalitäten
| ----------------------
|
| Votetaker : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein : Untenstehendes Formular ist zu verwenden. Möglich sind
| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung gültigen Fassung, die in de.admin.infos
| und unter <
http://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
| veröffentlicht sind. Sie erläutern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
| Gezählt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail bestätigt. Das Ergebnis wird
| nach dem Ende der Wahl veröffentlicht. Namen, E-Mail-Adresse und
| Inhalt der Stimmabgabe aller Abstimmenden werden im Ergebnis genannt.
| Mit Rücksicht auf das deutsche Datenschutzrecht ist daher die
| gesonderte Zustimmung zur Speicherung und Veröffentlichung der
| abgegebenen Stimme entsprechend Hinweis im Wahlschein nötig.
|
| =-=-=-=-=-=-=-=- Alles vor dieser Zeile bitte loeschen =-=-=-=-=-=-=-=-
|
| WAHLSCHEIN fuer Einrichtung von [Gruppenname]
|
| Dein Realname, falls nicht im FROM-Header:
|
| Wenn du keinen Real-Namen angibst, wird deine Stimme fuer
| ungueltig erklaert werden.
|
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)