On Wed, 8 Aug 2018 at 14:00, Paul Ganssle email@example.com 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:
- 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).
- 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:
Coordination of communication - Intermittently making sure everyone's on the same page, maybe setting up a common location for meeting minutes, etc.
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.
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