Thanks Dustin :)

Pradyun, maybe we could comment directly on the gist?

Nicole Harris
Kabu Creative

Mobile: + 44 (0) 7480 910 191

On 8 August 2018 at 07:40, Pradyun Gedam <> wrote:
Can we discuss this in a separate thread; since it's a fairly
different proposal from what Ernest proposed initially?


On Wed, Aug 8, 2018 at 7:14 AM Dustin Ingram <> wrote:
> 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:
> 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](
> 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
> ### 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 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:
> ```
> ```
> #### 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/
> ```
> ##### Links
> This section should contain relevant links depending on the status of
> the proposal. Example:
> ```
> # Links
> Discussion: <
> Vote: <>
> ```
> ## 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 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 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" 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   |   |   Brisbane, Australia
> > _______________________________________________
> > PyPA-Committers mailing list --
> > To unsubscribe send an email to
> >
> _______________________________________________
> PyPA-Committers mailing list --
> To unsubscribe send an email to
PyPA-Committers mailing list --
To unsubscribe send an email to