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