Debian 憲章

Debian 項目憲章（1.9版本）

1.9版本 批准於2022年03月26日。

取代以下版本： 1.8版本 批准於2022年01月28日， 1.7版本 批准於2016年08月14日， 1.6版本 批准於2015年12月13日， 1.5版本 批准於2015年01月09日， 1.4版本 批准於2007年10月07日， 1.3版本 批准於2006年09月24日， 1.2版本 批准於2003年10月29日， 1.1版本 批准於2003年06月21日 和 1.0版本 批准於1998年12月02日。

1. 簡介

Debian 項目是一個由擁有共同理念的個人組成的協會， 其目的是創建一個自由的操作系統。

本文件描述了關於項目正式決策的組織結構。它沒有描述項目的目標或如何實現這些 目標，也沒有包含任何政策（與決策過程直接相關的政策除外）。

2. 決策機構與決策人

項目中的每個決策都是由以下一個或多個決策者做出的：

  1. 開發人員，透過一般性決議或選舉產生；
  2. 項目負責人；
  3. 技術委員會和/或其主席；
  4. 從事特定任務的開發人員；
  5. 項目負責人指定的具體任務負責人；
  6. 項目秘書。

本文件剩餘部分中的大部分將概述這些機構的權力、組成和任命及其決策程序。 個人或組織的權力可能會受到他人的審查和/或限制；審查機構和審查人的條目會 説明這一點。 在上述列表中，個人或團體通常列在他們可以否決其決定或他們（幫助） 任命的任何人或團體之前，但不是所有前面列出的人都可以否決後面的人。

2.1. 一般規則

  1. 本憲章未規定任何人有義務為項目工作。不想做被委派或分配給他們的 任務的人可以不去做。 但是，他們不能主動故意違反這些規則和根據這些規則做出的決定。

  2. 一個人可以擔任多個職位，但項目負責人、項目秘書和技術委員會主席 必須是不同的，且負責人不能委派自己做自己的代表。

  3. 任何人可以隨時透過公開聲明離開項目或辭去其所擔任的特定職位。

3. 個人開發人員

3.1. 權力

個人開發人員 可以：

  1. 對自己的工作作出技術性或非技術性的決定；
  2. 提出議案或提出一般性決議草案；
  3. 在選舉中提名自己為項目負責人候選人；
  4. 就一般性決議和負責人選舉投票。

3.2. 組成和任命

  1. 開發人員是志願工作，他們自願參與項目工作、進一步實現項目目標， 並維護套件或做項目負責人代表認為有價值的其他工作。

  2. 項目負責人的代表可以選擇不招收新的開發人員，或者開除現有的開發人員。 如果開發人員認為代表在濫用其權力，他們可以透過一般性決議 推翻決定——見 §4.1(3)，§4.2 節。

3.3. 程序

開發人員可以在他們認為適當的時候做出這些決定。

4. 一般性決議或選舉選出的開發人員

4.1. 權力

同樣的，開發人員 可以：

  1. 任命或罷免項目負責人。

  2. 以超過四分之三的多數票修改憲章。

  3. 做出或推翻由項目負責人或代表授權的任何決定。

  4. 以超過三分之二的多數票做出或推翻技術委員會授權的任何決定。

  5. 發佈、更新和撤銷非技術性政策文件和聲明。

    這些文件包括描述項目目標、與其他自由軟件實體的關係以及非技術性政策 的文件，如 Debian 軟件必須滿足的自由軟件許可條款。

    它們還可能包括關於當天議題的立場聲明。

    1. 基礎文件即對項目任務和目的至關重要的文件或聲明。
    2. 基礎文件為： Debian 社羣契約 與 Debian 自由軟件指導方針。
    3. 基礎文件需要超過四分之三多數票才能更新。 透過修改本章程中的基礎文件清單， 以發佈新的基礎文件、撤銷現有基礎文件。

  6. 決定 Debian 相關信託資產的用途。（見 §9. 節）。

  7. 若項目負責人和現任秘書之間存在分歧，則任命一名新的秘書。

4.2. 程序

  1. 開發人員遵循以下標準決議程序。 若由任何開發人員提出並由至少 K 名其他開發人員支持， 或者由項目負責人或技術委員會提出，則可提出決議或投票選項。

  2. 推遲項目負責人或其代表的決定：

    1. 若項目負責人或其代表、或技術委員會已做出決定，則開發人員可透過 決議推翻這些決定；見 §4.1(3) 節。
    2. 若此決議是由至少 2K 個開發人員發起的，或者是由技術委員會提出的， 則該決議會立即擱置決定（前提是決議本身也如此要求）。
    3. 若最初的決定是改變討論期限或投票期限，或者決議是推翻技術委員會， 那麼只需有 K 個開發人員需要發起該決議，便能立即擱置該決定。
    4. 若決定被擱置，則需立即進行投票，以決定在對該決定進行完整投票前， 該決定是否繼續有效，或原決定的執行是否將推遲到那時。 本次即時程序性投票沒有法定人數要求。
    5. 若項目負責人（或其代表）撤回了最初的決定，則投票由於毫無意義 而不再進行。

  3. 投票由項目秘書負責。投票、計票和結果在投票期間不公佈； 投票結束後，項目秘書列出最終投票結果，其詳細程度應當 能允許任何人驗證選舉結果。每張選票具體由哪位開發人員 投出將不會被公開，但允許開發人員確認自己的選票已經被 包含在投票結果中。投票期限為 2 周，但可由項目負責人 最多更改 1 周。

  4. 項目負責人有決定性的一票。法定人數為 3Q。 默認選項是“以上皆不選”。

  5. 提案、支持、投票選項、投票和其他正式行動都是透過項目負責人或代表指定 的公開可讀的通信論壇發佈通知。任何開發人員皆可在該列表上發表。

  6. 投票以秘書方便的方式透過電子郵件進行。 秘書決定每一次投票的投票者是否可以更改他們的投票。

  7. Q 是當前開發人員人數平方根的一半。K 在 Q 或 5 中取較小值。 Q 和 K 不必是整數且不捨入。

5. 項目負責人

5.1. 權力

項目負責人 可以：

  1. 任命代表或將決定委託給技術委員會。

    負責人可以確定一個持續的責任範圍或一個具體的決定， 並將其委託給另一個開發人員或技術委員會。

    一旦某項特定決定被授權並實行，項目負責人不得撤回該授權； 但是，他們可以撤回對特定責任領域的持續授權。

  2. 授權給其他開發人員

    項目負責人可在被要求或其他情況下，對觀點或為項目的其他成員發表 支持聲明； 當且僅當項目負責人有權做出相關決定時，這些聲明才具有效力。

  3. 做出任何需要緊急行動的決定。

    這不適用於由於缺乏相關行動而逐漸變得緊急的決定， 除非有固定的截止日期。

  4. 做出無人負責的決定。

  5. 提出一般性決議和針對一般性決議的投票選項。當由項目負責人提出時， 對該一般性決議和針對一般性決議的投票選項的支持不是必需的； 見 §4.2.1. 節。

  6. 與技術委員會一起，任命新的委員會成員。（見 §6.2. 節）

  7. 在開發人員投票時使用決定性的一票。

    項目負責人在無記名投票中也有正常的投票權。

  8. 改變開發人員投票的討論期限（如前所述）。

  9. 引導開發人員進行討論。

    項目負責人應嘗試以一種有益的方式參與開發人員之間的討論， 以期將討論帶到手頭的關鍵問題上。 項目負責人不應利用領導職位來宣傳自己的個人觀點。

  10. 在與開發人員協商後，做出 Debian 相關信託資產用途的決策 （見 §9. 節）。此類決定由項目負責人或其代表傳達給成員。 在支付資金之前，應在通信論壇上提出並討論主要支出。

  11. 在受信組織（見 §9.3 節）列表中添加或刪除有權接受和持有 Debian 資產的組織。在項目負責人或其代表指定的通信論壇上進行評估和討論， 任何開發人員皆可該列表上發表。在將一個組織添加到受信組織列表之前， 至少有兩週的討論期。

5.2. 任命

  1. 項目負責人由開發人員選舉產生。
  2. 選舉在負責人職位空缺前六週開始，或者立即開始（如果已經遲了）。
  3. 在第一週，任何開發人員都可以提名自己為候選項目負責人， 並總結他們任期內的計劃。
  4. 此後三週內不再提名候選人；候選人應利用這段時間進行競選和討論。 如果提名期結束時沒有候選人，則提名期再延長一週，必要時可重複。
  5. 接下來的兩週是投票期，開發人員可以投票。
  6. 選票上的選項為那些已經提名且尚未退出的候選人，再加上一項以上皆不選。 如果以上所有人都沒有贏得選舉，則選舉程序將重複，必要時可多次進行。
  7. 使用 標準決議程序 §A.5 節規定的方法作出決定。 法定人數與一般決議（§4.2）相同，默認選項為以上皆不選。
  8. 項目負責人從他們當選起任期一年。

5.3. 程序

項目負責人應儘量做出與開發人員意見一致的決策。

在可行的情況下，項目負責人應非正式地徵求開發人員的意見。

項目負責人在以領導的身份做出決策時，應避免過分強調自己的觀點。

6. 技術委員會

6.1. 權力

技術委員會 可以：

  1. 決定任何技術政策問題：

    包括技術政策手冊的內容、開發人員的參考資料、示例套件和非實驗性包 構建工具的行為。（不過一般情況下，相關軟件或文件的常規維護者會 做出最初決定；見 6.3(5) 節）。

  2. 決定開發人員管轄權重疊的任何技術問題。

    在開發人員需要解決技術策略或立場衝突的情況下（例如，如果他們對： 衝突包的優先級、命令的歸屬問題、哪個包負責兩邊維護人員都發現的 缺陷、誰做維護者等有不同意見），技術委員會可決定該事項。

  3. 在被要求時做出決定。

    任何人或團體均可將其自己的決定委託給技術委員會做，或向其徵求意見。

  4. 否決開發人員（需要四分之三多數）

    技術委員會可在開發人員不願意的情況下要求其採取特定的技術措施， 但這需要四分之三多數票。 例如，委員會可以確定提交者對缺陷的投訴是合理的， 並且應該實施提交者提出的解決方案。

  5. 提供建議。

    技術委員會可正式宣佈其對任何事項的意見。 委員個人可就他們的意見和委員會可能的意見發表非正式聲明。

  6. 與項目負責人一起，任命委員會新成員或移除現有成員。（見 §6.2. 節）

  7. 任命技術委員會主席。

    主席由委員會從其成員中選出。委員會的所有成員都是自動提名的； 委員會在該職位空缺前一週投票（如已經太遲，則立即投票）。 委員會成員可以透過公開歡迎贊成方式投票給任何其他委員會成員， 包括他們自己；沒有默認選項。當所有成員投票或投票期限結束時，投票結束。 使用標準決議程序 §A.5 節規定的方法確定結果。沒有決定性的一票。 如果在 §A.5.8 節結束時，Schwartz 集合中有多個選項之間沒有勝敗關係， 則勝者將從這些選項中隨機產生，產生機制由項目秘書決定。

  8. 主席可與秘書一起代理負責人。

    如 §7.1(2) 節所述，若負責人缺位， 技術委員會主席和項目秘書可共同代理負責人。

6.2. 組成

  1. 技術委員會通常由 8 名開發人員組成，最少應由 4 人組成。

  2. 當成員少於8人時，技術委員會可向項目負責人推薦新成員， 項目負責人可選擇（部分）任命或不任命。

  3. 當委員人數不超過 5 人時，技術委員會可任命新委員， 直至委員人數達到 6 人。

  4. 當成員人數小於等於 5 名持續至少一週時，項目負責人可任命新成員， 直到成員數量達到6名，每次任命至少間隔一週。

  5. 如果開發人員在過去 12 個月內曾是技術委員會的成員，則他們不能（再次） 被任命為技術委員會成員。

  6. 如果技術委員會和項目負責人同意，他們可以撤換技術委員會的現有成員。

  7. 任期限制：

    1. 在每年的 1 月 1 日時，任職超過 42 個月（即 3.5 年）且是兩位 最高級委員中的一位的委員，其任期將於當年 12 月 31 日屆滿。

    2. 若技術委員會的一名成員被任命的更早，或者同時被任命但成為 Debian 項目成員的歷史更長，則該成員的級別要高於另一個成員。 若某成員被任命不止一次，則以最近一次的任命為準。

6.3. 程序

  1. 決議過程。

    技術委員會使用以下過程來準備決議以供投票：

    1. 技術委員會的任何成員都可以提出決議。這會產生初始的、具有兩個 選項的投票，另一個選項是默認選項“以上皆不選”。決議的提出者成為該投票選項 的提出者。
    2. 技術委員會的任何成員都可以提出額外的投票選項，或者修改或撤回 他們提出的投票選項。
    3. 如果除默認選項以外的所有選項都被撤回，則過程被取消。
    4. 技術委員會的任何成員都可以要求對當前的選票進行投票。此投票 立即開始，但如果技術委員會的任何其他成員在投票完成前反對進行投票， 則該投票將被取消，且不產生任何效果。
    5. 在最初的提案提出兩週後，選票不再進行任何更改，且投票自動開始。 此投票無法取消。
    6. 如果在最初的提案提出 13 天后根據 §6.3.1.4 取消投票， 則 §6.3.1.5 中闡述的投票將在取消後 24 小時開始。在這 24 小時內， 任何人不得要求投票，但技術委員會成員可以根據 §6.3.1.2 修改選票。

  2. 投票相關細節

    投票結果由 §A.5 中描述的計票機制確定。投票期持續一週 或直到結果不再有疑問（假設沒有成員改變投票），以較短者為準。 在投票期結束之前，成員可以更改他們的投票。法定人數為兩人。 主席有決定性的一票。默認選項是“以上皆不選”。

    當技術委員會投票決定是否推翻恰好也是委員會成員的開發人員時， 該成員不得投票（除非他們是主席，在這種情況下，他們只能使用 決定性的一票）。

  3. 公開討論和決策。

    討論、決議草案和投票選項，以及委員會成員的投票將在技術委員會 公開討論列表上公佈。 委員會不設單獨的秘書。

  4. 任命的保密。

    技術委員會可透過私人電子郵件、私人通信論壇或其他方式秘密討論委員會 的任命。但是，對任命的投票必須是公開的。

  5. 不參與細節設計工作。

    技術委員會不參與新提案和政策的設計。 此類設計工作應由個人單獨或共同進行， 並在一般的技術政策和設計論壇上討論。

    技術委員會僅限於在於其他地方提出並經合理徹底討論的解決方案和決定 之間作出選擇或採取折衷辦法。

    技術委員會的成員可以代表他們自己參與設計和政策工作的任何方面。

  6. 技術委員會做決定只作最後手段。

    技術委員會在試圖透過協商一致方式解決該問題的努力失敗之前， 不會作出技術性決定，除非通常負責該決定的人或機構要求它作出決定。

  7. 提出一般性決議。

    當技術委員會根據 §4.2.1 對項目提出一般性決議或一般性決議中 的投票選項時，可以將撤回、修正或對投票選項進行細微修改的權力授權給它的 一名成員。如果不這樣做，則必須透過技術委員會的決議作出這些決定。

7. 項目秘書

7.1. 權力

秘書 可以：

  1. 按照憲章要求，在開發人員中舉行投票，並確定開發人員的人數和身份。

  2. 可以同技術委員會主席一起代替負責人。

    如果項目負責人缺位，則技術委員會主席與秘書可透過共同協商做出必要決定。

  3. 裁決有關憲章解釋的任何爭議。

  4. 可將其部分或全部權力委託給他人，或隨時撤回此類授權。

7.2. 任命

項目秘書由項目負責人和現任項目秘書任命。

如果項目負責人和現任項目秘書不能就新的任命達成一致，他們必須透過一般決議 要求開發人員任命一名秘書。

如果沒有項目秘書或現任秘書缺席，且沒有授權作出決定，則該決定可由技術委員會 主席作為代理秘書作出決定或委託。

項目秘書的任期為 1 年，到期必須對其（重新）任命或任命另一秘書。

7.3. 程序

項目秘書應做出公平合理的決定，最好與開發人員的共識一致。

當共同代理缺席的項目負責人時，技術委員會主席和項目秘書應僅在絕對必要的情況下 做出決定，且只有在與開發商的一致意見一致的情況下才能做出決定。

8. 項目負責人代表

8.1. 權力

項目負責人代表 可以：

  1. 有項目負責人授予的權力；
  2. 可能會做出某些負責人可能不會直接做出的決定，包括批准或開除開發人員 或指定不維護套件的開發人員。 這是為了避免權力集中，特別是決定開發人員資格的權力， 集中在項目負責人手中。

8.2. 任命

代表由項目負責人任命，可由項目負責人自行更換。 項目負責人不得以代表的特定決定作為代表職位的條件， 也不得在代表做出決定後凌駕於代表的決定之上。

8.3. 程序

代表可以在他們認為合適的情況下做出決定， 但應致力於實施良好的技術決策和/或遵循一致意見。

9. Debian 信託資產

在世界上大多數司法管轄區，Debian 項目無法直接持有資金或其他財產。 因此， 財產必須由 §9.2 節中記載的多個組織中的任何一個持有。

傳統上，SPI 是唯一授權持有 Debian 項目資產的機構。SPI 成立於美國， 目的是在那裏託管資金。

SPI 和 Debian 是兩個獨立的組織， 但有着共同的目標。Debian 感謝 SPI 提供的法律支持框架。

9.1. 與關聯組織的關係

  1. Debian 開發人員不會僅由於是 Debian 開發人員而成為 Debian 託管資產 的組織的代理人或僱員，或彼此的代理人或僱員，或 Debian 項目中的 權威人士的代理人或僱員。 作為開發人員的個人所做上述行為僅代表其自己。 這些組織可以自行與同時也是 Debian 開發者的個人建立關係。

9.2. 權利

  1. 為 Debian 持有資產的組織無權干涉 Debian 的技術性或非技術性決定， 同時 Debian 對該組織代持的任何財產的任何決定均不得要求其在其 法律權限之外行事。

  2. Debian 無權干涉為 Debian 持有資產的組織，除了對託管的 Debian 財產的 使用權。

9.3. 受信組織

對 Debian 項目的任何捐贈必須提供給項目負責人（或代表）指定的一批組織中的 任何一個，以授權其處理用於 Debian 項目的資產。

為 Debian 託管資產的組織應承擔處理此類資產的合理義務。

Debian 維護着一份為 Debian 接受捐贈並託管資產（包括有形財產和知識產權）的 受信組織的公開名單，其中包含了這些組織就如何處理這些資產所作的承諾。

A. 標準決議程序

這些規則適用於由上述委員會和成員投票的公共決策。

A.0. 提案

  1. 正式程序從按 §4.2.1 的程序提出和支持決議草案時開始 。
  2. 該決議草案成為初始的兩個選項的選票中的一個投票選項，另一個選項 是默認選項，並且該決議草案的提議者成為該投票選項的提議者。

A.1. 討論與修正

  1. 討論期從決議草案被提出和支持時開始。最短討論期為 2 周。 最長討論期為 3 周。
  2. 可以根據提出新決議的要求提出和支持新的投票選項。
  3. 投票選項的提議者可以修正該選項，前提是在提出修正案時 該投票選項的支持者在 24 小時內沒有人不同意該更改。如果他們中的任何一個 不同意，投票選項將保持不變。
  4. 新增的投票選項或者投票選項的修正案引起的變更會將討論期的結束時間更改為 變更完成後一週，除非這會使總討論期短於最短討論期或長於最長討論期。 在後一種情況下，討論期的長度改為設置成最長討論期。
  5. 投票選項的提議者可以對該選項進行微小更改（例如，改正拼寫錯誤、 修正前後不一致或其他不改變意思的更改），前提是在 24 小時內沒有開發 人員反對。在這種情況下，討論期的長度不會改變。如果有開發人員反對，則 必須透過 §A.1.3 下的修正流程來進行更改。
  6. 項目負責人可以在過程中的任何時候，將最短和最長討論期從 §A.1.1 中 的初始值增加或減少最多 1 周，除非他們這樣做會引起討論期在進行此更改後 的 48 小時內結束。然後，重新計算討論期的長度，假定 在 §A.1.1 和 §A.1.4 中提到的所有先前的選票更改發生時，新的 最短和最長討論期已經生效。
  7. 默認選項沒有提議者或支持者，並且不能被修正或撤回。

A.2. 撤回投票選項

  1. 投票選項的提議者可以撤回。如果他們這麼做了，新的提議者可以站出來 以保持投票選項有效，在這種情況下，第一個這樣做的人將成為新的提議者， 剩下的人如果還不是支持者，將成為支持者。任何新的提議者或支持者必須符合 提議或支持新決議的要求。
  2. 投票選項的支持者可以撤回。
  3. 如果提議者和/或支持者的退出意味着投票選項沒有提議者或沒有足夠的 支持者來滿足新決議的要求，並且 24 小時過去了而沒有其他提議者和/或支持者 站出來補救，該投票選項會從投票草案中刪除。這不會改變討論期的長度。
  4. 如果除默認選項外的所有投票選項均被撤回，則該決議將被取消 並且不會被投票。

A.3. 要求投票

  1. 討論期結束後，項目秘書將發佈投票並要求投票。項目秘書可以在 討論期結束後立即這麼做，並且必須在討論期結束後的 7 天內這麼做。
  2. 項目秘書確定投票選項的順序及其它們在投票中的摘要。 項目秘書可以要求投票選項提議者起草這些摘要，並可以自行決定 對其進行修改以使其表述更清晰。
  3. §A.1.5 中對投票選項的微小更改只有在討論期剩餘 24 小時以上時，或者 項目秘書認同更改不會改變投票選項的意思並且（如果會引起的話） 值得推遲投票時，才能進行。在進行任何此類更改後，項目秘書將預留 24 小時 以接收反對意見，然後再要求投票。
  4. 如果討論期剩餘不到 24 小時，則不得提出新的投票選項， 不得修正投票選項，任何提議者或支持者都不得撤回，除非該舉動 依據 §A.1.4 成功地將討論期延長了至少 24 小時。
  5. 使現有投票保持不變的動作可以在討論期的最後 24 小時內執行， 即支持者反對根據 §A.1.3 進行的修正，開發人員反對根據 §A.1.5 進行 的微小更改，作為提議者站出來保留原提議者根據 §A.2.1 撤回的現有 投票選項，或支持由於支持者根據 §A.2.2 撤回而使得支持者數量少於 所需數量的現有投票選項。
  6. 項目秘書可以對 §A.3.4 作出例外處理，並在不再允許更改投票後 接受更改，前提是在要求投票前至少 24 小時完成。更改選票的所有其他要求 仍然必須滿足。這種情況應當很少出現，並且只有在項目秘書認為不進行更改 會損害項目的最優利益時才應該這麼做。

A.4. 投票程序

  1. 沒有明確的絕對多數要求的選項有 1:1 的多數要求。 默認選項沒有任何絕對多數要求。
  2. 根據 §A.5 中的規則進行計票。
  3. 如有疑問，項目秘書應決定程序事項。

A.5. 計票

  1. 每個投票者都需要對選票上的選項進行排序。 不必排序所有選項，但被排序的選項視為優先於所有未排序的選項。 投票者可將選項排成平級。未評級的選項被認為是平級的。 如何填寫選票的細節將包含在投票要求中。
  2. 如果投票要求法定人數 R，那麼除默認選項外的任何選項若未獲得至少 R 票， 則該選項高於默認選項時的排名將不予考慮。
  3. 任何選項（非默認）如未依要求的多數票比例勝過默認選項，則不予考慮。
    1. 給定兩個選項 A 和 B，V(A,B) 為選擇 A 項多過選擇 B 的投票者的人數。
    2. 若 V(A,D) 大於等於 N*V(D,A) 且 V(A,D) 嚴格大於 V(D,A)，則 選項 A 以多數比例 N 勝過默認選項 D。 譯註：多數比例 N 為 贊成/反對，不是 贊成/總數。
    3. 如果 A 需要 S:1 的絕對多數，那麼其多數比例為 S； 否則其多數比例為 1。
  4. 在未排除的選項中，生成一個一對一的選項勝負表。
    1. 如果 V(A,B) 嚴格大於 V(B,A) 則選項 A 勝過選項 B。
  5. 從未排除選項之間的勝負表中，產生傳遞勝敗集合。
    1. 若選項 A 勝過 C 或 A 勝過 B 而 B 傳遞勝過 C，則 A 傳遞勝過 C。
  6. 從傳遞勝敗集合中構造 Schwartz 集合。
    1. 對 Schwartz 集合中的任意 A、B 選項，要麼 A 傳遞勝過 B， 要麼 B 傳遞勝過 A。
  7. 若 Schwartz 集合中選項之間存在勝敗關係，則從一對一選項勝負表中刪除 最弱的勝敗關係對，然後回到步驟 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. 最弱的勝敗關係對指沒有比它更弱的勝敗關係。這可能不止一對。
  8. 若 Schwartz 集合中選項之間無勝敗關係，那麼則從 Schwartz 集合中選出 獲勝選項。 若只有一個這樣的選項，即是它。 若有多個選項，由投決定性一票的成員決定選擇哪個選項。

注意：排在默認選項之上的選項是投票者認為可以接受的選項， 排在默認選項之下的為其不可接受的選項。

當使用標準決議程序的計票機制時，提到它的文本必須説明誰擁有決定性的一票、法定人數、默認選項和任何絕對多數要求。 默認選項不得有任何絕對多數要求。

B. 措辭和行文

一般現在時（例如：是）意味着這項聲明是本憲章的一項規定。 能夠或可以表示表示個人或團體有自由裁量權。 應當意味着若遵守此條會被認為較好，但它並不具有約束力。 標記為引文的文本（如本段）用於解釋原因，不構成憲章的一部分。 在有疑義的情況下，只能用於輔助解釋。