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.
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
