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.

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).

✝Ok, skimmed.

On 08/08/2018 08:26 AM, Dustin Ingram wrote:
Yes, sorry Paul, not trying to stage a coup here. :) My plan was to
hand over the BDFRN reigns to you once the responsibilities no longer
include "define a governance model".

However, if you're not interested in being the arbiter of
non-standards related proposals, one thing I had considered but didn't
include in the model was:
* adding "types" or "tracks" to the proposal (such as "standards")
* breaking the BDFRN arbiter role into multiple people, one per type

That way you could have the final way in any proposal that is
"standards" related, someone else would handle "policy", etc.

Possibly. I view the standards process as being very much
community-focused, and about code interoperability, in the sense that
it's about standards that *all* tools (whether PyPA or not) must use
to interact with the packaging infrastructure. As such, consensus on
distutils-sig is key, much more so, to be honest, than PyPA consensus.
Conversely, PyPA governance questions and project standards are of
little interest to people outside of the PyPA and discussion can
reasonably be focused on PyPA members' opinions.
I think this model aligns well with that existing focus for standards.
Since an RFC is just a pull request, it would be open to anyone in the
community to comment on, including (but not limited to) the members of
distutils-sig.

Also, at least to my knowledge, we're not truly gathering consensus on
distutils-sig via a vote, we're just getting a general sense of
"nobody strongly dislikes this proposal" which would still be possible
by simply sharing a link with that mailing list whenever a new
proposal would be of interest to that group.

D.

On Wed, Aug 8, 2018 at 4:35 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 8 Aug 2018 at 10:19, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Aug 8, 2018 at 2:04 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 8 Aug 2018 at 09:54, Paul Moore <p.f.moore@gmail.com> wrote:
More seriously, I think it's extremely important that we do clarify
those boundaries.
I should add that I'm more than happy to write something up that more
clearly defines the role of the "packaging standards" process (and by
extension, my role as packaging BDFL-delegate (we really need a mode
concise term!)). It's not something that I think we've needed up to
now, but if there's going to be confusion between "what's a PyPA
issue" and "what's a packaging standards issue", I'm happy to do so.
It may take me a week or to to do so, though. (Nick, I'd want to
involve you as an initial reviewer of that document, if that's OK).

Personally, there's no real confusion in my mind over where the
boundary lies, but Dustin's document makes it pretty clear than not
everyone shares this clarity ;-)
I'm sure we can come up with some distinction, but I wonder: is having
two separate processes actually serving a useful purpose? Either way
it's basically the same people (i.e., the people reading this), doing
the same thing (writing a document, debating it, building consensus,
etc.), right, with slightly different set dressing?
Possibly. I view the standards process as being very much
community-focused, and about code interoperability, in the sense that
it's about standards that *all* tools (whether PyPA or not) must use
to interact with the packaging infrastructure. As such, consensus on
distutils-sig is key, much more so, to be honest, than PyPA consensus.
Conversely, PyPA governance questions and project standards are of
little interest to people outside of the PyPA and discussion can
reasonably be focused on PyPA members' opinions.

But if people want to say that it's the same process, then we have to
establish if it's me or the PyPA BDFRN that is the deciding authority
for that process.

To give a very specific example, I very strongly want (assuming people
aren't telling me that they think I'm doing a bad job!) to remain as
the deciding authority for standards like PEP 517 and compatibility
tags. But I've no interest in managing PyPA governance proposals. So
that's a clear distinction, at least in my mind :-) On the other hand,
having the same formal process, just with different subject areas and
responsible individuals, is fine with me - I'm not obsessed with
bureaucracy, just with results.

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/