[python-committers] An alternative governance model
ethan at stoneleaf.us
Wed Jul 18 06:31:34 EDT 2018
On 07/17/2018 07:02 PM, Barry Warsaw wrote:
> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors
> that helps the BDFL in various capacities, with additional responsibilities.
Having a singular BDFL certainly has its advantages, and from my interactions with Brett I certainly would have no
qualms about supporting him in that role.
More in-line devil's advocate comments below.
> A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community,
> and to the larger, more peripheral user base, that any particular individual has the authority to make decisions.
Regardless of size, there
> would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the
authority of said decision.
> How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can
speak authoritatively on
> decisions for the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably
authoritative than “Alice Jones, BDFL”.
If the council appointments are for life, it shouldn't take too long to figure out.
> This also comes into play for shutting down discussions early. With a committee, it’s possible that you’ll have some disagreement among the
> members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change
fits into the overall
> direction for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only to be overruled or
undermined by Bob Smith’s “That’s
> a good idea”.
I suspect that will occasionally happen -- I don't know that it's a big enough issue to make the NBDFL model the obvious
> Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the
> council to come across as a single voice, but I think it will generally be harder. A council also opens the door for
more back-channel lobbying
> of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention.
I think this is the crux of the argument: getting a group of people, even a small one, to agree on a singular vision
can be very difficult.
> I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing. While moratoriums and a more
> conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a
specific purpose, rather than
> the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have
more authority to make
> decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of
consensus or internal bickering.
Community support can be mercurial, and should not be relied upon as an underpinning of our governance model.
> Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed
> change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance
position, to actually move the
> language and its primary implementation forward? I’m not so sure.
I am sure that those questions will be difficult for a BDFL, a council, a membership majority, or whatever system we choose.
> The formation of a formal Council is still a good idea! I just think that it shouldn’t be the ultimate arbiter of decisions for Python. So what
> would the Council do?
> - It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental
> to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the
BDFL shouldn’t continuously fear
> a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for
when the BDFL is abusing their
In other words, a more complicated tyranny of the majority.
> - The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place.
> To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for
candidates, match them against
> well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
Why should the council have that power? If the core-devs are selecting the NBDFL now, I see no reason why we shouldn't
in the future as well.
> - The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested,
> and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
This doesn't sound significantly different from just a council without a BDFL. Besides which, whichever model we
choose, the fact that we chose it should be legitimizing enough.
> To summarize:
> * We retain a singular BDFL to lead Python
> * A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL.
I think an NBDFL model could work, but I find the supplemental CoA unnecessary. If we are worried about Evil Corp
subverting our BDFL, then we could go with NBDF10years (or something) instead (with possible/probable reinstatement).
Thank you, Barry, for taking the time to put your thoughts into words!
More information about the python-committers