User:NotAracham/RaidarrArchive/Wiki creators' guide

Wiki creation guide This page offers common advice to current and aspiring wiki creators. It may be useful to people who are requesting wikis to know how it works.

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.

• inreview: 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.
• onhold: 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).
• declined: 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).
• accepted: 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

Text	Action	Comment Verbatim
Other	All	(freeform text entered by user)
Perfect request	Approval	Perfect. Clear purpose, scope, and topic. Please ensure your wiki complies with all aspects of the Content Policy and Code of Conduct at all times and that it does not deviate from the approved scope or else your wiki may be closed. Thank you for choosing Miraheze!
Good request	Approval	Pretty good. Purpose and description are a bit vague, but there is nonetheless a clear enough purpose, scope, and/or topic here. Please ensure your wiki complies with all aspects of the Content Policy and Code of Conduct at all times and that it does not deviate from the approved scope or else your wiki will be closed. Thank you for choosing Miraheze!
Okay request	Approval	Okay-ish. Description doesn't meet our requirements, but in this case the sitename, URL, and categorisation suggest this is a wiki that would follow the Content Policy made clear by the preceding fields, and it is conditionally approved as such. Please be advised that if your wiki deviates too much from this approval, remedial action can be taken by a Steward which includes wiki closure and potential revocation of wiki requesting privileges, if necessary. Please ensure your wiki complies with all aspects of Content Policy and Code of Conduct at all times. Thank you.
Categorised as private	Approval	The purpose and scope of your wiki is clear enough. Please ensure your wiki complies with all aspects of the Content Policy and Code of Conduct at all times or it may be closed. Please also note that I have categorised your wiki as "Private". Thank you.
On hold pending response	On Hold	On hold pending response from the wiki requester (see the "Request Comments" tab). Please reply to the questions left by the wiki creator on this request but do not create another wiki request. Thank you.
On hold pending review from another wiki creator	On Hold	On hold pending review from another Wiki creator or Steward.
Needs more details	Decline	Can you give us a few more details on the purpose for, scope of, and topic of your wiki, and briefly describe some of your wiki's content in approximately 2-3 sentences? Additionally can you elaborate on your wiki's scope and topical focus a bit further? A few sentences describing the scope of your wiki and the sort of content it will contain should be helpful. Please go back into your original request and add to, but do not replace, your existing description. Thank you.
Invalid or unclear subdomain	Decline	The scope and purpose of the wiki seem clear enough. However, your requested subdomain is either invalid, is too generic, conveys a Miraheze affiliation, or suggests the wiki is an English language or multilingual wiki when it is not. Please change it to something that better reflects your wiki's purpose and scope. Thank you.
Invalid sitename/subdomain (obsence wording)	Decline	The scope and purpose of the wiki seem clear enough. However, the requested wiki name or subdomain is in violation of our Content Policy which prohibits obsence wording in wiki names and subdomains. Please change it to something that is better. Thank you.
Use Public Test Wiki	Decline	Please use Public Test Wiki, https://publictestwiki.com, to test the administrator and bureaucrat tools (as well as Miraheze since the wiki is hosted by us). You should review and follow all TestWiki:Policies, especially TestWiki:Testing policy and TestWiki:Main policy, reverting all tests you perform in the reverse order which you performed them. Request permissions at TestWiki:Request permissions. Thank you.
Database exists (wiki active)	Decline	A wiki already exists at the selected subdomain. Please visit the local wiki and contribute there. Please reach out to any local bureaucrat to request any permissions if you require them. If bureaucrats are not active on the wiki after a reasonable period of time, please start a local election and ask a Steward to evaluate it on the Stewards' noticeboard. Thanks.
Database exists (wiki closed)	Decline	A wiki exists at the subdomain selected but is closed. Please visit the Requests for reopening wikis page to request to reopen the wiki or ask for help on Community noticeboard.
Database exists (wiki already deleted)	Decline	A wiki exists at the selected subdomain but has been deleted in accordance with the Dormancy Policy. I will request a Steward undelete it for you. When it has been undeleted and reopened, please visit the local wiki and ensure you make at least one edit or log action every 45 days. Wikis are only deleted after 6 months of complete inactivity; if you require a Dormancy Policy exemption, you should review the policy and request it once your wiki has at least 40-60 content pages. Thank you.
Database exists (wiki undeleted)	Decline	The selected wiki database name already exists and the wiki was closed, however, the wiki has now been reopened. Please visit the wiki and ensure you make at least one edit or log action every 45 days. Wikis are only deleted after 6 months of complete inactivity. Please reach out to any local bureaucrat to request any permissions if you require them. If bureaucrats are not active on the wiki after a reasonable period of time, please start a local election and ask a Steward to evaluate it on the Stewards' noticeboard. Thank you.
Database exists (unrelated purpose)	Decline	Wiki database name and subdomain already exist. The wiki does not however seem to have the same purpose as the one you are requesting here, so you will need to request a different subdomain. Please update this request once you have selected a new subdomain to reopen it for consideration.
Duplicate request	Decline	Declining as a duplicate request, which needs more information. Please do not edit this request and instead go back into your original request. Also, please do not submit duplicate requests. Thank you.
Excessive requests	Decline	Declining as you have requested an excessive amount of wikis. Thank you for your understanding. If you believe you have legitimate need for this amount of wikis, please reply to this request with a 2-3 sentence reasoning on why you need the wikis.
Vandal request	Decline	Declining as this wiki request is product of either vandalism or trolling.
Content Policy (commercial activity)	Decline	Declining per Content Policy provision, "The primary purpose of your wiki cannot be for commercial activity." Thank you for understanding. If in error, please edit this wiki request and articulate a clearer purpose and scope for your wiki that makes it clear how this wiki would not violate this criterion of Content Policy.
Content Policy (deceive, defraud or mislead)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis with the sole purpose of deceiving, defrauding, or misleading people." Thank you for your understanding.
Content Policy (duplicate/similar wiki)	Decline	Your proposed wiki appears to duplicate, either substantially or entirely, the scope of an existing wiki, which is prohibited by the Content Policy. Could you please describe in a few more sentences by adding to, but not replacing, your existing description, the scope and focus for your wiki, and also assure us that your wiki will not be a complete or substantial duplication? If your wiki fouses on a subtopic of a bigger wiki, please clarify that. Thank you.
Content Policy (file sharing service)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis whose main purpose is to act as a file sharing service." Thank you for your understanding.
Content Policy (forks)	Decline	Declining per Content Policy provision, "Direct forks of other Miraheze wikis where no attempts at mediations are made are not allowed." Thank you for your understanding.
Content Policy (illegal UK activity)	Decline	Declining per Content Policy provision, "Miraheze does not host any content that is illegal in the United Kingdom." Thank you for understanding. If you believe this decline reason was used incorrectly, please address this with the declining wiki creator on their user talk page first before escalating your concern to the Stewards' noticeboard. Thank you.
Content Policy (makes it difficult for other wikis)	Decline	Declining per Content Policy provision, "A wiki must not create problems which make it difficult for other wikis." Thank you for understanding.
Content Policy (no anarchy wikis)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis that operate on the basis of an anarchy system (i.e. no leadership and no rules)." Thank you for understanding.
Content Policy (sexual nature involving minors)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis of a sexual nature which involve minors in any way." Thank you for your understanding.
Content Policy (toxic communities)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis where the community has developed in such a way as to be characterised as toxic." Thank you for your understanding.
Content Policy (unsubstantiated insult)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis which spread unsubstantiated insult, hate or rumours against a person or group of people." Thank you for understanding.
Content Policy (violence or hatred)	Decline	Declining per Content Policy provision, "Miraheze does not host wikis that promote violence, hatred, or harassment against a person or group of people." Thank you for your understanding.
Content Policy (Wikimedia-like wikis/forks)	Decline	Declining per Content Policy provision, "Direct forks and forks where a substantial amount of content is copied from a Wikimedia project are not allowed." Thank you for your understanding.
Reception wiki	Decline	Declining per resolution of a Request for Comment, "No new reception wikis will be accepted on the platform." Thank you for your understanding.
Author request	Decline	Declined at the request of the wiki requester.

On the topic of Reception Wikis

(Adding this section in Raidarr's absence NotAracham (talk • contribs • global) 18:35, 31 January 2023 (UTC))

Per a successfully closed RfC, requests for new Reception wikis should not be approved on the Miraheze platform. The challenge with this dictate is that a clear definition of what makes a reception wiki still does not exist.

In lieu of clear consensus on a definition, this excerpt from a community noticeboard post from Raidarr on the topic has been used as a guiding principle for fellow Wiki Creators. If this isn't enough to make a determination, get input from your colleagues!

All of the above are too narrow and fail to sufficiently cover the amount of factors that make up reception wikis. Unfortunately the clearest way to explain is simply by pointing out examples of how things work. Individual points don't make a reception wiki. Most or all of the points together do.

*Binary scope: (Good/Bad/Neutral-Decent-Average-etc) (thing) Wiki. Exception, certain wikis that glue the two together which hint at other factors or are clearly trying to subvert this principle explicitly.

*Formula: The substance of a mainspace page is bullet points of indeterminate size and quality, designed to 'rant' about certain components of the thing. Sometimes they'll come with sources of various quality. The objective is to list these things, not necessarily to explain where they came from, how they connect together (though some particularly long-winded pages do go in bullet point paragraphs to partially achieve this) and critically they rarely take a third party point of view and tend to read as primary or secondary sources.

*Overall slant: The above format will typically accompany a short, often pasted from Wikipedia opening or similar in style blurb; a tagline of indeterminate creativity, the main course of above, trivia and possibly a separate reception section attempting to tie in the pointers to how the 'thing' was popularly received. If the overall reflects a personal blog or an attempt to find consensus on a piece of material is completely at the mercy of who is writing the article.

*Management: Less crucial since this is broad and not reception wikis specifically, but the following observations are often shared. Founders/owners are treated with a degree of reverence. Admins and bureaucrats tend to have far greater agency and get away with more nonsense than in a truly Wikimedia-inspired community. In the past this came with arbitrary decision making and decidedly petty block reasons, but it's more recently been infused with 'sloppy RfCs' and some attempt at rules (though often, in finding a reception wiki the rules tend to be less than ideal and often make things more confusing). Main page wise there are pretty much two types and the commonalities are uncanny; either the "new" front page eyesore that is iconic for Qualitipedia or an older style that slaps rules, staff and a basic description/tagline on the main page.

Other factors come in but they're more individuals or trends that aren't as strongly tied with how reception wikis work, while the above tend to be the main commonalities that come together and you end up with what is known as a reception wiki.

We thank Raidarr for this thoughtfully-reasoned definition.

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 scope on a single individual - extremely narrow scopes of this kind are generally declined as best practice, as they are either personal promotion/commercial activity/created without consent of the subject and will inevitably violate content policy.
• 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.
• Prior Requests Users may try to repeatedly submit the same wiki request, either with slightly different domain names or user names. Copying the username or database name, switching status to 'All' in the request queue and searching by either for previously declined requests is recommended if a request looks suspect.

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.

See also

Nothing yet.