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

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

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

現行の 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. 任命

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

5.3. 意思決定手順

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

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

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

6. 技術委員会

6.1. 権限

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

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

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

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

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

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

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

議長は、技術委員会のメンバのなかから互選される。技術委員会の全メンバが自動的に立候補したとみなされ、議長が空席となる一週間前から (あるいはすでにそれ以下の期間しかなくなっている場合には即時に) 委員会内部での投票が行われる。委員会の各メンバは、自分自身を含む委員会メンバに対し、公開票を投ずることができる。デフォルトの選択肢はない。投票は全メンバの投票が終了した時点、あるいは投票期限が過ぎた時点で終了する。結果は「標準議事手順 (Standard Resolution Procedure)」の A.6 節で指定される方法によって決定される。
議長はプロジェクト書記とともにリーダの代行を行うことができる。

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(4) を見よ)。
最短討論期間の開始は、最新の公式修正案が受け入れられた時点、あるいは修正案がまったく提案・受け入れされていなければ決議文が提案された時点、となる。

A.3. 投票手続き

各決議文と、それに関連する修正案とは、単一の投票用紙をもって投票にかけられる。用紙には、当初の決議文・各修正案・ (適切な場合には) デフォルトの選択肢、が含まれる。
デフォルトの選択肢には超過半数 (supermajority) の要請を科してはならない。超過半数の要請が明示されていない選択肢には、 1:1 の多数が要請される。
投票は A.6 に定める規則にしたがって集計される。特に指定がなければ、デフォルトの選択肢は「更に議論する "Further Discussion"」となる。
不明確な点が現われたら、手続き的な問題はプロジェクト書記が決定する。

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

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

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

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

A.5. 期限切れ

もし提案された決議が四週間にわたって討論、修正、投票されず、その他の何らかの処置の状態にもない場合には、書記はその提案は撤回されたとの宣言を発することができる。そのいずれかの提案の賛同者が、一週間以内に誰も反対しなければ、その議題は撤回される。

適切な場合には、書記はその後どのようにするかを同時に提案しても良い。

A.6. 投票の集計

各投票者の用紙には、投票にかけられる選択肢が順位付けされる。すべての選択肢に順位をつけなくても良い。順位をつけた選択肢は、付けられなかった選択肢よりも優先されたとみなされる。投票者は複数の選択肢を同じ順位にしても良い。順位付けされなかった選択肢は、それぞれ同じ順位であるとみなされる。投票用紙にどのように記入すればよいかに関する詳細は、投票の呼びかけに含まれる。
投票用紙に必要最低得票数の要請 R が存在する場合、デフォルト以外の選択肢は、デフォルトの選択肢よりもそれを上位とする投票を R 票以上集めなければ、以降の処理から排除される。
デフォルトの選択肢に、要求された多数比を持って勝つことができなかった (デフォルト以外の) 選択肢は、以降の処理から排除される。
1. 選択肢 A と B に対し、V(A,B) は B よりも A を優先する投票者の数とする。
2. ある選択肢 A がデフォルトの選択肢 D に多数比 N で勝つには、 V(A,D) が N * V(D,A) よりも多くなければいけない (同数は含まない)。
3. 超過半数 S:1 が A に要請されている場合、 A の多数比は S となる。それ以外の場合は多数比は 1 となる。
排除されなかった選択肢のリストから、 1 対 1 勝敗表を作成する。
1. V(A,B) が V(B,A) よりも多ければ (同数は含まない)、選択肢 A は選択肢 B に勝利する。
(排除されなかった) 選択肢同士の勝敗表より、推移的な勝敗のセットが生成される。
1. (1) 選択肢 A が選択肢 C に勝利しているか、あるいは (2) A が別の選択肢 B に勝利かつ B が C に推移的に勝利している場合、 A は C に推移的に勝利する。
この推移的勝敗の組から、Schwartz 集合を構成する。
1. 選択肢 A は、すべての選択肢 B に対して推移的に勝利しているか、あるいは推移的に敗退していなければ、 Schwartz 集合に入る。
Schwartz 集合の内部にある選択肢同士に勝敗があれば、その勝敗における最弱のものを先ほどの 1 対 1 勝敗表から排除し、ステップ 5 に戻る。
1. V(A,X) が V(B,Y) より少ない場合、勝敗 (A,X) は、勝敗 (B,Y) より弱い。また V(A,X) が V(B,Y) と等しく、かつ V(X,A) が V(Y,B) より多い場合、勝敗 (A,X) は、勝敗 (B,Y) より弱い。
2. 最弱の勝敗とは、他のどの勝敗よりも弱いものをいう。そのような勝敗は複数存在することもある。
Schwartz 集合に勝敗がなくなったら、その集合から勝者を選ぶ。残った選択肢が 1 つだけだったら、それが勝者となる。複数の選択肢が残っていたら、決定票を持つ選挙人が、どの選択肢が勝利するか選択する。

注意: 投票者がデフォルトの選択肢よりも上位に置いた選択肢は、受け入れられるとみなした選択肢である。デフォルトの選択肢よりも下位に置かれた選択肢は、受け入れられないとみなした選択肢である。

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

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

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