Debian 宪章历史版本 v 1.7

Debian 项目宪章的历史版本（v1.7）

1.7版本 批准于2016年08月14日。

被以下版本取代：1.8版本 批准于2022年01月28日 和当前的1.9版本 批准于2022年03月26日。

取代以下版本： 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. 最短讨论期限为 2 周，但可由项目负责人最多更改 1 周。 项目负责人有决定性的一票。法定人数为 3Q。

  5. 提案、附议、修正案、投票和其他正式行动都是通过项目负责人或代表指定 的公开可读的邮件列表发布通知。任何开发人员皆可在该列表上发表。

  6. 投票以秘书方便的方式通过电子邮件进行。 秘书决定每一次投票的投票者是否可以更改他们的投票。

  7. Q 是当前开发人员人数平方根的一半。K 在 Q 或 5 中取较小值。 Q 和 K 不必是整数且不舍入。

5. 项目负责人

5.1. 权力

项目负责人 可以：

  1. 任命代表或将决定委托给技术委员会。

    负责人可以确定一个持续的责任范围或一个具体的决定， 并将其委托给另一个开发人员或技术委员会。

    一旦某项特定决定被授权并实行，项目负责人不得撤回该授权； 但是，他们可以撤回对特定责任领域的持续授权。

  2. 授权给其他开发人员

    项目负责人可在被要求或其他情况下，对观点或为项目的其他成员发表 支持声明； 当且仅当项目负责人有权做出相关决定时，这些声明才具有效力。

  3. 做出任何需要紧急行动的决定。

    这不适用于由于缺乏相关行动而逐渐变得紧急的决定， 除非有固定的截止日期。

  4. 做出无人负责的决定。

  5. 提出一般性决议草案和修正案。

  6. 与技术委员会一起，任命新的委员会成员。（见 §6.2. 节）

  7. 在开发人员投票时使用决定性的一票。

    项目负责人在无记名投票中也有正常的投票权。

  8. 改变开发人员投票的讨论期限（如前所述）。

  9. 引导开发人员进行讨论。

    项目负责人应尝试以一种有益的方式参与开发人员之间的讨论， 以期将讨论带到手头的关键问题上。 项目负责人不应利用领导职位来宣传自己的个人观点。

  10. 在与开发人员协商后，做出 Debian 相关信托资产用途的决策 （见 §9. 节）。此类决定由项目负责人或其代表传达给成员。 在支付资金之前，应在邮件列表上提出并讨论主要支出。

  11. 在受信组织（见 §9.3 节）列表中添加或删除有权接受和持有 Debian 资产的组织。在项目负责人或其代表指定的邮件列表上进行评估和讨论， 任何开发人员皆可该列表上发表。在将一个组织添加到受信组织列表之前， 至少有两周的讨论期。

5.2. 任命

  1. 项目负责人由开发人员选举产生。
  2. 选举在负责人职位空缺前六周开始，或者立即开始（如果已经迟了）。
  3. 在第一周，任何开发人员都可以提名自己为候选项目负责人， 并总结他们任期内的计划。
  4. 此后三周内不再提名候选人；候选人应利用这段时间进行竞选和讨论。 如果提名期结束时没有候选人，则提名期再延长一周，必要时可重复。
  5. 接下来的两周是投票期，开发人员可以投票。 负责人选举的投票是保密的，即使在选举结束后亦然。
  6. 选票上的选项为那些已经提名且尚未退出的候选人，再加上一项以上皆不选。 如果以上所有人都没有赢得选举，则选举程序将重复，必要时可多次进行。
  7. 使用 标准决议程序 第 §A.6 节规定的方法作出决定。 法定人数与一般决议（§4.2）相同，默认选项为以上皆不选。
  8. 项目负责人从他们当选起任期一年。

5.3. 程序

项目负责人应尽量做出与开发人员意见一致的决策。

在可行的情况下，项目负责人应非正式地征求开发人员的意见。

项目负责人在以领导的身份做出决策时，应避免过分强调自己的观点。

6. 技术委员会

6.1. 权力

技术委员会 可以：

  1. 决定任何技术政策问题：

    包括技术政策手册的内容、开发人员的参考资料、示例软件包和非实验性包 构建工具的行为。（不过一般情况下，相关软件或文档的常规维护者会 做出最初决定；见 6.3(5) 节）。

  2. 决定开发人员管辖权重叠的任何技术问题。

    在开发人员需要解决技术策略或立场冲突的情况下（例如，如果他们对： 冲突包的优先级、命令的归属问题、哪个包负责两边维护人员都发现的 缺陷、谁做维护者等有不同意见），技术委员会可决定该事项。

  3. 在被要求时做出决定。

    任何人或团体均可将其自己的决定委托给技术委员会做，或向其征求意见。

  4. 否决开发人员（需要四分之三多数）

    技术委员会可在开发人员不愿意的情况下要求其采取特定的技术措施， 但这需要四分之三多数票。 例如，委员会可以确定提交者对缺陷的投诉是合理的， 并且应该实施提交者提出的解决方案。

  5. 提供建议。

    技术委员会可正式宣布其对任何事项的意见。 委员个人可就他们的意见和委员会可能的意见发表非正式声明。

  6. 与项目负责人一起，任命委员会新成员或删除现有成员。（见 §6.2. 节）

  7. 任命技术委员会主席。

    主席由委员会从其成员中选出。委员会的所有成员都是自动提名的； 委员会在该职位空缺前一周投票（如已经太迟，则立即投票）。 委员会成员可以通过公开欢迎赞成方式投票给任何其他委员会成员， 包括他们自己；没有默认选项。当所有成员投票或投票期限结束时，投票结束。 使用标准决议程序第 A.6 节规定的方法确定结果。

  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. 技术委员会采用标准决议程序。

    决议草案或修正案可由技术委员会的任何成员提出。 没有最短讨论期；投票期为一周，或直到结果无异议为止。 成员可以更改他们的投票。法定人数为两人。

  2. 投票相关细节

    主席有决定性的一票。 当技术委员会投票决定是否推翻同时也是委员会成员的开发人员时， 该成员不得投票（除非他们是主席，此情况下他们只能投决定性的一票）。

  3. 公开讨论和决策。

    讨论、决议草案和修正案以及委员会成员的投票将在技术委员会 公开讨论列表上公布。 委员会不设单独的秘书。

  4. 任命的保密。

    技术委员会可通过私人电子邮件、私人邮件列表或其他方式秘密讨论委员会 的任命。但是，对任命的投票必须是公开的。

  5. 不参与细节设计工作。

    技术委员会不参与新提案和政策的设计。 此类设计工作应由个人单独或共同进行， 并在一般的技术政策和设计论坛上讨论。

    技术委员会仅限于在于其他地方提出并经合理彻底讨论的解决方案和决定 之间作出选择或采取折衷办法。

    技术委员会的成员可以代表他们自己参与设计和政策工作的任何方面。

  6. 技术委员会做决定只作最后手段。

    技术委员会在试图通过协商一致方式解决该问题的努力失败之前， 不会作出技术性决定，除非通常负责该决定的人或机构要求它作出决定。

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. 提案

正式程序从按要求提出决议草案并成为提案时开始。

A.1. 讨论与修正

  1. 提案提出后，可对决议进行讨论。 根据新决议的要求，修正案可以根据新决议 的要求提出和支持，也可以由原决议的提出者直接提出。
  2. 正式修正案可被决议提出者接受，此情况下，正式决议草案立即照此更改。
  3. 如果正式修正案未获接受，或该决议的支持者之一不同意提出者接受正式修正案， 则该修正案仍将作为修正案予以表决。
  4. 如果原提出者接受的修正案不符合其他人的喜好，他们可以提出另一项修正案 来推翻先前的变更（同样，他们必须满足提出者和支持者的要求）。
  5. 决议提出者可以建议修改修正案措辞；修正案提出者同意且提出者无异议的， 该等修改生效。此情况下，将对修改后的修正案进行表决。
  6. 决议提出者可以在 24 小时内对较小错误（例如，印刷错误或不一致）进行修正 或作不改变含义的更改，需无人在 24 小时内提出异议。 此情况下，最短讨论期限不会重新计算。

A.2. 要求投票

  1. 动议或修正案的提出者或支持者可要求投票，前提是最短讨论期（如有）已结束。
  2. 决议的提出者或任何支持者可要求对该决议及其所有相关修正案进行表决。
  3. 要求投票的人应陈述他们认为的决议和任何相关修正案的内容，以及投票应采取 的形式。 不过秘书拥有投票形式的最终决定权——见 7.1(1)，7.1(3) 和 A.3(4) 节。
  4. 最短讨论期从最后一次正式修正案被接受时算起，或在没有提出和接受修正案的 情况下自决议提出之日起计算。

A.3. 表决程序

  1. 每项决议及其相关修正案均以单次投票方式进行表决，其中包括原决议、 每项修正案和默认选项（如适用）。
  2. 默认选项不得有任何绝对多数票要求。 无明确绝对多数要求的选项遵循 二分之一多数要求。
  3. 根据 A.6 节中的规则计票。除非另有规定，默认选项为进一步讨论。
  4. 如有疑问，项目秘书应决定程序事项。

A.4. 撤回决议或不被接受的修正案

决议或未获接受的修正案的提出者得撤回之。 此情况下，一个新的提出者可继续提出以延续它， 第一个这样做的人将成为新的提出者，后续的人将成为成为支持者（若现在不是）。

决议或修正案（除非已被接受）的支持者可以撤回其决定。

如果提出者和/或支持者退出以致一项决议没有提出者或支持者不足，则需在决议 到期前解决，否则将不予表决。

A.5. 到期

如果提出的决议在 4 周内未经讨论、修正、表决或以其他方式处理，秘书可发布声明 说明该问题将被撤回。若一周内无其支持者反对，该议题将被撤回。

如有必要，秘书可就如何继续进行提出建议。

A.6. 计票

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

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