community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Project Culture and Commit Rights
Date Sat, 05 Jan 2013 18:20:14 GMT
On 5 January 2013 19:14, Marvin Humphrey <marvin@rectangular.com> wrote:

> 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.
>
If I may, mature projects might sometimes benefit from new thinkers, at
least that can cause quite some discussions (I talk here from personal
experience).

today a busy RTC project have the problem of answering patch mails
requesting CTR, so the work seems to be equal.

jan Iversen.

>
> Marvin Humphrey
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message