🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: dnet.general
Article #646

Spielregeln im DNET -- (Un-)Sinn ?

#646
From: Marc Binderberger
Date: Thu, 25 Jul 1991 14:01
265 lines
15299 bytes
Zuerst einmal `Hallo' allerseits.
Wie schon das Subject preisgibt, moechte ich hiermit eine kleine Diskussion
`anheizen' ueber Verhaltensregeln im DNET, speziell ueber

	- Call for Discussion
	- Call for Vote


Als Beispiel dafuer, dass dabei nicht immer alles glatt laeuft, faellt mir z.B.
dnet.chat oder der `CfV' ueber dnet.next ein (die `' stehen da ganz bewusst !).

So stellt sich erst mal die Frage: Wollen wir ueberhaupt solche Regeln ?
(also ich schon  :-} )
Und wenn ja, wie sollen die Aussehen ?

Deshalb moechte ich als Diskussionsvorschlag die Regeln aus dem SubNet als
Plattform vorschlagen. Diese Regeln koennen wir ja dann noch abaendern.
(Ob ich damit die Diskussion ueber ein "fuer/gegen Regeln" uebergehe ?
 NEIN !  Ich denke mir, ohne konkrete Beispiele bleibt so eine Diskussion
 doch nur heisse Luft.)


Nun, eine Diskussion beginnt man am besten mit ein paar Behauptungen
(Profis nennen sowas dann `Thesen' ... :-} ):

- zuviele Groups machen das Arbeiten im Netz eher schwieriger als leichter.
  Denn wenn die Unterteilung zu fein wird, wohin poste ich dann ein Thema ?
  So recht passt es vielleicht weder in die eine, noch in die andere Gruppe.
  Da es aber andererseits mit einigen Groups etwas zu tun hat, poste ich meinen
  Artikel notgedrungen in alle diese Groups. Ergebniss: Die anderen Anwender
  lesen meinen Artikel mehrfach, die Groups `laufen ueber' .

- Bei speziellen Groups fehlen auswertige Impulse. Eine Gruppe ueber z.B.
  NeXT-Rechner lesen wahrscheinlich nur die Benutzer dieses Rechners
  (naja, im wesentlichen zumindest). Aber gerade die Meinung/Erfahrung
  anderer Anwender/Systemverwalter koennte hier doch ganz nuetzlich sein.

- Die Lebensdauer einiger Gruppen ist recht kurz. Manchmal kommt spontan der
  Gedanke auf, fuer dieses oder jede Thema eine Newsgroup einzurichten
  ("brandheisses Thema, und soviele machen mit ..."). Mir faellt da z.B.
  das SubNet ein: Weil das Thema `Sciene Fiction' ploetzlich so viele zu
  interessieren schien, wollte man eine neue Gruppe. Also im Moment scheint
  das Thema aber stark an Interesse verloren zu haben, das Ganze war nur
  eine kurzfristige Angelegenheit. Oder nehmen wir sub.boerse :
  Geboren - Eingeschlafen - Wiedererweckt -- nur wie lange ?
  Also eher zoegern mit der Einrichtung, den CfD/CfV vielleicht erst nach
  1-2 Monaten starten, wenn es sich dann noch lohnt.
  
- "CfD enden nie, das gibt doch endlose Laberei/Schlammschlachten!"
  Jein !  Natuerlich kann das passieren (ich verweise wieder auf's SubNet,
   z.B. sub.config). Aber wer hindert uns daran, einen CfD auf 3-5 Wochen zu
  begrenzen ?!  Man kann zwar die Netzler nicht daran hindern, auch noch
  danach ihre Meinung zu aeussern, aber das wird wahrscheinlich stark
  nachlassen, wenn die erst mal merken, dass eh' keiner mehr zuhoert und
  deshalb auch kein Aufwaermen mehr moeglich ist. Und nach der oben genannten
  Zeitspanne kommen auch keine neuen und entscheidenden Argumente mehr.


So weit, so gut (oder nicht ? ...). Vielleicht liege ich ja auch voellig
daneben, denn im wesentlichen kenne ich nur DNET/SubNET intensiver.
So gesehen bin ich vielleicht einfach zu provinziell
(d.h. typisch deutsch: ordnungsliebend ... :-} )
und lasse mich deshalb gerne von `weltgewandten' Netzlern korrigieren.
(zum Teufel: WO IST MEIN DUDEN ...)

So, ich glaube, ich bremse mich hier erst mal und haenge nur noch die
SubNet-Regeln hinten an:

-------------schnipp-------------schnapp-------------schnipp-------------------

   From: bad@flatlin.ka.sub.org (Christoph Badura)
   Newsgroups: sub.newusers
   Subject: Einrichtung von Newsgroups <25-Feb-91>
   Date: 11 Jul 91 06:44:41 GMT
   Reply-To: sub-newusers@jattmp.imp.com
   Distribution: sub
   Organization: Guru Systems/Funware Department
   Supersedes: <new.sub.new.4@jattmp.imp.com>


   lumpi@dobag.in-berlin.de (Joern Lubkoll) writes:
   >Was ist denn ein 'richtiges' Voting ????

   Eins, das die Regeln einhaelt. Danach fehlen mindestens:
   Abstimmungszeitraum, Details der Stimmabgabe (wie sieht eine
   Ja/Nein-Stimme aus), benoetigte Stimmen und Stimmenverhaeltnis.

   Original-from: woods@ncar.ucar.edu (Greg Woods)
   [Most recent change: 06 Sep 1990 by lear@turbo.bio.net (Eliot Lear)]
   [Deutsche Uebersetzung: bad@flatlin.ka.sub.org (Christoph Badura)]

	    RICHTLINIEN FUeR DIE EINRICHTUNG VON USENET GRUPPEN


   Vorbedingungen fuer die Einrichtung von Gruppen:

      Diese Richtlinien sind im USENET allgemein akzeptiert worden, um neue
   Newsgruppen in der "standard" USENET-Hierarchien einzurichten.  Sie sind
   WEDER dazu gedacht, das Vorgehen bei anderen Prozeduren als der
   Einrichtung von neuen Gruppen festzulegen, NOCH dazu gedacht, die
   Vorgehensweise in "alternativen" oder lokalen Newshierachien zu
   bestimmen.  Diese Richtlinien betreffen folgende Hierachien: comp, news,
   sci, misc, soc, talk und rec, die am weitesten verbreiteten Teile der
   USENET Hierarchien.
      Jedem Antrag auf Einrichtung von Newsgruppen, der diesen Richtlinien
   folgt und erfolgreich ist, sollte stattgegeben werden.  Jeder Antrag, der
   diese Richtlinien nicht befolgt oder der erfolgreich ist, weil diese
   Richtlinien missachtet wurden, sollte nicht beachtet werden, ausser unter
   besonderen Umstaenden. Diese Vorgehensweisen sind Richtlinien und keine
   festen Regeln, weil diese "besonderen Umstaende" oder die Art, wie sie
   entstehen koennen, nicht vorhersagbar sind.
      An dieser Stelle muss nocheinmal darauf hingewiesen werden, dass die
   Entscheidung, ob eine Gruppe auf einer bestimmten Maschine eingerichtet
   wird oder nicht, selbstverstaendlich dem jeweiligen Administrator dieser
   Maschine obliegt. Diese Richtlinien sollen dem jeweiligen Administrator
   lediglich bei seiner Entscheidung helfen.


   Die Diskussion

   1. Ein "Call for Discussion" ueber die Einrichtung einer neuen Newsgruppe
      sollte nach news.announce.newgroups (sub-Netz: sub.config) und, falls
      gewuenscht, in jede andere Gruppe oder Mailing-Liste, die von dem
      vorgeschlagenen Thema beruehrt werden, gepostet werden. Diese Gruppe
      ist moderiert und die Followup-To:- Zeile wird so gesetzt, dass die
      tatsaechliche Diskussion nur in news.groups (sub-Netz: sub.config)
      stattfindet.  Benutzer an Sites, die Probleme haben in moderierte
      Gruppen zu posten, koennen ihre Beitraege fuer news.announce.newgroups
      an "announce-newgroups@turbo.bio.net" per E-Mail schicken.

   2. In der Diskussionsperiode sollten der Name und die Charta der
      vorgeschlagenen Gruppe und ob die Gruppe moderiert sein wird oder
      nicht festgelegt werden. Falls die Gruppe moderiert werden soll, sind
      der/die Moderator/en ebenfalls zubestimmen. Wenn die Befuerworter
      einer neuen Gruppe sich innerhalb von 30 Tagen nicht ueber diese
      Punkte einig werden koennen, dann sollte die Diskussion Offline (z.B.
      per Mail statt in news.groups (sub-Netz: sub.config)) weitergefuehrt
      werden, bis ein Konsens erreicht ist. Wenn ein Konsens zustandekommt,
      kann ein neuer, praezisierter Vorschlag eingebracht werden. In diesem
      Fall wird bei Schritt 1) neu angefangen.


   Die Abstimmung

   1. NACH der Diskussionsperiode, nachdem festgestellt wurde, dass eine
      neue Gruppe wirklich gewuenscht wird, eine Einigung ueber Name und
      Charta der Gruppe erreicht wurde, und bestimmt wurde, ob und von wem
      die Gruppe moderiert werden soll, kann ein "Call for Votes" nach
      news.announce.newgroups und jede Gruppe oder Mailing-Liste, in die der
      urspruengliche "Call for Discussion" gepostet wurde, gepostet werden.
      Der "Call for Votes" sollte sobald als moeglich nach dem Ende der
      Diskussionsperiode gepostet werden. In dem "Call for Votes" sollten
      genaue und klare Anweisungen enthalten sein, wie die Stimmen abgegeben
      werden koennen. Die Abgabe einer Stimme fuer die Einrichtung der
      Gruppe muss genauso klar erklaert und genauso einfach sein, wie eine
      Stimme gegen die Einrichtung, und umgekehrt.  Es ist explizit erlaubt,
      zwei verschiedene E-Mail-Adressen fuer die Ja- und Nein-Stimmen
      einzurichten, vorrausgesetzt sie sind auf der gleichen Maschine, oder
      eine andere Adresse als die, von der aus der Artikel gepostet wurde,
      anzugeben, oder nur "Replies" auf den "Call for Votes"-Artikel
      anzunehmen, solange in dem "Call for Votes"-Artikel klar und explizit
      erklaert wird, wie die Stimmen abgegeben werden koennen. Wenn zwei
      Adressen fuer die Stimmeabgabe benutzt werden, muss die Adresse im
      Reply-To:-Feld ENTWEDER sowohl Ja- als auch Nein-Stimmen annehmen und
      bearbeiten, ODER sie darf keine Stimme auf dieser Adresse akzeptieren.

   2. Die Abstimmungsperiode sollte mindestens 21 Tage aber nicht laenger
      als 31 TAge betragen, unabhaengig von Zwischenergebnissen der
      Abstimmung. In dem "Call for Votes" sollte das genaue Datum, an dem
      die Abstimmungsperiode endet, angegeben werden. Stimmen, die nach
      diesem Tag auf der Maschine desjenigen, der die Abstimmung
      durchfuehrt, eingehen, duerfen nicht mehr beruecksichtigt werden.

   3. Es koennen Erinnerungen an einen laufenden "Call for Votes" waehrend
      der Abstimmungsperiode gepostet werden, vorrausgesetzt, sie enthalten
      aehnlich klare und untendenzioese Anweisungen zur Stimmabgabe wie der
      urspruengliche Aufruf, und vorrausgesetzt sie sind unveraenderte
      Wiederholungen des urspruenglichen Vorschlags (siehe auch Punkt 5
      weiter unten).  Zwischenergebnisse der Abstimmung sollten in einer
      Wiederholung des "Call for Votes" NICHT veroeffentlicht werden; es
      genuegt, wenn darauf hingewiesen wird, das ueber einen bestimmten
      Vorschlag fuer eine Gruppe eine Abstimmung im Gange ist und wie die
      Stimmen abgegeben werden. Es ist erlaubt eine "Massenbestaetigung" zu
      posten, in der die Namen aller, von denen eine Stimme eingetroffen
      ist, veroeffentlicht werden, vorrausgesetzt, es wird keine Andeutung
      gemacht, wie die einzelnen abgestimmt haben, bis die
      Abstimmungsperiode offiziell beendet ist.

   4. Es werden AUSSCHLIESSLICH Stimmen die den Stimmenauszaehler PER MAIL
      erreichen beruecksichtigt. Stimmen, die ins Netz gepostet wurden
      (insbesondere weil der Stimmenzaehler nicht per Mail erreicht werden
      kann) und Proxy-Stimmen (z.B. ein Verwalter einer Mailing-Liste, der
      fuer jeden Teilnehmer der Liste eine Stimme "an seiner Statt" abgibt)
      duerfen nicht gezaehlt werden.

   5. Stimmen koeennen nicht auf einen anderen Abstimmungsvorschlag
      uebertragen werden. Eine Stimme zaehlt nur fuer GENAU DEN Vorschlag,
      fuer den sie abgegeben wurde. Insbesondere darf eine Stimme fuer oder
      gegen ein Newsgruppe mit einem bestimmten Namen NICHT als Stimme fuer
      oder gegen eine Newsgruppe mit einem anderen Namen oder einer anderen
      Charta, einem anderen unmoderiert/ moderiert Status oder, falls
      moderiert, einem anderen Moderator oder Gruppe von Moderatoren
      gezaehlt werden.

   6. Abgegebene Stimmen MUeSSEN explizit sein. So sollten etwa wie "I vote
      for the group foo.bar as proposed" ("Ich stimme fuer den Vorschlag
      fuer die Gruppe foo.bar") oder "I vote against the group foo.bar as
      proposed" ("Ich stimme gegen den Vorschlag fuer die Gruppe foo.bar")
      abgefasst werden. Die Wortwahl ist unerheblich, solange sie eindeutig
      ist. Insbesondere sollten Formulierungen in der Art von "I would vote
      for this group if..." ("Ich wuerde fuer diese Gruppe stimmen,
      wenn...")  ausschliesslich als Kommentar betrachtet werden und nicht
      als Stimmen gezaehlt werden.



   Das Ergebnis

   1. Am Ende der Abstimmungsperiode muss der Stimmenauszaehler das
      Auszaehlungsergebnis, die E-Mail-Adressen der eingetroffenen Stimmen
      und, wenn moeglich, die Namen der Waehler nach news.announce.newgroups
      (sub-Netz: sub.config) und jede andere Gruppe oder Mailing-Liste
      posten, in die der urspruengliche "Call for Votes" gepostet wurde. Aus
      der Auflistung sollte hervorgehen, wie jeder Waehler gestimmt hat,
      sodass das Ergebnis ueberprueft werden kann.

   2. NACHDEM das Abstimmungsergebnis gepostet wurde, kommt eine 5-taegige
      Wartezeit (sub-Netz: 10 Tage). Diese Wartezeit beginnt mit dem Tag, an
      dem das Ergebnis tatsaechlich in news.announce.newgroups (sub-Netz:
      sub.config) gepostet wurde. Waehrend der Wartezeit hat das Netz die
      Chance eventuelle Fehler in der Waehlerliste oder dem Verlauf der
      Abstimmung zu korrigieren.

   3. Wenn NACH der Warteperiode keine berechtigten Zweifel an der
      Gueltigkeit der Abstimmung bestehen und mindestens 100 (sub-Netz: 10)
      JA/Einrichten-Stimmen mehr als NEIN/Nicht-Einrichten-Stimmen vorhanden
      sind UND wenigsten 2/3 aller gueltigen Stimmen fuer die Einrichtung
      sind, kann eine Newgroup-Control-Message abgeschickt werden. Die
      Gruppe sollte nicht eingerichtet werden, wenn die 100-Stimmengrenze
      (sub-Netz: 10 Stimmen) oder das 2/3 Verhaeltnis nicht erreicht wurde.

      Wenn es ihm moeglich ist, sollte der Stimmenauszaehler die Newgroup-
      Message abschicken, ansonsten der Administrator der Maschine des
      Auszaehlers. Wenn auch letzteres nicht moeglich ist, sollte der
      Stimmenzaehler eine Mail an "newgroup@ncar.ucar.edu" (sub-netz:
      news@smurf.sub.org) schicken, in der steht, dass die Abstimmung
      erfolgreich war und darum bitten, eine Newgroup-Message zu posten.
      Das Abstimmungsergebnis sollte NICHT mitgeschickt werden, es kann in
      news.announce.newgroups nachgesehen werden. Ausserden sollte noch Gene
      Spafford (spaf@purdue.edu) (sub-Netz: Matthias Urlichs
      (news@smurf.sub.org)) ueber die erfolgreiche Abstimmung informiert
      werden, damit er die neue Gruppe in die Liste der offiziellen Gruppen
      aufnehmen kann.

   -- 
    STREAMS sucks.		   Christoph Badura, Karlsruhe, Deutschland
				   bad@flatlin.ka.sub.org

-------------schnipp-------------schnapp-------------schnipp-------------------


Gruessend, Marc.
--
Marc Binderberger                       Institute for Theoretical Physics
mbind@thp.Uni-Koeln.DE                  University of Cologne/Germany
Technical Details
Message-ID: <MBIND.91Jul25140120@sun9.thp.uni-koeln.de>
Path: arc1-ca.pugleaf.net!gmdzi!unido!uni-koeln!aix370.rrz.uni-koeln.de!mbind

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit
X-Google-Thread: 10dc06,8ee8c91314a3e3c2,start
X-Google-Attributes: gid10dc06,public
X-Google-ArrivalTime: 1991-07-25 05:16:47 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!uni-koeln!aix370.rrz.uni-koeln.de!mbind
From: mbind@thp.uni-koeln.de (Marc Binderberger)
Newsgroups: dnet.general
Subject: Spielregeln im DNET -- (Un-)Sinn ?
Message-ID: <MBIND.91Jul25140120@sun9.thp.uni-koeln.de>
Date: 25 Jul 91 14:01:20 GMT
Sender: news@rrz.uni-koeln.de (Usenet News System)
Reply-To: mbind@thp.uni-koeln.de (Marc Binderberger)
Followup-To: dnet.general
Distribution: dnet
Organization: Institute of Theoretical Physics, University of Cologne, F. R.
 Germany
Lines: 262