Mailman 3 August 2018 - PyPA-Committers

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

30 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 21 Dec '18

21 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

With Regards to Dustin's Proposal
by Donald Stufft 03 Sep '18

03 Sep '18

I’ve been kind of on and off again in my time lately, so I haven’t had much time to push this. However I would like to bring back the discussion here to Dustin’s proposal. Besides the specific process itself, here is the basic gist of it: - Individual projects still control themselves. - The PyPA handles cross project decisions - Specific topics get a Interest Area Authority delegated to them, to act as the final decision maker (e.g. BDFL-Delegate). - Topics without an IAA, or ones where the IAA recuse themselves for whatever reason (time, conflict, whatever) fall back to voting by the PyPA committers. - No longer using the PEP process except for actual changes to Python itself (e.g. ensurepip would still have been a PEP, PEP 440 would not). Basically I think this is overall a good thing for us. The basic structure is largely similar to what we had setup under the PEP process, except instead of authority being delegated by the BDFL, it’s delegated by us, the PyPA. Ultimately I think this is better, because we’re the folks investing the most time and effort into this space. Particularly with python-dev grappling with what the future decision making process is for python-dev (which is going to change the PEP process). I think it would be confusing for us to have a process strictly for governance stuff, and then another process for non PEP-worthy changes, but that still are cross team, and then the PEP process itself. It’s a lot easier and simpler if we just use the same process for it all. Obviously we’ll still have the PEP process for changes to the interpreter or standard library, but that’s a pretty easy clear line to draw between “third party packaging stuff via the PyPA” and “First party standard library / interpreter”. I know that Paul was concerned about his role, and ultimately I think that with the changes Dustin has made, that role is preserved as an Interest Area Authority (assuming the PyPA votes to keep him in that role! Which I see no reason why we wouldn’t). However it gives us a better answer for what to do if Paul steps down, or feels the need to recuse himself for one reason or another (or the extremely unlikely situation that an IAA starts making harmful decisions). I also know that Nick has a few concerns with accessibility to the wider community, which I believe I addressed in the other email thread, but to reiterate, I don’t think that the wider community cares one way or another, and I think the biggest benefit comes from being able to tailor this process to what we need. So we can adjust it as we go along to what makes the most sense to us, without having to go to python-dev and get them to change their process to fit our needs. All in all, I’m a big fan of the proposal, and I think it is the right direction for us to move in.

5 10

Bloomberg Dev Sprint - Oct 27&28 - NYC/London
by Dustin Ingram 27 Aug '18

27 Aug '18

Hi all, As mentioned previously in a distutils-sig thread [0], Bloomberg is hosting an "open source weekend" development sprint focusing on tools in the PyPA ecosystem. The events are free and open to the public. In addition, Bloomberg has offered to arrange travel for up to 6 "mentors" to attend the event and lend expertise, (preferably 3 in each location, but this is flexible). If you are interested in being a mentor and DO NOT require travel assistance: 1. Reply to this thread indicating that you'd like to be a mentor 2. RSVP to the respective event below 3. Attend the event! If you are interested in being a mentor and DO require travel assistance: 1. Reply to this thread indicating that you'd like to be a mentor 2. RSVP to the respective event below 3. Email me with the dates, location, and where you will be traveling from 4. DO NOT book travel or accommodations yourself. Bloomberg is unable to directly reimburse mentors, and will book travel for you instead. 5. I will follow up with more details To RSVP and see more details about the event, follow the links below: NYC: 10/27: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/new-y… 10/28: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/new-y… LON 10/27: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/londo… 10/28: https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/londo… Any questions, please respond in this thread! Thanks! D. [0] https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/…

2 1