Following system colour scheme - Python 增强提案 Selected dark colour scheme - Python 增强提案 Selected light colour scheme - Python 增强提案

Python 增强提案

PEP 8016 – 方向委员会模型

作者:
Nathaniel J. Smith, Donald Stufft
状态:
已接受
类型:
信息
主题:
治理
创建:
2018-11-01

目录

注意

此 PEP 为历史目的保留,但官方治理文档现为 PEP 13

摘要

此 PEP 提出了一种基于方向委员会的 Python 治理模式。该委员会拥有广泛的权力,他们努力尽量少地行使这些权力;相反,他们利用这种权力来建立标准流程,例如在其他 801x 系列 PEP 中提出的流程。这遵循了一般哲学,即最好将大型变更分解成一系列可以独立审查的小型变更:我们不尝试在一个 PEP 中完成所有工作,而是专注于为进一步的治理决策提供最少但坚实的基石。

PEP 接受

PEP 8016 于 2018 年 12 月 17 日星期一,根据 PEP 8001 中描述的 核心开发人员投票 接受。

基本原理

本提案的主要目标是

  • **枯燥**:我们不是治理专家,我们也不认为 Python 是一个试验新颖和未经考验的治理模式的好地方。因此,本提案尽可能地坚持成熟、知名、经过验证的流程。一个主要放手管理的委员会的高层方法可以说是大型成功的 F/OSS 项目中最常见的,而低层细节则直接源自 Django 的治理。
  • **简单**:我们试图将内容精简到使该提案可行所需的最低限度:委员会、核心团队(选举委员会)以及更改文档的流程。目标是最小可行治理。
  • **全面**:但对于我们需要定义的内容,我们试图确保涵盖所有方面,因为我们不想再次经历这种危机。制定清晰明确的规则也有助于最大限度地减少混乱和怨恨。
  • **灵活和轻量级**:我们知道,找到最佳合作流程需要时间和试验。通过将本文档尽可能精简,我们可以最大限度地灵活地调整后续内容,同时最大限度地减少对重型和令人焦虑的流程(如全项目投票)的需求。

许多细节在 此 Discourse 线程 中讨论,然后 此线程有进一步的讨论。这些可能对任何试图理解各种小决策基本原理的人有用。

规范

方向委员会

构成

方向委员会是一个 5 人委员会。

任务

方向委员会应努力

  • 维护 Python 语言和 CPython 解释器的质量和稳定性,
  • 使贡献尽可能地易于访问、包容和可持续,
  • 正式化并维护核心团队与 PSF 之间的关系,
  • 为 PEP 建立适当的决策流程,
  • 在以正式身份行动之前,寻求贡献者和核心团队之间的共识,
  • 充当所有其他方法都失败的决策“最终上诉法院”。

权力

该委员会拥有对项目做出决策的广泛权力。例如,他们可以

  • 接受或拒绝 PEP
  • 执行或更新项目的行为准则
  • 与 PSF 合作管理任何项目资产
  • 将部分权力委托给其他小组委员会或流程

但是,他们不能修改此 PEP,也不能影响核心团队的成员资格,除非通过此 PEP 中指定的机制。

该委员会应寻找尽可能少地使用这些权力的方法。与投票相比,寻求共识更好。与裁决单个 PEP 相比,定义 PEP 决策的标准流程更好(例如,通过接受其他 801x 系列 PEP 之一)。建立行为准则委员会比裁决个案更好。等等。

为了行使权力,委员会进行投票。每个委员会成员都必须投票或明确弃权。对特定投票有利益冲突的成员必须弃权。通过需要获得大多数非弃权委员会成员的支持。

只要可能,委员会的讨论和投票应公开进行。

选举委员会

委员会选举包括两个阶段

  • 阶段 1:候选人宣传他们担任该职位的意愿。候选人必须由核心团队成员提名。允许自我提名。
  • 阶段 2:每个核心团队成员可以对零至五名候选人进行投票。投票是匿名进行的。根据候选人收到的总票数对其进行排名。如果出现平局,可以通过候选人之间的相互协议来解决,否则将随机选择获胜者。

每个阶段持续一到两周,由离任委员会自行决定。对于首次选举,两个阶段都将持续两周。

选举流程由离任方向委员会提名的计票员管理。对于首次选举,计票员将由 PSF 执行董事提名。

该委员会应该理想地反映 Python 贡献者和用户的多样性,鼓励核心团队成员相应地投票。

任期

在每次功能发布后选举新的委员会。每个委员会的任期从他们的选举结果最终确定之时开始,到下一届委员会任期开始之时结束。没有任期限制。

空缺

委员会成员可以随时辞职。

每当在正常委员会任期内出现空缺时,委员会可以投票任命一名替补,以完成剩余任期。

如果委员会成员失去联系,并且在一个月或更长时间内无法联系到,那么其他委员会成员可以投票替换他们。

利益冲突

虽然我们相信委员会成员会以 Python 的最佳利益而不是他们自己或他们的雇主来行事,但仅仅是某家公司主导 Python 开发的表象本身也可能是有害的,并损害信任。为了避免任何利益冲突的表象,最多只有 2 名委员会成员可以为同一雇主工作。

在委员会选举中,如果前 5 名得票者中的 3 名为同一雇主工作,那么排名最低的人将被取消资格,排名第 6 的候选人晋升至第 5 位;重复此操作,直到形成有效的委员会。

在委员会任期内,如果由于环境变化导致违反了这条规则(例如,由于委员会成员更换雇主),那么一名或多名委员会成员必须辞职以解决问题,然后可以按正常方式填补由此产生的空缺。

驱逐核心团队成员

在特殊情况下,可能需要违背其意愿将某人从核心团队中移除。(例如:严重且持续的行为准则违规。)这可以通过方向委员会投票来实现,但与其他方向委员会投票不同,这需要至少三分之二的多数票。在 5 名成员投票的情况下,这意味着 3:2 的投票是不够的;4:1 的支持是此类投票成功的最低要求。此外,这是方向委员会唯一不能委托的权力,并且这种权力不能在不信任投票进行时使用。

如果被驱逐的核心团队成员也在方向委员会中,那么他们也将从方向委员会中移除。

不信任投票

在特殊情况下,核心团队可以通过不信任投票来移除现任委员会成员或整个委员会。

当核心团队成员在适当的项目通信渠道上公开呼吁进行不信任投票,而另一名核心团队成员附议该提议时,将触发不信任投票。

投票持续两周。核心团队成员投票赞成或反对。如果至少三分之二的投票者表达了不信任,那么投票就成功了。

不信任投票有两种形式:针对单个成员的投票和针对整个委员会的投票。对不信任投票的初始呼吁必须指定要进行哪种类型的投票。如果针对单个成员的投票成功,那么该成员将从委员会中移除,由此产生的空缺可以以通常的方式处理。如果针对整个委员会的投票成功,该委员会将被解散,并立即触发新的委员会选举。

核心团队

角色

核心团队是管理 Python 的一群值得信赖的志愿者。他们承担实现项目目标所需的许多角色,特别是那些需要高度信任的角色。他们做出了塑造项目未来的决定。

核心团队成员应代表社区以及所有依赖 Python 的人,充当社区的榜样和项目的守护者。

在必要的情况下,他们将在在线讨论或官方 Python 活动中进行干预,在罕见的情况下出现需要干预的情况。

他们对 Python 项目基础设施拥有权力,包括 Python 项目网站本身、Python GitHub 组织和存储库、错误跟踪器、邮件列表、IRC 频道等。

特权

核心团队成员可以参加正式投票,通常是提名新的团队成员和选举方向委员会。

成员资格

Python 核心团队成员展示了

  • 对 Python 项目哲学的深刻理解
  • 在建设性和帮助方面有良好的记录
  • 以任何形式对项目目标做出重大贡献
  • 愿意花时间改进 Python

随着项目的成熟,贡献超出了代码。以下列出了被视为加入核心团队的贡献领域(不分先后):

  • 从事社区管理和外联工作
  • 在邮件列表和 IRC 上提供支持
  • 对票证进行分类
  • 编写补丁(代码、文档或测试)
  • 审查补丁(代码、文档或测试)
  • 参与设计决策
  • 在特定领域提供专业知识(安全、国际化等)
  • 管理持续集成基础设施
  • 管理服务器(网站、跟踪器、文档等)
  • 维护相关项目(替代解释器、包装等核心基础设施)
  • 创建视觉设计

核心团队成员资格是对那些持续做出贡献并与 Python 项目理念和目标高度一致的贡献者的认可。

获得核心团队成员资格需要至少获得核心团队三分之二的投票赞成,并且没有指导委员会的否决。

核心团队成员始终在寻找有潜力的贡献者,教他们如何管理项目,并在他们准备好时提交他们的名字供核心团队投票。

核心团队成员资格没有时间限制。然而,为了让公众能够合理地了解有多少人维护 Python,鼓励已经停止贡献的成员将自己声明为 "非活跃"。那些在两年内没有做出任何非微不足道的贡献的人可能会被要求将自己移到这个类别,如果他们没有回应,就会被转移到那里。为了记录和表彰他们的贡献,非活跃的团队成员将继续与活跃的团队成员一起列出;并且,如果他们后来恢复贡献,他们可以随意切换回活跃状态。但是,当一个人处于非活跃状态时,他们会失去积极的权限,例如投票或提名指导委员会成员,以及提交访问权限。

最初的活跃核心团队成员将包括目前在 GitHub 上的 “Python 核心” 团队中列出的所有人,而最初的非活跃成员将包括所有过去曾经是提交者的其他成员。

更改本文档

对本文件的修改需要至少获得核心团队三分之二多数投票。

待办事项

  • 许多人提供了有益的建议和反馈;我们应该检查他们是否愿意被添加为共同作者。
  • 看来 Aymeric Augustin 编写了整个 Django 文档,所以大概拥有版权;也许我们应该问问他是否愿意将它发布到公共领域,这样我们下面的版权声明就可以更简单了。

致谢

大量文本是从 Django 项目的治理文件[https://docs.django.ac.cn/en/dev/internals/organization/](https://docs.django.ac.cn/en/dev/internals/organization/) 中shamelessly copied。


来源: [https://github.com/python/peps/blob/main/peps/pep-8016.rst](https://github.com/python/peps/blob/main/peps/pep-8016.rst)

最后修改: [https://github.com/python/peps/commits/main/peps/pep-8016.rst](https://github.com/python/peps/commits/main/peps/pep-8016.rst)