Closing the loop on PyPA Governance / BDFRN

I had the feeling that PEPs are for projects/decisions that affect more than one component in the ecosystem. What about decisions/design reviews/call for comments that are for a single component (e.g. pip, pipenv, virtualenv)? I suppose these can happen under the projects repository, but was hopping for having a unified method for all projects under PyPa, a unique portal that we can all follow without needed to follow all issues under a project. An option could be to send mails down distutils mail list with links to the repo issue/discussion board.

PEPs are for interoperability specs, basically - anything which multiple tools (either real ones or just potential ones - no-one has written an alternative to pip yet, but we want to allow for the possibility) might need to refer to. Things that only affect a single project internally are handled by the project’s own processes (typically the project’s tracker).

But I do also feel that it would be nice to have a “PyPA” forum, where larger decisions for individual tools can happen1 - not because they involve interoperability issues, but simply to share expertise with other PyPA members. But I don’t think there is such a thing at the moment (unless you count here, but it’s often hard to distinguish between PyPA discussions and “general public” discussions here).

1 I assume you’d be thinking of the “virtualenv next generation” discussion as an example here.

Partially that too, but additionally I would expect we have better governance in place to tackle general day to day issues too. For example when pip 19.1 broke editable installs I feel like needing three weeks to release a fix was a bit too long. Much of those three weeks was spent with coming up with a solution we could all agree on, over at least three separate forums (discourse, pip Github issue tracker, distutils, twitter). I would hope we can streamline these as part of PyPi Governance.

I’m not 100% sure what you mean here, but I’m deeply concerned about the idea that the PyPA would somehow involve themselves in how individual projects run themselves. Having better means of discussing responses to issues would be great (IMO, part of the problem with the editable install issue was the lack of anywhere we could discuss solutions without endless repeats of the “you broke pip, fix it NOW” complaints) - maybe a PyPA mailing list would help there. But having the PyPA as a group where people can escalate grievances with how individual projects make decisions would, in my opinion, be counter productive.

Definitely not grievances, I’m deeply sorry if it came through to like that. The PyPa as it stands down is a very loose thing, with very little governance (for better or worse). People tend to trust projects that live under the PyPa umbrella though. As such we should have a dedicated channel we (periodically) all come together, discuss and come to conclusion in a timely manner of either:

  • major decisions (even at individual tool level),
  • major issues.

Mostly because of the success or the hardships of individual projects that live under the PyPa brand will define how much people trust other projects under the PyPa organization. I hear way too often that python packaging is broken at multiple levels, and would like to change peoples perception on this.

1 Like

Strong +1 on this, but this is “communications”, not “governance”.

Some time ago, I suggested (somewhere, I don’t recall where) that getting someone with experience to help us with all aspects of communications might be worthwhile (internal communications, publicising our work, user outreach, etc). I don’t know if that’s something a grant-based project would be useful for?

1 Like

I suppose yes it is communication. The place where I’d imagine governance comes in is to not let discussion spiral around endlessly. A moderator sort of (potentially nominated by the governance/PEP delegate) that time boxes things, keeps things on topic, manages the discussion, sums up conclusions.

The packaging WG authorised spending PSF money on this a while back. The challenge is that it’s hard to hire someone if you don’t know what to ask for as project deliverables - while you can do time & materials “Help us figure out what we should be asking you to deliver” style contracts, those are also the ones that can be hardest to justify after the fact as money well spent.

I do agree that we have multiple challenges though:

  • clear communications channels between PyPA members both to resolve already existing problems (e.g. our miscommunications around the PEP 517 migration that broke pip 19.1), and to help check design changes for potential problems before they’re published
  • clear communications from PyPA to the rest of the world (it’s OK when there’s a PSF-backed project running with paid comms work as part of it, but we tend to let it fall by the wayside when it’s a purely volunteer activity)
  • a governance model to help make decisions about things like the above two points, as well as other issues mentioned further up this thread

The one area that I think we’ve actually got into a reasonable shape over the past few years is the interoperability specs - PyPA specifications - Python Packaging User Guide is a much nicer overview resource then simply linking to the PEP index, and using the PEP process to suggest changes to an external reference document is a much better fit for the way the PEP process was originally designed than attempting to use the PEPs themselves as reference documents.

What we need in such conversations is someone who’d champion the discussion and the work that it entails. I don’t think they need to get the authority to do so from a governance model.

I’m biased here since IMO my first major-ish contribution was managing a long discussion and poking it regularly to keep it from stagnation. It would be (more!) difficult to have that kind of scenario (external contributor who has not done much but spent a lot of time on the sidelines, championing a discussion) if certain amount of authority here comes from whatever governance model we have.

What I’m trying to say is, I might not have made the jump to the dark side if we had such a rule back when I had started contributing. :slight_smile:


@dustin Would you be working on an updated model that separates the governance model from the RFC process change?

Pinging @dustin on this again.

A joint reply to @pf_moore @ncoghlan @bernatgabor and @pradyunsg and anyone else who’s wondering about:

You may have seen the December 2018 post on pypa-dev in which I mentioned that Changeset would be doing communication/facilitation/roadmap work for PyPA. I’ve now posted an update (belatedly for sure!) about what’s happened since then and what Changeset’s work has gone into so far.

I’m glad @dustin started this thread, which I think is pretty related to Remove the "Authority" from Packaging I do think that the PyPA needs to, at the least, make it clearer how a person or project joins the PyPA, what the criteria are, what powers it believes itself to hold, under what circumstances the PyPA would stop including a person or project (perhaps because of inactivity), and whether we want some kind of unified roadmap that we’re all working towards. And deciding all of those things are easier if we have someone who is sort of like the Debian Project Leader or a clerk in a Quaker meeting, and that’s what I’d particularly appreciate in a BDFRN role.

Yes, if we decide we want to stick with the PEP process, I think this would be reasonable to do.

Agreed. I think this discussion is pretty focused on making technical decisions, but there are a number of other decisions that occasionally need to be made that are currently very ambiguous (especially to “outsiders”) and would benefit from a governance model.

Essentially, we could re-invision this discussion as an alternative to Remove the "Authority" from Packaging, and put actual authority in the organization.

1 Like

:heart_eyes:

Let’s do this then – we can switch away from the PEP process at a later date if we deem that as necessary; a model that changes as little from status quo as possible would likely be easier to work with right now.

Is anyone working on the updated governance model, that uses the PEP process?

governance model, that uses the PEP process?

Well… I found some time today (while procrastinating on my assignments) and came up with one. :slight_smile:

I created a new topic for discussing that model: PyPA Governance - A "Status-Quo" Model.

I’ve taken Pradyun’s modifications to my original proposal and turned it into a PEP draft (with some very light editing):

10 posts were split to a new topic: Should PyPA opt out of the PEP process?

The PEP is now published:

Per request I’ve also started a discussion thread in the “PEPs” topic:

https://discuss.python.org/t/pep-609-pypa-governance/

1 Like

A post was merged into an existing topic: Should PyPA opt out of the PEP process?