Status of the GNOME wiki

[crvi]

@ovitters

How would you know what someone’s Wiki account is?

All 3 preconditions listed above have an associated email address. So, we can add the email to wiki ACL, and send an email to the user to use the same email id to create wiki account, or if he already has the account created with the email, just notify that write access has been activated on that account.

[ovitters (Olav Vitters)]

@crvi

All 3 preconditions listed above have an associated email address. So, we can add the email to wiki ACL, and send an email to the user to use the same email id to create wiki account, or if he already has the account created with the email, just notify that write access has been activated on that account.

MoinMoin does not validate the email address is yours. Meaning, I can create an account with the email address dude@redhat.com and it’ll work. Further, creating the Wiki account still is a hassle, you’d want it to work immediately. MoinMoin is a bit limited in what is possible, last time I checked.

Secondly, you assume that everyone always uses the same email address.

Anyway, feel free to actually make some scripts and investigate further, but please do carefully check the assumptions and check how things work. Everything seems easy until you dive into the details.

[sri]

While there are a lot of valuable information on the wiki - Im more of re-imagining how we do our information anyways and then taking a frank approach that is streamlined towards onboarding. As we look at how we do the website and technical documentation - we should also re-assess the content on the wiki some of which is out of date.

[crvi]

@sri

we should also re-assess the content on the wiki some of which is out of date.

I think when the write access problem in wiki gets addressed, this should get fixed as a side-effect.

[sri]

Correct me if I’m wrong, but I interpreted your post as you approaching this from a “community edited” but a lot of those edits will likely done by folks who already have editor access already since ostensibly they are the subject matter expert for their team.

Of course, there might be content that can be fixed like code examples that can be corrected or some other matter, but in this case, it actually makes better since for gitlab pages in which an MR can be generated - and that will create a better flow and an opportunity for review using the same methodology of code. There are of course exceptions - one being the main website which should be under direct foundation staff control IMHO.

[crvi]

@sri

Correct me if I’m wrong, but I interpreted your post as you approaching this from a “community edited” but a lot of those edits will likely done by folks who already have editor access already since ostensibly they are the subject matter expert for their team.

First point here is that we need a better solution overall.

Like, how bugzilla to Gitlab, and devel-list to GNOME discourse migrations made a difference to the overall GNOME development and support model. wiki.gnome.org is the bugzilla of the documentation world. E.g. ACL is too primitive ( yes / no ).

bugzilla / devel-list / wiki.gnome.org are not totally bad. They’re still useful for some purposes, but not as a recommended solution in their respective domains anymore.

What we need:

1. Better / automatic anti spam support.
2. Provide automatic write access to users who have made decent GNOME contribution.
3. Initial user contributions should have mandatory reviews. ( say, first 5 contributions )
4. Initially new users should be allowed only few page edits per week ( say, 2 ). The more their edits are accepted, this count can increase gradually.
5. More control of ACL. E.g. a user who has a general wiki write access can update a page which needs special privileges ( team owned ), but that will be published only after review by the page / team members.

@sri

Of course, there might be content that can be fixed like code examples that can be corrected or some other matter, but in this case, it actually makes better since for gitlab pages in which an MR can be generated - and that will create a better flow and an opportunity for review using the same methodology of code. There are of course exceptions - one being the main website which should be under direct foundation staff control IMHO.

We’re turning to Gitlab, because we haven’t yet found the 2020 equivalent of MoinMoin wiki, not because Gitlab is the perfect solution for this problem. If we don’t have any other solution, we can think about Gitlab as a final measure.

Personally, I would not prefer Gitlab in its current form, for this specific purpose, unless Gitlab comes up with a new feature for managing documentation, in which case it would be awesome. But, that’s just wishful thinking.

Thanks!