[Accepted] Open Wiki Registration.

[Banditoz]

I was hoping to casually contribute to Aurora's wiki every now and then, until I found out I need to apply for wiki maintainer to even be able to edit the wiki in the first place. We should have this changed to allow everyone a wiki account. A closed wiki like this is very strange to me, and I don't think any other Space Station 13 server has this.

We could simply allow people to create an account, but this could create problems with wiki spambots (they exist, and are bad on some smaller wikis!) so instead, we could;

Allow people to PM a wiki maintainer to create them an account. This gives the wiki maintainers a lot more responsibility, especially when dealing with users, because they will have to grant accounts, patrol recent changes that aren't by their own team, (or from Aurora staff, which I believe have a wiki account) resolve editor wars, revert grief and ban bad users, among other things.

What do you think?

Apologies if this is the wrong subforum. This seemed like the right place.

[Skull132]

To prevent all of these fun things, do you know if Mediawiki has a proposed changes system, similar to how PR-ing on Git works? Or is recent edits all you get on that count? Because, if I had to choose, reviewing changes before approving them is infinitely better than reviewing them after they've been pushed live.

Also, I've linked this to the wiki plebs to see if they'd be interested in adding the role of Wiki Administratum to their job list.

[LordFowl]

Converting the wiki to a more standard format where wiki-devs act more like wiki administrators and the wiki is open to the public sounds infinitely better than our current system where a small number of people of sporadic interest are responsible for the entire wiki development.

[Banditoz]

To prevent all of these fun things, do you know if Mediawiki has a proposed changes system, similar to how PR-ing on Git works? Or is recent edits all you get on that count? Because, if I had to choose, reviewing changes before approving them is infinitely better than reviewing them after they've been pushed live.

There's a Mediawiki extension that has functionality close to what you want, where users must have their edits approved by people with a certain role before their edits appear on live.

[Scheveningen]

It's a good idea.

[Burrito Justice]

Provided the Moderation extension is installed and we do get something similar to pull requests, I'm entirely open to the idea, and wouldn't mind rolling around edit requests and approving changes to the wiki.

[Chada1]

I'm entirely in support of enabling the playerbase to suggest changes to the wiki, (They already can, if they just contact a wiki maintainer with their proposed changes) I'm not in support of giving full wiki accounts to all who register akin to most fully open wikis (However, if Wiki maintainers and Lore devs were given special ranks on the wiki that enabled unrestricted edits, that could work). Not only is that a pain to keep track of, it would likely be a risk to the Lore teams' work, and added hassle for both the wiki and the lore team. Proposed changes, however, I'm entirely in support of and I wouldn't mind reviewing proposals in the least.

As for the added responsibilities, I trust the current members of the team to act as Wiki mods of a sort, and if they're unsure of something they can also get into contact with other Staff members.

Overall, I'm in support so long as the changes must be reviewed before going live.

[Banditoz]

Provided the Moderation extension is installed and we do get something similar to pull requests, I'm entirely open to the idea, and wouldn't mind rolling around edit requests and approving changes to the wiki.

 

The moderation extension is the closest that you can get to pull requests. Although I did find this review and merge extension, it is unmaintained and probably would not work too well with the moderation extension.

If we were to get the moderation extension, it would be best to allow users to create an account in their own, and give trusted, long term users the ability to bypass the review process. If anyone griefs at all, simply revert the edit and block their account. This can also be done with the moderation extension.

With Baystation's wiki, there were no issues with griefers, the only issues were with spambots, which caused them to remove the ability for users to make their own accounts, rather have an admin make them. Note Bay does not have the moderation extension installed.

 

I'm entirely in support of enabling the playerbase to suggest changes to the wiki, (They already can, if they just contact a wiki maintainer with their proposed changes) I'm not in support of giving full wiki accounts to all who register akin to most fully open wikis (However, if Wiki maintainers and Lore devs were given special ranks on the wiki that enabled unrestricted edits, that could work). Not only is that a pain to keep track of, it would likely be a risk to the Lore teams' work, and added hassle for both the wiki and the lore team. Proposed changes, however, I'm entirely in support of and I wouldn't mind reviewing proposals in the least.

As for the added responsibilities, I trust the current members of the team to act as Wiki mods of a sort, and if they're unsure of something they can also get into contact with other Staff members.

Overall, I'm in support so long as the changes must be reviewed before going live.

 

Do remember changes to the wiki are very easily reverted.

[Chada1]

Do remember changes to the wiki are very easily reverted.

No matter how easy it is to revert changes, it is always possible a change will be missed when using a public contribution system. Not to mention, even if they are reverted, any changes made ontop of them will be reverted as well, even if they were good. The only way to prevent losing changes that were placed ontop is to go onto the page and manually delete what that edit added which is a lot of effort. As I said, it's a lot to keep track of when done through a fully public format.

And most importantly, I would rather not put Lore pages at risk of vandalization at all, I am fully willing to read through a ginormous list of suggestions and approve them one by one if I have to, but I don't want a fully public contribution system, not so long as the Lore Devs and Wiki Maintainers share the wiki. If the Lore team post in support of a fully public system then I might change my mind on that. Until then, I'm sure that I would want a suggest and approval system. And if not a suggest and approval system, then at minimum a manual account creation system.

[Banditoz]

Do remember changes to the wiki are very easily reverted.

No matter how easy it is to revert changes, it is always possible a change will be missed when using a public contribution system. Not to mention, even if they are reverted, any changes made ontop of them will be reverted as well, even if they were good. The only way to prevent losing changes that were placed ontop is to go onto the page and manually delete what that edit added which is a lot of effort. As I said, it's a lot to keep track of when done through a fully public format.

And most importantly, I would rather not put Lore pages at risk of vandalization at all, I am fully willing to read through a ginormous list of suggestions and approve them one by one if I have to, but I don't want a fully public contribution system, not so long as the Lore Devs and Wiki Maintainers share the wiki. If the Lore team post in support of a fully public system then I might change my mind on that. Until then, I'm sure that I would want a suggest and approval system. And if not a suggest and approval system, then at minimum a manual account creation system.

A solution to this would be to move every lore page to its own Lore namespace. Then create a usergroup, say `lore` that can only edit that namespace. See $wgNamespaceProtection and user rights. Alternatively, lock every lore page.

[Chada1]

A solution to this would be to move every lore page to its own Lore namespace. Then create a usergroup, say `lore` that can only edit that namespace. See $wgNamespaceProtection and user rights. Alternatively, lock every lore page.

 

Say we do all of this, which admittedly will knock a lot of links on the wiki out and require a lot of fixing. How would we solve the issue with Spambots? The Lore pages would be safe from vandalization, which is good. But we would still be swarmed by bots. That said, if we were to go fully public, that would have protected the Lore pages, for sure.

I'm still in favor of the moderation extension, or something similar.

[Skull132]

One more crazy idea would be to turn the wiki into a static site generator based website and host the main code on Github. But since nuking slowly accruing work sounds like a horrible idea, I'll just throw this into my bin of missed opportunities.

 

Say we do all of this, which admittedly will knock a lot of links on the wiki out and require a lot of fixing. How would we solve the issue with Spambots? The Lore pages would be safe from vandalization, which is good. But we would still be swarmed by bots. That said, if we were to go fully public, that would have protected the Lore pages, for sure.

I'm still in favor of the moderation extension, or something similar.

 

Spambots aren't an issue. We don't have wiki registration alone anymore. Users are based off of forum accounts, which are more secure.

But we can and will still install the moderation extension. IMO it's a better way to pre-emptively deal with potential edit wars and whatever else. It also means that a contributor can get feedback that they have to look at. Instead of doing their thing and then disregarding wiki maintainer feedback. Etcetera.

In general, I should be able to get this rolling some time this weekend.

[mention]Senpai Jackboot[/mention] what's your onion on this?

[Guest Marlon Phoenix]

I'd be fine with a more open system as long as, as suggested, wiki maintainers approve suggested changes.

[Faris]

Putting my seal of approval on this as well.

[duskofdawn]

I love this idea. I can't tell you how many times I've come across something inaccurate on the wiki.

[Mofo1995]

I love the idea, so long as Russian spambots and griefers can't edit my Tajara pages without first having my review.

[Skull132]

The moderation plugin has been installed and is currently being tested by the wiki team.

[Skull132]

Aand. The wiki is now open. Login with the forum username and password. Note that usernames with certain symbols (specifically spaces) do not work. You have to ask an admin (or me) to change it on the forums for you.

Note that because the two systems are linked, griefing or general idiocity on the wiki will result in a forum ban.

[Scheveningen]

Since wiki page changes are based on an approval basis from contributors, isn't it effectively impossible to do any actual damage/grief on the wiki aside from causing momentary annoyance to the individuals having to approve it?

[Doxxmedearly]

A lot of small annoyances adds up. Punishing those who do seems reasonable.

[Chada1]

We who approve wiki additions also have the option of marking users as spammers which are sectioned off from regular suggestions. So that is an option as well.

[Skull132]

Since wiki page changes are based on an approval basis from contributors, isn't it effectively impossible to do any actual damage/grief on the wiki aside from causing momentary annoyance to the individuals having to approve it?

 

The same mentality is applied to Github. If you are unable to adhere to the rules, and start wasting the staff's time by making joke edits, attempted griefing, etcetera, then you will be banned. Because, again, you're wasting staff's time and effort. We're here to deal with legitimate input.

[Faris]

This has been implemented.