retirement: feedback wanted

I recently made a proposal for retiring the GNOME wiki. I’m starting this thread to give an opportunity for more discussion and feedback.

As a conversation starter, some questions!

  1. If you have any concerns about the proposal: what are they?
  2. If you know of any wiki pages which it won’t be easy to migrate to any of the proposed alternatives: what are they?
  3. If you have any alternative ideas for where to migrate existing wiki content: what are they?
  4. If you want to be involved in future discussions about the wiki migration: please say!

The main concern I have is the amount of stuff I’ll have to migrate but potentially that’s also an opportunity to get rid of loads of cruft

I share a similar concern, but mine is that we might miss some stuff by accident. I reckon we need a way to make checklists (per namespace) with a way to indicate for each page where it’s been moved to, or whether it’s been intentionally left out as obsolete.

We also need to be careful with redirections. E.g. Apps - GNOME Wiki! has content, like links to subpages, but it quickly redirects to and now I can’t figure out to access the wiki page, including its wiki features like “Local Site Map”.

Out of interest - what content would you need to migrate, and where do you think you’d migrate it to?

Yeah, would be ideal to have all sub-pages moved before redirecting a parent page. I used the following as a workaround: Edit a different page, adjust the URL to the wiki page that you want to view, use preview feature if needed. Might come in handy during migration.

There’s basically Apps/Shotwell - GNOME Wiki!, Projects/Rygel - GNOME Wiki!, Projects/GUPnP - GNOME Wiki!

As to where to migrate that to… no concrete idea, something between gitlab pages, delete and static pages on the domains that currently redirect to the wiki for all the stuff that has no place on the suggested targets

1 Like

When we archive the wiki, we could potentially locate it at a different domain, like That way we could have redirects in place for the original locations, and still have access to all the old content.

1 Like

Just some general questions.

  1. Is the idea of a wiki a failure ( in 2023 ) ?

  2. How does wikipedia manage spam and is it possible to apply that in GNOME ?

That question probably deserves a topic of its own. :slightly_smiling_face:

They use different software (Mediawiki versus our Moinmoin), which is presumably hooked up to a proper authentication system (unlike ours). Theoretically, we could change that, by replacing Moinmoin with Mediawiki and/or integrating it with our authentication system.

However, I don’t get the impression that there’s much appetite to do that. Our sysadmin is stretched already, and there are other hosting issues with Moinmoin, so either doing integration work on what we’ve got, or replacing it with something else and then integrating that, is not very attractive.

A public facing wiki? Yes, demonstrably so.

By being Wikipedia:

  • paid staff
  • loads of volunteers
  • proper authentication
  • ad hoc software platform

The internet of the XXI century is a scary place, and handling spam is a full time job that cannot be replaced by a small group of volunteers in any appreciable way.


It would require rewriting the whole content of the wiki, because the wiki syntaxes are different.

Hypothetically speaking, if we were to set up a Mediawiki instance, I don’t think we’d want to migrate all our current wiki content over to it. I’d want to migrate the small % of useful content we have, and leave the rest behind. But then, I don’t think we want a Mediawiki instance…

I read that wikipedia uses bots to manage spam. Not sure how much % of spam management is shared between bots and staff / volunteers though. I get frequent notifications for donating to wikipedia ( and how few (100s) are managing the entire wikipedia ), so I think bots play a major role.

How do we handle things like hackfests and the like? We’ve been using the wiki as far as I know to provide a way to organize events. (eg who all is coming etc etc) I’m not 100% certain if it maps exactly with - we don’t really have a great mechanism for “upcoming events” - so I feel that is a gap.

Every GitLab project has its own wiki. Let’s encourage use of that. Then it’s just a matter of finding a suitable GitLab project to put the wiki page.


We can use HedgeDoc to set up the event attendance, travel, and agenda.

1 Like

The wiki is a good fit for hackfest organisation, and I’m yet to come across a direct replacement for this particular use case. Gitlab does have per-project wikis but, to my knowledge, there isn’t a way to grant blanket write access.

HedgeDoc is an interesting idea and does provide easy collaborative editing. Where it’s not so great is seeing who made what changes, and it’s not so great as an archive of previous events. Also you need a GNOME account to use it (though that would be true for some of the alternatives).

@sonny had an alternative idea to create a custom site for hackfest registrations.

Or the other option would be to go with Gitlab - have a hackfests project, and use either its wiki or issue tracker, and then be very liberal with granting access.

The board uses a lot of Wiki as you know @allanday ! :slight_smile: Publicly it’s where we store minutes, publish policies, committee memberships, etc. Privately we have other policies, draft and private minutes, and things like personal contact info. Do you have a sense of where all of that kind of stuff could/should live? I think a team/project wiki on GitLab doesn’t have the granularity of access control we’d need to have a private wiki-like corner.

What granularity do you need? Having a private GitLab project with a wiki that’s only accessible to people given a specific role under “Members” should be close to trivial.


Oh, I suppose that works. I hadn’t really thought about just making multiple projects. :person_facepalming: