JB, Guillaume, this is all very true and I think it is the best solution for it right now. I only think that we need to improve on the documentation.
1) Add the current trunk-documentation --> the nightly build should somehow generate it and add it to the page or something the like :-) 2) Some special pages, like contributor and the roadmap need a better "place" in the page. Thanks, Achim 2011/6/17 Jean-Baptiste Onofré <j...@nanthrax.net>: > Thanks Guillaume, > > you mentioned some points I forgot ;) > > Regards > JB > > On 06/17/2011 10:59 AM, Guillaume Nodet wrote: >> >> There are also lots of benefits of not using cwiki: >> * ability to work offline (that's really a problem with confluence) >> * ability to experiment using branches >> * ability to version documentation easily >> * ability to modify several pages at once >> * ability to better track contributions >> >> On the last one, I actually think giving people modification rights is >> not necessarily a good idea. >> People should be able to become committers but simply contributing >> doc. Do you monitor all the doc changes on cxf / camel made by non >> committers ? And actually, how many modifications are we talking about >> ? >> >> Last, we had a vote on that a few months ago, so please go read the >> discussions, as Jean-Baptiste explained, we had some discussions and >> came to a conclusion ... We were using cwiki until a few months. >> >> On Fri, Jun 17, 2011 at 10:19, Christian Schneider >> <ch...@die-schneider.net> wrote: >>> >>> I know that I have proposed this before and then got the answer that this >>> was discussed already. Still I have the feeling that everybody dislikes >>> the >>> current way we build our website.... so again a try :-)... >>> >>> I would even go a step farther and do as much of the website on the wiki >>> as >>> possible. Dan Kulp has written an exporter script that syncs the wiki to >>> static pages so the admins can live with it. >>> >>> I think we have to try to make the website and documentation as open as >>> possible. The wiki allows us to give editing right to anyone with a valid >>> icla. That is much more accessible than the current site. >>> Additionally any change can be seen right after the change on the wiki. I >>> think that is a big motivation. Currently you have to submit a patch for >>> the >>> website and wait for someone to commit it and then for someeone else to >>> sync >>> it to the web. This process can take months sometimes. That is quite >>> frustrating and I am sure it is the reason why we have so few updates to >>> the >>> site and documentation. >>> Another nice thing of the wiki is that it is a first step of contribution >>> below submitting patches. So people can come in contact with the project >>> gradually. >>> >>> Of course the wiki has the problem that it is not synched to the releases >>> but in cxf and camel this is also not the case. Still it works well >>> there. >>> The way to couple the documentation to releases is to note for example >>> which >>> attribute of a command has been introduced in which version. This is niot >>> perfect but works quite well in practice. >>> >>> Christian >>> >>> >>> Am 17.06.2011 09:46, schrieb Jean-Baptiste Onofré: >>>> >>>> Agree Andreas, >>>> >>>> I think that: >>>> - link to the wiki "cap" page in the community area of the website >>>> - wiki pages as children of the "cap" page >>>> >>>> is the most efficient way. >>>> >>>> Regards >>>> JB >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >> >> >> > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
