community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: Project Culture and Commit Rights
Date Sat, 05 Jan 2013 18:14:15 GMT
On Sat, Jan 5, 2013 at 7:35 AM, Benson Margulies <bimargulies@gmail.com> wrote:
> It seems that the people who show up at these projects are, almost
> universally, responsible adults who are happy to comply.

The ASF is always going to require an iCLA before granting commit rights.
That on its own poses a significant barrier to entry and will likely weed out
the occasional problem case.  It's a heuristic, but I think we can assume that
people who go through with signing and sending in an iCLA tend to skew
responsible, intellectually serious, knowledgable, dedicated and technically
competent.

Assuming a hard requirement on iCLAs and version control technology which is
capable of full restoration without extraordinary effort, trusting committers
by default ought to mean less total work for everyone -- and a better
experience for new contributors.  Schlepping around patch sets and getting
them applied by proxy is a proven approach which has worked well for a long
time and remains perfectly viable -- but having everyone work within the
version control system's native capabilities takes less effort.

> What I've presented, so far, is arguable a radical change to the usual
> Apache culture. It moves 'karma from merit' entirely from the 'commit'
> threshold to the 'supervise' threshold. I already know that there are
> people at Apache who don't like the idea, or at least don't think it makes
> sense for their projects. I'm not writing to suggest that this scheme be
> forced upon anyone. This is comdev@. Here, I think, we talk about ways of
> helping projects grow and succeed.

To address one of the objections...

A number of ASF projects unify their committer and PMC lists; it's a forcing
function in service of having a project governed by its contributors.

Relaxed committership requirements don't mesh well with this mechanism, but
despite its elegance, it's only a means to an end -- so long as the project is
elevating significant contributors to the PMC in a timely manner, there's no
problem.

Reasonable people can arrive at different conclusions about which technique
is more important to a community's health.

> Writing as the IPMC chair, I'm inclined to think that the Incubator would
> to well to encourage this model for new projects. By far, the biggest
> reason for podlings to fizzle is their failure to grow. I don't mistake
> this for a magic bullet, but I think it could help.

I agree that young projects which are competing for contributors in the open
source marketplace have the most to gain.

> 'Commit on request' means that the PMC has, potentially,
> more people to supervise after less experience. Some projects will not see
> this as a good tradeoff.

Mature, popular projects tend to receive more contributions than they can
handle; competent review becomes the scarce resource.  I question whether an
RTC project would really spend a lot of time cleaning up after newbie
rule-breakers, though.

Marvin Humphrey

Mime
View raw message