GLEP 77：Gentoo 一般决议

一般决议的可能主题

一般决议提供了以下可能性

1. 推翻（无效）任何理事会决定，前提是
   1. 所讨论的理事会决定是最终决定（即，一般决议不能用于绕过理事会），
   2. 该决定可以在不披露任何被视为机密的信息的情况下做出（例如，纪律处分申诉不能成为一般决议的主题）。
2. 发起对理事会成员的不信任投票，导致新的理事会选举。

一般决议的正式程序

一般决议机制定义如下

1. Gentoo 开发者（或一组 Gentoo 开发者）定义一般决议的主题——需要无效的具体动议，或上一节中定义的其他请求。
2. 请求者收集对其提案的初步支持。为了使一般决议投票成为可能，该请求需要得到 *N1* 名开发者的支持。开发者通过声明其同意以及一般决议的主题来附议该请求。这应以文本形式进行，并使用 OpenPGP 签名发送电子邮件给原始请求者。
3. 一旦收集到 *N1* 名开发者的签名批准，请求者将“一般决议请求”发送到 gentoo-project 邮件列表。该请求应包括决议主题、所有来自附议开发者的签名批准以及进一步讨论的基本原理。讨论至少持续两周。
4. 选举项目应确认一般决议的所有正式要求都已满足，并应说明投票时间表。投票期应在请求发布后的两周后开始，并持续两周。在邮件列表上发布请求时所有活跃的 Gentoo 开发者都有资格投票。
5. 开发者对一般决议的动议进行投票。为了使动议获得通过，正票与负票之比必须至少为 2:1。此外，正票数必须至少为 *N2*。

开发者人数最初定义为

• *N1*：活跃 Gentoo 开发者人数的 2 倍平方根，
• *N2*：活跃 Gentoo 开发者人数的四分之一，但不得少于 *N1*。

这些数字不进行四舍五入。所有法定人数均定义为“不少于”。

主题限制

一般决议机制的主要目的是为开发者提供一种方法，以便在必要时推翻理事会的决定或解散理事会。它并非旨在用作决策的常规程序。其限制和程序已专门为此而设计。

最值得注意的是，只有最终的理事会决定才能通过一般决议被推翻。这旨在防止开发者试图绕过理事会并将一般决议滥用为通用的决策过程。此外，为简化起见，一般决议不提供更改动议或提出新动议的方法——它仅提供使先前批准的动议无效的方法。

一般决议涉及所有开发者的投票。因此，所有开发者了解请求的基本原理并能够访问所有数据至关重要。这就是为什么该过程在投票之前需要公开讨论，以及为什么它不能用于取消纪律处分行动的原因。如果开发者认为理事会不正当地拒绝纪律处分申诉，他们可以请求进行不信任投票。

如果开发者认为理事会成员反复忽视其对开发者的职责，则提供不信任投票的替代方案。此选项使得可以在任期中途解散理事会并进行新的理事会选举。如果信任投票获得通过，理事会成员将立即失去其席位，并且在选举结束之前不会有理事会。

程序限制

由于一般决议需要所有开发者的投票，因此本 GLEP 提供了进一步的程序限制，以防止开发者滥用该程序反复呼吁所有开发者投票。

最值得注意的是，只有在所需数量的开发者首先附议该动议后，才能发起一般决议投票。建议通过私人渠道收集初步支持，以避免在 Gentoo 邮件列表上产生不必要的“我也是”流量高峰。使用 OpenPGP 签名确认开发者支持的真实性；签名消息需要包含原始动议，以防止将早期批准重新用于新的动议。

最初支持一般决议的开发者人数最低限度是为了防止一小部分开发者滥用该程序，同时使开发者能够真正地为正当使用一般决议收集支持。

投票要求 2:1 的多数，以及法定人数，也旨在阻止开发者试图滥用该程序。由于以这种方式做出的决定表明对理事会成员的严重指控，因此重要的是，它们实际上得到了开发者中相当一部分人的支持。

法定人数（*N2*，定义为活跃开发者人数的四分之一）有意低于最近理事会选举的投票率（2017 年为 39%，2016 年为 37%）。它以正票数来定义，以满足单调性标准（即，防止“否”票帮助动议获得通过）。

实践中的数字

假设开发者人数为 200 名活跃开发者。

*N1* 定义为 200 的 2 倍平方根，大约等于 28.3 名开发者。因此，为了发起一般决议，需要 29 名开发者的支持。随着新开发者的加入，这个数字增长不会很快——对于 300 名开发者来说是 34.6，对于 400 名开发者来说是 40。

*N2* 定义为活跃开发者人数的四分之一，投票多数定义为 2:1。这意味着，要使动议获得通过，必须至少获得 50 名活跃开发者的批准，且不得超过 25 名开发者积极反对。对于每一位投票“否”超过 25 的开发者，至少需要两名开发者投票“是”才能使动议获得通过。

一般决议的示例程序

让我们考虑以下示例。2018 年 2 月 30 日，理事会通过了一项动议，将 Gentoo 的默认初始化系统更改为 systemd。广大开发者社区似乎不同意此决定。开发者社区由 200 名开发者组成。

其中一位开发者提出了以下主题

推翻 2018 年 2 月 30 日理事会关于将默认初始化系统更改为 systemd 的决定。

他找到了 28 位不同意理事会决定的其他开发者，并将此文本发送给他们。他们向其中添加了明文签名，并将其发送回来。他添加了自己的签名主题，并准备了一个包含 29 个签名主题的文本文件。

此时，他向 gentoo-project 发送了以下邮件

尊敬的开发者社区：

我想就以下主题发起一般决议

推翻 2018 年 2 月 30 日理事会关于将默认初始化系统更改为 systemd 的决定。

我相信这是一个非常糟糕的决定，因为……

他将签名的批准作为文本文件适当地附加到邮件中。此时，关于该主题的讨论可以开始了。

选举项目的一名成员注意到请求并开始处理。首先，他确定投票的截止日期并创建一个合适的合格开发者列表。他下载签名的批准并使用GnuPG验证所有签名。之后，他确认使用的密钥与截止日期时 29 位不同开发者的指纹相匹配。

选举项目成员设置投票，使所提出的主题在初始邮件发出两周后开始。他向原始帖子发送回复，其中包含时间表和投票说明。

投票期结束后，选举项目收集结果。结果如下：

• 74 位开发者投票“是”，
• 37 位开发者投票“否”，
• 其余开发者要么弃权，要么未投票。

首先，验证法定人数。在本例中，需要 50 票“是”才能满足法定人数。由于 74 位开发者投票“是”，因此满足法定人数。

其次，验证比例。由于 37 位开发者投票“否”，因此至少需要 74 票“是”。由于正好有 74 位开发者投票“是”，因此动议通过。

然后，理事会决定无效。恢复之前的默认 init 系统。