On Wed, 8 Aug 2018, 07:14 Dustin Ingram,
Hi all, sorry for a bit of a delay here. I have a first draft of the governance model I've been working on for the PyPA, and I'd like to solicit some feedback.
TL;DR: it's consensus-based governance using a lightweight RFC process.
I've included the plaintext below for quote-ability, but it might be easier to read it rendered here: https://gist.github.com/di/c785bf9a04f6c5f52d7baf332204f05a
Cheers, D.
# PyPA Lightweight Governance Model In order to better serve the Python Packaging ecosystem, the following governance model is proposed for the Python Packaging Authority.
## Roles The following defines the various roles that may interact within the PyPA.
### PyPA members Anyone with the commit bit on at least one project in the PyPA organization, which should correspond to everyone on the [PyPA-Committers]( https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/) mailing list.
### PyPA community Essentially anyone who is interested in PyPA activity and wants to follow along or make proposals.
### Packaging-WG members As described in https://wiki.python.org/psf/PackagingWG
### BDFRN (Benevolent Dictator For Right Now) Dustin Ingram, at the moment.
## Goals Below are the primary goals and non-goals for the PyPA and it's governance model.
### Goals of the PyPA These goals are the primary motivation for the existance of the PyPA. These goals are largely already being carried out, even though most have not been explicitly defined.
#### Provide support for existing projects under the PyPA In the event that a given project needs additional support, or no longer has active maintainers, the PyPA will ensure that the given project will continue to be supported for users to the extent by which is necessary
#### Foster the creation and acceptance of standards for PyPA projects The PyPA should, as much as possible, strive for standardization and coordination across PyPA projects, primarily though the governance process outlined below.
#### Guide decisions which affect multiple PyPA projects The PyPA community (especially PyPA members) should be expected to provide opinions, insight and experience when ecosystem-wide changes are being proposed.
#### Accept new projects into the PyPA Either from the community, or created organicaly by the PyPA. This is done via the same governance process.
#### Enforce adherence to the CoC uniformly across all projects Generally this means leading by example, but occasionally it may mean more explicit moderation.
### Non-goals of the PyPA These are specific items that are explicitly _not_ goals of the PyPA.
#### Determine who is and isn't a PyPA member This is for maintainers of individual projects to decide as they add new maintainers (committers) to their projects. Maintainership of a project that is under the PyPA organization automatically transfers membership in the PyPA.
#### Micromanage individual projects development As long as the project is adhering to the Code of Conduct, the PyPA should only concerned with large, ecosystem-wide changes.
### Goals of the PyPA's Governance Model These are new goals which the governance model seeks to make possible.
#### Provide a consensus-driven decision-making process This will provide a more structured method of proposing and introducing changes than what currently exists, as well as a means by which PyPA members can decide which proposals will be accepted or rejected.
#### Provide a transparent record of proposed, accepted and rejected decisions Via an RFC process (described below), the proposed changes to the PyPA ecosystem will be centralized and standardized. This will allow both PyPA members and the wider PyPA community to understand the rationale, process and resolution of any change to the ecosystem.
## Process: The process for PyPA governance is outlined below:
### Lightweight Decision-Making Process:
#### 1. Creation of a Request for Comments (RFC) The RFC is created to propose changes to the PyPA ecosystem, with initial proposal, alternatives and tradeoffs, and submitted as a pull request to the `pypa/rfcs` repository. The structure of the RFC is defined below.
#### 2. Comments period During this period, the PyPA community and PyPA members publicly discuss the RFC to raise issues or concerns with the proposal, as comments on the pull request.
#### 3. Revision of the RFC by the author(s) to address comments This should be repeated above until "major objections" are fully addressed, or it's clear that there is a fundamental choice to be made.
#### 4. Put to vote Vote by the PyPA members (via the PyPA-committers mailing list) to confirm consensus (at least two +1's, more +1's than +0's, and no -1's) over a 5 day period.
The voting period should not include any significant changes to the RFC -- this should happen in the previous step, where anyone can participate. Voting should also not be conditional, e.g. "+1 if we make it do X instead of Y".
#### 5. Review Once voting has concluded, if the RFC has achieved consensus, it has been approved.
Otherwise, if the RFC has not achieved consensus, it goes to the BDFRN for review. At this point the BDFRN has the final say in accepting or rejecting the RFC.
Regardless of the outcome of the review, the pull request is then amended to reflect the resulting status, and merged.
#### 6. Implementation of the proposed change by maintainers If accepted, various maintainers then make the necessary changes.
#### 7. Conversion of the RFC into an Architectural Decision Record (ADR) Once implemented, the document should be updated in order to record what was actually implemented (if it differed from the proposed implementation).
### What requires an RFC: The following are examples of situations where an RFC should be proposed.
#### Significant user-facing changes Any change which is apparent to the user (highly visible new features, etc). This should not be for trivial changes, and thus should be used at the project maintainer's discretion (or upon suggestion from the PyPA).
#### Significant breaking changes or deprecations Any change which removes existing functionality or introduces a breaking change (e.g., deprecating the `python setup.py register` command). This should not be for trivial changes, and thus should be used at the project maintainer's discretion (or upon suggestion from the PyPA).
#### Changes affecting multiple PyPA projects Any change which would require modifications to more than one PyPA project (e.g., implementation of `Description-Content-Type` for Markdown READMEs)
#### New tools, systems, or standards Either proposing the creation of a new tool, system, or standard, or to accept a new project into the PyPA organization.
#### Changes to PyPA Governance or Policy Anything which would change how the PyPA or it's governance process works. Policy proposals should not be mixed with non-policy proposals (e.g., a proposal like PEP 541 "Package Index Name Retention" would not be mixed with a proposal detailing how PyPI plans to implement said policy).
### Creating a RFC: Below are the key components of an RFC:
#### Filename The filename should be sequential, containing the RFC number followed by the title. Example:
``` 001-adopting-python3.md ```
#### Title The title should be brief and to the point, short enough to fit in a commit message. Example:
``` # Title RFC-001: Adopting Python 3 ```
#### Summary The summary should be short and concise, maybe even 140 characters or less.
``` # Summary We decided to upgrade from Python 2 to Python 3 to support Unicode better. ```
#### Context The context describes the state of the system when the decision was made. It also records other external forces that come into play.
This should eventually become out of date, but still be contextually relevant. Without this context, the decision record might not make sense when reviewed in hindsight. And usually the implementation of this particular architectural decision will make the context out of date—but this is fine. For example:
``` # Context We are currently using Python 2 everywhere. The users want to start sending us Unicode characters in the API. ```
#### Decision The decision is made up of full sentences, in the active voice. Example:
``` # Decision We will migrate to Python 3 for services X, Y and Z. ```
#### Consequences This section should list all consequences (not just the benefits) to the decision, including what could go wrong. Example:
``` # Consequences We will be able to handle Unicode characters, but we might have to provide backwards-compatible support for some dependencies that haven't been ported to Python 3 yet. ```
#### Status The status section should only be one of the six following statuses. The flow is diagrammed as follows:
``` Proposed -----> Accepted ----> Implemented | | | V V V Rejected Deprecated Superseded ```
A minor process detail - I think Deprecated RFCs can move to Superseded, when the newer RFC is accepted. Ideally, this won't happen but that's a channel we might need someday.
##### Proposed A status of "Proposed" is the initial status of a newly created RFC, during the proposal, comment and consensus period.
##### Accepted A status of "Accepted" is assigned after a vote on the RFC has achieved consensus.
##### Rejected A status of "Rejected" is assigned after a vote on the RFC has failed to achieve consensus.
##### Implemented A status of "Implemented" is assigned after the proposed change has been completed by all necessary maintainers.
At the point at which the status changes from "Accepted" to "Implemented", the RFC should be revised to become an Architectural Decision Record (ADR), to accurately describe the true state of the ecosystem after implementation.
##### Deprecated A status of "Deprecated" is assigned to an RFC that was accepted, but either was not or could not be implemented.
##### Superseded A status of "Superseded" is assigned when a new RFC is proposed which oviates a previously implemented ADR. A link should be provided to the decision record which supersedes it:
``` # Status Superseded by [ADR-002](/adrs/002-going-back-to-python-2.md) ```
##### Links This section should contain relevant links depending on the status of the proposal. Example:
``` # Links Discussion: <https://github.com/pypa/rfcs/pull/42 Vote: < https://mail.python.org/mm3/archives/list/pypa-committers@python.org/thread/...
```
## Q&A
### Does this mean that we won't be using the PEP process anymore? For a number of things we currently use the PEP process for, such as defining standards, making changes to package metadata fields, etc., the answer is yes, this governance model is designed to replace that process, with these advantages:
* Lower barrier to entry for proposal authors * Wider audience of reviewers * More accessible to the community
This doesn't mean that we _can't_ use the PEP process anymore, however, it just limits the scope to changes that require it. This is somewhat subjective, but generally if a proposed change requires modifying CPython itself, it should be a PEP.
On Fri, Jun 8, 2018 at 8:39 AM Nick Coghlan
wrote: On 7 June 2018 at 09:59,
wrote: Recurring (weekly, monthly, or quarterly) synchronous meeting of the PyPA via a communications channel TBD. This channel should allow for
of discussions and some moderation.
Two things -- I think some kind of synchronous communication is incredibly helpful, especially for those of us who don't really know each other yet. The formality of email sometimes makes it difficult to develop a rapport, so I am a little worried that without any agreed-upon synchronous communication we will make it hard for people (like myself, as a newcomer to the PyPA) to collaborate and to feel empowered to assert a contrary position. Most of you probably have spoken to me at least once by now and know that I'm not exactly shy, but the rest of you, I'm not sure how I can get to know you personally without the aid of synchronous communication.
Right, having a common synchronous chat option (e.g. on
a log python.zulipchat.com) is incredibly useful for folks that don't personally like using Twitter as a global asynchronous water cooler (and there are *heaps* of reasons for folks to prefer to avoid Twitter).
On the other hand, formal meetings are somewhat problematic themselves
Roughly speaking I don't think decisions should be made synchronously
without allowing asynchronous input somewhere in the process.
Agreed (and I feel this especially keenly as someone that's essentially 8 hours out of sync with both the US and Europe, so it's personally and
because they tend to favor the most dominant voices and I would hate to silence a good idea by never giving it the space to be articulated. And like Paul, I spend most of my day in meetings, so I'm not eager to put more of those on my calendar. If there were some way to have a communication platform that supported both synchronous and asynchronous communication, that would be ideal... I know slack and others like it claim to do this, but slack is really built for synchronous communication. I'm not sure if there is a good option in this space professionally routine for me to have async conversations with 24 hour turn-around times between messages).
Synchronous comms are useful for tactical decision making on the scale
of hours or days where it doesn't really matter whether or not the conversation is inclusive (e.g. folks working on a targeted project like "Migrate PyPI to Warehouse and pypi.org" where the "Responsible & Accountable" lists are short, any required consultation happened up front, and it's OK for everyone else to just be informed of the outcomes after the decisions have already been made)
Synchronous comms also work well for collaborative discussion aimed at
helping folks that are currently disagreeing with each other better understand each other's perspective (since you can work through many more active listening iterations in a given amount of time synchronously than you can asynchronously).
However, synchronous events are appallingly awful for strategic decision
making in globally distributed communities. That's one of the reasons we effectively banned the Python Language Summit from actually making any binding language design decisions after the first couple: the folks missing from the in-person event significantly outnumber those that are present. (The other reason was a lack of search-engine-friendly records of the conversation, and that's a concern that applies to most electronic options as well: Google et al already struggle to give good search results from mailing lists, and they're even worse at finding relevant information in real time chat archives)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ PyPA-Committers mailing list -- pypa-committers@python.org To unsubscribe send an email to pypa-committers-leave@python.org https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/
_______________________________________________ PyPA-Committers mailing list -- pypa-committers@python.org To unsubscribe send an email to pypa-committers-leave@python.org https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/