Mailman 3 June 2018 - PyPA-Committers

Proposal: "Lightweight" governance model for PyPA
by Ernest W. Durbin III 31 May '19

31 May '19

Hello PyPA Committers! I'd like to start discussion on a possible governance model for the PyPA. ## Summary The model described here is what I consider a minimum viable governance for the Python Packaging Authority that would open realtime and asynchronous channels of communication for two purposes: - Keeping PyPA projects up to date on what one another are up to, and where they are headed. - Allowing the PSF Packaging Working Group insight into the PyPA's activities. This model is intended for coordination and communication among Python Packaging Authority projects and does not have bearing on the existing project structure or governance of individual projects beyond the existing requirement of adhering to the PyPA Code of Conduct. ## Model 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. Structure of meeting TBD, but a something along the lines of: Announcements, Old Business, New Business. A moderator and minute-taker would be responsible for summarizing the meeting, collecting project updates, and publishing minutes and updates for archival purposes and public review. Meeting note publication method TBD. Adherence to the PyPA Code of Conduct would be required for all attendees. ### Requirements #### For attendance as an observer: None (Note that observers can read/watch/listen the meeting in realtime but cannot participate/speak in the meeting.) #### For participation: - Maintainer of a PyPA project. - Contributed a summary of activity for the project ahead of meeting. - Contributed agenda items for Announcements or New Business. OR - Member of Python Software Foundation Packaging Working Group. ## Goals The basic design parameters I had in mind were: - Maintain independence of individual PyPA projects. - Provide a cadence to the PyPA's communications. - Create an incentive for centralized reporting of PyPA project activities. - Provide Packaging Working Group a way to understand what is going on in various PyPA projects, to understand how and where grants could make an impact.

13 32

Adding CoC link to the list description
by Nick Coghlan 22 Dec '18

22 Dec '18

Hi folks, It was recently pointed out to me that the distutils-sig list description is missing a CoC reference (see [1]), and it occurred to me that the description for this list should also link to the PyPA CoC: https://www.pypa.io/en/latest/code-of-conduct/ Cheers, Nick. [1] https://github.com/pypa/pypa.io/issues/33 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 3

PyPA, Governance and Communication
by Paul G 06 Jun '18

06 Jun '18

Kicking off a thread on the mailman: So basically then, the immediate questions are: > So basically then, the immediate questions are: > > A. Does all of the above sound reasonable to everyone involved here? > B. Do we want to just use a email chain with CCs on everyone as a temporary place for discussion for now until the above questions get answered, then move any subsequent stuff to whatever the answer is? > C. Are their additional people we should include? (I’ve CC’d everyone who is a maintainer of a PyPA project, since they’re the people this really effects, but if there’s some other important person to add then let’s do it). > D. If Yes to the above, who wants to be the BDFRN on the governance question? I think the consensus we have so far is that A is Yes, for B we created this mailman list (though the CCs are fine too) and no one has particularly enthusiastically volunteered for D. Consolidating the "half volunteered" votes here: 1. Donald Stufft 2. Paul Moore 3. Thea Flowers I have not included in this semi-summary Nick's proposal since it is more complicated and involves getting a grant. I personally think the grant thing is a useful idea but it's probably a good idea to have a BDFN independent of that who can be the final arbiter in this case. I don't know all the PyPA people as well as probably some of you, but Donald seems like a pretty natural choice to me for this. > Hey all. > > You’re getting this email because you’re listed as a maintainer on one of the projects that fall under the PyPA umbrella and you’re not someone that I know is now in-active and thus no longer really interested in this sorts of discussions. I’ve tried to default to open here rather than closed, so if you don’t feel particularly like you care about this, or you’re sort of a one off contributor that don’t want to really be involved in the larger PyPA and you want to focus on just your one project, then feel free to ignore this email! > > For everyone else, one of the things that I feel like came out of the packaging mini summit (and some subsequent discussion) is that we don’t really have very strong communication channels both between projects, and for projects to the world (and possibly even project to users?). This has generally been because PyPA has practically zero rules or infrastructure besides an org on Github and mandating the CoC, so we’ve never had anything that could function as that, and each individual project has been left otherwise entirely up to their own devices. This has lead to confusion, and a lack of a real good way to coordinate amongst ourselves. > > So ultimately we have a few underlying questions to ask ourselves here: > > 1. Do we want to introduce more governance to the PyPA? > 2. If we’re going to add more governance, how much do we want and what does that governance look like? > 3. What sort of communication channels do we want to add, promote, or even retire? > > So part of the problem with the fact we have no process, is that we have no process for deciding these questions. When I did the CoC thing, I just emailed all of the “member” projects, and asked if they had any opposition, nobody did so we made that a rule going forward. This is a little trickier because it has more room for having opinions about the specific shape the answers to each of those questions take and we’ve added more projects/people since then, so I’m going to assume that we’re unlikely to get a fully unanimous agreement on all of the details. > > We’ve been using the PEP process for similar style questions (unlikely to get fully unanimous etc), but I don’t think that the actual PEP process itself is the right tool here, because in terms of how we structure the PyPA, we don’t really need or want to care about what other random people think about how we organize ourselves. > > So here’s what I think we should do: > > We pick someone to act as a Benevolent Dictator For Right Now (BDFRN), whose sole charter is to act as the final decision maker for the above questions. Once those questions have been answered, the BDFRN role is over, and whatever (if any) new process takes over— or if we elect not to have anything new, then we just end the discussion there and continue as we are. > > The BDFRN will come up with a proposal first for answering the governance question, what, if any, governance we want to have and what shape that takes. This will effectively just be a “mini PEP” without any of the structure, just going through what that proposal is, how we make further decisions, etc etc. This will ideally be done with discussion amongst the people here (everyone I’ve CC’d is a maintainer of a PyPA project), and once the BDFRN has decided their proposal is ready, they’ll just call for a vote with some time limit 7 days?), and everyone involved here can +1, -1, +0, -0, or abstain (with no reply being abstain). Basically I see it working where if we get mostly +1/0 with no -1 and little to no -0 then the BDFRN will declare their proposal ratified, and we’ll switch to using whatever it is. > > If we don’t get a rough consensus, they’ll amend the proposal or possibly ultimately decide to keep the status quo if there isn’t governance that we want and can agree on. > > If that process does generate some level of governance with a decision making process, then I’d suggest we leave (3) from above as an open question for that new thing to decide. It’ll be a good first issue I think, and will give us a chance to test it, and possibly make tweaks to the system while it’s still new and fresh. > > If that process does not generate any level of governance with a decision making process, then I’d suggest we re-use the same process from above, except for communication channels. This could have a different BDFRN, or the same it doesn’t really matter. > > > So basically then, the immediate questions are: > > A. Does all of the above sound reasonable to everyone involved here? > B. Do we want to just use a email chain with CCs on everyone as a temporary place for discussion for now until the above questions get answered, then move any subsequent stuff to whatever the answer is? > C. Are their additional people we should include? (I’ve CC’d everyone who is a maintainer of a PyPA project, since they’re the people this really effects, but if there’s some other important person to add then let’s do it). > D. If Yes to the above, who wants to be the BDFRN on the governance question? > > My answers are: > > A: Yes > B: Yes > C: Maybe? I added everyone I could remember who were currently active maintainers, however there were a few folks (mentioned below) that I couldn’t locate email addresses for. > D: Don’t care, but am happy to do it if nobody else feels strongly about being it. > > > People I couldn’t locate email addresses for: > > pipenv: > - https://github.com/erinxocon > - https://github.com/vphilippon > > setuptools: > - https://github.com/idlesign <https://github.com/idlesign> > > As an aside, there are way more people in this list then there was when we added the CoC, and I think that’s awesome :D > > - Donald >

13 16