On Wed, 8 Aug 2018 at 13:26, Dustin Ingram di@python.org 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".
:-)
No problem - the main thing I was really picking up on was that there's probably multiple subject areas here, and they likely need to be at least enumerated, just to be sure people know what they are buying in to. Like you say below.
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.
That sounds reasonable to me. It would be very easy for something like this to splinter into too many areas, so we'll need to exercise caution here, but certainly I see a strong difference between "policy" and (technical) "standards" at least (both in terms of the content of the subject area, and in terms of the skills needed to be an effective BDFRN). I don't think I've personally got the patience with politics and bureaucracy to be a good fit for the "policy" side of the role (see below for hints of my views on voting processes, for example :-))
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.
Yep, that seems right.
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.
Conversely, we've not traditionally agreed standards by a vote, and I'm not sure it's something I'd be too keen on making into a formal process. It's too easy for people to take the stance "well, I didn't vote for it". At the moment, it's more a case of "you had your chance to express your opinions, so you need to accept the results". Of course, we've generally been fortunate in that most standards discussions have usually converged on a consensus (or if not consensus then at least exhausted acquiescence ;-)) and there's never been a real need for any sort of arbitration between entrenched opponents. For standards discussions at least, I'd like to see that continue, and I see my role as very much being to encourage participants to compromise and agree, and not to decide between choices[1].
I'll shut up now before this starts to sound like a political platform :-)
Paul
[1] I feel like that was very much Guido's style, and it worked really effectively. While I've no pretensions that my design instincts match Guido's, I feel like the real enabler of that approach is a good sense of community, which doesn't rely on any one individual but is something that can be encouraged in everyone.