[continued from previous message]
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. <
[email protected]e> (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 <
[email protected]>
| 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 <
[email protected]>
| Newsgroups: de.admin.news.misc,de.admin.infos
| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten |
| Archive-name: de-admin/entscheidung
| Posting-frequency: weekly
| Last-modified: 2013-06-09
| URL:
https://www.kirchwitz.de/~amk/dai/entscheidung
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 <
[email protected]e> und
| Charlotte Dominik <
[email protected]e>.
|
| Die Submissionsadresse lautet <
[email protected]e>.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begr�ndung
| ----------- ----------
|
| [Begr�ndung, ggf. untergliedert]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
3.2. Einreichung des RfD
------------------------
Der fertige RfD ist dann per E-Mail an <
[email protected]> 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:
[email protected] (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2022-01-16> 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:
[email protected] (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <
[email protected]>
|
| Filterma�nahmen bei der Durchf�hrung von Abstimmungen
| =====================================================
<
http://dana.de/archiv/2011-03-12-admin-wahlaccounts.txt>
* 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 <
[email protected]>
- Ralf D�blitz <
[email protected]>
- Karsten D�sterloh <
[email protected]>
- Michael Grimm <
[email protected]>
- Emil Schuster <
[email protected]>
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
<
[email protected]> 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 <
[email protected]>
| Newsgroups: de.admin.infos,de.admin.news.groups
| Subject: <2021-12-13> GVV-FAQ
|
| Archive-name: de-admin/gvv-faq
| Posting-frequency: weekly
| Last-modified: 2021-12-13
| URL:
https://votetakers.de/faq.php
| URL:
https://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 <
https://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.
|
| 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
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)