WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-users] Re: [Xen-devel] Xen document day (Oct 12 or 26)

To: Florian Heigl <florian.heigl@xxxxxxxxx>
Subject: Re: [Xen-users] Re: [Xen-devel] Xen document day (Oct 12 or 26)
From: Lars Kurth <lars.kurth@xxxxxxx>
Date: Tue, 01 Nov 2011 02:17:55 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Andrew Bobulsky <rulerof@xxxxxxxxx>, Joseph Glanville <joseph.glanville@xxxxxxxxxxxxxx>, "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 31 Oct 2011 19:19:00 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1Cc2Dqe9jae/Rhm1vY30NTPMGirHyjNlR7NfCRc9KYA=; b=wDvQRRqdnzOXemlFXAj3SctoOiMoIP4Vsm20Kk604vsnX1hjt5t+0mnMwwnkFwCtOB UKaGKhVmoIeTwt832ouoJx+vUrVXe+AuuUREuGIuEucchPCFhe1ygU2PCVKIz8YQFaSS AAC3TGtEiTdGZayZ8Be77TWnNKYnPDUJLk1/4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAFivhPk7Pk4DWHeDVTWvV26vQqU0-pqUqvV3GNx5JBDShQW85g@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E92D809.9000504@xxxxxxx> <20111010160404.GB28646@xxxxxxxxxxxxxxxxx> <4E946EB9.7050209@xxxxxxx> <CAOzFzEhU3YJtzyJn7rcUXUmwz+PhaxRsKQaYU+2-eHrv-LyD6g@xxxxxxxxxxxxxx> <20111013180244.GC15499@xxxxxxxxxxxxxxxxx> <5400260811821008556@unknownmsgid> <1318859996.16132.16.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E9C4516.2070902@xxxxxxx> <1318864667.16132.22.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E9C4BAB.9020605@xxxxxxx> <20111026195543.GA6558@xxxxxxxxxxxxxxxxxxx> <4EA932D5.3060504@xxxxxxx> <CAOzFzEiTzSDABmtJw3u+jow5Xw_wRYNxFr9U_G-q59-Qwv7j=g@xxxxxxxxxxxxxx> <4EAAA467.2030503@xxxxxxx> <CAFivhPk7Pk4DWHeDVTWvV26vQqU0-pqUqvV3GNx5JBDShQW85g@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
Note that mediawiki allows pages to be in several categories. Check out http://en.wikipedia.org/wiki/Special:Categories

 I think the main issues (mess) with the old wiki were:
 - not being able to contact someone if information is incorrect / outdated
We would need category and page owners for this. I will have to think about 
this.

 - noone looking into pages that had become outdated
Agreed. I think we also faced the issue that we didn't know what was outdated. 
That makes fixing it a harder problem

 - not looking for pages that might be outdated
Categories and attention boxes should help

 - most of the pages being immutable so you couldn't even fix stuff.
That is a MoinMoin feature (which should be resolved with MediaWiki). The 
MoinMoin spamming protection is extremely primitive.

 So if we limit edit rights to certain user groups that is not a
 problem, as long as the groups are big enough to maintain the
 categories.
MediaWiki has quite fine grained user control. I will have to think about how 
to set this up, but my gut feel is we should have:
- Admins
- Editors (get notified when people make changes, owners of categories)
- Authors (anybody with an account)

 Also it might be helpful to use a release mechanism - if any
 registered user can create pages, but they stay invisible until
 approval then this would save a lot of time for the regular authors
 and still keep up quality. (Thats working really well in my
 experience)
I think that is not advisable. I rather go for the WikiPedia approach, where 
wrong changes are reverted by editors. I think we should try with an open model 
and make it more restrictive it the open model doesn't work

Regards
Lars


On 30/10/2011 20:58, Florian Heigl wrote:
Hi Lars,

2011/10/28 Lars Kurth<lars.kurth@xxxxxxx>:
There may be a few more. Will need to work on these a little more. It may
also mean that the MediWiki instance is set up that pages must have a
category and that only a subset of users can create new ones. Otherwise we
get into the same mess again.
I think the main issues (mess) with the old wiki were:
- not being able to contact someone if information is incorrect / outdated
- noone looking into pages that had become outdated
- not looking for pages that might be outdated
- most of the pages being immutable so you couldn't even fix stuff.

So if we limit edit rights to certain user groups that is not a
problem, as long as the groups are big enough to maintain the
categories.
Also it might be helpful to use a release mechanism - if any
registered user can create pages, but they stay invisible until
approval then this would save a lot of time for the regular authors
and still keep up quality. (Thats working really well in my
experience)

Greetings
Florian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel