Wikipedia:Requested moves/Closing instructions
This is an explanatory essay about Wikipedia:Requested moves. This page provides additional information about concepts in the page(s) it supplements. This page is not one of Wikipedia's policies or guidelines as it has not been thoroughly vetted by the community. |
This page in a nutshell:
|
The following are suggestions for closing Wikipedia:Requested moves discussions. These should generally be applied only after the normal seven-day listing period has elapsed. These suggestions are addressed to formal move requests that occur on talk pages, i.e. controversial move requests, but are instructive as to the necessary page history investigation and preservation and cleanup procedures advisable upon any move. Requests listed in the technical requests section can be simply removed after they have been processed. Where technical moves are contested, move the listing to the contested technical requests section.
Failure of an RM closer to follow the spirit and intent of these instructions, especially about properly weighing consensus with applicable policies and guidelines, may result in the initiation of a Move Review.
Closers may find this guide helpful when considering the technical task of closing a discussion.
Who can close requested moves
Conflicts of interest
An
You are considered involved[a] if:
- You have ever opened a request to move the page
- You have ever supported or opposed a request to move the page
- You have ever closed a previous controversial request to move the page
- You have ever technical request)
- You have ever commented on any talk page in a way that has indicated a clear position on the specific move request
- Your editing on the page has demonstrated a clear position on the move request
An involved editor may comment in a move discussion, solicit a closure, or make a new move request at a later date, but may not close an open move request. When you are an involved editor, trust the process and leave the close to one of the many, many other editors on Wikipedia who are capable of closing move discussions.
If you wish to solicit a closure after at least a week of discussion has taken place, you can make a request for an impartial administrator to assess consensus. The closer should be familiar with all relevant policies and guidelines (especially those relating to article titles and disambiguation) as well as the procedures described on this page. Do not ask for a specific closer under any circumstances.
Non-admin closure
Experienced and uninvolved registered editors in good standing are encouraged to close requested move discussions. Any
|nac=
parameter in the closing template).
Non-administrators are reminded that closing a discussion calls for an impartial assessment of consensus or lack thereof, although arguments supported by directly relevant policy and guidelines are given more weight (while keeping broader Wikipedia policy, guidelines, and consensus in mind). Any editor wishing to express an opinion on the requested move should join the discussion, not close it.
Anyone, administrator or not, who wishes to close a requested move must be very familiar with the policies and guidelines associated with it (especially
Occasionally, a move involves a redirect with multiple revisions, and requires technical intervention. Editors are permitted to close the discussion and file a
In any case where a non-admin closer does resort to a technical move request, the closer should actively monitor that request, and be ready and willing to perform all tidying after the move (as instructed below), such as fixing double redirects, fair-use rationales, and navbox links included on the page. If a non-admin closer is not willing to wait for the technical deletion and to perform the follow up in this manner, they should only close requested moves that do not require technical intervention.
Closure by a page mover
Editors with the page mover permission can perform certain technical moves without administrator assistance, such as a move over a redirect with more than one edit via a
|pmc=
parameter in the closing template).
Early closure
In general, move discussions should remain open for at least seven days (168 hours) to allow interested editors adequate time to participate. However, when no one has commented yet, or if opposition is unanimous, discussions may be closed prior to the seven-day timeframe. Under these circumstances, the standards of determining if the closer has a conflict of interest do not apply.
- As long as no one has suggested any outcome besides not moving, the proposer of a move may close their own move request as withdrawn. In this case (and only in this case) of early closure the standards of determining appropriateness of non-admin closure do not apply; NAC must still be explicitly declared, however.
- Further, any editor may end such a move request with a procedural close if the request was initiated via block evasion.
On the other hand, when the outcome of the move discussion is, or has become, almost certain, such that there is not a "snowball's chance in hell" that the outcome will be anything other than what is expected, and there is clearly no need at all to prolong discussion further, the discussion may be closed early under the snowball clause.
- This clause should not be used to close a discussion when a particular outcome is merely "likely" or "highly likely", and there is a genuine and reasoned basis for disagreement. This is because move discussions are not a vote; it is important to be reasonably sure that there is little or no chance of accidentally excluding significant input or perspectives, or changing the weight of different views, if closed early. Especially, closers should beware of interpreting "early pile on" as necessarily showing how a discussion will end up. This can sometimes happen when a topic attracts high levels of attention from those engaged (or having a specific view) but slower attention from other less involved editors, perhaps with other points of view. It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to avoid precluding significant input and as a courtesy to ensure that it really will be a snowball.
Determining consensus
Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Wikipedia community in general as reflected in applicable policy, guidelines and naming conventions.
No minimum participation is required for requested moves. If no one has objected, go ahead and perform the move as requested unless it is out of keeping with
If objections have been raised, then the discussion should be evaluated just like any other discussion on Wikipedia: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority). However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if no consensus has been reached, the closer should move the article back to the most recent stable title. If no recent title has been stable, then the article should be moved to the title used by the first major contributor after the article ceased to be a stub.
Note that according to Wikipedia:Consensus § No consensus:
“ | When article title discussions end without consensus, the applicable policy preserves the most recent stable title. If there is no prior stable title, then the default is the title used by the first major contributor after the article ceased to be a stub .
|
” |
Therefore, if a page has been moved from a long-standing title, and it is not possible to move the page back to its original title during the discussion, the default title will be the title prior to the contested move. For example, if an article is created at
Relisting
Relisting is an option when a discussion cannot otherwise be closed, usually due to lack of consensus. Editors are under no obligation to wait to close a move request after it is relisted. Once a move request has been open for the full seven days, it may be closed at any time by an uninvolved editor. Closers wait mainly for general agreement, for consensus, to emerge.
Exception: if a page is added while relisting. Sometimes editors may not realize that to move page A to B, page B must first be moved to C. When a new page move request is added to one that is already seven days old, the RMCD bot places the notification tag on the newly added page that day, and the discussion must go a full seven days (more) before being closed. It is helpful to closers when relisters leave a note just below the nomination that this happened.
Relisting and participating
A relister may later become a participant or closer in the requested move discussion or survey.
Only move involved pages
A move request about moving X to Y should never be closed in such a way as to require page Z to move if Z wasn't listed in the original move request (see below).
Where a discussion would result in the original title pointing to a "Foo (disambiguation)" page, the practice of pagemovers has been to immediately move the disambiguation page to the base page name, per
Write a clear, concise closing statement
There are generally three different outcomes for consensus in requested moves. The closer should clearly show which outcome has taken place so that other editors may quickly see the progression of consensus regarding the title; it is much easier to move an article that has never had a firm consensus about the title.
- Moved (or consensus to move) should be used when consensus is found to rename the page. If there is any question whatsoever as to which title it should be moved to, please note this in the closing summary (e.g. "moved to Squeezy José"). This almost always sets a consensus for the new title, and further requests to move the page are likely to fail unless new information or arguments are brought forth.
- Not moved (or consensus not to move) should be used when a consensus has formed to keep the current title and not rename the article(s) in question. For instance, a proposal to rename Bob Dylan to Squeezy Joe would likely result in everyone (or nearly everyone) agreeing that the proposed move should not take place; this notifies other editors that they should probably not propose this move in the future until and unless circumstances change. There is a positive consensus found, and that consensus is for the page to stay exactly where it is.
- No consensus should be used when there is neither a consensus to move nor a consensus to keep the current title. This may be because a discussion has fractured into several possible titles and none seem especially suitable, or simply because equally strong arguments and appeals to Wikipedia policy and outside sources were found on both sides, without any clear reason to move the page found in the discussion. Of course, as elsewhere on Wikipedia, this usually means that no action is to be taken at the present time.
While it is usually bad form to re-request a move if consensus is found against it (until and unless circumstances change), it is not considered bad form to re-raise a request that found "no consensus" to move. (Successful move re-requests generally, though not always, take place at least three months after the previous one. An exception is when the no-consensus move discussion suggests a clear, new course of action.)
Discussions involving multiple options
Most move requests are simple. Alice proposes that we move X to Y. Bob, Carol and Dave chime in. Edgar analyzes the discussion and decides whether there is a consensus, and then gives one of the three outcomes above.
But sometimes things get complicated. Alice proposes moving X to Y, but then Bob raises real concerns about Y, and proposes Z instead. Carol says, no, we should stay with Y. Dave says we actually need to keep the article at X. Edgar shows up and is very confused. What does he do?
If you as a closer are in doubt because too many titles have been proposed and there's no real consensus anywhere, it is generally best to close as no consensus and allow someone to re-propose the move to a more specific or better title.
But then again, there are situations where multiple names have been proposed and no consensus arises out of any, except that it is determined that the current title should not host the article. (There are good arguments for Y, and there are good arguments for Z, but there are virtually no good arguments for it to stay at X.) In these difficult circumstances, the closer should pick the best title of the options available, and then make clear that while consensus has rejected the former title (and no request to bring it back should be made lightly), there is no consensus for the title actually chosen. Because such closures are inherently complex and require the closer to use more independent judgment than normal, it is strongly encouraged to provide an explicit closing statement in such closures. As this result does not indicate a consensus for the chosen title, anyone who objects to the closer's decision may make another move request at any time, and is advised to create such a request instead of taking the closure to
Closing the requested move
When you complete an entry on the project (whether the move was accepted or rejected), remove the {{
While historically, there have been other options for closing the move request survey on the affected article's talk page, nowadays we exclusively use the twin templates {{
Step-by-step closing procedure
After clicking the [edit] tab next to the move discussion, you may follow these step-by-step instructions for closing an RM discussion:
Before closing | After closing | Description |
---|---|---|
==Requested move== | ==Requested move== | Leave the heading alone; the close starts below it. |
{{Requested move/dated|Foo}} | {{subst:RM top|'''RESULT.'''|pmnac=yes}} | Replace text on left with text on right. |
DISCUSSION | DISCUSSION | Body of the discussion stays unchanged. |
{{subst:RM bottom}} | Add the bottom template. |
- If additional explanation is provided as to why you have closed the move discussion as a certain result, add additional comments immediately after '''RESULT'''..
- Save the page with an edit summary such as "
Closing requested move survey; page moved/not moved
".
After closing, the page should look similar to this:
- The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.
The result of the move request was: RESULT. [Additional comments]. (non-admin closure) Example (talk) 00:41, 26 March 2024 (UTC)
]
- Supports/Opposes with discussion
Add {{Old moves}} to the talk page if so desired
After the move is complete, the {{Old moves}} template may be added to the top of the talk page (or updated if already present), allowing editors to see previous move discussions that might otherwise be archived. This is helpful for titles that are likely to be challenged again, so that any would-be re-proposer can make reference to previous arguments and consider how a consensus may be formed to move. In the case of pages with multiple move discussions, these templates should always be added/updated after the closure of an RM.
Automatic removals
Once the article's talk page has been updated, there's no need to return to the Wikipedia:Requested moves page and delete the article's entry there; this will be performed automatically by a bot.
Likewise,
Using move protection during RMs and immediately after RM closes
Some RM discussions are contentious; undiscussed, unilateral page moves during a discussion or page moves made immediately after and contrary to an RM close decision are disruptive and hurt the integrity of the RM process. Admins monitoring RM discussions should use their discretion to move protect articles during contentious RM discussions when they believe a premature, undiscussed unilateral move would be disruptive to the discussion. The same discretion should be used to start or continue move protection immediately after the RM close. Generally, such move protection should be limited to no more than 30 days under normal circumstances. The RM closing comment should reference the move protection.
Moving procedures
Edit history of destination page
The majority of target names for move requests already exist as
- For page histories resulting from cut and paste moves, the correct way to fix this is to merge the page history of the present article and the redirect, using the procedure outlined at Wikipedia:Administrators' guide/Fixing cut-and-paste moves. On rare occasions, this procedure will not work correctly. Once a history merge is done, it cannot easily be undone, so don't pick this option unless it is definitely the right one. You can request history merges at Wikipedia:Requests for history merge.
- For duplicate articles and merged content, or alternatively for cut and paste moves, the page histories of the article and the redirect can be swapped with a round-robin move. For cut and paste moves this leaves a bifurcated history, but has less chance of causing problems. Simply move the redirect with a major history to a temporary name (
Draft:Move/NAME
is suggested), suppressing the creation of a redirect (in the event you forget to suppress the redirect, delete the same); next, move the article to the move target location, again suppressing the redirect and deleting the same if you forget; next, move the redirect from its temporary location to the title at which the article you just moved was formerly located. At this point the redirect will be pointing at itself; re-target it to point to the new location of the article. See alsoWP:ROUNDROBIN. - Another option is for redirect pages with major histories to be archived into a talk namespace, and a link then placed on the article's Network South East).
Cleaning up after the move
You should not close any move if you are unwilling to do the necessary clean up tasks described at
- Updating the article prose (including the first sentence) to use the new name
- Updating any navigational templates to link directly to the new title, rather than via a redirect
- Fixing any mistargeted wikilinks resulting from the move (only applies when the move involves a change to primary topic)
Moves of other pages
If a page is to be moved as the result of a move request, mention should be made of this in the move proposal and a notice should be placed on the talk page of the article to be moved (unless of course it is hosting the discussion). Generally, a move request on whether to move
These situations often come up when
Even if consensus is clear, when closing a move request do not move articles that have not been nominated to be moved except in the very clearest and not-even-plausibly controversial situations.
Bot considerations
Malformed requests
A request will be listed in a special section titled "Malformed requests" on Wikipedia:Requested moves when the listing bot fails to successfully interpret the request. Please remember to use {{subst:Requested move}}
– rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:
- The request was appended to an existing talk page section. Add a new section header immediately above the
{{Requested move/dated}}
template. - It is OK to change the auto-generated level 2 header to a level 3 header, thus making the RM section a sub-section of an earlier-started discussion.
- The page requested to be moved is a redirect. Only pages with non-redirecting content should be requested to be moved.
- Per WP:SIGPROBthe timestamp must adhere to the system-generated format (
HH:MM, D MM YYYY (UTC)
) and must not be customized.
"Time could not be ascertained"
A request will be listed in a special section titled "Time could not be ascertained" on Wikipedia:Requested moves when the listing bot cannot ascertain the date on which the request was made. Please remember to use {{subst:Requested move}}
– rather than manually format the request yourself – to avoid this issue. Possible causes and solutions include:
- The move request is not signed. Sign the move request, and the problem is solved. If you are signing for someone else and you use {{Unsigned}}, you must place today's time/date stamp for this to remedy the problem, so you can use the form {{subst:unsigned|Foo|~~~~~}}, and note this uses five tildes to place the time stamp, or the actual timestamp can be copied from history - but adding (UTC) is required.
Also remove the<!-- Template:Unsigned -->
comment from the end of the line – the bot allows up to 23 bytes following the timestamp at the end of the line, and that comment is 26 bytes long. - A missing – between the proposed move and the proposal description will prevent the description from appearing. This can be fixed by simply adding the missing –.
- Unusually formatted signatures will prevent recognizing the end of the proposal description, for example, if the date is formatted Month Day, Year instead of Day Month Year. This can be fixed by editing the timestamp or adding a formatted time stamp.[1] In the first case, December 20, 2012 was changed to 20 December 2012, in the second case, a second time stamp was added.
Header confusion
Occasionally two sections with the same
Notes
- ^ Note that these criteria are significantly stricter than the criteria listed at WP:INVOLVED; this is intentional, befitting the less urgent nature of requested moves.