Approved: moderator@dana.de Newsgroups: de.admin.news.announce Followup-To: de.admin.news.misc Sender: jonas@netwarriors.org Date: Thu, 27 Jul 2000 15:44:54 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable User-Agent: modpost2.1-loki Organization: Moderation von d.a.n.a From: Adrian Suter Subject: Einspruch zur Reorganisation de.comm.software.* References: X-PGP-Sig: 2.6.3i Approved,Newsgroups,Followup-To,Sender,Date,Message-ID,From,Subject iQCVAwUBOX/o94GLvASULeRFAQG5HwP8Du/EAaVVCFaPlAIautne93A2E5jc2hz7 RXWuTVN4uZlzMyN6TGs9bITm+7ol8+uqKNnxMa7d9C2iAQWnWWR2DGoaBCCOa+DY vZy94le7vuLAuKVWummc3Op6EJmiJ0xvUy4gGnWIuGZkb0LXsXbbxsZ723j6a0g3 kOZTVtDS1/g= =rwIC Path: news.t-online.com!newsmm00.btx.dtag.de!newsfeed01.sul.t-online.de!t-online.de!unlisys!news.snafu.de!wuff.inx.de!loki.netwarriors.org!netwarriors.org!loki Lines: 222 Xref: news.t-online.com de.admin.news.announce:3501 Hiermit erhebe ich Einspruch ========= gegen das Result zur Reorganisation der Hierarchie de.comm.software.* (vgl. ), und beantrage Annullierung und Nicht-Umsetzung des Ergebnisses. Begründung Bei der Gestaltung des Wahlscheins ist es zu Unsorgfältigkeiten gekommen, die geeignet sind, das Abstimmungsergebnis zu verfälschen. Das jetzt vorliegende Ergebnis spiegelt aufgrund des unglücklich gewählten Verfahrens nicht die Mehrheitsmeinung wider. Die Kritikpunkte sind im einzelnen die folgenden: 1) Vereinsamte misc-Gruppe ~~~~~~~~~~~~~~~~~~~~~~~~~~ Die Gruppe de.comm.software.client.mail.misc ist in der durch das Result vorgesehenen Struktur vereinsamt: es gibt keine andere Hierarchie in dieser Gruppe. Ausserdem fehlt in der Hierarchie de.comm.software.mailreader.* in der durch das Result vorgesehenen Struktur die misc-Gruppe. Dies ist eine Inkonsistenz, die zumindest dem Geist der folgenden Regel widerspricht: | .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie -- | sei es durch Umwandlung einer bestehenden Gruppe oder durch | Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc | endende Gruppe eingerichtet. Der zur Gründung der Hierarchie | führende RfD hat hierzu die notwendigen Angaben bereitzustellen. | Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so | findet hierüber eine normale Abstimmung statt. 2) Verzerrung des Wählerwillens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dieser Umstand ist ganz offensichtlich nicht der Wille der Mehrheit der Abstimmenden. Betrachtet man die Stimmabgaben zu dcs.client.mail.pegasus und dcs.client.mail.misc, so ist festzustellen, dass die überwältigende Mehrheit mit JJ oder NN gestimmt hat, d.h. sich dahingehend geäussert hat, dass die beiden Gruppen in die gleiche Hierarchie verschoben (JJ) oder in der gleichen Hierarchie verbleiben (NN) sollen. Das Argument "die Mehrheit wollte eine solche Struktur" sticht also nicht. Die Überwältigende Mehrheit wollte gerade nicht eine Aufteilung der Mailclients auf zwei Unterhierarchien. Nur über ie Frage, in welche von zwei möglichen Hierarchien die Mailclient-Gruppen eingeordnet werden sollen, herrschte Uneinigkeit, die bei den beiden betroffenen Gruppen jeweils mit einem Zufallmehr in die eine bzw. andere Richtung entschieden worden ist. Der Wahlschein hat somit den Wählerwillen verzerrt, indem trotz grosser Mehrheit für eine gemeinsame Einordnung der beiden Mailclient-Gruppen eine getrennte Einordnung herausgekommen ist. 3) Trennung der Webbrowser- und Webserver-Gruppen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In der neuen Struktur, wie sie das Result vorsieht, sind die Gruppen für Webbrowser und Webserver in unterschiedlichen Hierarchien eingeordnet: dciw.browsers und dcss.web. Diese Inkonsistenz ist nicht gleich massiv wie die unter 1) genannte, trotzdem ist es eine, die (nach zugegeben flüchtiger Durchsicht des Ergebnisses) ebenfalls nicht dem Wählerwillen zu entsprechen scheint. Auch hier hat eine grosse Mehrheit mit JJ oder NN gestimmt, war also der Meinung, die beiden Gruppen würden in die gleiche Hierarchie gehören. Durch den Abstimmungsmodus wurde also auch hier der Wählerwille verfälscht. 4) Einordnung der Server-Gruppen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In weiteren Punkten hätte es leicht zu weiteren Inkonsistenzen kommen können, diese wurden aber durch z.T. geringe Mehrheiten vermieden. So hätte es zum Beispiel leicht geschehen können, dass zwar dcs.mailserver in eine neue Hierarchie dcs.server.* verschoben wird, dcs.newsserver hingegen nicht. Oder die Hamstergruppe hätte leicht auch ausserhalb der neu geschaffenen dcs.server.*-Hierarchie eingerichtet werden können. Auch hier zeigt eine (wiederum oberflächliche) Betrachtung des Ergebnisses, dass die Mehrheit der Abstimmenden bei den entsprechenden Gruppen gleich abgestimmt hat, d.h. keine Aufsplitterung der Serversoftware auf dcs.server.* und direkt unter dcs.* wollte. 5) Vorgängige Hinweise auf möglicherweise inkonsistente Ergebnisse ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Es wurde in der Diskussionsphase mehrfach und von verschiedenen Diskussionsteilnehmern auf die möglichen inkonsistenten Ergebnisse hingewiesen. Es ist möglich und wahrscheinlich, dass manche Abstimmenden genau wegen dieser drohenden Inkonsistenzen in bestimmter Weise abgestimmt haben, z.B. durchgängig Nein gesagt haben, obwohl sie der Meinung waren, *wenn* die Client-Hierarchie eingerichtet würde, dann gehöre auch die Webbrowser-Gruppe dort hinein. Somit war auch das Wissen um (und die Angst vor) möglicherweise inkonsistenten Ergebnissen geeignet, den Wählerwillen zu verfälschen. 6) Grosse Sammelabstimmung ~~~~~~~~~~~~~~~~~~~~~~~~~~ Die Einrichtungsregeln raten von Sammelabstimmungen ab: | Ein RfD/CfV kann eine Sammelabstimmung über mehrere Gruppen | enthalten, wenn für jede Gruppe jeweils eine Charta und eine | Kurzbeschreibung vorhanden ist. Sie sollte im allgemeinen aber | vermieden werden, da hier leicht durch eine zugkräftige Gruppe die | Wahlbeteiligungsklausel (s.u.) der anderen Gruppen ausgehebelt | werden kann. Es ist anzunehmen, dass bei diesem CfV Leute teilgenommen haben, die sich eigentlich nur für einen Teilbereich interessiert haben. Dadurch kann das Ergebnis verfälscht werden. Da von Sammelabstimmungen in den Regeln zwar abgeraten, sie aber nicht verboten, sondern ausdrücklich als Möglichkeit vorgesehen sind, reicht dieser Punkt _allein_ nicht, um das Ergebnis für ungültig zu erklären. Er ist aber ein weiterer Gesichtspunkt, der in Kombination mit den Punkten 1)-4) eine Annullierung der Abstimmung begründen kann. Insbesondere ist dieser Punkt 6), wie schon Punkt 5), ein Grund, die _ganze_ Abstimmung zu annullieren, und nicht einzelne Teilfragen als gültig anzusehen. Formale Berechtigung des Einspruchs Es wurde in der bisherigen Diskussion in de.admin.news.groups angezweifelt, ob ein Einspruch das geeignete Mittel in dieser Situation sei. Es wurde gesagt, mit dem Argument "Inkonsistenz" würde ja das Ergebnis als solches, und nicht dessen Zustandekommen kritisiert, also in etwa "Einspruch, weil mir das Ergebnis nicht passt". Ich hoffe, mit meiner Begründung gezeigt zu haben, dass der Wahlmodus den Wählerwillen verfälscht hat, und dass man für das Ergebnis, wie es jetzt vorliegt, nicht den "Willen der Mehrheit" ins Feld führen kann. Vorschlag für das weitere Vorgehen Mein Antrag ist eine komplette Annullierung der Abstimmung in allen Punkten. Bei einer Neuauflage, die ich begrüssen würde, sollte der Wahlmodus ungefähr so gestaltet werden (jeweils _eine_ Frage, entsprechende Sonderregeln sind nötig): (1) Löschung der Mailtraq-Gruppe (2) Einrichtung einer Unterhierarchie dcs.server.*, Verschiebung _aller_ Servergruppen unter dcs.* in diese neue Unterhierarchie und Einrichtung einer Gruppe dcs.server.misc. (3) Einrichtung einer Unterhierarchie dcs.client.*, Verschiebung _aller_ Clientgruppen unter dcs.* in diese neue Unterhierarchie und Einrichtung einer Gruppe dcs.client.misc. (4) Frage, ob die Punkte (2) und (3) auch umgesetzt werden sollen, wenn nur einer der beiden angenommen wird [einfache Mehrheit genügt] (5) Verschiebung von dciw.serbver nach dcs.server.web [Kaskadierung: nur relevant, wenn (2) umgesetzt wird] (6) Verschiebung von dciw.browser nach dcs.client.webbrowser [Kaskadierung: nur relevant, wenn (3) umgesetzt wird] (7) Frage, ob die Punkte (5) und (6) auch dann umgesetzt werden sollen, wenn nur einer der beiden angenommen wird [einfache Mehrheit genügt] (8) Einrichtung einer Hamster-Gruppe in der passenden Hierarchie [dcs.hamster, wenn (2) abgelehnt wird, dcs.server.hamster, wenn (2) angenommen wird] Die Punkte (4) und (7) könnte man allenfalls weglassen. Sie sollen sicherstellen, dass sowohl jene, die die Server-Hierarchie als von der Client-Hierarchie unabhängig betrachten, als auch jene, die eine konsistente Struktur nur bei Einrichtung beider Hierarchien sehen, ihrer Meinung Ausdruck verleihen können. Adrian Suter