1.RfD: Grosse Regelreform: Rahmen-RfD

5 views
Skip to first unread message

Adrian Suter

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

Erster Aufruf zur Diskussion (1.RfD)
===================================
zur Neufassung der Einrichtungsregeln
=====================================
*Rahmen-RfD*
===========
Worum es geht
=============
Dies ist ein Aufruf zur Diskussion zur Neufassung der "Regeln für die
Einrichtung und Entfernung von Usenet-Gruppen", die wöchentlich in
de.newusers.infos, de.admin.news.announce, de.newusers.questions,
de.admin.news.groups und de.alt.admin gepostet werden.

Der vorliegende Artikel beschreibt den Rahmen, in dem das Verfahren
ablaufen soll.

Die neuen Vorschläge
====================
Es werden zeitgleich mit diesem Rahmen-RfD zwei Vorschläge für die
Neufassung der Einrichtungsregeln gepostet:

* "Vorschlag Mailingliste": Ein Vorschlag wurde in den letzten Monaten
auf einer Mailingliste intensiv diskutiert und bereits im
vergangenen Dezember eingereicht. Aufgrund der Kollision mit einem
früher eingereichten Verfahren wurde der Vorschlag aber nie in den
News diskutiert.
<RfD-1-Regelreform-Mail...@dana.de>

* "Vorschlag KISS": Ein weiterer Vorschlag wurde nach einem
informellen Posting in de.admin.news.misc diskutiert. Er wurde
aufgrund dieser Diskussion überarbeitet und wird nun im Rahmen
dieses RfD formell zur Diskussion gestellt.
<RfD-1-Regelreform-...@dana.de>

Zum Vorschlag Mailingliste
==========================
Dieser Vorschlag orientiert sich inhaltlich an einem früheren
Regelentwurf, der in der Abstimmung nicht die notwendige qualifizierte
Mehrheit erreicht hatte. Die Proponenten sind der Meinung, dass ein
wichtiger Grund für das damalige Scheitern war, dass man zu einzelnen
umstrittenen Änderungen nicht getrennt, sondern nur im Paket Stellung
nehmen konnte. Dies soll bei diesem neuen Versuch anders sein.

Die hinter diesem Vorschlag stehende Philosophie ist, dass bestimmte
Interpretationsunsicherheiten der bestehenden Regeln geklärt, Lücken
geschlossen, aber auch unnötiger Ballast beseitigt werden soll. Zum
einzelnen siehe den Vorschlag selbst und den erläuternden Artikel
der Proponenten.

Zum Vorschlag KISS
==================
Der Vorschlag KISS (Akronym für "Keep it simple, stupid") möchte die
Regeln radikal vereinfachen. Er geht davon aus, dass Regellücken immer
auftreten werden und diese anhand des Einzelfalls entschieden werden
sollen. Die Regeln bilden dafür den Rahmen - nicht mehr und nicht
weniger.

Auch hier siehe zum einzelnen den Vorschlag selbst und die
erläuternden Artikel der Proponenten.

Zum Verfahren
=============
Beide Vorschläge werden parallel diskutiert. Sie werden von
unterschiedlichen Proponenten betreut. Die Diskussion geschieht in
de.admin.news.misc.

Da mehrere Vorschläge alternativ zur Diskussion stehen, muss
im Verlauf des Verfahrens zwischen diesen Vorschlägen entschieden
werden. Die Proponenten machen die Art und Weise, wie diese
Entscheidung herbeigeführt werden soll, vom Verlauf der Diskussion
abhängig.

Die Proponenten
===============
Alle Proponenten sind gemeinsam über die de-Regeln-Mailingliste
erreichbar:

de-r...@prenzl.net

Der Reply-To:-Header aller Artikel der Proponenten in
de.admin.news.announce ist entsprechend gesetzt.

Die Proponenten im einzelnen:

Rahmen-RfD:
Adrian Suter <adrian...@schweiz.org>
Rolf Krahl <ro...@Informatik.Uni-Bremen.DE>

Vorschlag Mailingliste:
Olaf Schneider <o...@blaubeere.rhein-neckar.de>
Michael Ottenbruch <M.Otte...@sailor.ping.de>

Vorschlag KISS:
Boris 'pi' Piwinger <3....@Math.MIT.edu>

--
Fertige Artikel für de.admin.news.announce, Einsprüche und sonstige
Mail an die Moderation bitte an <mode...@dana.de> (vertrauliche
Einsendung) oder <pub...@dana.de> (geht zur Kontrolle auch an eine
öffentliche Mailingliste) schicken.

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~


Gegenstand:
~~~~~~~~~~~

Dies ist ein Aufruf zur Diskussion über eine Neufassung der
Regelwerke zur Verwaltung der Newshierarchie de.all. Diese Regeln
betreffen das Verfahren zur Einrichtung (Löschung, ...) von Newsgruppen
unter de.!alt.all sowie die Richtlinien für die Moderation von
de.admin.news.announce.

Die derzeit gültigen Regeln werden regelmäßig unter dem Titel
»Einrichtung von Usenet-Gruppen in "de.*"«, Archive-Name:
de-newusers/einrichtung, nach de.newusers.infos gepostet.

An ihre Stelle sollen zwei Texte treten:

* die »Empfehlungen zur Einrichtung von de-Newsgroups«, die das
Verfahren zur Einrichtung, Löschung und Änderung von Gruppen
beschreiben (Entwurf in
<RfD-1-Reform...@dana.de>),
und

* die »Richtlinien für die Moderation von de.admin.news.announce«,
die die Arbeit des dana-Moderators regeln (Entwurf in
<RfD-1-Reform...@dana.de>). Die Regeln zur »Neuwahl
der de.admin.news.announce-Moderation«, die sich zur Zeit zur
Überarbeitung in einem separaten Verfahren befinden, sollen nach
Abschluß jenes Verfahrens als Punkt 5. in die »Richtlinien für die
Moderation von de.admin.news.announce« integriert werden.
Der Text ist in der vorgeschlagenen Form aber auch zu den
derzeitigen Moderatorenwahlregeln kompatibel.

Beide Entwürfe werden zeitgleich mit diesem RfD und einem weiteren
Vorschlag zur Änderung der Einrichtungsrichtlinien (KISS) im Rahmen
eines Rahmen-RfD "Grosse Regelreform" nach de.admin.news.announce
gepostet.

Die Diskussion sollte in separaten Threads in de.admin.news.misc geführt
werden.


Erläuterungen:
~~~~~~~~~~~~~~~

Zur Zeit läuft ein CfV von Ralph Babel zur Anpassung der
Einrichtungsrichtlinien. Selbstverständlich werden die Proponenten
des vorliegenden RfD das Ergebnis dieser Wahl akzeptieren.

Wir werden also die Änderungen aus diesem Vorschlag, die eine
qualifizierte Mehrheit finden, unaufgefordert in unseren Entwurf
übernehmen. Einige Neuerungen sind jedoch auch schon im hier
vorgestellten Entwurf enthalten.

Auf eine detaillierte Begründung einzelner Punkte der vorgeschlagenen
Regeln wird hier verzichtet. In der Diskussion werden diese Gründe
sicherlich zur Sprache kommen.

Explizit auflisten möchten wir an dieser Stelle aber einige unserer
Meinung nach in der Diskussion zu klärende Fragen. Natürlich kann
und soll auch ueber andere Punkte diskutiert werden. Außerdem werden
einige Punkte genannt, in denen sich unser Entwurf von den derzeitigen
Regeln oder der aktuellen Praxis unterscheidet. Die folgende
Liste erhebt keinen Anspruch auf Vollständigkeit:

(An dieser Stelle empfiehlt es sich, zunächst einen Blick auf die
vorgeschlagenen Texte zu werfen.)

Sprachgebrauch:

Bei der Verwendung der Verben "können", "sollen" und "müssen"
wurden die folgenden Bedeutungen zugrunde gelegt:

muß/müssen unbedingt, immer; Ausnahme nur bei Regelungslücken
soll/sollen grundsaetzlich, begründete Ausnahmen möglich
sollte/sollten Empfehlung, nicht verbindlich
kann/können Ermessen im Rahmen des Regelungszwecks, kein
Belieben (häufig auch im Sinne von "darf" oder
"die Möglichkeit haben")

Sollte dies in irgeneiner Form in den Texten erläutert werden?

Glossar:

Begriffe und Sprachgebrauch in den Regeln sollen in einem Glossar
erläutert werden. Zu klären ist, ob und in welcher Form dieses
den Texten beigefügt werden soll, ohne sie unnötig aufzublähen.

Kombinierte Abstimmungen:

Wir schlagen vor, wieder zu der ursprünglichen Form der
kombinierten Abstimmungen zurückzukehren: Jede Variante steht
einzeln zur Wahl und muß unabhängig von den Alternativ-Vorschlägen
angenommen werden (d.h 2/3-Mehrheit und mindestens 30 Ja-Stimmen).
Trifft dies auf mehrere Vorschläge zu, müssen weiter Kriterien
herangezogen werden (Ja-Nein-Differenz). Alternativ seht dem
Proponenten die Möglichkeit offen, im selben CfV eine zusätzliche
Stichwahl durchzuführen.

Einrichtung von misc-Gruppen:

Es wurde vorgeschlagen, die Einrichtung einer misc-Gruppe bei
Unterteilung einer Gruppe bzw. Neueinrichtung einer Hierarchie
explizit vorzuschreiben.

de.alt.all:

Der Abschnitt zur Unterhierarchie de.alt.all in den "Empfehlungen
zur Einrichtung von de-Newsgroups" wurde komplett aus den derzeit
gültigen Einrichtungsregeln übernommen, ergänzt um einen Hinweis
auf FAQs, die das Verfahren in de.alt.admin näher erläutern.
Immer wieder in de.alt.admin aufflammende Diskussionen lassen
aber vermuten, dass eine Neuformulierung gewünscht wird.

Alternativ wäre es auch denkbar, die Erläuterungen zu
de.alt ganz aus den Regeln für de.!alt.all zu streichen. Neben
der Erklärung, daß diese Regeln nicht zuständig sind, könnte
noch ein Verweis auf de.alt.admin und eventuell auf vorhandene
FAQs erfolgen.

Stimmberechtigung:

Was ist ein Realname?
Soll das Verbot von Sammelaccounts bei Abstimmungen festschreiben
werden (one Account = one Vote)?
Ist Reply-Fähigkeit ein notwendiges Kriterium fuer eine gültige
Stimme - auch bei Abstimmungen ohne persönliche Wahlscheine.

Abstimmungszeitraum:

Ist es sinnvoller, den Abstimmungszeitraum - beginnend mit der
Veröffentlichung des jeweiligen CfV - exakt festzulegen?

Mindestanzahl Ja-Stimmen:

Bei der Bewertung des Abstimungsergebnisses werden wie üblich
zwei Kriterien herangezogen. Die 2/3-Mehrheit dient dazu, die
Akzeptanz eines Vorschlages bei den Netzteilnehmern zu prüfen.
Außerdem soll durch die geforderte Mindestzahl von Ja-Stimmen
der Bedarf für die vorgeschlagene Änderung geklärt werden.

Die Forderung nach einer Erhöhung der letztgenannten Hürde wurde
in der Vergangenheit schon mehrfach erhoben. Begründet wird dies
meist mit der schnell wachsenden Zahl der Usenet-Teilnehmer
und/oder der Gefahr, daß "tote" Gruppen ohne ausreichenden
eigenen Traffic eingerichtet werden.

Wir haben vor, eine solche Erhöhung der Mindest-Ja-Stimmenzahl
in einer gesonderten Abstimmung (im selben CfV) zur Wahl zu
stellen. Hierbei werden wir uns natürlich an die in den
»Empfehlungen zur Einrichtung von de-Newsgroups« gestellte
Forderung halten: Die Erhöhung der Mindest-Ja-Stimmenzahl auf <x>
ist nur dann angenommen, wenn sich dafür eine 2/3-Mehrheit findet
_und_ die Anzahl der Ja-Stimmen mindestens <x> beträgt.

Dabei steht <x> natürlich für die neu festzulegende Anzahl.
Unser Vorschlag lautet x=80.

Entscheidungsmöglichkeiten bei Einsprüchen:

Neben der relativ offenen Formulierung im Entwurf ist auch
über eine restriktive Festlegung der möglichen Konsequenzen
aus Einspruechen diskutiert worden. Die kürzeste Formel lautet:
Entweder ist die beanstandete Abstimmung (CfV) gültig (Einspruch
abgelehnt), oder sie wird annulliert (Einspruch stattgegeben).

Sperrfristen und inhaltlich kollidierende Vorschläge:

Die Sperrfristen hören auf. [*]

Der Entwurf sieht keine Sperrfrist vor, es gibt sie folglich
nicht. Es scheint nicht möglich, ein genaues Kriterium anzugeben,
wann zwei Vorschläge hinreichend verschieden sind, sodaß die
Sperrfrist nicht mehr greift. Außerdem werden so möglicherweise
auch sinnvolle und dringende Änderungen blockiert
(Mißbrauchsgefahr!).

Analoges gilt auch für ein Zurückstellen von RfDs wegen
inhaltlicher Kollision mit laufenden Verfahren. Hier ist die
Vernunft der Beteiligten und keine exakte Regelung gefragt.

Offensichtlichen Mißbrauch von dana (z.B. vielfach wiederhohlter
RfD zur gleichen Gruppe) soll der dana-Moderator unter Berufung
auf Abschnitt 1 der Moderationsrichtlinien dennoch verhindern
können. Er unterliegt dabei der Kontrolle durch die
Netzgemeinschaft, die letztlich durch einen RfD zur Neuwahl
ausgeübt wird.

[*] (C) Wolfgang Kopp, in Anlehnung an die Paulskirchenverfassung
von 1848, dort: "Die Verwaltungsrechtspflege hört auf."

Abstimmungsmodalitäten für dieses Verfahren:

Offen ist auch noch, ob die beiden Texte gemeinsam oder einzeln
zur Wahl gestellt werden. Da sich beide Texte z.T. gegenseitg
bedingen, spricht eigentlich vieles für eine gemeinsame
Abstimmung. Allerdings wollen wir verhindern, dass konsensfähige
Reformvorschläge durch extrem strittige Punkte blockiert werden.
Deshalb ist es auch denkbar, neben der schon genannten Mindest-
Ja-Stimmenzahl über weitere Fragen eine getrennte Abstimmung
durchzuführen.


Danksagung:
~~~~~~~~~~~

Es würde zu weit führen, hier alle jene aufzuzählen, die durch ihre
Diskussionsbeiträge in der Mailingliste und in dang zu den Entwürfen
beigetragen haben. Unser besonderer Dank gilt Chris Blum und
Thomas Roessler. Ohne ihre Vorarbeit wäre dieser RfD nie
zustandegekommen.

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~

Entwurf der:
~~~~~~~~~~~~

Richtlinien für die Moderation von de.admin.news.announce


Charta von de.admin.news.announce: In dieser Gruppe werden
Diskussions- (RfD, Request for Discussion) und Abstim­
mungsaufrufe (CfV, Call for Votes), Abstimmungsergebnisse
und Listen laufender Verfahren betreffend die Einrichtung,
Entfernung und Veränderung von Gruppen unter de.* (ohne
de.alt), die zugehörigen Kontrollnachrichten, sowie Adminis­
tration, Regelwerk und Moderation betreffende Artikel
gepostet.

Dieser Text beschreibt die Richtlinien für die Moderation der
deutschsprachigen Gruppe de.admin.news.announce, kurz: dana. Der
dana-Moderator hat im wesentlichen drei Aufgaben:

· Die Moderation von de.admin.news.announce selbst.

· Das Versenden von Steuernachrichten zur Einrichtung und Löschung
von Gruppen unterhalb von de.all und zur Pflege dieser Hierarchie
(newgroup, rmgroup, checkgroups).

· Die Pflege und behutsame Fortschreibung der Empfehlungen für die
Einrichtung von de-Gruppen.

1. Moderation

Über den Tisch des dana-Moderators gehen alle Vorschläge (RfD),
Wahlaufrufe (CfV) etc., die bei Einrichtungen, Entfernungen,
Umbenennungen und Unterteilungen von de-Gruppen sowie administrativen
Angelegenheiten der de-Hierarchie anfallen. Aufgabe des Moderators
ist eine formale Kontrolle der eingehenden Postings auf Konformität
mit den Empfehlungen zur Einrichtung von Gruppen unterhalb von de.all
sowie eine Überprüfung inhaltlicher Minimalanforderungen: Postings,
die laut RfC oder allgemeinem Gebrauch unzulässige Gruppennamen zur
Diskussion oder Abstimmung stellen, in sich extrem unschlüssig sind
(Verwendung verschiedener Namen für die gleiche Gruppe und dergleichen
mehr) oder nicht erkennen lassen, was gefordert beziehungsweise zur
Diskussion gestellt wird, sind zurückzuweisen.

Bei der Entscheidung, welche Artikel zu veröffentlichen sind, soll
sich der Moderator einer weitergehenden inhaltlichen Würdigung des
Vorschlags (beispielsweise der Beurteilung der hierarchischen
Einordnung) enthalten, da dies Aufgabe der Diskussion in
de.admin.news.groups/misc ist. Ebenso enthält sich der Moderator
eigenmächtiger Interventionen in laufende Verfahren, er soll
beispielsweise nicht aus eigenem Antrieb eine Abstimmung abbrechen.

Bei sachlichen Kollisionen mehrerer Verfahren sowie bei dem Einreichen
oder Weiterverfolgen eines Verfahrens, das ganz oder teilweise
offensichtlich mißbräuchlich ist, kann die Moderation alle
erforderlichen Maßnahmen treffen, um den ordnungsgemäßen und fairen
Ablauf sämtlicher Verfahren zu gewährleisten. Gibt es kein milderes
Mittel, kann sie eine mißbräuchliche Einreichung zurückweisen oder ein
solches Verfahren abbrechen. Das Verfahren zur Neuwahl der dana-
Moderation bleibt hiervon unberührt.

2. Steuernachrichten

Im Einklang mit den Empfehlungen für die Einrichtung von de-Gruppen
setzt der dana-Moderator die als Ergebnis in de.admin.news.announce
geposteten und in de.admin.news.groups akzeptierten Beschlüsse der
Netzgemeinschaft durch Versenden von Steuernachrichten zur Einrichtung
oder Auflösung von Gruppen sowie einer Aufnahme in die bzw. Streichung
aus der von ihm geposteten »checkgroups«-Nachricht um.

Die Gruppen der Unterhierarchie de.alt.all behandelt der dana-
Moderator bei der Erstellung des checkgroups für de.all nach bestem
Wissen und Gewissen. Eine weitergehende Zuständigkeit des dana-
Moderators für de.alt besteht nicht.

3. Pflege und Fortschreibung der Richtlinien

Dem dana-Moderator obliegt die Pflege der Empfehlungen für die
Einrichtung von de-Gruppen, die er monatlich nach
de.admin.news.announce postet. Kleinere Änderungen am Text können von
jedermann in de.admin.news.announce vorgeschlagen werden. Innerhalb
von vierzehn Tagen nach der Veröffentlichung kann jeder Netzteilnehmer
durch Posting in de.admin.news.announce Widerspruch einlegen. Der
Proponent kann dann entweder ein formelles Verfahren entsprechend den
Empfehlungen in Gang setzen oder seinen Vorschlag zurückziehen. Wird
kein Widerspruch eingelegt, so gilt der Vorschlag als angenommen. Sind
umfangreiche Änderungen geplant, so sollte direkt ein formelles
Verfahren eingeleitet werden.

Analoges gilt für die Moderationsrichtlinien, den vorliegenden Text.

4. Einspruchsverfahren

An <eins...@dana.de> eingesandte Einsprüche gegen das Ergebnis eines
Abstimmungsverfahrens werden vom dana-Moderator unverzüglich in
de.admin.news.announce veröffentlicht. Nach einer Diskussionsfrist
von mindestens 7 Tagen entscheidet der Moderator unter
Berücksichtigung der Diskussion in de.admin.news.groups|misc, ob die
Abstimmung gültig ist (Einspruch abgelehnt) oder dem Einspruch
stattgegeben wird. Die Entscheidung und die weitere Vorgehensweise
(korrigiertes Wahlergebnis, erneute Abstimmung, ...) wird in
de.admin.news.announce veröffentlicht. Diese Entscheidung ist
endgültig (»Schiedsrichterentscheid«).

Bei der Entscheidungsfindung - vor allem bei strittigen Fragen, z.B.
Verdacht auf Wahlmanipulation - soll sich der Moderator am »Geist der
Regeln« orientieren. Im Usenet kann es kaum endgültige Beweise geben,
daher muß die Entscheidung so fallen, wie es nach Kenntnis der Fakten
sinnvoll erscheint. Der Moderator von dana ist dazu gewählt, diese
Entscheidung nach bestem Wissen und Gewissen zu fällen.

Boris 'pi' Piwinger

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. Aufruf zur Diskussion

Neufassung der Richtlinien zur
Neueinrichtung von Gruppen in de.*

Der untenstehende Text ist ein Versuch, die Richtlinien
zur Einrichtung von Gruppen in der Hierarchie de.* auf das
notwendige Mindestmaß zu reduzieren und von
Selbstverständlichkeiten zu befreien.

Dies bedeutet gleichzeitig eine Ausweitung der Kompetenzen
der Moderation von de.admin.news.announce, der in einer
ganzen Reihe von Fragen das letzte Wort überlassen wird.
Eine Moderation, die zu weit vom groben Konsens in
de.admin abweicht, müßte in diesem Fall durch das Auslösen
eines Neuwahlverfahrens zur Raison gebracht und ggfs.
ersetzt werden.


Zu den Änderungen im einzelnen:

- Das Wahlverfahren als solches wird _nicht_ geregelt,
sondern der Einigung zwischen dem Proponenten, dem
Publikum in de.admin.news.groups und der Moderation in
de.admin.news.announce überlassen. Die Idee dahinter
ist, neben dem etablierten Wahlverfahren (Mailantwort
auf den 1. CfV, Bestätigung per Mail oder 2. CfV) auch
andere Protokolle zuzulassen. Man könnte dabei zum
Beispiel an die Schlichting-Babelsche Variante von den
personalisierten Stimmzetteln denken, die per Mail
zugestellt werden.

Die gebräuchlichsten Verfahren müßten von interessierten
Netzteilnehmern und/oder der Moderation in einem FAQ
niedergelegt werden. Weniger gebräuchliche Verfahren
wären vor dem CfV in de.admin.news.groups zu
diskutieren.

Zu überwachen wäre die Wahl eines akzeptablen Verfahrens
durch die dana-Moderation und (in letzter Instanz) durch
die Netzgemeinde in de.admin.news.groups.

- Es bleibt weitgehend offen, was zur Abstimmung gestellt
wird: Bedingte und kombinierte Abstimmungen werden
_nicht_ ausgeschlossen; auch sie bleiben der Einigung
zwischen Proponenten, de.admin.news.groups und
Moderation überlassen. Um Überraschungen zu verhindern,
wird die Übereinstimmung zwischen CfV-Vorschlag und dem
letzten vorhergehenden RfD gefordert.

- Es gibt keine Sperrfrist; konkurrierende Verfahren
werden nicht geregelt und damit insbesondere nicht
ausgeschlossen. Es bliebe einer Moderation dabei
durchaus unbelassen, gewisse Verfahren abzulehnen - wenn
sie dies denn in de.admin.news.groups vertreten zu
können glaubt.

- Einsprüche werden nur insoweit geregelt, daß sie nach
dem Ergebnis eines Verfahrens möglich sind. Einsprüche
gegen laufende Verfahren (etwa mit dem Ziel des Abbruchs
einer laufenden Abstimmung) werden nicht explizit
behandelt und damit insbesondere nicht ausgeschlossen.
Das gleiche gilt für die Behandlung derartiger
Einsprüche durch die Moderation noch während eines
laufenden Verfahrens; diese könnte zum Beispiel den
Abbruch eines laufenden Verfahrens auch gegen den Willen
des betreffenden Wahlleiters zur Folge haben.


Der Richtlinienentwurf im Volltext:


Bemerkung zum Procedere

Dieser RfD erscheint gleichzeitig und in Konkurrenz zu
einem anderen, deutlich ausführlicheren
Formulierungsvorschlag, der auf der
<de-regeln>-Mailingliste ausgearbeitet wurde. Die
Proponenten dieser beiden Verfahren sind sich einig, daß
sie die beiden Texte in getrennten RfDs diskutieren, aber
in einem einheitlichen Wahlverfahren zur Abstimmung
bringen wollen.


Proponent: Boris Piwinger <3....@Math.MIT.EDU>


------------------------------
Gruppenänderungen in de.all


Diese Spielregeln gelten für die Einrichtung, Entfernung und Änderung
von Gruppen in der Hierarchie de. Ausgenommen sind die Gruppen unter
de.alt, über die in de.alt.admin nach Fairness entschieden wird.


1. Diskussion

Wer die Einrichtung, Entfernung oder Änderung einer Gruppe anregen
will, verfaßt einen formalen Diskussionsaufruf, den er bei der
Moderation von de.admin.news.announce zur Veröffentlichung einreicht.
Der Aufruf erscheint in de.admin.news.announce, de.admin.news.groups
und weiteren vom Vorschlag betroffenen Gruppen. Die Diskussion
erfolgt in de.admin.news.groups.

Zwischenergebnisse der Diskussion können in Form weiterer
Diskussionsaufrufe ebenfalls in de.admin.news.announce veröffentlicht
werden.

2. Abstimmung

Nach Abschluß der Diskussion wird eine Abstimmung durchgeführt. Der
Aufruf hierzu erscheint in de.admin.news.announce und anderen vom
Vorschlag betroffenen Gruppen. Der zur Abstimmung gestellte Vorschlag
sollte mit dem zuletzt veröffentlichten Diskussionsaufruf
übereinstimmen.

3. Ergebnis

Das Ergebnis der Abstimmung wird in den gleichen Gruppen wie der
Aufruf veröffentlicht. Es enthält die komplette Liste der
eingegangenen Stimmen einschließlich Namen und E-Mail-Adressen der
Abstimmenden.

Angenommen werden Vorschläge mit mindestens 60 Ja-Stimmen und
mindestens doppelt so vielen Ja-Stimmen wie Nein-Stimmen.

Innerhalb von 7 Tagen nach Veröffentlichung des Ergebnisses kann jeder
Netzteilnehmer begründeten Einspruch bei der Moderation von
de.admin.news.announce einlegen. Derartige Einsprüche werden umgehend
veröffentlicht.

Die Moderation von de.admin.news.announce setzt das Ergebnis nach Ende
der Einspruchsfrist und einer Entscheidung über etwaige Einsprüche um.

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~

Entwurf der:
~~~~~~~~~~~~

Empfehlungen zur Einrichtung von de-Newsgroups


1. Grundsätzliches

Diese Empfehlungen stellen das allgemein akzeptierte Verfahren zur
Einrichtung, Auflösung und Modifikation von Gruppen in der
deutschsprachigen Usenet-Hierarchie de.all mit Ausnahme der
Unterhierarchie de.alt.all dar. Sie sind - außer für die Moderation
von de.admin.news.announce in dieser Funktion - nicht bindend, da die
Entscheidung über die Einrichtung (Abschaffung, Modifikation etc.)
einer Gruppe letztlich in den Händen der einzelnen
Systemadministratoren liegt. Die Empfehlungen wollen diesen jedoch
eine Entscheidungshilfe liefern, um so eine möglichst weite
Verbreitung »allgemein akzeptierter« Gruppen zu erreichen.

Man kann davon ausgehen, daß Gruppen, die nach diesen Empfehlungen
»angenommen« sind, allgemein eingerichtet werden; Gruppen, die
»abgelehnt« wurden, werden erfahrungsgemäß nur unter außergewöhnlichen
Umständen eingerichtet und verbreitet werden.

Obwohl sich diese Empfehlungen zunächst nur auf die Einrichtung,
Auflösung und Modifikation von Gruppen beziehen, spricht nichts
dagegen, auch andere die deutschsprachige Usenet-Hierarchie de.all
betreffende Entscheidungen nach analogen, nur im Detail abweichenden
Regeln herbeizuführen. Dies gilt insbesondere für Änderungen an
diesen Empfehlungen selbst. Änderungen, die die Kriterien zur Annahme
eines Vorschlages betreffen, gelten nur dann als angenommen, wenn sie
es sowohl nach den alten als auch nach den neuen Empfehlungen sind.

2. Die Unterhierarchie de.alt.all

Nicht relevant ist das hier vorgestellte Verfahren für die Gruppen in
der Unterhierarchie de.alt: Die einzige echte Regel lautet hier:
Fairneß.

Eine Einrichtung einer Gruppe in de.alt.* läuft folgendermaßen ab: Man
postet in de.alt.admin, ob jemand Einwände gegen die vorgeschlagene
Gruppe hat, wartet fairerweise lang genug, damit sich auch wirklich
jemand beklagen kann (News-Laufzeiten liegen bedauerlicherweise immer
noch im Tage-, nicht im Minutenbereich - also etwa eine Woche warten),
und schickt, wenn der Protest nicht allzu heftig war, einfach die
newgroup-Message. Nachteil: de.alt wird nur von einer kleineren Menge
von Systemen getragen; man erreicht also nur einen kleineren Teil
gegebenenfalls Interessierter.

Einen Überblick über die aktuelle Praxis bei der Einrichtung
(Entfernung, Umbenennung, ...) von de.alt-Gruppen geben die regelmäßig
in de.alt.admin geposteten FAQs, die auf Anfrage auch beim Moderator
von de.admin.news.announce erhältlich sind.

3. Vorschlag und Diskussion

3.1. Der Diskussionsaufruf

Der Vorschlag (RfD, Request for Discussion) zur Einrichtung einer
neuen Gruppe oder zur Entfernung oder Veränderung einer bestehenden
Gruppe muß in der moderierten Gruppe de.admin.news.announce (durch
Einsenden an <mode...@dana.de>) veröffentlicht werden. Vorschläge
mit thematischem Bezug auf andere Gruppen der de-Hierarchie werden bei
der Veröffentlichung in de.admin.news.announce per Crossposting auch
in diesen veröffentlicht.

Ein RfD besteht aus zwei Teilen: Dem Vorschlag an sich und einer
ausführlichen Begründung, warum die angesprochene Gruppe eingerichtet,
geändert oder aufgelöst werden soll. Der Vorschlag umfaßt:

· den Namen der neu einzurichtenden oder umzubenennenden oder in
ihrer Charta oder Kurzbeschreibung zu ändernden Gruppe,

· eine Kurzbeschreibung (nach Möglichkeit sollten Gruppenname und
Kurzbeschreibung, getrennt durch einen 8-Zeichen-Tabulator,
insgesamt weniger als 80 Zeichen einnehmen) und

· eine Charta.

Die Charta beschreibt detailliert Thema und Regeln der Gruppe.
Wird die Auflösung einer bestehenden Gruppe vorgeschlagen, so muß
der Vorschlag eine Gruppe benennen, in der Diskussionen zum Thema
der aufzulösenden Gruppe in Zukunft geführt werden können; die
Angabe einer Charta ist in diesem Fall nicht nötig.

· Außerdem ist anzugeben, ob die Gruppe moderiert oder unmoderiert
sein soll; bei moderierten Gruppen sollten Name und Mailadresse des
Moderators oder der Moderatoren in spe genannt werden.

Fehlen einzelne dieser Punkte, sollte zunächst eine informelle
Voranfrage nach de.admin.news.groups gepostet und dann anhand der
dortigen Diskussion ein formeller Vorschlag ausgearbeitet werden.

Die anschließende Diskussion soll ausschließlich in der Gruppe
de.admin.news.groups stattfinden. Der Followup-To-Header wird vor der
Veröffentlichung in de.admin.news.announce entsprechend gesetzt.

3.2. Die Diskussionsphase

Der Diskussion sollte mindestens ein Zeitraum von vierzehn Tagen
eingeräumt werden. Zeigt die Diskussion Ergebnisse, die stark von dem
ursprünglichen Vorschlag abweichen, so empfiehlt es sich, als
Zusammenfassung einen neuen formellen Vorschlag zu formulieren, und
diesen als 2., 3., ... RfD in de.admin.news.announce zu
veröffentlichen.

Über Inhalt von Diskussions- und Wahlaufruf entscheidet allein der
Proponent. Ein Anspruch auf Übernahme von während der
Diskussionsphase geäußerten Vorschlägen besteht nicht, die
Nichtübernahme begründet kein Einspruchsrecht. Es empfiehlt sich
dennoch, auf Diskussionsvorschläge einzugehen; der Wahlaufruf sollte
weitgehend mit dem letzten geposteten Diskussionsaufruf
übereinstimmen.

Hat sich in der Diskussion schließlich ein Vorschlag
herauskristallisiert, so kann dieser durch den Proponenten des
Verfahrens oder mit dessen Zustimmung durch einen anderen
Netzteilnehmer zur Abstimmung gestellt werden. Im Falle eines
Rückzugs des Proponenten kann ein anderer Netzteilnehmer auch ohne
dessen Einverständnis die Abstimmung durchführen, sofern höchstens
vier Wochen seit dem letzten Diskussionsaufruf vergangen sind;
andernfalls muß ein neues Verfahren begonnen werden.

4. Verkürztes Verfahren

Für Änderungen des Namens, der Kurzbeschreibung oder der Charta einer
Gruppe, die deren Moderationsstatus unberührt lassen, ist ein
verkürztes Verfahren möglich. Dazu veröffentlicht der Proponent die
vorgeschlagene Änderung in de.admin.news.announce und in der
betroffenen Gruppe, mit Followup-To auf de.admin.news.groups. Wird
während der auf die Veröffentlichung folgenden 14 Tage kein
Widerspruch in de.admin.news.announce erhoben, gilt die Änderung als
beschlossen. Andernfalls ist ein formelles Verfahren einzuleiten.

5. Die Abstimmung

5.1. Abstimmungsaufruf und Wahlscheine

Der Abstimmungsaufruf (CfV, Call for Votes) wird an den gleichen
Stellen wie der ihm vorangehende Diskussionsaufruf veröffentlicht.
Der Aufruf und die Wahlscheine müssen den folgenden Punkten genügen:

· Der Aufruf enthält den kompletten Vorschlag, das heißt: den Namen
der Gruppe, ihre Kurzbeschreibung und Charta, ihren
Moderationsstatus und - wenn es sich um eine moderierte Gruppe
handelt - Namen des Moderators oder der Moderatoren und Mailadresse
der Moderation.

Ein Abstimmungsaufruf sollte nur einen einzigen Vorschlag zur Wahl
stellen; Sammelabstimmungen über mehrere zusammenhangslose
Vorschläge sind zu vermeiden.

· Bei der Einrichtung oder Auflösung mehrerer Gruppen wird für jede
Gruppe eine unabhängige Abstimmung durchgeführt.

Wenn eine bestehende Gruppe unterteilt oder eine neue
Unterhierarchie eingerichtet werden soll, so sollte dies in einem
einzigen Wahlaufruf geschehen. Dabei wird über jede der neu
entstehenden Gruppen einzeln abgestimmt. Bei Unterteilung einer
Gruppe bedarf die Erweiterung des Namens der Ursprungsgruppe um das
Suffix ».misc« im Erfolgsfalle des Vorschlags (das heißt bei
Annahme mindestens einer der Gruppen) keiner eigenen Abstimmung.
Die Neueinrichtung einer Hierarchie wird wie die Einrichtung einer
neuen Gruppe mit nachfolgender Unterteilung behandelt. Die
Abstimmung über die einzelnen Gruppen ist nur dann relevant, wenn
die neue Hierarchie angenommen wird (Kaskadierung der Vorschläge).

Außerdem kann eine kombinierte Abstimmung erfolgen, wenn in der
Diskussion keine Einigkeit über Namen, Kurzbeschreibung, Charta
oder Moderationsstatus der Gruppe oder die Person des Moderators zu
erreichen war. In diesem Fall ist über jede gewünschte Kombination
eine unabhängige Abstimmung durchzuführen; sinnvollerweise
natürlich in einem gemeinsamen Wahlaufruf.

· Der Abstimmungsaufruf enthält entweder einen Blanko-Wahlschein,
oder es ist eine Mailadresse angegeben sein, bei der die Wähler
einen persönlichen Wahlschein anfordern können.

Dem Wahlschein müssen klare Anweisungen beiliegen, wie für oder
gegen die Einrichtung (Auflösung, Statusänderung etc.) der
vorgeschlagenen Gruppe gestimmt werden kann. Dabei müssen die
Anweisungen für alle Arten der Stimmabgabe gleich klar sein. Alle
Arten der Stimmabgabe müssen gleich einfach möglich sein. Die
angegebene Adresse für die Abgabe der Stimmen muß sowohl Ja-, als
auch Nein-Stimmen (sowie Enthaltungen) annehmen; sie muß jedoch
nicht mit der Absenderadresse des Wahlaufrufs oder der Wahlschein-
Anforderungsadresse übereinstimmen. Der Wahlschein ist so zu
gestalten, daß für eine Änderung des status quo mit »Ja« und für
seine Beibehaltung mit »Nein« zu stimmen ist.

Bei Verwendung von Blanko-Wahlscheinen muß die Rückadresse des
Abstimmungsaufrufs (dies ist die Adresse im Reply-To-Header, falls
dieser nicht vorhanden ist, die Adresse im From-Header) mit der
Adresse für die Stimmabgabe übereinstimmen.

Persönliche Wahlscheine werden bei der Ausgabe auf eine Art
markiert, die eine eindeutige Zuordnung des Wahlscheins zum
Abstimmenden ermöglicht und die das Erzeugen gültig erscheinender
Fälschungen soweit wie möglich ausschließt.
Wahlscheinanforderungen ohne funktionierende Rückadresse im From-
oder Reply-To-Header werden vom Wahlscheinausgebenden (in der Regel
ist das der Wahlleiter) ignoriert. Die Rückadresse des
Abstimmungsaufrufs muß mit der Adresse zur Anforderung der
Wahlscheine übereinstimmen; die Rückadresse des Wahlscheins muß mit
der Adresse übereinstimmen, die die Stimmen entgegennimmt.

5.2. Das Wahlverfahren

Die Wahlen sind frei und gleich. Wahlberechtigt sind nur natürliche
Personen. Der Wähler muß seinen Realnamen und seine Mailadresse
(normalerweise im From-Header der Stimme) nennen. Gehen mehrere
Stimmen von der gleichen Person ein, so wird davon nur die zuletzt
eingegangene gewertet. Eingehende Stimmmen werden durch den
Wahlleiter per Mail bestätigt; bei Abstimmungen mit persönlichen
Wahlscheinen wird die Bestätigung an die Adresse gesendet, an die der
Wahlschein ausgegeben wurde.

Es werden nur solche Stimmen gewertet, die direkt und per Mail an die
Abstimmungsadresse geschickt wurden und eine eindeutige
Willensäußerung enthalten. Stimmen, die im Usenet oder im Namen
Dritter abgegeben wurden, werden nicht gezählt. Wird die Wahl unter
Verwendung markierter (persönlicher) Wahlscheine durchgeführt, gelten
nur solche Stimmen, die auf korrekt markierten Wahlscheinen abgegeben
wurden.

Die Abstimmungsperiode dauert zwischen 21 und 30 Tagen. Das Ende der
Abstimmungsperiode wird im ersten Aufruf zur Stimmabgabe festgelegt,
es kann nicht mehr geändert werden. Die Abstimmungsperiode beginnt
mit der erstmaligen Veröffentlichung des Wahlaufrufs in
de.admin.news.announce.

Der Wahlleiter oder der Proponent kann die Abstimmung durch eine
Mitteilung in de.admin.news.announce abbrechen, wenn Probleme
auftreten, die den ordnungsgemäßen Verlauf gefährden. Innerhalb von
vier Wochen nach dem Abbruch kann jederzeit ein neuer Wahlaufruf
ergehen; Aufrufe zu Wiederholungswahlen sollen keinen Blanko-
Wahlschein enthalten, sondern Interessierte zur Anforderung eines
persönlichen Wahlscheins auffordern. Wird die gleiche Abstimmung
zweimal in Folge abgebrochen, kann der Proponent oder der Moderator
von de.admin.news.announce verlangen, daß ein neuer Wahlleiter
bestimmt wird. Wird eine Abstimmung viermal in Folge abgebrochen,
gilt der zur Abstimmung stehende Vorschlag als abgelehnt.

In der Mitte der Abstimmungsperiode soll eine Wiederholung des
Wahlaufrufs gepostet werden. Der erneute Wahlaufruf muß sich auf
exakt den gleichen Vorschlag beziehen wie der erste Aufruf. Er muß
die gleichen Informationen und Instruktionen wie dieser enthalten.
Die Art der Wahlscheinausgabe muß gleich sein. Stimmen können nicht
während der Wahlperiode auf eine andere laufende Abstimmung übertragen
werden, sie gelten ausschließlich für den Vorschlag, für den sie
abgegeben wurden. Die Wiederholung des Wahlaufrufs darf keine
Teilergebnisse der Abstimmung enthalten; sie soll jedoch eine Liste
der Personen enthalten, die bereits abgestimmt haben.

5.3. Das Ergebnis

Nach dem Ende der Wahlperiode veröffentlicht der Wahlleiter das
ausgezählte Wahlergebnis in de.admin.news.announce und den anderen
Gruppen, in denen Vorschlag und Wahlaufruf veröffentlicht wurden.
Dieses Ergebnis muß Mailadresse, Realnamen und Stimme jedes
Abstimmungsteilnehmers in einer nachvollziehbaren Ordnung enthalten.
Die Zusammenstellung des Ergebnisses obliegt dem Wahlleiter.

Ein Vorschlag gilt als angenommen, wenn mindestens doppelt so viele
Ja-Stimmen wie Nein-Stimmen abgegeben wurden und die Anzahl der Ja-
Stimmen mindestens 30 beträgt. Werden bei einer kombinierten
Abstimmung mehrere alternative Vorschläge angenommen, so gilt davon
allein derjenige als beschlossen, der die größte Differenz von Ja- und
Nein-Stimmen aufweist; bei Differenzengleichheit gewinnt der Vorschlag
mit den wenigsten Nein-Stimmen. Führt auch diese Regel keine
Entscheidung herbei, so ist es dem Proponent überlassen, einen der
verbliebenen Vorschläge auszuwählen. Alternativ dazu kann bereits im
CfV eine Stichfrage gestellt werden, welcher Vorschlag im Fall der
Annahme von mehreren alternativen Vorschlägen bevorzugt wird.

Einsprüche müssen binnen einer Woche nach Veröffentlichung des
Wahlergebnisses in de.admin.news.announce per Mail an
<eins...@dana.de> gerichtet werden. Sie werden vom dana-Moderator
unverzüglich in de.admin.news.announce veröffentlicht. Über die
Annahme entscheidet der Moderator von de.admin.news.announce unter
Berücksichtigung der Diskussion in de.admin.news.groups.

Ist die Abstimmung erfolgreich, die Einspruchsfrist abgelaufen, und
sind eventuelle Einsprüche abgelehnt oder zurückgezogen, verschickt
der Moderator von de.admin.news.announce die für die Umsetzung nötigen
Steuernachrichten.

Olaf Erkens

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) wrote:

> Wenn eine bestehende Gruppe unterteilt oder eine neue
> Unterhierarchie eingerichtet werden soll, so sollte dies in einem
> einzigen Wahlaufruf geschehen. Dabei wird über jede der neu
> entstehenden Gruppen einzeln abgestimmt.

Bis dahin ok ...

> Bei Unterteilung einer
> Gruppe bedarf die Erweiterung des Namens der Ursprungsgruppe um das
> Suffix ».misc« im Erfolgsfalle des Vorschlags (das heißt bei
> Annahme mindestens einer der Gruppen) keiner eigenen Abstimmung.

Auch wenn ich es durchaus diskussionswürdig finde, ob man unbedingt
diese Gruppe *immer* braucht - könnte man den Namen wenigstens mal auf
einen Begriff wie ».sonstiges« ändern, damit jedem im deutschen
Sprachraum auch ohne vorheriges Studium diverser DAU-Anweisungen klar
ist, was damit gemeint ist?! Ich mein - nur so wegen der
Benutzerfreundlichkiet?!

> Die Neueinrichtung einer Hierarchie wird wie die Einrichtung einer
> neuen Gruppe mit nachfolgender Unterteilung behandelt.

Diese Formulierung würde bedeuten, daß obiger Absatz immer zieht und
damit sofort die Gruppe ».sonstiges« eingerichtet wird?! Ist es das,
was gewollt ist oder wo ist mein Denkfehler?

> Bei Verwendung von Blanko-Wahlscheinen muß die Rückadresse des
> Abstimmungsaufrufs (dies ist die Adresse im Reply-To-Header, falls
> dieser nicht vorhanden ist, die Adresse im From-Header) mit der
> Adresse für die Stimmabgabe übereinstimmen.

Könnte man evtl. der Einfachheit halber formulieren: "... im Reply-To-
oder From-Header) ...". Dann sollte es in jedem Falle passen und
Mistverständnisse werden unwahrscheinlicher.

Olaf


********************* OLAF ERKENS **********************
FJ@#RRR http://www.wiso.uni-dortmund.de/~1/
FJ1200 3YA BJ93 110Mm rrr#25
WANTED: XJ1200S shaft driven*injection*catalytic converter

Adrian Suter

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

[Anmerkung: Da ich vergessen habe die entsprechenden
Referenzen innerhalb des Textes zu ersetzen werden die
Artikel der Grossen Regelreform mit korrekten Msg-IDs im
Rahmen-RfD supersedet.]

Erster Aufruf zur Diskussion (1.RfD)
===================================
zur Neufassung der Einrichtungsregeln
=====================================
*Rahmen-RfD*
===========
Worum es geht
=============
Dies ist ein Aufruf zur Diskussion zur Neufassung der "Regeln für die
Einrichtung und Entfernung von Usenet-Gruppen", die wöchentlich in
de.newusers.infos, de.admin.news.announce, de.newusers.questions,
de.admin.news.groups und de.alt.admin gepostet werden.

Der vorliegende Artikel beschreibt den Rahmen, in dem das Verfahren
ablaufen soll.

Die neuen Vorschläge
====================
Es werden zeitgleich mit diesem Rahmen-RfD zwei Vorschläge für die
Neufassung der Einrichtungsregeln gepostet:

* "Vorschlag Mailingliste": Ein Vorschlag wurde in den letzten Monaten
auf einer Mailingliste intensiv diskutiert und bereits im
vergangenen Dezember eingereicht. Aufgrund der Kollision mit einem
früher eingereichten Verfahren wurde der Vorschlag aber nie in den
News diskutiert.

<RfD-1-Reform-2...@dana.de>,
<RfD-1-Reform-3...@dana.de> und
<RfD-1-Reform-4...@dana.de>

* "Vorschlag KISS": Ein weiterer Vorschlag wurde nach einem
informellen Posting in de.admin.news.misc diskutiert. Er wurde
aufgrund dieser Diskussion überarbeitet und wird nun im Rahmen
dieses RfD formell zur Diskussion gestellt.

<RfD-1-Reform-5...@dana.de>

de-r...@prenzl.net

Die Proponenten im einzelnen:

--

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~


Gegenstand:
~~~~~~~~~~~

Dies ist ein Aufruf zur Diskussion über eine Neufassung der
Regelwerke zur Verwaltung der Newshierarchie de.all. Diese Regeln
betreffen das Verfahren zur Einrichtung (Löschung, ...) von Newsgruppen
unter de.!alt.all sowie die Richtlinien für die Moderation von
de.admin.news.announce.

Die derzeit gültigen Regeln werden regelmäßig unter dem Titel
»Einrichtung von Usenet-Gruppen in "de.*"«, Archive-Name:
de-newusers/einrichtung, nach de.newusers.infos gepostet.

An ihre Stelle sollen zwei Texte treten:

* die »Empfehlungen zur Einrichtung von de-Newsgroups«, die das
Verfahren zur Einrichtung, Löschung und Änderung von Gruppen
beschreiben (Entwurf in

<RfD-1-Reform-4...@dana.de>),
und

* die »Richtlinien für die Moderation von de.admin.news.announce«,
die die Arbeit des dana-Moderators regeln (Entwurf in

<RfD-1-Reform-3...@dana.de>). Die Regeln zur »Neuwahl


Erläuterungen:
~~~~~~~~~~~~~~~

Sprachgebrauch:

Glossar:

Kombinierte Abstimmungen:

Einrichtung von misc-Gruppen:

de.alt.all:

Stimmberechtigung:

Abstimmungszeitraum:

Mindestanzahl Ja-Stimmen:

Entscheidungsmöglichkeiten bei Einsprüchen:

Abstimmungsmodalitäten für dieses Verfahren:


Danksagung:
~~~~~~~~~~~

--

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~

Entwurf der:
~~~~~~~~~~~~

Richtlinien für die Moderation von de.admin.news.announce

1. Moderation

2. Steuernachrichten

4. Einspruchsverfahren

--

Olaf Schneider

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. RfD: Reform der Wahlregeln für de.all
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Mailing-Listen-Entwurf)
~~~~~~~~~~~~~~~~~~~~~~~~

Entwurf der:
~~~~~~~~~~~~

Empfehlungen zur Einrichtung von de-Newsgroups


1. Grundsätzliches

2. Die Unterhierarchie de.alt.all

3. Vorschlag und Diskussion

3.1. Der Diskussionsaufruf

· eine Charta.

3.2. Die Diskussionsphase

4. Verkürztes Verfahren

5. Die Abstimmung

5.1. Abstimmungsaufruf und Wahlscheine

Wenn eine bestehende Gruppe unterteilt oder eine neue


Unterhierarchie eingerichtet werden soll, so sollte dies in einem
einzigen Wahlaufruf geschehen. Dabei wird über jede der neu

entstehenden Gruppen einzeln abgestimmt. Bei Unterteilung einer


Gruppe bedarf die Erweiterung des Namens der Ursprungsgruppe um das
Suffix ».misc« im Erfolgsfalle des Vorschlags (das heißt bei
Annahme mindestens einer der Gruppen) keiner eigenen Abstimmung.

Die Neueinrichtung einer Hierarchie wird wie die Einrichtung einer

neuen Gruppe mit nachfolgender Unterteilung behandelt. Die
Abstimmung über die einzelnen Gruppen ist nur dann relevant, wenn
die neue Hierarchie angenommen wird (Kaskadierung der Vorschläge).

Außerdem kann eine kombinierte Abstimmung erfolgen, wenn in der
Diskussion keine Einigkeit über Namen, Kurzbeschreibung, Charta
oder Moderationsstatus der Gruppe oder die Person des Moderators zu
erreichen war. In diesem Fall ist über jede gewünschte Kombination
eine unabhängige Abstimmung durchzuführen; sinnvollerweise
natürlich in einem gemeinsamen Wahlaufruf.

· Der Abstimmungsaufruf enthält entweder einen Blanko-Wahlschein,
oder es ist eine Mailadresse angegeben sein, bei der die Wähler
einen persönlichen Wahlschein anfordern können.

Dem Wahlschein müssen klare Anweisungen beiliegen, wie für oder
gegen die Einrichtung (Auflösung, Statusänderung etc.) der
vorgeschlagenen Gruppe gestimmt werden kann. Dabei müssen die
Anweisungen für alle Arten der Stimmabgabe gleich klar sein. Alle
Arten der Stimmabgabe müssen gleich einfach möglich sein. Die
angegebene Adresse für die Abgabe der Stimmen muß sowohl Ja-, als
auch Nein-Stimmen (sowie Enthaltungen) annehmen; sie muß jedoch
nicht mit der Absenderadresse des Wahlaufrufs oder der Wahlschein-
Anforderungsadresse übereinstimmen. Der Wahlschein ist so zu
gestalten, daß für eine Änderung des status quo mit »Ja« und für
seine Beibehaltung mit »Nein« zu stimmen ist.

Bei Verwendung von Blanko-Wahlscheinen muß die Rückadresse des


Abstimmungsaufrufs (dies ist die Adresse im Reply-To-Header, falls
dieser nicht vorhanden ist, die Adresse im From-Header) mit der
Adresse für die Stimmabgabe übereinstimmen.

Persönliche Wahlscheine werden bei der Ausgabe auf eine Art

5.2. Das Wahlverfahren

5.3. Das Ergebnis

--

Boris 'pi' Piwinger

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

1. Aufruf zur Diskussion


Der Richtlinienentwurf im Volltext:


Bemerkung zum Procedere


Proponent: Boris Piwinger <3....@Math.MIT.EDU>


------------------------------
Gruppenänderungen in de.all


1. Diskussion

2. Abstimmung

3. Ergebnis

--

Heiko Schlichting

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

O.Er...@wiso.uni-dortmund.de (Olaf Erkens) writes:
>Auch wenn ich es durchaus diskussionswürdig finde, ob man unbedingt
>diese Gruppe *immer* braucht - könnte man den Namen wenigstens mal auf
>einen Begriff wie ».sonstiges« ändern, damit jedem im deutschen
>Sprachraum auch ohne vorheriges Studium diverser DAU-Anweisungen klar
>ist, was damit gemeint ist?

Nein.

Stephan Lehmke

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

In article <3532535f...@news.uni-dortmund.de>,
O.Er...@wiso.uni-dortmund.de (Olaf Erkens) writes:

>> Bei Unterteilung einer
>> Gruppe bedarf die Erweiterung des Namens der Ursprungsgruppe um das
>> Suffix ».misc« im Erfolgsfalle des Vorschlags (das heißt bei
>> Annahme mindestens einer der Gruppen) keiner eigenen Abstimmung.

> Auch wenn ich es durchaus diskussionswürdig finde, ob man unbedingt
> diese Gruppe *immer* braucht - könnte man den Namen wenigstens mal auf
> einen Begriff wie ».sonstiges« ändern, damit jedem im deutschen
> Sprachraum auch ohne vorheriges Studium diverser DAU-Anweisungen klar

> ist, was damit gemeint ist?! Ich mein - nur so wegen der
> Benutzerfreundlichkiet?!

>> Die Neueinrichtung einer Hierarchie wird wie die Einrichtung einer
>> neuen Gruppe mit nachfolgender Unterteilung behandelt.

> Diese Formulierung würde bedeuten, daß obiger Absatz immer zieht und
> damit sofort die Gruppe ».sonstiges« eingerichtet wird?! Ist es das,
> was gewollt ist oder wo ist mein Denkfehler?

"bedarf [...] keiner eigenen Abstimmung"

ist ungleich

"wird sofort eingerichtet".

>> Bei Verwendung von Blanko-Wahlscheinen muß die Rückadresse des
>> Abstimmungsaufrufs (dies ist die Adresse im Reply-To-Header, falls
>> dieser nicht vorhanden ist, die Adresse im From-Header) mit der
>> Adresse für die Stimmabgabe übereinstimmen.

> Könnte man evtl. der Einfachheit halber formulieren: "... im Reply-To-
> oder From-Header) ...". Dann sollte es in jedem Falle passen und
> Mistverständnisse werden unwahrscheinlicher.

Aber wenn sowohl Reply-To als auch From existieren, ist nicht mehr
eindeutig, welcher genommen wird.

Gruss
Stephan

--
Stephan Lehmke Stephan...@cs.uni-dortmund.de
Department of Computer Science I Tel. +49 231 755 6434
University of Dortmund FAX 6555
D-44221 Dortmund, Germany

Michael Ottenbruch

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

Am Tue, 31 Mar 1998 02:31:06 GMT, schrieb O.Er...@wiso.uni-dortmund.de
(Olaf Erkens):

> Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) wrote:
>
> [...]


>
> > Die Neueinrichtung einer Hierarchie wird wie die Einrichtung einer
> > neuen Gruppe mit nachfolgender Unterteilung behandelt.
>

> Diese Formulierung würde bedeuten, daß obiger Absatz immer zieht und
> damit sofort die Gruppe ».sonstiges« eingerichtet wird?! Ist es das,
> was gewollt ist oder wo ist mein Denkfehler?

Es besagt zunächst nur, daß bei Neueinrichtung einer Hierarchie die
Einrichtung einer *.misc-Gruppe keiner eigenen Abstimmung bedarf.

> > Bei Verwendung von Blanko-Wahlscheinen muß die Rückadresse des
> > Abstimmungsaufrufs (dies ist die Adresse im Reply-To-Header, falls
> > dieser nicht vorhanden ist, die Adresse im From-Header) mit der
> > Adresse für die Stimmabgabe übereinstimmen.
>

> Könnte man evtl. der Einfachheit halber formulieren: "... im Reply-To-
> oder From-Header) ...". Dann sollte es in jedem Falle passen und
> Mistverständnisse werden unwahrscheinlicher.

Dann wäre es korrekt, die Adresse für die Stimmabgabe in den From-Header
zu setzen und einen Reply-To: woandershin. Diese Form des DAU-Filters
ist nicht vorgesehen. :-)
--
...und tschuess!

Michael
E-mail: M.Otte...@sailor.ping.de

Zippo Zimmermann

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

Heiko Schlichting <he...@cis.fu-berlin.de> wrote:

> Nein.

Doch.

Erhard Sanio

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

In article <1d6rbca.1n1...@acc1-147.telip.uni-sb.de>,

>> Nein.

>Doch.

Nein.

Es geht um *.misc statt *.gut_durchgequirltes_oder_wie_immer .

Miscellanea war eine staendige Rubrik in _deutschen_ Journalen und
Essays seit Goethe. Bildet Euch erstmal in Deutsch ehe ihr tuemelt
bzw sprachpuristet.

SCNR

regards, es

Kay Marquardt

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) wrote:
>Sprachgebrauch:

> soll/sollen grundsaetzlich, begründete Ausnahmen möglich
> sollte/sollten Empfehlung, nicht verbindlich

IMHO zu leicht zu verwechseln.
Auf jeden Fall sollte diese Definition mit in den Text


>Einrichtung von misc-Gruppen:
>
> Es wurde vorgeschlagen, die Einrichtung einer misc-Gruppe bei
> Unterteilung einer Gruppe bzw. Neueinrichtung einer Hierarchie
> explizit vorzuschreiben.

dagegen, in eurer Nomenklatur: sollte

>de.alt.all:


> Alternativ wäre es auch denkbar, die Erläuterungen zu
> de.alt ganz aus den Regeln für de.!alt.all zu streichen. Neben
> der Erklärung, daß diese Regeln nicht zuständig sind, könnte
> noch ein Verweis auf de.alt.admin und eventuell auf vorhandene
> FAQs erfolgen.

genau das, de.alt ist ein eigener Bereich


>Stimmberechtigung:
>
> Was ist ein Realname?

Ausgeschriebener Vor- und Nachnahme, kein Phantasiename, "echte"
Pseudonyme von mir aus (Lieschen Mueller wuerde lieber Anna Gross
heissen)

> Soll das Verbot von Sammelaccounts bei Abstimmungen festschreiben
> werden (one Account = one Vote)?

JA!

> Ist Reply-Fähigkeit ein notwendiges Kriterium fuer eine gültige
> Stimme - auch bei Abstimmungen ohne persönliche Wahlscheine.

JA!

>Mindestanzahl Ja-Stimmen:

JA 80 oder Differenz 50


>Sperrfristen und inhaltlich kollidierende Vorschläge:
>
> Die Sperrfristen hören auf. [*]

JAEIN, Sperrfrist ja, aber nur 1 Monat oder so, Kriterium ist ist die
Meinung des Moderators.

Kay
--
rrr#69hc 33.1 drmHuPT http://www.rrr.net Die Rocker!

Member of Megafete Org-Team http://www.rrr.net/megafete/

Kay Marquardt

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

"Boris 'pi' Piwinger" <3....@Math.MIT.edu> wrote:
[KISS]

ich bin eigentlich fuer die KISS Idee, allerdings ist diese Version
viel zu vage, man kann den gesunden Netzverstand leider nicht durch so
weit gefasste Regeln zurueckbringen

Heiko Schlichting

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

sa...@berlin.snafu.de (Erhard Sanio) writes:
>Miscellanea war eine staendige Rubrik in _deutschen_ Journalen und
>Essays seit Goethe. Bildet Euch erstmal in Deutsch ehe ihr tuemelt
>bzw sprachpuristet.

Die weniger gebildeten koennen sich auch einfach vorstellen, dass ".misc"
fuer
MISChmasch
oder
verMISChtes
steht.

".misc" ist Usenetkultur und steht unter Denkmalschutz. Der ".misc"-Beauftrage
des Usenets wuerde einer Verschandelung nicht zustimmen.

Heiko

Boris 'pi' Piwinger

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

k...@rrr.net (Kay Marquardt) wrote:

>ich bin eigentlich fuer die KISS Idee, allerdings ist diese Version
>viel zu vage, man kann den gesunden Netzverstand leider nicht durch so
>weit gefasste Regeln zurueckbringen

Da bin ich eben nicht so sicher. Das Scheitern des Konkreten mussten
wir zu deutlich erleben. Die Regelung gibt zweifelsohne der Moderation
mehr Spielraum und Verantwortung.

pi
--
Only the paranoid survive. (Andrew S. Grove)

Boris 'pi' Piwinger

unread,
Mar 31, 1998, 3:00:00 AM3/31/98
to

k...@rrr.net (Kay Marquardt) wrote:

>> Es wurde vorgeschlagen, die Einrichtung einer misc-Gruppe bei
>> Unterteilung einer Gruppe bzw. Neueinrichtung einer Hierarchie
>> explizit vorzuschreiben.
>

>dagegen, in eurer Nomenklatur: sollte

Nein: MUST (= soll)

Rolf Zweifel

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Boris 'pi' Piwinger wrote:
>
> k...@rrr.net (Kay Marquardt) wrote:
>
>> ich bin eigentlich fuer die KISS Idee, allerdings ist diese Version
>> viel zu vage, man kann den gesunden Netzverstand leider nicht durch so
>> weit gefasste Regeln zurueckbringen
>
> Da bin ich eben nicht so sicher. Das Scheitern des Konkreten mussten
> wir zu deutlich erleben.

Durch die (leider immer noch andauernde) Regelhaarspalterei, bin ich
auch langsam dazu geneigt, *weniger* für *mehr* zu halten.

Aber bin auch noch unentschlossen, denn ich gebe ungern so einfach
solchen momentanen Eindrücken (den Trolls) nach.

Klar, entzieh' den Regelspaltern die Regeldetails und Ruh' is'.

Aber es bleibt doch noch offen, ob die Regelhaarspalterei nicht
einfach in Auslegungshaarspalterei und Präzedenzfall-Streit
mündet; und man ohne sein Gigabyte Purpurdaten verloren dasteht.

Für eine tiefere Analyse wäre ich schon dankbar,
offen für die Sache ...

Rolf^2

Daniel Schneider

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Rolf Zweifel <rolf...@vossnet.de> wrote:

> Aber es bleibt doch noch offen, ob die Regelhaarspalterei nicht
> einfach in Auslegungshaarspalterei und Präzedenzfall-Streit
> mündet; und man ohne sein Gigabyte Purpurdaten verloren dasteht.

Ich befürchte ähnliches. Meines Erachtens könnte man auch bei
den derzeitigen Regeln bleiben, wenn man es endlich als
Konsens begreifen könnte, daß die Regeln nicht im Wort, sondern
im Sinn von der Moderations verstanden werden sollen. Das käme
KISS sehr nahe.

--
Daniel Schneider
PGP-Key: http://www.westfalen.de/terrania/daniel.asc or on key-servers

Mark Nowiasz

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Heiko Schlichting <he...@cis.fu-berlin.de> wrote:

>".misc" ist Usenetkultur und steht unter Denkmalschutz. Der ".misc"-Beauftrage
>des Usenets wuerde einer Verschandelung nicht zustimmen.

Oh, OK.

1.RfD: Neuwahl des Misc-Beauftragten des Usenets
================================================

Hiermit soll das Verfahren zur Wahl eines Beauftragten oder einer Gruppe
von Beauftragten für ".misc" des Usenets eingeleitet werden.

Der Veröffentlichung schließt sich eine mindestens zweiwöchige
Diskussionsphase an, während der jeder Usenet-Teilnehmer seine
Bereitschaft zur Kandidatur öffentlich erklären kann, und zwar durch
ein Posting in de.alt.arnooo oder (über den amtierenden
Misc-Beauftragten) in misc.beauftragter. Dies ist - auch für jedes
einzelne Mitglied einer gemeinsam kandidierenden Gruppe von
Moderatoren - notwendige Voraussetzung für eine Kandidatur.

Motivation:
-----------
Der Misc-Beauftragte ist ein Betonkopf,

Proponenten:
------------
Mark Nowiasz <buck...@blackbox.free.de>

Gruß,
Mark
--
|\ _,,,---,,_ Mark Nowiasz (buck...@blackbox.free.de)
/,.-'' -. ;-;;,_ PGP-Key available at keyservers/request.
|,4- ) )-,_..;\ ( '-' http://www.free.de/~buckaroo/
'---''(_/--' -'\_) IRC: Buckaroo | Voice: +49 177 2190385

Michael Ottenbruch

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Am Tue, 31 Mar 1998 16:20:29 -0500, schrieb Boris 'pi' Piwinger
<3....@Math.MIT.edu>:

> k...@rrr.net (Kay Marquardt) wrote:
>
> >> Es wurde vorgeschlagen, die Einrichtung einer misc-Gruppe bei
> >> Unterteilung einer Gruppe bzw. Neueinrichtung einer Hierarchie
> >> explizit vorzuschreiben.
> >

> >dagegen, in eurer Nomenklatur: sollte
>
> Nein: MUST (= soll)

Offensichtlich ist die Formulierung im RfD tatsächlich mehrdeutig.

Wir werden im 2. RfD folgende Ersetzung vornehmen:

Anstatt

> Bei Unterteilung einer
> Gruppe bedarf die Erweiterung des Namens der Ursprungsgruppe um das
> Suffix ».misc« im Erfolgsfalle des Vorschlags (das heißt bei
> Annahme mindestens einer der Gruppen) keiner eigenen Abstimmung.

werden wir folgende Formulierung zur Diskussion stellen:

> Bei Unterteilung einer Gruppe wird bei Annahme mindestens einer
> weiteren Gruppe grundsätzlich der Name der Ursprungsgruppe um
> das Suffix ».misc« erweitert, ohne daß hierüber separat abgestimmt
> wird. So wird sichergestellt, daß es in jeder Hierarchieebene eine
> *.misc-Gruppe gibt.

Wir denken, daß diese Formulierung keine Unklarheiten mehr offen läßt.

Rolf Zweifel

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Daniel Schneider wrote:
>
>> Aber es bleibt doch noch offen, ob die Regelhaarspalterei nicht
>> einfach in Auslegungshaarspalterei und Präzedenzfall-Streit
>> mündet; und man ohne sein Gigabyte Purpurdaten verloren dasteht.
>
> Ich befürchte ähnliches. Meines Erachtens könnte man auch bei
> den derzeitigen Regeln bleiben, wenn man es endlich als
> Konsens begreifen könnte, daß die Regeln nicht im Wort, sondern
> im Sinn von der Moderations verstanden werden sollen. Das käme
> KISS sehr nahe.

Vielleicht brauchen wir einfach *so* eine Präambel in den Regeln,
welchen auch immer.

<Vorschlag>

Präambel
========

§ 1 Der gesunde Menschenverstand ist unantastbar.

Diese Regeln ordnen sich diesem Grundsatz unter,
sofern den Nutzern des Usenet im Einzelfall besser
gedient werden kann.

Ungeregeltes ist nur dann verboten, wenn es den
Nutzern des Usenet nicht dient oder gar schadet.

§ 2 Was den Nutzern des Usenet am besten dient,
ergibt sich durch Anwendung von § 1 Abs. 1.

§ 3 Diese Regeln spiegeln einen Konsens wider und
sind nur *so* gänzlich zu begreifen.
(Geist der Regeln)
Sie gelten immer als Ganzes und sind nicht dafür
entworfen, in juristisch-diffiziele Auslegungen
atomisiert und interpretiert zu werden.
(Wortlaut der Regeln)

§ 4 Diese Regeln sollen Hilfestellung in der Anwendung
geben und nicht Munition für Auseinandersetzungen
entgegen dem Konsens, insbesondere § 1 Abs. 1.

§ 5 Wer eine schweigende Mehrheit hinter sich vermutet,
kann den tatsächlichen Konsens feststellen lassen.

§ 6 Diese Regeln sollen, dem Konsens entsprechend,
behutsam fortgeschrieben werden.

</Vorschlag>

--
Rolf^2

Wolfgang Behrens

unread,
Apr 1, 1998, 3:00:00 AM4/1/98
to

Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
> ".misc" ist Usenetkultur und steht unter Denkmalschutz. Der ".misc"-Beauftrage
> des Usenets wuerde einer Verschandelung nicht zustimmen.

Wo kann man sich für diesen Posten bewerben?


Wolf "Unterwanderung - Teil 1" gang


Boris 'pi' Piwinger

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Rolf Zweifel <rolf...@vossnet.de> wrote:

>> Da bin ich eben nicht so sicher. Das Scheitern des Konkreten mussten
>> wir zu deutlich erleben.
>
>Durch die (leider immer noch andauernde) Regelhaarspalterei, bin ich
>auch langsam dazu geneigt, *weniger* für *mehr* zu halten.

Sic.

>Aber es bleibt doch noch offen, ob die Regelhaarspalterei nicht
>einfach in Auslegungshaarspalterei und Präzedenzfall-Streit
>mündet; und man ohne sein Gigabyte Purpurdaten verloren dasteht.

Die Gefahr duerfte keinesfalls groesser als momentan sein. Ich denke
eher, sie ist deutlich kleiner, weil genau die, die hier die Probleme
erzeugen, eben nicht mehr Einzelregelungen herauspicken und
missbrauchen koennen. Es liegt schlicht an der Moderation, die
Zulaessigkeit von Verfahren zu entscheiden.

pi
--
Usenet is like Tetris for those who still can read.

Boris 'pi' Piwinger

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Wolfgang Behrens <wolf...@snoopy.flensburg.de> wrote:

>> ".misc" ist Usenetkultur und steht unter Denkmalschutz. Der ".misc"-Beauftrage
>> des Usenets wuerde einer Verschandelung nicht zustimmen.
>
>Wo kann man sich für diesen Posten bewerben?

ment...@dana.de

Adrian Suter

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Boris 'pi' Piwinger <3....@Math.MIT.edu> wrote:

>Rolf Zweifel <rolf...@vossnet.de> wrote:
>>Aber es bleibt doch noch offen, ob die Regelhaarspalterei nicht
>>einfach in Auslegungshaarspalterei und Präzedenzfall-Streit
>>mündet; und man ohne sein Gigabyte Purpurdaten verloren dasteht.
>
>Die Gefahr duerfte keinesfalls groesser als momentan sein.

ACK. Aber zum Thema "Präzedenzfall" mal so eine Idee. In Deinem
KISS-Entwurf ist aus irgendeinem Grund der Satz ausgefallen, dass die
Moderation über die Zulässigkeit von Verfahren entscheidet - weil es
selbstverständlich ist?

Ich hielte es nicht für falsch, eine einfache (!) Aussage darüber zu
machen, welche Aufgaben de Moderation gemäss diesen Regeln zukommen.

<Vorschlag>

Die Moderation von de.admin.news.announce hat die Aufgabe, ein faires
Verfahren zu ermöglichen. Dazu gehört, dass sie die Einhaltung dieser
Regeln überwacht und sie im Einzelfall interpretiert.

</Vorschlag>

Zwei Bmerkungen:

1. "Im einzelfall" will sagen, dass die Entscheidung im einen
Einzelfall nicht zwingend eine gleiche Entscheidung in einem anderen
Einzelfall impliziert. Grund: die Einzelfälle sind prinzipiell immer
verschieden.

2. Das "Recht" der Moderation, das Verfahren zu regeln und die Regeln
zu interpetieren, ist sekundär gegenüber der "Pflicht", ein faires
Verfahren zu ermöglichen.

Adrian
--
adrian...@schweiz.org funktioniert und wird gelesen.
Fuer schnelleren Kontakt ersetze schweiz.org durch christkath.ch.

http://www.christkath.ch/leute/adrian.htm

Wolfgang Kopp

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

adrian...@schweiz.org (Adrian Suter) schrieb:

> 1. "Im einzelfall" will sagen, dass die Entscheidung im einen
> Einzelfall nicht zwingend eine gleiche Entscheidung in einem anderen
> Einzelfall impliziert. Grund: die Einzelfälle sind prinzipiell immer
> verschieden.

Nicht nur das: Man kann sich auch mal irren und sollte nicht gehindert
sein, sich zu korrigieren.

--
Wolfgang Kopp · <ko...@naranek.camelot.de> · http://home.pages.de/~kopp/
»Das Buch ist gut. Ich habe einiges daraus gelernt.«
Lutz Donnerhacke macht einem Buch über Usenet das größtmögliche
Kompliment, de.soc.netzkultur, 1998

Adrian Suter

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

ko...@naranek.camelot.de (Wolfgang Kopp) wrote:

>Nicht nur das: Man kann sich auch mal irren und sollte nicht gehindert
>sein, sich zu korrigieren.

...ohne deswegen jenes zwei Jahre zurückliegende Verfahren, bei dem
man sich geirrt hat, wiederholen oder eine seither gut etablierte
Gruppe löschen zu müssen.

Adrian

Florian Kuehnert

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Rolf Zweifel schrieb/wrote/écrivait:
><Vorschlag>
>Präambel
></Vorschlag>

Gute Idee.

Florian
--
»t-shirts.de.hauteng.und.nass.mit.reichlich.dicken.augen.drin.lechz«
-- Thomas G. Liesner möchte eine Gruppe haben

Boris 'pi' Piwinger

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

adrian...@schweiz.org (Adrian Suter) wrote:

>ACK. Aber zum Thema "Präzedenzfall" mal so eine Idee. In Deinem
>KISS-Entwurf

Ich moechte hervorheben, dass der Vorschlag von tlr erarbeitet wurde,
alle Ehre gebuehrt ihm.

>ist aus irgendeinem Grund der Satz ausgefallen, dass die
>Moderation über die Zulässigkeit von Verfahren entscheidet - weil es
>selbstverständlich ist?

Sic.

>Ich hielte es nicht für falsch, eine einfache (!) Aussage darüber zu
>machen, welche Aufgaben de Moderation gemäss diesen Regeln zukommen.

Ist durchaus denkbar.

><Vorschlag>
>
>Die Moderation von de.admin.news.announce hat die Aufgabe, ein faires
>Verfahren zu ermöglichen. Dazu gehört, dass sie die Einhaltung dieser
>Regeln überwacht und sie im Einzelfall interpretiert.
>
></Vorschlag>

Klingt durchaus gut. Wird hier zu diskutieren sein.

Rolf Krahl

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

In Artikel <6fth4i$gr$1...@snoopy.flensburg.de>
schrieb Wolfgang Behrens <wolf...@snoopy.flensburg.de>:

> Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
>> ".misc" ist Usenetkultur und steht unter Denkmalschutz. Der
>> ".misc"-Beauftrage des Usenets wuerde einer Verschandelung nicht
>> zustimmen.
>
> Wo kann man sich für diesen Posten bewerben?

Wie Mark ja bereits dankenswerterweise klargestellt hat durch ein
Posting in de.alt.arnooo.

[ F'up ]

--
Rolf Krahl <ro...@informatik.uni-bremen.de>
PGP public key available:
pgp-pub...@pgp.ai.mit.edu, Subject: GET 0x41F08261, empty body

Juergen Dollinger

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Olaf Schneider <Olaf.Sc...@blaubeere.rhein-neckar.de> wrote:
> muß/müssen unbedingt, immer; Ausnahme nur bei Regelungslücken

Wer genehmigt Ausnahmen?

> soll/sollen grundsaetzlich, begründete Ausnahmen möglich

Wer genehmigt Ausnahmen?

> sollte/sollten Empfehlung, nicht verbindlich

Nicht Verbindliche Empfehlungen gehoeren in irgendwelche FAQ's die
dann in dni gepostet werden, und nicht in die Wahlregeln die dann
nicht mehr nach dni gehoeren.

> Sollte dies in irgeneiner Form in den Texten erläutert werden?

Unbedingt.

> de.alt.all:

Da laeuft gerade ein anderes Verfahren. Wenn dort die bisherige Regelung
bestaetigt wird warum sollte man die dann rausnehmen oder aendern?
Sind die FAQ's per CfV beschlossen? Wenn nein: Raus aus den Regeln.

<droh> Soll ich auch mal ne FAQ schreiben? </droh>

> Ist Reply-Fähigkeit ein notwendiges Kriterium fuer eine gültige
> Stimme - auch bei Abstimmungen ohne persönliche Wahlscheine.

IHMO: Prinzipielle Reply-Faehigkeit. Das heisst Reply-Faehigkeit bis auf
technische Pannen. Es kann passieren, dass ausgerechnet Mails vom Wahlhost
abgeleht werden oder temporaere Reply-Un-Faehigkeit vorliegt. Das sollte
nicht zur Ungueltigkeit einer Stimme fuehren.

Andererseits sollte auch aehnliche Anforderungen an den Wahlhost stellen.

> Entscheidungsmöglichkeiten bei Einsprüchen:

Sollten der Moderation ueberlassen bleiben. --> Flexibilitaet+KISS

> Sperrfristen und inhaltlich kollidierende Vorschläge:
>
> Die Sperrfristen hören auf. [*]

Das ist unrealistisch. Die Moderation kann immer verschleppen und
das ist gut so. Vorschlag:

Gehen innerhalb von <x> Monaten mehr als ein RfD zum selben Thema
oder mehr als <y> RfD's von der selben Person ein oder ist ein
RfD/CfV geeignet das Ergebnis eines bereits laufenden Verfahrens zu
beeinflussen so kann die Moderation den RfD ablehnen oder den RfD/CfV
zurueckstellen und spaeter behandeln.

Was das selbe Thema ist entscheidet die Moderation. Ja diese Idee an
KISS mag ich: Die Moderation entscheidet.

> Offensichtlichen Mißbrauch von dana (z.B. vielfach wiederhohlter
> RfD zur gleichen Gruppe) soll der dana-Moderator unter Berufung
> auf Abschnitt 1 der Moderationsrichtlinien dennoch verhindern

Das ist ziemlich wage.

--
| J"urgen Dollinger | mailto:jue...@magrathea.stud-verwaltung.uni-ulm.de |
| Universit"at Ulm | http://www.stud-verwaltung.uni-ulm.de/people/juergen/ |
| If a system ain't broke, it doesn't have enough features yet! |

Juergen Dollinger

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Olaf Schneider <Olaf.Sc...@blaubeere.rhein-neckar.de> wrote:
> Ebenso enthält sich der Moderator
> eigenmächtiger Interventionen in laufende Verfahren, er soll
> beispielsweise nicht aus eigenem Antrieb eine Abstimmung abbrechen.

Streichen. Wenn es noetig ist soll er das tun, wenn nicht tut er es
sowieso nicht.

Rolf Krahl

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

In Artikel <3524be4b...@news.bluewin.ch>
schrieb adrian...@schweiz.org (Adrian Suter):

> ko...@naranek.camelot.de (Wolfgang Kopp) wrote:
>
>>Nicht nur das: Man kann sich auch mal irren und sollte nicht gehindert
>>sein, sich zu korrigieren.
>
> ....ohne deswegen jenes zwei Jahre zurückliegende Verfahren, bei dem

> man sich geirrt hat, wiederholen oder eine seither gut etablierte
> Gruppe löschen zu müssen.

... und ohne den Netizens zumuten zu wollen, sich Gigabytes an
Purpurdaten in den Keller legen zu müssen, nur um blödsinnige Verweise
auf zwei Jahre zurückliegende "Präzedenzfälle" kontern zu können.

Rolf Krahl

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

In Artikel <35223e4...@zebra.fh-weingarten.de>
schrieb k...@rrr.net (Kay Marquardt):

> Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) wrote:
>
>>de.alt.all:
>> Alternativ wäre es auch denkbar, die Erläuterungen zu
>> de.alt ganz aus den Regeln für de.!alt.all zu streichen. Neben
>> der Erklärung, daß diese Regeln nicht zuständig sind, könnte
>> noch ein Verweis auf de.alt.admin und eventuell auf vorhandene
>> FAQs erfolgen.
>
> genau das, de.alt ist ein eigener Bereich

Dem möchte ich aus zwei Gründen widersprechen.


Erstens (formal):

de.alt ist zunächst einmal kein eigener Bereich. Erst durch den
Abschnitt zu de.alt.all in den Einrichtungsregeln _wird_ de.alt.all zu
einem eigenen Bereich mit eigenen Regeln. Wenn Du diesen Absatz
streichst, gelten (zumindest formal) die Einrichtungsregeln incl. RfD
und CfV ohne Einschränkungen auch für de.alt.


Zweitens (inhaltlich):

Die Regeln[1] zur Einrichtung von Gruppen in de.alt sind nicht
gottgegeben. Sie sind von Menschen gemacht und zumindest ich möchte,
daß sie auch irgendwo dokumentiert sind (selbst, wenn sie sich in dem
einen Satz wie "Es gilt Fairness" erschöpfen). Eine Anarchie[2] wie
in alt.all mit newgroup/rmgroup-wars möchte ich für de.alt nicht.

Ich kann das Argument, für de.alt sei de.alt.admin zuständig, deshalb
sollen die Regeln für de.alt in de.alt.admin diskutiert und
entschieden werden und nicht in de.admin.news.* zwar nachvollziehen,
allerdings halte ich recht wenig davon, nun zwei Einrichtungsregeln,
eine für de.!alt und eine eigene für de.alt (vgl. die aktuelle
Griesbecksche Debatte) zu diskutieren. Gerade, wenn die Regeln für
de.alt nur aus einem Satz bestehen sollen, halte ich es für
unverhältnismäßig, diesen einen Satz in einem eigenen Regeltext zu
verewigen. Da halte ich es doch für wesentlich pragmatischer, diesen
Satz in die Regeln für de.!alt mit aufzuführen (und so ein in sich
geschlossenes und vollständiges Regelwerk für de.all zu bekommen).


Anm. 1: Ja, es gibt Regeln und wird immer welche geben. Auch wenn man
sagt, es gebe keine Regel und jeder verschickt seine newgroups nach
Gusto, so ist dies eine Regel.

Anm. 2: Stimmt natürlich so nicht. Selbst in alt.all herrscht keine
Anarchie. Wie man zumindest der Lektüre von control.rmgroup entnehmen
kann, gibt es durchaus klare Regeln für Gruppenvorschläge in alt.all
auf die sich die Begründungen für die rmgroups berufen.

Michael Ottenbruch

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Am 2 Apr 98 21:32:08 GMT, schrieb Juergen Dollinger
<jue...@magrathea.stud-verwaltung.uni-ulm.de>:

> Olaf Schneider <Olaf.Sc...@blaubeere.rhein-neckar.de> wrote:
> > Ebenso enthält sich der Moderator
> > eigenmächtiger Interventionen in laufende Verfahren, er soll
> > beispielsweise nicht aus eigenem Antrieb eine Abstimmung abbrechen.
>
> Streichen. Wenn es noetig ist soll er das tun, wenn nicht tut er es
> sowieso nicht.

So wie ich den Satz verstehe, sind die Schlüsselwörter dieses Satzes
"eigenmächtig" bzw. "aus eigenem Antrieb". Es scheint hier gemeint zu
sein, daß der Moderator derartiges unterlassen soll, wenn er der
*einzige* ist, der es für nötig hält.

Michael Ottenbruch

unread,
Apr 2, 1998, 3:00:00 AM4/2/98
to

Am 2 Apr 98 21:20:28 GMT, schrieb Juergen Dollinger
<jue...@magrathea.stud-verwaltung.uni-ulm.de>:

> Olaf Schneider <Olaf.Sc...@blaubeere.rhein-neckar.de> wrote:
> > muß/müssen unbedingt, immer; Ausnahme nur bei Regelungslücken
>
> Wer genehmigt Ausnahmen?

Die Moderation.



> > soll/sollen grundsaetzlich, begründete Ausnahmen möglich
>
> Wer genehmigt Ausnahmen?

Die Moderation.



> > sollte/sollten Empfehlung, nicht verbindlich
>
> Nicht Verbindliche Empfehlungen gehoeren in irgendwelche FAQ's die
> dann in dni gepostet werden, und nicht in die Wahlregeln die dann
> nicht mehr nach dni gehoeren.

Das würde bedeuten, daß Regeln nur Dinge enthalten dürfen, die
verbindlich vorgeschrieben sind. Das würde aber auch verbieten, Dinge zu
erwähnen, die lediglich gestattet sind, und im Ergebnis dazu führen, daß
alles, was nicht obligatorisch ist, verboten ist. Dies ist nicht unsere
Auffassung davon, wie Richtlinien für dana aussehen sollten.

>
> [...]


>
> > Entscheidungsmöglichkeiten bei Einsprüchen:
>
> Sollten der Moderation ueberlassen bleiben. --> Flexibilitaet+KISS

Hier scheint ein Mißverständnis vorzuliegen. Dies ist kein zweiter
Versuch, KISS-Regeln einzuführen, sondern ein konkurrierendes Projekt,
das im wesentlichen den Ansatz der jetzigen Wahlregeln gut heißt.


> > Sperrfristen und inhaltlich kollidierende Vorschläge:
> >
> > Die Sperrfristen hören auf. [*]
>
> Das ist unrealistisch. Die Moderation kann immer verschleppen und
> das ist gut so. Vorschlag:
>
> Gehen innerhalb von <x> Monaten mehr als ein RfD zum selben Thema
> oder mehr als <y> RfD's von der selben Person ein oder ist ein
> RfD/CfV geeignet das Ergebnis eines bereits laufenden Verfahrens zu
> beeinflussen so kann die Moderation den RfD ablehnen oder den RfD/CfV
> zurueckstellen und spaeter behandeln.
>
> Was das selbe Thema ist entscheidet die Moderation. Ja diese Idee an
> KISS mag ich: Die Moderation entscheidet.

Falsche Baustelle. Siehe oben.

> > Offensichtlichen Mißbrauch von dana (z.B. vielfach wiederhohlter
> > RfD zur gleichen Gruppe) soll der dana-Moderator unter Berufung
> > auf Abschnitt 1 der Moderationsrichtlinien dennoch verhindern
>
> Das ist ziemlich wage.

Natürlich ist das ziemlich vage. Es ist ja auch nicht das Anliegen
dieses Entwurfes, dana robomod-fähig zu machen. Die Moderation muß einen
gewissen Ermessensspielraum haben, der unseres Erachtens allerdings
nicht so weit gehen sollte, daß sie alles kann und darf...

Juergen Dollinger

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

Michael Ottenbruch <M.Otte...@sailor.ping.de> wrote:
> So wie ich den Satz verstehe, sind die Schlüsselwörter dieses Satzes
> "eigenmächtig" bzw. "aus eigenem Antrieb". Es scheint hier gemeint zu
> sein, daß der Moderator derartiges unterlassen soll, wenn er der
> *einzige* ist, der es für nötig hält.

Und wenn es einen Riesenaufstand in dang gibt wird die Moderation
sagen wir duerfen nicht abbrechen es steht so in den Regeln. Wenn die
Betonung auf "eigenmächtig" liegt dann muss auch gesagt werden wer dann
den Abbruch fordern darf. Die Stimmung in dang? Der Proponent? Ralph
Babel? Jeder Nicht-Moderator?

Juergen Dollinger

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

Michael Ottenbruch <M.Otte...@sailor.ping.de> wrote:
> Das würde bedeuten, daß Regeln nur Dinge enthalten dürfen, die
> verbindlich vorgeschrieben sind. Das würde aber auch verbieten, Dinge zu
> erwähnen, die lediglich gestattet sind, und im Ergebnis dazu führen, daß
> alles, was nicht obligatorisch ist, verboten ist.

Kann kann bleiben ;)
Nur das "Sollte/Soll" stoert mich. Natuerlich sollen Dinge gestattet
sein die nicht vorgeschrieben sind. Aber wenn man etwas nur "soll"
dann kommt sofort einer der das fuer irrelevant haelt. Zumindest muss
bei Soll-Bestimmungen klar geregelt sein in welchem Fall Ausnahmen
zulaessig sind. (ZB Wenn die Moderation es genehmigt).

> Hier scheint ein Mißverständnis vorzuliegen. Dies ist kein zweiter
> Versuch, KISS-Regeln einzuführen, sondern ein konkurrierendes Projekt,
> das im wesentlichen den Ansatz der jetzigen Wahlregeln gut heißt.

Das mag sein, aber ein bisschen KISS schadet diesen Regeln nicht. Das
aktuell vorgeschlagene echte KISS ist nicht so mein Ding.

Oliver Gassner

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

sa...@berlin.snafu.de (Erhard Sanio) wrote/schrieb in
de.admin.news.misc :

>In article <1d6rbca.1n1...@acc1-147.telip.uni-sb.de>,
>Zippo Zimmermann <zi...@phil.uni-sb.de> wrote:
>>Heiko Schlichting <he...@cis.fu-berlin.de> wrote:
>
>>> Nein.
>
>>Doch.
>
>Nein.
>
>Es geht um *.misc statt *.gut_durchgequirltes_oder_wie_immer .


>
>Miscellanea war eine staendige Rubrik in _deutschen_ Journalen und
>Essays seit Goethe. Bildet Euch erstmal in Deutsch ehe ihr tuemelt
>bzw sprachpuristet.

"Vermischtes" wuerde aber bedeuten, dass alles, was in den *.non-misc
Untergruppen on topic ist auch in *.misc jeweils on-topic ist. Das ist
aber _nicht_ so (oder ich habe was missverstanden).

Konkret:

In de.admin.net-abuse.misc sind die dinge on-topic, die nicht sinnvoll
(ausschliesslich) nach *.mail oder *.news einsortierbar sind.

Oder: in de.rec.sf.startrek.misc sind dei dinge on topic, die __weder__
*.aktuell(e Folgen oder Filme), *.fan(s), *.technologie noch *.kulturen
beteffen.

Also eben: Sonstiges. In de.etc.misc gilt aehnliches ;)

Da es immer mehr Newusers geben wird, bin ich (wo nicht Technik Namen
wie *.answers diktiert) fuer moeglichst eindeutige deutschsprachige
Benennungen.

Es waere schoen, wenn sich hier mal ein Konsens erzielen liesse, damit
man das nicht jedes Mal wieder diksutieren muss...

OG
--
Literatur am Draht:
http://www.carpe.com/lit/
Meine "private" Homepage:
http://lit-inf.home.pages.de/


Wolfgang Kopp

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) schrieb:

> Empfehlungen zur Einrichtung von de-Newsgroups

IMHO sollte der Titel »Regeln für die Einrichtung von Newsgruppen in
de.*« lauten. »Empfehlungen« ist deutlich zu schwach und läßt den
normativen Charakter nicht erkennen. Das entspricht zwar dem aktuellen
Trend zur Deregulierung, aber wenn man schon Regeln macht, dann sollte
man das auch sagen.

»Der Wortlaut der Regeln gestattet es Wahlen ohne Sinn und Verstand
-ähm Akzeptanz- durchzuziehen. Das ist nicht im Sinne des Netzes, der
Moderation und insbesondere der Regeln.« Lutz Donnerhacke, d.a.n.m

Heiko Schlichting

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

ko...@naranek.camelot.de (Wolfgang Kopp) writes:
>Olaf.Sc...@blaubeere.rhein-neckar.de (Olaf Schneider) schrieb:
>
>> Empfehlungen zur Einrichtung von de-Newsgroups
>
>IMHO sollte der Titel »Regeln für die Einrichtung von Newsgruppen in
>de.*« lauten.

Insbesondere sollte man nicht wieder den alten Fehler machen und nur
"Einrichtungen" behandeln und im Titel auffuehren. Die Regeln werden
fuer Einrichtungen, Loeschungen und Umbenennungen gleichermassen benoetigt.

Heiko

Adrian Suter

unread,
Apr 3, 1998, 3:00:00 AM4/3/98
to

Juergen Dollinger <jue...@magrathea.stud-verwaltung.uni-ulm.de>
wrote:

>Nur das "Sollte/Soll" stoert mich. Natuerlich sollen Dinge gestattet
>sein die nicht vorgeschrieben sind. Aber wenn man etwas nur "soll"
>dann kommt sofort einer der das fuer irrelevant haelt. Zumindest muss
>bei Soll-Bestimmungen klar geregelt sein in welchem Fall Ausnahmen
>zulaessig sind. (ZB Wenn die Moderation es genehmigt).

Eine Soll-Bestimmung, bei der die Ausnahmefälle abschliessend geregelt
sind, ist eine Muss-Bestimmung ("es muss... ausser wenn..."). Der Sinn
von Soll-Bestimmungen ist IMHO gerade, dass wir uns nicht im voraus
festlegen, in welchem hypothetischen Fall die Bestimmung nicht gelten
soll.

Michael Ottenbruch

unread,
Apr 3, 1998, 3:00:00 AM4/3/98