> And then for people to actually be able to edit the wiki page they > have to sign up for the ICLA which takes a fair bit of time and for > some people just scare them off.
This is a mandatory part as long as we include the manual in the distro. Hadrian On Nov 10, 2010, at 10:07 AM, Claus Ibsen wrote: > On Wed, Nov 10, 2010 at 4:00 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >> That is true, but you can see your changes in the wiki right away. >> >> I love the idea of having the docs version controlled, I understand all the >> benefits. I am also convinced losing the ability to edit in place is a major >> community issue. Can we have both? We want to make it as easy as possible >> for people to contribute. Documentation, as shown by the survey, is the #1 >> issue. >> > > I actually don't think we have had many wiki comments about > suggestions for changes on the wiki documentation at Apache Camel. > In my time I would guess its less than 10-20 comments I have seen for > that, in 3 years. > > On the other hand if people could send a documentation patch I would > assume we would have far more patches submitted to us, than the > current number of comments we get on wiki. > > And then for people to actually be able to edit the wiki page they > have to sign up for the ICLA which takes a fair bit of time and for > some people just scare them off. > > So I suggest out first goal is the transition to have documentation in SVN. > Then later we can work on a live web site for the people who may want > to try editing from the web browser. But again if some infastracture > software in the future can do this automatic, eg as James talks about > they work on github. Or if Atlassian is working on some software for > that as well, we can use at Apache. > > > >> Hadrian >> >> >> On Nov 10, 2010, at 9:46 AM, James Strachan wrote: >> >>> On 10 November 2010 13:40, Hadrian Zbarcea <hzbar...@gmail.com> wrote: >>>> Thanks James, >>>> >>>> You have to comment out the dependency on scalate-test in the pom for this >>>> to work (otherwise you get a "Failed to resolve artifact"). >>>> >>>> That aside, one of the important requirements I believe is not to raise >>>> the barrier to entry for those who want to contribute documentation. >>>> Today, one only needs to have a icla signed at apache and edit the wiki in >>>> place. How is this solved? >>> >>> Anyone can submit a patch using the traditional SVN mechanism just >>> like for patches to code or build files - or by forking the Camel >>> repository at Github.com, editing the entire website there and pushing >>> the change back to us. The benefit is folks can now do things like >>> grep & search/replace to fix up bad links or whatever. >>> >>> In either case, whether folks are committers or not, whether they use >>> our svn checkout or a git clone, folks get to edit the wiki files and >>> actually see what the website is really going to look like before they >>> commit/send a patch. Currently the only way to see how the site will >>> look after a documentation change is to make the change, then hope >>> that in a few hours AutoExport will re-render the page and the Apache >>> web cache will eventually refresh. If includes or navigation is >>> changed you usually have to wait for an administrator to run >>> AutoExport on the entire site... >>> >>> >>> -- >>> James >>> ------- >>> FuseSource >>> Email: ja...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: jstrachan >>> Blog: http://macstrac.blogspot.com/ >>> >>> Open Source Integration >> >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/
