1 |
On Sat, Apr 3, 2010 at 16:19, Ben de Groot <yngwin@g.o> wrote: |
2 |
> 1 - requirements |
3 |
> ================ |
4 |
> |
5 |
> In order to choose the best possible wiki implementation, we need to |
6 |
> know our requirements. So what features do you think are essential or |
7 |
> good to have? What syntax would we prefer to use? |
8 |
> |
9 |
> I myself am a big fan of reStructuredText, which is quite simple, |
10 |
> easy to pick up, highly readable, and has a good featureset. Plus, it |
11 |
> is also reusable in other contexts (it is for example widely used in |
12 |
> documentation of Python libraries). MediaWiki, MoinMoin and Trac have |
13 |
> support for rst. |
14 |
> |
15 |
> Some others: |
16 |
> |
17 |
> - active upstream (bug fixes, security updates) |
18 |
> - free open source software |
19 |
> - ACLs |
20 |
> - spam prevention measures |
21 |
> - attachments (to upload screenshots for example) |
22 |
> - feeds |
23 |
There is currently a wiki for gentoo at gentoo-wiki.com, which is |
24 |
running MediaWiki, so it would be easiest to transfer the content if |
25 |
we were to run the same software. Now, this doesn't mean we should be |
26 |
limited by their actions, but it seems to me like the best choice for |
27 |
other reasons as well. Its syntax is probably the most well known, |
28 |
thanks to Wikipedia. Its upstream is active, it apparently scales and |
29 |
performs pretty well, it's GPL, supports translations/localization, |
30 |
feeds, attachments, etc. |
31 |
I'm sure many other alternatives are as qualified, so this is most |
32 |
likely a personal preference issue. As such, lets just agree on |
33 |
something that works and is widespread and go with that and avoid all |
34 |
the bikeshedding. |
35 |
|
36 |
> 2 - maintainers |
37 |
> =============== |
38 |
> |
39 |
> Who is volunteering for maintaining the wiki? We need editors and |
40 |
> moderators, people who look out for quality control and take care of |
41 |
> spam removal. So let's get together a team. I'm sure if we ask on the |
42 |
> forums we'll get some users interested as well. |
43 |
I volunteer. Spam shouldn't be that much of an issue if editing is |
44 |
restricted to registered users, but it is a good idea to have a team |
45 |
of moderators similar to the one that exists for the forums (of course |
46 |
users can take part of it as well as developers). |
47 |
|
48 |
> 3 - edit access |
49 |
> =============== |
50 |
> |
51 |
> Do we keep to the original "free for all" model, with all the spam |
52 |
> that includes, or do we go with registered users only? I think the |
53 |
> latter is the smarter option. I also think we will want to mark |
54 |
> certain pages "official" and lock down editing rights. |
55 |
IMO it's best if only registered users can edit (but registering |
56 |
should be easy, no bugs to file or anything, just sign up and use |
57 |
immediately). This will probably prevent most kinds of spam and allow |
58 |
for much better tracking of editing and history, allow for banning, |
59 |
etc. without closing the wiki up too much. |
60 |
Also, from what I could tell, this is how others are managing their |
61 |
wiki as well (Arch and Amarok, for example). |
62 |
|
63 |
Dror Levin |