2. Coordination of funding - For the most part I imagine this will be dealt with in the PSF Packaging Working Group, but whatever PyPA-wide governance model we decide should probably at least be concerned with being aware of PyPA priorities which could be brought ot the PWG.
Funding is strictly the responsibility of the Packaging-WG. I think the main interaction here is "if the PyPA has a proposal that needs funding in some way, it will be brought to the WG once approved".
2. Per-project governance - The PyPA is a collection of otherwise independent projects, each of which has its own internal standards and governance, etc, and we don't want that to change.
Yes, there is a slightly grey line here between "things internal to a single project" and "things which affect the larger ecosystem" which is largely subjective. The idea here is that maintainers of a given project will know it when they see it, and take care to bring a proposal to the larger PyPA community when it is appropriate. Otherwise the project is free to operate however they please (aside from CoC adherence).
Conversely, we've not traditionally agreed standards by a vote, and I'm not sure it's something I'd be too keen on making into a formal process. It's too easy for people to take the stance "well, I didn't vote for it". At the moment, it's more a case of "you had your chance to express your opinions, so you need to accept the results". Of course, we've generally been fortunate in that most standards discussions have usually converged on a consensus (or if not consensus then at least exhausted acquiescence ;-)) and there's never been a real need for any sort of arbitration between entrenched opponents. For standards discussions at least, I'd like to see that continue, and I see my role as very much being to encourage participants to compromise and agree, and not to decide between choices[1].
I should say: it's also fine if we just don't want a governance model because we think the existing process is fine. However, for those that weren't at PyCon this year, one of the outcomes from the packaging mini-summit was the idea that we _might_ need a governance model, hence this proposal. D. On Wed, Aug 8, 2018 at 8:10 AM Paul Moore
On Wed, 8 Aug 2018 at 14:00, Paul Ganssle
wrote: I do think there's a reasonable distinction between standards and project governance, but it may be worth noting that without a PyPA-wide governance, we already have two reasonable levels of governance:
1. Standards - This is necessary for interop purposes between PyPA and non-PyPA projects (including things like proprietary mirrors, which are not likely to ever fall under the remit of the PyPA). 2. Per-project governance - The PyPA is a collection of otherwise independent projects, each of which has its own internal standards and governance, etc, and we don't want that to change.
In my original draft of this e-mail, I wrote up what I thought the role for a PyPA government would be separate from these two levels, but then I actually read✝ Dustin's proposal and realized he did all the work for me already in the goals section: https://gist.github.com/di/c785bf9a04f6c5f52d7baf332204f05a#goals
To the extent that PyPA governance overlaps with #1, so I don't see any real problems here.
Yes, if we consider "Standards" as independent of "PyPA governance" to the same extent as "Per-project governance" is, then that matches how I see things. In my previous reply to Dustin, that would categorise "PyPA governance" as the "policy" side of the distinction I drew there.
If anyone is interested in my own rough formulation of these goals (which has a lot of overlap with Dustin's even though it was developed independently), here are the three main areas of interest I see for PyPA-wide organization:
1. Coordination of communication - Intermittently making sure everyone's on the same page, maybe setting up a common location for meeting minutes, etc.
2. Coordination of funding - For the most part I imagine this will be dealt with in the PSF Packaging Working Group, but whatever PyPA-wide governance model we decide should probably at least be concerned with being aware of PyPA priorities which could be brought ot the PWG.
3. Branding-related decisions - A project is given some additional clout when it is released under the brand of a "PyPA project", and so there is a role for governance in making decisions about how this brand should be applied and what the minimum requirements are for being a PyPA project. For example, maintaining the PyPA code of conduct (and if a PyPA project wants a different code of conduct, decision about whether it is "compatible" with the PyPA CoC).
+1 on all of these. And in my view, none of them really overlap much, if at all, with the "interoperability standards" side of things, which is where I see my role lying. Paul _______________________________________________ PyPA-Committers mailing list -- pypa-committers@python.org To unsubscribe send an email to pypa-committers-leave@python.org https://mail.python.org/mm3/mailman3/lists/pypa-committers.python.org/