User:NotAracham/RaidarrArchive/Wiki creators' guide

First of all, this page is a draft and I do intend to come back and clean it up. I'm writing this off-the-cuff because I'm feeling a little swamped and I want to put out what I know so hopefully more people will benefit in the wiki creation process and the Miraheze system overall.

This page is written because I,the principle author, am not particularly satisfied with the layout of the existing wiki creators' guide and am also a bit too lazy at the time of writing to navigate translation units and all that. Frankly, anyone who wants to be a wiki creator on Miraheze will require a conversational understanding of English anyway in order to work with other creators and volunteers and properly handle requests. Despite the somewhat personal nature of this page, it is open to edits for clarity and accuracy. Its contents are free to merge into the linked guide by someone more patient. It should be updated or at least marked as obsolete by a Steward if I'm not present and the wiki creation process changes significantly.

How the queue works
The queue, containing all wiki requests, can be accessed with Special:RequestWikiQueue. This form will automatically appear in the Requests section of a wiki creator's sidebar. This is also a tool for anyone to find the request of almost any wiki on the platform. Almost, because some wikis were made with Special:CreateWiki. This feature is sometimes used for testing and creating 'core' wikis on the platform, but its use is generally discouraged. Using the request form leaves a 'paper trail' and helps everyone even if you have the power to simply make a wiki.

Wiki creators themselves can request and then approve their own wiki. Wiki creators should set an example with their requests; they shouldn't make something that another creator would reasonably reject as lacking information or being a content policy issue. There is no practice requiring them to wait for another creator to review, though if they want to present the image of fairness this is something they could do.

RequestWiki interface
There are four states a request can be in.
 * : The request is in the queue and needs to be handled somehow. Default status. A request that is updated by form is put back in review from the below statuses. Regular comments don't do this.
 * : A status indicating someone has seen the request but it needs work to be accepted. Check out this queue every so often because there are some caveats. If a request has been on hold for too long it can be declined (ideally more than 3 days).
 * : The request cannot be accepted as it is. Note the phrasing: people can later update the request and change it to become acceptable (unless you've told them 'no' and that's that).
 * : All is good and the wiki is created. It generally shouldn't be touched after this but you can leave comments if appropriate.

RequestWiki provides various canned replies for you to give whether you are accepting, placing on hold or declining the request. It would be helpful to look into what these replies are so when you use them, they reflect what you mean (the wording left in comments is more explicit than what the dropdown in the form says). These replies often reference the Content Policy since requestors often don't read it or don't know about it even when requesting a wiki. You can supplement these replies with comments of their own. Requestor are notified on Meta of any comment that appears in their request and the initial approve/on hold/decline is automatically mirrored with an email to the requestor if they have one attached. Note that users generally aren't globally notified on Miraheze unless they've explicitly opted into this in their Preferences.

There's also an option to put in your own text. I prefer this to better reflect what I mean, but it can be clunky to write in the approve/hold/decline field - in the initial response you only get a tiny text box and can't use spaces. If you're placing on hold and want to elaborate you have a little more flexibility just saying the request is on hold and to check the comments, then have a little more space in the comments. Note that approving will always preface your text with "Request approved." Also note that you don't get links or formatting at this time.

You have the discretion to just leave a comment and not even change the status formally; this leaves the review queue more messy but at least other reviewers will see it and the requestor will still be notified on Meta of the comment. For this reason always check the comments before handling the request. It's technically preferred to put the request on hold especially if it's been sitting with a comment and needs action by the requestor.

Note that the request is put back in queue when the form is updated. The status is not changed when only using the comment field (ie, someone replies to your request for more information by just leaving a comment). It's preferred to have people update the request form with their response because anyone can take a look at the queue and see it, while comments will only notify people involved in the request (see the notes section: ping management is important to be a good wiki creator). If someone has replied by comment to your inquiry, there's no procedural or technical reason not to take it. Just be aware of the request when it's handled in this way.

Approval
If the wiki is clearly unproblematic you're free to approve it. If there is an error, you may want to check to see if the wiki was generated correctly by going to the domain and looking at Special:ListUsers/bureaucrat. If the requestor is there it's probably fine. Still, it's a good idea to leave a message to a member of SRE (probably informally via IRC or discord) just to make sure it's fine as errors shouldn't happen but they've been known to happen anyway.

On hold
Placing on hold is the technically correct way to 'pause' a request and seek confirmation, more information, or make an inquiry. However there are caveats to this system. Per above, the request is only flagged as 'inreview' if the form is updated. You may get replies just through comments. The request can be approved/declined from there (or maybe more clarification is needed).

If someone is struggling to give the information you need, consider avoiding the canned response and asking about the elements that are the problem.

Decline
When a request has been on hold too long and you're reviewing the on hold queue, or when something is fundamentally problematic enough that you want to make it clear that it won't go forward this way. Unless you specify, decline is non-permanent - the request can still be updated to become compliant. It might be updated if someone wants to push it and you already said no at which point you say no more firmly. If someone keeps pushing it and doesn't get it you may want to point a Steward to the situation. Skip to this when someone is blatantly using the process to troll. You can also decline and hide the request if it has exceedingly foul language, such as liberal use of the n-word pass which is not valid anywhere in the request process.

Evaluating requests
Evaluating a request comes down to having judgement and understanding of how Miraheze works. Obviously your priority is having a 'good feel' that the request is in line with the Content Policy. The other component is to avoid certain pitfalls that come up but are not obvious just by knowing platform policy verbatim.

It is preferred for a request to have a few sentences to spell out what it means in description. Practically speaking wiki creators have discretion. They may be advised by Stewards if they are too liberal (or too strict) but the permitted range is fairly broad. For example, I tend to be one of the more relaxed requestors regarding length if the overall gist is clear enough and unproblematic. If it becomes a problem then typically that's because the requestor wasn't willing to be upfront in the first place and they've signed their own doom. I tend to prod for details if I cannot get the gist or the subject matter hits certain red flags.

Common red flags often requiring clarity and/or a confirmation, up to refusal for Content Policy include:
 * a focus on real life people or users on the internet. This is a factor often handled poorly that causes problems. It is not prohibited but its misuse can if nothing else get the wiki in trouble by the toxicity clause. There's a checkbox in the form for this.
 * a focus on drama, internet communities and politics. This is not a hard rule but you should treat these with a bit more caution if they fit any of these lines.
 * Focus on NSFW material. The main red flags here are general age group of the characters portrayed (if it gets into clearly underage characters, god forbid people it's a problem) and use of images on the wiki which isn't blocked but is expected to come with appropriate warnings.
 * Free editing/undefined scope, wikipedia forks or forks of known wikis on the platform. See the notes section for how to check the latter. We particularly don't accept wikis that are just 'wikipedia with a little twist' or which have a true anarchy type structure.
 * Testing wikis. We accept wikis for general personal use but we have a wiki explicitly dedicated to testing out the Miraheze interface: publictestwiki.com. The request should have more than testing, or make it clear what they're doing that PTW can't cover.
 * Commercial wikis: This does not exclude wikis intended to coordinate a commercial, private or government entity (if starbucks or some municipality wants a coordination wiki, well, why not). It also doesn't exclude having links in for patreon, seeking donations, even doing a fundraiser pertaining to the wiki's purpose. Pretty much just think spam or explicit use to sell people stuff.

Other important checks:
 * Subdomain. Three things: can't stick "miraheze" or "wikipedia" in the name, can't be too general (ie, francewiki, mewiki, subdomainwiki) and ideally matches the described purpose, and can't be explicit.
 * Categories. Not critical but an often overlooked factor. You can request they be updated or if the option is very obvious you might update it yourself (yes, you have this power - use it responsibly). Sometimes we don't have a good category for the scope and it can be left alone.
 * Private wiki. If the intent is fairly obvious and/or the wiki is more personal in nature, this tends to get more leniency. Note that people can change the setting after the wiki is made, so if your acceptance hinges on the wiki being private then you should make note of this when accepting.

Being a creator is as simple as reading the form, ensuring it's filled out properly, making sure the domain name/wiki name/description make sense and don't hit obvious red flags, and then approving/pausing to clarify/refusing if it's obviously not going to work. Being a good wiki creator requires you be a little more proactive from time to time.

If you, a wiki creator, find yourself a bit burned out or short on time, what you can do is deal with 'easy' requests that are clearly just fine and then go over requests requiring more thought in a second wave. As a caveat this means you should take the time to go back and deal with ones that have been sitting for a bit during the 'inreview' stage. If you are unsure you can put the request on hold and get the attention of another creator or a steward. Please be sure that the person you want to review is notified, or to leave the message somewhere obvious to other creators so they can follow up. If you put it on hold and expect another creator to just see it, chances are they won't because the on hold queue is messy and wiki creators rarely have the time or patience to sift through it of their own initiative. If you're going to drop it from 'inreview', make sure you're going to follow up or that someone else will be aware of it.

Some notes

 * Clear out your pings regularly. This is essential if you are reviewing more than one or two requests. You will be buried in pings from wiki created and scoring messages (generated automatically) and it is essential that you see if someone has left a comment and didn't update the request itself (especially if you put the request on hold). Obviously, check the pings before marking as read for this reason.
 * If you find yourself burned out or short on time, consider going through clearly easy requests and leaving ones requiring more thought/review/involved replies later. This is better than nothing, but the caveat is being willing to go back over more tricky requests later, even if that's also all you can do at a later time. Do not review at all if you 'aren't awake enough' or don't have the time to even really look over requests. In this process it is better for people to wait a little than to process things incorrectly, which will likely cause issues for other people in the future.
 * Consider checking a user's previous requests or even CentralAuth if you get the bug. It's not reasonable to do this every time but personally I've found it useful to do this if I have the inkling it would be useful, because sometimes a user's prior requests are relevant or they might have background in their connected accounts that is relevant to the request.
 * Also consider looking up the wiki's scope + "miraheze' if the topic is more broad and there's a chance it is already covered on Miraheze. This is useful to minimize wikis with overlapping/identical scopes. Sometimes this is easy because the database name will be the same, but that's not an absolute rule; you'll make more progress by doing a general search and seeing if a Miraheze wiki pops up. This is a compromise between trying to know what wikis are on Miraheze so you can consider this factor (it's unreasonable to know all of them by heart, even all the big-ish ones) and not knowing the wikis on the platform and accidentally approving things that result in this being an issue later. Conversely this can be helpful if you want to look into a wiki's background on Fandom if it's being forked from there and you don't get a specific link. This tip can be pretty much disregarded on requests with a personal or highly specialized scope.
 * Consider saving the names of wikis that strike you as borderline problematic or could be problematic, so you could check on them later and see if they're holding up. This is not your job, but it can make the job of Stewards easier if you come across a wiki that either failed to handle its somewhat more sensitive scope properly or has outright lied about its intentions and gone to do something different. Not necessary if you're very short on time, but useful if you want to be proactive.
 * If you want to go the extra mile and can find a discord server or other community link pertaining to the request, consider having a look so you know beyond doubt what you're getting into. This is not required but can prove useful and is a way to be thorough if you have time. Related to this it is not required that you go out of your way to verify people claiming to be from certain places or doing certain things are who they say they are. However, doing so is a massive step up in being a good wiki creator.

These notes are generally not required to be a wiki creator, but will either help your workflow or make you more thorough, and in any case will single you out as being just plain a better contributor so you have something to point to if you are seeking to get into more advanced positions like Global Sysop or Steward.