1389 lines
59 KiB
Plaintext
1389 lines
59 KiB
Plaintext
Archive-name: de-admin/dan-glossar
|
|
Posting-frequency: weekly
|
|
Version: 1.5.7
|
|
Last-modified: (unreleased)
|
|
URL: https://th-h.de/archives/faqs/dan-glossar.txt
|
|
URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
|
|
|
|
Wichtige Begriffe in de.admin.news.*
|
|
====================================
|
|
|
|
Dieses kleine Wörterbuch soll Dir helfen, die Diskussionskultur und
|
|
die Inhalte der Gruppen de.admin.news.[announce|groups|misc] zu
|
|
verstehen, damit Du auch ohne jahrelanges Mitlesen in diesen Gruppen
|
|
mitwirken kannst. Es ist als einführendes Nachschlagewerk gedacht,
|
|
liefert aber viele Verweise zu weiterführenden Texten. Jeder solche
|
|
Verweis ist entweder
|
|
|
|
* eine URL
|
|
|
|
oder
|
|
|
|
* die Message-ID eines Artikels im Usenet, den Du auf diese Weise
|
|
in Deinem Newsreader oder mit einer Usenet-Suchmaschine wie
|
|
<http://al.howardknight.net/> finden kannst. Das Archiv von
|
|
GoogleGroups ist insofern leider nur noch bedingt hilfreich.
|
|
|
|
Dieses Nachschlagewerk setzt viele elementare Begriffe des Usenets
|
|
bereits als bekannt voraus. Wenn Du im Usenet insgesamt noch unerfahren
|
|
bist, solltest Du daher Unbekanntes zuerst in einem einführenden Text
|
|
wie
|
|
|
|
| From: amk@spamfence.net (Andreas M. Kirchwitz)
|
|
| Newsgroups: de.newusers.infos
|
|
| Subject: <Datum> Glossar
|
|
|
|
|
| Archive-name: de-newusers/glossar
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 2011-12-09
|
|
| URL: http://www.kirchwitz.de/~amk/dni/glossar
|
|
|
|
nachschlagen. Auch ganz grundsätzlich ist die Lektüre der einleitenden
|
|
Texte zum Usenet an sich in der Newsgroup de.newusers.infos, die sich
|
|
an neue Benutzer wendet; ein Schritt, der sich vor der Lektüre der
|
|
Texte in de.admin.infos, die sich mit der Selbstverwaltung der
|
|
deutschsprachigen Hierarchie de.* beschäftigen, anbietet.
|
|
|
|
Wenn Dir beim Lesen von de.admin.news.* weitere schwierige Begriffe
|
|
auffallen, die hier nicht erklärt sind, oder wenn Du andere hilfreiche
|
|
Verweise auf weiterführende Texte kennst, so schreibe mir bitte, damit
|
|
ich dieses Nachschlagewerk vervollständigen kann; siehe dazu auch die
|
|
Hinweise am Ende des Textes.
|
|
|
|
Querverweise habe ich mit /Schrägstrichen/ gekennzeichnet. Mit Pl. gebe
|
|
ich an, wie die Mehrzahl eines Wortes üblicherweise gebildet wird.
|
|
|
|
***
|
|
|
|
Abstimmungsaufruf
|
|
/CfV/.
|
|
|
|
advocacy-Gruppe
|
|
nennt man eine Gruppe, in der Vor- und Nachteile konkurrierender
|
|
Ideen oder Produkte diskutiert werden. Eine advocacy-Gruppe ist
|
|
üblicherweise /unmoderiert/ und endet mit der /Komponente/ advocacy.
|
|
|
|
.ALL
|
|
bezeichnet alle Gruppen einer /Hierarchie/. Zum Beispiel ist de.ALL
|
|
eine andere Schreibweise für /de.*/.
|
|
|
|
alt.*
|
|
ist eine internationale /Hierarchie/, in der /newgroups/ nach recht
|
|
lockeren Regeln verschickt werden dürfen. Sie ist demzufolge
|
|
unübersichtlich und wird in /dan*/ gern als abschreckendes Beispiel
|
|
genannt, wenn jemand die hiesigen /Einrichtungsregeln/ als zu streng
|
|
kritisiert.
|
|
|
|
announce-Gruppe
|
|
nennt man eine Gruppe, welche die Ankündigungen einer thematischen
|
|
/Unterhierarchie/ bündelt. Eine announce-Gruppe ist üblicherweise
|
|
/moderiert/ und endet mit der /Komponente/ announce.
|
|
|
|
anonym
|
|
kann man nach außen hin in einem /CfV/ abstimmen, wenn man dem
|
|
/Wahlleiter/ überzeugende Gründe hierfür nennt. In diesem Fall
|
|
erscheint weder der /Realname/ noch die E-Mailadresse im /Result/.
|
|
|
|
approven (engl. "to approve")
|
|
bedeutet, einen zur Veröffentlichung in einer /moderierten/ Gruppe
|
|
eingereichten Artikel zuzulassen. Dies ist Aufgabe der jeweiligen
|
|
/Moderation/, welche einen Approved:-Header setzt und dann den
|
|
Artikel ins Usenet einspeist.
|
|
|
|
Da ein Approved:-Header technisch auch von jeder anderen Person
|
|
gesetzt werden kann (wenn auch nicht darf), signieren manche
|
|
/Moderationen/ jeden approveten Artikel mit /PGP/. Dadurch kann man
|
|
nicht von der /Moderation/ approvete Artikel erkennen und auch
|
|
automatisiert /canceln/.
|
|
|
|
Aprilscherz
|
|
ist ein schalkhafter /RfD/, der traditionsgemäß am 1. April in
|
|
/dana/ veröffentlicht wurde und die Ernsthaftigkeit von /dan*/ auf
|
|
die Schippe nimmt. /Proponenten/ für gute Aprilscherze sind immer
|
|
willkommen.
|
|
|
|
Attribute
|
|
einer Gruppe sind /Gruppenname/, /Kurzbeschreibung/, /Charta/ und
|
|
/Status/. Bei /moderierten/ Gruppen kommen die Mitglieder der
|
|
/Moderation/ hinzu.
|
|
|
|
auf Verdacht
|
|
werden in /de.*/ keine Gruppen eingerichtet. Für jede neue Gruppe
|
|
muss stets der tatsächliche /Bedarf/ nachgewiesen werden. Das liegt
|
|
daran, dass leerstehende Gruppen einerseits die /Übersichtlichkeit/
|
|
der /Hierarchie/ stören und andererseits ihre /Löschung/
|
|
problematisch ist. Näheres ist in den /Missverständnissen/ erläutert.
|
|
|
|
Bedarf
|
|
ist die wichtigste Voraussetzung für eine Entscheidung in /de.*/.
|
|
In /daa/ zeigt man den tatsächlichen Bedarf meist durch einen
|
|
/Trafficnachweis/. In /dan*/ dient außerdem die /Mindeststimmenzahl/
|
|
zur Überprüfung des Bedarfs.
|
|
|
|
Big8 (die)
|
|
nennt man die großen acht englischsprachigen internationalen
|
|
/Hierarchien/ comp.*, humanities.*, misc.*, news.*, rec.*, sci.*,
|
|
soc.* und talk.*. Sie sind gut gepflegt und dienten in ihrer
|
|
Gliederung teilweise als Vorbild für /de.!alt/. Mittlerweile hat
|
|
/de.*/ jedoch eine eigene, hiervon unabhängige Gliederung, so dass
|
|
ein Verweis auf Parallelen in den Big8 meist ein /Missverständnis/
|
|
ist.
|
|
|
|
Buzzword-Traffic
|
|
ist /Traffic/, der erst durch die /Einrichtung/ einer Gruppe
|
|
entsteht, da der /Gruppenname/ oder die /Kurzbeschreibung/ ein
|
|
Buzzword enthält - also ein Wort, nach dem viele Leute suchen. Das
|
|
Vertrauen auf Buzzword-Traffic kann mitunter den /Trafficnachweis/
|
|
ersetzen.
|
|
|
|
canceln (engl. "to cancel")
|
|
heißt, das Löschen eines Artikels im Usenet zu veranlassen.
|
|
Bei eigenen Artikeln ist dies stets erlaubt, zum Beispiel um einen
|
|
Fehler zu korrigieren. Bei Artikeln anderer Leute wird innerhalb
|
|
von /de.*/ jedoch dringend empfohlen, die Richtlinien zum
|
|
Fremdcancel in der - seit 2012 nicht mehr neu veröffentlichten -
|
|
Fremdcancel-FAQ
|
|
|
|
| From: Florian Seffler <florian@filmateleven.de>
|
|
| Newsgroups: de.admin.net-abuse.news,de.admin.net-abuse.announce,de.admin.news.misc,de.soc.netzkultur.misc,de.answers,news.answers
|
|
| Subject: <2000-03-20> Fremdcancel-FAQ
|
|
|
|
|
| Fremdcancel-FAQ
|
|
|
|
|
| Archive-Name: de-net-abuse/fremdcancel-faq
|
|
| URL: https://web.archive.org/web/20120226145750/http://filmateleven.de/cms/?Usenet:Fremdcancel-FAQ
|
|
| Posting-Frequency: monthly
|
|
|
|
zu beachten.
|
|
|
|
CfV (= Call for Votes; der, Pl. CfVs)
|
|
ist ein Aufruf an die /Netzöffentlichkeit/, über eine Sachfrage zu
|
|
entscheiden, die zuvor in /dan*/ diskutiert worden ist. Ein CfV wird
|
|
in /dana/ und allen betroffenen Gruppen veröffentlicht. Er sollte
|
|
frühestens zwei Wochen nach dem letzten einschlägigen /RfD/
|
|
erscheinen und mit diesem inhaltlich übereinstimmen. Nähere
|
|
Einzelheiten stehen in den /Einrichtungsregeln/ und im
|
|
/dana-Manual/.
|
|
|
|
"[x] CfV now!"
|
|
ist eine knappe Aufforderung an den /Proponenten/, die /Diskussion/
|
|
für beendet zu erklären und den /CfV/ einzureichen. Der Grund
|
|
hierfür kann entweder sein, dass man mit dem /Proponenten/ inhaltlich
|
|
völlig übereinstimmt oder mit ihm derart unterschiedlicher Meinung
|
|
ist, dass aus einer weiteren /Diskussion/ keine neuen Erkenntnisse zu
|
|
erwarten sind.
|
|
|
|
Charta (die, Pl. Chartas)
|
|
ist eine möglichst allgemeinverständliche Beschreibung, welche
|
|
Themen in einer Gruppe behandelt werden sollen und welche nicht.
|
|
Listen aller Chartas von /de.*/ einschließlich /de.alt/ findest Du
|
|
in
|
|
|
|
| From: Thomas Hochstein <thh@thh.name>
|
|
| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
|
|
| Subject: <Datum> Die Newsgruppen der de-Hierarchie
|
|
|
|
|
| Archive-name: de-newusers/de-newsgruppen
|
|
| Posting-frequency: weekly
|
|
| URL: https://th-h.de/archives/faqs/de-newsgruppen.txt
|
|
| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
|
|
|
|
Es lohnt sich, Chartas sorgfältig und sprachlich sauber zu
|
|
verfassen, damit jeder Leser möglichst eindeutig entscheiden kann,
|
|
was in der betreffenden Gruppe on topic ist.
|
|
|
|
checkgroups (der)
|
|
ist ein /Control/, der die /Taglines/ aller Gruppen einer
|
|
/Hierarchie/ auflistet.
|
|
|
|
Control (der, Pl. Controls)
|
|
ist ein Artikel im Usenet, der nicht zur menschlichen, sondern zur
|
|
maschinellen Auswertung gedacht ist, also eine /Steuernachricht/.
|
|
Controls sind Befehle an die Newsserver. Dazu zählen einerseits
|
|
Veränderungen an der Gruppenstruktur (/newgroup/, /rmgroup/,
|
|
/checkgroups/), zum anderen das Löschen von Artikeln (/Canceln/).
|
|
|
|
In /de.!alt/ versendet die /dana-Moderation/ die strukturändernden
|
|
Controls, signiert mit dem /dana-Key/. In /de.alt/ hingegen tun dies
|
|
mehrere technisch erfahrene Leute auf Anfrage.
|
|
|
|
daa
|
|
ist die Gruppe de.alt.admin. Sie verwaltet die Unterhierarchie
|
|
/de.alt/ gemäß Anhang A der /Einrichtungsregeln/.
|
|
|
|
dai
|
|
ist die /moderierte/ Gruppe de.admin.infos. Sie enthält für /dan*/
|
|
relevante /Regeltexte/ und hilfreiche Erläuterungen dazu. Von allen
|
|
/Diskutanten/ wird stillschweigend erwartet, dass sie mit den Texten
|
|
aus dai vertraut sind.
|
|
|
|
dana
|
|
ist die /moderierte/ Gruppe de.admin.news.announce. Von hier aus
|
|
werden die Gruppen von /de.!alt/ und die Regeln von /de.*/
|
|
verwaltet. Das bedeutet, dass hier alle einschlägigen /RfDs/, /CfVs/,
|
|
/Results/ und /Einsprüche/ erscheinen.
|
|
|
|
Wenn Du an der Pflege von /de.*/ mitwirken willst, solltest Du dana
|
|
regelmäßig lesen. Da es sich um eine /Low-Traffic-Gruppe/ handelt,
|
|
reicht es, sie alle paar Tage zu lesen. Wenn Du dabei auf ein Thema
|
|
stößt, das Dich besonders interessiert, solltest Du für die Dauer
|
|
der Diskussion die passende Gruppe in /dan*/ abonnieren, auf die der
|
|
Followup-To:-Header zeigt.
|
|
|
|
dana-Key (der)
|
|
heißt der /PGP/-Schlüssel der /dana-Moderation/. Er dient dazu,
|
|
/Controls/ zu authentifizieren, welche /de.!alt/ betreffen.
|
|
|
|
dana-Manual (das)
|
|
ist eine ausführliche und sehr lesenswerte Beschreibung, wie man ein
|
|
/Verfahren/ in /dan*/ erfolgreich durchführt, und unter
|
|
|
|
| From: dana-manual@usenet.th-h.de (Thomas Hochstein / Michael Ottenbruch)
|
|
| Newsgroups: de.admin.infos,de.answers,news.answers
|
|
| Subject: <Datum> Erlaeuterungen zur Einrichtung neuer Gruppen in de.*
|
|
|
|
|
| Archive-name: de-newusers/dana-manual
|
|
| Posting-frequency: weekly
|
|
| Version: 2.2.6
|
|
| Last-modified: 2020-08-24
|
|
| URL: http://www.kirchwitz.de/~amk/dai/dana-manual
|
|
| URL: https://th-h.de/archives/faqs/dana-manual.txt
|
|
|
|
veröffentlicht.
|
|
|
|
dana-Moderation
|
|
ist die /Moderation/ von /dana/. Sie kann unter der E-Mailadresse
|
|
<moderator@dana.de> erreicht werden.
|
|
|
|
Die derzeitige dana-Moderation besteht aus dem /Statusverwalter/,
|
|
dem /Umsetzungsbeauftragten/ und den vier /Verfahrensbetreuern/.
|
|
Ihr /Moderationskonzept/ bestimmt die interne Arbeitsweise.
|
|
|
|
Diese Ämter- und Aufgabenverteilung kann sich jederzeit ändern, wenn
|
|
das /Moderationskonzept/ überarbeitet oder die dana-Moderation durch
|
|
/Neuwahl/ abgelöst wird. Insbesondere ist es möglich, dass /dana/
|
|
von einer Einzelperson /moderiert/ wird. Alle früheren
|
|
dana-Moderatoren sind in
|
|
<https://web.archive.org/web/20120529054756/http://www.babylonsounds.com/usenet/moderation.html>
|
|
aufgelistet.
|
|
|
|
dana-Status
|
|
heißt der wöchentlich in /dana/ erscheinende Überblick über alle
|
|
anhängigen /Verfahren/. Er wird von der /dana-Moderation/
|
|
veröffentlicht und gilt als Pflichtlektüre für /dang-Regulars/.
|
|
Ergänzt wird er um die Statusübersicht der /GVV/, den /GVV-Status/.
|
|
|
|
dang
|
|
ist die Gruppe de.admin.news.groups. Hier wird die /Einrichtung/
|
|
oder /Löschung/ von Gruppen in /de.!alt/ diskutiert sowie die
|
|
Änderung der zuhörigen /Attribute/.
|
|
|
|
dang-Regular (der, Pl. dang-Regulars)
|
|
nennt man jemanden, der regelmäßig in /dang/ mitliest und
|
|
mitdiskutiert, auch wenn er vom augenblicklichen Thema nicht
|
|
unmittelbar betroffen ist. Seine Motivation dazu ist, an der Pflege
|
|
von /de.!alt/ aktiv teilzunehmen, damit /de.*/ eine übersichtliche
|
|
und nützliche /Hierarchie/ wird und bleibt.
|
|
|
|
Die dang-Regulars sind mitunter sehr verschiedene Menschen. Manche
|
|
sind erfahrene alte Hasen, die schon seit Anbeginn von /de.*/ diese
|
|
/Hierarchie/ mitpflegen. Andere wiederum sind erst vor wenigen
|
|
Monaten oder Jahren hierhergelangt und haben Gefallen an der
|
|
Verantwortung für /de.!alt/ gefunden. Nicht immer sind die
|
|
lautstärksten dang-Regulars auch diejenigen, auf die man am meisten
|
|
hören sollte.
|
|
|
|
danm
|
|
ist die Gruppe de.admin.news.misc. Hier werden sonstige Themen der
|
|
Unterhierarchie /dan*/ behandelt. Wichtig darunter sind die
|
|
/Neuwahlen/ oder /Nachwahlen/ von /Moderationen/, insbesondere die
|
|
der /dana-Moderation/.
|
|
|
|
danr
|
|
war die Gruppe de.admin.news.regeln. Hier fanden früher
|
|
Regeldiskussionen und /Richtlinienverfahren/ statt, ebenso die
|
|
öffentliche Debatte zu /Einsprüchen/. Diese Themen werden nunmehr
|
|
in de.admin.news.misc (und ggf. de.admin.news.groups) diskutiert.
|
|
Damit die /Diskussionen/ sachlich bleiben und nicht ins Absurde
|
|
abgleiten, sollte man jegliches /Nomicen/ unterlassen.
|
|
|
|
dan*
|
|
bezeichnet die für menschliche Leser bestimmten Gruppen der
|
|
/Unterhierarchie/ de.admin.news.*. Das sind also /dana/, /dang/
|
|
und /danm/.
|
|
|
|
dcsa
|
|
ist die Unterhierarchie de.comm.software.*. Sie war in den Jahren
|
|
1999/2000 Gegenstand einer umfassenden, letztlich aber gescheiterten
|
|
/Reorganisation/. Ursache des Misslingens war ein komplizierter
|
|
/Wahlschein/, der nicht gegen das letztlich entstandene unliebsame
|
|
/Result/ abgesichert war. Dieses /Verfahren/ gilt wegen seiner
|
|
langen Dauer, des damit einhergegangenen Umzugs von /Traffic/ nach
|
|
/hamster.*/ und des letztlich entstandenen /Schlamassels/ als
|
|
abschreckendes Beispiel.
|
|
|
|
de.*
|
|
ist eine internationale deutschsprachige /Hierarchie/. Ihr Themen-
|
|
und Gruppenangebot beruht auf den Grundideen /Vollständigkeit/,
|
|
/Themenorientierung/ und /Übersichtlichkeit/.
|
|
|
|
de.alt
|
|
ist die /Unterhierarchie/, welche von /daa/ gemäß Anhang A der
|
|
/Einrichtungsregeln/ verwaltet wird. Über Gruppen in de.alt wird
|
|
also nicht durch Abstimmung, sondern durch Konsens entschieden.
|
|
|
|
de.!alt
|
|
bezeichnet alle /Unterhierarchien/ von /de.*/, welche nicht zu
|
|
/de.alt/ gehören. Über Gruppen in de.!alt wird mittels formeller
|
|
/Verfahren/ und Abstimmungen in /dana/ und /dang/ entschieden.
|
|
|
|
de.answers
|
|
ist eine /moderierte/ Gruppe, in der zahlreiche Informationstexte
|
|
aus anderen deutschsprachigen Gruppen in regelmäßigen Abständen
|
|
veröffentlicht werden.
|
|
|
|
de.etc.misc
|
|
ist die Gruppe, in der alle Themen besprochen werden, zu denen es
|
|
keine passendere Gruppe in /de.*/ gibt. Ihr Nutzwert ist
|
|
hauptsächlich theoretischer Natur. In der Praxis eignet sich meist
|
|
eine andere /misc-Gruppe/ besser für die Diskussion, weil dort mehr
|
|
fachkundige Leute mitlesen.
|
|
|
|
Diskussion
|
|
bezeichnet in /dan*/ anders als im übrigen Usenet nicht jeden
|
|
beliebigen kontroversen Schriftwechsel, sondern meist nur die durch
|
|
einen formellen /RfD/ oder einen informellen /Prae-RfD/ eingeleitete
|
|
Besprechung einer Sachfrage.
|
|
|
|
Da in /dan*/ sehr viele Leute mitlesen und mitdiskutieren, ist etwas
|
|
Disziplin und Diskussionskultur wichtig. Insbesondere der Grundsatz
|
|
"Teilen Sie etwas Neues mit!" aus der Netiquette verdient Beachtung.
|
|
Weder der /Proponent/ noch sonst ein /Diskutant/ sollte sich durch
|
|
übermäßig viele Beiträge zum Alleinunterhalter aufschwingen. Es
|
|
bringt auch nichts, mit immergleichen Argumenten und Gegenargumenten
|
|
im Kreis zu debattieren, sondern schadet nur der Übersichtlichkeit
|
|
der Diskussion. Scheinbar unüberbrückbare Gegensätze werden in
|
|
/dan*/ nicht durch Endlosdebatten, sondern per Abstimmung gelöst.
|
|
|
|
Diskussionskultur heißt insbesondere, dass mit Veröffentlichung des
|
|
/CfV/ die Diskussionsphase beendet ist und nicht mehr über
|
|
verbliebene Uneinigkeiten debattiert zu werden braucht.
|
|
|
|
Diskussionsaufruf
|
|
/RfD/.
|
|
|
|
Diskutant
|
|
ist jeder, der an einer /Diskussion/ in /dan*/ aktiv teilnimmt.
|
|
Hierzu zählen der /Proponent/, seine Mitstreiter und Gegner sowie
|
|
interessierte /dang-Regulars/. Häufig diskutieren auch Mitglieder
|
|
der /dana-Moderation/ mit, sofern sie an der Sachfrage interessiert
|
|
sind.
|
|
|
|
Eindeutschung
|
|
ist ein häufig wiederkehrender Vorschlag, die vielen englischen
|
|
Fachbegriffe aus /Gruppennamen/, /Kurzbeschreibungen/, /Chartas/
|
|
oder sogar der /Diskussion/ in /dan*/ zu tilgen und durch deutsche
|
|
Wörter zu ersetzen. Einen /RfD/ zu diesem Thema einzureichen lohnt
|
|
sich nicht, da sich viele Fachbegriffe eingebürgert und als
|
|
praktisch erwiesen haben.
|
|
|
|
Einrichtung
|
|
einer Gruppe geschieht durch /newgroup/. Innerhalb von /de.*/ ist
|
|
dies erst nach einem /Verfahren/ gemäß der /Einrichtungsregeln/
|
|
möglich.
|
|
|
|
Einrichtungsregeln
|
|
legen fest, wie ein /Verfahren/ in /de.*/ abläuft. Sie sind für die
|
|
/Einrichtung/ von Gruppen formuliert, gelten aber analog auch für
|
|
/Löschung/, /Umbenennung/, Änderung anderer /Attribute/ einer Gruppe
|
|
und /Richtlinienverfahren/. Sie sind unter
|
|
|
|
| From: 3.14@piology.org (Boris 'pi' Piwinger)
|
|
| Newsgroups: de.admin.infos,de.alt.admin
|
|
| Subject: <Datum> Einrichtung von Usenet-Gruppen in de.*
|
|
|
|
|
| Archive-name: de-admin/einrichtung
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 2012-01-09
|
|
| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
|
|
|
|
veröffentlicht.
|
|
|
|
Einspruch
|
|
nennt man einen formellen Einwand gegen ein /Result/. Er ist
|
|
innerhalb der /Einspruchsfrist/ bei der /dana-Moderation/
|
|
einzureichen und kann die Korrektur oder die Annullierung des
|
|
/Results/ zum Gegenstand haben. Die /dana-Moderation/ entscheidet
|
|
abschließend darüber. Näheres steht in den /Einrichtungsregeln/.
|
|
|
|
Die Höflichkeit gebietet, das Instrument des Einspruchs nur in
|
|
begründeten Fällen zu nutzen und es nicht zum /Nomicen/ zu
|
|
missbrauchen.
|
|
|
|
Einspruchsfrist
|
|
beträgt eine Woche nach Veröffentlichung des /Results/.
|
|
|
|
Ergebnis
|
|
/Result/.
|
|
|
|
Erinnerungs-RfD
|
|
nennt man einen /RfD/, der weitgehend wortgleich mit seinem
|
|
Vorgänger ist und hauptsächlich deshalb veröffentlicht wird, um die
|
|
/Netzöffentlichkeit/ an ein zwischenzeitlich unterbrochenes
|
|
/Verfahren/ zu erinnern. Es gilt als höflich, vor dem /CfV/ einen
|
|
Erinnerungs-RfD einzuschieben, falls die Unterbrechung länger als
|
|
sechs Wochen gedauert hat.
|
|
|
|
Fake (das; Pl. Fakes)
|
|
nennt man einen Artikel mit gefälschtem Absender in E-Mail oder
|
|
Usenet. Dabei ist unerheblich, ob der vermeintliche Absender
|
|
tatsächlich existiert oder eine Phantasieperson beschreibt.
|
|
|
|
In einem /CfV/ werden als Fakes erkannte Stimmen nicht gewertet.
|
|
Wann der Verdacht gerechtfertigt ist, dass eine Stimme ein Fake
|
|
darstellt, und welche Konsequenzen man aus dem Verdacht ziehen soll,
|
|
wird in <9q4ttd$37a$1@kalkleiste.nomic.de> ausführlich erörtert.
|
|
Entsprechende Entscheidungen der /dana-Moderation/ sind in ihrem
|
|
Entscheidungs-Archiv unter <http://dana.de/archiv.html>
|
|
veröffentlicht.
|
|
|
|
flach
|
|
nennt man die Einordnung einer Gruppe, wenn der /Gruppenname/ nur
|
|
aus wenigen /Komponenten/ besteht. Zum Beispiel ist die Gruppe
|
|
/de.answers/ flach eingeordnet, weil ihr Thema sehr allgemein ist.
|
|
|
|
free.*
|
|
ist eine internationale /Hierarchie/, in der jedermann /newgroups/
|
|
verschicken darf. Sie ist demzufolge unübersichtlich und wird in
|
|
/dan*/ gern als abschreckendes Beispiel genannt, wenn jemand die
|
|
hiesigen /Einrichtungsregeln/ als zu streng kritisiert.
|
|
|
|
Fuchsschwanz
|
|
nennt man ein /Verfahren/, welches augenscheinlich nur der
|
|
Befriedigung der persönlichen Eitelkeit des /Proponenten/ dient.
|
|
Gründe für diesen Vorwurf können sein, dass der /Proponent/ eine
|
|
Gruppe ohne erkennbaren /Traffic/, mit zu /flacher/ Einordnung oder
|
|
ungeachtet aller sinnvollen Gegenargumente einrichten lassen will.
|
|
Namensgebend hierfür sind die Fuchsschwänze, mit denen Mantafahrer
|
|
ihre Autos zu verzieren pflegen.
|
|
|
|
Gesinnungs-Nein
|
|
heißt eine Neinstimme gegen die /Einrichtung/ einer Gruppe, die nur
|
|
deswegen abgegeben wird, weil dem Wähler das Thema der Gruppe
|
|
missfällt. Solche Neinstimmen schaden der /Übersichtlichkeit/ von
|
|
/de.*/ und sollten daher unterbleiben. Dies wurde erstmals in
|
|
<qDZiz*tPi@yaps.rhein.de> erörtert.
|
|
|
|
Go-Gruppe
|
|
ist die Anspielung auf ein /Verfahren/ aus den Jahren 1999/2000,
|
|
welches sich durch Starrsinn aller Beteiligten sowie durch Auftreten
|
|
von /Stimmvieh/ in die Länge zog und an Streitigkeiten über /flache/
|
|
oder /tiefe/ Einordnung der Gruppe scheiterte. Es gilt als
|
|
abschreckendes Beispiel dafür, wie man eine gute Idee in /dan*/
|
|
durch zu viel Eifer zum Misserfolg führen kann. Eine Dokumentation
|
|
ist in <9ueqm9.19k.1@babylonsounds.com> zu finden.
|
|
|
|
GPG (GNU Privacy Guard; der)
|
|
ist ein Ersatz für /PGP/ in Form freier Software, der den
|
|
OpenPGP-Standard (/RFC/ 4880) implementiert und PGP in der Praxis
|
|
weitgehend ersetzt haben dürfte.
|
|
|
|
Gruppenleiche
|
|
heißt eine Gruppe, wenn sie auf manchen Newsservern noch existiert,
|
|
obwohl sie bereits vor langer Zeit durch einen /rmgroup/ gelöscht
|
|
wurde und nicht mehr im /checkgroups/ vorkommt. Da manche, vor
|
|
allem kleinere Newsserver schlecht gepflegt werden, kommen
|
|
Gruppenleichen in der Praxis durchaus vor und führen dann zu
|
|
Verwirrung.
|
|
|
|
Gruppenname
|
|
ist das wichtigste und einprägsamste /Attribut/ einer Gruppe im
|
|
Usenet. Da der Name die Einordnung der Gruppe in eine
|
|
/Unterhierarchie/ beschreibt, ist er besonders sorgfältig
|
|
auszuwählen und auf das Thema abzustimmen. Einzelheiten stehen auf
|
|
<http://www.dana.de/newsgroup-namen.html> und im /dana-Manual/.
|
|
|
|
Gruppennamen werden in der /Diskussion/ häufig abgekürzt. Auf
|
|
<http://www.purl.org/stefan_ram/pub/usenet-gruppenkuerzel-de> steht,
|
|
wie solche Abkürzungen im allgemeinen aussehen.
|
|
|
|
GVV (= German Volunteer Votetakers, Pl.)
|
|
sind ein Kreis erfahrener /dang-Regulars/, die meist gern bereit
|
|
sind, einen /CfV/ als /Wahlleiter/ zu übernehmen. Sie können unter
|
|
der E-Mailadresse <gvv@dana.de> erreicht werden. Näheres ist auf
|
|
<https://votetakers.de/> erläutert.
|
|
|
|
GVV-Status
|
|
wird die Statusübersicht der von den /GVV/ betreuten Abstimmungen
|
|
genannt, die ebenso wie der /dana-Status/ wöchentlich in /dana/
|
|
veröffentlicht wird und die neu eingegangenen, laufenden und
|
|
bereits beendeten Abstimmungen sowie deren Verlauf zusammenfasst.
|
|
|
|
hamster.*
|
|
ist eine internationale, mehrsprachige /Hierarchie/ über die
|
|
Newsserver-Software Hamster. Sie entstand im Verlaufe des
|
|
/Verfahrens/ zu /dcsa/ und gilt als abschreckendes Beispiel dafür,
|
|
dass /Traffic/ aus /de.*/ abwandert, wenn man ihm nicht binnen
|
|
vernünftiger Frist eine passende Gruppe zur Verfügung stellt.
|
|
|
|
Hierarchie
|
|
nennt man eine Menge von Gruppen, deren Namen mit denselben
|
|
/Komponenten/ beginnen. Je nach Anzahl der gemeinsamen /Komponenten/
|
|
unterscheidet man Hierarchien verschiedenen Grades:
|
|
|
|
Top-Level-Hierarchien: z. B. /de.*/, at.*, ch.*, /Big8/
|
|
Second-Level-Hierarchien: z. B. /de.alt/
|
|
Third-Level-Hierarchien: z. B. de.admin.news.*
|
|
|
|
Eine einigermaßen vollständige Liste aller Top-Level-Hierarchien
|
|
ist zu finde auf
|
|
<https://web.archive.org/web/20161105222209/http://www.pfx.ca/mlnh/index.html>.
|
|
|
|
Unterschiedliche Hierarchien werden nach unterschiedlichen Regeln
|
|
verwaltet. Für /de.*/ gelten die hiesigen /Einrichtungsregeln/.
|
|
|
|
High-Traffic-Gruppe
|
|
nennt man eine Gruppe, deren /Traffic/ mehr als etwa 50 Artikel pro
|
|
Tag beträgt.
|
|
|
|
Hype-Traffic (der)
|
|
ist ein zeitweilig sehr hohes Diskussionsaufkommen aufgrund
|
|
aktueller Gegebenheiten (politischer Ereignisse, Veröffentlichungen
|
|
von Büchern, Filmen, Software usw.). Erfahrungsgemäß sinkt solcher
|
|
/Traffic/ nach einiger Zeit wieder. Da ein /Trafficnachweis/ erst
|
|
dann überzeugt, wenn der /Traffic/ über längere Zeit stabil bleibt,
|
|
taugt Hype-Traffic nicht als Argument für eine neue Gruppe.
|
|
|
|
info-Gruppe
|
|
nennt man eine Gruppe, welche Informationstexte einer thematischen
|
|
/Unterhierarchie/ bündelt. Eine info-Gruppe ist üblicherweise
|
|
/moderiert/ und endet auf die /Komponente/ infos.
|
|
|
|
[J/N/E]
|
|
ist eine schematische Darstellung der Entscheidungsmöglichkeiten JA,
|
|
NEIN und ENTHALTUNG in einer Abstimmung. Sie wird vor allem in
|
|
Diskussionen benutzt, um die Struktur komplizierterer /Wahlscheine/
|
|
zu erläutern.
|
|
|
|
KISS (= Keep It Simple, Stupid; das)
|
|
heißt ein bereits mehrfach gescheiterter Versuch, die
|
|
/Einrichtungsregeln/ radikal zu vereinfachen. Er ist als
|
|
Gegenbewegung zum regelverfeinernden /Nomicen/ zu verstehen und hat
|
|
seinen Ursprung in <6bp4rp$pta$1@sobolev.rhein.de>.
|
|
|
|
kombiniertes Voting
|
|
nennt man einen /CfV/, in dessen /Wahlschein/ man aus mehreren
|
|
Möglichkeiten eine auswählen soll. Die Einzelheiten hierzu werden
|
|
in Punkt 9 der /Einrichtungsregeln/ beschrieben.
|
|
|
|
Ein kombiniertes Voting verkompliziert erfahrungsgemäß den /CfV/ und
|
|
vermindert manchmal dessen Erfolgsaussichten. Darum ist es im
|
|
allgemeinen ratsam, auf das kombinierte Voting zu verzichten und
|
|
stattdessen bereits während der /Diskussion/ die Entscheidung durch
|
|
einen /Strawpoll/ herbeizuführen. Ausführlich besprochen wird diese
|
|
Problematik in
|
|
|
|
| From: Ralf Döblitz <faq@netzverwaltung.net>
|
|
| Newsgroups: de.admin.news.misc,de.admin.infos
|
|
| Subject: <Datum> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|
|
|
|
|
| Archive-name: de-admin/entscheidung
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 2013-06-09
|
|
| URL: http://www.kirchwitz.de/~amk/dai/entscheidung
|
|
|
|
Komponenten
|
|
nennt man die einzelnen Bestandteile des /Gruppennamens/, die durch
|
|
Punkte voneinander getrennt sind. Zum Beispiel besteht der Name
|
|
/dana/ aus den Komponenten de, admin, news, announce.
|
|
|
|
Kristallkugel
|
|
heißt ein Werkzeug des Wahrsagehandwerks, welches verlässliche
|
|
Aussagen über die Zukunft ermöglicht. Mancher /dang-Regular/
|
|
behauptet, eine Kristallkugel zu besitzen und mit ihr /Results/ oder
|
|
zukünftigen /Traffic/ präzise abschätzen zu können. Obwohl solche
|
|
Vorhersagen von Seiten erfahrener /dang-Regulars/ durchaus ernst zu
|
|
nehmen sind, können sie die sachliche /Diskussion/ und den
|
|
objektiven /Trafficnachweis/ nicht ersetzen.
|
|
|
|
Kurzbeschreibung
|
|
ist eine sehr knappe Benennung des Themas einer Gruppe, die den
|
|
/Gruppennamen/ ergänzt und von den meisten Newsreadern zusammen mit
|
|
ihm als /Tagline/ angezeigt wird. Sie soll in /de.!alt/ keine
|
|
Umlaute enthalten und mit einem Satzendezeichen aufhören. Oft
|
|
empfiehlt sich ein kurzer, einprägsamer, gern auch witziger
|
|
Sinnspruch.
|
|
|
|
Löschung
|
|
einer Gruppe geschieht durch /rmgroup/. Da manche Newsserver einen
|
|
/rmgroup/ mit starker Verspätung oder nie ausführen, besteht immer
|
|
die Gefahr, dass dort eine /Gruppenleiche/ zurückbleibt. Um dies
|
|
zu vermeiden, werden Gruppen in /de.*/ niemals /auf Verdacht/
|
|
eingerichtet und noch viel zögerlicher gelöscht. Meistens denkt man
|
|
erst dann über eine Löschung nach, wenn der /Traffic/ dauerhaft
|
|
ausnehmend niedrig ist, oft tagelang ganz ausbleibt und wenn Fragen
|
|
in der Gruppe nicht mehr beantwortet werden.
|
|
|
|
Low-Traffic-Gruppe
|
|
nennt man eine Gruppe, deren /Traffic/ weniger als etwa 5 Artikel
|
|
pro Tag beträgt.
|
|
|
|
"[x] make it so"
|
|
ist eine freundliche Zustimmung zu einer Idee, verbunden mit der
|
|
Aufforderung, sie möglichst rasch zu verwirklichen. Adressat dieses
|
|
Zitats ist in /dan*/ meist der /Proponent/. Ursprünglich stammt es
|
|
von Captain Picard aus der Fernsehserie Star Trek.
|
|
|
|
Mindeststimmenzahl
|
|
beträgt in einem /Result/ 50 Jastimmen. Sie soll sicherstellen, dass
|
|
für eine angestrebte Änderung von /de.*/ genügend /Bedarf/ besteht.
|
|
Insbesondere bei der /Einrichtung/ einer neuen Gruppe zeigt das
|
|
Erreichen der Mindeststimmenzahl, dass sich genügend Leute für das
|
|
Thema interessieren, um die neue Gruppe mit lebhaften Diskussionen
|
|
zu füllen.
|
|
|
|
misc-Gruppe
|
|
nennt man eine Gruppe, die auf die /Komponente/ misc endet und alle
|
|
Themen bündelt, die innerhalb ihrer thematischen /Unterhierarchie/
|
|
keine eigene Gruppe haben. In /de.!alt/ werden misc-Gruppen
|
|
zusammen mit ihrer /Unterhierarchie/ ohne weitere Abstimmung
|
|
eingerichtet. Näheres dazu steht in den /Einrichtungsregeln/.
|
|
|
|
Missverständnisse
|
|
treten in /dang/ häufig auf, weil viele Neulinge irrtümlich meinen,
|
|
das /Einrichten/ einer Gruppe zu ihrem Lieblingsthema gehöre zu
|
|
ihren unveräußerlichen Menschenrechten in /de.*/. Warum dem nicht so
|
|
ist, ist in
|
|
|
|
| From: 3.14@piology.org (Boris 'pi' Piwinger)
|
|
| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
|
|
| Subject: <Datum> Missverstaendnisse in de.admin.news.groups
|
|
|
|
|
| Archive-name: de-admin/dang-faq
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 2009-01-24
|
|
| URL: http://www.kirchwitz.de/~amk/dai/dang-faq
|
|
|
|
erklärt.
|
|
|
|
Mitnahmeeffekte
|
|
entstehen, wenn über nicht zusammengehörige Sachfragen in einer
|
|
/Sammelabstimmung/ entschieden wird: Wer sich nur für einen Teil der
|
|
Fragen interessiert, stimmt trotzdem auch beim anderen Teil mit und
|
|
verfälscht damit /Mindeststimmenzahl/ oder /2/3-Mehrheit/. Aus
|
|
diesem Grund sind /Sammelabstimmungen/ im allgemeinen ungeeignet,
|
|
den /Bedarf/ einer Änderung festzustellen.
|
|
|
|
mitwirken
|
|
kann man in /dan*/ in vielfältiger konstruktiver Weise. Einen guten
|
|
Überblick liefert
|
|
|
|
| From: thh@thh.name (Thomas Hochstein)
|
|
| Newsgroups: de.admin.infos,de.soc.usenet
|
|
| Subject: <Datum> Usenet aktiv mitgestalten
|
|
|
|
|
| Archive-name: de-admin/mitgestalten
|
|
| Posting-frequency: weekly
|
|
| Version: 2.0.6
|
|
| Last-modified: 2020-08-24
|
|
| URL: https://th-h.de/archives/faqs/mitgestalten.txt
|
|
| URL: http://www.kirchwitz.de/~amk/dai/mitgestalten
|
|
|
|
Moderation
|
|
heißt ein Kreis von einer oder mehreren Personen, der darüber
|
|
entscheidet, welche zur Veröffentlichung eingereichten Artikel in
|
|
einer /moderierten/ Gruppe erscheinen und welche nicht.
|
|
|
|
In /de.!alt/ wird die jeweilige Moderation gleichzeitig mit der
|
|
/Einrichtung/ der moderierten Gruppe gewählt. Sie kann ihre
|
|
Zusammensetzung anschließend nach eigenem Gutdünken ändern, indem
|
|
sie Mitglieder entlässt, neue ernennt oder per /Nachwahl/ bestimmt.
|
|
Unbeschadet dessen kann eine Moderation auch von Außenstehenden im
|
|
Rahmen einer /Neuwahl/ abgelöst werden.
|
|
|
|
Moderationseid
|
|
nennt man die Selbstverpflichtung der /dana-Moderation/ auf den
|
|
Sinn (und nicht den reinen Wortlaut) der /Einrichtungsregeln/.
|
|
|
|
Moderationskonzept
|
|
nennt man einen Text, in welchem eine /Moderation/ ihre Arbeitsweise
|
|
erklärt. Ein solcher Text gründet auf Vertrauen, ist für niemanden
|
|
verbindlich und kann von der /Moderation/ jederzeit geändert werden.
|
|
Wenn eine /Moderation/ häufig gegen ihr Konzept verstößt und die
|
|
/Netzöffentlichkeit/ brüskiert, läuft sie allerdings Gefahr, durch
|
|
/Neuwahl/ ersetzt zu werden.
|
|
|
|
Das bekannteste Moderationskonzept ist das der /dana-Moderation/. Es
|
|
ist unter <http://www.dana.de/modkonzept.html> zu finden.
|
|
|
|
moderiert
|
|
ist eine Gruppe, wenn Artikel nicht sofort dort erscheinen, sondern
|
|
erst, nachdem die jeweilige /Moderation/ sie /approvet/ hat.
|
|
|
|
Technisch geschieht dies dadurch, dass Dein Newsserver Deinen Artikel
|
|
zunächst nicht im Usenet verbreitet, sondern per E-Mail an die
|
|
/Moderation/ schickt. Falls Du den Artikel gleichzeitig auch an
|
|
/unmoderierte/ Gruppen adressiert hast, wird er auch dort erst
|
|
erscheinen, sobald er /approvet/ ist.
|
|
|
|
Nachwahl
|
|
nennt man eine öffentliche Abstimmung über neue Mitglieder einer
|
|
/Moderation/. Die Initiative geht dabei von der /Moderation/ selbst
|
|
aus. Zum Beispiel veranstaltet die derzeitige /dana-Moderation/
|
|
einmal pro Quartal eine solche Nachwahl in /danm/.
|
|
|
|
Netzöffentlichkeit
|
|
sind theoretisch alle Nutzer von /de.*/. In der Praxis handelt es
|
|
sich jedoch nur um die augenblickliche Leserschaft von /dana/ bzw.
|
|
/daa/.
|
|
|
|
Neuwahl
|
|
nennt man die Ablösung einer /Moderation/ durch eine Nachfolgerin im
|
|
Rahmen einer öffentlichen Abstimmung. Die Initiative geht dabei
|
|
meist von Kritikern außerhalb der /Moderation/ aus. Falls die
|
|
betroffene /moderierte/ Gruppe keine eigenen Wahlregeln kennt,
|
|
werden die /Neuwahlregeln/ der /dana-Moderation/ sinngemäß
|
|
angewendet.
|
|
|
|
Neuwahlregeln
|
|
gelten derzeit sinngemäß für alle /moderierten/ Gruppen in /de.!alt/
|
|
außer /de.answers/ und sind in
|
|
| From: Olaf Schneider <oschneid@mathe.tu-freiberg.de>, Adrian Suter <adrian.suter@schweiz.org>
|
|
| Newsgroups: de.admin.infos,de.admin.news.misc
|
|
| Subject: <Datum> Neuwahl der de.admin.news.announce-Moderation
|
|
|
|
|
| Archive-name: de-admin/dana-neuwahl
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 1998-05-18
|
|
| URL: http://www.kirchwitz.de/~amk/dai/dana-neuwahl
|
|
|
|
veröffentlicht.
|
|
|
|
newgroup (der)
|
|
heißt der /Control/ zum /Einrichten/ einer Gruppe.
|
|
|
|
Nomic
|
|
ist ein Spiel, dessen Ziel erst im Spielverlauf durch Schaffen und
|
|
Verändern von Regeln klar wird und das dementsprechend kompliziert,
|
|
langwierig und für Unerfahrene sinnlos werden kann. Näheres ist in
|
|
<https://de.wikipedia.org/wiki/Nomic> erklärt.
|
|
|
|
nomicen
|
|
nennt man ein Diskussionsverhalten, das durch /Regelfetischismus/
|
|
und Vorliebe für /Richtlinienverfahren/ auffällt. Wer nomict, hat
|
|
den Sinn von /dan*/ nicht verstanden: hier geht es nämlich nicht um
|
|
ein möglichst kontroverses Spiel, sondern um die sinnvolle Pflege
|
|
der /Hierarchie/ /de.*/.
|
|
|
|
PGP (= Pretty Good Privacy; das)
|
|
war das erste weit verbreitete Programm zur Verschlüsselung und
|
|
digitalen Signatur von Daten. Zugleich steht PGP als pars pro toto
|
|
oft für das zugrundeliegende Prinzip an sich, auch wenn heute
|
|
zumeist die freie Version /GPG/ zur Anwendung kommen dürfte.
|
|
Im Usenet werden digitale Signaturen zur Authentifizierung von
|
|
Artikeln und /Controls/ verwendet. Signiert werden normalerweise
|
|
einige ausgewählte Headerzeilen, alternativ dazu notfalls der Body.
|
|
Eine Signatur überprüfen kann man, wenn man über entsprechende
|
|
Software (wie /GPG/) verfügt und den öffentlichen Schlüssel, den
|
|
Public Key, des Autors (bzw. des Signierenden) kennt.
|
|
|
|
Auf <http://www.dana.de/dana-keys.html> stehen die Schlüssel der
|
|
/dana-Moderation/ sowie einige Verweise auf weiterführende Texte zu
|
|
PGP.
|
|
|
|
"+"-Gruppe
|
|
bezeichnet eine Gruppe, in deren Name als letzte /Komponente/ zwei
|
|
miteinander verwandte Themen durch ein Pluszeichen getrennt genannt
|
|
werden. Ein solcher /Gruppenname/ ist meist sehr griffig, birgt
|
|
allerdings die Gefahr, dass die Gruppe mit wachsendem /Traffic/
|
|
irgendwann in ihre beiden Bestandteile zerlegt werden muss, was
|
|
unangenehme /Umbenennungen/ nach sich zieht.
|
|
|
|
Pointer (der, Pl. Pointer)
|
|
nennt man jeden Verweis auf einen /RfD/ oder /CfV/ durch Angabe
|
|
der Message-ID oder der URL aus <http://www.dana.de/status.html>.
|
|
Falls Du Leute, die /dan*/ oder die betroffenen Gruppen nicht lesen,
|
|
auf einen /RfD/ oder /CfV/ aufmerksam machen willst, so sollte dies
|
|
ausschließlich in Form von Pointern geschehen. Zitate aus /RfD/ oder
|
|
/CfV/, insbesondere die Weitergabe des /Wahlscheins/, werden Dir
|
|
sonst leicht als Herankarren von /Stimmvieh/ ausgelegt und können zu
|
|
/Wahlabbruch/ oder erfolgreichen /Einsprüchen/ führen.
|
|
|
|
"Popcorn!"
|
|
ist ein sarkastischer Ausruf wohligen Lesevergnügens, wenn sich eine
|
|
kontroverse /Diskussion/ abzeichnet. Namensgebend ist das Naschwerk,
|
|
welches gern zu abendfüllenden Kinofilmen verzehrt wird. Der Ausruf
|
|
gilt als Warnung, die /Diskussion/ nicht ausufern zu lassen.
|
|
|
|
Prae-RfD (der, Pl. Prae-RfDs)
|
|
ist ein informeller Diskussionsaufruf, der eine Sachfrage zunächst
|
|
nur anreissen soll, um später zu entscheiden, ob ein /RfD/ hierzu
|
|
eingereicht wird. Der Prae-RfD sollte wie ein /RfD/ entweder in
|
|
/dang/ oder in /danm/ veröffentlicht und dort diskutiert werden.
|
|
In anderen Gruppen gelten Prae-RfDs meist als off topic.
|
|
|
|
Prinzip-Nein
|
|
nennt man die Neinstimme eines /dang-Regulars/ in einem /CfV/, wenn
|
|
sie nur aufgrund eines Verstoßes gegen die Gepflogenheiten in /dan*/
|
|
abgegeben wird. Beispiele solcher Verstöße können sein: das
|
|
Nichteinhalten der /Sperrfrist/, unsachliche Diskussionsweise des
|
|
/Proponenten/ oder schroffes Ignorieren von Gegenargumenten. Auch
|
|
verfahrenstechnische Bedenken können ein Prinzip-Nein rechtfertigen.
|
|
|
|
Prinzip-Neins aus reiner Kraftmeierei ohne ernsthafte Gründe sollten
|
|
jedoch unterbleiben, da sie das /Result/ verfälschen.
|
|
|
|
Proponent (der, Pl. Proponenten)
|
|
heißt die Person, welche einen /RfD/ in /dana/ einreicht und damit
|
|
ein /Verfahren/ initiiert. Der Proponent hat innerhalb des
|
|
/Verfahrens/ eine sehr mächtige Stellung, weil er im Rahmen der
|
|
/Einrichtungsregeln/ allein über die Inhalte des /RfD/ und damit
|
|
auch des - vom /Wahlleiter/ verfassten - /CfV/ bestimmt. Als
|
|
Proponent ist es daher wichtig, verantwortungsvoll und überlegt zu
|
|
diskutieren, um der eigenen Sache nicht zu schaden.
|
|
|
|
Ein /Verfahren/ kann auch von mehreren Proponenten gleichzeitig
|
|
getragen werden. Solche Mitproponenten sind im /RfD/ zu erwähnen.
|
|
Die Zusammensetzung der Proponentenschaft darf sich während des
|
|
/Verfahrens/ ändern.
|
|
|
|
proponieren
|
|
heißt, ein /Verfahren/ als /Proponent/ in /dan*/ zu vertreten.
|
|
|
|
"Protest!"
|
|
ist in /daa/ die übliche Form eines informellen Einwands gegen einen
|
|
Vorschlag gemäß Anhang A der /Einrichtungsregeln/.
|
|
|
|
Public checkgroups (der)
|
|
nennt man einen Artikel, der den /checkgroups/ einer /Hierarchie/
|
|
für menschliche Leser auflistet. Ein Public checkgroups für /de.*/
|
|
wird von der /dana-Moderation/ monatlich unter dem Subject: "How to
|
|
add de.ALL" in /dana/ veröffentlicht. Sein Inhalt ist auch über
|
|
<http://www.dana.de/checkgroups.txt> zugänglich.
|
|
|
|
Realname (der, Pl. Realnamen)
|
|
ist eine Kombination aus je mindestens einem ausgeschriebenen
|
|
Personen- und Familiennamen.
|
|
|
|
Recke-Index
|
|
bezeichnet die Anzahl der /Verfahren/, in der eine bestimmte Person
|
|
gleichzeitig /Proponent/ sein kann, ohne aufgrund argumentativer
|
|
Überforderung unsachlich zu werden. Manchmal liegt sie unter 1,
|
|
selten darüber. In <slrn544f8t.1fr.mr94@husemann.in-berlin.de> wurde
|
|
sie erstmals erörtert.
|
|
|
|
Regelfetischismus
|
|
nennt man ein Diskussionsverhalten, welches den Wortlaut der
|
|
/Einrichtungsregeln/ über deren Sinn stellt. Dies führt mitunter zu
|
|
unnötigen Spitzfindigkeiten sowie ungerechtfertigten /Prinzip-Neins/
|
|
und sollte daher unterbleiben.
|
|
|
|
Regeltexte
|
|
für /de.*/ sind die /Einrichtungsregeln/, die /Neuwahlregeln/ und
|
|
die Regeln für /Gruppennamen/. Sie haben im Gegensatz zu allen
|
|
anderen regelmäßig erscheinenden Texten in /de.*/ verbindlichen
|
|
Charakter.
|
|
|
|
rejecten (engl. "to reject")
|
|
heißt, einen zur Veröffentlichung in einer /moderierten/ Gruppe
|
|
eingereichten Artikel abzulehnen. Dies ist Aufgabe der jeweiligen
|
|
/Moderation/.
|
|
|
|
Wer der Meinung ist, dass seine Artikel von einer /Moderation/
|
|
ungerechtfertigt abgelehnt wurden, kann sich in /danm/ darüber
|
|
beschweren und schlimmstenfalls eine /Neuwahl/ einleiten, falls
|
|
keine Einigung erzielt wird.
|
|
|
|
Rekord
|
|
ist ein /Result/, welches klarer oder knapper als alle bisherigen in
|
|
der Geschichte von /dan*/ ist. Eine Aufstellung der Rekorde ist auf
|
|
<https://web.archive.org/web/20061223204051/http://usenet.babylonsounds.com/rekorde.html>
|
|
zu finden.
|
|
|
|
Reorganisation
|
|
nennt man die Umgestaltung einer oder mehrerer /Unterhierarchien/.
|
|
Sie besteht meist aus mehreren /Umbenennungen/, manchmal auch
|
|
einigen /Löschungen/ oder /Einrichtungen/ neuer Gruppen. Eine
|
|
Reorganisation ist sehr aufwendig und kompliziert und erfordert
|
|
häufig eine /Sammelabstimmung/ mit einigen /weiteren Regeln/.
|
|
|
|
Result (das, Pl. Results)
|
|
ist das Ergebnis einer Abstimmung. Es wird wie der /CfV/ in /dana/
|
|
sowie in allen von der Sachfrage betroffenen Gruppen veröffentlicht
|
|
und benennt zu jedem Wähler dessen /Realname/, E-Mailadresse und
|
|
Stimmverhalten, sofern er nicht /anonym/ abgestimmt hat.
|
|
|
|
Die Sachfrage gilt als angenommen, wenn im Result /2/3-Mehrheit/ und
|
|
/Mindeststimmenzahl/ erreicht sind.
|
|
|
|
RFC (= Request for Comments; der, Pl. RFCs)
|
|
sind seit 1969 fortlaufend numerierte technische Dokumente zur
|
|
Diskussion und Standardisierung von Internet- und internetbezogenen
|
|
Diensten. Sie bilden die technische und organisatorische Grundlage
|
|
für den Datenaustausch im Netz und werden bei Bedarf überarbeitet,
|
|
wobei dann ein neuer RFC den technischen Standard (STD) oder den
|
|
derzeitigen Konsens (BCP, best current practice) wiedergibt.
|
|
|
|
So beschreibt derzeit RFC 5322 den grundsätzlichen Aufbau von
|
|
E-Mail-Nachrichten, worauf RFC 5536 mit der Beschreibung des
|
|
Aufbaus von Usenet-Postings aufbaut. Zusammen mit RFC 5537, der
|
|
das grundsätzliche Zusammenspiel der Usenet-Protokolle und die
|
|
zugrundeliegende Architektur beschreibt, und RFC 3977, der das
|
|
Protokoll für den Datenaustausch zwischen Newsservern untereinander
|
|
und mit Newsreadern beschreibt, bilden diese drei RFCs das
|
|
technische Grundgerüst des Usenets.
|
|
|
|
RfD (= Request for Discussion; der, Pl. RfDs)
|
|
nennt man einen formellen Diskussionsaufruf, der in /dana/ und allen
|
|
von der Sachfrage betroffenen Gruppen veröffentlicht wird. Die
|
|
/Diskussion/ selbst findet statt
|
|
|
|
* in /dang/, falls es um /Einrichtung/ oder /Löschung/ einer
|
|
Gruppe oder um die Änderung von /Gruppenname/,
|
|
/Kurzbeschreibung/, /Charta/ oder /Status/ geht;
|
|
* in /danm/, falls es sich um ein /Richtlinienverfahren/ handelt
|
|
oder die /Moderation/ einer Gruppe neu besetzt
|
|
werden soll;
|
|
|
|
Der 1. RfD leitet die /Diskussion/ ein; eventuelle Änderungen und
|
|
Verfeinerungen des Diskussionsgegenstandes werden in weiteren
|
|
durchnumerierten RfDs bekanntgegeben.
|
|
|
|
Wer noch nie einen RfD veröffentlicht hat, sollte unbedingt das
|
|
/dana-Manual/ studieren und ggf. zur Erstellung des 1. RfD das
|
|
Skript <http://piology.org/cgi-bin/rfd.pl> benutzen, damit auch alle
|
|
formalen Anforderungen von /dana/ erfüllt sind. Weitere Einzelheiten
|
|
hierzu stehen in den /Einrichtungsregeln/.
|
|
|
|
RfD-Howto (das)
|
|
<https://web.archive.org/web/20070105012315/http://usenet.babylonsounds.com/rfd_howto.html>
|
|
ist eine kurze Anleitung, wie man einen guten /RfD/ zur /Einrichtung/
|
|
einer Gruppe verfasst.
|
|
|
|
"[x] RfD now!"
|
|
ist eine knappe Aufforderung, die /Diskussion/ eines /Prae-RfD/ zu
|
|
beenden und ein formelles /Verfahren/ zu beginnen. Der Grund hierfür
|
|
ist meist, dass tatsächlicher /Bedarf/ an der Sachfrage zu bestehen
|
|
scheint.
|
|
|
|
Richtlinienverfahren
|
|
nennt man ein /Verfahren/, das die Einführung, Änderung oder
|
|
Abschaffung von /Regeltexten/ für /de.*/ zum Gegenstand hat. Solche
|
|
/Verfahren/ finden in /danm/ statt.
|
|
|
|
rmgroup (der)
|
|
heißt der /Control/ zum /Löschen/ einer Gruppe.
|
|
|
|
Sammelabstimmung
|
|
nennt man einen /CfV/, der gleichzeitig über mehrere Sachfragen
|
|
entscheiden lässt. Wegen der zu befürchtenden Komplikationen und
|
|
/Mitnahmeeffekte/ ist eine Sammelabstimmung nur in drei Fällen
|
|
anzuraten: zum einen, wenn mehrere /Attribute/ einer bestehenden
|
|
Gruppe geändert werden sollen; zum zweiten, wenn eine Gruppe in
|
|
eine /Unterhierarchie/ aufgespalten werden soll; zum dritten, wenn
|
|
die /Reorganisation/ einer oder mehrerer /Unterhierarchien/ ansteht.
|
|
|
|
Falls in einer bestehenden /Unterhierarchie/ mehrere neue Gruppen
|
|
eingerichtet werden sollen, empfehlen sich hierfür getrennte
|
|
/Verfahren/. Näheres steht in den /Einrichtungsregeln/.
|
|
|
|
Scheintraffic (der)
|
|
ist ein abschätziger Name für /Traffic/, der eigens für ein
|
|
/Verfahren/ erzeugt wird, um einen /Trafficnachweis/ zu schönen. Der
|
|
Verdacht, dass Scheintraffic im Spiel ist, kommt vor allem bei
|
|
/Fuchsschwänzen/ leicht auf.
|
|
|
|
Schlamassel (der, Pl. Schlamassel)
|
|
heißt ein /Result/, welches so unpopulär ist, dass niemand dessen
|
|
/Umsetzung/ wünscht. So etwas ist nur bei einer missglückten
|
|
/Sammelabstimmung/ denkbar und kam bisher allein im /Verfahren/ zu
|
|
/dcsa/ vor. Namensgebend hierfür war der Einspruchsentscheid
|
|
<dcsa-schlamassel-entscheid-Fri-25-Aug-00-1.jonas@dana.de>.
|
|
|
|
6a-Verfahren
|
|
nennt man einen /CfV/, der keinen /Wahlschein/ enthält, sondern nur
|
|
beschreibt, wie man ihn personalisiert beim /Wahlleiter/ anfordert.
|
|
Sinn dieser Vorgehensweise ist, Manipulationen der Abstimmung zu
|
|
erschweren. Sie wird angewendet, wenn in einem /Verfahren/
|
|
Misstrauen aufgekommen ist. Näheres erläutern Punkt 6a der
|
|
/Einrichtungsregeln/ und Abschnitt 4.3 des /dana-Manuals/.
|
|
|
|
Second-Level-Hierarchie
|
|
/Hierarchie/ zweiten Grades.
|
|
|
|
Segment
|
|
/Komponente/.
|
|
|
|
"Show traffic, get group!"
|
|
ist ein Grundsatz, nach dem viele /Verfahren/ ablaufen. Die zentrale
|
|
Frage ist dabei, ob ein überzeugender /Trafficnachweis/ geführt
|
|
wird.
|
|
|
|
SLH
|
|
/Second-Level-Hierarchie/.
|
|
|
|
Sonderregel
|
|
/weitere Regel/.
|
|
|
|
Sperrfrist
|
|
nennt man die Gepflogenheit in /dan*/, über eine Sachfrage
|
|
frühestens sechs Monate nach dem /Result/ erneut abzustimmen. Wer
|
|
als /Proponent/ die Sperrfrist verletzt, erntet hierfür oft viele
|
|
/Prinzip-Neins/.
|
|
|
|
Status (der, Pl. Status)
|
|
nennt man die Eigenschaft einer Gruppe, /moderiert/ oder
|
|
/unmoderiert/ zu sein.
|
|
|
|
Statusverwalter
|
|
heißt dasjenige Mitglied der derzeitigen /dana-Moderation/, welches
|
|
den /dana-Status/ pflegt und die Arbeit der /Verfahrensbetreuer/
|
|
koordiniert.
|
|
|
|
Steuernachricht
|
|
/Control/.
|
|
|
|
Stimmvieh
|
|
werden Leute genannt, die in einem /CfV/ abstimmen, obwohl sie kein
|
|
konkretes, persönliches, usenetinternes Interesse am
|
|
Abstimmungsgegenstand haben. Dazu zählen insbesondere auch Freunde
|
|
und Verwandte von Interessierten, die ihrerseits nicht im Usenet
|
|
aktiv sind. Solche Stimmen stören das /Result/ beträchtlich und
|
|
können Anlass für einen /Wahlabbruch/ oder einen erfolgreichen
|
|
/Einspruch/ sein.
|
|
|
|
Strawpoll (der, Pl. Strawpolls)
|
|
ist eine informelle Abstimmung über eine Sachfrage. Häufig findet
|
|
er während der /Diskussion/ eines /RfD/ statt, um einen Streitpunkt
|
|
zu klären, zu welchem sich kein klarer Konsens abzeichnet. Er wird
|
|
von einem /Wahlleiter/ analog zu einem formellen /CfV/ veranstaltet
|
|
und ausgewertet und mit Unterstützung der /dana-Moderation/ oft auch
|
|
in /dana/ veröffentlicht. Die Stimmfrist ist meist etwas kürzer und
|
|
die Beteiligung geringer als bei einem /CfV/. Näheres ist in
|
|
|
|
| From: Ralf Döblitz <faq@netzverwaltung.net>
|
|
| Newsgroups: de.admin.news.misc,de.admin.infos
|
|
| Subject: <Datum> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|
|
|
|
|
| Archive-name: de-admin/entscheidung
|
|
| Posting-frequency: weekly
|
|
| Last-modified: 2013-06-09
|
|
| URL: http://www.kirchwitz.de/~amk/dai/entscheidung
|
|
|
|
erläutert.
|
|
|
|
Subhierarchie
|
|
/Unterhierarchie/.
|
|
|
|
Sympathie-Ja
|
|
nennt man eine Jastimme in einem /CfV/, die nicht aus persönlichem
|
|
Interesse an der Sache abgegeben wird. Solche Jastimmen stören die
|
|
Entscheidungen in /dan*/, weil sie den Nachweis des /Bedarfs/
|
|
verfälschen; sie sollten daher nach Möglichkeit unterbleiben.
|
|
|
|
[Tag] (das, Pl. [Tags])
|
|
nennt man ein Kürzel, welches man an den Anfang des Subject:-Headers
|
|
stellt, um den Artikel innerhalb einer Gruppe einem Unterthema
|
|
zuzuordnen. Wenn [Tags] konsequent verwendet werden, wird die Gruppe
|
|
deutlich lesbarer, weil jeder mühelos diejenigen Unterthemen
|
|
herausfiltern kann, für die er sich besonders interessiert. Viele
|
|
/Chartas/ in /de.*/ empfehlen [Tags] oder schreiben sie sogar vor.
|
|
|
|
Tagline (die, Pl. Taglines)
|
|
heißt die Spezifikation einer Gruppe auf dem Newsserver. Sie besteht
|
|
aus einer einzigen Zeile und wird auch von den meisten Newsreadern
|
|
dargestellt. Ihr Aufbau lautet: /Gruppenname/ + 8er-Tabulator +
|
|
/Kurzbeschreibung/. Wenn die Gruppe /moderiert/ ist, kommt in /de.*/
|
|
hinzu: " " + <E-Mail-Adresse der /Moderation/> + " (Moderated)".
|
|
|
|
Die /Einrichtungsregeln/ erwarten, dass /Gruppenname/, Tabulator und
|
|
/Kurzbeschreibung/ zusammen kürzer als 80 Zeichen sind, damit die
|
|
Tagline sowohl im /Public checkgroups/ als auch im Newsreader
|
|
übersichtlich dargestellt werden kann.
|
|
|
|
talk-Gruppe
|
|
nennt man eine Gruppe, in der ein festgelegtes Thema im Plauderton
|
|
behandelt wird. Eine talk-Gruppe ist üblicherweise /unmoderiert/ und
|
|
steht innerhalb von /de.*/ in einer der /Unterhierarchien/ de.talk.*
|
|
oder de.alt.talk.*. Ein /CfV/ zur /Einrichtung/ einer talk-Gruppe
|
|
außerhalb von de.talk ruft meist zahlreiche /Prinzip-Neins/ hervor,
|
|
kann aber dennoch erfolgreich sein.
|
|
|
|
Themenorientierung
|
|
bedeutet, dass Gruppen in /de.*/ für Themen und nicht für Personen
|
|
oder Personenkreise eingerichtet werden. Das heißt insbesondere, dass
|
|
Diskussionen, die in ihrem Verlauf ihr Thema wesentlich wechseln, in
|
|
einer anderen, passenderen Gruppe weiterzuführen sind.
|
|
|
|
Third-Level-Hierarchie
|
|
/Hierarchie/ dritten Grades.
|
|
|
|
tief
|
|
nennt man die Einordnung einer Gruppe, wenn der /Gruppenname/ aus
|
|
vielen /Komponenten/ besteht. Zum Beispiel ist die Gruppe
|
|
de.comp.os.unix.apps.kde tief eingeordnet, weil ihr Thema sehr
|
|
speziell ist.
|
|
|
|
TLH
|
|
/Top-Level-Hierarchie/.
|
|
|
|
Top-Level-Hierarchie
|
|
/Hierarchie/ ersten Grades.
|
|
|
|
Traffic (der)
|
|
nennt man zum einen den Nutzungsgrad einer Gruppe. Er wird meist in
|
|
Artikeln pro Tag oder Artikeln pro Monat gemessen, wobei
|
|
üblicherweise nur solche Artikel zählen, die in der Gruppe on topic
|
|
sind. Zum anderen bezeichnet man in gleicher Weise auch den gesamten
|
|
Schriftverkehr zu einem bestimmten Thema als Traffic, selbst wenn er
|
|
über mehrere benachbarte Gruppen verteilt ist oder außerhalb des
|
|
Usenets (zum Beispiel auf einer Mailingliste) stattfindet.
|
|
|
|
Trafficnachweis
|
|
nennt man eine Aufstellung des /Traffics/ zu einem bestimmten Thema
|
|
über einen gewissen Zeitraum (meist drei Monate oder mehr). Ein
|
|
solcher Nachweis wird für /Verfahren/ in /de.alt/ benötigt, da
|
|
/Traffic/ dort das Hauptargument zur /Einrichtung/ von Gruppen ist.
|
|
In /de.!alt/ dient zwar schon die /Mindeststimmenzahl/ dazu, den
|
|
/Bedarf/ zu belegen. Dennoch ist ein formeller Trafficnachweis im
|
|
/RfD/ oder während der /Diskussion/ auch hier gern gesehen. Wer
|
|
glaubt, der Trafficfrage gänzlich ausweichen zu können, erliegt
|
|
einem schweren /Missverständnis/.
|
|
|
|
Falls zu einem Thema /umzugswilliger/ /Traffic/ im Umfang von
|
|
täglich mehr als 10 bis 15 Artikeln existiert, ist es sinnvoll,
|
|
hierfür eine eigene Gruppe in /de.*/ einzurichten. Warum manchmal
|
|
auch schon etwas weniger genügt, wird ausführlich erläutert in
|
|
<a505k0$39kc2$2@ID-807.news.dfncis.de>.
|
|
|
|
Damit ein Trafficnachweis einfach erstellt und überprüft werden
|
|
kann, empfiehlt es sich, bereits einige Monate vor Beginn des
|
|
/Verfahrens/ ein /[Tag]/ zum betreffenden Thema einzuführen und
|
|
konsequent zu verwenden.
|
|
|
|
Übersichtlichkeit
|
|
bedeutet, dass Gruppen in /de.*/ aussagekräftig benannt und sinnvoll
|
|
in /Unterhierarchien/ eingeordnet werden sollen. Außerdem ist darauf
|
|
zu achten, dass die einzelnen Gruppen weder ausnehmend wenig noch
|
|
unangemessen viel /Traffic/ enthalten.
|
|
|
|
Übertragungsverbot
|
|
nennt man die Bestimmung der /Einrichtungsregeln/, dass eine Stimme
|
|
nur für genau den Vorschlag gilt, für welchen sie abgegeben wurde.
|
|
Das heißt, dass Stimmen für oder gegen eine bestimmte Gruppe nicht
|
|
gleichzeitig auch Änderungen an anderen Gruppen bewirken sollen.
|
|
|
|
Manchmal kann es sinnvoll sein, von diesem Verbot durch eine
|
|
/weitere Regel/ eine Ausnahme zu machen, zum Beispiel, wenn bei
|
|
/Einrichtung/ einer Gruppe die /Charta/ einer anderen Gruppe in
|
|
einem unstrittigen Detail angepasst werden soll.
|
|
|
|
Umbenennung
|
|
einer Gruppe geschieht durch /rmgroup/ und anschließenden
|
|
/newgroup/. Damit besteht wie beim /Löschen/ die Gefahr, auf vielen
|
|
Newsservern eine /Gruppenleiche/ zu hinterlassen. Deshalb ist man in
|
|
/de.*/ Umbenennungen gegenüber kritisch eingestellt und unterstützt
|
|
solche /Verfahren/ nur, wenn eine /Unterhierarchie/ dadurch deutlich
|
|
übersichtlicher wird.
|
|
|
|
Umsetzung
|
|
besteht darin, die Entscheidung eines /Verfahrens/ wirksam zu
|
|
machen. Bei Änderungen der Gruppenstruktur geschieht dies durch
|
|
Versenden der /Controls/, bei neuen /Chartas/ durch Veröffentlichung
|
|
in den betroffenen Gruppen, bei /Richtlinienverfahren/ durch
|
|
Anpassung und Veröffentlichung der einschlägigen /Regeltexte/.
|
|
|
|
Falls ein /Verfahren/ scheitert, findet keine Umsetzung statt.
|
|
|
|
Umsetzungsbeauftragter
|
|
heißt dasjenige Mitglied der derzeitigen /dana-Moderation/, welches
|
|
für die /Umsetzung/ jedes erfolgreich verlaufenen /Verfahrens/ in
|
|
/de.!alt/ sorgt.
|
|
|
|
umzugswillig
|
|
nennt man den /Traffic/ zu einem Thema, wenn seine häufigsten
|
|
Autoren bereit sind, hierfür in Zukunft eine andere, meist neu zu
|
|
gründende Gruppe zu nutzen. Umzugswilligkeit wird vor allem dann
|
|
sehr kritisch hinterfragt, wenn der /Traffic/ bisher außerhalb des
|
|
Usenets stattfindet.
|
|
|
|
unmoderiert
|
|
ist eine Gruppe, wenn Artikel in ihr sofort auf dem Newsserver
|
|
erscheinen und ins Usenet eingespeist werden. Dies ist der übliche
|
|
/Status/ von Gruppen.
|
|
|
|
Unterhierarchie
|
|
nennt man eine /Hierarchie/ zweiten oder höheren Grades.
|
|
|
|
Verfahren
|
|
nennt man den gesamten Prozess, mit dem eine Sachfrage in /de.*/ zu
|
|
einer Entscheidung geführt wird.
|
|
|
|
In /de.!alt/ umfasst ein Verfahren einen oder mehrere /RfDs/, die
|
|
/Diskussion/, zwei /CfVs/ und ein /Result/, gegen welches unter
|
|
Umständen noch /Einsprüche/ eingereicht werden können, sowie die
|
|
anschließende /Umsetzung/. Bei guter Vorbereitung des /Proponenten/
|
|
dauert das Verfahren acht bis zehn Wochen; unter widrigen Umständen
|
|
können auch einige Monate vergehen.
|
|
|
|
In /de.alt/ besteht ein Verfahren aus einem Vorschlag in /daa/,
|
|
einer Debatte darüber und der anschließenden /Umsetzung/. Falls der
|
|
Vorschlag unstrittig ist, dauert das Verfahren gut eine Woche; bei
|
|
mehrfachem /"Protest!"/ können weitere Wochen vergehen.
|
|
|
|
Die genaue Vorgehensweise erläutern die /Einrichtungsregeln/ und das
|
|
/dana-Manual/.
|
|
|
|
Verfahrensbetreuer
|
|
heißen diejenigen Mitglieder der derzeitigen /dana-Moderation/,
|
|
welche die vom /Proponenten/ bzw. /Wahlleiter/ eingereichten /RfDs/,
|
|
/CfVs/ und /Results/ gegenlesen, zur Nachbesserung zurückschicken
|
|
und schließlich veröffentlichen. Oft sind einige E-Mailwechsel mit
|
|
dem jeweiligen Verfahrensbetreuer nötig, bis ein Text reif zur
|
|
Veröffentlichung ist.
|
|
|
|
Verknüpfungsverbot
|
|
nennt man die Bestimmung der /Einrichtungsregeln/, dass über jede
|
|
Gruppe einzeln abzustimmen ist. Sie besagt, dass zwischen mehreren
|
|
im Rahmen einer /Sammelabstimmung/ behandelten Gruppen keine
|
|
stimmtechnischen Abhängigkeiten bestehen sollen.
|
|
|
|
In einigen seltenen Fällen, zum Beispiel bei einer /Reorganisation/,
|
|
kann es sinnvoll sein, von diesem Verbot durch eine /weitere Regel/
|
|
eine Ausnahme zu machen.
|
|
|
|
Vollständigkeit
|
|
bedeutet, dass es innerhalb von /de.*/ zu jedem nur denkbaren Thema
|
|
eine passende Gruppe gibt. Welche das im Einzelfall ist, kannst Du
|
|
den /Chartas/ entnehmen oder in der Gruppe de.newusers.questions
|
|
erfragen.
|
|
|
|
Die Vollständigkeit von /de.*/ wird durch die /misc-Gruppen/,
|
|
insbesondere durch /de.etc.misc/, sichergestellt.
|
|
|
|
Votetaker
|
|
/Wahlleiter/
|
|
|
|
VV (= vereinfachtes Verfahren; das)
|
|
heißt der Versuch, eine Sachfrage ohne /Diskussion/ und Abstimmung
|
|
zu entscheiden. Das ist meist nur dann sinnvoll, wenn es um kleine
|
|
Änderungen an einer /Charta/ oder /Kurzbeschreibung/ geht.
|
|
|
|
Ein VV wird wie ein /RfD/ in /dana/ und allen betroffenen Gruppen
|
|
veröffentlicht. Falls aus der /Netzöffentlichkeit/ kein Widerspruch
|
|
bei der /dana-Moderation/ eingeht, gilt das VV als erfolgreich.
|
|
Näheres hierzu steht in den /Einrichtungsregeln/.
|
|
|
|
Wahlabbruch
|
|
heißt die Entscheidung des /Wahlleiters/, einen /CfV/ nicht weiter
|
|
auszuwerten, sondern die Abstimmung ohne Ergebnis zu beenden. Dies
|
|
geschieht, wenn es im Abstimmungsverlauf zu Unregelmäßigkeiten
|
|
gekommen ist. Näheres erklären die /Einrichtungsregeln/.
|
|
|
|
wahlberechtigt
|
|
ist in /dan*/, wer eine eigene E-Mailadresse hat und gegenüber dem
|
|
/Wahlleiter/ seinen /Realnamen/ angibt. Von jedem Wähler wird jedoch
|
|
erwartet, dass er nur dann einen /Wahlschein/ abschickt, wenn er ein
|
|
konkretes, persönliches, usenet-internes Interesse am
|
|
Abstimmungsgegenstand hat.
|
|
|
|
Wahlleiter
|
|
oder auch /Votetaker/ heißt die Person, welche die auf den /CfV/
|
|
folgende Abstimmung auswertet (weshalb "Abstimmungsleiter" wohl
|
|
der treffendere Begriff wäre, der sich aber nicht eingebürgert
|
|
hat).
|
|
|
|
Ursprünglich wurde allgemein erwartet, dass der /Proponent/ dies
|
|
selbst tut. Da die meisten Proponenten dazu aus zeitlichen oder vor
|
|
allem auch technischen Gründen nicht in der Lage sind, hat es sich
|
|
mittlerweile eingebürgert, dass die Durchführung der Abstimmungen
|
|
durch Dritte, meistens die /GVV/, erfolgt. Es kann sich auch
|
|
anbieten, die Abstimmung aus anderen Gründen nicht selbst
|
|
durchzuführen, wenn man bspw. als /Proponent/ in /dan*/ nicht
|
|
ausreichend Vertrauen genießt oder prophylaktisch den Vorwurf der
|
|
Manipulation vermeiden möchte.
|
|
|
|
Wahlschein
|
|
ist derjenige Bestandteil eines /CfV/, in welchen der Wähler seine
|
|
Entscheidung eintragen kann, also quasi der Stimmzettel. Meist wird
|
|
der Wahlschein mit dem /CfV/ mitgeliefert; eine Ausnahme hiervon ist
|
|
das /6a-Verfahren/. Den Wahlschein sollte man sorgfältig abtrennen
|
|
und sauber mit JA, NEIN oder ENTHALTUNG ausfüllen, um dem
|
|
/Wahlleiter/ möglichst wenig Arbeit zu machen. Einzusenden ist er
|
|
per E-Mail an die jeweils angegebene Abstimmadresse.
|
|
|
|
weiße T-Shirts
|
|
sind ein gern genanntes Beispiel eines Allerweltsthemas, für welches
|
|
man trotz seiner großen Verbreitung keine eigene Gruppe braucht,
|
|
weil einfach niemand darüber diskutiert. Wer für ein solches
|
|
Allerweltsthema dennoch eine Gruppe einrichten will, erliegt einem
|
|
/Missverständnis/. Weiße T-Shirts taugen allenfalls für einen
|
|
/Aprilscherz/ wie <RfD-1-de.rec.weisse-tshirts-01.04.1998@dana.de>.
|
|
|
|
weitere Regel
|
|
nennt man jede Bestimmung im /CfV/, welche inhaltlich von den
|
|
üblichen /Einrichtungsregeln/ abweicht. Eine solche Zusatzregelung
|
|
sollte man nur in Ausnahmefällen und dann in enger Absprache mit der
|
|
/dana-Moderation/ treffen. Sie muss im letzten /RfD/ erwähnt werden.
|
|
|
|
Zotty-Traffic (der)
|
|
nennt man /Scheintraffic/, der als Reaktion auf einen /RfD/ zur
|
|
/Löschung/ einer Gruppe erzeugt wird. Namensgebend waren die vielen
|
|
vergeblichen Versuche, die Gruppe de.alt.zotty.answers zu löschen.
|
|
|
|
2/3-Mehrheit
|
|
der Stimmen ist in einem /Result/ nötig, um eine Entscheidung
|
|
durchzusetzen. Das heißt, dass mindestens doppelt so viele Jastimmen
|
|
wie Neinstimmen beim /Wahlleiter/ eingehen müssen. Der Grund für
|
|
diese strenge Quote ist, dass der augenblickliche Zustand von /de.*/
|
|
stets Bestandsschutz genießt und nur dann geändert werden soll, wenn
|
|
ein deutlicher /Bedarf/ dafür besteht.
|
|
|
|
***
|
|
|
|
Maintainer dieser FAQ: Thomas Hochstein <thh@thh.name>
|
|
|
|
Das dan-Glossar wurde im August 2014 überarbeitet. Weitere
|
|
Änderungen und/oder Ergänzungen werden gerne entgegengenommen.
|
|
|
|
Das Glossar ist auch in einem Git-Repository unter
|
|
<https://code.th-h.de/?p=faqs/dan-glossar.git> verfügbar und kann
|
|
über die Weboberfläche eingesehen oder via "git clone" ausgecheckt
|
|
werden. Bei Änderungsvorschlägen sind Git-Patches am einfachsten zu
|
|
verarbeiten; natürlich wird aber auch jede andere Form von Anregungen
|
|
gerne entgegengenommen.
|
|
|
|
Autor und Maintainer bis 2014: Bernd Gramlich
|
|
|
|
Idee, Ton und der Großteil des Textes dieser FAQ stammen vom
|
|
ursprünglichen Autor und Betreuer, Bernd Gramlich. Spätere
|
|
Anpassungen wurden möglichst behutsam eingearbeitet.
|
|
|
|
Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
|
|
haben außerdem beigetragen:
|
|
|
|
- Ludwig Boeckel
|
|
- Marc 'HE' Brockschmidt
|
|
- Michael Dahms
|
|
- Oliver Ding
|
|
- Frank Ellermann
|
|
- Karsten Huppert
|
|
- Gerhard Jahnke
|
|
- Wolfgang Jäth
|
|
- Dirk Nimmich
|
|
- Michael Ottenbruch
|
|
- Simon Paquet
|
|
- Christian Pree
|
|
- Stefan Ram
|
|
- Nikolaus Rath
|
|
- Andreas Riedel
|
|
- Kai-Olaf Runge
|
|
- Olaf Schneider
|
|
- Adrian Suter
|
|
- Uwe Tetzlaff
|
|
- Felix Wiemann
|
|
|
|
Herzlichen Dank!
|
|
--
|
|
Id: $Format:%t %d %ai %an$
|