Re: Mitarbeit an deutscher Übersetzung
* Christian Britz <cbritz@gmx.net> schrieb am 23.03.04 um 12:17 Uhr:
<sniep>
> Gerne! Ich habe kurzfristig Zeit zum Korrekturlesen.
Hallo Christian (und Liste),
hier ist meine Übersetzung von devel/constitution.
Du kannst zur Ansicht am einfachsten HTML daraus machen, indem du die
Kommentare im Kopf ausklammerst oder entfernst und 'tidy' drüberlaufen
läßt.
Ich schlage vor, dass Du Korrekturen mit 'diff -u' wieder an diese
Liste schickst, so dass 'andere interessierte Parteien' mitreden können.
Angefügt ist auch noch ein Aufschrieb über die Wortwahl.
Vielleicht kannst Du kurz bestätigen, dass Du den Text zur Korrektur
durchgehst?
Gruß,
Matthias
#use wml::debian::template title="Debian-Satzung" BARETITLE="true"
#use wml::debian::translation-check translation="1.2"
# Translator: Matthias Lutz <lutz@lumpix.de>
<h1>Satzung für das Debian-Projekt (v1.2)</h1>
<p>Dies ist die am 29. Oktober 2003 ratifizierte Version 1.2. Sie
ersetzt die am 21. Juni 2003 ratifizierte <a href=
"constitution.1.1">Version 1.1</a>, welche ihrerseits die am 2.
Dezember 1998 ratifizierte <a href="constitution.1.0">Version 1.0</a>
ersetzt.</p>
<h2>1. Einleitung</h2>
<p><cite>Das Debian-Projekt ist ein Verband von
Einzelpersonen, die die Schaffung eines freien Betriebssystem zu
ihrer gemeinsamen Sache gemacht haben.</cite></p>
<p>Dieses Dokument beschreibt die Organisationsstruktur für
formelle Entscheidungsfindung innerhalb des Projekts. Es
beschreibt nicht die Ziele des Projekts oder wie es diese
erreicht, und es enthält keine Richtlinien außer denen, die sich
direkt auf den Prozess der Entscheidungsfindung beziehen.</p>
<h2>2. Entscheidungsfindende Organe und Einzelpersonen</h2>
<p>Jede Entscheidung innerhalb des Projekts wird von einem oder
mehreren der folgenden Organe und Einzelpersonen getroffen:</p>
<ol>
<li>Die Entwickler, durch eine Allgemeine Entschließung;</li>
<li>Der Projekt-Leiter;</li>
<li>Der Technische Ausschuss und/oder sein Vorsitzender;</li>
<li>Der an einer einzelnen Aufgabe arbeitende Entwickler;</li>
<li>Vom Projekt-Leiter für bestimmte Aufgaben ernannte
Delegierte;</li>
<li>Der Projekt-Schriftführer.</li>
</ol>
<p>Das meiste vom Rest dieses Dokuments beschreibt die Befugnisse
dieser Organe, ihre Zusammensetzung und Ernennung und das
Verfahren bei ihrer Entscheidungsfindung. Die Befugnisse einer Person
oder eines Organs können der Überwachung und/oder Einschränkung
unterworfen sein; in diesem Fall gibt dies der Eintrag
unter dem überwachenden Organ oder der Person an. <cite>In der
obigen Liste ist eine Person oder ein Organ in der Regel vor
irgendwelchen Personen oder Organen aufgeführt, deren
Entscheidungen sie aufheben oder die sie ernennen (oder ihnen
dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt
wurde, jeden, der nachher aufgeführt wurde,
überstimmen.</cite></p>
<h3>2.1. Allgemeine Vorschriften</h3>
<ol>
<li>
<p>Nichts in dieser Satzung erlegt irgendjemandem die
Verpflichtung auf, für das Projekt Arbeit zu verrichten. Eine
Person, die eine an sie delegierte oder ihr zugewiesene
Aufgabe nicht erledigen möchte, muss es nicht tun. Jedoch
darf sie nicht diesen Vorschriften oder Entscheidungen, die
nach diesen Vorschriften ordnungsgemäß getroffen wurden, aktiv
entgegenwirken.</p>
</li>
<li>
<p>Eine Person kann verschiedene Ämter innehaben, mit der
Ausnahme, dass sich der Projekt-Leiter, der Projekt-Schriftführer
und der Vorsitzende des Technischen Ausschusses unterscheiden
müssen, und dass der Projekt-Leiter sich nicht zu seinem
eigenen Delegierten ernennen kann.</p>
</li>
<li>
<p>Eine Person kann das Projekt verlassen oder ein bestimmtes
Amt zu jeder Zeit niederlegen, indem sie dies öffentlich
erklärt.</p>
</li>
</ol>
<h2>3. Einzelne Entwickler</h2>
<h3>3.1. Befugnisse</h3>
<p>Ein einzelner Entwickler kann</p>
<ol>
<li>jede technische oder nichttechnische Entscheidung
hinsichtlich seiner eigenen Arbeit treffen;</li>
<li>einen Entwurf zu einer Allgemeinen Entschließung einbringen
oder befürworten;</li>
<li>sich bei Wahlen selbst als Kandidat für das Amt des
Projekt-Leiters vorschlagen;</li>
<li>bei Allgemeinen Entschließungen und bei Wahlen über die
Leitung abstimmen.</li>
</ol>
<h3>3.2. Zusammensetzung und Ernennung</h3>
<ol>
<li>
<p>Entwickler sind Freiwillige, die sich darin einig sind,
die Ziele des Projekts insofern zu fördern, als sie an ihm
teilhaben, und die ein oder mehrere Pakete für das Projekt
instandhalten oder andere Arbeit verrichten, welche der oder
die Delegierten des Projekt-Leiters als lohnenswert
betrachten.</p>
</li>
<li>
<p>Der oder die Delegierten des Projekt-Leiters können es
vorziehen, keine neuen Entwickler aufzunehmen, oder
vorhandende Entwickler auszuschließen. <cite>Wenn die
Entwickler verspüren, dass die Delegierten ihre Autorität
mißbrauchen, können sie selbstverständlich die Entscheidung
durch eine Allgemeine Entschließung außer Kraft setzen -
siehe §4.1(3), §4.2.</cite></p>
</li>
</ol>
<h3>3.3. Verfahren</h3>
<p>Entwickler können diese Entscheidungen treffen, wie sie es für
richtig halten.</p>
<h2>4. Die Entwickler durch eine Allgemeine Entschließung oder
Wahl</h2>
<h3>4.1. Befugnisse</h3>
<p>Zusammen können die Entwickler</p>
<ol>
<li>
<p>Den Projekt-Leiter ernennen oder abberufen.</p>
</li>
<li>
<p>Diese Satzung abändern, vorausgesetzt, sie stimmen dem mit
einer 3:1-Mehrheit zu.</p>
</li>
<li>
<p>Jede vom Projekt-Leiter oder einem Delegierten getroffene
Entscheidung außer Kraft setzen.</p>
</li>
<li>
<p>Jede vom Technischen Ausschuss getroffene Entscheidung
außer Kraft setzen, vorausgesetzt, sie stimmen dem mit einer
2:1-Mehrheit zu.</p>
</li>
<li>
<p>Nicht-technische schriftliche Richtlinien und Erklärungen
herausgeben, ersetzen und zurückziehen.</p>
<p>Diese beinhalten Dokumente, welche die Ziele des Projekts
und seine Beziehung zu anderen Gebilden der Freien
Software beschreiben, sowie nicht-technische Richtlinien wie die
Lizenzbedingungen für Freie Software, die Debian-Software
erfüllen muss.</p>
<p>Sie können auch Positionserklärungen zu Tagesfragen
hinzufügen.</p>
<ol style="list-style: decimal;">
<li>Ein Gründungsdokument ist ein Dokument oder eine
Erklärung, die als entscheidend für den Auftrag und die
Zwecke des Projekts betrachtet wird.</li>
<li>Die Gründungsdokumente sind die Arbeiten mit dem Titel
<q>Debian-Gesellschaftsvertrag</q> und <q>Debian
Richtlinien für freie Software</q>.</li>
<li>Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um
ersetzt zu werden. Durch Abändern der Liste der
Gründungsdokumente in dieser Satzung werden neue
Gründungsdokumente herausgegeben und vorhandene
zurückgezogen.</li>
</ol>
</li>
<li>
<p>Zusammen mit dem Projekt-Leiter und SPI Entscheidungen über
mit Debian in Beziehung stehendes, treuhänderisch verwaltetes
Eigentum treffen. (Siehe §9.1.)</p>
</li>
</ol>
<h3>4.2. Verfahren</h3>
<ol>
<li>
<p>Die Entwickler befolgen das Standard-Entschließungsverfahren
– siehe weiter unten. Eine Entschließung oder Abänderung wird
eingebracht, indem sie von irgendeinem Entwickler beantragt und
von mindestens K anderen Entwicklern befürwortet wird, oder wenn
sie vom Projekt-Leiter oder Technischen Ausschuss beantragt
wird.</p>
</li>
<li>
<p>Aufschieben einer Entscheidung des Projekt-Leiters oder
seines Delegierten:</p>
<ol>
<li>Wenn der Projekt-Leiter, sein Delegierter oder der
Technische Ausschuss eine Entscheidung getroffen haben, können
Entwickler diese überstimmen, indem sie dazu eine
Entschließung verabschieden; siehe §4.1(3).</li>
<li>Wenn eine solche Entschließung von wenigstens 2K
Entwicklern befürwortet wird, oder wenn sie vom Technischen
Ausschuss beantragt wird, vertagt die Entschließung die
Entscheidung unmittelbar (vorausgesetzt, diese
Entschließung selbst besagt dies).</li>
<li>Falls die ursprüngliche Entscheidung darin bestand, eine
Diskussions- oder Abstimmungsfrist zu ändern, oder wenn die
Entschließung darin besteht, den Technischen Ausschuss zu
überstimmen, dann brauchen nur K Entwickler die Entschließung
zu befürworten, um die Entscheidung unmittelbar vertagen zu
können.</li>
<li>Falls die Entscheidung vertagt wird, wird eine
unmittelbare Abstimmung abgehalten, um zu bestimmen, ob die
Entscheidung solange aufrechterhalten wird, bis die
vollständige Abstimmung über die Entscheidung durchgeführt
wurde, oder ob die Erfüllung der ursprünglichen Entscheidung
bis dahin verzögert wird. Es gibt bei dieser unmittelbaren
verfahrensbezogenen Abstimmung kein Quorum <cite>(d.h.:
Mindestzahl von Teilnehmern)</cite>.</li>
<li>Falls der Projekt-Leiter (oder der Delegierte) die
ursprüngliche Entscheidung zurückzieht, so wird die
Abstimmung gegenstandslos und wird nicht weiter
durchgeführt.</li>
</ol>
</li>
<li>
<p>Der Projekt-Schriftführer lässt abstimmen. Stimmen,
Stimmensummen und Ergebnisse werden während der
Abstimmungsfrist nicht offengelegt; nach der Abstimmung führt
der Projekt-Schriftführer alle abgegebenen Stimmen in einer Liste
auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den
Projekt-Leiter um bis zu einer Woche variiert werden.</p>
</li>
<li>
<p>Die Mindestfrist für Diskussionen beträgt zwei Wochen,
kann aber durch den Projekt-Leiter um bis zu einer Woche
variiert werden. Die Stimme des Projekt-Leiters gibt den
Ausschlag. Es gibt ein Quorum von 3Q.</p>
</li>
<li>
<p>Anträge, Befürwortungen, Abänderungen, Aufrufe zur
Abstimmung und andere formelle Handlungen werden auf einer
für die Öffentlichkeit lesbaren, von dem bzw. den Delegierten
des Projekt-Leiters bestimmten Mailingliste bekanntgemacht;
jeder Entwickler kann dort Beiträge abgeben.</p>
</li>
<li>
<p>Stimmen werden in einer für den Schriftführer geeigneten
Weise durch E-Mail abgegeben. Der Schriftführer legt für jede
Abstimmung fest, ob Stimmberechtigte ihre Stimme ändern
können.</p>
</li>
<li>
<p>Q ist die Hälfte der Quadratwurzel aus der Anzahl der
gegenwärtigen Entwickler. K ist Q oder 5, je nachdem, welches
davon kleiner ist. Q und K brauchen nicht ganze Zahlen zu
sein und werden nicht gerunded.</p>
</li>
</ol>
<h2>5. Projekt-Leiter</h2>
<h3>5.1. Befugnisse</h3>
<p>Der <a href="leader">Projekt-Leiter</a> kann</p>
<ol>
<li>
<p>Delegierte ernennen oder Entscheidungen an den Technischen
Ausschuss delegieren.</p>
<p>Der Leiter kann einen Bereich mit fortlaufender
Verantwortung oder eine bestimmte Entscheidung festlegen und
diese an einen anderen Entwickler oder den Technischen
Ausschuss übergeben.</p>
<p>Sobald eine bestimmte Entscheidung delegiert und getroffen
wurde, darf der Projekt-Leiter diese Delegierung nicht
zurückziehen; jedoch darf er eine fortlaufende Delegierung
eines bestimmten Verantwortungsbereichs zurückziehen.</p>
</li>
<li>
<p>Anderen Entwicklern Vollmacht erteilen.</p>
<p>Der Projekt-Leiter kann Erklärungen zur Unterstützung von
Standpunkten oder von anderen Mitgliedern des Projekts abgeben,
gebeten oder ungebeten; diese Erklärungen haben nur dann
Kraft, wenn der Projekt-Leiter befugt wäre, die fragliche
Entscheidung zu treffen.</p>
</li>
<li>
<p>Jede Entscheidung treffen, welche dringende Handlung
erfordert.</p>
<p>Dies gilt nicht für Entscheidungen, die nur durch einen
Mangel an entsprechenden Maßnahmen allmählich dringend
geworden sind, außer wenn es einen festen Stichtag gibt.</p>
</li>
<li>
<p>Jede Entscheidung treffen, für die niemand sonst
Verantwortung trägt.</p>
</li>
<li>
<p>Entwürfe für Allgemeine Entschließungen und Abänderungen
einbringen.</p>
</li>
<li>
<p>Zusammen mit dem Technischen Ausschuss neue Mitglieder in
den Ausschuss berufen. (Siehe §6.2.)</p>
</li>
<li>
<p>Sich einer ausschlaggebenden Stimme bedienen, wenn
Entwickler abstimmen.</p>
<p>Der Projekt-Leiter hat auch eine normale Stimme bei solchen
Abstimmungen.</p>
</li>
<li>
<p>Die Diskussionsfrist für Abstimmungen der Entwickler
variieren (wie oben).</p>
</li>
<li>
<p>Diskussionen unter Entwicklern leiten.</p>
<p>Der Projekt-Leiter sollte versuchen, an Diskussionen unter
den Entwicklern auf eine hilfreiche Weise teilzunehmen, die
versucht, die Diskussion zu den vorhandenen Kernproblemen zu
bringen. Der Projekt-Leiter sollte nicht seine
Leitungsposition benutzen, um seine eigenen persönlichen
Ansichten zu befördern.</p>
</li>
<li>
<p>Zusammen mit SPI Entscheidungen treffen, die mit Debian
in Beziehung stehendes, treuhänderisch verwaltetes Eigentum betreffen.
(Siehe §9.1.)</p>
</li>
</ol>
<h3>5.2. Ernennung</h3>
<ol>
<li>Der Projekt-Leiter wird von den Entwicklern gewählt.</li>
<li>Die Wahl beginnt neun Wochen, bevor das Amt der Leitung
frei wird, oder (wenn es bereits zu spät ist) unmittelbar.</li>
<li>In den darauffolgenden drei Wochen kann jeder Entwickler
sich selbst als Kandidat für das Amt des Projekt-Leiters
nominieren.</li>
<li>Danach können für drei Wochen keine weiteren Kandidaten
nominiert werden; Kandidaten sollten diese Zeit für die
Wahlkampagne nutzen (um ihre Person und Positionen
bekanntzumachen). Falls es am Ende der Nominierungsfrist keine
Kandidaten gibt, so wird die Nominierung um weitere drei Wochen
verlängert – falls nötig, wiederholt.</li>
<li>Die nächsten drei Wochen sind der Abstimmungszeitraum, in
der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen
für das Amt des Projekt-Leiters werden geheimgehalten, sogar
nachdem die Abstimmung beendet ist.</li>
<li>Die Optionen <cite>(d.h. Wahlmöglichkeiten)</cite> auf dem
Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert
und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich
»Niemand von den Obigen«. Falls »Niemand von den
Obigen« die Wahl gewinnt, so wird das Wahlverfahren
wiederholt, dies viele Male, falls nötig.</li>
<li>Die Entscheidung wird nach der in §A.6 des
Standard-Entschließungsverfahrens bestimmten Methode getroffen.
Das Quorum ist dasselbe wie für eine Allgemeine Entschließung
(§4.2) und die Default-Option ist »Niemand von den
Obigen«.</li>
<li>Der Projekt-Leiter amtiert nach seiner Wahl ein Jahr
lang.</li>
</ol>
<h3>5.3. Verfahren</h3>
<p>Der Projekt-Leiter sollte versuchen, Entscheidungen zu treffen,
die mit der übereinstimmenden Meinung der Entwickler vereinbar
sind.</p>
<p>Sofern es praktikabel ist, sollte der Projekt-Leiter sich
informell um die Ansichten der Entwickler bemühen.</p>
<p>Der Projekt-Leiter sollte es vermeiden, seinen eigenen
Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft
als Projekt-Leiter Entscheidungen trifft.</p>
<h2>6. Technischer Ausschuss</h2>
<h3>6.1. Befugnisse</h3>
<p>Der <a href="tech-ctte">Technische Ausschuss</a> kann</p>
<ol>
<li>
<p>Über jede Angelegenheit entscheiden, die technische
Grundsätze betrifft.</p>
<p>Dies schließt die Inhalte der Handbücher für technische
Richtlinien, Nachschlagematerial für Entwickler,
Beispielpakete und das Verhalten der nicht-experimentellen
Paket-Bauwerkzeuge ein. (In jedem dieser Fälle trifft jedoch der
übliche Instandhalter der entsprechenden Software oder
Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)</p>
</li>
<li>
<p>Über jede technische Angelegenheit entscheiden, in der sich die
Entscheidungsbefugnis von Entwicklern überlappt.</p>
<p>In Fällen, bei denen Entwickler miteinander vereinbare
technische Richtlinien oder Standpunkte erfüllen müssen (zum
Beispiel, wenn sie über die Priorität kollidierender Pakete
verschiedener Meinung sind, oder über das Eigentum am Namen
eines Befehls, oder darüber, welches Paket für einen Fehler
verantwortlich ist, bei dem beide Instandhalter sich einig
sind, dass er ein Fehler ist, oder darüber, wer der
Instandhalter eines Pakets sein sollte), kann der technische
Ausschuss die Angelegenheit entscheiden.</p>
</li>
<li>
<p>Eine Entscheidung treffen, wenn er darum gebeten wird.</p>
<p>Jede Person oder Organ kann eine eigene Entscheidung an
den Technischen Ausschuss delegieren, oder von ihm Rat
einholen.</p>
</li>
<li>
<p>Einen Entwickler überstimmen (benötigt eine
3:1-Mehrheit).</p>
<p>Der technische Ausschuss kann einen Entwickler darum
bitten, einen bestimmten technischen Handlungsweg zu
beschreiten, sogar wenn der Entwickler dies nicht wünscht;
dazu wird eine 3:1-Mehrheit benötigt. Zum Beispiel kann der
Ausschuss festlegen, dass eine Beanstandung, die vom
Einsender eines Fehlerberichts erhoben wurde, gerechtfertigt
ist, und dass die vom Einsender vorgeschlagene Lösung erfüllt
werden sollte.</p>
</li>
<li>
<p>Rat anbieten.</p>
<p>Der Technische Ausschuss kann seine Ansichten über
jegliche Angelegenheit formell bekanntmachen. <cite>Einzelne
Mitglieder können natürlich informelle Erklärungen über ihre
Ansichten und über die voraussichtlichen Ansichten des Ausschusses
abgeben.</cite></p>
</li>
<li>
<p>Zusammen mit dem Projekt-Leiter neue Mitglieder in den
Ausschuss berufen oder vorhandene Miglieder abberufen. (Siehe
§6.2.)</p>
</li>
<li>
<p>Den Vorsitzenden des Technischen Ausschusses ernennen.</p>
<p>Der Vorsitzende wird vom Ausschuss aus seinen Mitgliedern
gewählt. Alle Mitglieder des Ausschusses werden automatisch
nominiert; der Ausschuss beginnt eine Woche vor dem
Freiwerden des Amtes zu wählen (oder unmittelbar, wenn es
bereits zu spät ist). Die Mitglieder können durch öffentliche
Akklamation für jedes Mitglied des Ausschusses stimmen,
inklusive ihrer selbst; es gibt keine Default-Option. Die
Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder
wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch
die in §A.6 des Standard-Entschließungsverfahrens
bestimmte Methode festgelegt.</p>
</li>
<li>
<p>Der Vorsitzende kann den Projekt-Leiter zusammen mit dem
Schriftführer vertreten.</p>
<p>Wie in §7.1(2) einzeln beschrieben wird, können
der Vorsitzende des Technischen Ausschusses und der
Projekt-Schriftführer zusammen den Projekt-Leiter vertreten, falls es
keinen Projekt-Leiter gibt.</p>
</li>
</ol>
<h3>6.2. Zusammensetzung</h3>
<ol>
<li>
<p>Der technische Ausschuss besteht aus bis zu 8 Entwicklern
und sollte für gewöhnlich mindestens 4 Mitglieder haben.</p>
</li>
<li>
<p>Wenn es weniger als 8 Mitglieder gibt, kann der technische
Ausschuss dem Projekt-Leiter ein oder mehrere neue Mitglieder
empfehlen, der seinerseits (einzeln) entscheiden kann, ob
er sie ernennt oder nicht.</p>
</li>
<li>
<p>Wenn es 5 oder weniger Mitglieder gibt, kann der
Technische Ausschuss ein oder mehrere Mitglieder ernennen,
bis die Anzahl der Mitglieder 6 erreicht.</p>
</li>
<li>
<p>Wenn es für mindestens eine Woche 5 oder weniger
Mitglieder gegeben hat, kann der Projekt-Leiter ein oder
mehrere neue Mitglieder ernennen, bis die Anzahl der
Mitglieder 6 erreicht, dies in Abständen von mindestens einer
Woche pro Ernennung.</p>
</li>
<li>
<p>Falls der Technische Ausschuss und der Projekt-Leiter sich
einig sind, können sie ein im Technischen Ausschuss
vorhandenes Mitglied entfernen oder ersetzen.</p>
</li>
</ol>
<h3>6.3. Verfahren</h3>
<ol>
<li>
<p>Der Technische Ausschuss bedient sich des
Standard-Entschließungsverfahrens.</p>
<p>Ein Entschließungsentwurf oder eine Abänderung kann von
jedem Mitglied des Technischen Ausschusses vorgeschlagen
werden. Es gibt keine Mindestfrist für Diskussionen; die
Abstimmungsfrist dauert bis zu einer Woche, oder bis über den
Ausgang kein Zweifel mehr besteht. Mitglieder können ihre
Stimmen ändern. Das Quorum beträgt 2.</p>
</li>
<li>
<p>Einzelheiten, die die Abstimmung betreffen.</p>
<p>Der Vorsitzende hat eine ausschlaggebende Stimme. Wenn der
Technische Ausschuss darüber abstimmt, ob ein Entwickler, der
ebenfalls Mitglied des Ausschusses ist, überstimmt werden
soll, so darf dieser Entwickler nicht abstimmen (es sei denn, er
ist der Vorsitzende – in diesem Fall kann er nur seine
ausschlaggebende Stimme benutzen).</p>
</li>
<li>
<p>Öffentliche Diskussion und Entscheidungsfindung.</p>
<p>Diskussion, Entschließungsentwürfe und Abänderungen,
sowie Stimmen von Mitgliedern des Ausschusses werden auf der
öffentlichen Diskussionsliste des Technischen Ausschusses
bekannt gemacht. Es gibt keinen gesonderten Schriftführer für den
Ausschuss.</p>
</li>
<li>
<p>Vertraulichkeit der Ernennungen.</p>
<p>Der Technische Ausschuss kann vertrauliche Diskussionen
durch private E-Mail, eine private Mailingliste oder andere
Mittel abhalten, um Ernennungen in den Ausschuss zu
diskutieren. Jedoch müssen Abstimmungen über Ernennungen
öffentlich sein.</p>
</li>
<li>
<p>Keine Entwurfsarbeit in Einzelheiten.</p>
<p>Der Technische Ausschuss nimmt nicht am Entwurf neuer
Vorschläge oder Richtlinien teil. Solche Entwurfsarbeit
sollte von Einzelpersonen für sich oder zusammen durchgeführt
werden und in gewöhnlichen Foren für technische Richtlinien
und Entwürfe diskutiert werden.</p>
<p>Der Technische Ausschuss beschränkt sich darauf,
Kompromisse zwischen Lösungen und Entscheidungen, welche
anderswo vorgeschlagen und hinreichend gründlich diskutiert
worden sind, auszuwählen oder aufzunehmen.</p>
<p><cite>Einzelne Mitglieder des Technischen Ausschusses
können selbstverständlich in eigener Sache an jedem Aspekt
der Arbeit an Entwürfen und Richtlinien teilhaben.</cite></p>
</li>
<li>
<p>Technischer Ausschuss fasst Beschlüsse nur als letzten
Ausweg.</p>
<p>Der technische Ausschuss trifft keine technische
Entscheidung, solange nicht Anstrengungen, diese durch einen
Konsens zu entscheiden, unternommen worden und fehlgeschlagen
sind, außer wenn er von der Person oder dem Organ, das
normalerweise dafür verantwortlich ist, darum gebeten wurde,
eine Entscheidung zu treffen.</p>
</li>
</ol>
<h2>7. Der Projekt-Schriftführer</h2>
<h3>7.1. Befugnisse</h3>
<p>Der <a href="secretary">Schriftführer</a></p>
<ol>
<li>
<p>Lässt unter den Entwicklern abstimmen und bestimmt die
Anzahl und Person der Entwickler, wann immer dies die Satzung
erfordert.</p>
</li>
<li>
<p>Kann zusammen mit dem Vorsitzenden des Technischen
Ausschusses an die Stelle des Projekt-Leiters treten.</p>
<p>Wenn es keinen Projekt-Leiter gibt, können der Vorsitzende
des Technischen Ausschusses und der Projekt-Schriftführer in
gegenseitigem Einvernehmen Entscheidungen treffen, wenn sie
dies als unumgänglich betrachten.</p>
</li>
<li>
<p>Über jegliche Streitigkeit urteilen, die die Auslegung der
Satzung betrifft.</p>
</li>
<li>
<p>Kann seine Befugnisse teilweise oder vollständig an jemand
anderes übertragen oder eine solche Delegierung zu jeder Zeit
zurücknehmen.</p>
</li>
</ol>
<h3>7.2. Ernennung</h3>
<p>Der Projekt-Schriftführer wird vom Projekt-Leiter und dem
gegenwärtigen Projekt-Schriftführer ernannt.</p>
<p>Wenn der Projekt-Leiter und der gegenwärtige Projekt-Schriftführer
sich nicht auf eine neue Ernennung einigen können, müssen
sie das Board von SPI (siehe §9.1.) darum bitten, einen
Schriftführer zu ernennen.</p>
<p>Wenn es keinen Projekt-Schriftführer gibt, oder der gegenwärtige
Projekt-Schriftführer nicht erreichbar ist und seine Vollmacht über
eine Entscheidung nicht abgegeben hat, kann der Vorsitzende des
Technischen Ausschusses als stellvertretender Schriftführer die
Entscheidung treffen oder delegieren.</p>
<p>Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen
Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden
muss.</p>
<h3>7.3. Verfahren</h3>
<p>Der Projekt-Schriftführer sollte gerechte und vernünftige
Entscheidungen treffen, die vorzugsweise mit dem Konsens der
Entwickler vereinbar sind.</p>
<p>Wenn der Vorsitzende des Technischen Ausschusses und der
Projekt-Schriftführer zusammen stellvertretend für einen abwesenden
Projekt-Leiter handeln, sollten sie nur wenn absolut notwendig
Entscheidungen treffen, und nur, wenn diese vereinbar mit dem
Konsens der Entwickler sind.</p>
<h2>8. Die Delegierten des Projekt-Leiters</h2>
<h3>8.1. Befugnisse</h3>
<p>Die Delegierten des Projekt-Leiters</p>
<ol>
<li>haben vom Projekt-Leiter an sie delegierte Befugnisse;</li>
<li>können gewisse Entscheidungen treffen, die der Leiter nicht
auf direkte Weise treffen darf. Dazu gehört, Entwickler
anzuerkennen oder zu verweisen, oder Personen zu Entwicklern zu
bestimmen, die keine Pakete instandhalten. <cite>Dies dient
dazu, eine Konzentration vom Macht, besonders eine über
Mitgliedschaft von Entwicklern, in den Händen des
Projekt-Leiters zu verhindern.</cite></li>
</ol>
<h3>8.2. Ernennung</h3>
<p>Die Delegierten werden durch den Projekt-Leiter ernannt und
können vom Projekt-Leiter nach seinem Ermessen ersetzt werden. Der
Projekt-Leiter kann weder die Position des Delegierten von
bestimmten Entscheidungen des Delegierten abhängig machen, noch
kann er sich über eine Entscheidung hinwegsetzen, die einmal von
einem Delegierten getroffen wurde.</p>
<h3>8.3. Verfahren</h3>
<p>Delegierte können Entscheidungen treffen, wie sie es für
richtig halten, jedoch sollten sie versuchen, gute technische
Entscheidungen zu vollziehen und/oder der übereinstimmenden
Meinung zu folgen.</p>
<h2>9. Software im Öffentlichen Interesse</h2>
<p><a href="http://www.spi-inc.org/";>SPI</a> und Debian sind
getrennte Organisationen, welche einige Ziele miteinander
teilen. Debian ist dankbar für die rechtliche Unterstützung, die
SPI anbietet. <cite>Die Entwickler von Debian sind gegenwärtig
Mitglieder von SPI auf Grund ihres Status' als
Entwickler.</cite></p>
<h3>9.1. Befugnis</h3>
<ol>
<li>SPI hat keine Befugnis, die Debians technische oder
nichttechnische Entscheidungen betrifft, mit den Ausnahmen, dass
keine Entscheidung durch Debian in Hinsicht auf irgendwelches von
SPI verwaltetes Eigentum erfordern darf, dass SPI außerhalb seiner
rechtlichen Befugnis handelt, und dass nach Debians Satzung SPI
gelegentlich in letzter Instanz als entscheidendes Organ
verwendet.</li>
<li>Debian beansprucht keine Befugnis über SPI außer der über
die Verwendung gewissen Eigentums von SPI, wie weiter unten
beschrieben wird. Dennoch können den Debian-Entwicklern
innerhalb von SPI nach den Vorschriften von SPI Befugnisse
erteilt werden.</li>
<li>Debian-Entwickler sind weder Vertreter oder Angestellte von
SPI oder voneinander oder von innerhalb des Debian-Projekts mit
Befugnis versehenen Personen. Eine Person, die als
Entwickler handelt, tut dies als Einzelperson, im eigenen
Namen.</li>
</ol>
<h3>9.2. Verwaltung des Eigentums für Zwecke, die mit Debian in Beziehung
stehen</h3>
<p>Da Debian keine Befugnis hat, Geld oder Eigentum zu besitzen,
müssen jegliche Spenden für das Debian-Projekt an SPI gemacht
werden, das solche Angelegenheiten handhabt.</p>
<p>SPI hat folgende Zusicherungen gemacht:</p>
<ol>
<li>SPI besitzt für mit Debian in Beziehung stehende Zwecke
Geld, Warenzeichen und anderes materielle und immaterielle
Eigentum und handhabt andere Angelegenheiten.</li>
<li>Solches Eigentum wird für diese Zwecke, über die Debian und
SPI entsprechend dieses Abschnitts entscheiden, treuhänderisch mit
separater Rechenschaft verwaltet.</li>
<li>SPI wird kein für Debian treuhänderisch verwaltetes Eigentum
veräußern oder verwenden, ohne dass eine Genehmigung durch Debian
vorliegt. Diese kann vom Projekt-Leiter oder durch Allgemeine
Entschließung der Entwickler erteilt werden.</li>
<li>SPI wird in Betracht ziehen, treuhänderisch verwaltetes
Eigentum zu verwenden oder zu veräußern, wenn es durch den
Projekt-Leiter darum gebeten wird.</li>
<li>SPI wird für Debian treuhänderisch verwaltetes Eigentum
verwenden oder veräußern, wenn es durch eine Allgemeine
Entschließung der Entwickler darum gebeten wird, vorausgesetzt,
dass dies mit der rechtlichen Befugnis von SPI verträglich
ist.</li>
<li>SPI wird die Entwickler durch E-Mail auf einer Mailingliste
des Debian-Projekts benachrichtigen, wenn es für Debian
treuhänderisch verwaltetes Eigentum verwendet oder
veräußert.</li>
</ol>
<h2>A. Standard-Entschließungsverfahren</h2>
<p>Diese Vorschriften betreffen gemeinschaftliche
Entscheidungsfindung durch Ausschüsse und Plebiszite, wo oben
angegeben.</p>
<h3>A.1. Beantragung</h3>
<p>Das formelle Verfahren beginnt, wenn ein Entschließungsentwurf
beantragt und befürwortet wird, je nach Bedarf.</p>
<h3>A.1. Diskussion und Abänderung</h3>
<ol>
<li>Nach der Beantragung kann die Entschließung diskutiert
werden. Abänderungen können formell gemacht werden, indem sie
entsprechend den Anforderungen an eine neue Entschließung
beantragt und befürwortet werden, oder auf auf direktem
Wege durch den Antragsteller der ursprünglichen
Entschließung.</li>
<li>Eine formelle Abänderung kann durch den Antragsteller der
Entschließung angenommen werden. In diesem Fall wird der
formelle Entschließungsentwurf unmittelbar mit der Abänderung
in Übereinstimmung gebracht.</li>
<li>Wenn eine formelle Abänderung nicht angenommen wird, oder
einer der Befürworter der Entschließung nicht mit der Annahme
durch den Antragsteller einer formellen Abänderung
einverstanden ist, bleibt die Abänderung eine Abänderung und es
wird über sie abgestimmt.</li>
<li>Wenn eine vom ursprünglichen Antragsteller angenommene
Abänderung nicht nach dem Geschmack Anderer ist, können diese
eine weitere Abänderung einbringen, um die frühere Veränderung
umzukehren (dabei müssen sie wiederum Antragsteller und Befürworter
gemäß der Anforderungen sein).</li>
<li>Der Antragsteller einer Entschließung kann Veränderungen an
der Formulierung von Abänderungen vorschlagen; diese werden wirksam,
wenn der Antragsteller der Abänderung damit
einverstanden ist und keiner der Befürworter dagegen ist. In
diesem Fall wird anstelle der ursprünglichen über die
veränderten Abänderungen abgestimmt.</li>
<li>Der Antragsteller einer Entschließung kann Veränderungen
vornehmen, um unbedeutendere Fehler (zum Beispiel Schreibfehler
oder Ungereimtheiten) zu berichtigen, oder Veränderungen
vornehmen, die nicht den Sinn ändern, vorausgesetzt niemand
erhebt innerhalb von 24 Stunden Einwände. In diesem Fall
beginnt die Mindestfrist für Diskussionen nicht von vorn.</li>
</ol>
<h3>A.2. Aufruf zur Abstimmung</h3>
<ol>
<li>Der Antragsteller oder ein Befürworter eines Antrages kann zur
Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für
Diskussionen (falls vorhanden) abgelaufen ist.</li>
<li>Der Antragsteller und jeder Befürworter einer Entschließung
können zu einer Abstimmung über diese Entschließung und alle damit
zusammenhängenden Abänderungen aufrufen.</li>
<li>Die Person, welche zu einer Abstimmung aufruft, gibt bekannt,
welches ihrer Ansicht nach die Formulierung der Entschließung und
relevante Abänderungen sind, und folglich, welche Form der
Stimmzettel annehmen sollte. Dennoch liegt die endgültige
Entscheidung über die Form des/der Stimmzettel beim Schriftführer
– siehe §§7.1(1), 7.1(3) und A.3(4).</li>
<li>Die Mindestfrist für Diskussionen zählt ab dem Zeitpunkt,
zu dem die letzte formelle Abänderung angenommen wurde, oder ab
dem Zeitpunkt, zu dem die ganze Entschließung vorgeschlagen
wurde, falls keine Abänderungen vorgeschlagen und angenommen
wurden.</li>
</ol>
<h3>A.3. Wahlverfahren</h3>
<ol>
<li>Über jede Entschließung und die damit zusammenhängenden
Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der
jeweils eine Option für die ursprüngliche Entschließung, jede
Abänderung und die Default-Option (wo anwendbar) enthält.</li>
<li>Die Default-Option darf keine Supermajorität
<cite>(d.h.: über die einfache Mehrheit hinausgehende
Mehrheit)</cite> erfordern. Optionen, die nicht explizit eine
Supermajorität erfordern, erfordern eine 1:1-Mehrheit.</li>
<li>Die Stimmen werden nach den Vorschriften in §A.6. gezählt.
Die Default-Option heißt "Weitere Diskussion", wenn nicht eine
andere bestimmt wurde.</li>
<li>In Zweifelsfällen entscheidet der Projekt-Schriftführer über
Angelegenheiten des Verfahrens.</li>
</ol>
<h3>A.4. Zurückziehen von Entschließungen oder nicht
angenommenen Abänderungen</h3>
<p>Der Antragsteller einer Entschließung oder einer nicht
angenommenen Abänderung kann diese zurückziehen. In diesem Fall
können neue Antragsteller hervortreten, um sie am Leben zu
halten; dann wiederum wird die erste Person, die dies tut, der
neue Antragsteller, und alle anderen werden Befürworter, wenn
sie dies nicht bereits sind.</p>
<p>Ein Befürworter einer Entschließung oder einer Abänderung (es
sei denn, sie wurde angenommen) kann seine Befürwortung
zurückziehen.</p>
<p>Wenn die Zurückziehung durch den Antragsteller und/oder die
Befürworter bedeutet, dass die Entschließung keinen
Antragsteller oder nicht genug Befürworter hat, wird über sie
nicht abgestimmt, es sei denn, dies wird berichtigt, bevor die
Entschließung verfällt.</p>
<h3>A.5. Verfall</h3>
<p>Wenn innerhalb von 4 Wochen eine vorgeschlagene Entschließung
nicht diskutiert wurde, sie nicht abgeändert wurde, darüber
abgestimmt wurde oder sie auf andere Weise behandelt wurde, kann
der Schriftführer eine Erklärung abgeben, dass man dabei ist, die
Angelegenheit zurückzuziehen. Wenn keiner der Befürworter der
Anträge innerhalb einer Woche Einwände erhebt, wird die
Angelegenheit zurückgezogen.</p>
<p>Der Schriftführer kann seiner Erklärung, falls angebracht, auch
Vorschläge beifügen, wie man weiter vorgehen soll.</p>
<h3>A.6. Stimmenzählung</h3>
<ol>
<li>Der Stimmzettel jedes Stimmberechtigten arrangiert die
Optionen <cite>(d.h.: erteilt ihnen einen Rang)</cite>, über die
abgestimmt wird. Nicht alle Optionen müssen arrangiert
werden. Arrangierte Optionen werden als bervorzugt gegenüber allen
nicht arrangierten Optionen betrachtet. Die Stimmberechtigten
können Optionen gleichrangig arrangieren. Nicht arrangierte
Optionen werden als einander gleichrangig betrachtet. Einzelheiten
darüber, wie Stimmzettel ausgefüllt werden können, werden mit in
den »Aufruf zur Abstimmung« aufgenommen.</li>
<li>Falls der Wahlzettel ein Quorum R fordert, werden alle
Optionen (außer der Default-Option), die nicht mindestens R
Stimmen erhalten, die diese Option gegenüber der Default-Option
höher arrangieren, fallen gelassen.</li>
<li>Jede (nicht-Default-) Option, die die Default-Option nicht
mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird
fallengelassen.
<ol>
<li>Sind zwei Optionen A und B gegeben, so ist V(A,B) die
Anzahl von Stimmberechtigten, die Option A gegenüber Option B
bevorzugen.</li>
<li>Eine Option A besiegt die Default-Option D mit einem
Mehrheitsverhältnis N, falls V(A,D) echt größer als
N * V(D,A) ist.</li>
<li>Wenn eine Supermajorität von S:1 für A benötigt
wird, beträgt ihr Mehrheitverhältnis S; im anderen Fall ist
ihr Mehrheitsverhältnis 1.</li>
</ol>
</li>
<li>Aus der Liste von nicht fallengelassenen Optionen erzeugen
wir eine Liste von paarweisen Besiegungen.
<ol>
<li>Eine Option A besiegt eine Option B, falls V(A,B) echt
größer als V(B,A) ist.</li>
</ol>
</li>
<li>Aus der Liste der paarweisen Besiegungen erzeugen wir eine
Liste von transitiven Besiegungen.
<ol>
<li>Eine Option A besiegt eine Option C transitiv, falls A
C besiegt oder es eine andere Option B gibt, so dass A B
besiegt UND B transitiv C besiegt.</li>
</ol>
</li>
<li>Wir konstruieren die Schwartzsche Menge aus der Menge der
transitiven Besiegungen.
<ol>
<li>Eine Option A ist in der Schwartzschen Menge, falls für alle
Optionen B entweder A transitiv B besiegt, oder B nicht transitiv
A besiegt.</li>
</ol>
</li>
<li>Wenn es Besiegungen zwischen Optionen gibt, die in der
Schwartzschen Menge liegen, so lassen wir die schwächste
solcher Besiegungen aus der Liste der paarweisen Besiegungen
fallen und kehren zu Schritt 5 zurück.
<ol>
<li>Eine Besiegung (A,X) ist schwächer als eine Besiegung
(B,Y) falls V(A,X) kleiner als V(B,Y) ist. Außerdem ist
(A,X) schwächer als (B,Y) falls V(A,X) gleich V(B,Y) ist,
und V(X,A) größer als V(Y,B) ist.</li>
<li>Eine schwächste Besiegung ist eine Besiegung, die keine
andere schwächere Besiegung besitzt. Es kann mehr als eine
solche Besiegung geben.</li>
</ol>
</li>
<li>Falls es keine Besiegungen in der Schwartzschen Menge gibt,
wird der Sieger aus den Optionen in der Schwartzschen Menge
ausgewählt. Falls es nur eine solche Option gibt, ist sie der
Sieger. Falls es mehrere Optionen gibt, bestimmt der
Stimmberechtigte mit der ausschlaggebenden Stimme, welche der
Optionen siegt.</li>
</ol>
<p><strong>Notiz:</strong> Optionen, welche die Wähler über die
Default-Option arrangieren, sind Optionen, die sie annehmbar
finden. Unter die Default-Option arrangierte Optionen sind
Optionen, die sie nicht annehmbar finden.</p>
<p><cite>Wenn das Standard-Entschließungsverfahren benutzt werden
soll, muss der darauf bezugnehmende Text bestimmen, was
ausreicht, um einen Entschließungsentwurf einzubringen und/oder
zu befürworten, wie lange die Mindestfrist für Diskussionen
dauert, und wie lange die Abstimmmungsfrist dauert. Er muss auch jegliche
Supermajorität und/oder das Quorum (und Default-Option)
bestimmen, die zu verwenden sind.</cite></p>
<h2>B. Sprachgebrauch und Typographie</h2><!-- Done -->
<p>Der Präsens Indikativ (zum Beispiel ›ist‹)
bedeutet, dass die Aussage eine Vorschrift in dieser Satzung
ist. ›Darf‹ oder ›kann‹ zeigt an, dass
es im Ermessen der Person oder des Organs liegt.
›Sollte‹ bedeutet, dass es als gute Sache betrachtet
würde, wenn der Satz befolgt würde, aber er ist nicht
bindend. <cite>Als Zitat markierter Text, so wie dieser, stellt nur
Beweggründe dar, und bildet keinen Teil der Satzung. Er darf nur
dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu
helfen.</cite></p>
<p><strong>Anmerkung des Übersetzers: </strong> Obwohl diese
Übersetzung mit Sorgfalt erstellt wurde, ist nur der
englische Originaltext dieser Satzung verbindlich.</p>
Wortwahl und Anmerkungen
Diese Liste enthält einige Begriffe aus devel/constitution, für die es
Sinn ergibt, eine einheitliche Übersetzung zu wählen. In drei Fällen
schlage ich vor, eine auf den Webseiten gewählte Verwendung zu
korrigieren. Das ist aber zur Diskussion gestellt. Es gibt bereits
eine Wortliste im CVS, zu denen, wenn nicht bereits vorhanden, die
neuen Begriffe hinzukommen sollten.
Matthias Lutz, 30/3/2004
-----------------------------------------------------------------
board of the SPI: Board von SPI
constitution: Satzung
'Constitution', obwohl es sprachlich äquivalent zu 'Verfassung' ist,
sollte hier besser mit 'Satzung' übersetzt werden. 'Verfassung' wird
überwiegend bei politischen Gebilden ab einer gewissen Größe
verwendet. Auch regelt 'constitution.wml' eher Verfahrensaspekte,
wogegen bei einer Verfassung zusätzlich gewisse Grundwerte der
verfassten Gemeinschaft niedergeschrieben werden, und für die
formellen Details auf weitere Gesetze verwiesen wird.
(Im Englischen wird 'constitution' auch auf Vereine angewandt.)
casting vote: ausschlaggebende Stimme
default option: Default-Option
'Default' hat hier den Sinn von 'in Ermangelung von Alternativen',
wofür es kein prägnantes deutsches Wort zu geben scheint.
'Standard' scheint nicht den Sinn wiederzugeben, denn ansonsten
würde es bedeuten, dass 'Keiner von den Obigen' oder 'Weitere
Diskussion' die Regel oder die Messlatte bei Abstimmungen ist.
Zweite Wahl: "Vorgabe-Option", was immerhin ausdrückt, dass
diese Option feststeht.
foundation document: Gründungsdokument
Project-Leader: Projekt-Leiter
proposal: Beantragung, Antrag
to propose: beantragen
proposer: Antragsteller
to propose a draft resolution: Entwurf einbringen
to rank options: Optionen arrangieren
Heißt: anordnen, in Rangordnung bringen
(General) Resolution: (Allgemeine) Entschließung
'Entschließung' wird bei nach einem formellen Ablauf getroffenen
Beschlüssen verwandt, und betont den Ablauf, nicht das Ergebnis,
daher passt es besser als 'Beschluss'. Zweite Wahl wäre
'Resolution'.
supermajority: Supermajorität
Eine über die einfache Mehrheit hinausgehende Mehrheit.
'Supermajorität' wird zwar nur von Politologen verwendet, die auf
englische Texte bezugnehmen, der Sinn ergibt sich in der Satzung
jedoch auch aus dem Zusammenhang. Die bekannte 2/3-Mehrheit
entspricht einer '2:1 (super-)majority'.
Secretary: Schriftführer
Technical Committee: Technischer Ausschuss
Reply to: