On 5 January 2013 19:14, Marvin Humphrey <mar...@rectangular.com> wrote:
> On Sat, Jan 5, 2013 at 7:35 AM, Benson Margulies <bimargul...@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 >
