karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Karaf first birthday concall minute notes
Date Fri, 17 Jun 2011 09:12:32 GMT
Thanks for your feedback Claus.

It confirms that our current solution looks the right one !!

Maybe we can work on the documentation look and feel but it's another topic.

+1 to keep as we are now ;)

Regards
JB

On 06/17/2011 11:09 AM, Claus Ibsen wrote:
> Actually I envy Karaf since you have made the transition from
> confluence to scalate (eg docs in svn).
>
> Maintaining the Camel wiki documentation is becoming a problem with
> the sheer number of releases we have.
> It starts to become a lot of .. if you use Camel version X then bla
> bla, but if you use version Y then bla bla, or if version Z then bla
> bla.
> This is not convenient for end users of Camel to read the
> documentation in this manner.
>
>
> And since Camel 1.x is EOL we still have documentation that only
> applies for that release. Its frankly a big task to go over all the
> wiki pages and remove any obsolete documentation.
>
> And in terms of contributions by people who have edit rights to wiki
> pages and does some changes, then thats a very small number. Maybe
> once a month. Likewise with people who comment on the wiki pages.
>
> Instead having the documentation in svn is a big +1 IMHO. And I would
> love that we did this transition in Camel.
>
> And we had a discussion about this last year. And Hadrian wrote up a
> summary of that
> http://camel.apache.org/site-update-ideas.html
>
>
> On Fri, Jun 17, 2011 at 10:59 AM, Guillaume Nodet<gnodet@gmail.com>  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
>> <chris@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
>>>
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>

Mime
View raw message