path: root/debian/data/sisu_markup_samples/dfsg/debian_constitution_v1.2~de.sst

% SiSU 0.38

@title: Debian-Verfassung

@subtitle: Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]

@creator: Debian Project

@type: information

@subject: debian policy

@date.created: 1998-12-03

@date.issued: 1998-12-03

@date.valid: 2003-10-29

@date.available: 2003-10-29

@date.modified: 2003-10-29

@date: 2003-10-29

@language.document: German

@language.original: English

@level: new=C; num_top=1

@skin: skin_debian

@bold: Debian; DPL

% @italics:

@rights: http://www.debian.org/license.de.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.<br>"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.<br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich.

% @rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc.

@links: {Authoritative Source Document}http://www.debian.org/devel/constitution
{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html
{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html
{About Debian}http://www.debian.org/intro/about
{News}http://www.debian.org/News/
{Getting Debian}http://www.debian.org/distrib/
{Support}http://www.debian.org/support
{Developer's Corner}http://www.debian.org/devel/
{Sitemap}http://www.debian.org/sitemap
{Search}http://search.debian.org/

@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original

@rcs: $Id: debian_constitution_v1.2~de.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $

:A~ Debian-Verfassung

:B~ Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3]

1~pre [Prefix]-#

Dies ist die am 29. Oktober 2003 ratifizierte Version 1.2. Sie ersetzt die am 21. Juni 2003 ratifizierte Version 1.1, welche ihrerseits die am 2. Dezember 1998 ratifizierte Version 1.0 ersetzt.

1~ Einleitung

/{Das Debian-Projekt ist ein Verband von Einzelpersonen, die die Schaffung eines freien Betriebssystem zu ihrem gemeinsamen Anliegen gemacht haben.}/

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.

1~ Entscheidungsfindende Organe und Einzelpersonen

Jede Entscheidung innerhalb des Projekts wird von einem oder mehreren der folgenden Organe und Einzelpersonen getroffen:

# Den Entwicklern, durch einen Allgemeinen Beschluss oder eine Wahl.

# Dem Projektleiter;

# Dem Technischen Ausschuss und/oder seinem Vorsitzenden;

# Dem an einer einzelnen Aufgabe arbeitenden Entwickler;

# Vom Projektleiter für bestimmte Aufgaben ernannten Delegierten;

# Dem Projekt-Schriftführer.

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 durch Andere unterworfen sein; in diesem Fall gibt dies der Eintrag des überwachenden Organs oder der Person an. In der obigen Liste ist eine Person oder ein Organ in der Regel vor irgendwelchen Personen oder Organen aufgeführt, deren Entscheidungen sie aufheben können oder die sie ernennen (oder ihnen dabei helfen) – jedoch kann nicht jeder, der vorher aufgeführt wird, jeden, der nachher aufgeführt wird, überstimmen.

2~ Allgemeine Vorschriften

# Nichts in dieser Verfassung 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.

# Eine Person kann verschiedene Ämter innehaben, mit der Ausnahme, dass sich der Projektleiter, der Projekt-Schriftführer und der Vorsitzende des Technischen Ausschusses unterscheiden müssen, und dass der Projektleiter sich nicht zu seinem eigenen Delegierten ernennen kann.

# Eine Person kann das Projekt verlassen oder ein bestimmtes Amt zu jeder Zeit niederlegen, indem sie dies öffentlich erklärt.

1~ Einzelne Entwickler

2~ Befugnisse

Ein einzelner Entwickler darf

# jede technische oder nicht-technische Entscheidung hinsichtlich seiner eigenen Arbeit treffen;

# einen Entwurf zu einem Allgemeinen Beschluss einbringen oder befürworten;

# sich bei Wahlen selbst als Kandidat für das Amt des Projektleiters vorschlagen;

# bei Allgemeinen Beschlüssen und bei Wahlen über die Leitung abstimmen.

2~ Zusammensetzung und Ernennung

# 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 betreuen oder andere Arbeit verrichten, welche der oder die Delegierten des Projektleiters als lohnenswert erachten.

# Der oder die Delegierten des Projektleiters können es vorziehen, keine neuen Entwickler aufzunehmen, oder vorhandene Entwickler auszuschließen. Wenn die Entwickler verspüren, dass die Delegierten ihre Autorität missbrauchen, können sie selbstverständlich die Entscheidung durch einen Allgemeinen Beschluss außer Kraft setzen - siehe §4.1(3), §4.2.

2~ Verfahren

Entwickler können diese Entscheidungen treffen, wie sie es für richtig halten.

1~ Die Entwickler durch einen Allgemeinen Beschluss oder Wahl

2~ Befugnisse

Zusammen können die Entwickler

# Den Projektleiter ernennen oder abberufen.

# Diese Verfassung abändern, vorausgesetzt, sie stimmen dem mit einer 3:1-Mehrheit zu.

# Jede vom Projektleiter oder einem Delegierten getroffene Entscheidung außer Kraft setzen.

# Jede vom Technischen Ausschuss getroffene Entscheidung außer Kraft setzen, vorausgesetzt, sie stimmen dem mit einer 2:1-Mehrheit zu.

# Nicht-technische schriftliche Richtlinien und Erklärungen herausgeben, ersetzen und zurückziehen.

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.

Sie können auch Positionserklärungen zu Tagesfragen hinzufügen.

_# Ein Gründungsdokument ist ein Dokument oder eine Erklärung, die als entscheidend für den Auftrag und die Zwecke des Projekts betrachtet werden.

_# Die Gründungsdokumente sind die Arbeiten mit dem Titel Debian-Gesellschaftsvertrag und Debian Richtlinien für freie Software.

_# Ein Gründungsdokument benötigt eine 3:1-Mehrheit, um ersetzt zu werden. Durch Abändern der Liste der Gründungsdokumente in dieser Verfassung werden neue Gründungsdokumente herausgegeben und vorhandene zurückgezogen.

# Zusammen mit dem Projektleiter und SPI Entscheidungen über mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum treffen. (Siehe §9.1.)

2~ Verfahren

# Die Entwickler befolgen das Standard-Beschlussverfahren – siehe weiter unten. Einen Beschluss oder Abänderung wird eingebracht, indem sie von irgendeinem Entwickler beantragt und von mindestens K anderen Entwicklern befürwortet wird, oder wenn sie vom Projektleiter oder Technischen Ausschuss beantragt wird.

# Aufschieben einer Entscheidung des Projektleiters oder seines Delegierten:

_# Wenn der Projektleiter, sein Delegierter oder der Technische Ausschuss eine Entscheidung getroffen hat, können Entwickler diese überstimmen, indem sie dazu einen Beschluss verabschieden; siehe §4.1(3).

_# Wenn ein solcher Beschluss von wenigstens 2K Entwicklern befürwortet oder vom Technischen Ausschuss beantragt wird, vertagt der Beschluss die Entscheidung unmittelbar (vorausgesetzt, dieser Beschluss selbst besagt dies).

_# Falls die ursprüngliche Entscheidung darin bestand, eine Diskussions- oder Abstimmungsfrist zu ändern, oder wenn der Beschluss darin besteht, den Technischen Ausschuss zu überstimmen, dann brauchen nur K Entwickler den Beschluss zu befürworten, um die Entscheidung unmittelbar vertagen zu können.

_# Falls die Entscheidung vertagt wird, wird eine sofortige Abstimmung abgehalten, um zu bestimmen, ob die Entscheidung solange bestehen bleibt, 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.

_# Falls der Projektleiter (oder der Delegierte) die ursprüngliche Entscheidung zurückzieht, so wird die Abstimmung gegenstandslos und wird nicht weiter durchgeführt.

# Der Projekt-Schriftführer lässt abstimmen. Stimmen, Stimmensummen und Ergebnisse werden während der Abstimmungsfrist nicht offen gelegt; nach der Abstimmung listet der Projekt-Schriftführer alle abgegebenen Stimmen auf. Die Abstimmungsfrist beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden.

# Die Mindestfrist für Diskussionen beträgt zwei Wochen, kann aber durch den Projektleiter um bis zu eine Woche variiert werden. Die Stimme des Projektleiters gibt den Ausschlag. Es gibt ein Quorum von 3Q.

# Anträge, Befürwortungen, Abänderungen, Aufrufe zur Abstimmung und andere formelle Handlungen werden auf einer für die Öffentlichkeit lesbaren Mailingliste bekanntgegeben, die von dem bzw. den Delegierten des Projekt-Leiters bestimmt wird; jeder Entwickler kann dort Beiträge abgeben.

# 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 die Abstimmenden ihre Stimme ändern können.

# 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 sein und werden nicht gerundet.

1~ Projektleiter

2~ Befugnisse

Der Projektleiter darf

# Delegierte ernennen oder Entscheidungen an den Technischen Ausschuss delegieren.

Der Leiter darf einen Bereich mit fortlaufender Verantwortung oder eine bestimmte Entscheidung festlegen und diese an einen anderen Entwickler oder den Technischen Ausschuss übergeben.

Sobald eine bestimmte Entscheidung delegiert und getroffen wurde, darf der Projektleiter diese Delegierung nicht zurückziehen; jedoch darf er eine fortlaufende Delegierung eines bestimmten Verantwortungsbereichs zurückziehen.

# Anderen Entwicklern Vollmacht erteilen.

Der Projektleiter kann Erklärungen zur Unterstützung von Standpunkten oder von anderen Mitgliedern des Projekts abgeben, gebeten oder ungebeten; diese Erklärungen haben dann und nur dann Kraft, wenn der Projektleiter befugt wäre, die fragliche Entscheidung zu treffen.

# Jede Entscheidung treffen, welche dringende Handlung erfordert.

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.

# Jede Entscheidung treffen, für die niemand sonst Verantwortung trägt.

# Entwürfe für Allgemeine Beschlüsse und Abänderungen einbringen.

# Zusammen mit dem Technischen Ausschuss neue Mitglieder in den Ausschuss berufen. (Siehe §6.2.)

# Sich einer ausschlaggebenden Stimme bedienen, wenn Entwickler abstimmen.

Der Projektleiter hat auch eine normale Stimme bei solchen Abstimmungen.

# Die Diskussionsfrist für Abstimmungen der Entwickler variieren (wie oben).

# Diskussionen unter Entwicklern leiten.

Der Projektleiter sollte versuchen, an Diskussionen unter den Entwicklern auf eine hilfreiche Weise teilzunehmen, die versucht, die Diskussion zu den vorhandenen Kernproblemen zu bringen. Der Projektleiter sollte nicht seine Leitungsposition benutzen, um seine eigenen persönlichen Ansichten zu befördern.

# Zusammen mit SPI Entscheidungen treffen, die mit Debian in Beziehung stehendes, treuhänderisch verwaltetes Eigentum betreffen. (Siehe §9.1.)

2~ Ernennung

# Der Projektleiter wird von den Entwicklern gewählt.

# Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.

# In den darauf folgenden drei Wochen kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren.

# 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 bekannt zu machen). Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen verlängert – falls nötig, wiederholt.

# Die nächsten drei Wochen sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.

# Die Wahlmöglichkeiten 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 – viele Male, falls nötig.

# Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist »Niemand von den Obigen«.

# Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.

2~ Verfahren

Der Projektleiter sollte versuchen, Entscheidungen zu treffen, die mit dem Meinungskonsens der Entwickler vereinbar sind.

Sofern es praktikabel ist, sollte der Projektleiter sich informell um die Ansichten der Entwickler bemühen.

Der Projektleiter sollte es vermeiden, seinen eigenen Standpunkt übermäßig zu betonen, wenn er in seiner Eigenschaft als Projektleiter Entscheidungen trifft.

1~ Technischer Ausschuss

2~ Befugnisse

Der Technische Ausschuss darf

# Über jede Angelegenheit entscheiden, die technische Grundsätze betrifft.

Dies schließt die Inhalte der Handbücher für technische Richtlinien, Nachschlagematerial für Entwickler, Beispielpakete und das Verhalten nicht-experimenteller Paketbau-Werkzeuge ein. (In jedem dieser Fälle trifft jedoch der übliche Betreuer der entsprechenden Software oder Dokumentation anfänglich Entscheidungen; siehe §6.3.(5).)

# Über jede technische Angelegenheit entscheiden, in der sich die Entscheidungsbefugnisse von Entwicklern überlappen.

In Fällen, bei denen Entwickler technische Richtlinien oder Standpunkte erfüllen müssen, die miteinander vereinbar sind (zum Beispiel, wenn sie über die Priorität miteinander im Konflikt stehender Pakete oder über das Eigentum am Namen eines Befehls verschiedener Meinung sind; oder darüber, welches Paket für einen Fehler verantwortlich ist, bei dem beide Betreuer sich einig sind, dass er ein Fehler ist; oder darüber, wer der Betreuer eines Pakets sein sollte), kann der technische Ausschuss die Angelegenheit entscheiden.

# Eine Entscheidung treffen, wenn er darum gebeten wird.

Jede Person und jedes Organ kann eine eigene Entscheidung an den Technischen Ausschuss delegieren, oder von ihm Rat einholen.

# Einen Entwickler überstimmen (benötigt eine 3:1-Mehrheit).

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.

# Rat anbieten.

Der Technische Ausschuss kann seine Ansichten über jegliche Angelegenheit formell bekannt machen. Einzelne Mitglieder können natürlich informelle Erklärungen über ihre Ansichten und über die voraussichtlichen Ansichten des Ausschusses abgeben.

# Zusammen mit dem Projektleiter neue Mitglieder in den Ausschuss berufen oder vorhandene Mitglieder abberufen. (Siehe §6.2.)

# Den Vorsitzenden des Technischen Ausschusses ernennen.

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 sofort, wenn es bereits zu spät ist). Die Mitglieder können durch öffentliche Akklamation (d.h. Zuruf) für jedes Mitglied des Ausschusses stimmen, inklusive ihrer selbst; es gibt keine Vorgabe-Wahlmöglichkeit. Die Abstimmung endet, wenn alle Mitglieder abgestimmt haben, oder wenn die Abstimmungsfrist abgelaufen ist. Das Ergebnis wird durch die in §A.6 des Standard-Beschlussverfahrens bestimmte Methode festgelegt.

# Der Vorsitzende kann den Projektleiter zusammen mit dem Schriftführer vertreten.

Wie in §7.1(2) detailliert beschrieben wird, können der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen den Projektleiter vertreten, falls es keinen Projektleiter gibt.

2~ Zusammensetzung

# Der Technische Ausschuss besteht aus bis zu 8 Entwicklern und sollte für gewöhnlich mindestens 4 Mitglieder haben.

# Wenn es weniger als 8 Mitglieder gibt, kann der Technische Ausschuss dem Projektleiter ein oder mehrere neue Mitglieder empfehlen, der seinerseits (im Einzelfall) entscheiden kann, ob er sie ernennt oder nicht.

# Wenn es 5 oder weniger Mitglieder gibt, kann der Technische Ausschuss ein oder mehrere Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht.

# Wenn es für mindestens eine Woche 5 oder weniger Mitglieder gegeben hat, kann der Projektleiter ein oder mehrere neue Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht – dies in Abständen von mindestens einer Woche pro Ernennung.

# Falls der Technische Ausschuss und der Projektleiter sich einig sind, können sie ein im Technischen Ausschuss vorhandenes Mitglied entfernen oder ersetzen.

2~ Verfahren

# Der Technische Ausschuss bedient sich des Standard-Beschlussverfahrens.

Ein Beschlussentwurf 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.

# Einzelheiten, die die Abstimmung betreffen.

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).

# Öffentliche Diskussion und Entscheidungsfindung.

Diskussion, Beschlussentwürfe und Abänderungen, sowie Stimmen von Mitgliedern des Ausschusses werden auf der öffentlichen Diskussionsliste des Technischen Ausschusses veröffentlicht. Es gibt keinen gesonderten Schriftführer für den Ausschuss.

# Vertraulichkeit der Ernennungen.

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.

# Keine Entwurfsarbeit in Einzelheiten.

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.

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.

Einzelne Mitglieder des Technischen Ausschusses können selbstverständlich in eigener Sache an jedem Aspekt der Arbeit an Entwürfen und Richtlinien teilhaben.

# Der Technische Ausschuss fasst Beschlüsse nur als letzten Ausweg.

Der Technische Ausschuss trifft keine technische Entscheidung, solange nicht Anstrengungen, diese durch einen Konsens zu entscheiden, unternommen wurden 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.

1~ Der Projekt-Schriftführer

2~ Befugnisse

Der Schriftführer

# Lässt unter den Entwicklern abstimmen und bestimmt die Anzahl und Person der Entwickler, wann immer dies die Verfassung erfordert.

# Kann zusammen mit dem Vorsitzenden des Technischen Ausschusses an die Stelle des Projektleiters treten.

Wenn es keinen Projektleiter 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.

# Über jegliche Streitigkeit urteilen, die die Auslegung der Verfassung betrifft.

# Kann seine Befugnisse teilweise oder vollständig an jemand anderen übertragen oder eine solche Delegierung zu jeder Zeit zurücknehmen.

2~ Ernennung

Der Projekt-Schriftführer wird vom Projektleiter und dem gegenwärtigen Projekt-Schriftführer ernannt.

Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer sich nicht auf eine neue Ernennung einigen können, müssen sie den Vorstand von SPI (siehe §9.1.) darum bitten, einen Schriftführer zu ernennen.

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.

Die Amtszeit des Projekt-Schriftführers beträgt 1 Jahr, nach dessen Ablauf dieser oder ein anderer Schriftführer (wieder-)ernannt werden muss.

2~ Verfahren

Der Projekt-Schriftführer sollte gerechte und vernünftige Entscheidungen treffen, die vorzugsweise mit dem Konsens der Entwickler vereinbar sind.

Wenn der Vorsitzende des Technischen Ausschusses und der Projekt-Schriftführer zusammen stellvertretend für einen abwesenden Projektleiter handeln, sollten sie nur wenn absolut notwendig Entscheidungen treffen, und nur, wenn diese vereinbar mit dem Konsens der Entwickler sind.

1~ Die Delegierten des Projektleiters

2~ Befugnisse

Die Delegierten des Projektleiters

# haben vom Projektleiter an sie delegierte Befugnisse;

# dürfen 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 betreuen. Dies dient dazu, eine Konzentration von Macht, besonders eine über Mitgliedschaft von Entwicklern, in den Händen des Projektleiters zu verhindern.

2~ Ernennung

Die Delegierten werden durch den Projektleiter ernannt und können vom Projektleiter nach seinem Ermessen ersetzt werden. Der Projektleiter 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.

2~ Verfahren

Delegierte können Entscheidungen treffen, wie sie es für richtig halten, jedoch sollten sie versuchen, gute technische Entscheidungen zu vollziehen und/oder dem Meinungskonsens zu folgen.

1~ Software in the Public Interest (»Software im öffentlichen Interesse«)

SPI und Debian sind getrennte Organisationen, welche einige Ziele miteinander teilen. Debian ist dankbar für die rechtliche Unterstützung, die SPI anbietet. Die Entwickler von Debian sind gegenwärtig Mitglieder von SPI auf Grund ihres Status als Entwickler.

2~ Befugnis

# SPI hat keine Befugnis, die Debians technische oder nicht-technische 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 Debians Verfassung SPI gelegentlich als entscheidendes Organ letzter Instanz verwenden darf.

# 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.

# Debian-Entwickler sind keine 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.

2~ Verwaltung von Eigentum für Zwecke, die mit Debian in Beziehung stehen

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.

SPI hat folgende Zusicherungen gemacht:

# SPI besitzt für mit Debian in Beziehung stehende Zwecke Geld, Warenzeichen und anderes materielle und immaterielle Eigentum und handhabt andere Angelegenheiten.

# Solches Eigentum wird für diese Zwecke, über die Debian und SPI entsprechend dieses Abschnitts entscheiden, treuhänderisch mit separater Rechenschaft verwaltet.

# 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 Projektleiter oder durch Allgemeine Beschlüsse der Entwickler erteilt werden.

# SPI wird in Betracht ziehen, treuhänderisch verwaltetes Eigentum zu verwenden oder zu veräußern, wenn es durch den Projektleiter darum gebeten wird.

# SPI wird für Debian treuhänderisch verwaltetes Eigentum verwenden oder veräußern, wenn es durch einen Allgemeinen Beschluss der Entwickler darum gebeten wird, vorausgesetzt, dass dies mit der rechtlichen Befugnis von SPI verträglich ist.

# 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.

1~a A. Standard-Beschlussverfahren

Diese Vorschriften betreffen gemeinschaftliche Entscheidungsfindung durch Ausschüsse sowie direkte Abstimmungen, wie oben angegeben.

2~a1 A.1. Beantragung

Das formelle Verfahren beginnt, wenn ein Beschlussentwurf beantragt und befürwortet wird, je nach Bedarf.

2~a1a A.1. Diskussion und Abänderung

# Nach der Beantragung kann der Beschluss diskutiert werden. Abänderungen können formell gemacht werden, indem sie entsprechend den Anforderungen an einen neuen Beschluss beantragt und befürwortet werden, oder auf direktem Wege durch den Antragsteller des ursprünglichen Beschlusses.

# Eine formelle Abänderung kann durch den Antragsteller des Beschlusses angenommen werden. In diesem Fall wird der formelle Beschlussentwurf unmittelbar mit der Abänderung in Übereinstimmung gebracht.

# Wenn eine formelle Abänderung nicht angenommen wird, oder einer der Befürworter des Beschlusses 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.

# 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 (wieder müssen sie dann Antragsteller und Befürworter gemäß der Anforderungen sein).

# Der Antragsteller eines Beschlusses 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.

# Der Antragsteller eines Beschlusses kann Veränderungen vornehmen, um unbedeutende 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.

2~a2 A.2. Aufruf zur Abstimmung

# Der Antragsteller oder ein Befürworter eines Antrages oder einer Abänderung kann zur Abstimmung aufrufen, vorausgesetzt, dass die Mindestfrist für Diskussionen (falls vorhanden) abgelaufen ist.

# Der Antragsteller und jeder Befürworter eines Beschlusses können zu einer Abstimmung über diesen Beschluss und alle damit zusammenhängenden Abänderungen aufrufen.

# Die Person, welche zu einer Abstimmung aufruft, gibt bekannt, welches ihrer Ansicht nach die Formulierung des Beschlusses und relevanter 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).

# 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 der ganze Beschluss vorgeschlagen wurde, falls keine Abänderungen vorgeschlagen und angenommen wurden.

2~a3 A.3. Wahlverfahren

# Über jeden Beschluss und die damit zusammenhängenden Abänderungen wird auf einem einzigen Wahlzettel abgestimmt, der jeweils eine Wahlmöglichkeit für den ursprünglichen Beschluss, jede Abänderung und die Vorgabe-Wahlmöglichkeit (wo anwendbar) enthält.

# Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität erfordern. Wahlmöglichkeiten, die nicht explizit eine Supermajorität erfordern, erfordern eine 1:1-Mehrheit.

# Die Stimmen werden nach den Vorschriften in §A.6. gezählt. Die Vorgabe-Wahlmöglichkeit heißt »Weitere Diskussion«, wenn nicht eine andere bestimmt wurde.

# In Zweifelsfällen entscheidet der Projekt-Schriftführer über Angelegenheiten des Verfahrens.

2~a4 A.4. Zurückziehen von Beschlüssen oder nicht angenommenen Abänderungen

Der Antragsteller eines Beschlusses 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.

Ein Befürworter eines Beschlusses oder einer Abänderung (es sei denn, sie wurde angenommen) kann seine Befürwortung zurückziehen.

Wenn die Zurückziehung durch den Antragsteller und/oder die Befürworter bedeutet, dass der Beschluss keinen Antragsteller oder nicht genug Befürworter hat, wird über sie nicht abgestimmt, es sei denn, dies wird berichtigt, bevor der Beschluss verfällt.

2~a5 A.5. Verfall

Wenn innerhalb von 4 Wochen ein vorgeschlagener Beschluss nicht diskutiert, nicht abgeändert, darüber abgestimmt oder 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.

Der Schriftführer kann seiner Erklärung, falls angebracht, auch Vorschläge beifügen, wie man weiter vorgehen soll.

2~a6 A.6. Stimmenzählung

# Der Stimmzettel jedes Abstimmenden rangiert die Wahlmöglichkeiten (d.h.: ordnet ihnen einen Rang zu), über die abgestimmt wird. Nicht alle Wahlmöglichkeiten müssen rangiert werden. Rangierte Wahlmöglichkeiten werden als bevorzugt gegenüber allen nicht rangierten Wahlmöglichkeiten betrachtet. Die Abstimmenden können Wahlmöglichkeiten gleichrangig rangieren. Nicht rangierte Wahlmöglichkeiten werden als einander gleichrangig betrachtet. Einzelheiten darüber, wie Stimmzettel ausgefüllt werden können, werden mit in den »Aufruf zur Abstimmung« aufgenommen.

# Falls der Wahlzettel ein Quorum R fordert, werden alle Wahlmöglichkeiten (außer der Vorgabe-Wahlmöglichkeit), die nicht mindestens R Stimmen erhalten, die diese Wahlmöglichkeit gegenüber der Vorgabe-Wahlmöglichkeit höher rangieren, fallen gelassen.

# Jede (nicht-Vorgabe-) Wahlmöglichkeit, die die Vorgabe-Wahlmöglichkeit nicht mit ihrem benötigten Mehrheitsverhältnis überstimmt, wird fallengelassen.

_# Sind zwei Wahlmöglichkeiten A und B gegeben, so ist V(A,B) die Anzahl der Abstimmenden, die Wahlmöglichkeit A gegenüber Wahlmöglichkeit B bevorzugen.

_# Eine Wahlmöglichkeit A besiegt die Vorgabe-Wahlmöglichkeit D mit einem Mehrheitsverhältnis N, falls V(A,D) echt größer als N * V(D,A) ist.

_# Wenn eine Supermajorität von S:1 für A benötigt wird, beträgt ihr Mehrheitsverhältnis S; im anderen Fall ist ihr Mehrheitsverhältnis 1.

# Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten erzeugen wir eine Liste von paarweisen Besiegungen.

_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit B, falls V(A,B) echt größer als V(B,A) ist.

# Aus der Liste der paarweisen Besiegungen erzeugen wir eine Liste von transitiven Besiegungen.

_# Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit C transitiv, falls A C besiegt oder es eine andere Wahlmöglichkeit B gibt, so dass A B besiegt UND B transitiv C besiegt.

# Wir konstruieren die Schwartzsche Menge aus der Menge der transitiven Besiegungen.

_# Eine Wahlmöglichkeit A ist in der Schwartzschen Menge, falls für alle Wahlmöglichkeiten B entweder A transitiv B besiegt, oder B nicht transitiv A besiegt.

# Wenn es Besiegungen zwischen Wahlmöglichkeiten 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.

_# 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.

_# Eine schwächste Besiegung ist eine Besiegung, die keine andere schwächere Besiegung besitzt. Es kann mehr als eine solche Besiegung geben.

# Falls es keine Besiegungen in der Schwartzschen Menge gibt, wird der Sieger aus den Wahlmöglichkeiten in der Schwartzschen Menge ausgewählt. Falls es nur eine solche Wahlmöglichkeit gibt, ist sie der Sieger. Falls es mehrere Wahlmöglichkeiten gibt, bestimmt der Stimmberechtigte mit der ausschlaggebenden Stimme, welche der Wahlmöglichkeiten siegt.

Anmerkung: Wahlmöglichkeiten, welche die Abstimmenden über die Vorgabe-Wahlmöglichkeit rangieren, sind Wahlmöglichkeiten, die sie annehmbar finden. Unter die Vorgabe-Wahlmöglichkeit rangierte Wahlmöglichkeiten sind Wahlmöglichkeiten, die sie nicht annehmbar finden.

Wenn das Standard-Beschlussverfahren benutzt werden soll, muss der darauf bezugnehmende Text bestimmen, was ausreicht, um einen Beschlussentwurf einzubringen und/oder zu befürworten, wie lange die Mindestfrist für Diskussionen dauert, und wie lange die Abstimmungsfrist dauert. Er muss auch jegliche Supermajorität und/oder das Quorum (und Vorgabe-Wahlmöglichkeit) bestimmen, die zu verwenden sind.

1~b B. Sprachgebrauch und Typographie

Der Präsens Indikativ (zum Beispiel »ist«) bedeutet, dass die Aussage eine Vorschrift in dieser Verfassung 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. Als Zitat markierter Text, so wie dieser, stellt nur Beweggründe dar, und bildet keinen Teil der Verfassung. Er darf nur dazu benutzt werden, um in Zweifelsfällen bei der Interpretation zu helfen.

Anmerkung des Übersetzers: Obwohl diese Übersetzung mit Sorgfalt erstellt wurde, ist nur der englische Originaltext dieser Verfassung verbindlich.

%% SiSU markup sample Notes:
% SiSU http://www.jus.uio.no/sisu
% SiSU markup for 0.16 and later:
%   0.20.4 header 0~links
%   0.22 may drop image dimensions (rmagick)
%   0.23 utf-8 ß
%   0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title)
%   0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6
% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html
% markup in this document is 0.38, (rad) experimental