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. 措辞和行文

一般现在时（例如：是）意味着这项声明是本宪章的一项规定。 能够或可以表示表示个人或团体有自由裁量权。 应当意味着若遵守此条会被认为较好，但它并不具有约束力。 标记为引文的文本（如本段）用于解释原因，不构成宪章的一部分。 在有疑义的情况下，只能用于辅助解释。