Status of the GNOME wiki

Community
1

https://wiki.gnome.org/AccountsTeam/NewAccounts is not accurate.

Can i get access to a wiki account ? I’ve been trying to get it for quite sometime without success, which is sad.

Thanks!

2

Why?

You need an account and you need to be added to the trusted editors group, which was created as an anti-spam measure.

In general, though, you should not edit pages under a specific team unless you’re also part of that team.

3

Commit access will be granted only with an existing GNOME maintainer vouching. It’s the actual policy and way of doing things since 15 years - @averi

It is not mentioned in the prerequisites section below:

Pre-requisites

We do request that applicants have submitted a reasonable number of patches to an existing maintainer, or GitLab issues before they request direct commit access.

I think we need to update things a bit here. GNOME discourse is very good in that sense, as users contribute, it continuously adds extra badges and privileges, which is excellent.

Some people are comfortable asking for access to others, while others aren’t. In such cases, we can offer automatic access unlocking ( for wiki etc ), if the user makes a reasonable contribution to the GNOME community.

I checked with @averi regarding wiki update.

Thanks!

4

Then you can also ask Andrea to fix the page, since he’s on the Accounts team. :wink:

The only way to change things is to drop the wiki, which is somewhat problematic. Discourse is not a wiki, even if you can turn topics into “wiki-like” pages. The content we currently have on wiki.gnome.org cannot be automatically migrated elsewhere, which means it’ll require a manual step for editing and importing elsewhere.

In any case, this warrants more discussion.

5

I’ve heard this argument in another topic, which I don’t remember.

What’s the reasoning to move in a direction to drop the wiki ?

Thanks

6

“Drop” as in “replace”. We cannot disable the current anti-spam measure because the wiki generates a ton of spam, and requires an almost full time editor to ensure things don’t get out of hand. The only way to avoid this would be to move to a different wiki, with a different set of moderation tools—though, even in that case, it’s unlikely we’re going to get less spam.

Alternatively, we could have wiki hosted on GitLab, though that comes with its own set of problems: wikis are per-project, instead of living in a global namespace; editing is reserved to people in the same group as the project; wikis do not follow the same process as a merge request; and it would still require auditing and editing all content on wiki.gnome.org from MoinMoin wiki syntax to markdown.

1 Like
7

Okay.

This should be an issue for all open source communities. Any idea how other communities go about this ?

PS: Can we split this wiki discussion into a separate topic.

8

I have no idea, and if I can be really blunt, I don’t particularly care.

If you want to start looking, feel free to do it and create a proposal and present it to the docs team.

9

Sure, when I get time.

But if we have a docs team, shouldn’t they be working on this ? :slight_smile:

10

It’s not the only thing they have to do, and they could always do with more volunteers.

11

Okay.

One more thing. Since all apps have wiki.gnome.org hard coded in their code, I guess any solution would imply a HTTP redirect to the new doc page.

Even if new package versions update the links in code, there will always be older version of the package which will have the old links, as the distribution package maintainers don’t patch old packages in their stable and old stable repo, unless it is really critical.

12

Projects have already begun moving away from the MoinMoin wiki…

Some preferring to use GitLab wiki – e.g. https://gitlab.gnome.org/GNOME/gnome-build-meta/-/wikis/home. We lose the global ‘recent changes’ and ‘search’ features when this happens – but surely we can recreate these inside GitLab? Searching a few 1000 webpages is not an advanced tech problem :slight_smile:

In Tracker we are trying to move as much content as possible into the project’s Git repo, and publishing it to GitLab Pages. It makes sense in this case because the Tracker wiki mostly holds docs, which is mostly way out of date as developers forget it exists and it doesn’t appear in git grep.

A lot of the coordination that happened under https://wiki.gnome.org/GUADEC seems to have moved to https://gitlab.gnome.org/Teams/Engagement/Events/GUADEC

Initiatives have moved to https://gitlab.gnome.org/GNOME/Initiatives

You can use https://wiki.gnome.org/RecentChanges?max_days=60 to get a good idea of who is actually still using the wiki. My suggestion would be to go with the trend of what we already doing, and focus on making GitLab easier to search and monitor for recent changes so that we don’t lose the benefits we had when GNOME all shared the same wiki.

13

GNOME packages currently point to the wiki.gnome.org, which looks like a normal documentation site - meaning just documentation and documentation related operations ( search text / search title etc ).

While I like Gitlab very much, I am not sure if moving documentation to Gitlab for desktop users to view them there is a right choice. Gitlab has a lots of menu and options, which have nothing to do with the documentation being displayed, for a user who just landed there to read some help page.

Thanks!

14

Sorry, I missed a point here.

  1. We’re getting “a ton” of spam in-spite of the huge access restrictions in GNOME wiki ?

  2. We cannot move to any other doc solutions because they’ll have the same issues as [1]

  3. Gitlab works better, because Gitlab doc pages are git commits which are reviewed before publishing, thereby avoiding spam to a great extent ?

In that case, can we go with [3], which publishes content from gitlab.gnome.org to wiki.gnome.org as part of a nightly job, while maintaining GNOME wiki as read-only.

Thanks!

15

No, we get a ton of spam if we relax the access restrictions we currently have in place. Those restrictions were added precisely because of the spam.

Other wikis have spam problems too; other wikis may have better tools to reduce them than adding a very strong ACLs, or maybe they have a larger amount of volunteers that can police the content and revert spam.

Contributions to GitLab pages are subject to the same mechanisms as code contributions. Access is reserved to those who have a GitLab account, and can create a merge request. This is, ostensibly, a restricted ACL that is fairly similar to having an additional ACL on top of a wiki.

That’s not really how anything works.

Yes: we can turn the current wiki into a static website that is backed by a GitLab repository. It would not be a wiki any more, though, which has its downsides in terms of barrier of entry and contributions.

16

Sorry, if no spam issue now, they why replace GNOME wiki in the first place ?

I noticed a lot of spam in gitlab snippets couple of weeks back, so I guess we’re never immune from a very determined spammer. The only thing we can guarantee with our resources, is to minimize as much spam as possible, and absolutely no spam in pages which are reachable by most users.

17

Assuming we’re using MoinMoin wiki from Sam’s above comment:

MoinMoin from wikipedia.

"MoinMoin faces a supportability gap in 2020, based on the January 2020 deprecation of Python 2.7. The current release of Moinmoin, 1.9.10, is written in Python 2.7 and is not slated to be ported to Python 3. Moinmoin 2.0, based on Python 3.5, is not yet released (as of Aug. 2019), and "development is very slow going," according to their Python3 support page.[5] Installation of Moinmoin 1.9.10 now yields multiple warnings of this deprecation. "

So, good signs to move away from it I guess.

Some alternatives, if we’re looking for a wiki based solution:

Thanks!

18

You suggested that the access control should be easier, that seems only solvable by moving away from MoinMoin. I looked again at the v2.0 branch, development seems to be slow, still. We could theoretically reach out, I guess the developer is (like everyone) looking for additional developers/assistance.

The spam on the GNOME Wiki used to be small, until it grew and grew. Eventually there was no other option than to have new accounts manually approved. The spammers aren’t just using bots btw, it was obvious they manually created accounts. Once the account is manually created they spammed the entire site using bots.

Moving away is not easy. The syntax is likely different, often there are no migration tools, etc. It’s a huge task that (if you want to do it right) will likely take months of work (creating migration tools, etc). There’s no easy solution here that I see.

1 Like
19

I was thinking of something like having one of the following conditions to send a email link to the contributor, to claim his / her wiki access:

  • code commit count > 10 in git post commit hook
  • have moved to a certain level of badge and privilege in GNOME discourse, checked weekly.
  • Have contributed to > 30 bugs in gitlab, checked weekly.

Thanks

20

How would you know what someone’s Wiki account is? Same for the code hooks, Discourse bit, Gitlab. Also, if someone gets git commit rights, then Wiki is overdue to get. So probably you want to check git author instead of the person doing the commit.