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/
