1 |
On 4 April 2010 01:37, Sebastian Pipping <sping@g.o> wrote: |
2 |
> Btw was it Fedora having moved from MoinMoin to MediaWiki? |
3 |
> I remember something like that, could be erring though. |
4 |
|
5 |
You are right. Here are some relevant links a quick Google search |
6 |
turned up for me: |
7 |
|
8 |
https://fedorahosted.org/fedora-infrastructure/ticket/31 |
9 |
http://fedoraproject.org/wiki/Infrastructure/WikiRequirements |
10 |
https://www.redhat.com/archives/fedora-infrastructure-list/2008-February/msg00085.html |
11 |
|
12 |
It looks like their main concerns were performance, both in terms of |
13 |
scalability and search (the default internal MoinMoin search engine |
14 |
is notoriously slow). Makes you wonder how Ubuntu manage to use |
15 |
MoinMoin apparently succesfully. |
16 |
|
17 |
The conclusion (in my eyes) is that MediaWiki is likely to be the |
18 |
best choice and easiest to set up for our purposes. Unless someone |
19 |
comes with another proposal and good arguments to go with something |
20 |
else, I'd say we should stick to MediaWiki. |
21 |
|
22 |
|
23 |
>>> Here's another idea: |
24 |
>>> The German Wikipedia uses a concept called "sighted revisions". If you |
25 |
>>> visit an article without logging in you will see the latest sighted |
26 |
>>> revision, as an identified user you can also view the latest revision. |
27 |
>> |
28 |
>> That's an interesting idea, which we should consider. |
29 |
> |
30 |
> I'm not sure if that a thing to go for. Drawbacks: |
31 |
> - More work (whereas we could use more manpower already) |
32 |
> - New bottlenecks |
33 |
> |
34 |
> Couldn't we just make two big "namespaces" |
35 |
> |
36 |
> 'devs' -- Developers only |
37 |
> 'registered' -- Full edit access to any registered user |
38 |
> |
39 |
> in the same wiki and have pages be in either namespace, reflecting the |
40 |
> namespace in the page name or path somehow? |
41 |
> |
42 |
> I expect that to be |
43 |
> - easy to implement |
44 |
> - providing a good mix of openness and quality control |
45 |
|
46 |
Actually this came up in earlier discussions as well, and there was |
47 |
an in my opinion valid concern about the status and quality of user |
48 |
generated documentation, especially if we open it to the wider public |
49 |
as we are proposing here. I think it would be a good thing to give |
50 |
certain revisions of a certain page an offical "stamp of approval". |
51 |
It would probably be educational to see how other distros handle |
52 |
that. Does anyone want to volunteer to find that out? |
53 |
|
54 |
>> GuideXML documents are often experienced as an unnecessary |
55 |
>> barrier. |
56 |
> |
57 |
> I think you should clearly state again that this is not gonna replace |
58 |
> GuideXML, just migrate a few use cases where a wiki fits better. |
59 |
> This is what you aim for, right? |
60 |
|
61 |
A wiki can fulfill several purposes for us: |
62 |
|
63 |
1. Easy collaboration among devs, for brainstorming, developing new |
64 |
documentation, assembling upcoming meeting agendas, and so on |
65 |
[for which there currently is not really any obvious place] |
66 |
2. A place for users to collaborate on and contribute to documentation |
67 |
[which is currently covered by the unofficial wiki] |
68 |
3. A place to host and maintain our existing documentation |
69 |
[which is currently in GuideXML] |
70 |
|
71 |
For me the most important and immediate need is number 1. This is the |
72 |
need that came up several times recently, and the push for me to try |
73 |
to make this happen. |
74 |
|
75 |
I am not pushing for our existing documentation to be migrated into a |
76 |
wiki at this point. But I think that once the place is there, and it |
77 |
functions well, it would be the obvious next step to do so. As I said |
78 |
before, the barrier to contributing and maintaining documentation is |
79 |
much higher in the case of GuideXML, so it doesn't really make sense |
80 |
to keep that around when we have a better solution. |
81 |
|
82 |
I know there are people who do not agree with me on this last point, |
83 |
which is why I see that as a later and separate goal. We can cross |
84 |
that bridge when we come to it. |
85 |
|
86 |
Cheers, |
87 |
-- |
88 |
Ben de Groot |
89 |
Gentoo Linux Qt project lead developer |