incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Refactoring the brand: Apache ooo + (was branding)
Date Tue, 02 Aug 2011 15:21:39 GMT
Umm, the proposal page for this incubator project was on a public wiki site and was publicly
edited.  While there were some mistakes in the course of that, it all worked out didn't it?

The project home page is where it is.  That's a straw man (just like the one I just gave).
 It is not on and it won't be, it seems to me.  It is in the Apache ooo space.

I propose that we do this on an individual-case basis as we migrate/blend/divide/whatever content and content.

I propose that we do *not* drop the iCLA hammer on everything to do with and
we should deal with this on concrete terms when we have cloned the content of
ready to reopen under new management but with the same welcoming face to the public.

I don't accept that there has been any harm in the handling of provenance on
although it certainly could have been done better.  In fact, keeping it the
site is probably the easiest way to avoid sticky permission problems.  Of course, if any contributors
want their material taken down, we should happily comply.

I wouldn't even add the Apache license to the pages.  The Creative Commons attribution license
seems perfectly fine there and we should not mess with it.  The copyright notice I would leave
to sharper minds than ours.

 - Dennis

-----Original Message-----
From: Rob Weir [] 
Sent: Tuesday, August 02, 2011 07:53
Subject: Re: Refactoring the brand: Apache ooo + (was branding)

On Tue, Aug 2, 2011 at 10:32 AM, Dennis E. Hamilton
<> wrote:
> -1
> I don't understand why there is continued pressing that things not in a release have
to be treated as if it requires the same treatment as the content of a release.  I thought
we had worked a high-level sketch of the user documentation case with Jean Hollis Weber some
time ago on this list.

That was something else entirely,, a site that is
external to Apache.  We're not discussing that right now.  What we're
discussing is the content at, which we
are planning to be part of the Apache OpenOffice project. Two
different things.

As for "in release" versus "not in a release", I'll pose a question:
Should we allow anyone to directly edit the project home page, even if
they are not a project committer?  Why not?  It is not "in a release"?

We should be trying to build a an open source release that anyone can
use, modify and redistribute, according to the Apache 2.0 license.
The fact that some pieces are in the source tarball and other pieces
are on the website is irrelevant.  We prevent others from making full
use of our code if we do not allow them to also make full use of
essential documentation.

> There are cross-over cases, such as authoring of what will be embedded help (in many
languages) and also the support for on-line help.  But even for on-line help it would be great
if it could be community-augmented.

I agree,  Everything at Apache is built by the community, including
the source code.  We encourage contributions from all, including
committers, of course, but also patches from users and other
interested parties.  But all such patches are reviewed and approved by
project committers.

> All we're accomplishing here is guaranteeing that the only well-written documents and
congenial forums for users will carry the LibreOffice logo.
> We already have two separate wikis, one that the community uses and one that requires
committers to make the changes.  I notice the second one is not getting much activity.

And I'm not seeing a lot of activity at the wiki either:

What does that prove?

> I think this stance is too heavy-handed in an area where there is no demonstration of
harm and a great need for community engagement.  We need to be flexible here, and quickly

The harm is to the ability of downstream consumers to copy, modify and
redistribute the documentation.  The lax attention paid to this
concern by is responsible for the nebulous state of the
IP in the wiki's content today.  That harm has already been done.  I'd
like to prevent that harm from continuing.

>  - Dennis
> -----Original Message-----
> From: Rob Weir []
> Sent: Tuesday, August 02, 2011 05:04
> To:
> Subject: Re: Refactoring the brand: Apache ooo + (was
> On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber <> wrote:
>> On Mon, 2011-08-01 at 21:24 -0400, Rob Weir wrote:
>>> I'd look at it like this:  The documentation that is needed for our
>>> users to be successful with our product, from end users, to admins, to
>>> application developers, that documentation is product documentation.
>>> If having it deleted or defaced, without us noticing it, would cause
>>> our users some harm, then it is product documentation.  If the right
>>> to copy, modify and redistribute the documentation is essentially to
>>> successful creating and hosting a new port or translation, or even a
>>> commercial derivative or an open source fork, of the project, then it
>>> is product documentation.
>> Leaving aside for the moment all the other user-doc type items on the
>> wiki, and looking specifically at the existing current set of user
>> guides (which are in ODT/PDF format, but made available for download
>> from the existing OOo wiki), I'm unclear how they will fit into this.
>> They are not currently under the Apache license, and we would never be
>> able to track down all the contributors to get them to agree to the
>> license and/or sign the iCLA. So are we talking only about future
>> updates to these docs? And if so, do you mean that every future
>> contributor to these guides during their production must sign the iCLA?
>> Or just that only someone with suitable access rights (committer?) can
>> put them on the wiki (in ODT/PDF format)? Or something else?
> I'd like us to treat documentation like we do code.  Not necessarily
> the same tools, but the same care for provenance, accountability and
> quality, namely:
> 1) We welcome "patches" and "contributions" from anyone, but these
> must be first reviewed and approved by a project committer before they
> become part of the documentation set.  Any such contributions must be
> made under Apache 2.0 license.
> 2) Only project committers have direct write access to the
> documentation.  This requires that they first sign the iCLA.
> 3) All contributions, whether from the public or from committers and
> tracked/logged, so we can accurately determine who made a given
> change.  So no anonymous or pseudonymous patches.  A user id that we
> can trace to a real email address is fine.
> With code this works by non-committer contributors sending patches
> (diffs) to the mailing list, where they are merged in and reviewed by
> a committer, and then checked into the repository.  With
> documentation, using a wiki , we would need a different mechanism for
> achieving this.  Luckily there are MediaWiki extensions to enable
> this.
> I'd like to preserve the immediate nature of editing on the wiki.
> That is its strength.  But we need to find away to also get this under
> project oversight as well.  I think we can do both, without too much
> annoyance to contributors.
>> --Jean

View raw message