On 4 April 2010 01:37, Sebastian Pipping <firstname.lastname@example.org> wrote:
> Btw was it Fedora having moved from MoinMoin to MediaWiki?
> I remember something like that, could be erring though.
You are right. Here are some relevant links a quick Google search
turned up for me:
It looks like their main concerns were performance, both in terms of
scalability and search (the default internal MoinMoin search engine
is notoriously slow). Makes you wonder how Ubuntu manage to use
MoinMoin apparently succesfully.
The conclusion (in my eyes) is that MediaWiki is likely to be the
best choice and easiest to set up for our purposes. Unless someone
comes with another proposal and good arguments to go with something
else, I'd say we should stick to MediaWiki.
>>> Here's another idea:
>>> The German Wikipedia uses a concept called "sighted revisions". If you
>>> visit an article without logging in you will see the latest sighted
>>> revision, as an identified user you can also view the latest revision.
>> That's an interesting idea, which we should consider.
> I'm not sure if that a thing to go for. Drawbacks:
> - More work (whereas we could use more manpower already)
> - New bottlenecks
> Couldn't we just make two big "namespaces"
> 'devs' -- Developers only
> 'registered' -- Full edit access to any registered user
> in the same wiki and have pages be in either namespace, reflecting the
> namespace in the page name or path somehow?
> I expect that to be
> - easy to implement
> - providing a good mix of openness and quality control
Actually this came up in earlier discussions as well, and there was
an in my opinion valid concern about the status and quality of user
generated documentation, especially if we open it to the wider public
as we are proposing here. I think it would be a good thing to give
certain revisions of a certain page an offical "stamp of approval".
It would probably be educational to see how other distros handle
that. Does anyone want to volunteer to find that out?
>> GuideXML documents are often experienced as an unnecessary
> I think you should clearly state again that this is not gonna replace
> GuideXML, just migrate a few use cases where a wiki fits better.
> This is what you aim for, right?
A wiki can fulfill several purposes for us:
1. Easy collaboration among devs, for brainstorming, developing new
documentation, assembling upcoming meeting agendas, and so on
[for which there currently is not really any obvious place]
2. A place for users to collaborate on and contribute to documentation
[which is currently covered by the unofficial wiki]
3. A place to host and maintain our existing documentation
[which is currently in GuideXML]
For me the most important and immediate need is number 1. This is the
need that came up several times recently, and the push for me to try
to make this happen.
I am not pushing for our existing documentation to be migrated into a
wiki at this point. But I think that once the place is there, and it
functions well, it would be the obvious next step to do so. As I said
before, the barrier to contributing and maintaining documentation is
much higher in the case of GuideXML, so it doesn't really make sense
to keep that around when we have a better solution.
I know there are people who do not agree with me on this last point,
which is why I see that as a later and separate goal. We can cross
that bridge when we come to it.
Ben de Groot
Gentoo Linux Qt project lead developer