From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ny3ao-0006Kv-0D for garchives@archives.gentoo.org; Sat, 03 Apr 2010 13:40:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CDFA5E09CB; Sat, 3 Apr 2010 13:40:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 8BC07E09A2 for ; Sat, 3 Apr 2010 13:40:43 +0000 (UTC) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E32831B416B for ; Sat, 3 Apr 2010 13:40:42 +0000 (UTC) Received: by bwz2 with SMTP id 2so2348269bwz.10 for ; Sat, 03 Apr 2010 06:40:38 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.74.163 with HTTP; Sat, 3 Apr 2010 06:40:38 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Apr 2010 16:40:38 +0300 Received: by 10.204.156.213 with SMTP id y21mr4292185bkw.195.1270302038613; Sat, 03 Apr 2010 06:40:38 -0700 (PDT) Message-ID: Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki From: Dror Levin To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: dd274206-0c55-4a5d-b02c-9103f1c4779d X-Archives-Hash: 0a42c7baf7ce68f30516c5364b62c61f On Sat, Apr 3, 2010 at 16:19, Ben de Groot wrote: > 1 - requirements > ================ > > In order to choose the best possible wiki implementation, we need to > know our requirements. So what features do you think are essential or > good to have? What syntax would we prefer to use? > > I myself am a big fan of reStructuredText, which is quite simple, > easy to pick up, highly readable, and has a good featureset. Plus, it > is also reusable in other contexts (it is for example widely used in > documentation of Python libraries). MediaWiki, MoinMoin and Trac have > support for rst. > > Some others: > > - active upstream (bug fixes, security updates) > - free open source software > - ACLs > - spam prevention measures > - attachments (to upload screenshots for example) > - feeds There is currently a wiki for gentoo at gentoo-wiki.com, which is running MediaWiki, so it would be easiest to transfer the content if we were to run the same software. Now, this doesn't mean we should be limited by their actions, but it seems to me like the best choice for other reasons as well. Its syntax is probably the most well known, thanks to Wikipedia. Its upstream is active, it apparently scales and performs pretty well, it's GPL, supports translations/localization, feeds, attachments, etc. I'm sure many other alternatives are as qualified, so this is most likely a personal preference issue. As such, lets just agree on something that works and is widespread and go with that and avoid all the bikeshedding. > 2 - maintainers > =============== > > Who is volunteering for maintaining the wiki? We need editors and > moderators, people who look out for quality control and take care of > spam removal. So let's get together a team. I'm sure if we ask on the > forums we'll get some users interested as well. I volunteer. Spam shouldn't be that much of an issue if editing is restricted to registered users, but it is a good idea to have a team of moderators similar to the one that exists for the forums (of course users can take part of it as well as developers). > 3 - edit access > =============== > > Do we keep to the original "free for all" model, with all the spam > that includes, or do we go with registered users only? I think the > latter is the smarter option. I also think we will want to mark > certain pages "official" and lock down editing rights. IMO it's best if only registered users can edit (but registering should be easy, no bugs to file or anything, just sign up and use immediately). This will probably prevent most kinds of spam and allow for much better tracking of editing and history, allow for banning, etc. without closing the wiki up too much. Also, from what I could tell, this is how others are managing their wiki as well (Arch and Amarok, for example). Dror Levin