Committers vs. contributors (was: Support for (Java) Pattern Matching)

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Oct 31, 2017 at 1:41 AM, rlamont@componentcorp.com
<rl...@componentcorp.com> wrote:
> ...I might be staying the obvious, but to maximise Community involvement, you probably want to build a baseline process around
> contributors rather than committers...

I agree with that and it's also possible (if that's what the NetBeans
PPMC wants) to give commit access to people "early", without waiting
for them to demonstrate that they are ready to be elected as (P)PMC
members.

In Apache projects, committers don't have formal decision power, so
they cannot do much harm - worst case if someone commits bad stuff
that can be reverted, and if the problem persists their commit rights
can be suspended. That's quite extreme, I've seen maybe two such cases
in 17 years of Apache activity.

What I mean is that the project doesn't have to be as cautious about
electing committers as it has to be for PMC members, who can actually
do harm and are harder to "fire".

Many Apache projects elect committers early, even if they might not be
qualified to commit to the project's core yet, stating that they are
not expected to touch code that they don't fully master. You don't
need complex access rights for that, social limitations are good
enough and Git is your friend.

This is for the PPMC to decide, but my suggestion would be to create
additional repositories for experiments, plugins etc and set a
relatively low barrier for electing committers who are meant to commit
to those repositories only, in general, except for minor obvious fixes
that might be committed to the core directly.

-Bertrand (with my experienced Apache member hat on)