# Straw poll: Which governance proposals do you like best? **URL:** \ **Category:** Committers\ **Tags:** governance\ **Created:** [November 15, 2018, 2:11pm UTC](https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436 "2018-11-15T14:11:46Z")\ **Posts on this page:** 1\ **Showing post:** 29
**Author:** ![njs](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/njs/32/204_2.png) [@njs](https://discuss.python.org/u/njs)\ **Post date:** [November 20, 2018, 10:09am UTC](https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436/29 "2018-11-20T10:09:17Z")
# Brett’s comments on leadership / voting / change / vision > [@brettcannon](#): > > Ironically I have heard the exact opposite reasoning against me being elected the GUIDO if PEP 8010 were to transpire: that I can lead folks but I don’t have enough technical chops to replace Guido. So does the union of people’s opinion count? 😉 You should take my intuitions with a huge grain of salt, but fundamentally our sample size for successful BDFLs is too small for anyone to know what works. But my intuition is that there’s leadership, there’s technical chops, and then there’s the kind of hybrid-sociotechnical-leadership that successful BDFLs show, and it’s kind of a third thing entirely. It’s about things like “what should I say about this problem that I don’t really understand, that will cause the experts discussing it to discover a better technical solution than they would have otherwise?” Absolute witchcraft. > [@brettcannon](#): > > There’s also more of a “us versus them” mentality when things are decided by votes (even with anonymous ballots people will know in general how people voted so it won’t really be unknown). Under Guido we seemed to be reasonably good at saying to ourselves, “well, that decision was made, so that is that”. But with voting it won’t be like that and people will end up taking sides and it will start to be obvious who is driving the language a certain way and that may lead to some bitterness because _those_ people voted _that_ way. Now it’s also quite possible it won’t work this way as much as people being just a bitter towards a single or triple of people, but I know for me I don’t expect things to necessarily run smoother if we are suddenly voting on everything after how things have gone down recently. Yeah, there are cases where voting is the right thing, but it’s just one tool, and it really doesn’t replace doing the hard, informal work of talking to each other and working things out. Here’s a giant block quote [from Karl Fogel’s excellent book on F/OSS development](https://producingoss.com/en/consensus-democracy.html#when-to-vote), because it’s all so relevant that I couldn’t figure out where to trim 😄: > In general, taking a vote should be very rare — a last resort for when all other options have failed. Don’t think of voting as a great way to resolve debates. It isn’t. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often: a lively debate can produce a new way of looking at the problem, and lead to a proposal that eventually satisfies everyone. Even when no new proposal arises, it’s still usually better to broker a compromise than to hold a vote. After a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy. From a political standpoint, the former situation is preferable: at least each person can feel he extracted a price for his unhappiness. He may be dissatisfied, but so is everyone else. > > Voting’s only function is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion. The more experienced people are with open source projects, the less eager I find them to be to settle questions by vote. Instead they will try to explore previously unconsidered solutions, or compromise more severely than they’d originally planned. Various techniques are available to prevent a premature vote. The most obvious is simply to say “I don’t think we’re ready for a vote yet,” and explain why not. Another is to ask for an informal (non-binding) show of hands. If the response clearly tends toward one side or another, this will make some people suddenly more willing to compromise, obviating the need for a formal vote. But the most effective way is simply to offer a new solution, or a new viewpoint on an old suggestion, so that people re-engage with the issues instead of merely repeating the same arguments. > > In certain rare cases, everyone may agree that all the compromise solutions are worse than any of the non-compromise ones. When that happens, voting is less objectionable, both because it is more likely to lead to a superior solution and because people will not be overly unhappy no matter how it turns out. Even then, the vote should not be rushed. The discussion leading up to a vote is what educates the electorate, so stopping that discussion early can lower the quality of the result. > [@brettcannon](#): > > That can also swing the other way of testing a new governance model _for us_ . While you can argue that PEP 8010 is unique by electing a dictator, it is what we are used to, with 8011 going along that theme somewhat. But the other PEPs are new to this group of people and we don’t know how we will take to any of them as compared to having a singular leader. I actually agree with you 100% here :-). If we end up on one of the community-based systems, then we’ll collectively have to learn how to cope with that, and it’ll take real time and effort, and we’re probably going to hate it at some points. But there’s some risk like this in any system – after all, even with a quasi-BDFL model, the actual governance depends totally on who the dictator is, and we’ve never had any dictators besides Guido! But there are lots of successful F/OSS projects where people have learned to work together effectively, and I’m pretty confident we can figure it out too. I’m less confident that we can find a New Guido. It’s a matter of weighing the risks… > [@brettcannon](#): > > Personally, I’m worried. For me, “vision” goes beyond language design. It also extends to question like “do we rework the C API for potential performance, and if so how should that look?” Or how about “in the modern era of PyPI do we cut down on the batteries in the stdlib?” I think there are still plenty of question which will come down to a vision of how things should function as a whole which extend beyond just a choice on syntax or whether we want a `None` -aware operator. I hear your worry, and this is super subjective. But to share where I’m at: even in those cases, I’m not really worried? These are complex issues, but we have a pretty solid shared vocabulary for describing our values (our traditional commitment to backcompat, the Zen, etc.), and we have lots of technical experts to work out the trade-offs of different approaches, their effect on different user communities, etc., so we can compare them to those values. The whole point of a consistent vision is that it doesn’t involve inventing new principles to answer new questions; it’s about figuring out how old principles apply to new situations. # Paul’s concern that formalizing the new-core-dev process is alienating and bureaucratic > [@njs](#): > > Our current process for promoting a core dev is pretty informal, right? Which is fine for easy cases where everyone agrees that someone’s ready, or everyone agrees that someone’s not ready. But sometimes there are borderline cases where there are some +1s, and some -1s, and there are more +1s then -1s, but no-one’s exactly sure what the threshold is. Right now, those cases are effectively resolved by Guido, either directly or indirectly (e.g. someone declares what they think the resolution is, and he doesn’t object). > [@njs](#): > > @pf_moore: if one of these ambiguous cases comes up next year, what do you think should happen? > [@pf\_moore](#): > > Well, I’d take the view that as with anything else, if we don’t have a clear consensus [about whether to promote someone], status quo wins (i.e., the default is let’s not promote someone right now, but wait a while). Sure, that means that it’s a little harder to get new core devs, but there are other aspects of the various proposals that have that problem (e.g., see my other comments in this thread), and anyway I’d personally prefer we had a high level of trust in each other, which means people getting in on a borderline decision probably _isn’t_ the right thing. I see where you’re coming from, but on reflection this actually bothers me quite a bit. Let me try to articulate why. There will always be borderline cases… as long as there is some level of consensus where the person doesn’t get promoted, and some level where they do get promoted, then it’s an unavoidable mathematical fact that there is some minimum level of support where they do get promoted, but anything less would have failed, i.e. they’re on the borderline. So you can’t eliminate borderline cases. What you can do, and I guess what our current process does, is obfuscate them. If you make a crisp rule like “2/3 supermajority”, then it’s easy to tell how close any particular vote is. But if no-one’s quite sure where the border is, then no-one’s quite sure whether any particular case is borderline or not. You can say “well, if you’re not sure, then that’s on the failure side of the line”, but that doesn’t resolve the issue, it just moves it – now it’s the cases where we’re not sure whether we’re sure that are ambiguous. Obfuscating the border like this does have some benefits; no-one _likes_ having to lay down the law and be the bad guy and bureaucracy and all that. But it also causes real problems: - There will always be borderline cases, where no-one knows what to do. This isn’t a theoretical issue. IIUC, when Victor sent [this email](https://mail.python.org/pipermail/python-committers/2018-June/005621.html), he was actually uncertain about whether we had enough consensus to promote Pablo, and was kind of bluffing and hoping no-one would call him on it, and until [Guido replied](https://mail.python.org/pipermail/python-committers/2018-June/005628.html) he wasn’t sure what the outcome would be. (@vstinner, correct me if I’m misrepresenting things here!) - And whenever you have power wielded by unstructured and unaccountable processes, then what tends to happen is that [decisions get made by whoever blusters the loudest, or by invisible and unaccountable friend networks](https://www.jofreeman.com/joreen/tyranny.htm). It also makes it extra easy for bias to slip in, and for the appearance of bias, which is nearly as bad. Imagine you were a woman who was interested in becoming a core dev. You ask what’s required, and get told “well, at some point when you’ve jumped through enough hoops – we can’t tell you how many – then you’ll get judged by a bunch of dudes according to some criteria we can’t tell you, and if you meet some arbitrary and unspecified threshold, then you’ll get in; and if not, then maybe at some future unspecified point you can try again. But don’t worry, _they all have a high level of trust in each other_.” It’s just… ick. I also want us to have a high level of trust in each other, but I think we can do that while also having clear guidelines and articulable rules. - And obviously we’re not going to solve all these problems by just writing down some rule like “2/3 supermajority”. But it’s a necessary first step. If you can’t describe the process, then you can’t discuss it or change it. There’s substantial disagreement about how we should promote core devs: Łukasz thinks [unanimity](https://www.python.org/dev/peps/pep-8012/#voting-mechanics), Carol has [suggested 50%](https://discuss.python.org/t/private-ballot-for-voting-on-promoting-a-contributor-as-a-core-developer/416/13), and I don’t feel like I know what the process actually is right now, which is a pretty disempowering feeling for me. Like I know the general outline, but all the details are based on precedent and whim, absorbed through osmosis, and I’ve only been a core dev for ~a year. I guess the people who’ve been core devs for 5+ years have a better idea, but I also bet they don’t all agree. (And how ridiculous is it that someone can be a core dev for a year and still not know this basic stuff?) But if we refuse to codify anything then this is what happens – it squashes discussion. And BTW, having a formal criterion like 2/3 supermajority is totally compatible with talking to each other, it’s really not either/or :-). # Authority of leaders to rule on non-technical matters > [@brettcannon](#): > > I actually don’t agree that list is what Guido actually did. For instance, I have never ran by Guido any time I have given someone tracker permissions. Nor do I think he has ever really stepped in to formally specify how we choose a core developer (our current approach kind of just happened). I would not assume that just because Guido didn’t say anything, that means he wasn’t paying attention :-). I bet if he disagreed then you would have heard from him! And you can’t tell me Guido didn’t have some direct intervention [here](https://mail.python.org/pipermail/python-committers/2018-September/006059.html) 🙂 > [@Mariatta](#): > > - Pronounce on PEPs ( **expected responsibility of the trio** ) > - Decide whether a particular decision requires a PEP ( **expected responsibility of the trio** ) > - [Decide whether or not an alternative implementation is really Python](https://github.com/naftaliharris/tauthon/issues/47#issuecomment-266218423) ( **I don’t actually know, I don’t have much opinion about this** ) > - Add people to the core team, remove people from the core team, change the process for promoting people ( **not expected of the trio** ) > - Make decisions about special cases, like giving someone bpo permissions without commit permissions, or giving commit permissions but only for the docs ( **not expected of the trio** ) > - Change the rules for the governance itself ( **not expected of the trio, unless there’s a PEP about it** ) Thanks @Mariatta, that’s helpful! And to be clear: “not expected” here doesn’t just mean “they can ignore it if they want to”, but rather means “if there’s a debate arises, they don’t have any special authority to resolve it”, right? And then PEP 8011 also has a kind of blank check for falling back on PEP 8001 to resolve edge cases: > It is allowed, and perhaps even expected, that as experience is gained with this model, these parameters may be tweaked in order to provide for a smoother governing process. The process for tweaking these parameters will generally be the same voting process as described in [PEP 8001](https://www.python.org/dev/peps/pep-8001). Which I’m guessing would also apply to resolving any debate where the trio doesn’t have authority? --- _[View the full topic](https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436)._