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.

Evaluating requests
Evaluating a request comes down to having judgement and understanding of how Miraheze works. It's a little more advanced than first glance. As a wiki creator your primary job is to look at the request and be able to say that this wiki reasonably won't be an issue down the road. You are the first line of defense and you are also the first line of 'customer service' if a requestor doesn't understand how things work. This is necessary because the request process is not always self explanatory and if a prospective founder misses something that an experienced user might consider obvious, it's up to you to make it clear and ensure the process is smooth.

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.

Red flags and how certain requests are treated
This is an important section and I don't have the time to fill it out right now. Please bear with me.

Special situations
per above. This whole section might be moved around - bear with me!

Request status and how replies work
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.

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."

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.

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 might have to take anther step, which I'll elaborate on later.

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.

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.