devel/constitution.wml

[Tsutomu Saito <saio777@xxxxxxxxxxxxxxx>]

齋藤です。

かねこさんより承諾を得て "Debian 憲章" を wml にしました。
かねこさんの依頼により、
4.1 にある「今日現在の問題点のまとめ」という箇所を
「リリース等日時に関する立場表明」に変更してあります。
--
Tsutomu Saito <saio777@xxxxxxxxxxxxxxx>

#use wml::debian::template title="Debian 憲章"
<!--original_revision: 1.2 :-->

<h1> Debian プロジェクトの組織構成(v1.0) </h1>
    
<h2>1. はじめに </h2>

    <cite>Debianプロジェクトはフリーなオペレーティングシステムを作るという
共通の目的を持った人々の連合体である</cite>
    <p>
この文書はこのプロジェクトの正式な意思決定手段を行うための組織
上の構成について記載するものであり、意思決定に直接関連するもの
以外の、このプロジェクトの目的とそれを実現するための手法、ある
いは方針等につき記載するものではない。

<h2>2.意思決定機関と、代表者</h2>
    
このプロジェクトの決定は、以下に挙げる組織もしくは代表者、あるいは
下記の人々の共同作業によって、行われる。

<ol>
<li>連合体としての開発者：一般決議及び選挙の形で
<li>プロジェクトリーダ
<li>技術委員会、およびその議長
<li>個々の開発者：特定の仕事に従事する開発者は、その仕事に関して。
<li>代行者：プロジェクトリーダによって特定の仕事を委任される。
<li>プロジェクト書記
</ol>
    
この文書の以降の部分では、上記の組織と代表者の権限の概略を規定し、
また組織構成、任命手続き、そして意思決定の手順について述べる。上
記個人あるいは組織の権限は、他者に監査される、もしくは制約を
受ける場合があり、本文書はそのような組織または個人の介入に付いて規定する。
<cite>上記に挙げた列挙では、一般に前に挙げられている個人ないし組
織が後に挙げられているものより高い決定権をもつ、あるいは後のもの
を任命する、という関係にあるが、前に挙げられている者が後に挙げら
れている者すべてにわたっての決定を変更できるわけではない。</cite>


    <h3>2.1. 総則 </h3>

    <ol>
      <li><p>
       この憲章は、何人にもこのプロジェクトのために何かをすることを義務づ
けることを意図したものではない。委任された、または割り当てられた仕事を行い
たくない場合には、それを行う必要はない。しかし、この憲章に対して、またこの
憲章にしたがって適切に行われた決定に対して明に反対してはならない。

       </p><li><p>
      一人の人が、プロジェクトリーダ、プロジェクト書記、および技術委員会の
議長の３つのポスト以外のいくつかのポストを兼任することができる。この３つの
ポストについては、別々の人でなければならない。またプロジェクトリーダは自分
自身をプロジェクトリーダ代行に選んではならない。
      </p><li><p>
いつなんどきでも、公にその旨を表明することによって、このプロジェクトを離れ、
あるいは特定のポストから辞任することができる。

    </ol>

<h2>3.個々の開発者</h2>
<h3>3.1.権限</h3>
個々の開発者は、以下列挙されていることを行うことができる。
<ol>
<li>自分の作業対象の範囲で、技術的あるいは非技術上の決定を行なう。
<li>一般決議の提案、発議を行なう。
<li>選挙の際、プロジェクトリーダに立候補する。
<li>決議およびリーダの選挙に対して、投票する。
</ol>

<h3>3.2.構成と任命</h3>
    <ol><li><p>
開発者は、このプロジェクトに参加している間はこのプロジェクトの目的を
進めることに同意した、ボランティアの集まりである。開発者はプロジェクト
のため、パッケージを維持管理する仕事、またはプロジェクトリーダ代行
が有意義であると認めた他の仕事に従事する。
    </p><li><p>
プロジェクトリーダ代行は新規の開発者を拒絶する、あるいは既存の開発
者を解任することができる。<cite>もし開発者が代行がその権限を濫用し
ていると考えた場合には、いうまでもなく一般決議によってその決定を変
更することができる。以下の節を参照のこと： s.4.1(3), s.4.2.</cite>
    </ol>

<h3>3.3.意思決定手順</h3>
開発者は、適切と考えるならそのように決定を行なってよい。

<h2>4. 開発者による決議と選挙</h2>
<h3>4.1.権限</h3>
開発者は連合体として
    <ol>
<li><p>プロジェクトリーダを任命、罷免できる。</p>
<li><p>この憲章を、3:1 の多数決によって修正できる。</p>
<li><p>プロジェクトリーダ代行の判断を変更することができる。</p>
<li><p>2:1 の多数決を持って、技術委員会の判断を変更することができる。</p>
<li><p>技術的なものではないポリシィに関する文書や宣言を公表することができる。
<p>これには、このプロジェクトの目的を記載した文書、他のフリーソフトウェア
を標榜する組織との関係、そして非技術的なポリシィガイドライン、たとえば
Debian のソフトウェアの満たすべきフリーソフトウェアの許諾条件、などが含
まれる。
<p>また、リリース等日時に関する立場表明なども含まれる。</p>
<li><p>プロジェクトリーダ、およびSPI と協力して、Debianに関する目的の
ため保有する資産に関して決定を行う。</p>
    </ol>
    
<h3>4.2.意思決定手順</h3>
    <ol><li><p>
開発者は以下に記載する「標準議事手順」にしたがわなければならない
まず決議文ないしは修正案が開発者によって提案される場合には、少なくとも K 人
の開発者が発議人とならなければならない。また、プロジェクトリーダおよび
技術委員会は決議ないしは修正を提案することができる。

    </p><li><p>プロジェクトリーダおよびその代行の決定の保留について
    <ol><li>
もしプロジェクトリーダ、その代行、および技術委員会が何らかの決定を行った
場合、開発者はその決定を修正決議を通すことにより修正できる。4.1 節参照の
こと。
    <li>
もしそのような決議文が少なくとも 2*K 人の開発者が発議人となっているか、
もしくは技術委員会によって提案されている場合には、明にその旨を記すこと
によってその決議文により問題となっている決定を保留とすることができる。
    <li>
もし、問題となっている決定が討論期間もしくは投票期間の変更に関するも
のであるか、技術委員会の決定である場合には、K 人の開発者が発議人となる
ことにより、問題となっている決定を保留とすることができる。
    <li>
決定が保留となった場合、正規の投票が終了するまでの間問題の決定を保留
としたままとするかどうか、および保留としたままとする場合の処置をどう
するかに関しての緊急即時投票が実施される。この投票では最低得票数は
定めない。
    <li>
もしプロジェクトリーダ（または代行）が問題の決定を取り下げた場合には、
投票は未決とし、それ以上の処置は行わない。
    </ol>
    </p><li><p>
投票はプロジェクト書記が受け付ける。投票内容と中間結果は投票期間中は
公表されない。投票終了後、プロジェクト書記は投票内容のリストを公表す
る。投票期間は２週間であるが、プロジェクトリーダは一週間以内の範囲で
増減を行うことができ、またプロジェクト書記は投票結果が確定した時点で
投票を打ち切ることができる。
    </p><li><p>
最短の討論期間は２週間であるが、プロジェクトリーダは一週間以内の範囲で
増減を行うことができる。最低得票数は 3*Q である。
    </p><li><p>
提案、発議、修正、投票の要請など正式な手続きは、プロジェクトリーダ代行が
管理する一般に公開されたメーリングリスト上で行われる；各開発者はそのメー
リングリストに投稿することができる。
    </p><li><p>
投票はプロジェクト書記が適切とする方法で、E-Mail にて行われる。プロジェ
クト書記は投票ごとに投票者が投票内容を変更することを認めるかどうかを
判断する。
    </p><li><p>
Q は現在の開発者数の平方根の半分である。K は Q と５のいずれか小さい
ほうである。Q と K は整数である必要はないため、丸めは行わない。
    </ol>

<h2>5.プロジェクトリーダ</h2>
<h3>5.1.権限</h3>
プロジェクトリーダは以下の権限を持つ。
    <ol>
<li>代行を任命する。または決定を技術委員会に委任する。
	<p>
プロジェクトリーダは現在の責任分野や決定事項から特定のものを切りだし、
他の開発者や技術委員会にその責任や決定を委任することができる。
	<p>
特定の決定が委任され決定された後に、プロジェクトリーダはその件に関する
委任を取り下げてはならない。ただし、特定の責任分野に関する進行中の委任
ならばいつでも取り下げることができる。

	</p>
<li><p>他の開発者に正式の支持を与える
<p>プロジェクトリーダは、このプロジェクトに関するある見解やある開発者に対する
支援を、求められた場合等に、表明することができる。ただし、この表明は問題と
なる判断に対してプロジェクトリーダが権限を持つ場合にのみ強制力を持つ。

	</p>
<li><p>緊急を要する決定を行う
	<p>
これについては、適切な対応がとられなかったために徐々に緊急性を増
してきた事項に対する決定に対しては、その事項に決まった締め切りが
ある場合を除いては、適用されない。
	</p>
<li><p>他の誰かに決定する権限のないような事項に対して決定を行う。
	</p>
<li><p>一般決議文と、その修正案を提案する。
	</p>
<li><p>技術委員会との協議により、技術委員会の新メンバを任命する(6.2節を参照のこと）
	</p>
<li><p>開発者の投票において、キャスティングボートを持つ。
<p>プロジェクトリーダは、開発者の投票において通常の投票権ももつ。
	</p>
<li><p>開発者投票において、討論期間を変更する（上記参照）。
	</p>
<li><p>開発者間の討論をリードする。
	<p>
プロジェクトリーダは、開発者間の討論が鍵となる問題に直接関連した討論と
なるよう手助けになることを意図して、討論に参画すべきである。プロジェクト
リーダは、自らの個人的見解を通すためにリーダーシップをとるべきでない。
	</p>
<li><p>SPIとの協議に基づき、Debian に関連した目的のため保有する資産に
かかわる決定を行なう。
    </ol>

<h3>5.2.任命</h3>
    <ol>
      <li>
プロジェクトリーダは開発者の選挙によって選出される。
      <li>
選挙は、リーダの地位が空席となる９週前、あるいはすでにそれ以下の期間
しかなくなっている場合には即時、に開始される。
      <li>
引き続く３週間の間、開発者はプロジェクトリーダ候補者として立候補する
ことができる。
      <li>
３週間の終了後、新たな立候補者は受け付けられない。候補者はこの期間に
選挙活動（自らの経歴と主張の周知を図る）を行うべきである。もしも立候
補の受付期間が終了した時点で立候補者がいなかった場合には、立候補の受
付期間は３週間単位で（必要に応じて繰り返し）延長される。
      <li>
次の３週間は投票期間であり、開発者は投票を行うことができる。リーダ選
挙の投票は秘密投票であり、投票内容は投票終了後も公開されない。
      <li>
投票は、立候補した候補者（立候補の取下げを行った者は除く）に対して、
または「全員不可」とすることができる。もし「全員不可」が最大得票を
集めた場合には選挙手続きが必要なだけ何度でも繰り返される。

<li>決定はコンコード得票によって行われる。最低得票数は、一般決議(4.2節）
に同じで、最低得票数に達さなかった場合の既定の選択は「全員不可」である。
      <li>
選出されたプロジェクトリーダは１年の任期を務める。
    </ol>

<h3>5.3.意思決定手順</h3>
<p>プロジェクトリーダは、開発者の意見の総意に添う決定を行うよう努め
るべきである。
<p>プロジェクトリーダは、そうできる場合には、非公式に開発者の見解を
求めるべきである。
<p>プロジェクトリーダはリーダの裁量に基づき決定を行うにあたって、自
らの見解を過度に打ち出すことを控えるべきである。

<h2>6.技術委員会</h2>
<h3>6.1.権限</h3>
技術委員会は以下の権限を持つ。
    <ol>
<li>技術的方針に関する事項に関して決定を行う。
<p>これには、技術面でのポリシーマニュアルの内容、開発者の参照する個々
の資料、例題パッケージや実験段階を脱したパッケージ構築ツールの挙動等
が含まれる（その個々の事項においては、問題のソフトウェアや文書のメン
テナが、まず一次決定を行う。6.3(5)を参照のこと）
</p>
<li>開発者間で管轄範囲が重なる場合の技術的事項の判断を行う
	<p>
開発者間で技術的方針や立場の調整を行う必要があるとき
（たとえば、競合するパッケージ間の優先順位についてや、コマンド名の
所有権の調整について、またパッケージ間で両開発者がバグとは認めてい
るものも何れのパッケージで修正すべきかについて、そしてパッケージの
メンテナが誰であるかについて、などの問題で開発者間で意見の相違があ
るとき）技術委員会が判断を行うことができる。
	</p>
<li><p>要請された場合、決定を行う。
<p>任意の個人、あるいは組織は自らの決定を技術委員会にゆだねる、あるいは
技術委員会に助言を求めることができる。
	</p>
<li><p>開発者の決定を修正する（3:1の多数決が必要）
	<p>
技術委員会は開発者に対してある種の技術的な一連の作業を行うよう要求する
ことができる。但し、これには 3:1 の多数決を必要とする。
例えば、技術委員会はバグ指摘者の修正要求を正当なものと認め、その指摘者
の提案する解決案を実施するべきであると決定することができる。
	</p>
      <li><p>
答申を行う。
	<p>
技術委員会は、どのような件に関しても、委員会の正式見解を公表することが
できる。<cite>もちろん、技術委員会の個々のメンバは自分の見解や、
技術委員会の見解に関する推察に関して非公式に意見を述べることができる</cite>
	</p>
<li><p>プロジェクトリーダとともに、技術委員会の新メンバの任命と、
既存メンバの解任を行う（6.2節参照のこと）。
	</p>
<li><p>技術委員会の議長を任命する。
<p>議長は、技術委員会のメンバのなかから互選される。技術委員会の全メンバが
自動的に立候補したとみなされ、議長が空席となる一週間前（あるいは
すでに遅すぎる場合には即時）から委員会投票が行われる。メンバは、自分
たち自身を含む委員会メンバ間の議場委任に投票することができる。「全員
不可」という選択肢はない。投票は全メンバの投票が終了した時点、あるいは
当選者が確実になった場合に終了する。結果は コンコード得票で決定される。
	</p>
<li>議長はプロジェクト書記との合議によってリーダの代行を行う。
	<p>
7.1(2) 節記載のとおり、技術委員会議長はプロジェクト書記との合議によっ
てリーダ不在の際のリーダの代行を行う。
    </ol>

    <h3>6.2. 構成</h3>
    <ol><li><p>
技術委員会は最大８名、そして通常は少なくとも４名以上、の開発者
で構成される。
    </p><li><p>
技術委員会のメンバ数が８名未満である場合、技術委員会はプロジェクト
リーダに新メンバを推薦でき、プロジェクトリーダは各人別に任命の採否を
決定できる。

    </p><li><p>
技術委員会のメンバ数が５名以下である場合、技術委員会は新メンバを総
メンバ数が６名に達するまで任命することができる。

    </p><li><p>
技術委員会のメンバ数が５名以下である状態が一週間以上続いた場合、
プロジェクトリーダは新メンバを総メンバ数が６名に達するまで任命する
ことができる。但し、この場合は各任命ごとに一週間以上の間隔を取ら
なければならない。

    </p><li><p>
技術委員会とプロジェクトリーダが合意した場合、技術委員会のメンバを解任、
もしくは交代させることができる。
    </ol>

<h3>6.3. 意思決定手順</h3>
    <ol>
<li>技術委員会は標準議事手順を用いる。
	<p>
決議文および修正案を技術委員会のメンバから提案することができる。
この場合最短の討論期間は定めない。投票期間は一週間、または結果に
疑いの余地がなくなるまで続く。メンバは自分の投票を変更することが
できる。最低得票数は２である。
	</p>
<li>投票に関する詳細
<p>
議長がキャスティングボートをもつ。技術委員会が、委員会のメンバである
開発者の決定を変更しようとする場合には、そのメンバは投票してはな
らない（議長を除く。議長の場合にはキャスティングボートのみをもつ）
	</p>
<li>公開の討議と決定
<p>
討論、決議文と修正案、および投票は技術委員会の公開討議メーリング
リストにて公開の元に実施される。委員会に別途書記を置くことはしない。

	</p>
     <li>
任命に関する討議の秘密性
<p>技術委員会は技術委員会のメンバの任命を討議する場合は個人宛て
電子メール、非公開メーリングリストなどを用いて秘密討議を行うこと
ができる。ただし、任命に関する投票は公開しなければならない。
	</p>
      <li>
詳細策定作業への不干渉
	<p>
技術委員会は新しい提案の計画や方針の立案には関与しない。そのような
立案作業は各個人が個々または集団で遂行するべきものであり、
技術上の方針や設計を行う通常の討議の場で討論される。
	<p>
技術委員会は、他で提案され十分かつ通して討論されてきた解決案
または決定案のうちから選択を行ったり、折衷案を作成する作業に
限って行う。

	<p>
<cite>技術委員会の個々のメンバが自分自身のため計画や方針の策定作業の
各局面に参画することは、もちろん行ってよい。</cite>
	</p>
<li>最後の手段としての技術委員会の決定
<p>技術委員会は合意による解決の努力の試みが失敗するまでは、
その件に関する責任を持つ個人もしくは組織から特に要請されない限り、
技術的な決定を行わない。
    </ol>

    <h2>7. プロジェクト書記</h2>
    <h3>7.1. 権限</h3>

    書記は以下の権限を持つ：
    <ol>
      <li>
        <p>
    憲章に規定されている場合に、開発者からの投票を受け、その数と投票有効性の
認証を行う。
	</p>
      <li>
        <p>
   技術委員会の議長と協力し、リーダの代行を行う。
	<p>
プロジェクトリーダが不在の際、技術委員会の議長とプロジェクト書記の両名が
緊急と認めた場合には、合意に基づき決定を行うことができる。
	</p>
      <li>
	<p>
憲章解釈に関する論争に対して、裁定を行う。
	</p>
      <li>
        <p>
自己の権限の一部、あるいは全体を誰かに委任することができる。またその委
任をいつでも取り下げることができる。
    </ol>

    <h3>7.2. 任命 </h3>
    <p>
      後任のプロジェクト書記は、プロジェクトリーダと現在のプロジェクト
書記によって指名される。
    <p>
プロジェクトリーダと現在のプロジェクト書記が指名について合意に達さない
場合は、両名は SPI 協議会に書記の指名を求めなければならない。
    <p>
もしプロジェクト書記が不在または職務を遂行できない状態であり、かつ決定の
委任を行っていない場合は、プロジェクト書記の行うべき決定は、技術委員会の
議長が実施するか、適当な者に暫定書記として委任しなければならない。
    <p>
プロジェクト書記の任期は一年である。期間満了後は、（再）指名を行わなけれ
ばならない。

<h3>7.3.意思決定手順</h3>
プロジェクト書記は、公正で妥当であるならそのように決定を行なってよ
いが、それが開発者の総意に矛盾しない判断であるべきである。
    <p>

プロジェクトリーダが不在の際、技術委員会の議長とプロジェクト書記の両名が
どうしても必要と認めた場合には、開発者の総意に矛盾しない範囲でプロジェクト
リーダの代理として技術委員会の議長と共に決定を行うことができる。
      
<h2>8.プロジェクトリーダ代行</h2>
<h3>8.1.権限</h3>
プロジェクトリーダ代行は以下の権限を持つ
<ol>
<li>プロジェクトリーダから委任された権限を持つ。
<li>プロジェクトリーダが直接関与することを許されない事項につき決定を
行なう。そのような事項には、開発者の承認と除名、パッケージを維持管理
しない開発者の解任、などが含まれる。
<cite>これは、プロジェクトリーダに開発者の人選を委ねる事によって、権
限が過度に集中するのを避けるためである</cite>
</ol>

<h3>8.2.任命</h3>
代行はプロジェクトリーダによって、プロジェクトリーダの自由裁量に基
づき、任命されあるいは解任される。ただし、プロジェクトリーダは、
代行の職務権限を代行の個々の決定内容に依存するものとしたり、代行の
行った決定を変更することはできない。

<h3>8.3.意思決定手順</h3>
代行は、適切と考えるならそのように決定を行なってよいが、技術的に妥当
な決定となるよう、また開発者総意に則るよう、努めるべきである。

    <h2>9. Software in the Public Interest</h2>

SPIとDebian はいくつかの目的を共有する別の組織である。Debian は SPI
によって提供される法的支援の枠組みに感謝する。
    <cite>
Debianの開発者は、開発者であることをもって同時に SPI のメンバとなる。
    </cite>
    
<h3>9.1. 権限</h3>
    <ol>
      <li>
SPI は、Debian 組織体が SPIの保有する
（有形、無形の）資産に関して SPI の法的権限から外れる行動を SPI に対
して求めるような決定は行わないこと、また場合によっては Debian 組織体は
SPI を最後の手段として決定主体に用いることができること、を除いては
Debian の技術的、非技術的な決定に対して権限を持たない
      <li>
Debian は SPI に対して、下記のとおりある種の SPI の資産を利用する
以外の権利を有しないが、SPI の規則に従い SPI の内で Debian の開発者
に権限が与えられることがある。
      <li>
Debian の開発者は SPI の代理人でも雇用者でもない。また、開発者
は集団としても個人としても Debian プロジェクトの代表者ではない。
開発者として行動する個人は、個人として自分のために行動するもの
とする。
    </ol>

<h3>9.2. Debianに関係した目的のための資産管理</h3>
Debian組織体は金銭や財産を保有する権限を有しないため、Debian
プロジェクトに対する寄付はそのような事務処理を行う SPI に対し
て行なわなければならない。
	<p>
SPIは以下を請け負う：
    <ol>
      <li>
SPIは Debian に関係した目的のため、金銭、商標および他の有形
または無形の資産を管理し、その他の事務処理を行う。
      <li>
そのような資産は個別に管理され、この節記載の通り Debian と
SPI によって決定される目的のために信託される。
      <li>
SPIは Debian からの承認なき限り信託された資産を処分ないしは利用
することはない。このような承認は、プロジェクトリーダ、もしくは
開発者の一般決議によって行うことができる。
      <li>
SPI は、プロジェクトリーダからその旨の要請があった場合、Debian
より信託された資産を利用ないしは処分する検討を行う。
      <li>
SPI は、開発者の一般決議によりその旨の要請があった場合、それが
SPI の法的権限の及ぶ範囲であるならば Debian より信託された資産
を利用ないしは処分する検討を行う。
      <li>
SPI は、Debianより信託された資産を利用ないしは処分する際には、
Debian プロジェクトメーリングリストにより電子メールを用いて
開発者に対して通告を行なう。

    </ol>

<h2>A. 標準議事手順</h2>
この規定は、上記委員会および構成員投票の自治意思決定に用いる。

<h3>A.1. 提案</h3>
正式な手続きは、必要要件に従い決議文が提案され、発議された時点に始まる
    <h3>A.1. 議事と修正動議</h3>
    <ol>
      <li>
提案の後、決議文は討議に入る。修正案は新規の決議文の必要要件を
満たす形で提案・発議されるか、もともとの決議文の提案者から提案
された場合、正式なものとして扱われる。
      <li>
決議文の提案者はそのような正式修正案を受け入れる
ことができる。その場合、正式の決議文は即座に修正案に沿って変更さ
れる。
      <li>
もし正式な修正案が受け入れられない、または決議文の発起人の
少なくとも一名が修正案の提案者の上記受け入れ処置に反対した場合、
修正案は修正案のまま扱われ投票の対象となる。
      <li>
もし、原提案者に受け入れられた修正案にたいして納得がいかない場合、
不賛成の人は先の修正を元に戻す新たな修正案を提案することができる。
この場合も同様に修正案の提案と発議の条件を満たさなければならない。
      <li>
決議文の提案者は、修正案の字句に対して変更を示唆することが
できる。この示唆は修正案の提案者が受け入れ、修正案の発起人
から異論が出なければ有効となる。この場合には、変更された修
正案が原案の代わりに投票に付されることになる。
	  <li>
決議文の提案者は、２４時間の間に反対者が出ない場合、小修正
（たとえば字句修正や矛盾の解消）、意味を変更しない範囲での
変更を行うことができる。この場合には最小討論期間の再スタート
は行わない。
    </ol>

    <h3>A.2. 投票発議</h3>
    <ol>
      <li>
決議案および修正案の提案者および発起人は最小討論期間満了後
投票の発議を行うことができる。
      <li>
決議案の提案者および発起人は、全部ないしはいくつかの修正案を
個別もしくは一括して投票に付す発議を行うことができる。
修正案の提案者はその修正案と関連した修正案について投票に付す
発議を行うことができる。
      <li>
投票の発案者は、決議案の文面と適切な修正案群、および投票形態に
関して考えることを明らかにしなければならない。
しかしながら、最終の投票に付される形態の判断はプロジェクト書記が
行なう（7.1(1),7.1(3)およびA.3(6)参照のこと）
      <li>
最短の討論期間は、最終の正式修正案が受け入れられたか、修正案が投票
に付されるならば関連した最終の修正案が受け入れられた時点、または修
正案が提案かつ受け入れられていないならば、決議文提案の時点から、
計算される。
    </ol>

<h3>A.3. 投票手続き </h3>
    <ol>
      <li>
関連する修正案を集めた修正案群は、独立した群ごとに別々の投票とする。
そのような投票では、意味のある修正案の組み合わせ、および選択肢
「討論の継続」が選択肢となる。
もし「討論の継続」が勝者となった場合には、決議手続き全体が
討論期間のはじめから戻り再開される。
修正案には最小得票数は規定しない。
      <li>
決議の最終文案が定まった後、それが最終投票に付される。
この場合の選択肢は「はい」、「いいえ」および「討論の継続」
である。もし「討論の継続」が勝者となった場合には、
決議手続き全体が討論期間のはじめから戻り再開される。

      <li>
投票管理人（が規定されている場合）または有権者（投票が公告に
基づき実施される場合）は、これらの投票を同時に実施するよう
（極端な場合は、例えば、一通の投票電子メールで）調整することができる。
もし修正案に関する投票と最終投票が同時に実施される場合には、
有権者が最終の決議案が取りうる形態のおのおのに対して異なる
票を投じることができるようにしなければならない。
      <li>
投票は他の個所で規定している通り投票期間中に行なう。もし結果の確定
により投票期間を終了させる場合には、投票者が自らの投票内容を修正す
る可能性は考慮されない。
      <li>
投票はコンコード得票により実施する。もし最小得票数が規定されている場合は
規定の選択肢は「討論の継続」とする。
      <li>
手続き的な部分で疑念が生じたときには、プロジェクト書記が決定する。
（例えば、特定のいくつかの修正案を独立のものとみなすか否かなど）
    </ol>

    <h3>A.4. 決議文の取り下げ、不採択の修正案の扱い</h3>
決議文の提案者、不採択となった修正案の提案者は提案を取り下げる
ことができる。その場合には、他の提案者によってその提案を引き継ぐ
ことができる。引継ぎの場合では、最初に引継ぎを通告した人が新たな
提案者となり、引継ぎ時点で新たに発起人を募ることができる。
<p>
決議文および修正案（採択されていない限り）の発起人は、発起を取り
消すことができる。
<p>
もし提案者もしくは発起人の取り下げに伴い決議文に提案者が不在とな
るか、発起人の人数要件を満たさなくなった場合、決議文が廃案と
なる前にその状況が修正されない限り投票には付されない。

<h3>A.5. 廃案</h3>
もし提案された決議が四週間にわたって討論、修正、投票されず、その他
の何らかの処置の状態にもない場合には、取り下げたものとして扱われる。
    
<h3>A.6. コンコード得票</h3>
    <ol>
      <li>
これは列挙された選択肢から勝者を選び出すために用いる。
投票用紙には投票者の望む選択肢が順序付きで記載される（すべての
選択肢について順序がつけられる必要はない）
      <li>
選択肢AがBより優位であるとは、AよりBを選んだ投票がBよりAを選んだ
投票より多いこと、のみを意味する。
      <li>
少なくとも１つのより優位な選択肢をもつ選択肢は捨てられ、投票用紙
に記載されたその選択肢に関する言及は無視される。
      <li>
もしすべてのほかの選択肢より優位なものがあるなら、それが勝者である。
      <li>
この時点で複数の選択肢が残っている場合には単一遷移得票法
が残りに対して適用される。
	<ul>
	  <li>
各選択肢に対して第一優先とした投票を数える。もし１つの選択肢が
過半数を得ているなら、それが勝者である。
	  <li>
勝者が決まらない場合には、第一優先とした投票の最も少ない選択肢
を除外して、第二優先とした投票に対し同様の処理を行う。
	  <li>
この除外処理を第二優先、第三優先、第四優先…と必要なだけ過半数を
得る選択肢が出るまで繰り返す。
	</ul>
      <li>
同点の場合には、キャスティングボートをもつ選挙人が判断する。この
キャスティングボートは普通の投票の数には入れない。但し、この選挙人
は通常普通の一票の投票権も持つ。
      <li>
もし多数決以上の多数が必要となる場合、最後の投票集計の YES
の投票は指定された係数にしたがって削る。より厳密に言えば、F:A
の多数決が要求されている場合、Yes より他の選択肢Xを優先する
とした選択肢の数（Yes が X より優位にある、または X が Yes
より優位にある場合)、および第一（もしくは第二以降）優先とした
投票の数（単一遷移得票法が勝者決定と除外を行うために用いられて
いる場合）を A/F 倍してから比較を実施する。
	<cite>
即、2:1 の多数とは、対抗選択肢の２倍の人がその選択肢に
投票するということである。棄権は数に入れない。
	</cite>
      <li>
最低得票数が必要である場合には、既定の選択肢より少なくとも指定数
以上の得票差が勝者となった選択肢になければならない。そうでなければ
既定の選択肢が勝者となる。もし投票が多数決以上の多数を要求する場合
には、最低得票数に達したかどうかの判定は実際の得票数で行われる。
    </ol>

<cite>
標準議事手順が使われるとする場合には、その本文中に決議文の提案または
発議になにが必要であるかを規定し、最短の討論期間、投票期間を定めなけ
ればならない。また多数決以上の多数や、最小得票数（または規定の選択肢）
を用いるかどうかを記載しなければならない。</cite>

<h2>B. 凡例</h2>
現在形はその位置文が本憲章において規則であることを意味している。しても
よい、またはできる、という語は個人もしくは組織が選択できることを示して
いる。「べきである」という記載はその文の内容に従うことが望ましいと考え
られるが、義務ではないことを示している。<cite> 引用としてマーキングさ
れた文（こんな風に）は注釈を示し、憲章の一部ではない。これは疑問が生
じた場合の解釈の助けにのみ用いる。</cite>