PyPA Governance - A "Status-Quo" Model

Packaging
1

Following from the “Closing the loop on PyPA Governance / BDFRN” topic, I felt it would be best to start with a governance model that was close to our existing practices.

I found a few hours today to polish up my thoughts on that and write something up –
a “PyPA Status-Quo Governance Model” – https://gist.github.com/pradyunsg/e3f7de20f41dd49214954802eff35f90

A quick summary of this model:

  • Redefines “PyPA members” as folks w/ triage or commit bit. Introduces “PyPA committers” as folks w/ commit bit.
  • Has the same goals for PyPA, as the “Lightweight” model.
  • Uses our already-documented process at pypa.io, for interoperability standards.
    • I’ve not moved language from pypa.io, but we’d probably want to do that in the final form of this model.
  • Uses voting for governance decisions, adopted from core team voting in PEP 13:
    • "at least two thirds of voters vote +1"
    • 7 day period.
    • Only PyPA committers can vote.
  • Describes how projects can leave PyPA if they want to.

Feel free to suggest improvements and changes to this. Please drop a comment on the GitHub Gist if I’ve made language errors or typos, so that this topic only has “functional” discussions. :slight_smile:

If everyone is OK with the general approach outlined there, and our BDFRN (@dustin) gives us his go-ahead, we should probably formalize this into a PEP. I’ll be happy to do the writing work for that, if it’s before 1 October (otherwise it’s a maybe from me).

1 Like
2

Bumping this.

The only input I’ve gotten regarding this till now, is from @pf_moore seeking clarification on how the steering-council delegates their power to PyPA folks.

If you’re okay with this model as is, please :heart: this message. If you’re not, please drop a comment below.

2 Likes
3

4 posts were split to a new topic: Reporting outdated/unmaintained projects on PyPI?

4

Bumping this 2.0.

I’m not sure if the silence here is due to folks:

  • not having any concerns with the model or,
  • been able to make time to take a look at this and provide feedback or,
  • not being interested in moving forward this discussion.

Either way, I’m hoping we can get the ball moving on this sooner than later; especially since I will likely have a fair amount of time to put toward OSS in the coming weeks.

5

I always assume that when it comes to open source, else you will be waiting forever. :slight_smile:

2 Likes
6

I provided some feedback on the gist a couple weeks ago, but didn’t see a reply. Did you see that?

7

@cjerdonek Oh sorry! I’d missed that (in the swamp of my GitHub notifications).

I’ll move the discussion about it here, since this feels like a better place to discuss it. Hopefully you don’t mind that. :slight_smile:

and can choose one of +1, +0 and -1.

It seems like you’d also want -0 (as well as 0 if someone is truly neutral) for completeness.

TBH, I don’t know how I feel about so many zeros when we’re only counting +1s. I’m not inclined to add more,since the +0 is already equivalent to -1s since we’re only counting +1s vs total votes.

I guess it’s better to fix that – let’s only allow +1 or -1s in the votes, since intentionally abstaining is OK. It’ll involve taking much more explicit positions during voting (which is fine IMO), and avoid the case where voting 0 vs voting -1, have the same effect. This brings it in sync (AFAICT) with CPython’s current core team voting mechanics.

I’ve updated the proposal to use this model because I feel that 0 and -1 should not have the same effect, and I think this works better for the way we operate. All that said, I don’t really have any strong opinions around this area, so if someone has a suggestion for a better voting model than the one I’ve proposed here, please let me know. =)

It seems like it would be good for the “Goals” section to be centered on something concrete and external to the PyPA. Right now it seems a bit circular because it talks about things like supporting PyPA projects and deciding what should be a PyPA project, but never saying what these projects all have in common (aside from being PyPA projects) and in particular why they are PyPA projects.

That’s fair. I had that feeling too, but I wasn’t sure if it was me trying to over-polish this thing or if it was a legitimate concern. I’ve changed the start of the “Goals” section, adding language from pypa.io’s landing page (with slight changes).

I think that covers your concern here, but please do holler if that’s not the case. :slight_smile:

Maybe this could be handled by having a higher-level mission statement that talks e.g. about maintaining and furthering packaging for Python (and whatever other concrete things there are), and then the goals can reference back to the mission statement. Basically, it should answer the question of what is the underlying purpose of PyPA?

I think adopting a mission statement is likely something we can want to do as a follow up to this, if there’s interest in that. I don’t think that is directly related to our governance discussions per se.

My goal with this proposal, is to minimize the changes we make to the “status quo” in the process of adopting this model (obviously, other than formalizing the decision making process).

8

Another update – @ncoghlan reviewed the document and posted comments on the Gist (mostly clarifications), which I have addressed. :slight_smile:

@dustin Any suggestions on how to move forward here?

10

Thanks @pradyunsg. I’ve taken these modifications and turned it into a PEP draft (with some very light editing). Let’s take the discussion back to https://discuss.python.org/t/closing-the-loop-on-pypa-governance-bdfrn/.

1 Like
11

Hurray! Sounds like a plan. :slight_smile: