openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Refactoring the brand: Apache ooo + (was branding)
Date Tue, 02 Aug 2011 14:39:30 GMT

On Aug 2, 2011, at 7: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.
> 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.
> 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.
> 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

+1 - Let's listen carefully. We don't have to have all the answers immediately and we don't
need to drown in slew of emails.


> - 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