I've made some updates to the document, generally accepting Donald's proposed changes here (with some minor tweaks to the wording), namely:
* No BDFRN role as ultimate arbiter * Instead, nominated Interest Area Authorities for various areas of interest under the PyPA, who act as the decision-makers instead of a given proposal being put to a vote * Fallback on a vote if there is no Interest Area Authority or they are otherwise unavailable
I've also made some other small suggested miscellaneous changes elsewhere.
You can see the diff here: https://gist.github.com/di/c785bf9a04f6c5f52d7baf332204f05a/revisions
D. On Wed, Aug 8, 2018 at 4:02 PM Donald Stufft firstname.lastname@example.org wrote:
On Aug 8, 2018, at 3:42 PM, Paul Moore email@example.com wrote:
On Wed, 8 Aug 2018 at 18:03, Donald Stufft firstname.lastname@example.org 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?
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:
- 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. 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
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.
- 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. 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#d...
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 :) ).