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
