Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 609 – Python Packaging Authority (PyPA) Governance

Author:
Dustin Ingram <di at python.org>, Pradyun Gedam <pradyunsg at gmail.com>, Sumana Harihareswara <sh at changeset.nyc>
Sponsor:
Paul Ganssle <paul at ganssle.io>
Discussions-To:
Discourse thread
Status:
Active
Type:
Process
Topic:
Packaging
Created:
05-Nov-2019
Post-History:
05-Nov-2019
Table of Contents

摘要

本文件描述了 Python Packaging Authority（PyPA）的管理模式。该模型紧密地基于现有的非正式实践，目的是使 PyPA 的运作更加清晰，并使 PyPA 的透明过程正规化。

理论依据

The Python Packaging Authority (PyPA) is a collaborative community that maintains and advances many of the relevant projects in Python packaging. The software and standards developed through the PyPA are used to package, share, and install Python software and to interact with indexes of downloadable Python software such as PyPI, the Python Package Index.

目前，PyPA是一个非正式的、定义松散的组织，缺乏真正的权威，将某个项目纳入 PyPA 的保护伞或创建新项目都是以临时的、一次性的方式进行的。同样，PyPA 的个人成员资格也没有明确的定义”

虽然这种模式在过去或多或少对 PyPA 起了作用，但它导致一个组织缺少一个稳定的生态系统的某些特征，即一个清晰和透明的决策过程。本项目旨在通过为 PyPA 定义一个管理模式来纠正这一问题”

名词解释

本 PEP 中使用的个人贡献者群体的相关术语：

PyPA 成员：
Anyone with the triage bit or commit bit, on at least one project in the PyPA organization.
PyPA 提交者：
Anyone with the commit bit on at least one project in the PyPA organization, which should correspond to everyone on the PyPA-Committers mailing list.
PyPA 社区：
任何对 PyPA 活动感兴趣并想关注、贡献或提出建议的人”
Packaging-WG 成员：
As described in the Packaging-WG Wiki page. For clarity: there is no formal relationship between the Packaging-WG and PyPA. This group is only included in this list to disambiguate it from PyPA.

目标

以下部分正式确定了 PyPA 的目标（和非目标）以及这种治理模式。

PyPA 的目标

这些目标是PyPA存在的主要动机。这些目标在很大程度上已经在实施，尽管大多数没有明确的定义。

为 PyPA 下的现有项目提供支持

如果某个项目需要额外的支持，或者不再有活跃的维护者，PyPA 将确保在必要的范围内继续为用户支持该项目。

促进 PyPA 项目标准的建立和接受

PyPA 应该尽可能地努力实现 PyPA 项目之间的标准化和协调，主要是通过以下概述的治理过程。PyPA 项目应遵守由 PyPA 维护的适用规范。

指导影响多个 PyPA 项目的决策

在提出整个生态系统的变化时，应该期待 PyPA 社区（特别是 PyPA 成员）提供意见、见解和经验。

确定哪些项目应接受 PyPA 的指导

例如：接受社区的新项目，在 PyPA 内有机地创建项目，等等。

在所有项目中强制遵守《行为守则》

一般来说，这意味着以身作则，但偶尔也可能意味着更明确的节制。

PyPA 的非目标

这些是明确不是 PyPA 目标的具体项目。

确定谁是和不是 PyPA 成员

这是由各个项目的成员决定的，因为他们在自己的项目中增加了新成员。在 PyPA 组织下的项目的维护者会自动转为 PyPA 的成员。

对个别项目进行微观管理

只要项目遵守行为准则并遵循 PyPA 支持的规范，PyPA 应该只关注大型的、全生态系统的变化。

制定和维护独立的《行为守则》

PyPA projects follow the PSF Code of Conduct.

PyPA 的治理模式的目标

这些都是治理模式所要实现的新目标。

PyPA 成员的透明度

为所做的决定提供一个透明的过程，关于 PyPA 中的项目成员资格”

记录 PyPA 使用 PEPs 的情况

正式记录 PyPA 如何使用 Python 增强提案（PEPs），以维护 PyPA 定义的互操作性规范。

过程

下面概述了PyPA的活动过程。

规格说明

PyPA 将使用 PEPs 来定义 PyPA 所维护的互操作性规范，并对其进行修改。因此，Python 指导委员会对这些互操作性规范的接受有最终决定权。

It is expected (but not required) that the Python Steering Council would delegate authority to sponsor and/or approve/reject PEPs related to packaging interoperability specifications, to individuals within the PyPA community. At the time of writing (June 2020), the Python Steering Council has standing delegations for currently active packaging interoperability specifications.

The details of the process of proposing and updating the interoperability specifications are described in the PyPA Specifications document.

管理

PyPA 提交人投票

A PyPA member can put forward a proposal and call for a vote on a public PyPA communication channel. A PyPA committer vote is triggered when a PyPA committer (not the proposer) seconds the proposal.

The proposal will be put to a vote on the PyPA-Committers mailing list, over a 7-day period. Each PyPA committer can vote once, and can choose one of +1 and -1. If at least two thirds of recorded votes are +1, then the vote succeeds.

PyPA committer votes are required for, and limited to, the following kinds of proposals:

Addition of a project to the PyPA

Proposing the acceptance of a project into the PyPA organization. This proposal must not be opposed by the existing maintainers of the project.

Creation of a new project in the PyPA

Proposing the creation of a new tools / project in the PyPA organization.

Removal of a project from PyPA

Proposing the removal of a project in the PyPA organization.

Updates to the Governance/Specification Processes

Proposing changes to how the PyPA operates, including but not limited to changes to its specification and governance processes, and this PEP.

Leaving PyPA

A project that is a part of the PyPA organization, can request to leave PyPA.

Such requests can made by a committer of the project, on the PyPA-Committers mailing list and must clearly state the GitHub user/organization to transfer the repository to.

If the request is not opposed by another committer of the same project over a 7-day period, the project would leave the PyPA and be transferred out of the PyPA organization as per the request.

Code of Conduct enforcement

Each project that is a part of the PyPA organization follows the PSF Code of Conduct, including its incident reporting guidelines and enforcement procedures.

PyPA members are responsible for leading by example. PyPA members occasionally may need to more explicitly moderate behavior in their projects, and each project that is a part of the PyPA organization must designate at least one PyPA member as available to contact in case of a Code of Conduct incident. If told of any Code of Conduct incidents involving their projects, PyPA members are expected to report those incidents up to the PSF Conduct WG, for recording purposes and for potential assistance.

Source: https://github.com/python/peps/blob/main/pep-0609.rst

Last modified: 2022-06-14 21:22:20 GMT