Django Software Foundation（DSF）正在征求社区意见，计划新增一种“活跃投票会员”状态。核心变化并不是取消长期未投票者的会员资格，而是调整选举法定人数（quorum）的计算基数：过去两年参加过董事会选举的会员自动视为活跃，并计入法定人数；其他会员仍保留身份，但需要主动表达投票意愿后，才重新进入相应的投票名册与法定人数基数。
这项提案要解决的是一个典型的非营利组织治理问题：会员名册持续增长，但实际参与选举的人数没有同步增长。如果法定人数始终按照全部历史会员计算，一场获得大量有效选票的选举仍可能因为未达到门槛而失效。
改变的是法定人数基数，不是会员资格
理解这项提案时，需要把三个概念分开：
- 会员身份：不会因为两年内没有投票而丢失。
- 活跃投票状态：过去两年参加过董事会选举的会员自动获得；其他会员可以在选举开始前主动申请恢复。
- 法定人数基数：只统计当前处于活跃投票状态的会员。
未处于活跃状态的会员仍然是 DSF 会员，也会继续列在网站上。该状态主要用于判断一次选举是否达到有效门槛，而不是清理会员、撤销荣誉或永久剥夺投票资格。
可以把它看成从“历史上共有多少会员”转向“目前有多少会员明确愿意参与治理”。来源摘要还提到，按活跃成员计算法定人数是非营利组织中的常见做法，Python Software Foundation 也采用了相近机制：投票会员需要确认投票意愿，而其董事会在 2024 年 6 月批准，对参加过上一届董事会选举的人免除再次确认。
为什么全量会员名册会让选举越来越脆弱
假设某组织累计有 1,000 名会员，但长期稳定参与董事会选举的只有 300 人。如果章程要求超过半数会员参与，那么即使这 300 人全部投票，选举仍无法达到 501 人的门槛。
随着组织成立时间变长，这种差距通常会继续扩大：有人更换邮箱、离开项目、减少社区活动，或者单纯不再关注选举通知，但仍合法地保留会员身份。此时，全量名册反映的是组织的历史规模，而不是当前可动员的治理群体。
采用活跃状态后，如果 300 人在过去两年投过票，那么法定人数会围绕这 300 人计算。这样不会降低每张选票的效力要求，却能减少“沉默名册”导致整场选举无效的风险。
不过，这套制度也有边界：活跃人数越少，少数持续参与者对治理的影响越大。因此，状态更新必须透明，恢复流程必须简单，通知也不能只依赖一封容易被忽略的邮件。
用一个小脚本模拟两种计算方式
下面的 Python 脚本用于比较“全体会员基数”和“活跃会员基数”。示例假设法定人数比例为 50%，这只是便于理解的模型，并不代表 DSF 章程采用的具体公式。
将代码保存为 quorum_demo.py，然后运行 python quorum_demo.py：
from dataclasses import dataclass
from math import ceil
@dataclass(frozen=True)
class Election:
total_members: int
active_voting_members: int
ballots_cast: int
quorum_rate: float = 0.50
def required(self, membership_base: int) -> int:
return ceil(membership_base * self.quorum_rate)
def report(self) -> None:
old_required = self.required(self.total_members)
proposed_required = self.required(self.active_voting_members)
print(f'Total members: {self.total_members}')
print(f'Active voting members: {self.active_voting_members}')
print(f'Ballots cast: {self.ballots_cast}')
print()
print(
'All-member model:',
f'{old_required} required,',
'valid' if self.ballots_cast >= old_required else 'not valid',
)
print(
'Active-member model:',
f'{proposed_required} required,',
'valid' if self.ballots_cast >= proposed_required else 'not valid',
)
if __name__ == '__main__':
election = Election(
total_members=1000,
active_voting_members=300,
ballots_cast=180,
)
election.report()
示例输出会显示：按 1,000 名会员计算需要 500 票，180 票无法达到门槛；按 300 名活跃投票会员计算需要 150 票，同一次选举则可以达到门槛。
真实制度还需要明确几个实现细节：两年窗口如何精确计算、名册何时冻结、申请恢复状态的截止时间、重复记录如何处理，以及谁有权限审计状态变更。脚本只展示分母变化带来的影响，不能替代章程文本与正式选举规则。
防止“错过邮件就被排除”是关键
DSF 表示，不希望任何人仅仅因为漏看一封邮件而无法参与。按照当前提案，组织将在每次选举前发送提醒，并在博客和论坛发布通知；希望投票的会员可以在选举开放前联系 DSF，要求加入投票名册。
要让这个机制长期可信，实践中至少应满足以下条件：
- 多渠道通知：邮件、博客和论坛同时发布，避免单点失效。
- 清晰的个人状态查询：会员应能确认自己是否处于活跃投票状态。
- 低摩擦恢复：表达投票意愿不应要求重新申请会员资格。
- 明确的名册冻结时间：避免选举开始后临时改变法定人数基数。
- 保留审计记录：记录状态改变的时间和原因，同时限制个人数据访问。
- 定期公开汇总数据：例如会员总数、活跃投票会员数和实际投票数，但不必披露个人投票选择。
其中最值得关注的是时间边界。如果恢复申请必须在选举开放前完成，那么通知必须足够早，截止日期也应在每个渠道中保持一致。否则，一项旨在提高选举有效性的规则，可能反过来制造参与障碍。
仍是提案，社区反馈将决定下一步
相应的章程修改已经提交讨论，也经过 Django Forum 的持续交流以及 DjangoCon US 的线下讨论。目前它仍处于公开征求意见阶段，并非已经生效的规则。
社区可以在 2026 年 10 月 7 日前提交反馈；DSF 会员也可以在会员专属论坛主题中讨论。董事会将审阅意见。如果社区没有提出重大异议，董事会计划在 2026 年 10 月 8 日的会议上表决。
评估这项提案时，可以重点检查四件事：会员身份是否确实不受影响、恢复投票状态是否足够简单、通知机制是否覆盖充分，以及活跃名册能否被透明审计。若这些保障落实到章程和操作流程中，按活跃成员计算法定人数能够在保留开放参与的同时，降低会员规模增长给选举有效性带来的风险。