On Wed, 8 Aug 2018 at 18:03, Donald Stufft
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? 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] (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. Beyond that, though, I'm left in the somewhat uncomfortable position of not being sure whether I'm offering my views on the PyPA governance model, or fighting for my role as interop standards lead. So I think I'd like to wait for a little while before contributing further, to find out what the group as a whole feels should happen to the interop standards lead role in future. Paul [1] If you want an example, I'll happily use my current powers to arbitrarily declare that version numbers must be in roman numerals. I'll bet you any amount of money you like that nothing will change, except possibly the level of credibility I have ;-) [2] And we were working on moving even further in that direction, even before Guido's departure. [3] Before this discussion arose, my intention was to do my best as BDFL-delegate to *never* leave myself in a position where I had to make a substantive decision. If that happened, I'd have considered it a failure on my part in guiding the discussion and consensus process.