camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: helping out with the Web site
Date Wed, 10 Nov 2010 16:06:42 GMT
Now, that's not entirely true either.

Not all projects include the wiki documentation in the distro. That is the issue!
Since we do, everything in the distro must be AL2 and the IP tracked to original contributions.
A non committer must either submit a patch (which does not currently work for docs, because
there's no way to submit a patch for wiki content), or file the icla to edit the wiki.
For some of you how may not know, for significant contributions, even checking the 'grant
license to apache' is not sufficient, you need an ip grant.
Another thing, once you have an icla on file, you can edit *any* wiki at the ASF, afaik.

The barrier to entry today, for a small contribution is to check a checkbox and grant license
to the ASF. Not implemented for docs.
Next level is to have an icla on file, in which case you can edit the wiki in place, at will.
Next level apache account, committer access for both code and docs.

Eric, documentations *is* as important as the code, we all agree on that. My statement was
that we should not raise the barrier. This proposal has the potential to lower the barrier,
*if* we allow edit in place (for authenticated users) with a 'grant license to apache' checkbox.
I would love that.


On Nov 10, 2010, at 10:37 AM, Guillaume Nodet wrote:

> On Wed, Nov 10, 2010 at 16:29, Eric Johnson <> wrote:
>> I want to make sure I understand a few of the issues here:
>> We want to make it as easy as possible for people to make changes to
>> the documentation.
>> Before a person can edit the wiki they need to sign an icla.
>> We don't let anyone change the code who hasn't been vetted by the
>> community and made a committer.
>> New comers must have their patches vetted by a commiter before they
>> can be applied.
>> Any one who signs an icla can change the documentation or Wiki without
>> being vetted.
> That's not entirely true.  I mean, I don't think it's an ASF policy.
> Each PMC decides what to do with permissions afaik.  The only mandate
> is that contributions are done by people with ICLA or express grant
> (through JIRA patches).
> A lot of projects don't allow non committers to change docs.  Some do.
> The only difference is that in order to modify svn, you need an
> apache account, while you don't to modify confluence content.
>> If those statements are true I can see two issues:
>> 1. The barrier for entry on adding content is already relatively high.
>> 2. If the documentation is as important as the code, then why have the
>> barrier for entry be different? I say make it the same.
> Agreed.  i don't see why it would be different either.
>> The tooling question is a different story. Tech writers are a strange
>> bunch and may be scared by maven, version control, or text editors. It
>> would be nice to have less "developery" editing tools.
>> On Wed, Nov 10, 2010 at 10:15 AM, James Strachan
>> <> wrote:
>>> On 10 November 2010 15:00, Hadrian Zbarcea <> 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.
>>> "major community issue" is completely over the top IMHO.
>>> If it really is such an issue, maybe we should switch off subversion
>>> and put our source code on confluence too? We might get more
>>> contributions from people who can't use source control....
>>>> Documentation, as shown by the survey, is the #1 issue.
>>> and since we've had it for 3-4 years already, keeping Confluence is
>>> going to improve the documentation how?
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email:
>>> Web:
>>> Twitter: jstrachan
>>> Blog:
>>> Open Source Integration
>> --
>> Principle Technical Writer
>> Phone (781) 280-4174
>> Skype finnmccumial
>> E-Mail
>> Blog
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

View raw message