注意: 原文はこの翻訳よりも新しくなっています。

歴史的バージョンの Debian 憲章 v 1.0

歴史的バージョンの Debian プロジェクト憲章 (v1.0)

現行の Version 1.7 は 2016 年 8 月 14 日に批准され、Version 1.6 を更新した。 Version 1.6 は 2015 年 12 月 13 日に批准され、Version 1.5 を更新した。 Version 1.5 は 2015 年 1 月 9 日に批准され、Version 1.4 を更新した。 Version 1.4 は 2007 年 10 月 7 日に批准され、Version 1.3 を更新した。 Version 1.3 は 2006 年 9 月 24 日に批准され、Version 1.2 を更新した。 Version 1.2 は 2003 年 10 月 29 日に批准され、 Version 1.1 を更新した。 Version 1.1 は 2003 年 6 月 21 日に批准され、 Version 1.0 を更新した。 Version 1.0 は 1998 年 12 月 2 日に批准された。

1. はじめに

Debian プロジェクトは、フリーなオペレーティングシステムを作る、という共通の目的を持った人々の連合体である。

この文書は、Debian プロジェクトの公式な意思決定に関わる組織構成について記述する。 Debian プロジェクトの目的やその実現方法については記述しない。また意思決定プロセスに直接関連しない方針についても記述しない。

2. 意思決定機関と個人

このプロジェクトの意思決定は、以下のひとつまたは複数によって行われる。

開発者 (Developer) の集団 (一般決議 (General Resolution) および選挙による)
プロジェクトリーダ
技術委員会 (Technical Commitee) およびその議長
特定の作業に従事している開発者個人
プロジェクトリーダから特定の作業を委任された代行者 (Delegate)
プロジェクト書記 (Project Secretary)

この文書の以降の大部分では、上記各主体の権限、それらの構成、任命手続き、意思決定手順の概略について述べる。上記個人あるいは組織の権限は、他者に監査もしくは制約される場合がある。この場合、監査者の組織または個人のエントリがこれを表す。上記のリストで先に挙げられている個人ないし組織は、後に挙げられている者より一般に高い決定権を持つ。あるいは前者は後者を任命する、という関係にある。ただし先に挙げられている者が後に挙げられている者の決定を常に変更できるわけではない。

2.1. 総則

この憲章におけるあらゆる記述は、誰かにこのプロジェクトに対する作業を義務づけようとするものではない。委任された、または割り当てられた仕事を行いたくない場合には、それを行う必要はない。しかし、この憲章の規則に反して、またこの憲章に従って適切になされた決定に反して意図的に行動をとってはならない。
あるひとりの個人は複数のポストを兼任できるが、プロジェクトリーダ、プロジェクト書記、技術委員会議長の三つのポストは例外であり、この三つのポストには別々の人がつかなければならない。またプロジェクトリーダは自分自身を代行者に選んではならない。
ある個人は、公にその旨を表明することによって、いつなんどきでもこのプロジェクトを去ったり、特定のポストから辞任することができる。

3. 個々の開発者

3.1. 権限

個々の開発者は以下の権限を持つ。

自分の作業対象の範囲で、技術的あるいは非技術的な決定を行なう。
一般決議の草案を提案する、またはその賛同者となる。
選挙の際、プロジェクトリーダに立候補する。
一般決議およびリーダの選挙に対して投票する。

3.2. 構成と任命

開発者は、このプロジェクトに参加している間、その目的を進めることに同意したボランティアの集まりである。開発者はプロジェクトのパッケージを維持管理する仕事や、またはプロジェクトリーダ代行者が有意義であると考える、その他の仕事に従事する。
プロジェクトリーダ代行者は新規の開発者を拒絶したり、あるいは既存の開発者を解任することができる。代行者がその権限を濫用していると開発者たちが考えた場合には、もちろん一般決議によってその決定を変更できる。 4.1(3) 節および 4.2 節を見よ。

3.3. 意思決定手順

開発者は、自分が適切と考える通りに決定を行なってよい。

4. 開発者の集団 (一般決議および選挙による)

4.1. 権限

開発者は集合体として以下の権限を持つ。

プロジェクトリーダを任命、罷免できる。
3:1 の賛成多数をもって、この憲章を修正できる。
プロジェクトリーダおよび代行者の決定を覆すことができる。
2:1 の賛成多数をもって、技術委員会の判断を覆すことができる。
技術的なものではない方針 (policy) 文書や宣言を公表できる。

これらの文書には、このプロジェクトの目的を述べたもの、他のフリーソフトウェア組織との関係を述べた、非技術的な方針ガイドライン (たとえば Debian のソフトウェアの満たすべきフリーソフトウェアの許諾条件) などが含まれる。

また日時に関る立場の表明などもこれらの文書に含まれる。
プロジェクトリーダおよび SPI と協力して、 Debian に関連する目的のために保有されている資産に関する決定を行う。 (9.1 節を見よ。)

4.2. 意思決定手順

開発者は後述する「標準議事手順 (Standard Resolution Procedure)」に従う。決議文ないし修正案は、ある開発者によって提案され、 K 人以上の開発者がその賛同者となれば、議事の対象となる。またプロジェクトリーダまたは技術委員会から提案された決議文ないし修正案は議事の対象となる。
プロジェクトリーダまたはその代行者による決定を保留する:
1. プロジェクトリーダ、その代行者、技術委員会のいずれかが何らかの決定を行った場合、開発者は修正決議を通すことによりその決定を覆すことができる。 4.1(3) 節を見よ。
2. そのような決議文が、2*K 人以上の開発者が賛同者となっているか、もしくは技術委員会によって提案されている場合には、決議文にその旨を記すことによって、その決議文の対象である決定を直ちに保留とすることができる。
3. 問題となっている決定が討論期間もしくは投票期間の変更に関するものであるか、あるいはその決定が技術委員会の決定を覆すためのものである場合には、 K 人の開発者が賛同者となることにより、問題となっている決定を直ちに保留とすることができる。
4. その決定が保留となった場合は、直ちに投票が実施され、正規の投票が終了するまでの期間、その決定の実施を有効とするか、実施せずに保留とするかを定める。この緊急投票では必要最低得票数は定めない。
5. もしプロジェクトリーダ (または代行者) がもともとの決定を取り下げた場合には、投票は未決とし、それ以上の処置は行わない。
投票はプロジェクト書記が処理する。投票期間中には、投票内容と中間結果は公表されない。投票終了後、プロジェクト書記は投票内容のリストを公表する。投票期間は二週間であるが、プロジェクトリーダは一週間以内の範囲でこれを変更できる。またプロジェクト書記は投票結果が確定した時点で投票を打ち切ることができる。
最短の討論期間は二週間であるが、プロジェクトリーダは一週間以内の範囲でこれを変更できる。必要最低得票数は 3*Q である。
提案、賛同、修正、投票の要請などの正式な手続きは、プロジェクトリーダ代行者が管理する、一般から閲覧可能なメーリングリスト上で行われる。全ての開発者はそのメーリングリストに投稿できる。
投票はプロジェクト書記が適切とする方法で、電子メールにて行われる。プロジェクト書記は、投票者による投票内容の変更を認めるかどうかを、投票ごとに判断する。
Q は現在の開発者数の平方根の半分である。 K は Q と５のいずれか小さいほうである。 Q と K は整数である必要はないため、丸めは行わない。

5. プロジェクトリーダ

5.1. 権限

プロジェクトリーダは以下の権限を持つ。

代行者を任命する。または決定を技術委員会に委任する。

プロジェクトリーダは、その職責の一部や特定の決断事項を定義して、その責任や決定を他の開発者や技術委員会にを委任できる。

特定の決断事項に対する委任がなされた後は、プロジェクトリーダはその委任を取り下げることはできない。ただし、職責の一部に対する委任は取り下げることができる。
他の開発者を支持する。

プロジェクトリーダは、求められた場合 (あるいは求められなくても)、ある意見やプロジェクトのメンバに対する支持を表明できる。ただしこの表明は、プロジェクトリーダがその問題に対する決定権を持っている場合に限って強制力を持つ。
緊急を要する決定を行う。

その決定の緊急性が (適切な対応がとられなかったために) 徐々に増してきたような場合については、これは適用されない。ただしその事項に決まった締め切りがある場合は適用される。
他に誰も権限を持っていない事項に対する決定を行う。
一般決議の草案と、その修正案を提案する。
技術委員会とともに、委員会の新メンバを任命する (6.2節を見よ。）
開発者の投票において、決定票 (casting vote) を投ずる。

プロジェクトリーダは、このような投票において通常の投票権も持つ。
開発者投票において、討論期間を変更する (上記参照)。
開発者間の討論をリードする。

プロジェクトリーダが開発者間の議論に参加する際には、議論の衝突点を明らかにするよう、その助けとなるような態度を取るべきである。プロジェクトリーダは、自らの個人的見解を通すためにそのリーダーシップを利用すべきではない。
SPI と共に、Debian に関連した目的のために委託されている財産に関る決定を行なう (9.1 節を見よ)。

5.2. 任命

プロジェクトリーダは開発者によって選出される。
選挙は、リーダのポストが空席となる九週間前 (あるいはすでにそれ以下の期間しかなくなっている場合には即時) に開始される。
続く三週間の間、開発者はプロジェクトリーダ候補者に立候補できる。
立候補期間の終了後の三週間は、新たな立候補者は受け付けられない。この期間に候補者は選挙活動を行い、自らの経歴と立場の周知を図ることになる。もしも立候補受付期間が終了した時点で立候補者がいなかった場合には、受付期間は三週間単位で (必要に応じて繰り返し) 延長される。
次の三週間は投票期間であり、この間に開発者は投票を行うことができる。リーダ選挙の投票は秘密投票であり、投票内容は選挙後も公開されない。
投票の選択肢は、立候補してその取り下げを行っていない候補者たちそれぞれと、「全員不可」である。もし「全員不可」が最大得票を集めた場合には、選挙手続きが (必要なだけ何度でも) 繰り返される。
決定は「コンコード投票集計法」によって行われる。必要最低得票数は一般決議 (4.2節) の場合と同じで、既定の選択肢は「全員不可」である。
選出されたプロジェクトリーダは一年の任期を務める。

5.3. 意思決定手順

プロジェクトリーダは、開発者の意見の総意に添う決定を行うよう努めるべきである。

それが役に立つであろう場合には、プロジェクトリーダは非公式に開発者の見解を求めるべきである。

リーダとしての裁量に基づいて決定を行うにあたっては、プロジェクトリーダは自らの見解を過度に打ち出すべきではない。

6. 技術委員会

6.1. 権限

技術委員会は以下の権限を持つ。

技術的な方針に関するあらゆる事項に関して決定を行う。

これには、技術的方針マニュアルの内容、開発者のリファレンス類、見本パッケージ、実用段階のパッケージ構築ツールの動作などが含まれる (しかし各事項に対する最初の決定は、そのソフトウェアや文書のメンテナがまず行う。6.3(5) 節を見よ)。
複数の開発者の管轄権が絡む技術的問題を判断する。

複数の開発者間で技術的方針や立場の調整を行う必要があるとき (たとえば競合するパッケージ間の優先順位、コマンド名の所有権、あるバグが (バグであることは関係者全員が認めているとして) どのパッケージの責任なのか、あるパッケージのメンテナが誰か、などについて開発者間で意見の相違があるとき)、技術委員会はその件に関する判断を行うことができる。
要請された場合、決定を行う。

あらゆる個人または組織は、自らの決定を技術委員会に委ねることができる。あるいは技術委員会に助言を求めることができる。
開発者の決定を覆す (3:1 の賛成多数が必要)

技術委員会は開発者に対し、ある種の技術的な一連の作業を (その開発者が望まない場合でも) 行うよう要求することができる。これには 3:1 の賛成多数を必要とする。例えば、技術委員会はバグ報告者の修正要求を正当なものとし、その報告者の提案する解決案を実施すべきであると決定することができる。
答申を行う。

技術委員会は、どのような件に関しても、委員会の正式見解を公表することができる。技術委員会の個々のメンバは、もちろん自分の見解や技術委員会の見解 (とそのメンバが考えるもの) に関する非公式な声明を行ってよい。
プロジェクトリーダとともに、技術委員会自身の新メンバを任命し、また現在のメンバを解任する (6.2 節を見よ)。
技術委員会の議長を任命する。

議長は、技術委員会のメンバのなかから互選される。技術委員会の全メンバが自動的に立候補したとみなされ、議長が空席となる一週間前から (あるいはすでにそれ以下の期間しかなくなっている場合には即時に) 委員会内部での投票が行われる。委員会の各メンバは、自分自身を含む委員会メンバに対し、公開票を投ずることができる。「全員不可」という選択肢はない。投票は全メンバの投票が終了した時点、あるいは当選者が確実になった時点で終了する。結果は「コンコード投票集計法」で決定される。
議長はプロジェクト書記とともにリーダの代行を行うことができる。

7.1(2) 節に述べる通り、技術委員会の議長とプロジェクト書記とは、リーダ不在の際に共同でリーダの代行を行うことができる。

6.2. 構成

技術委員会は 8 名以下の開発者から構成される。また通常は少なくとも 4 名のメンバを持つべきである。
技術委員会のメンバ数が 8 名未満である場合、技術委員会はプロジェクトリーダに新メンバを推薦でき、プロジェクトリーダは (各人ごとに) 任命の採否を決定できる。
技術委員会のメンバ数が 5 名以下である場合、技術委員会は新メンバを総メンバ数が 6 名に達するまで任命できる。
技術委員会のメンバ数が 5 名以下である状態が一週間以上続いた場合、プロジェクトリーダは新メンバを総メンバ数が 6 名に達するまで任命できる。ただし、この場合は一人任命するごとに一週間以上の間隔を取らなければならない。
技術委員会とプロジェクトリーダが合意した場合、技術委員会のメンバを解任もしくは交代させることができる。

6.3. 意思決定手順

技術委員会は「標準議事手順 (Standard Resolution Procedure)」を用いる。

技術委員会の各メンバは、決議文の草案あるいは修正案を提案できる。最短の討論期間は定めない。投票期間は一週間、または結果が確定するまで続く。メンバは自分の投票を変更できる。必要最低得票数は 2 である。
投票に関する詳細

議長は決定票 (casting vote) を持つ。技術委員会の投票が、委員会のメンバでもある開発者の決定を覆すかどうかに関するものの場合は、そのメンバは投票してはならない (ただしそれが議長の場合には、決定票の投票権だけは持つ)。
討論と決定の公開

技術委員会のメンバによる討論、決議文の草案、修正案、投票は、技術委員会の公開議論用メーリングリストにおいて公表される。委員会にはメンバ以外の書記を置くことはしない。
任命に関する討議の秘密性

技術委員会メンバの任命に関する議論においては、技術委員会は個人宛て電子メールや非公開メーリングリストなどを用いて非公開の議論を行うことができる。ただし任命に関する投票は公開しなければならない。
詳細な策定作業の禁止

技術委員会は新しい提案や方針の立案には関与しない。そのような立案作業は、各個人がひとりで、あるいは通常の技術方針立案の場で議論しながら共同で、行われるべきものである。

技術委員会が行う作業は、複数の解決法や決断の中から選択を行ったり、それらの折衷案を採ったりすることに限られる。それらの案は、他の場所で提案され、そこで充分な議論を受けたものであるべきである。

技術委員会の個々のメンバが個人の立場で、計画や方針の策定作業の各段階に参加することは、もちろん許される。
技術委員会はやむを得ない場合に限って決定を行う。

技術委員会が技術的な決定を行うのは、合意による解決の努力の試みが失敗した後、または本来その決定に責任を持つ個人や組織から要請された場合、に限られる。

7. プロジェクト書記

7.1. 権限

書記は以下の権限を持つ:

憲章に規定されている場合に、開発者からの投票を受け、その計数と投票有効性の認証を行う。
技術委員会の議長と共同で、リーダを代行することができる。

プロジェクトリーダが不在の際、技術委員会の議長とプロジェクト書記の両名は、両者が緊急と考えた場合には、合意に基づいて決定を行うことができる。
憲章の解釈に関する論争に対して裁定を行う。
自己の権限の一部あるいは全体を他人に委任できる。またその委任をいつでも取り下げることができる。

7.2. 任命

プロジェクト書記は、プロジェクトリーダと現在のプロジェクト書記とによって指名される。

プロジェクトリーダと現在のプロジェクト書記との間で、この指名に関して合意ができなかった場合には、両名は SPI 協議会 (9.1 節を見よ) に書記の指名を依頼しなければならない。

プロジェクト書記が不在または職務を遂行できない状態であり、かつ決定権限の委任を行っていない場合は、技術委員会の議長が臨時代理としてプロジェクト書記の行うべき決定を行ったり、適当な者に委任したりできる。

プロジェクト書記の任期は一年である。期間満了後は、自分自身あるいは他の者を (再) 指名しなければならない。

7.3. 意思決定手順

プロジェクト書記は、公正かつ妥当であるように、またできれば開発者の総意に矛盾しなように決定を行うべきである。

プロジェクトリーダが不在の際に技術委員会の議長とプロジェクト書記の両名がその代理を行う場合には、絶対に必要不可欠な事柄に限って決定を行うべきであり、かつその決定は開発者の総意に矛盾しないようにすべきである。

8. プロジェクトリーダ代行

8.1. 権限

プロジェクトリーダ代行者は以下の権限を持つ。

プロジェクトリーダから委任された権限を持つ。
プロジェクトリーダが直接行えない事項について決定を行なう。そのような事項には、開発者の承認と除名、パッケージをメンテナンスしない開発者の解任、などがある。これは、プロジェクトリーダに開発者の人選を委ねる事によって、権限が過度に集中するのを避けるためである

8.2. 任命

代行者はプロジェクトリーダによって、プロジェクトリーダの自由裁量に基づき、任命されあるいは解任される。ただしプロジェクトリーダは、代行者の役職をその代行者の特定の判断によって左右したり、代行者の行った決定を変更したりすることはできない。

8.3. 意思決定手順

代行者は、当人が適切と考えるように決定を行なってよいが、それが技術的に良いものであるよう、また開発者の総意に則るよう、努めるべきである。

9. Software in the Public Interest

SPI と Debian はいくつかの目的を共有する別の組織である。 Debian は SPI によって提供される法的支援の枠組みに感謝する。現在のところ Debianの開発者は、開発者であることをもって同時に SPI のメンバとなる。

9.1. 権限

SPI は Debian の技術的・非技術的な決定に関連する権限は一切持たない。ただし SPI が保有する資産に関連する Debian の決定は、 SPI に法的権限を外れて行動することを求めてはならない。また Debian の組織は、臨時に SPI を (他に手段がない場合の) 決定主体とすることができる。
Debian は SPI に対して、SPI の特定の資産を利用する権利 (後述) 以外の権利を有しないが、Debian の各開発者は SPI の規則のもとに SPI 内部での権限を与えられる。
Debian の開発者は SPI の代理人でも雇用者でもない。また開発者は集団としても個人としても Debian プロジェクトの代表者ではない。 Debian 開発者として行動する個人は、個人として自らの信念に従って行動する。

9.2. Debian に関係した目的のための資産の管理

Debian は金銭や財産を保有する権限を有しないため、 Debian プロジェクトに対する寄付は SPI に対して行なわれなければならない。これらの管理は SPI が行う。

SPIは以下を請け負う：

SPIは Debian に関係した目的のため、金銭、商標およびその他の有形または無形の資産を管理し、その他の事務処理を行う。
そのような資産は個別に管理され、この節の記述に則って Debian と SPI とによって決定される目的のために委託される。
SPI は Debian からの承認がない限り、委託された資産を処理も利用もしない。このような承認は、プロジェクトリーダによって、もしくは開発者の一般決議によって与えられる。
SPI は、プロジェクトリーダからその旨の要請があった場合、 Debian より委託された資産を利用ないし処理する検討を行う。
SPI は、開発者の一般決議によりその旨の要請があった場合、それが SPI の法的権限の及ぶ範囲であるならば、 Debian より委託された資産を利用ないし処理する。
Debian より委託された資産を利用ないし処理する際には、 SPI は Debian プロジェクトのメーリングリストに電子メールを送り、開発者に対して通知する。

A. 標準議事手順 (Standard Resolution Procedure)

この規則は、委員会および構成員が、上述してきたような局面で、集団としての意思決定を行う際に適用される。

A.1. 提案

正式な手続きは、議決文の草案が必要な人数の発起人とともに提案された時点から始まる。

A.1. 議事と修正動議

提案に続き、決議文は討議に入る。修正案は、新規の決議文の必要要件を満たす形で提案かつ賛同されるか、もともとの決議文の提案者から提案された場合、正式なものとして扱われる。
決議文の提案者はそのような正式修正案を受け入れることができる。その場合、正式の決議文は即座に修正案に沿って変更される。
もし正式な修正案が受け入れられなかった場合、または決議文の賛同者の一名以上が修正案の提案者の受け入れ処置に反対した場合、修正案は修正案に留まり投票の対象となる。
原提案者に受け入れられた修正案が気に入らなかった人 (賛同者以外) は、その修正を元に戻す新たな修正案を提案できる (この場合も提案者と賛同者の要件を満たさなければならない)。
決議文の提案者は、修正案の字句に対して変更を示唆できる。この示唆は修正案の提案者が受け入れ、修正案の賛同者から異論が出なければ有効となる。この場合には、変更された修正案が原案の代わりに投票に付されることになる。
決議文の提案者は、小修正 (たとえば字句修正や矛盾点の解消) や意味を変更しない範囲での変更を行うことができ、24 時間の間に反対者が出なければその修正は有効となる。この場合には最短討論期間の再スタートは行わない。

A.2. 投票動議

決議案または修正案の提案者または賛同者は (最短討論期間がある場合にはその期間が経過したら)、投票動議を行うことができる。
決議案の提案者および賛同者は、一部ないし全部の修正案を個別または一括した投票動議を行える。修正案の提案者は、その修正案およびそれに関連した修正案についてのみ投票動議を行える。
投票動議を行う者は、決議案とそれに関連する修正案の文面について (自らの見解に沿うかたちで) 明らかにし、またその結果として、どのような投票形態をとるべきかを明らかにしなければならない。しかしながら、最終的な投票形態はプロジェクト書記が判断する (7.1(1), 7.1(3), A.3(6) を見よ)。
最短討論期間の開始は、最新の公式修正案が受け入れられた時点、あるいは修正案が投票中ならば最新の関連修正案が受け入れられた時点、あるいは修正案がまったく提案・受け入れされていなければ決議文が提案された時点、となる。

A.3. 投票手続き

関連する修正案を集めた集合は、それぞれの集合に別々の票を投ずるかたちで投票にかけられる。そのような投票の各々における選択肢は、修正案やオプションの (無意味にならない範囲での) あらゆる組み合わせ、および「討論の継続」である。もし「討論の継続」が勝者となった場合には、決議手続き全体が討論期間のはじめに戻って再開される。修正案には必要最低得票数は定めない。
決議の最終文案が定まったら、それが最終投票に付される。この場合の選択肢は「はい」「いいえ」「討論の継続」である。もし「討論の継続」が勝者となった場合には、決議手続き全体が討論期間のはじめに戻って再開される。
投票管理人 (が規定されている場合) または有権者 (投票が公告によって実施される場合) は、これらの投票を同時に行うように手配することができ、 (例えば) 1 通の投票メッセージを用いるかたちですらかまわない。もし修正案に関する投票と最終投票とがこのように同時に実施される場合には、最終の決議案が取りうる形態の各々に対して、有権者が異なる票を投じることができるようにしなければならない。
投票は (他で指定されている) 投票期間中に行なう。結果が確定して投票期間を終了させる場合には、投票者が自らの投票内容を修正する可能性は考慮されない。
投票は「コンコード投票集計法」により計数される。もし必要最低得票数が要求されている場合は、既定の選択肢は「討論の継続」とする。
不明確な点が現われたら、手続き的な問題はプロジェクト書記が決定する (例えば特定のいくつかの修正案を独立のものとみなすか否かなど)。

A.4. 決議文および不採択修正案の取り下げ

決議文や不採択となった修正案の提案者は、その提案を取り下げることができる。その場合には、他の者が提案者となってその提案を引継ぐことができる。引継ぐ場合には、最初に引継ぎを通告した人が新たな提案者となり、それ以外の人は (まだ賛同者がいない場合は) 賛同者になる。

決議文や修正案の賛同者は、(それらがまだ採択されていない限り) 賛同を取り下げることができる。

提案者もしくは賛同者の取り下げによって、決議文の提案者がいなくなったり賛同者の人数要件を満たさなくなった場合には、その決議文が期限切れによって廃案となる前にその状況が修復されない限り、その決議文は投票には付されない。

A.5. 期限切れ

もし提案された決議が四週間にわたって討論、修正、投票されず、その他の何らかの処置の状態にもない場合には、その提案は取り下げられたものとみなされる。

A.6. コンコード投票集計法

これは列挙された選択肢から勝者を選び出すために用いられる。投票者は投票用紙に望む選択肢を順序付きで記載する (すべての選択肢について順序をつける必要はない)。
選択肢 A が B より「優位」であるとは、 A を B より優先した投票数が、B を A より優先した投票数より多いこと、のみを意味する。
より「優位」な選択肢を少なくともひとつ持つ選択肢は捨てられ、各投票用紙に記載されたその選択肢に関する情報は以降無視される。
もしすべてのほかの選択肢より「優位」なものがあるなら、それが勝者である。
この時点で複数の選択肢が残っている場合には、単一遷移投票 (Single Transferrable Vote) が残りに対して適用される。
- 各選択肢に対して、それを第一優先とした投票を数える。もしいずれかの選択肢が過半数を得ていれば、それが勝者である。
- 勝者が決まらない場合には、第一優先とした投票数が最も少ない選択肢を除外して、その票を第二優先に従って他の選択肢に振り分ける。
- この除外処理は、ある選択肢が「第一」優先を過半数取るまで、第二優先、第三優先、第四優先…と降りていきながら繰り返される。
同点の場合には、決定票 (casting vote) を持つ選挙人が決定する。この決定表は通常投票の数には入れない。ただしこの選挙人は通常の一票の投票権も持つことが多いだろう。
もし過半数以上の多数が必要となる場合、投票の最終結果の Yes 票は、指定された係数に従って減らす。より厳密に言えば、F:A の多数決が要求されている場合、 Yes を他の選択肢 X より優先するとした投票数 (Yes が X より「優位」であるか、 X が Yes より「優位」であるかを決める場合)、あるいは (最終の) 第一優先選択肢が Yes である投票数 (単一遷移得票法を勝者と除外の決定に用いられている場合) を A/F 倍してから比較を実施する。すなわち例えば 2:1 の多数とは、対抗選択肢の 2 倍の人がその選択肢に投票する、ということである。棄権は数に入れない。
必要最低得票数を必要とする場合には、勝者の選択肢を既定の選択肢より優先した投票が、その数だけ存在しなければならない。そうでなければ既定の選択肢が勝者となる。もし投票が過半数以上の多数を要求する場合には、 Yes 票の (比率を乗ずる前の) 実際の投票数が、必要最低得票数に達したかどうかの判断対象になる。

標準議事手順を用いようとする場合には、その文脈で、決議文草案の提案・賛同に必要なもの、最短の討論期間、投票期間、を定めなければならない。また過半数以上の多数を必要とするかどうか、必要最低得票数 (および既定の選択肢) を用いるかどうか (用いる場合にはその数)、についても記述しなければならない。

B. 語法および表示について

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