Re: Migrate Wiki to Gitlab? (was: Migrating custom qemu.org infrastructure to GitLab)

[Daniel P . Berrangé]

On Fri, Oct 23, 2020 at 07:59:00AM +0200, Thomas Huth wrote:
> On 09/07/2020 12.22, Thomas Huth wrote:
> > On 09/07/2020 12.16, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >>>> 2. wiki.qemu.org is a MediaWiki instance. Account creation is a hurdle
> >>>> to one-time or new contributors. It is unclear whether GitLab's wiki
> >>>> is expressive enough for a lossless conversion of the existing QEMU
> >>>> wiki. Any volunteers interested in evaluating the wiki migration would
> >>>> be appreciated.
> >>>
> >>> Yeah, this is a potentially big piece of work. We didn't finish this
> >>> in libvirt either. Looking at the libvirt mediawiki though, I decided
> >>> not todo a straight export/import of all content.
> >>
> >> FYI: gitlab wiki is basically just a git repo with markdown pages +
> >> renderer + gui editor.  You can also update the wiki using git clone +
> >> edit + git commit + git push.
> > 
> > FWIW, seems like we could use the "pandoc" tool to convert Mediawiki
> > (our old Wiki) to Markdown (Gitlab wiki). I've done a quick test and
> > converted https://wiki.qemu.org/Contribute/MailingLists into
> > https://gitlab.com/huth/qemu/-/wikis/Contribute/MailingLists with some
> > few clicks.
> 
> Revisiting this topic after a couple of weeks, I think there is one more
> thing to consider: If I've got that right, your account has to be a member
> of the corresponding project to be able to edit a page in the Wiki in
> gitlab. So unless we want to add lots of persons to the qemu-project as
> members (which we likely do not really want, do we?), it's maybe better to
> keep the separate MediaWiki instance with the separate user accounts, I guess?

Yep, manual says it requires "Developer" permissions which is certainly
not something we want to give out widely, as it grants way too much
privilege.

I'd still suggest we look at folding the wiki into either the website or
the main repo documentation as appropriate for the docs in question.
Having 3 separate sources of documentation just feels wrong to me, and
we largely lost the "drive by" contributor for the wiki since we had
to lock new account creation - only a handful of people actually ask us
to create accounts for them.

The qemu-web.git could be made fairly low overhead for contributors by
accepting contributions via merge requests, which would let people just
interatively edit the web pages and submit the changes all from the web
UI. Not quite as seemless as a wiki, but not far off.

We could even demarcate a subset of the website with a /wiki URL and just
stuff all current wiki content in there as RST. Then have a much looser
review policy for merging changes in that subtree. Basically allow anything
as long as it is well formatted and not grossly incorrect. Could even 100%
automate approval under that subdir if you want the true wiki experiance
of having no content review.


The main downside with the main qemu.git documentation is that it takes
a long time to get docs through the contribution workflow and you have
to deal with the qemu-devel firehose. Use of RST has improved the authoring
part, but review/merge is still a bit tedious. There is no single docs
maintainer, and parts of docs are completely lacking maintainer entries.
So it can be pot-luck whether your docs contribution gets reviewed and
merged in reasonable time.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|