On Sat, Jan 5, 2013 at 10:20 AM, janI <j...@apache.org> wrote:
> On 5 January 2013 19:14, Marvin Humphrey <mar...@rectangular.com> wrote:
>> 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).
Challenging orthodoxy is important, but relaxed committership is unsuitable as
a mechanism for driving discussion.
Apache is a home for consensus-driven development. If an individual abuses
their Apache committership to commit something controversial to the mainline,
they should be blacklisted. (Regardless of seniority!) A crucial assumption
underlying relaxed committership is that the overwhelming majority of
contributors won't do something antisocial like that -- and thus it's wasteful
to force good citizens to work outside of the version control system.
That said, it's beneficial to have people doing branch development within view
of the rest of the community, so that people can follow the evolution of ideas
via commit emails and gradual changes to the repository. However, ideas which
are introduced via branch commits are no different from ideas which are
introduced via email proposals: establishing community consensus -- lazy or
explicit -- for disruptive changes is still mandatory, and the project's dev
list is still the appropriate forum.
My initial comment was limited to RTC projects for the sake of simplicity, but
CTR projects shouldn't have problems either so long as they communicate that
committership comes with constraints -- as per the sample policy from Benson's
original post:
"Commit rights to this project are granted upon request. However,
committers must read, understand, and comply with our policies. When you
start out, you may want to ask for review, or commit to a branch, and get
feedback from the community."
Outside of Apache, the Jenkins project couches its liberal committership
policy similarly:
https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document#GovernanceDocument-Corecommitters
One is not required to have a proven history of contributions before
granted the committership, but that doesn’t mean other core committers
will never revert your changes.
Marvin Humphrey
