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 events.gnome.org - 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.
2 Likes
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.
2 Likes
Oh, I suppose that works. I hadn’t really thought about just making multiple projects. 
That’s also what I also had in mind for the private board docs. The public docs could go on any of the following:
- the new GNOME handbook docs site
- the foundation website
- a new docs site just for board documentation
The other potentially problematic case which hasn’t been raised so far is team documentation, like for i18n, docs, engagement and design.
Group-level wikis in Gitlab would have been the perfect solution for this, but unfortunately they are an enterprise feature. The only alternatives I currently have are:
- Team READMEs, like the design team has
- A project within a team’s Gitlab space that is used for docs (either through its wiki or in-tree docs in the repo)
- Individual team docs sites (probably using Sphinx, like we do for developer docs and the HIG)
However, none of these are ideal. Team READMEs are hidden at the bottom of the page, and are just a single page. Dedicated docs projects in Gitlab are awkward from a navigation and discoverability perspective. Docs sites are OK if you have a lot of docs to maintain, but there’s obviously additional work involved in creating and maintaining them.
1 Like
I’ve also been working on a first draft of the handbook site. The latest version can be seen at Home - GNOME Project Handbook documentation , and the project is Allan Day / GNOME Project Handbook · GitLab .
I think that the handbook will be more or less ready to move on to the wiki transition proper, once it’s moved to a team space in Gitlab.
2 Likes
My thoughts for this migration are:
On wikipedia (or other wikis), changes are reviewed after they are made, and contributors are told to “be bold”.
This introduced the spam and edit-war problem on the wiki.gnome.org instance.
For important pages and information, it’s a good thing that changes are intended to be reviewed first before being applied. But it can be an hindrance for fixing trivial things such as a broken link or typos.
In any case, the parts of wiki.gnome.org that are replaced by another mini-wiki (wiki located in a GitLab project) won’t suffer from the spam problem because it’s hosted on GitLab. But changes are still reviewed after-the-fact there (the workflow won’t change).
Another thought that I have is that it’s going to be a lot of migration work. For some teams that already lack man power, this can be seen as something not desirable. So like the bugzilla to GitLab issues tickets migration, an automatic tool to convert the wiki pages to something else would solve that problem.
Another thing, in all cases the MoinMoin syntax is less friendly than Markdown or reStructuredText, as already said.
So migrating things is well worth it, even if it takes time.
For teams with a lot of pages to migrate (and which lack the man power), let’s not rush things. For example if a warning message about the wiki being deprecated is added to all pages of the wiki, this would not be a pleasant experience. My suggestion is to add the warning message when editing a page, not in the page content itself.
My 2 cents 
Hi,
Maybe a tool like pretalx would be a nice fit for organizing events?
I mean we have an indicio for that - and while that’s a tad weird, it serves the job I think.
In lieu of that, has anyone a recommendation for a hugo theme (or any other static content generator, for that matter) that does not look too bad but also does not bring in half a ton of dependencies?
The design team has produced some simple static sites that might be of interest: Websites · GitLab. Or it’s easy to create your own Sphinx project if you want something for docs.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.