User:NotAracham/RaidarrArchive/Requests for reopening guide

This guide attempts to empower people to triage requests on requests for reopening wikis while all being consistent to (current as of writing) practice. This page is free to modify as circumstances change, or to add bits that may help (for example I know some users have come up with boilerplate templates for certain responses).

I see the need for this because there are several flairs and tricks which can vary between who is looking at a given time, and I wish to mix the best of as many approaches as possible for ideal outcomes. It should be 'starter reading' even if you are an established (non-steward) volunteer in reviewing the page, and especially if you are brand new to it and want to help out. This is not intended as a 'use guide', but this may come in helpful for people just wanting to use it too. Again, feel free to add tricks that I may have missed in verifying scenarios. They can be deceptively tricky especially if a subdomain linked simply gives a 404 error.

Circumstances for reopening / intervening

 * Wiki was closed for inactivity, and you can still see it. This can be left as-is, it just requires a Steward to visit and mark as open and no action is needed. If the requests have been sitting for several days, a week or so, you may wish to poke a steward.
 * Wiki was closed for inactivity and deleted. This forks into two scenarios. One is that the database exists: you can check with Special:ManageWiki/core/(databasename)wiki, ie, Special:ManageWiki/core/metawiki. If there is a form then the database exists and can be undeleted by a Steward. If the user notices it's gone and is confused, you can leave a reassurance based on this evidence. Otherwise this can be left as-is. If that produces an error (and the URL is correct), the database has been dropped and the recovery for the most part cannot be undertaken. This can be marked as such, however if you want to go the extra mile first, you can establish if the wiki was public or private and how long ago it was removed. If the removal was in the span of the past year, get Reception123's attention (can be inline or a poke elsewhere, ie, Discord). He may have a backup on his end that can be restored. Please see the malformed requests section before making this call; it can be tricky to say without having looked into all circumstances. If you are not 100% confident it can be left alone.
 * Wiki was closed by a bureaucrat/manually. This cannot be undertaken and is not what the RfR page is designed to handle. You can base this on a clear sitenotice on-wiki, a log entry of closure (including on Meta if the wiki may have been outright deleted for Content Policy reasons), or an on-wiki discussion. If the circumstances of closure are disputed, invite the requestor to leave a message on the Stewards' noticeboard with all context involved or contact a Steward directly/by email with that information. If this is for Qualitipedia network wikis, the closure will not be overturned (having been based on a clear cut and procedural correct community vote) and this exchange should simply end as quickly as possible. This is the list to use, basing off the first list of wikis and the ones in the former section marked 'closed' on this page.
 * Wiki was affected by db141 issues. This cannot be undertaken, but for clarity you can add a pipe and mark explicitly as db141 issue. The user can be directed to Tech:Wiki recreations, the current main way to get people up to speed on what can happen next. As time goes on this will become a rarer, hopefully completely absent scenario. This can be easily verified by visiting the provided link and receiving an 'Action Required' message.

In general, reviewing how past requests have been processed (especially by stewards) can offer further clarity on what is done (and how, ie, ways of marking requests). It's preferred to leave it be over intervening unless the course is extremely clear or your contribution 'settles' or offers essential context for the issue. In making contact it is preferred to ping the requestor, further ensuring they see and understand.

Malformed requests
Requests that are malformed cannot be processed. Common examples are 'double headers' where people fill out header sections incorrectly; fail to fill in fields resulting in SUBDOMAIN_HERE, fail to provide a reason or throw the request somewhere random on the page instead of at the end.

If the malformation is minor and you can deduce how it should be, just fix it. If it is major (domain is unknown, no reason is offered) then it depends. You could remove the request if it is completely incoherent; in this case you should leave a message on their talk page asking them to clarify and correct. You could prod them for further information, ie if the request is functional but the domain is unclear or there is no reason. They can just be asked to please provide those things so a Steward can proceed. If you're savvy you may be able to guess what domain they mean based on what they say and what their CentralAuth says, but if you aren't certain then they should just be asked to correct it themselves. It's possible they made a typo. Checking their CentralAuth may yield a valid name that is clearly what they meant.

Other tips
In performing the 'background research' element you may find the CentralAuth and Special:RequestWikiQueue utilities helpful. These shouldn't be needed often but are good to be aware of for the principles mentioned above.