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/
