[python-committers] And Now for Something Completely Different

[Brett Cannon]

On Thu, 19 Jul 2018 at 16:47 Victor Stinner <vstinner at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180720/d4634e2f/attachment.html>