path: root/german/devel/constitution.1.4.wml

#use wml::debian::template title="Historische Debian-Satzung v1.4" BARETITLE="true"
#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794"
#use wml::debian::toc

  <!--  translation: Matthias Lutz <lutz@lumpix.de>
	   * updated on 2006-10-09 for version 1.3 of the constitution
	   * updated on 2008-02-24 for version 1.4 of the constitution (HK)
  -->

  <h1>Historische Version der Satzung für das Debian-Projekt (v1.4)</h1>

  <p>Dies ist die am 7. Oktober 2007 ratifizierte Version 1.4. Sie ersetzt die
  am 24. September 2006 ratifizierte <a href="constitution.1.3">Version 1.3</a>, 
  die am 29. Oktober 2003 ratifizierte <a
  href="constitution.1.2">Version 1.2</a> und 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.

  Diese Version 1.4 wurde am 09. Januar 2015 durch die
  <a href="constitution.1.5">Version 1.5</a> ersetzt.
  Diese wiederum wurde am 13. Dezember 2015 durch die
  <a href="constitution.1.6">Version 1.6</a> ersetzt.
  Diese wiederum wurde am 14. August 2016 durch die
  <a href="constitution">aktuelle Version 1.7</a> ersetzt.
  </p>

  <toc-display />

  <toc-add-entry name="item-1">1. Einleitung</toc-add-entry>

  <p><cite>Das Debian-Projekt ist ein Verband von Einzelpersonen,
  die die Schaffung eines freien Betriebssystems zu ihrem
  gemeinsamen Anliegen 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>

  <toc-add-entry name="item-2">2. Entscheidungsfindende Organe und Einzelpersonen</toc-add-entry>

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

  <ol>
    <li>Den Entwicklern, durch einen Allgemeinen Beschluss oder
    eine Wahl.</li>

    <li>Dem Projektleiter;</li>

    <li>Dem Technischen Ausschuss und/oder seinem
    Vorsitzenden;</li>

    <li>Dem an einer einzelnen Aufgabe arbeitenden Entwickler;</li>

    <li>Vom Projektleiter für bestimmte Aufgaben ernannten
    Delegierten;</li>

    <li>Dem 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 durch Andere unterworfen sein; in diesem Fall gibt
  dies der Eintrag des überwachenden Organs 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 können oder die sie ernennen (oder
  ihnen dabei helfen) &ndash; jedoch kann nicht jeder, der vorher
  aufgeführt wird, jeden, der nachher aufgeführt wird,
  ü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 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.</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>

  <toc-add-entry name="item-3">3. Einzelne Entwickler</toc-add-entry>

  <h3>3.1. Befugnisse</h3>

  <p>Ein einzelner Entwickler darf</p>

  <ol>
    <li>jede technische oder nicht-technische Entscheidung
    hinsichtlich seiner eigenen Arbeit treffen;</li>

    <li>einen Entwurf zu einem Allgemeinen Beschluss einbringen
    oder befürworten;</li>

    <li>sich bei Wahlen selbst als Kandidat für das Amt des
    Projektleiters vorschlagen;</li>

    <li>bei Allgemeinen Beschlüssen 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
      betreuen oder andere Arbeit verrichten, welche der oder die
      Delegierten des Projektleiters als lohnenswert erachten.</p>
    </li>

    <li>
      <p>Der oder die Delegierten des Projektleiters können es
      vorziehen, keine neuen Entwickler aufzunehmen, oder
      vorhandene Entwickler auszuschließen. <cite>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.</cite></p>
    </li>
  </ol>

  <h3>3.3. Verfahren</h3>

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

  <toc-add-entry name="item-4">4. Die Entwickler durch einen Allgemeinen Beschluss 
  oder Wahl</toc-add-entry>

  <h3>4.1. Befugnisse</h3>

  <p>Zusammen können die Entwickler</p>

  <ol>
    <li>
      <p>Den Projektleiter 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 Entscheidung treffen oder außer Kraft setzen, zu der der
	  Projektleiter oder einer seiner Delegierten befugt ist.
	  </p>
	</li>

	<li>
	  <p>Jede Entscheidung treffen oder außer Kraft setzen, zu der der
	  Technische Ausschuss befugt ist, vorausgesetzt sie stimmen
	  diesem 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 werden.</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>Entscheidungen über treuhänderisch verwaltetes Eigentum
	  treffen, welches mit den Zwecken von Debian in Beziehung
	  steht. (Siehe §9.)</p>
	</li>

	<li>
	  <p>Im Falle einer Meinungsverschiedenheit zwischen dem
	  Projektleiter und dem amtierenden Schriftführer einen neuen
	  Schriftführer ernennen.</p>
	</li>

  </ol>

  <h3>4.2. Verfahren</h3>

  <ol>
    <li>
      <p>Die Entwickler befolgen das
      Standard-Beschlussverfahren &ndash; 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.</p>
    </li>

    <li>
      <p>Aufschieben einer Entscheidung des Projektleiters oder
      seines Delegierten:</p>

      <ol>
        <li>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).</li>

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

        <li>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.</li>

        <li>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.</li>

        <li>Falls der Projektleiter (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 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.</p> </li>

    <li> <p>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.</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 Mailingliste bekanntgegeben, die von dem
    bzw. den Delegierten des Projekt-Leiters bestimmt wird; 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 die Abstimmenden 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 sein und werden
  nicht gerundet.</p> </li> </ol>

  <toc-add-entry name="item-5">5. Projektleiter</toc-add-entry>

  <h3>5.1. Befugnisse</h3>

  <p>Der <a href="leader">Projektleiter</a> darf</p>

  <ol> <li> <p>Delegierte ernennen oder Entscheidungen an den
  Technischen Ausschuss delegieren.</p>

      <p>Der Leiter darf 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 Projektleiter 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 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.</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 Beschlüsse 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 Projektleiter 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 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.</p> </li>

	<li>
	  <p>Im Einvernehmen mit den Entwicklern Entscheidungen fällen,
	  die treuhänderisch verwaltetes Eigentum betreffen, welches mit
	  den Zwecken von Debian in Beziehung steht. (Siehe §9.) Solche
	  Entscheidungen werden den Mitgliedern durch den Projektleiter
	  oder dessen Delegierte(n) mitgeteilt. Bedeutendere Ausgaben
	  sollten beantragt und auf den Mailinglisten debattiert werden,
	  bevor Gelder ausgezahlt werden.</p>
    </li>

	<li>
	  <p>Der Liste von vertrauenswürdigen Organisationen (siehe §9.3)
	  Organisationen hinzufügen oder entfernen, die befugt sind, für
	  Debian Vermögen anzunehmen und zu verwalten.  Die zu einer
	  solchen Entscheidung führende Beurteilung und Diskussion findet
	  auf einer vom Projektleiter oder seines/seiner Delegierten
	  bestimmten Mailingliste statt, auf der jeder Entwickler Beiträge
	  abgeben kann.  Es besteht eine Diskussionsfrist von mindestens
	  zwei Wochen, bevor eine Organisation der Liste
	  vertrauenswürdiger Organisationen hinzugefügt werden kann.</p>
	</li>

  </ol>

  <h3>5.2. Ernennung</h3>

  <ol> <li>Der Projektleiter wird von den Entwicklern gewählt.</li>

    <li>Die Wahl beginnt sechs Wochen, bevor das Amt der Leitung frei
    wird, oder (wenn es bereits zu spät ist) sofort.</li>

    <li>In der ersten Woche kann jeder Entwickler sich
    selbst als Kandidat für das Amt des Projektleiters
    nominieren, und seine Pläne für seine Amtszeit zusammenfassen.</li>

    <li>Danach können für drei Wochen keine weiteren Kandidaten
    nominiert werden; Kandidaten sollten diese Zeit für die
    Wahlkampagne und zur Diskussion nutzen.
    Falls es am Ende der Nominierungsfrist keine Kandidaten
    gibt, so wird die Nominierung um eine zusätzliche Woche verlängert
    &ndash; falls nötig, wiederholt.</li>

    <li>Die nächsten zwei 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.</li>

    <li>Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen
    Kandidaten, die sich selbst nominiert und die Kandidatur noch
    nicht zurückgezogen haben, und zusätzlich <q>Niemand von den
    Obigen</q>. Falls <q>Niemand von den Obigen</q> die Wahl gewinnt, so wird
    das Wahlverfahren wiederholt &ndash; viele Male, falls nötig.</li>

    <li>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 <q>Niemand von den
    Obigen</q>.</li>

    <li>Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.</li>
  </ol>

  <h3>5.3. Verfahren</h3>

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

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

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

  <toc-add-entry name="item-6">6. Technischer Ausschuss</toc-add-entry>

  <h3>6.1. Befugnisse</h3>

  <p>Der <a href="tech-ctte">Technische Ausschuss</a> darf</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 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).)</p>
    </li>

    <li>
      <p>Über jede technische Angelegenheit entscheiden, in der
      sich die Entscheidungsbefugnisse von Entwicklern
      überlappen.</p>

      <p>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.</p>
    </li>

    <li>
      <p>Eine Entscheidung treffen, wenn er darum gebeten wird.</p>

      <p>Jede Person und jedes 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 bekannt machen. <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 Projektleiter neue Mitglieder in den
      Ausschuss berufen oder vorhandene Mitglieder 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 sofort, wenn es bereits zu spät
      ist). Die Mitglieder können durch öffentliche Akklamation
      <cite>(d.h. Zuruf)</cite> 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.</p>
    </li>

    <li>
      <p>Der Vorsitzende kann den Projektleiter zusammen mit dem
      Schriftführer vertreten.</p>

      <p>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.</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 Projektleiter ein oder mehrere neue Mitglieder
      empfehlen, der seinerseits (im Einzelfall) 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 Projektleiter ein oder mehrere neue
      Mitglieder ernennen, bis die Anzahl der Mitglieder 6 erreicht
      &ndash; dies in Abständen von mindestens einer Woche pro
      Ernennung.</p>
    </li>

    <li>
      <p>Falls der Technische Ausschuss und der Projektleiter 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-Beschlussverfahrens.</p>

      <p>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.</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 &ndash; in diesem Fall kann er nur
      seine ausschlaggebende Stimme benutzen).</p>
    </li>

    <li>
      <p>Öffentliche Diskussion und Entscheidungsfindung.</p>

      <p>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.</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>Der Technische 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 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.</p>
    </li>
  </ol>

  <toc-add-entry name="item-7">7. Der Projekt-Schriftführer</toc-add-entry>

  <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 Projektleiters treten.</p>

      <p>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.</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
      anderen ü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 Projektleiter und dem
  gegenwärtigen Projekt-Schriftführer ernannt.</p>

  <p>Wenn der Projektleiter und der gegenwärtige Projekt-Schriftführer
  sich nicht auf eine neue Ernennung einigen können, müssen sie die
  Entwickler auf dem Weg eines Allgemeinen Beschlusses 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 Projektleiter handeln, sollten sie nur wenn absolut
  notwendig Entscheidungen treffen, und nur, wenn diese vereinbar
  mit dem Konsens der Entwickler sind.</p>

  <toc-add-entry name="item-8">8. Die Delegierten des Projektleiters</toc-add-entry>

  <h3>8.1. Befugnisse</h3>

  <p>Die Delegierten des Projektleiters</p>

  <ol>
    <li>haben vom Projektleiter an sie delegierte Befugnisse;</li>

    <li>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. <cite>Dies dient dazu,
    eine Konzentration von Macht, besonders eine über
    Mitgliedschaft von Entwicklern, in den Händen des
    Projektleiters zu verhindern.</cite></li>
  </ol>

  <h3>8.2. Ernennung</h3>

  <p>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.</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 dem Meinungskonsens zu folgen.</p>

  <toc-add-entry name="item-9">9. Für Debian treuhänderisch verwaltetes Vermögen</toc-add-entry>

  <p>In den meisten Gerichtsbarkeiten auf der Welt ist Debian nicht in
  der Lage, direkt Vermögen oder anderes Eigentum zu besitzen. Daher
  muss Eigentum von einer Reihe von Organisationen besessen werden,
  wie in §9.2 genauer beschrieben wird.</p>
  
  <p>Traditionell war SPI die einzige Organisation, die befugt war,
  Eigentum und Gelder für das Debian-Projekt zu besitzen. SPI wurde
  in den Vereinigten Staaten gegründet, um dort Geld treuhänderisch
  zu verwalten.</p>

  <p><a href="https://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.</p>

  <h3>9.1. Beziehung zu angegliederten Organisationen</h3>

  <ol>
	<li>
	  <p>Debian-Entwickler werden nicht allein durch den Vorzug,
	  Debian-Entwickler zu sein, Beauftragte oder Angestellte von für
	  Debian treuhänderisch Vermögen verwaltenden Organisationen, oder
	  voneinander, oder von Personen mit Befugnis im Debian-Projekt.
	  Eine als Entwickler handelnde Person tut dies als
	  Einzelperson, im eigenen Namen.  Solche Organisationen dürfen
	  jedoch aus eigenem Antrieb Beziehungen zu Einzelpersonen
	  unterhalten, die auch Debian-Entwickler sind.</p>
	</li>
  </ol>

  <h3>9.2. Befugnisse</h3>

  <ol>
	<li>
	  <p>Eine Organisation, welche für Debian Vermögen verwaltet, hat
	  keine Befugnis hinsichtlich Debians technischer oder
	  nichttechnischer Entscheidungen, außer, dass keine von Debians
	  Entscheidungen bezüglich irgendwelchen von der Organisation
	  verwalteten Eigentums von der Organisation verlangen möge,
	  außerhalb ihrer rechtlichen Befugnis zu handeln.</p>
	</li>
	<li>
	  <p>Debian beansprucht keine Befugnis über eine Organisation,
	  welche Vermögen für Debian verwaltet, außer der Benutzung des
	  für Debian treuhänderisch verwalteten Eigentums.</p>
	</li>
  </ol>

  <h3>9.3. Vertrauenswürdige Organisationen</h3>
  
  <p>Jegliche Spenden für das Debian-Projekt müssen an eine aus einer
  Reihe von Organisationen gehen, die vom Projektleiter (oder eines
  Delegierten) dazu ernannt wurden, für den Umgang mit für das
  Debian-Projekt verwendetem Vermögen befugt zu sein.</p>

  <p>Organisationen, die für Debian Vermögen treuhänderisch verwalten,
  sollten für den Umgang mit diesem Vermögen angemessene
  Verpflichtungen eingehen.</p>

  <p>Debian unterhält eine öffentliche Liste von vertrauenswürdigen
  Organisationen (<q>List of Trusted Organisations</q>), die Spenden
  annehmen und für Debian Vermögen treuhänderisch verwalten (hierbei
  sind sowohl Sachvermögen als auch geistiges Eigentum
  inbegriffen). Die Liste enthält sowohl die Verpflichtungen, die
  diese Organisationen eingehen, als auch wie mit diesem Vermögen
  umgegangen wird.</p>

  <toc-add-entry name="item-A">A. Standard-Beschlussverfahren</toc-add-entry>

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

  <h3>A.1. Beantragung</h3>

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

  <h3>A.1. Diskussion und Abänderung</h3>

  <ol>
    <li>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.</li>

    <li>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.</li>

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

    <li>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.</li>

    <li>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.</li>
  </ol>

  <h3>A.2. Aufruf zur Abstimmung</h3>

  <ol>
    <li>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.</li>

    <li>Der Antragsteller und jeder Befürworter eines Beschlusses
    können zu einer Abstimmung über diesen Beschluss 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 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 &ndash; 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 der ganze Beschluss vorgeschlagen
    wurde, falls keine Abänderungen vorgeschlagen und angenommen
    wurden.</li>
  </ol>

  <h3>A.3. Wahlverfahren</h3>

  <ol>
    <li>Ü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.</li>

    <li>Die Vorgabe-Wahlmöglichkeit darf keine Supermajorität
    erfordern. Wahlmöglichkeiten, 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 Vorgabe-Wahlmöglichkeit heißt <q>Weitere Diskussion</q>, 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 Beschlüssen oder nicht angenommenen
  Abänderungen</h3>

  <p>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.</p>

  <p>Ein Befürworter eines Beschlusses 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 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.</p>

  <h3>A.5. Verfall</h3>

  <p>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.</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 Abstimmenden rangiert die
    Wahlmöglichkeiten <cite>(d.h.: ordnet ihnen einen
    Rang zu)</cite>, ü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 <q>Aufruf zur Abstimmung</q>
    aufgenommen.</li>

    <li>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.</li>

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

      <ol>
        <li>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.</li>

        <li>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.</li>

        <li>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.</li>
      </ol>
    </li>

    <li>Aus der Liste von nicht fallengelassenen Wahlmöglichkeiten
    erzeugen wir eine Liste von paarweisen Besiegungen.

      <ol>
        <li>Eine Wahlmöglichkeit A besiegt eine Wahlmöglichkeit 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 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.</li>
      </ol>
    </li>

    <li>Wir konstruieren die Schwartzsche Menge aus der Menge der
    transitiven Besiegungen.

      <ol>
        <li>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.</li>
      </ol>
    </li>

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

      <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 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.</li>
  </ol>

  <p><strong>Anmerkung:</strong> 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.</p>

  <p><cite>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.</cite></p>

  <toc-add-entry name="item-B">B. Sprachgebrauch und Typographie</toc-add-entry>

  <p>Der Präsens Indikativ (zum Beispiel <q>ist</q>) bedeutet, dass
  die Aussage eine Vorschrift in dieser Satzung ist. <q>Darf</q>
  oder <q>kann</q> zeigt an, dass es im Ermessen der Person oder des
  Organs liegt.  <q>Sollte</q> 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 <a href=
  "constitution.en.html">englische Originaltext dieser Satzung</a>
  verbindlich.</p>