User:NotAracham/RaidarrArchive/Wiki creators' guide

While this page has shaped up quite a bit from first draft, it's still not done and it's subject to revision, feedback and possibly whole section shuffling.

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

Templated Responses
The following is a list of templated language included in the RequestWiki interface, along with full verbiage and intended use

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. If the domain already exists, see the relevant section below.
 * 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 wikis. 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.

Additional 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.
 * Be aware of other creators. There is no way to know if another creator is working through the requests the same time you are. I get around this by refreshing fairly often and deferring if another wiki creator is active at the time. Wiki creators have a channel on discord that can be used to verify this. There's also an IRC channel doing the same on IRC, but it is not 'officially' run and from my experience isn't particularly active. If you can stand the pings, there is a meta edits relay on IRC which will leave messages when wiki creators are active in queue (along with other going-ons with Meta).

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.

Existing domain
ManageWiki will not let you create wikis in an existing domain. You'll be notified that the database already exists. This can go a few different ways and it is important to know what situation applies so you can make a helpful recommendation or seek advice.
 * Open/inactive wiki: If it's the same concept you can decline, inform the user of the existing wiki and point them to it. If the domain pertains to something different, they should be recommended to change the domain.
 * Closed wiki: As standard process the user should be directed to requests for reopening wikis if the scope overlaps as the wiki technically exists and overlaps, it just needs to be taken over by someone. this guide may help out (it's slightly outdated, consult a current steward to be sure). Unfortunately this scenario is a bit more messy.
 * Deleted wiki: A wiki that is deleted but not dropped will give you a 404 error when you try to visit, but will still stop you from creating the wiki. You can verify this by going to Special:ManageWiki/core/domainnamewiki, noting that the database will always have the domain name and then wiki at the end. This is because wikis that are deleted are not immediately dropped and the database can still be restored by a Steward with just a few button presses. This is useful to know if someone is requesting a wiki because their old one disappeared and was under the same domain name. In limited circumstances this process could be 'hastened' and the database dropped to allow a fresh start, but it would be ideal to consult a Steward/SRE member because this scenario is tricky and depends on context. Otherwise the standard process is to have the user follow the RfR process which supports undeleting wikis. I bring up dropping because if the wiki didn't have much on it or was just a mess, it may be beneficial to allow the requestor to have a fresh start and not be held back by a wiki that was never meaningfully developed and just happened to be there first. But if the user is directed to RfR then the process is out of the wiki creator process anyway. I'm not 100% sure on this section and it will likely be altered following consultation and feedback with other volunteers.

Overlapping requests
Sometimes people will make the same request multiple times, or two people will have the same idea (most often two people of the same community), or something else happens where requests overlap. For this reason it is ideal to review the request queue as a whole to see if there are multiples. From there you can either bring it to the attention of someone more confident or attempt to get to the bottom of it; preferring to find a solution where the more stable request is created (ie, existing/senior community manager or one party's agreement to let the other happen). If it turns out the issue can't be resolved that easily or something is 'up', you should bring in someone else to advise, probably a Steward.

Other tools and checks
You can find a user's request history and account connections on Miraheze by going to their contributions page, which is linked in the request form, and checking the links from there. The request history can be useful if you want to get background information or the requestor looks familiar; the main issue requiring this is if someone likes to 'pump and dump' wiki requests (lots of requests with minimal development on any of the wikis). This is not common but it has been known to happen and wiki creators have needed to tell someone to please stop, take a step back and work on what they have since it's not appropriate to just make endless wiki requests and do nothing with them. If broader sanction is needed, ie, the user should be blocked from the request system (this should be very rare), contact a Steward. A group on Meta exists for this purpose. Checking connected accounts can be useful to get background context and give you more to work with for edge cases. Often requestors are brand new to Miraheze but some are better established.

It's best to know exactly what you're doing, or consult with a Steward/senior creator if you intend to act on information from the checks above.