Hi Rob,

(comments inline)

Rob Weir schrieb:
On Mon, Aug 1, 2011 at 10:38 PM, Jean Hollis Weber<[email protected]>  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.

I don't agree. It is the nature of a wiki, that the content is not approved before, but by ongoing editing.

  Any such contributions must be
made under Apache 2.0 license.

In http://www.ooowiki.de/ we have the license information on the start page and in the header of each editing mode page. Submitting a change automatically agrees to the license. Wouldn't it be possible to do it the same with the Apache 2.0 license?


2) Only project committers have direct write access to the
documentation.  This requires that they first sign the iCLA.

That is a very formal action. So most people will not do it. But they might write some tips and tutorials.


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.

Isn't it possible to set up the wiki in a way, that only registered users can write? That is already a hurdle, but I would accept it.


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.

That is fine for all things, which belong to the product binaries and to the sources, but not for the wiki content.

  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.

We need no such formal mechanism like signing up a iCLA, but groups of people who feel responsible for special parts of the wiki. For example, compare the pages belonging to http://en.wikipedia.org/wiki/Portal:Statistics with the corresponding ones in other languages. The better quality of the English ones are not due to a formal mechanism of contribution and pre-approving, but because the people in the group http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Statistics care for the pages. It is still possible for everyone to edit the content of the wiki pages.

Kind regards
Regina



Reply via email to