Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 1:05 PM, Benson Margulies wrote: > ICLAs are still an absolute requirement. So, imagine an Apache project with > a policy like: > >Commit rights are granted on request to people with an Apache ICLA on > file ... > OK. I understand. And I hope we think of "commit rights" in the broad sense. It is more than just SVN. We have other systems where access is keyed to an Apache ID. For example: Pootle, which we use for translations, has an enhanced set of rights that come only with having an ID today. Similarly in Bugzilla, we (OpenOffice project) give extra permissions to those with registered email addresses from apache.org. So for us a very useful thing would be a streamlined way of granting these non-SVN privileges that ordinarily are reserved for committers. Regards, -Rob > > > > On Sat, Jan 5, 2013 at 1:02 PM, Rob Weir wrote: > >> On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies >> wrote: >> >> . >> . >> . >> > >> > The question at hand here is, 'is this really a good idea? Would project >> > grow and thrive better if they set a lower bar to grant commit rights?' >> > >> >> How does the iCLA fit into any change? Personally I would not mind >> commit rights on request, but I still see the value for a project to >> have iCLA's on file for all those who have such rights. This is to >> protect our users. >> >> -Rob >>
Re: Project Culture and Commit Rights
The problem with that is that we don't get any of the benefits out of simplification of our rulesets: namely more comprehensible behavior out of the server when a commit has been blocked and someone needs help, and it doesn't imply that the org has made any cultural shifts towards a more open infra, which defeats a lot of the point of the exercise from my POV. Let me be clear tho, I have always argued that projects have the exclusive right to control access to their codebase. However the means by which that control is exercised depends on many factors, and we shouldn't enshrine an unexamined mode of technical operation into perpetuity just because "we've always done it that way". Relaxing ACL's simply represents a more practical, and more modern, way of maximizing the utility you get out of a centralized version control tool like Subversion. Projects shouldn't balk at polite suggestions to modernize, even if we always allow themselves the option of declining to participate. > > From: Bertrand Delacretaz >To: dev@community.apache.org >Sent: Friday, January 11, 2013 3:43 AM >Subject: Re: Project Culture and Commit Rights > >On Sat, Jan 5, 2013 at 4:35 PM, Benson Margulies wrote: >> ...There's a weaker form of this idea that looks at two populations of >> potential contributors: the members of the Apache Software Foundation >> (members@) and all of the people who have been granted commit rights on all >> of the projects (committers@). Projects that don't feel prepared to offer >> commit-on-demand to the world at large might feel inclined to do so for >> (one or both of) these groups... > >As the ASF aims to give PMCs as much freedom as possible, I'd favor a >solution where PMCs can decide themselves who they give write >permission to their code repositories. > >Basing this on groups, project A could say that it's friends with >projects B and C, and as such allow all people who can write to B and >C to write to A as well, based on group authorizations. > >We used to do that with Cocoon, where B and C were Lenya and Forrest - >as sibling projects, we felt that those folks should be able to commit >small fixes directly without asking, but they were expected to ask >before making any substantial changes to our code. > >A PMC could then decide to give write access to all ASF members, all >committers, etc. Letting PMCs make this decision avoids requiring the >whole ASF (that's 150 projects today) to agree on this, which is in >line with how we usually handle things - modularization vs. requiring >everybody to agree. > >-Bertrand > > >
Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 4:35 PM, Benson Margulies wrote: > ...There's a weaker form of this idea that looks at two populations of > potential contributors: the members of the Apache Software Foundation > (members@) and all of the people who have been granted commit rights on all > of the projects (committers@). Projects that don't feel prepared to offer > commit-on-demand to the world at large might feel inclined to do so for > (one or both of) these groups... As the ASF aims to give PMCs as much freedom as possible, I'd favor a solution where PMCs can decide themselves who they give write permission to their code repositories. Basing this on groups, project A could say that it's friends with projects B and C, and as such allow all people who can write to B and C to write to A as well, based on group authorizations. We used to do that with Cocoon, where B and C were Lenya and Forrest - as sibling projects, we felt that those folks should be able to commit small fixes directly without asking, but they were expected to ask before making any substantial changes to our code. A PMC could then decide to give write access to all ASF members, all committers, etc. Letting PMCs make this decision avoids requiring the whole ASF (that's 150 projects today) to agree on this, which is in line with how we usually handle things - modularization vs. requiring everybody to agree. -Bertrand
Re: Project Culture and Commit Rights
On Fri, Jan 11, 2013 at 12:31:44AM -, Ross Gardler wrote: > > -Original Message- > > From: Jed Smith [mailto:j...@jedsmith.org] > > Sent: 10 January 2013 21:27 > > Subject: Re: Project Culture and Commit Rights > > ... > > > The tool isn't the issue here, and I disagree with any attempt to reframe it > > that way. > > +1 +1 (as a subversion dev who occasionally reviews patches coworkers are writing for git.git and libgit2) While the choice of tool often does have implications for workflows a project can use, this discussion is about community management, not workflows. No version control tool will help facilitate community management in the slightest. Tools cannot reason about human interactions and their consequences. There are suitable and unsuitable ways of using a tool to accomplish a particular community management goal. But it's not the tool's fault if something bad happens because humans make the wrong decisions.
RE: Project Culture and Commit Rights
> -Original Message- > From: Jed Smith [mailto:j...@jedsmith.org] > Sent: 10 January 2013 21:27 > Subject: Re: Project Culture and Commit Rights ... > The tool isn't the issue here, and I disagree with any attempt to reframe it > that way. +1 Ross
Re: Project Culture and Commit Rights
There is nothing wrong with Subversion except for preference and difficulty in making branches. I disagree that Benson's topic is directly influenced by such a lower-rung choice as a version control system. The same discussion would be necessary if Apache were completely on Git; who can push directly? Who can't? There's also nothing wrong with the patch-on-JIRA workflow, and you end up with something similar to the Linux kernel. The tool isn't the issue here, and I disagree with any attempt to reframe it that way. -- Jed Smith j...@jedsmith.org
Re: Project Culture and Commit Rights
On Thu, Jan 10, 2013 at 3:58 PM, Thomas Koch wrote: > Benson Margulies: >> Anyone can read http://www.apache.org/dev/open-access-svn.html to see a >> summary of the central idea that started this discussion: that the default >> authorization scheme for Subversion at Apache should be to grant technical >> permission to commit to all committers across the Foundation. > > I'm not currently active in any Apache project but have been and was very > annoyed to be forced to use Subversion. Apache now support git, but I disagree as to the implication. Apache requires there to be a single, reference, repository, from which releases derive. An enumerated list of people has permission to push to that repository, and this discussion has implications for the access control on that. > > Therefor just for the record: The whole discussion would be meaningless if the > ASF would switch to Git. (I'm not sure about the progress in this regard.) > With Git, everybody can add commits to every Git repository on the Internet. > One would just not be able to push them. But I can just push to my own Github > account and send an email asking for a pull. > > Regards, > > Thomas Koch, http://www.koch.ro
Re: Project Culture and Commit Rights
Benson Margulies: > Anyone can read http://www.apache.org/dev/open-access-svn.html to see a > summary of the central idea that started this discussion: that the default > authorization scheme for Subversion at Apache should be to grant technical > permission to commit to all committers across the Foundation. I'm not currently active in any Apache project but have been and was very annoyed to be forced to use Subversion. Therefor just for the record: The whole discussion would be meaningless if the ASF would switch to Git. (I'm not sure about the progress in this regard.) With Git, everybody can add commits to every Git repository on the Internet. One would just not be able to push them. But I can just push to my own Github account and send an email asking for a pull. Regards, Thomas Koch, http://www.koch.ro
Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 10:20 AM, janI wrote: > On 5 January 2013 19:14, Marvin Humphrey 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
Re: Project Culture and Commit Rights
On 5 January 2013 19:14, Marvin Humphrey wrote: > On Sat, Jan 5, 2013 at 7:35 AM, Benson Margulies > 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 >
Re: Project Culture and Commit Rights
I personally like the idea of giving committer right on request. I do not like the fact that is has to be earned...we are volunteers not workers ! However I fully understand PMCs that are concerned about uncontrolled commits, so I see the "right on request" go hand in hand with a way of "removing right". PMC should be able to, with reason and warning, to "ban" a committer, and that should be effective for all ASF. I also think that people with commit rights who are inactive for a longer period of time (I am not sure how long that should be, but no longer than a year) should automatically have revoked the right (with the option that they can request it again). ICLA is a must. I know from other projects (outside) ASF that they talk about committers and committer-interest, the latter group is controlled/reviewed by an old committer. With that, committers save time to commit patches, and new people feel welcome. but that is just my personal opion. Jan Iversen. On 5 January 2013 19:05, Benson Margulies wrote: > ICLAs are still an absolute requirement. So, imagine an Apache project with > a policy like: > >Commit rights are granted on request to people with an Apache ICLA on > file ... > > > > > On Sat, Jan 5, 2013 at 1:02 PM, Rob Weir wrote: > > > On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies > > > wrote: > > > > . > > . > > . > > > > > > The question at hand here is, 'is this really a good idea? Would > project > > > grow and thrive better if they set a lower bar to grant commit rights?' > > > > > > > How does the iCLA fit into any change? Personally I would not mind > > commit rights on request, but I still see the value for a project to > > have iCLA's on file for all those who have such rights. This is to > > protect our users. > > > > -Rob > > >
Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 7:35 AM, Benson Margulies 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
Re: Project Culture and Commit Rights
ICLAs are still an absolute requirement. So, imagine an Apache project with a policy like: Commit rights are granted on request to people with an Apache ICLA on file ... On Sat, Jan 5, 2013 at 1:02 PM, Rob Weir wrote: > On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies > wrote: > > . > . > . > > > > The question at hand here is, 'is this really a good idea? Would project > > grow and thrive better if they set a lower bar to grant commit rights?' > > > > How does the iCLA fit into any change? Personally I would not mind > commit rights on request, but I still see the value for a project to > have iCLA's on file for all those who have such rights. This is to > protect our users. > > -Rob >
Re: Project Culture and Commit Rights
On Sat, Jan 5, 2013 at 10:35 AM, Benson Margulies wrote: . . . > > The question at hand here is, 'is this really a good idea? Would project > grow and thrive better if they set a lower bar to grant commit rights?' > How does the iCLA fit into any change? Personally I would not mind commit rights on request, but I still see the value for a project to have iCLA's on file for all those who have such rights. This is to protect our users. -Rob
Project Culture and Commit Rights
Over the last several weeks, there has been a length discussion amongst Apache Foundation members about how the Foundation manages access to source control, with a focus on Subversion. Anyone can read http://www.apache.org/dev/open-access-svn.html to see a summary of the central idea that started this discussion: that the default authorization scheme for Subversion at Apache should be to grant technical permission to commit to all committers across the Foundation. The purpose of this message is to start a discussion here about the culture of commit rights. The purpose of this message is *not* to create an additional debate about the UCB (universal commit bit) itself, which, at the request of the VP of Infrastructure, is happening on the operations@mailing list. (?Does Comdev have a Wiki?) Let me start by defining two terms: 'Commit Permission' and 'Commit Rights'. 'Commit Permission' is a _technical_ status. If you have commit permission, and you run an 'svn commit' command, it will succeed. 'Commit Rights' is a _social status_. You have commit rights when a community has voted to invite you to commit. The people with commit rights on a project are the 'committers'. This message is about commit rights. It skips right over the arguments about changing the relationship between commit rights and commit privileges, to focus on how communities manage rights. Commit rights are not necessarily a simple, binary, phenomenon. Committers on projects are expected to follow community policies, procedures, and norms. One simple example of this is RTC. If a project operates under RTC conventions, committers don't go off and commit things without review. There are many more examples. If a project has agreed to drive towards a release, committers are expected to not disrupt the process by committing big, new things. Some projects insist that every commit be tied to a JIRA. All in all, however, Apache projects have tended to treat commit rights as a big deal. You don't get commit rights until you earn them via merit. Some projects are very conservative in evaluating merit. Some projects look for some level of overall community engagement as a prerequisite to commit rights. The question at hand here is, 'is this really a good idea? Would project grow and thrive better if they set a lower bar to grant commit rights?' Some people (Greg Stein, e.g.) have written eloquently on the historical justification for conservative commit control. Historically (i.e. in CVS), it was difficult to monitor changes and it was difficult to cleanly undo an inappropriate change. So, it was necessary to set a high bar for commit rights, so as to reduce the risk of something awful happening. In the modern world, on the other hand, the Foundation provides email with diffs for review, and Subversion makes it reasonably straightforward to reverse an untoward commit. Thus, this argument claims, projects have little to lose by granting commit rights more easily. What, on the other hand, do they have to gain? Long-term success of an open source projects depends on continued acquisition of new participants. Projects that don't grow risk shrinking and dying. When a person shows up at a project and reads the message, 'we don't trust you until you've posted 15 patches, etc.' that is not exactly a welcoming message. Some people see it as a challenge and rise to it. Other people are put off. There are several notable examples of successful open source projects outside of the Foundation that adopt the opposite tactic. Their publish a policy like: "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." It seems that the people who show up at these projects are, almost universally, responsible adults who are happy to comply. This 'welcoming' policy has the effect of drawing people in. 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. 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. To recapitulate a bit, so far I've presented some historical context and an argument for an alternative model of _commit rights_. It has no particular implication for the management of _commit privileges_. If a project adopts this model, it still adds peo
