And Now for Something Completely Different
or: Replace Dictatorship with Democracy.
Hi,
== Introduction: unjustified fears? ==
I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc.
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python?
In my experience, a consensus has been reached in less than one month on most PEPs without the help of the BDFL. There were a few controversal PEPs. The most controversial PEP is obviously the latest accepted PEP, the PEP 572 (assignment expressions). OK. But do you have other examples?
In a different thread,I gave the example of my PEP 446 "Make newly created file descriptors non-inheritable": Guido approved it, even though Charles-François Natali was against it (since it broke the backward compatibility). If I recall correctly, the issue with that PEP is that almost nobody cared about it: it was mostly Charles-François and Guido :-) Hopefully, such cases are rare.
== What is the image send to the community and contributors? ==
Last year, I mentored multiple contributors. What I learnt is that contributing to Python is much harder than what I expected.
Most core developers are core for 5 years or longer (maybe 10 years for some of them?), and we (core developers) forgot how hard it is to contribute. When your name is known in a community: it's very easy to share your ideas, other people listen to you and respect your experience. It's much faster to get a pull request merged... sometimes simply because you merged your own PR :-)
Becoming a core developer takes between 6 months and 2 years, it requires a lot of commitment, to have free time, etc. In short, it's *very hard* to recruit new core developers. It seems like many people forgot that.
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community.
== Democracy: vote on PEPs open to all core developers ==
I would like to come back to my idea of using a vote restricted to core developers: a PEP would require "50% +1" (at least 50% of votes + 1 voter) to be approved. Maybe some more sensitive PEPs would require a bigger majority, like 66%+1, for example PEPs changing the Python language. The vote would only be opened once we (core devs) consider that the PEP is ready for a vote.
Drawbacks.
The main risk is that PEPs would fail to be approved if no consensus can be found. In practice, it means that Python remains unchanged. Honestly, I don't think that this consequence is a disaster: sometimes, doing nothing *is* a wise choice :-) The PEP author is free to retry in 6 or 12 months with a new PEP, maybe written differently, maybe with better examples. For example, if everybody agreed to reject the first version of the PEP 572, I expect a more positive result on the latest flavor of the PEP. The issue is sometimes the PEP itself, not the proposed change. Guido forced me to rewrite my very long PEP 540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it was a major enhancement for my PEP :-)
OK, but sometimes everyone like the proposed change, but just not the PEP itself. What can be done? Well, the PEP can be modified. Another different PEP can be proposed. In the worst case, it's a dead end. Again, IMHO it's fine to done nothing. Moreover, I would like to insist that in last years, I don't think that such case occurred frequently. To be honest, I fail to find any example...
Advantages.
We saw drawbacks. What are advantages of a democracy where every core developer vote counts?
First, the BDFL is no longer a bottleneck. Last years, Guido became less available, some PEPs took a lot of time to be approved, I'm thinking about PEP 525 and PEP 530.
Moreover, core developers can take holiday. You are allowed to take care of friends, family, and just have a break. It's fine. There are other people who will take care of Python for you.
The decision becomes taken by "the community" (core developers in practice) rather than an individual. Negative comments should no longer target an individual but the collective decision. Being a public person is not easy, it seems like Guido resigns partially because of that pressure. I know that Brett Cannon also suffered of negativity of some haters of the Internet. I also had a depression recently caused partially by Python. Working on an open source and public project causes specific issues.
== Annex For Council Lovers ==
We already have a concept of *councils*. When I have a question on importlib, I will first ask Brett Cannon. If he is not available, I would ask Nick Coghlan and Barry Warsaw. When I have a question on C internals, I will ask Serhiy Storchaka and INADA Naoki. We even have a written list of "experts" (or "maintainers"):
https://devguide.python.org/experts/
Note: this list is filled by core developers who add themselves :-)
These experts are known references in their domain, and it's common that Guido delegates his BDFL role on PEPs. For example, INADA Naoki is the delegate of two Unicode PEPs: Nick's PEP 538 "C locale coercion" and my PEP 540 "UTF-8 Mode". If Naoki would reject my PEP, I would be fine with that: I trust and respect his judgment.
== Summary ==
It is already very hard to become a core developer: a contributor only becomes a core dev once other core developers trust them.
I propose to trust core developers judgment and let them all decide if a PEP should be accepted (or rejected). Common PEPs would require "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python language) would require 66%+1 majority (2/3).
Known experts will help to lead the discussion and to refine the PEP. Core developers will decide when they consider that a PEP is mature enough for a vote.
If a PEP is rejected by a vote, the author is free to make a new attempt 6 to 12 months later with a new PEP, maybe with a new stronger rationale and better examples. Or a competitor PEP can be proposed by a different author. I expect that the common case will be that the author will not attempt a new similar PEP since the vote result will be explicit enough.
Rejecting a PEP doesn't mean a failure for Python: sometimes, doing nothing is the wisest choice :-)
Victor
On 07/19/2018 04:47 PM, Victor Stinner wrote:
or: Replace Dictatorship with Democracy.
Hi,
== Introduction: unjustified fears? ==
I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc.
I imagine that will be made clear in that proposed PEP.
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions will be approving/rejecting the PEPs, and internal consistency becomes impossible.
Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python?
Examples inside Python are good enough:
PEP 435 (Enum) [accepted] lots of minor decisions from BDFL about this or that choice, and still there were about 1,000 emails over several threads
PEP 461 (%-formatting for bytes and byte arrays) [accepted] IIRC there was lots of push-back on adding this to bytes and byte arrays
PEP 463 (exception-catching expressions) [rejected] lots of discussion here, not sure if it would have been accepted by majority vote
PEP 572 (assignment expressions) [accepted] 'nough said
In my experience, a consensus has been reached in less than one month on most PEPs without the help of the BDFL. There were a few controversal PEPs. The most controversial PEP is obviously the latest accepted PEP, the PEP 572 (assignment expressions). OK. But do you have other examples?
See above.
I propose to trust core developers judgment and let them all decide if a PEP should be accepted (or rejected). Common PEPs would require "50%+1" majority (1/2), sensitive PEPs (ex: modify the Python language) would require 66%+1 majority (2/3).
Known experts will help to lead the discussion and to refine the PEP. Core developers will decide when they consider that a PEP is mature enough for a vote.
My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters.
My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.
My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium.
-- ~Ethan~
Le 20/07/2018 à 02:51, Ethan Furman a écrit :
My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters.
My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.
My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium.
This is true. But it's a problem for the BDFL even more. Our ex-BDFL resigned because of pressure and exhaustion. Why would another BDFL fare better?
Victor pointed out something I didn't know: that several prominent core devs (him, Brett Cannon) recently suffered from breakdown/burnout/depression.
I find the PEP-delegate to be a powerful concept. Why wouldn't *every* PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can discuss how to nominate PEP-delegates (Nick had an interesting proposal).
Regards
Antoine.
Le 20/07/2018 à 01:47, Victor Stinner a écrit :
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
That's a very good point, I think. Creating intimidating structures may not help attract new contributors. A BDFL is intimidating. Depending on its name and powers, a council or collegial body can be intimidating too (I'd recommend against naming it "Council of Elders", which IMHO sends the wrong message).
Regards
Antoine.
Hi Ethan,
Thanks for your feedback!
2018-07-20 2:51 GMT+02:00 Ethan Furman <ethan@stoneleaf.us>:
I see that many people are eager to replace the old governance based on a single BDFL with a new governance with a new BD(FL) and/or a council. My problem is that I don't see any clear definition of the roles of these BD(FL) and/or council: what they are expected to do, what they cannot do, etc.
I imagine that will be made clear in that proposed PEP.
In that case, I would prefer that people abstain from voting on this mailing list (I'm talking about "+1" emails), before a formal and well defined PEP is written ;-)
This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions will be approving/rejecting the PEPs, and internal consistency becomes impossible.
Can someone please explain me the rationale behind these fears? Do you have examples? Maybe examples outside Python?
Examples inside Python are good enough:
- PEP 435 (Enum) [accepted] lots of minor decisions from BDFL about this or that choice,
Hum, first I would like to have better statistics on the number of active core developers. On Stéphane Wirtel statistics on pull requests, the number of active core developers was closer to 34...
Would you mind to elaborate? How would enum be inconsistent without the BDFL work?
and still there were about 1,000 emails over several threads
Honestly, I don't recall the discussion on the enum module. What do you mean by this large number of emails?
People are free to send emails, but at the end, a vote would occur on a proper PEP, not on emails.
Let me try to guess what you mean. Do you mean that a 50%+1 majority would be impossible to reach because each core developer had a different taste on how enum should look like?
What I saw in PHP RFC is that sometimes there are multiple votes on a single RFC, to choose between alternatives (translation for Python: replace RFC with PEP :-)). A recent example:
https://wiki.php.net/rfc/array_key_first_last
The RFC proposed to add array_key_first/last()" and array_value_first/last(). The array_value variant was controversial and so has been voted separately. There was a corner value for values: a value can really be null, whereas the RFC proposes to also return null to signal an error. This case doesn't occur with keys, since using null as a key is automatically replaced with an empty string: it's possible to distinguish null as an error. They decided to approve array_key_first()/last() but reject array_value_first()/last(), which IMHO is a wise choice :-)
For enum, if you are talking about the two proposed alternatives "Not having to specify values for enums" and "Using special names or forms to auto-assign enum values", I guess that separated votes could be used: one vote for the main idea "having an Enum type", and a vote on the variants. The PEP author (and maybe an expert would him them to drive the PEP) would decide which votes are worth it.
- PEP 461 (%-formatting for bytes and byte arrays) [accepted] IIRC there was lots of push-back on adding this to bytes and byte arrays
Sorry, I don't understand what is wrong with this PEP. If I recall correctly, all core developers were in favor of adding back this feature to Python 3, no?
I recall that I started to write a PEP 460, but Antoine wanted to "modify" it. In fact, he basically rewrote it from scratch, so I asked him to remove my name from it :-)
Then you wrote a competitor PEP. At the end, your PEP won.
I don't see how bytes % args is a good example of the need of a BDFL to keep Python consistent. Would you mind to elaborate? Do you have that having two PEPs in a competition goes against the principle of voting?
- PEP 463 (exception-catching expressions) [rejected] lots of discussion here, not sure if it would have been accepted by majority vote
Hum, I don't recall well this discussion. If I recall correctly, the consensus quickly agreed to reject the PEP. Most people already disliked the PEP on python-ideas, no... I'm not sure of that. At least, I disliked the PEP since its start :-)
What do you mean by "not sure if it would have been accepted by majority vote"??
- PEP 572 (assignment expressions) [accepted] 'nough said
Joker! I will not comment that one. I don't have enough perspective on it yet.
My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters.
I agree that an author can be confused when two different core developers ask to make two opposite changes. This is where an expert can help the author to drive the discussion and help the author to make choices.
To formalize a little bit more, I would identify 3 groups: PEP authors (usually an individual), group who help authors to write the PEP and drive the discussion, group who vote (all core devs) at the end.
I guess that the group helping the authors is supposed to like the proposed change, but I'm not sure that it's mandatory. It's like an advocate who is supposed to help their client even if their client killed someone ;-)
If you want a recent example, on the PEP 572, Guido and Tim were strong supporters of the PEP and they helped a lot Chris to refine his PEP. At the end, they even decide to become co-authors.
My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.
Sorry, what does BDFOP stand for?
I saw people writing "mandatory votes" in a different thread. I don't see why anyone would be forced to vote on PEPs :-) (I'm not talking here about this very specific case of deciding a new governance for Python.)
I prefer to abstain me from commenting PEPs in some areas like typing or distutils, since they are out of my interest area and I don't feel that I would add anything useful. I love that other experts who have a stronger background in these topics than me are able to provide good feedback to drive the discussion.
Hum. Let me try to explain my point differently. Currently, some people don't read PEPs just because at the end, only the single BDFL vote counts. What's the point of spending hours (if not days) on reading a long PEP and the long discussion on mailing lists, if your count doesn't count? Now imagine that all votes count. I expect that people will spend more time on reading carefully each PEP and follow more closely discussions since they will be de facto more involved in the decision process.
By the way, PHP votes on RFC votes is public. One advantage is that it forces voters to vote "seriously", since later someone can ask them why they voted like that :-)
Are you sure that all core developers would have have the knee reaction of rejecting the PEP 572 if their vote really counts? On python-committers, I opened a *poll* on the PEP 572. The meaning is very different from a real vote where your voice really counts.
Another way to explain it. It's really hard to force volunteers to work for free... In a regular job, IMHO a good way to involve workers is to give them more responsibilities.
I already saw this issue on reviews. I read someone saying that they don't review pull requests since only core developers can merge changes, so what's the point of commenting? If you take the point of view of the core developer: merging a pull request means that it becomes your pet for life, you will have to clean up its shit for its whole life... So core developers feel more responsible when commenting pull requests.
And now we ask regular contributor to do more reviews? I'm not sure that it works. If you want someone to do more review, IMHO you should give them the right to merge a PR. Suddenly, people are more careful on reviews :-)
My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium.
See my previous point: you are not asked to vote on all PEPs. You are free to abstain from voting.
"Time is at a premium." is very true in open source software where almost everybody is volunteer. This is why I consider that a BDFL or a council is not sustainable regarding the popularity of Python and the pressure on accepting changes.
A BDFL was definitively a good choice 20 years ago, when Python was new and little used. Time changed. Python became #1 programming language in many area. They are million of users. We all feel the pressure of users who expect stability (this is partially why Python 2.7 is still very popular nowadays). IMHO a single BDFL can no longer handle the high number of PEPs nor the high traffic of python-ideas and python-dev lists. Moreover, since it has been written that no core developer is legitimate to replace BDFL, I expect even stronger criticism on the Internet against "unpopular" accepted changes...
These problems go away when you replace a single BDFL with a collective decision. Dozens of core developers scale and accumulate skills.
Victor
On 20 July 2018 at 12:57, Victor Stinner <vstinner@redhat.com> wrote:
Hum. Let me try to explain my point differently. Currently, some people don't read PEPs just because at the end, only the single BDFL vote counts. What's the point of spending hours (if not days) on reading a long PEP and the long discussion on mailing lists, if your count doesn't count?
My suspicion is that *most* people who don't read PEPs don't do so because they don't have the time, not because they don't believe that their opinion will matter. In actual fact, the evidence from many threads is that people are more than happy to express their opinion even though they haven't read the PEP. So I doubt that giving people more power to affect the result will make little practical difference.
Now imagine that all votes count. I expect that people will spend more time on reading carefully each PEP and follow more closely discussions since they will be de facto more involved in the decision process.
In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote.
I suspect that the reality will be somewhere between these two extremes.
Paul
Excerpts from Antoine Pitrou's message of 2018-07-20 09:49:01 +0200:
Le 20/07/2018 à 02:51, Ethan Furman a écrit :
My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters.
My second issue is qualifications: there are plenty of PEPs that I either have no interest in or whose field I have no experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.
My third issue is, quite simply, time. Working on patches takes time; reviewing PRs takes time; and being a good voting citizen takes lots and lots of time -- and we're all volunteers. Time is at a premium.
This is true. But it's a problem for the BDFL even more. Our ex-BDFL resigned because of pressure and exhaustion. Why would another BDFL fare better?
Victor pointed out something I didn't know: that several prominent core devs (him, Brett Cannon) recently suffered from breakdown/burnout/depression.
I find the PEP-delegate to be a powerful concept. Why wouldn't *every* PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can discuss how to nominate PEP-delegates (Nick had an interesting proposal).
+1
Doug
Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
On 20 July 2018 at 12:57, Victor Stinner <vstinner@redhat.com> wrote:
Hum. Let me try to explain my point differently. Currently, some people don't read PEPs just because at the end, only the single BDFL vote counts. What's the point of spending hours (if not days) on reading a long PEP and the long discussion on mailing lists, if your count doesn't count?
My suspicion is that *most* people who don't read PEPs don't do so because they don't have the time, not because they don't believe that their opinion will matter. In actual fact, the evidence from many threads is that people are more than happy to express their opinion even though they haven't read the PEP. So I doubt that giving people more power to affect the result will make little practical difference.
Now imagine that all votes count. I expect that people will spend more time on reading carefully each PEP and follow more closely discussions since they will be de facto more involved in the decision process.
In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote.
I suspect that the reality will be somewhere between these two extremes.
Paul
In other communities that use this form of consensus approval for design changes I have seen folks who do not have time or interest to dig deeply into a proposed change learn to trust others who have the time, interest, and expertise. The team comes out stronger as a result of that built-up trust.
Doug
On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
[...]
In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote.
[...]
In other communities that use this form of consensus approval for design changes I have seen folks who do not have time or interest to dig deeply into a proposed change learn to trust others who have the time, interest, and expertise. The team comes out stronger as a result of that built-up trust.
A few questions...
You say folks "learn to trust others", but what does that mean in practice? The only interpretation I can think of is:
People vote for a feature, because Fred says he's in favour
of it and they trust him, or like him personally, or because
he's more charismatic and persuasive than those against it.What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct?
How large are these communities you are referring to?
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
Certainly the Python community as a whole is *significantly* bigger than a village. What about the core developers? Now? In the future?
One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent.
When it comes to *representative democracy* I believe that the Australian model of mandatory voting (resulting in 90% turnouts or higher) has many advantages over other systems. But for a technical community like this, I don't know that mandatory voting is desirable.
(Perhaps if we have an Abstain option as well as Yes or No.)
So how many non-Abstain votes are needed? Victor mentioned "50% + 1" votes, but does that assume 100% turnout? What if only a handful of people vote on some exceedingly obscure, technical question of no interest to the majority?
Personally, I'm not sure I'd even want to vote on every PEP that comes up. When I was first nominated to the PSF, I took the voting rights as both a privilege and a duty and took them very seriously indeed. But as time went on, I got somewhat disillusioned and burned out (for reasons we need not go into). And that is only voting once or twice a year.
If I had to vote on a dozen or two dozen PEPs a year, most of which I have little or no interest in, the annoyance factor would be correspondingly greater. But if I don't vote, could that doom PEPs to fail because they don't get a quorum?
Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret.
-- Steve
On Fri, Jul 20, 2018 at 09:59:39AM +0200, Antoine Pitrou wrote:
Le 20/07/2018 à 01:47, Victor Stinner a écrit :
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
That's a very good point, I think. Creating intimidating structures may not help attract new contributors. A BDFL is intimidating. Depending on its name and powers, a council or collegial body can be intimidating too (I'd recommend against naming it "Council of Elders", which IMHO sends the wrong message).
Perhaps we could call it the Pythonic Inquisition, whose three weapons are experience, intelligence, the PEP process, and a fanatical dedication to backwards compatibility, and absolutely no braces.
*wink*
Please be explicit: what message do you think it sends which is the wrong message?
I think that the messages sent include:
there is someone in charge;
this is a meritocracy;
you too could get into the council, someday;
but you aren't in it yet;
trust and responsibility comes in degrees;
and must be earned, not just granted to random people on the Internet because they ask for core developer rights;
the evolution of the language is driven by reasoned argument, not popularity contests.
We've had a BDFL for a quarter of a century, and Python has done pretty well, possibly by far the most popular programming language not driven by a corporate owner or patron (and more popular than many languages which do have corporate owners). Of course it is impossible to prove a negative, we cannot dismiss the possibility that Guido-as-BDFL has been "sending the wrong message" for two decades, scaring off contributors and acting as a drag on Python's success. But I doubt it, and I doubt that a new BDFL or Council or Triumvirate would do so either.
-- Steve
Summary: appointing a BDFL or small council *does not* force them to do all the work themselves.
On 20Jul2018 0457, Victor Stinner wrote:
mailing list (I'm talking about "+1" emails), before a formal and well defined PEP is written ;-)
Until your new process arrives, "+1" emails are not votes and have never been considered as such. They've always been an easy and impersonal way to provide the BDFL[-delegate] with the opinions of the experts within the team who have taken the time to review a proposal.
Judging the general feeling of an email list is impossible without such emails. Counting these without taking into account the person providing the vote is a terrible idea (for example, if the topic is itertools, my +1 in no way comes close to cancelling out Raymond's -1, and nor should it).
People are free to send emails, but at the end, a vote would occur on a proper PEP, not on emails.
Substitute "vote" for "decision" (which may be decided by voting, but does not presuppose that voting is the only option) and I'm +1 on this. The final decision should always be made against the PEP, not the discussion.
[Ethan] My first issue with this model is, as discussed above, a lack of a consistent vision. A BDFL is not just there to say, "this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely not something easily done by 100+ voters.
I agree that an author can be confused when two different core developers ask to make two opposite changes. This is where an expert can help the author to drive the discussion and help the author to make choices.
To formalize a little bit more, I would identify 3 groups: PEP authors (usually an individual), group who help authors to write the PEP and drive the discussion, group who vote (all core devs) at the end.
Despite apparently being completely opposed to the other proposals, this part matches them nearly identically.
Everyone seems to be in support of a model where:
- anyone can propose a change (PEP author)
- trusted people should help sponsor/champion it (core committer bringing it to python-dev)
- trusted person/people should make a final determination
The only argument I see is entirely around how to choose that last group. The options:
- choose one person who always has to make that determination
- choose one person who chooses that group on a proposal-by-proposal basis
- choose a small group who always has to make that determination
- choose a small group who chooses that group on a proposal-by-proposal basis
- don't choose and force everyone to make that determination
Your proposal is the last one. My preference is the second or fourth. Some people seem to assume that unless we slow down now we will automatically end up with the first or third, but I don't see any basis for that assumption.
A BDFL or Council are free to delegate as much or as little as they want, and could conceivably reduce their workload to "once a week I will review emails starting with '[PEP xxx] Request for delegate' and provide a response".
I saw people writing "mandatory votes" in a different thread. I don't see why anyone would be forced to vote on PEPs :-) (I'm not talking here about this very specific case of deciding a new governance for Python.)
I prefer to abstain me from commenting PEPs in some areas like typing or distutils, since they are out of my interest area and I don't feel that I would add anything useful. I love that other experts who have a stronger background in these topics than me are able to provide good feedback to drive the discussion.
"Abstain" is counted as a vote, just not in any direction. The point about mandatory voting is whether we need to wait for you to respond before considering a decision to have been reached. If we make that decision numerical, then sooner or later we will need to make exceptions. If we have appointed 1-to-n people to determine when a decision has been reached, the flexibility is built in to the process.
Hum. Let me try to explain my point differently. Currently, some people don't read PEPs just because at the end, only the single BDFL vote counts. What's the point of spending hours (if not days) on reading a long PEP and the long discussion on mailing lists, if your count doesn't count? Now imagine that all votes count. I expect that people will spend more time on reading carefully each PEP and follow more closely discussions since they will be de facto more involved in the decision process.
If/when we choose a BDFL, it will need to be someone who is known for listening to all contributions and not excluding people for unfair or invalid reasons. It will also give them the power to declare how they want to hear contributions - they do not need to commit to reading and responding to every email! If you feel strongly against a proposal, you know who to go to in order to make that known.
By contrast, if everyone gets an equal vote on each proposal, and I want to prevent your PEP from being accepted, I have my choice of up to 50% of voters to convince to vote against you! That leads to a dynamic that I'm *very* nervous about. I would much rather have a trusted delegate tell me "thanks for your feedback but I trust Victor on this issue more than you" and have that be the end of it. There is no good that comes out of me spending time on Twitter/emails/etc. advocating that people vote against your proposal.
I already saw this issue on reviews. I read someone saying that they don't review pull requests since only core developers can merge changes, so what's the point of commenting? If you take the point of view of the core developer: merging a pull request means that it becomes your pet for life, you will have to clean up its shit for its whole life... So core developers feel more responsible when commenting pull requests.
And now we ask regular contributor to do more reviews? I'm not sure that it works. If you want someone to do more review, IMHO you should give them the right to merge a PR. Suddenly, people are more careful on reviews :-)
Massive change of subject here, but I agree. Core developers *are* taking responsibility for the code they merge, and being willing to take on that responsibility is one of the main reasons for getting the role. "Making contributions" is not the qualification - "making good decisions about contributions" is.
A BDFL was definitively a good choice 20 years ago, when Python was new and little used. Time changed. Python became #1 programming language in many area. They are million of users. We all feel the pressure of users who expect stability (this is partially why Python 2.7 is still very popular nowadays). IMHO a single BDFL can no longer handle the high number of PEPs nor the high traffic of python-ideas and python-dev lists. Moreover, since it has been written that no core developer is legitimate to replace BDFL, I expect even stronger criticism on the Internet against "unpopular" accepted changes...
These problems go away when you replace a single BDFL with a collective decision. Dozens of core developers scale and accumulate skills.
Perhaps, but they also go away when your single BDFL sets very clear limits on their availability and process, and when the process sets very clear expectations on their behaviour. Guido's problem is perhaps that he cared too much about every individual contribution and giving everyone an opportunity to make the case for shaping the language :) If a new BDFL declared "I do not read or respond on python-ideas, or proposals on python-dev that are not championed by a core developer" then that immediately reduces their workload without making it harder for people to contribute.
Perhaps it will reduce their "celebrity" status, and maybe they won't be stalked at conferences as much as Guido suffers from (hopefully "suffered from"), but I doubt that is a concern for anyone that would be under consideration.
Excerpts from Steven D'Aprano's message of 2018-07-21 02:32:02 +1000:
On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
[...]
In contrast, I would imagine that people would continue to discuss PEPs in exactly the same way that they currently do, so the result would be that the votes are based more on partially-informed opinion and "gut feeling". Certainly some people will work harder to provide an informed vote, but I doubt that will be true in the majority of cases. Worst case, people will feel a responsibility to vote, but won't have any more time than they do right now so they'll vote with limited information simply because "it's expected of them" to vote.
[...]
In other communities that use this form of consensus approval for design changes I have seen folks who do not have time or interest to dig deeply into a proposed change learn to trust others who have the time, interest, and expertise. The team comes out stronger as a result of that built-up trust.
A few questions...
You say folks "learn to trust others", but what does that mean in practice? The only interpretation I can think of is:
People vote for a feature, because Fred says he's in favour of it and they trust him, or like him personally, or because he's more charismatic and persuasive than those against it.What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct?
The same sort of thing that happens with PEPs. Either the proposal itself is changed to support more compromise, or it is abandoned and the status quo prevails.
How large are these communities you are referring to?
OpenStack had 2000 contributors during 2017. Of those, I would estimate that on the order of a few hundred are considered core reviewers in some way and would have a formal vote in our specification process, although the group reviewing any given specification would be somewhat closer to the size of the python core developer team size.
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
It is certainly harder to implement as the size of the group grows. I don't think this group has hit the point where it is impossible to sustain, though.
Certainly the Python community as a whole is *significantly* bigger than a village. What about the core developers? Now? In the future?
I'm not sure the entire Python community is really the relevant size to consider. Another important aspect of open source governance to keep in mind is that decisions need to be made by the folks doing the work. That's one reason the existing PEP delegate process works so well today -- the person making that final decision is invested in not just the decision but the overall area where the work is happening. We already trust them to both know what they are doing technically and guide the decision making process to consensus.
I find it interesting that the arguments in favor of a single BDFL tend to assume that the person selected will be responsible and informed enough to make good decisions, and the argument against a more democratic approach seems to be that the community would not be. Where in that latter assumption is the leadership of the person we would be giving the BDFL title to? Why are they unable to communicate, inform, and lead a democratically organized community to achieve goals for the common good? And if they can't, why are they qualified to be a dictator?
One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent.
Yes, this is a good point. I'm not sure a 1-size-fits-all approach necessarily works, but some way of deciding how to know when consensus is reached would be an important aspect of choosing a democratic approach.
Personally, I'm not sure I'd even want to vote on every PEP that comes up. When I was first nominated to the PSF, I took the voting rights as both a privilege and a duty and took them very seriously indeed. But as time went on, I got somewhat disillusioned and burned out (for reasons we need not go into). And that is only voting once or twice a year.
If I had to vote on a dozen or two dozen PEPs a year, most of which I have little or no interest in, the annoyance factor would be correspondingly greater. But if I don't vote, could that doom PEPs to fail because they don't get a quorum?
One approach some of our teams take is to have a subset of the core reviewers serve as reviewers for specifications. This reduces the number of people needed for quorum, explicitly asks those people to commit to doing the reviews, and still supports a democratic decision making process. Combining that approach with the PEP delegation system already in use, we could designate a team for making decisions on individual PEPs. Core developers could volunteer or be drafted, and we could include knowledgeable and interested contributors who are not core, in some cases (PyPA comes to mind).
Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret.
I don't know anyone currently on the core team who would engage in that sort of behavior, or who would put up with it if discovered in any current or future members. Within the OpenStack community we have *much* higher pressure from companies to add features supporting their products (supporting hardware, use cases, odd-ball customer configurations, etc.) than I have ever seen in any discussion related to Python itself. An open, democratic, approach *exposes* these sorts of issues, and lets us deal with them directly.
Doug
On Jul 20, 2018, at 00:49, Antoine Pitrou <antoine@python.org> wrote:
I find the PEP-delegate to be a powerful concept. Why wouldn't *every* PEP have a PEP-delegate? This way we don't need a BDFL anymore. We can discuss how to nominate PEP-delegates (Nick had an interesting proposal).
Because IMHO that would lead to a language designed by committee, with a less consistent vision.
Cheers, -Barry
On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner@redhat.com> wrote:
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
I think the core difference behind all of the proposals, when you get down to brass tacks, will be the vision for where the langauge goes. There are independently good ideas that maybe should not be accepted, because they compromise the vision for the worse, or ideas that seem poor on the tin but that once they get added they mesh well with the overall language.
The further you scale up the number of people directly deciding the direction of the language, the more likely you will find inconsistency. No two people have the same design sense, and so if you ask two people you're likely to get at least two answers.
Of course with many things, there are grey areas. If you have some sort of council of N developers, with a small enough N you can arrive at a place where the design sense for all of N are closely enough aligned that the inconsistency produced by them are minor enough as to not be noticeable. However, the larger you make that group, the more likely you are to introduce larger and larger inconsitencies.
Now, that doesn't mean that focusing on consistency to the end of all other things is the right choice. The laws of any democratic country tend to be extremely inconsistent, due to that very reason, but most people would not argue that we should revert democracy back to dictatorships in those countries.
Democracy brings with it more power to the "masses" and helps protect against a sole leader drastically going against the will of "the people" over an extended period of time.
So realistically, the choice comes down to whether we value consistency more (in which case, we'd want to favor solutions that have a small N) or more directly empowering people with a democracy.
Of course, you could try to do something that combines the two of them. You could elect a BDFL, but have PEPs go through a vote process first where they need to get a simple majority, and at which point the BDFL could approve or veto, and if they veto, then the voting body gets an additional chance to vote and if they're able to get a larger majority (2/3?) then they can override the BDFL's veto. That provides some protections from both a "design by committee" effect (since the BDFL can veto) but also provides very popular proposals a chance to pass even if the BDFL is against them.
The big loss of that compromise is that you again, give up some of the consistency, since a large enough group of developers can still introduce an inconsistent vision and you remove the ability for the BDFL to accept unpopular but long term necessary PEPs (since they'd have to get a simple majority first).
On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner@redhat.com> wrote:
or: Replace Dictatorship with Democracy. [SNIP]
== What is the image send to the community and contributors? ==
Last year, I mentored multiple contributors. What I learnt is that contributing to Python is much harder than what I expected.
Most core developers are core for 5 years or longer (maybe 10 years for some of them?), and we (core developers) forgot how hard it is to contribute. When your name is known in a community: it's very easy to share your ideas, other people listen to you and respect your experience. It's much faster to get a pull request merged... sometimes simply because you merged your own PR :-)
Becoming a core developer takes between 6 months and 2 years, it requires a lot of commitment, to have free time, etc. In short, it's *very hard* to recruit new core developers. It seems like many people forgot that.
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community.
This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away like candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history.
Now we're being asked to also trust someone's design acumen as they will be voting on PEPs. Up until this point I didn't have to worry about whether every core dev would take the language in a direction I disagreed with because they simply didn't have the authority to; it rested with Guido. This proposed change, though, means I now have to judge all core developers not just on whether I can trust them to code appropriately but whether I think they would vote on PEPs that I agree with. That would mean I wouldn't have voted to give Pablo commit privileges because I simply do not know his contributions well enough to know if he would make decisions in a way I'm personally in favour of.
[SNIP]
Advantages.
[SNIP]
The decision becomes taken by "the community" (core developers in practice) rather than an individual. Negative comments should no longer target an individual but the collective decision. Being a public person is not easy, it seems like Guido resigns partially because of that pressure. I know that Brett Cannon also suffered of negativity of some haters of the Internet. I also had a depression recently caused partially by Python. Working on an open source and public project causes specific issues.
Steve pointed out in his reply about how this might increase load as people will have to start trying to get people on side to vote the way they want. In US politics this is done by someone called a *whip* who "whips up" votes for a bill. With 91 (or more if people start to come back to use their commit rights who have not added their GitHub usernames) of us getting grandfathered into this, people will be somewhat political in getting votes for or against PEPs they care about since only people post-Guido would be made core devs knowing they now have a vote on PEPs and thus take that into consideration when adding new members to the team.
2018-07-20 18:32 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct?
In my proposal, if no consensus can be found, the vote fails to reach the majority, the PEP is rejected.
Usually, people disagree on on specific aspect of a PEP, not on the overall idea. This is where I propose to separate the decision in two votes: one vote for the "overall PEP" and one vote to decide between two variants (paint it blue or green?).
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
Hum, I'm not sure if it's revelant here, but in France, 44 855 000 people vote for the president every 5 years.
If you want numbers, it seems like PHP has around 32 voters on RFC. I also expect a number around 30 for Python. I'm not talking about the total number of core developers (who can vote), but the number of core developers that I expect to vote on a single PEP. I expect that many cores will abstain from voting because they consider that it's not their interest area, they didn't have time to follow the discussion or they are "away from keyboard".
One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent.
My worst example for a vote would be the PEP 446 example that I used previously. In short, they were 3 people who cared: Charles-François Natali, Guido van Rossum and me (the author).
First, I would suggest that the authors are not allowed to vote on their own PEP. For the PEP 446, it means that there were only 2 voters.
I propose to require at least 3 voters on a PEP. For the 50%+1 majority case, it means 2 "+1" votes are enough to approve a PEP on a total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I propose to require at least 5 voters. If there are not enough voters, the vote is canceled and a new vote can be attempted later.
I don't think that we will reach this minimum often. If it occurs, maybe we can extend the vote window and ask people to vote.
When it comes to *representative democracy* I believe that the Australian model of mandatory voting (resulting in 90% turnouts or higher) has many advantages over other systems. But for a technical community like this, I don't know that mandatory voting is desirable.
Wait. I'm against mandatory voting.
First, it's common that people are away from their computer for good reasons like holidays.
Second, I would strongly suggest core developers to abstain to vote if they didn't read the PEP (at least) or if they consider that they don't know enough to be able to have an opinion on a PEP.
(Perhaps if we have an Abstain option as well as Yes or No.)
I propose to not account "vote: 0" and missing voters to account the majority.
Ballot example:
- Like (+1): 6
- Dislike (-1): 5
- Abstain: 1
If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7 "like" votes are needed for the majority.
If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6 "like" votes are needed for the majority.
IMHO 6 to win the vote makes more sense than 7. It becomes even more obvious if you account all core developers who didn't vote, it would look more like:
- Like (+1): 6
- Dislike (-1): 5
- Abstain: 60
:-)
Personally, I'm not sure I'd even want to vote on every PEP that comes up. (...)
Me neither :-) As I wrote, I'm already ignoring some topics like typing and packaging.
Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret.
I propose to make the vote public. I expect that some people who are not sure about their vote will check who already voted (and what were their vote) to help them to make a choice.
After talking with friends, I realized that I forgot to explain something: my proposal doesn't change anything on the long discussion which occurs *before* the vote. IMHO most tractions occurs during these discussions, not during the vote. (I'm not sure of the word "traction": I mean the pressure to pull most people on your side.)
By the way, I propose that the vote window will be "short": just 1 week.
Maybe we should announce the date of the vote 1 week before, to make sure that people who care about the PEP will be available to vote.
Let me explain why I prefer a short window with a counter example. If a vote remains open for 1 month, the discussion will likely continue during the vote, and people who voted early may want to change their vote. I'm not sure that it's a good thing that people are tempted to change their vote.
Victor
On Fri, Jul 20, 2018, 17:03 Victor Stinner, <vstinner@redhat.com> wrote:
2018-07-20 18:32 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
What happens when two trusted experts disagree and the voters don't have the expertise to tell which one is correct?
In my proposal, if no consensus can be found, the vote fails to reach the majority, the PEP is rejected.
Usually, people disagree on on specific aspect of a PEP, not on the overall idea. This is where I propose to separate the decision in two votes: one vote for the "overall PEP" and one vote to decide between two variants (paint it blue or green?).
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
Hum, I'm not sure if it's revelant here, but in France, 44 855 000 people vote for the president every 5 years.
But that's for representation, not policy. California is actually a direct democracy through its proposition system.
If you want numbers, it seems like PHP has around 32 voters on RFC. I also expect a number around 30 for Python. I'm not talking about the total number of core developers (who can vote), but the number of core developers that I expect to vote on a single PEP. I expect that many cores will abstain from voting because they consider that it's not their interest area, they didn't have time to follow the discussion or they are "away from keyboard".
One factor that I don't think Victor has covered is that of what percentage of core devs would have to vote for the result to be accepted -- a quorum, or equivalent.
My worst example for a vote would be the PEP 446 example that I used previously. In short, they were 3 people who cared: Charles-François Natali, Guido van Rossum and me (the author).
First, I would suggest that the authors are not allowed to vote on their own PEP. For the PEP 446, it means that there were only 2 voters.
I propose to require at least 3 voters on a PEP. For the 50%+1 majority case, it means 2 "+1" votes are enough to approve a PEP on a total of 3 voters. On sensitive PEPs (the ones with 66%+1 majority), I propose to require at least 5 voters. If there are not enough voters, the vote is canceled and a new vote can be attempted later.
Who decides what's a sensitive PEP?
-Brett
I don't think that we will reach this minimum often. If it occurs, maybe we can extend the vote window and ask people to vote.
When it comes to *representative democracy* I believe that the Australian model of mandatory voting (resulting in 90% turnouts or higher) has many advantages over other systems. But for a technical community like this, I don't know that mandatory voting is desirable.
Wait. I'm against mandatory voting.
First, it's common that people are away from their computer for good reasons like holidays.
Second, I would strongly suggest core developers to abstain to vote if they didn't read the PEP (at least) or if they consider that they don't know enough to be able to have an opinion on a PEP.
(Perhaps if we have an Abstain option as well as Yes or No.)
I propose to not account "vote: 0" and missing voters to account the majority.
Ballot example:
- Like (+1): 6
- Dislike (-1): 5
- Abstain: 1
If you account Abstain, 50%+1 majority means: (6+5+1)//2+1, at least 7 "like" votes are needed for the majority.
If you ignore Abstain, 50%+1 majority means: (6+5)//2+1, at least 6 "like" votes are needed for the majority.
IMHO 6 to win the vote makes more sense than 7. It becomes even more obvious if you account all core developers who didn't vote, it would look more like:
- Like (+1): 6
- Dislike (-1): 5
- Abstain: 60
:-)
Personally, I'm not sure I'd even want to vote on every PEP that comes up. (...)
Me neither :-) As I wrote, I'm already ignoring some topics like typing and packaging.
Another issue we should consider: organised vote swapping. If votes are public, as Victor suggests, that would allow people to do deals: "I'll support your PEP for GOTO, if you support my PEP to deprecate tuples..." sort of thing. There's a reason why most ballots are secret.
I propose to make the vote public. I expect that some people who are not sure about their vote will check who already voted (and what were their vote) to help them to make a choice.
After talking with friends, I realized that I forgot to explain something: my proposal doesn't change anything on the long discussion which occurs *before* the vote. IMHO most tractions occurs during these discussions, not during the vote. (I'm not sure of the word "traction": I mean the pressure to pull most people on your side.)
By the way, I propose that the vote window will be "short": just 1 week.
Maybe we should announce the date of the vote 1 week before, to make sure that people who care about the PEP will be available to vote.
Let me explain why I prefer a short window with a counter example. If a vote remains open for 1 month, the discussion will likely continue during the vote, and people who voted early may want to change their vote. I'm not sure that it's a good thing that people are tempted to change their vote.
Victor
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Le 20/07/2018 à 18:32, Steven D'Aprano a écrit :
The sort of participatory democracy Victor and you seem to be talking about doesn't scale beyond small communities where everyone knows everyone else. That's why such participatory democracy worked in ancient Greece, and continues to be used in (eg) Swiss canons, but beyond that communities have moved to a representative democratic model.
It is commonly estimated that there were between 30000 and 60000 citizens in ancient Athens, and that 6000 of them could physically take part in assembly sessions.
That's small compared to modern Nation States, but that's *much* larger than the team of Python core developers.
Regards
Antoine.
Le 20/07/2018 à 23:14, Brett Cannon a écrit :
Steve pointed out in his reply about how this might increase load as people will have to start trying to get people on side to vote the way they want. In US politics this is done by someone called a /whip/ who "whips up" votes for a bill. With 91 (or more if people start to come back to use their commit rights who have not added their GitHub usernames) of us getting grandfathered into this, people will be somewhat political in getting votes for or against PEPs they care about since only people post-Guido would be made core devs knowing they now have a vote on PEPs and thus take that into consideration when adding new members to the team.
That's an interesting point, but do you have any evidence of such phenomena in other open source projects? Just because something happens in US politics doesn't mean it's likely to happen in a technical project populated with volunteers.
Regards
Antoine.
On Mon, Jul 23, 2018, 01:11 Antoine Pitrou, <antoine@python.org> wrote:
Le 20/07/2018 à 23:14, Brett Cannon a écrit :
Steve pointed out in his reply about how this might increase load as people will have to start trying to get people on side to vote the way they want. In US politics this is done by someone called a /whip/ who "whips up" votes for a bill. With 91 (or more if people start to come back to use their commit rights who have not added their GitHub usernames) of us getting grandfathered into this, people will be somewhat political in getting votes for or against PEPs they care about since only people post-Guido would be made core devs knowing they now have a vote on PEPs and thus take that into consideration when adding new members to the team.
That's an interesting point, but do you have any evidence of such phenomena in other open source projects? Just because something happens in US politics doesn't mean it's likely to happen in a technical project populated with volunteers.
Nope, no evidence (but I suspect most of what any of us are suggesting has something we can directly compare against 😉). This is just a potential worry of mine.
-Brett
Regards
Antoine.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 21 July 2018 at 04:30, Donald Stufft <donald@stufft.io> wrote:
On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner@redhat.com> wrote:
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
I think the core difference behind all of the proposals, when you get down to brass tacks, will be the vision for where the langauge goes. There are independently good ideas that maybe should not be accepted, because they compromise the vision for the worse, or ideas that seem poor on the tin but that once they get added they mesh well with the overall language.
The further you scale up the number of people directly deciding the direction of the language, the more likely you will find inconsistency. No two people have the same design sense, and so if you ask two people you're likely to get at least two answers.
One of the things that puzzles me about the "Who will set the direction of the language if Guido doesn't do it?" concern is that from my perspective, this is something that Guido mostly *didn't* do (and I'm OK with that). Python has never had a clear road map in the 15+ years I've been part of the core development community - it's just had assorted projects that different individuals have driven to varying levels of completion based on the strength of their convictions about the topic, and the time they've had available to devote to driving it (along with a few "definitely not" issues written down in the form of rejected PEPs).
The projects that Guido has been directly involved in driving have been more ambitious in scope than most other folks would be prepared to pursue (e.g. Py3k, asyncio, type hinting), but there have been significant changes he accepted that were originated by others (such as f-strings and assignment expressions), as well as significant topics where he largely delegated decision making to others (such as Unicode handling, project dependency management, the import system, and scientific computing).
If I were to write an article like https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-l... today, the specific topics I'd mention would be different, but the overall tone would be similar.
And I think that's inevitable in an environment driven primarily by volunteer and sponsored development: the time to pursue particular activities has to come from somewhere, and that's either going to be the intrinsic motivations of individuals donating their own time, or else the extrinsic motivation of folks pursuing paid problem solving on behalf of an organisation.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 21 July 2018 at 07:14, Brett Cannon <brett@python.org> wrote:
On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner@redhat.com> wrote:
What is the image sent to contributors if we create a subgroup inside core developpers called "council"? What if we elect a new BDFL *for life*? Does it mean that even core developers judgment are no longer trusted, only the council decision matters? What about people outside in the insider group of cores... regular contributors? Will anyone still listen to them?
I'm not saying that a new governance will lead to such issues. I'm only opening the question of the image sent to the community.
This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away like candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history.
Now we're being asked to also trust someone's design acumen as they will be voting on PEPs. Up until this point I didn't have to worry about whether every core dev would take the language in a direction I disagreed with because they simply didn't have the authority to; it rested with Guido. This proposed change, though, means I now have to judge all core developers not just on whether I can trust them to code appropriately but whether I think they would vote on PEPs that I agree with. That would mean I wouldn't have voted to give Pablo commit privileges because I simply do not know his contributions well enough to know if he would make decisions in a way I'm personally in favour of.
I'd share Brett's concern about our being careful in changing the responsibilities of what it means to be a core developer - we're already pretty slow and cautious when it comes to promoting people and encouraging them to find their own comfort level with their new privileges and responsibilities, and so we should be wary of making that learning curve even steeper than it already is.
By contrast, I think that adding more explicit responsibility levels beyond the initial step of becoming a core developer has the potential to help us avoid some of the pitfalls described decades ago in Jo Freeman's excellent discussion on the "Tyranny of Structurelessness": https://www.jofreeman.com/joreen/tyranny.htm
It's already the case that we have differing levels of influence amongst the core development team - they're just currently acquired through years of personal interactions, both positive and negative, and thus I'd expect them to mainly correlate with "available time" (to increase the number of opportunities for positive interactions), "self-restraint" (to reduce the frequency of negative interactions), and "freedom to travel" (to provide more opportunities to meet people in person and increase trust levels that way).
While those aspects of community influence and leadership are never going to go away, we have an opportunity now to set up a model that allows folks to ask themselves if they're interested in pursuing a more visible role not only amongst the core development team, but also in representing the core development team to the outside world (whether that's through day-to-day participation in python-dev and python-ideas, through presentations and personal articles, or through being a point of contact for media enquiries). Similar to the way PSF Board elections work, folks offering to serve in this role could be elected via Approval voting amongst the core developers, using the same Helios platform as the Board elections.
That way even if we do decide that it still makes sense to have a Chief Shrubbery Tender (with or without obscure English comedy references in their role title), we can also build succession planning into the system by which we appoint them, by ensuring that more folks than just the primary designated spokesperson are gaining community visibility.
Cheers, Nick.
P.S. The Chief Shrubbery Tender suggestion isn't entirely in jest. In addition to being a Monty Python reference, it also ties in to a community management discussion that was rumbling along in the background (e.g. [1]) when I was still working for Red Hat: the upstream/downstream analogy that Linux distributions have long used to describe the way that open source software flows into their systems and then on to downstream rebuilds has a lot of problems, one of the most notable of which is that open source communities tend to require a lot more tending than oceans, rain clouds and natural springs do. While it doesn't look like the potential replacement analogies were ever fully elaborated in a public venue (at least, not that I can find), [2] touches on the one that seemed most compelling: building and maintaining a successful open source community is a lot like tending a garden, where the key activities are things like keeping weeds away and helping to provide water and appropriate amounts of sunlight, rather than trying to tell the individual plants how to grow leaves and flowers :)
[1] http://community.redhat.com/blog/2017/05/let-the-river-flow/ [2] https://community.redhat.com/blog/2017/05/seeds-of-community/
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, 24 Jul 2018 at 07:46 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 21 July 2018 at 04:30, Donald Stufft <donald@stufft.io> wrote:
On Jul 19, 2018, at 7:47 PM, Victor Stinner <vstinner@redhat.com> wrote:
It seems that the main question for a new governance is how to take a decision on PEPs (accept or reject them with some variants like Deferred). I read that core developers are unable to make a decision themselves (fail to reach a consensus) and that letting core developers decide would make Python "inconsistent" (as if only a single BDFL is able to keep Python consistent). I also read that the BDFL is required to make unpopular decisions to enhance Python.
I think the core difference behind all of the proposals, when you get
to brass tacks, will be the vision for where the langauge goes. There are independently good ideas that maybe should not be accepted, because they compromise the vision for the worse, or ideas that seem poor on the tin but that once they get added they mesh well with the overall language.
The further you scale up the number of people directly deciding the direction of the language, the more likely you will find inconsistency. No two
down people
have the same design sense, and so if you ask two people you're likely to get at least two answers.
One of the things that puzzles me about the "Who will set the direction of the language if Guido doesn't do it?" concern is that from my perspective, this is something that Guido mostly *didn't* do (and I'm OK with that). Python has never had a clear road map in the 15+ years I've been part of the core development community - it's just had assorted projects that different individuals have driven to varying levels of completion based on the strength of their convictions about the topic, and the time they've had available to devote to driving it (along with a few "definitely not" issues written down in the form of rejected PEPs).
The projects that Guido has been directly involved in driving have been more ambitious in scope than most other folks would be prepared to pursue (e.g. Py3k, asyncio, type hinting), but there have been significant changes he accepted that were originated by others (such as f-strings and assignment expressions), as well as significant topics where he largely delegated decision making to others (such as Unicode handling, project dependency management, the import system, and scientific computing).
If I were to write an article like
https://www.curiousefficiency.org/posts/2011/08/of-python-and-road-maps-or-l... today, the specific topics I'd mention would be different, but the overall tone would be similar.
So I think if you replaced "direction" with "tone" in your opening phrase then that would encompass what a lot of people are worried about. It isn't necessarily about a roadmap (which we obviously have never had written down ;) , but Guido did set a tone for the language overall which he kept in his head and worked towards through thought and instinct.
But Guido has done directional things like saying the removal of the GIL would be acceptable if single-threaded performance was kept, even potentially at the cost of a bit of the C API. So while we have never laid out explicit plans for the next 1, 5, or 10 years, I think there has been guidance and an implicit direction of where the language should be headed.
-Brett
And I think that's inevitable in an environment driven primarily by volunteer and sponsored development: the time to pursue particular activities has to come from somewhere, and that's either going to be the intrinsic motivations of individuals donating their own time, or else the extrinsic motivation of folks pursuing paid problem solving on behalf of an organisation.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Brett:
This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away like candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history.
I don't think that giving core dev priviledge just if you attend a sprint is a good practice :-) Maybe we did that in the past, but it seems like nowadays the process is more formalized and stricter.
Some people wrote that they are "100+" core developers. If everyone vote on each PEP, one additional core dev just has 1 vote on 101 voters. I don't see any pressure here.
Now we're being asked to also trust someone's design acumen as they will be voting on PEPs. Up until this point I didn't have to worry about whether every core dev would take the language in a direction I disagreed with because they simply didn't have the authority to; it rested with Guido. This proposed change, though, means I now have to judge all core developers not just on whether I can trust them to code appropriately but whether I think they would vote on PEPs that I agree with. That would mean I wouldn't have voted to give Pablo commit privileges because I simply do not know his contributions well enough to know if he would make decisions in a way I'm personally in favour of.
IMHO it's ok if people make mistakes on voting if we are enough voters. Making mistakes is part of the learning process.
If the vote results are public during the vote, if a voter "does a mistake", you are free to lobby to vote against this mistake to guide people to the right choice :-)
Again, I expect that the discussion before a vote will already highlight the popular opinions. The vote result shouldn't be a surprise for anyone if the discussion goes well.
Honestly, in many cases, I just follow the expert that I trust, when I'm unable to have my own opinion on a PEP.
Victor
Le 25/07/2018 à 01:50, Victor Stinner a écrit :
Brett:
This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away like candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history.
I don't think that giving core dev priviledge just if you attend a sprint is a good practice :-) Maybe we did that in the past, but it seems like nowadays the process is more formalized and stricter.
It seems at some point it was believed that giving commit rights early would boost participation. Now we know that doesn't work.
Regards
Antoine.
On Tue, 24 Jul 2018 at 16:51 Victor Stinner <vstinner@redhat.com> wrote:
This will also make it harder to become a core developer. In the past we have been willing to give people commit privileges for showing they know how to code to our standards, make decisions when it came to PRs, and knew when they were outside of their depth (e.g. giving someone commit privileges to work on Python code but not C). We've also given commit privileges away
Brett: like
candy to people who have attended sprints in the past, so we have not even held up that level of requirement for all of Python's history.
I don't think that giving core dev priviledge just if you attend a sprint is a good practice :-)
It isn't now, but it was what we thought made sense at the time. Remember the team used to be quite a bit smaller. :)
Maybe we did that in the past, but it seems like nowadays the process is more formalized and stricter.
Yes.
Some people wrote that they are "100+" core developers. If everyone vote on each PEP, one additional core dev just has 1 vote on 101 voters. I don't see any pressure here.
There has been more than one person who has joined the core team since I did. ;) From my perspective this isn't about the next person, but the next 10, 20, or 50 people who will heavily influence the outcome of a vote. Remember, we are measuring time in decades here.
Now we're being asked to also trust someone's design acumen as they will be voting on PEPs. Up until this point I didn't have to worry about whether every core dev would take the language in a direction I disagreed with because they simply didn't have the authority to; it rested with Guido. This proposed change, though, means I now have to judge all core developers not just on whether I can trust them to code appropriately but whether I think they would vote on PEPs that I agree with. That would mean I wouldn't have voted to give Pablo commit privileges because I simply do not know his contributions well enough to know if he would make decisions in a way I'm personally in favour of.
IMHO it's ok if people make mistakes on voting if we are enough voters. Making mistakes is part of the learning process.
I would rather we didn't learn on language changes we will be living with for decades if we can help it. ;)
If the vote results are public during the vote, if a voter "does a mistake", you are free to lobby to vote against this mistake to guide people to the right choice :-)
I don't think any of us want to lobby against how an individual already voted. That seems like scare tactics against individuals.
Again, I expect that the discussion before a vote will already highlight the popular opinions. The vote result shouldn't be a surprise for anyone if the discussion goes well.
Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate.
My point isn't about being surprised in an outcome. My point is it will shift how we judge people becoming core devs and the barrier to join will go up. So unless there's reasonable expectation of an increase in participants in the project due to a governance shift like this then we would need to be ready for having slower team growth if this is the governance model that is chosen.
Honestly, in many cases, I just follow the expert that I trust, when I'm unable to have my own opinion on a PEP.
Sure, and that's you. But that doesn't mean the 90 other people think that way. ;) And that's my point: I now have to find out how people will think going forward in language design and screen future core devs on this new, extra criteria.
On Jul 25, 2018, at 2:01 PM, Brett Cannon <brett@python.org> wrote:
Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate.
It makes me think a bit of the US Supreme Court, where judges who might someday want to be on that court, learn to be very careful about hiding their true opinions (without directly lying of course) on a number of very controversial topics, knowing that coming out for/against them is likely to blow up their changes of ever progressing to that point.
Le 26/07/2018 à 01:21, Donald Stufft a écrit :
On Jul 25, 2018, at 2:01 PM, Brett Cannon <brett@python.org <mailto:brett@python.org>> wrote:
Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate.
It makes me think a bit of the US Supreme Court, where judges who might someday want to be on that court, learn to be very careful about hiding their true opinions (without directly lying of course) on a number of very controversial topics, knowing that coming out for/against them is likely to blow up their changes of ever progressing to that point.
You know, I'm sure that's already the case in the Python community, on topics such as diversity policies, CoCs and the like.
Regards
Antoine.
On Wed, Jul 25, 2018 at 7:24 PM Donald Stufft <donald@stufft.io> wrote:
On Jul 25, 2018, at 2:01 PM, Brett Cannon <brett@python.org> wrote:
Right, and your proposal means I now have to judge proposed core developers on which side of popular opinion they will come down on in hopes that they vote in ways I agree with and thus help take the language in a direction I think is appropriate.
It makes me think a bit of the US Supreme Court, where judges who might someday want to be on that court, learn to be very careful about hiding their true opinions (without directly lying of course) on a number of very controversial topics, knowing that coming out for/against them is likely to blow up their changes of ever progressing to that point.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
(I've been quite on this thread thus far, just soaking everything else up, but this side note about SCOTUS made me want to share this potentially relevant observation/nerdery.)
Recent trends in Supreme Court nominees increasingly have justices coming from the DC Circuit [0]. The reason for this (IMO) is that the DC Circuit deals very heavily in parts of the law that only lawyers care about -- primarily administrative law and suits against the federal government. They see almost no cases dealing with social issues. As a result, nominees tend to have records without cases that will generate significant controversy amongst the public (while still being able to demonstrate their judicial philosophy to folks who understand such things).
The analogy in the Python-verse might be inviting a new core developer for their work on runtime internals, but then having the ability to sway stdlib design once they become a core dev.
This type of system stands in contrast with the one the Rust community has, where they have dedicated teams, which people are members of (some people are members of many), and they define the scope of the team's responsibility/authority. So you can be a member of the compilers team, with no say over how the community team functions.
Hope everyone enjoyed my Supreme Court nerdery, Alex
[0]: Chief Justice Roberts, Justice Ginsburg, Justice Thomas, Judge Garland, and Judge Kavanaugh.
-- All that is necessary for evil to succeed is for good people to do nothing.
participants (12)
-
Alex Gaynor -
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Donald Stufft -
Doug Hellmann -
Ethan Furman -
Nick Coghlan -
Paul Moore -
Steve Dower -
Steven D'Aprano -
Victor Stinner