openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Access to wiki
Date Sun, 07 Aug 2011 20:58:31 GMT
On Sun, Aug 7, 2011 at 4:12 PM, Ross Gardler <> wrote:
> On 6 August 2011 22:11, Rob Weir <> wrote:
>> On Fri, Aug 5, 2011 at 3:14 AM, Jean Hollis Weber <> wrote:
>>> On Thu, 2011-08-04 at 10:22 -0400, Rob Weir wrote:
> ...
>> Maybe I'm too skeptical,  but do we really have thousands of non core
>> project members dropping in for minutes at a time, adding information
>> on the architecture of OOo?  And build instructions? Looking at the
>> history of these pages, it looks more like this is core dev-enabling
>> information that should be part of the core project website.
> If there is *one* person who is unable to make that first, simple
> contribution then there is *one* person who the project cannot move
> from user to committer. Sustainable open source (managed under the
> Apache Way) is about maximising the number of people who can
> contribute. That is not the same as maximising the number of people
> who do contribute (although the latter will usually be a side product
> of the former).

Perhaps my point was not clear.  I was saying that for some areas of
the project, where it is important to publish authoritative, PPMC
approved information, that this should be CRT for committers, but RTC
for others.  That doesn't mean that we need to raise initial barriers
for contributors. It should be very easy to submit a contribution.
But it does mean that for some areas -- code being an obvious one --
we don't allow non-committers to change the repository directly.
Contributors are mediated via the review and approval of committers.
In parallel with that RTC cycle, we proactively identify potential new

There is nothing in what I said that suggests we should not encourage
contributions.  I only said that in some areas we should be careful to
establish PPMC oversight via the normal means.

Any objections to that in principle?

> I'd also suggest that the history of the project shouldn't dictate the
> future. I thought one of the concerns many people had about OOo in the
> past was that there were too many barriers to to contributions.

Some, certainly.  I don't know about "many".  For example, we had one
company that tried to make contributions under incompatible license
terms.  Sun refused to integrate that code.   Simon had a nice
rebuttal at that time, explaining the value of long-established
"community norms", even using Apache as an example:

> Of course, there needs to needs to be a balance between putting effort
> into enabling quick and simple contributions from everyone and getting
> on with doing work.

Unlike many Apache projects, the documentation with is
not merely supplemental, optional, nice to have, dispensable, etc.  It
is a core deliverable of the project.  As an end-user application, we
need end user documentation.  As an application that is deployed
broadly in large organizations, we need admin documentation.  As an
application with a rich macro language, we need app developer
documentation. And as an application that is extensible via plugins,
we need extension developer documentation.  Without this
documentation, is severely diminished.  So I do not
think we should think that discussion of documentation is opposed to
"getting on with doing work".

> Ross

View raw message