On Aug 8, 2018, at 3:42 PM, Paul Moore <p.f.moore@gmail.com> wrote:

On Wed, 8 Aug 2018 at 18:03, Donald Stufft <donald@stufft.io> wrote:

When it comes to the interoperability specs, there are a few reason why I think we should pull them under the same process:

Thanks for the information - I'll have to think it all through before
commenting. But there's (I guess) one question that I would like to
clarify - and this isn't just for you, it's for the group as a whole.
Where do people see my role as "packaging interoperability BDFL
delegate" fitting into all of this, both in terms of how things stand
currently, and how we want things to be going forward?

tl; dr 

I was operating under an older proposal, I re-read it and suggested changes. In those changes, the BDFL-Delegate role would in essence be renamed in the new process, PyPA would vote on whether to keep you (and me for PyPI) operating in that role.


In the interests of full disclosure, my views are:

(Current/past situation)
1. Python-dev (and in particular Guido) had little real interest in
packaging, and so the BDFL delegate role was in effect the ultimate
authority on packaging questions.
2. It was far more of an enabling role than a decision making one - it
was about guiding people to consensus and limiting bikeshedding, not
about arbitrating disputes.
3. There was no precedent for Guido, or his delegate, making arbitrary
decisions, and the community would likely have just ignored any
attempts to do so - suggestions that anyone had the power to
arbitrarily declare *anything* as a new standard, have no real basis
in fact[1].
4. It was much wider than PyPA, in the sense that the interop
standards are precisely about how *non-PyPA* projects can safely
interact with PyPA ones. It also *felt* like a wider role, insofar as
"what the PyPA (pip team, warehouse team, ...) thought" always felt
like only a part of the discussions.
5. The fact that it linked into the PEP process, while formally
important, was a relatively minor admin point in practical terms[2]


So I agree with most of these, and I think that speaks to *why* packaging should have it’s own process that it personally owns.

Now, perhaps people disagree with that, but let’s assume for the sake of argument that we think that the concept of packaging in Python should have it’s own process.

The first question we would need to answer, is who owns that process? In my opinion, it makes the most sense for the PyPA to own that process, much the same way as the PEP process intermingles the concepts of Python and CPython, this would intermingle the concepts of the PyPA and “Python Packaging”. I don’t think that this is a problem though, because I think we’re all reasonable people and that we care about interoperability not just within our own tooling, but with tooling that for one reason or another, doesn’t fall under the PyPA.

Now, you could say it would be more ideologically pure to have a distinct thing that sits above the PyPA, and can represent things that simply aren’t part of the PyPA better. I think going down that road is ultimately a hunt for a spherical cow. The overlap between PyPA and “Python Packaging” is pretty large, and much like how CPython’s PEP process (owned/controlled by python-committers) functions for defining standards for other Python interpreters, the PyPA process would simply act as the place for decision making.

Ultimately, part of the reason why we ended up going with the PEP process in the first place is because it was there, and we didn’t have a better answer at the time for “what group of people “owns” Python packaging””. Given a more formal decision making process within the PyPA, I think that we *do* have a better answer for that now, and because of the other changes going on the in the Python ecosystem, it is a good time to transition to fully owning our own processes.


(Going forward)
1. I want to continue in the role - I feel I can do some good, and I
don't think I've had the chance yet to really get involved.
2. I'd prefer not to see authority granted to some form of PyPA voting
process. Or to rephrase that, I don't think (as noted above) that
there actually *is* any such authority to grant - and I'd like to
avoid the appearance (to the wider community) that we think there is.
Having said that, I have no problem with (as BDFL-delegate) stating
that if I need to decide on the colour of a bikeshed, I'll do so by
putting the question to the PyPA voting process. My only constraint
would be that I'd expect to retain the right to decide whether to
refer to the PyPA or continue looking for consensus[3].
3. I don't actually think that the fallout in python-dev over Guido's
resignation has much impact on us. It might mean that we have to
accelerate the process of switching to doing our own admin around
signing off and storing standards documents, but that's minor. I doubt
that anyone over at python-dev (who isn't already active in the
packaging community) will care much either way what we do.
4. I'm not interested in taking on the wider BDFRN role described in
Dustin's document. So either we have 2 separate roles, or I'm going to
have to relinquish the interop standards role. If that feels like I'm
making demands, I'm sorry - I don't intend it to, but I also don't
feel like I'd do a good job on the "policy" side of things.

I actually just went and re-read the proposal (I had seen an earlier draft of it, and forgot about one of the changes that Dustin said he was going to make).

In my opinion, I think we should nix the BDFRN role (once the final decision of how we govern ourselves has been made). In general I don’t think that we should be applying voting to the vast bulk of these hypothetical RFCs. I would instead of the areas of interest thing that I described above, where the PyPA members elect people to act as the “leader” for that area of interest.

Basically, here is the diff of what I would suggest (From Dustin’s proposal): https://gist.github.com/dstufft/d591cba12abf64818352238ccf05a64e/revisions#diff-6d4b6145b579633abaf87fb443a15902

The *practical* differences between the status quo:

* We call proposal RFCs instead of PEPs.
* They have a different format, and a slightly difference process (discussion on GitHub Pr, etc).
* Instead of BDFL-Delegates, we have “Area of Interest Leader” (Or a better name, I suck at naming).
* We add an answer to the question of what happens if we find ourselves without a AoEL / BDFL-Delegate (due to whatever reason).
* We add a mechanism to get rid of a AoEL / BDFL-Delegate if the members of the PyPA vote to recall them.

The *philosphical* difference between the status quo:

* Authority over Python packaging belongs to the PyPA, not to python-committers / the Python BDFL.

Assuming for a moment that we adopted my above revision, then basically the first order of business IMO would be to vote to adopt two areas of interests leaders:

* Interoperability Standards -> Paul Moore
* PyPI / Repository -> Donald Stufft

Of course, the PyPA could ultimately decide in that vote not to adopt those either or both of those AoELs, but I personally feel like they make sense? (Although I could just be biased :) ).