AAFAIK, most projects use the default settings, i.e. edit for committers, comments for everyone with an ICLA on file. If non-committers with a ICLA on file want to edit, permissions is granted case by case usually (at least, that's what i've done since a few years). So the bar is lower than for code, but mostly because there's no need for an apache account. If you want a low bar for code and doc, it's easy to vote in contributors as committers. The lower the bar is, the more people will get involved, and inviting people as committers often as the effect of raising their contribution level. Imho, it's just a question of trust (which is mostly earned by merit of course). And even if they haven't shown the highest degree of comprehension of the whole code base, people usually commit in area they understand, and it's easy to mentor / review the commits for a few months anyway.
Actually, I think allowing access to non-committers tend to raise the bar artificially. The reason is that when a contributor start contributing a lot of patches, you need to spend more time to review and apply his patches. If he can change directly (using confluence in our case), you don't necessary feel the pain, thus you tend to not grant committership as easily. On Wed, Nov 10, 2010 at 22:16, Eric Johnson <emjohn...@fusesource.com> wrote: > Hadrian, > As it turns out, not anyone with a signed CLA can edit the Camel wiki. > The Apache Confluence wiki allows each community to determine who can > edit the pages in their space. > I went create a page listing the ideas/issues around a site update and > was confronted with a "Permission Denied" page. My guess is that the > Camel space either has me specifically banned or that the permissions > are set such that the asf-cla group does not have permission to create > pages. > Cheers, > Eric > > On Wed, Nov 10, 2010 at 11:14 AM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >> Just for the record. I like scalate too, it's f*** awesome s*** :). >> Hadrian >> >> On Nov 10, 2010, at 11:04 AM, Johan Edstrom wrote: >> >>> I actually really liked the scalate project and writing the docs in IDEA, >>> making a patch and tossing it in github. >>> >>> Offline editing also seems really nice for when you are on planes, in >>> airports or hotels. >>> Not to mention if you actually fix a bug and submit a patch you could fix >>> documentation in one feel swoop. >>> >>> And with the possibility of editing and running Jetty locally - it was >>> really easy. >>> >>> Just my .02, i'm one of those that like irc for the quick informal style >>> over forums for example, >>> I also really like svn/git since I have tooling around versioning et al. >>> >>> And yeah, making patches is "klunky" using diff and things like that. >>> >>> /je >>> On Nov 10, 2010, at 8:52 AM, Hadrian Zbarcea wrote: >>> >>>> >>>> On Nov 10, 2010, at 10:28 AM, James Strachan wrote: >>>> >>>>> On 10 November 2010 15:15, Daniel Kulp <dk...@apache.org> wrote: >>>>>> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote: >>>>>>> On 10 November 2010 14:51, Daniel Kulp <dk...@apache.org> wrote: >>>>>>>> >>>>>>>> For most of the people on this list, it ISN'T a big deal. We deal >>>>>>>> with >>>>>>>> svn and mvn every day. For others, it could be. >>>>>>> >>>>>>> Given 99% of all our documentation and web content is developed by >>>>>>> committers or folks who are capable of editing text files and using >>>>>>> git/svn, I'd rather use a system that helps the 99% be more effective. >>>>>>> >>>>>>> Maybe you should just help out this one CXF person & show them how to >>>>>>> fork & commit to github (its very easy), then you can easily pull >>>>>>> their commits from there? >>>>>> >>>>>> Umm.. no. Pulling branches from github is NOT, at this point, an >>>>>> acceptable >>>>>> way of getting content into an Apache product. They would still need to >>>>>> create a patch and attach it to JIRA with the "grant" checkbox checked. >>>>> >>>>> Whatever happens folks have to raise a JIRA and click the "grant" >>>>> checkbox. >>>>> >>>>> I fail to see why a link to a specific commit (i.e. a link to a number >>>>> of patches) is any less suitable than a number of patch files being >>>>> attached in place to the JIRA. Got anything specific to back this up >>>>> or is it just that we've not done it before? >>>>> >>>>> Patch files are a total PITA for both the person contributing and the >>>>> person applying the patch. (They usually break, get out of sync, have >>>>> whitespace issues and frequently have the wrong path information in >>>>> them & often have problems with new/renamed/deleted files). >>>>> >>>>> If this discussion really is about being a "community issue" and >>>>> making it easy for both folks to contribute and for committers to >>>>> apply those contributions, I'd rather we figure out this issue of >>>>> using links to git commits as an alternative to patch files on JIRAs - >>>>> this could make a *massive* difference to both getting contributions >>>>> and more effectively applying them IMHO. Helping scm-novices >>>>> contribute to documentation (which they've never really done so far on >>>>> Camel anyway) seems quite irrelevant in comparison. >>>> I don't know if this is a scm-novices issues. We had contributions from >>>> not committers in the past. >>>> Johan (before his commiter days) is one example, Steve Bate is another. I >>>> would rather ask them how likely would it be to contribute to doc if they >>>> had to co/edit/submit-patch, vs edit in-place wiki style. >>>> I know they are not scm-novices. >>>> >>>> I am open to any alternative that would not raise the barrier to entry for >>>> documentation contributors and that's acceptable to the ASF. >>>> >>>> Hadrian >>>> >>>>> >>>>> -- >>>>> James >>>>> ------- >>>>> FuseSource >>>>> Email: ja...@fusesource.com >>>>> Web: http://fusesource.com >>>>> Twitter: jstrachan >>>>> Blog: http://macstrac.blogspot.com/ >>>>> >>>>> Open Source Integration >>>> >>> >> >> > > > > -- > Principle Technical Writer > Phone (781) 280-4174 > Skype finnmccumial > E-Mail emjohn...@fusesource.com > Blog http://documentingit.blogspot.com/ > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
