openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Refactoring the brand: Apache ooo + (was branding)
Date Tue, 02 Aug 2011 15:44:25 GMT
On Tue, Aug 2, 2011 at 11:21 AM, Dennis E. Hamilton
<> wrote:
> +1
> All wikis that accept public contributions (which is essentially all interesting wikis)
must be curated.  Ward Cunningham has provided the definitive exposition about that.
> I am sure we can find responsible contributors who will be eager to do that.  Maybe
some will need administrative access rights and we can require them to be project committers
as part of the extension of PPMC oversight and responsibility.
> But with regard to contributions of documentation pages, forums, FAQ, etc., the more
extended-community involvement that is encouraged by low-friction means, the better.

I think that is the key piece, determining what are the essential
documentation pieces (the pieces without which the project cannot
function and the users cannot make use of the releases) versus the
broader universe of supplemental material.

I hope we agree that there is some core part of the documentation set
that the project must provide more direct oversight of, and which we
need to ensure is under a license that permits downstream consumers to
copy, modify and redistribute.

That's all I'm asking for.  That we treat the core documentation as an
essential project asset and use those procedures that we routinely
apply to core project assets.

> In addition, wiki operation is very much in the Apache spirit already - there is no change
that can't be reverted (and, in many cases, the reversion consists of moving a copy of an
earlier version to be most-recent also, so history is never lost).  I have seen Wikipedia
lose history, but I assume that there are ways to avoid that with Wikimedia if we are careful.

It is funny when you read Obama's biography one day and read that he
was born in 1712.  It is not funny when you read an OpenOffice wiki
page and a see DOS command that instructs the unwary user to delete
their windows/system directory.

We need to make it clear what is core, trusted documentation versus
other supplemental material that we put a disclaimer on.  Untrusted,
unreviewed doc can do just as much damage as untrusted, unreviewed

> I think this can be worked out as we bring up with hosting on Apache infrastructure.
 We do not need a one-size-fits-all autocratic solution.

We need two sizes, right:  1) core documentation  and 2) supplemental.
 That was the idea if having two wikis in the first place.


>  - Dennis
> -----Original Message-----
> From: Reizinger Zoltán []
> Sent: Tuesday, August 02, 2011 07:45
> To:
> Subject: Re: Refactoring the brand: Apache ooo + (was
> 2011.08.02. 15:47 keltezéssel, Rob Weir írta:
>> On Tue, Aug 2, 2011 at 9:17 AM, Reizinger Zoltán<>  wrote:
>>> 2011.08.02. 14:03 keltezéssel, Rob Weir írta:
>>>> 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
>>>>>> users to be successful with our product, from end users, to admins,
>>>>>> 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
>>>>>> successful creating and hosting a new port or translation, or even
>>>>>> commercial derivative or an open source fork, of the project, then
>>>>>> 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.
>>> Rob,
>>> I think you lives outside of this world. You will not find a lot of
>>> contributors which needs to work with this idea.
>> I'm seeing it working exactly as it does now, with the difference that
>> the changes made by non-committers are not immediately visible on the
>> page until reviewed and approved by a committer.
>>> This will stop causal documentation contributors to enhance wiki page.
>> So you think that someone will refuse to contribute unless their
>> change is made available immediately?  Have you tried this?  Can you
>> back up your assertion that no one will contribute?
>> Take a look at the wiki logs right now:
>> What do you see?  Many new zombie accounts.  People updating their
>> User pages (not documentation) and a few real documentation changes,
>> most of which are made by Jean, who is already an Apache OpenOffice
>> committer.
>> So although I've seen claims that there are 35,000 user accounts, even
>> 15,000 real accounts, I'm not seeing a huge volume of changes.
> Fighting with spammers is a continuous work.
> No changes so much because OOo 3.4 was not out on time, and the no new
> features happens, it is an side effect of Oracle stopping work on OOo.
> See my rare contribution to wiki:
> Check it, the changes I've made during my contribution, worth for
> committer checks, who has not knowledge in Hungarian or OOo Base?
> Worth for waiting for approvals?
> Your idea to bring all user content under AL 2.0 will not help the users
> of OOo, it will hurt them, that is what my experience on tho OOo is saying.
> I see no further effort on this topic, your idea may be wrong.
> I not want to spend more time on this.
> I not see so much support on your side, only you forcing this idea.
> Time will tell that it will be useful or not.
> Zoltan
>> When I started working with wiki documentation, first I checked that the
>> written down text is working in OOo, and if I find something corrected the
>> text.
>> I did this when I found some time to work on wiki.
>> If the causal user meet barriers like every post wait for moderating for
>> committers they will lost their interest very soon.
>> What if the wait for review was only a day?
>>> May be you will have good managed and fully license compliant documentation,
>>> but fully out of date.
>> Again, what if aimed to delay the review/approval by no more than 1
>> day?  Certainly that would not be technically out of date.  Even if
>> the delay was a week it would not be out of date since releases come
>> only every couple of months.
>>> Zoltan
>>>> 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