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
```

##### 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 <ncoghlan@gmail.com> wrote:
>
> On 7 June 2018 at 09:59, <dan@danryan.co> wrote:
>>
>> > > Recurring (weekly, monthly, or quarterly) synchronous meeting of the
>> > PyPA via a communications channel TBD.  This channel should allow for a log
>> > 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 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 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
>>
>>
>> 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 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/