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 apps.gnome.org and now I can’t figure out to access the wiki page, including its wiki features like “Local Site Map”.
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.
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
When we archive the wiki, we could potentially locate it at a different domain, like wiki-archive.gnome.org. That way we could have redirects in place for the original locations, and still have access to all the old content.
That question probably deserves a topic of its own.
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.
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.
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 events.gnome.org - we don’t really have a great mechanism for “upcoming events” - so I feel that is a gap.
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 ! 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.
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.