While thinking about how to get more contributors onboard, I
identified that one bottleneck is building trust. Currently, a vote to
promote a contributor as a core dev requires the approval of almost
all active core developers, and this list is quite large (50 people?
more?). It takes a lot of time until a contributor is known by enough
people to start the process to promote them as a core dev.
My idea is to create subteams which would have less permission than
"everything": restrict changes to specific directories. It seems like
in practice, we already have such subteams: Documentation, IDLE and
asyncio have a dedicated Component in the bug tracker, their own
directories, a group of people focused on these components, and
even... a dedicated mailing list!
The restriction would be the ability to merge a pull request. Since
miss-ilington recently got the power of merging a PR, it makes me
think that it's doable to allow "non core" people to merge a change
under certain conditions. For example, let's say that a contributor
called "Alice" is part of a subteam. If Alice approves a change in the
review, added the "approved" label and the CI pass: a bot can merge
the change, since Alice is allowed to merge a PR modifying specific
directories.If Alice doesn't have the power, the bot may notice Alice
that she lacks permission and the bot may remove the label.
IMHO it's better to have two steps to merge: approval in the review
and a label, sometimes a change looks good but should not be merged
yet, or you don't want to take the responsibility to merge it
What about current core developers? No change for them, they keep
their "super power" to modify everything.
If a member of a subteam shows interest to do more than only working
in a subteam, the usual promotion process with a vote on
python-committers can be followed.
My expectation is that it will be faster to promote a contributor into
a subteam. It's easier to trust someone if they is only allowed to
modify some directories. In my experience, people with the same
interest find their way to meet other people working on the same
topic. The trust is built naturally in a component.
You may see a parallel with the Linux kernel hierarchy and Linux
subsystems, but the proposed organization is different. In Python, the
tradition is that everybody works in the same repository. I don't want
to change that.
What do you think? Do you like the idea of subteams? Is it feasible
(the label and the bot things)?
I identified 3 obvious subteams:
Maybe you see more candidates?