Agree on all counts. Hadrian On Nov 10, 2010, at 5:06 PM, Guillaume Nodet wrote:
> 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
