On Thu, 19 Jul 2018 at 16:47 Victor Stinner email@example.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.
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.