corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: [DISCUSS] Wiki Authorization Policy
Date Thu, 25 Dec 2014 20:22:55 GMT
On 25 December 2014 at 21:11, Dennis E. Hamilton <>

> I notice there tend to be two flavors of wiki on ASF project,
>  1. Wikis that are limited to project committers (so pretty much as
> closely-held as the web site)
>  2. Wikis that are writable by anyone who sets up an account and then
> request write and editing permission from the project.  (This is different
> than a level of administrative access that allows granting of such
> accounts.)
> In the past there were fully-open Wikis, but it was discovered that lead
> to adulteration by spam and make curation too difficult.  So, instead, the
> fully-open Wikis, such as the AOO Community Wiki, were changed to provide
> authorization only upon request to the dev list.
> I favor (2) as a way to encourage community-participation.  There are many
> fully capable to contribute valuable content on wikis and forums and who do
> not have project-developer ambitions.  I prefer to see that kind of
> contribution encouraged.  Although Corinthia is looking more to
> tool-building than end-user interests, it still strikes me that having the
> wiki as open as practical is a good idea.
> Has any thought been given to this already?  What are the views on this?
> The 2 wiki solution is very special for AOO, and the reason was that AOO
came with a wiki (mediawiki), but needed another wiki while transfering to

I dont know any other projects that have 2 wikis.

We have currently only asked for 1 wiki (cwiki) and I highly agree with
your 2). I am currently space admin on our wiki, so when a user wants it I
can grant the person karma, I am also happy to share the space admin with
anybody who want to do it. Later we will need 1-2 admin (think of
moderator) who check newly created pages etc. to avoid spam.

The wiki is setup, so that users can create an account by themself, but an
admin need to grant them write karma.

jan i.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message