incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Access to wiki
Date Thu, 04 Aug 2011 14:22:44 GMT
On Wed, Aug 3, 2011 at 10:32 PM, Jean Hollis Weber <jeanweber@gmail.com> wrote:
> I've got completely lost in all the mutations of the "Refactoring"
> thread, and don't recall all that has been said, so please forgive me if
> what I'm about to suggest has been dealt with already.
>

Thanks for starting a new thread.

> Two low-barrier methods I have seen work quite successfully on wikis,
> forums, and similar sites are:
>
> 1) People must ask for an account; they can't self-subscribe. Nothing is
> required except a few words about who you are and why you want an
> account. Any one of several people authorised to approve or reject these
> requests can deal with them expeditiously. Very few spammers, in my
> experience, take the trouble to actually request accounts.
>

I think it depends more on permissions than accounts.  So if the basic
user account allows you to write to a comment page, or "watch" a page
to be notified of changes, etc., I think these are actions we can
safely permit to anyone.  These are analogous to what a user can do on
any Apache list.  They can join the list, post to the list, ask
questions, submit (via the list) corrections to the website and
patches to the code, for review.  What they cannot do is change the
website and code directly.  Those rights are reserved to committers,
those who are trusted to do those tasks and elected by the PPMC.

So the wiki is a different tool.  It makes some things easier.  The
"affordances" of a wiki (as the design people would say) is the easy
ability to do collaborative editing of hypertext.  But the qualities
of the tool should not (IMHO) change our fundamental orientation to
the different roles of contributors and committers. Of course, these
roles will map differently to different tools, based on the
capabilities of those tools.  But the roles are part of how Apache
works.

So I think you are asking the right questions.  One useful way of
thinking of it (to me at least) is asking how the capabilities of the
tool map to Apache Project roles:

1) User
2) Developer (also called Contributor)
2) Committer
3) PMC member

See: http://www.apache.org/foundation/how-it-works.html#roles


> 2) Alternatively, or in addition, the first X edits/ contributions/
> whatever are moderated by a group of people, any one of whom can approve
> or reject the items. After X acceptable contributions, the person is
> then allowed to edit the wiki without further supervision -- until or
> unless they start posting inappropriate material such as spam. Again,
> very few spammers will take the trouble to post some useful info before
> going into spam mode.
>
> These methods deal with the vast majority, if not all, of the concerns I
> have seen Rob expressing about systems with no control at all, but at
> the same time they do not require more time or commitment on the
> contributors' part to be authorised to participate.
>

The other set of concerns I had was with respect to content license.
Today we seem to have a mix of 4 different licenses for contributed
content, as well as content that does not have any evident license
attached to it.  I realize cleaning up the past is nearly impossible,
But is there anything we can do better going forward?

In particular, please note that I'd like to encourage IBM
contributions of documentation to the project, along with our Symphony
work.  For example, we have doc related to enterprise deployment and
this is applicable to OpenOffice as well as Symphony.  But if we
contribute this under Apache 2.0 and then it is edited by anonymous
(or pseudonymous) users who have not signed the iCLA, then our
contributions can be immediately contaminated by unlicensed (or
incompatibly licensed) changes, making it impossible for us to use
future revisions of own doc.  As you can imagine, that would make it
very difficult for us, or any other corporation, to collaborate on
documentation.

So that's the essential trade-off.  If we require iCLA for substantial
content contributors, then you will cause some contributors to stop
participating  But if you don't require an iCLA, then you will inhibit
participation from corporations.  And note that this is true for all
reusable content in the project.  So code, help, documentation and
translations.  If we want participation from corporations then we need
to have the means to establish and maintain the pedigree of the
contributions under a consistent license (or set of compatible
licenses).


> AFAIK, most wikis & similar sites provide some way to limit the editing
> of specific pages to a smaller group of people (admins or whatever).
>
> --Jean
>
>
>
>

Mime
View raw message