The following are guidelines for closing Bharatpedia:Requested moves discussions. They should generally be applied after the normal seven-day listing period has elapsed. These instructions primarily concern formal move requests on talk pages, including controversial and potentially controversial requests. They also explain the page-history investigation, preservation and clean-up procedures that may be necessary when carrying out any page move.

Requests listed under technical requests may be removed from the list once they have been processed. If a technical move is contested, the request should be moved to the contested technical requests section.

Failure to follow the purpose and principles of these instructions, particularly when assessing consensus in accordance with applicable policies and guidelines, may result in a request for a review of the closure.

Who can close requested moves[edit source]

Conflicts of interest[edit source]

An involved editor, whether an administrator or not, should not close a requested move discussion, except in the limited circumstances described below. These restrictions are deliberately stricter because requested moves are generally less urgent than other administrative matters.

An editor is considered involved if they have ever:

  • Opened a request to move the page;
  • Supported or opposed a request to move the page;
  • Closed an earlier controversial request to move the page;
  • Moved the page boldly to a title they prefer, except when reverting page-move vandalism or carrying out a technical request;
  • Commented on a talk page in a way that clearly indicates their position on the specific move request;
  • Edited the page in a way that demonstrates a clear position on the requested move.

An involved editor may participate in the discussion, request that an uninvolved editor close it, or submit a new move request at a later date. However, they should not close an open move request themselves. Editors who are involved should allow an uninvolved editor to assess the discussion and determine its outcome.

After at least seven days of discussion, an editor may request a closure by asking an impartial editor to assess consensus through Bharatpedia:Closure requests. The closer should be familiar with all relevant policies and guidelines, particularly those concerning article titles, disambiguation and the procedures described on this page. Do not request a particular editor to close the discussion.

Non-admin closure[edit source]

Experienced, uninvolved registered editors in good standing are encouraged to close requested move discussions. Any non-administrator closure (NAC) must be explicitly identified using an appropriate template, such as {{subst:RMnac}}, placed immediately after the closing rationale within the {{subst:RM top}} template. Alternatively, use the |nac= parameter in the closing template, if supported.

Non-administrators should remember that closing a discussion requires an impartial assessment of consensus, or the absence of consensus. Arguments supported by directly relevant policies and guidelines should receive greater weight, while broader Bharatpedia policies, guidelines and established community consensus should also be considered. Editors wishing to express an opinion on the proposed move should participate in the discussion rather than close it.

Anyone wishing to close a requested move, whether an administrator or not, should be familiar with the applicable policies and guidelines, particularly Bharatpedia:Article titles, Bharatpedia:Disambiguation and Bharatpedia:Consensus. Previous experience with requested move discussions is also beneficial.

Any closure may be challenged through BP:Move review. However, the fact that a closure was performed by a non-administrator is not, by itself, sufficient reason to overturn it, provided that the editor was uninvolved, assessed consensus impartially and followed the applicable procedures.

Non-administrators should exercise particular caution when closing contentious discussions in which significant disagreements remain unresolved. Nevertheless, any experienced, uninvolved editor in good standing may close a requested move discussion when they are able to assess the arguments fairly and apply the relevant policies and guidelines.

Occasionally, a move involves a redirect with multiple revisions and requires technical intervention. An editor may close the discussion and submit a technical move request, including a link to the closed discussion.

Outcomes supported by the discussion should generally be respected by the administrator or other editor carrying out the move. If an administrator identifies a clearly improper closure, they should take appropriate steps to reverse it and reopen the discussion where necessary.

When a non-administrator submits a technical move request after closing a discussion, they should monitor the request and be prepared to complete the necessary post-move clean-up, as described under Cleaning up after the move. This may include updating relevant links, templates and other page references.

Editors who are unwilling or unable to follow through with the technical move and its associated clean-up should limit their closures to requests that can be implemented without technical intervention.

Closure by a page mover[edit source]

Editors with the page mover permission may be able to carry out certain technical moves without administrator assistance, such as moving a page over a redirect with multiple revisions by performing a round-robin page swap, where the relevant permissions and procedures allow it.

The page mover right should be granted only to editors who have demonstrated a sound understanding of Bharatpedia's page-naming system and sufficient experience with page moves.

Since closure by a page mover is a form of non-administrator closure, it should be labelled accordingly using {{subst:RMnac}}, {{subst:RMpmc}} or an equivalent template, if supported. Alternatively, the |pmc= parameter may be used in the closing template where available.

Early closure[edit source]

Requested move discussions should generally remain open for at least seven days (168 hours), allowing interested editors adequate time to participate. However, a discussion may be closed before the seven-day period in appropriate circumstances, including when no one has commented or when the opposition to the proposed move is unanimous.

  • If no participant has suggested an outcome other than keeping the existing title, the proposer may withdraw the request. The closure should clearly state that the request was withdrawn.
  • An editor may also close a request with a procedural close in the following circumstances:
    • If the request was initiated through block evasion. In this situation, the closer may have been involved in the discussion.
    • If related discussions need to be consolidated into a single multi-page discussion.
  • When the outcome has become virtually certain and there is no useful reason to prolong the discussion, it may be closed early under the snowball clause.

The snowball clause should not be used merely because a particular outcome appears likely or highly likely when there remains a genuine, reasoned basis for disagreement. Requested move discussions are not votes. Closers should be reasonably certain that ending the discussion early will not exclude significant contributions or perspectives, or materially change the weight of the arguments.

Closers should also be cautious about interpreting an early concentration of support or opposition as a reliable indication of the final outcome. A topic may attract early attention from editors with a particular viewpoint, while other editors with different perspectives may participate later. Allowing a few additional days may be appropriate even when the discussion initially appears to favour one outcome.

Determining consensus[edit source]

Consensus is determined by evaluating the arguments presented, assigning appropriate weight to them and considering the relevant policies, guidelines and naming conventions. It is not determined merely by counting the preferences expressed by participants.

No minimum participation is required for requested moves. If no one has objected, the proposed move may be carried out, provided that it is consistent with Bharatpedia's naming conventions and does not conflict with applicable policies or guidelines.

Conversely, a requested move that conflicts with applicable naming conventions, policies or guidelines should ordinarily be closed without moving the page, regardless of how many participants support it, unless there is a compelling reason to ignore the rules.

Participants in a discussion represent only a small proportion of Bharatpedia's editorial community. Closers should therefore be familiar with the applicable policies, guidelines and conventions and assess the proposal accordingly.

If objections have been raised, the discussion should be evaluated on the strength of the arguments presented. When participants have not reached consensus and the applicable policies and naming conventions do not clearly favour a change, the page should ordinarily remain at its existing title.

However, a requested move may have been submitted in response to a recent change from a long-established title. If consensus has not been reached and the page can no longer be returned to its earlier title without administrative assistance, the closer should generally restore the most recent stable title.

If no recent stable title can be identified, the page should ordinarily be moved to the title used by the first major contributor after the article ceased to be a stub, where this can be established.

Note that according to Bharatpedia:Consensus § No consensus:


Therefore, if a page has been moved from a long-standing title and cannot be restored during the discussion, the default outcome should generally be to return it to the title used before the contested move.

For example, suppose an article was created at Soda can and remained there for several years before being moved boldly to Pop can. If a requested move discussion subsequently ends without consensus, the article should ordinarily return to its long-standing title, Soda can.

This applies even if the article was originally created at Pop can, Fizzy drink can or Orange-flavoured soft drink can, provided that Soda can subsequently became the established title through consensus and can be identified as the most recent stable title.

Relisting[edit source]

Relisting is an option when a discussion cannot be closed because the available arguments do not establish a clear outcome, usually due to a lack of consensus.

Editors are not required to wait for a particular period after a discussion has been relisted before closing it. Once a request has been open for the full seven days, an uninvolved editor may close it at any time. Closers should generally allow sufficient opportunity for consensus to emerge before deciding the outcome.

Exception: If an additional page is included in a move request after the discussion has already been open for seven days, the newly added proposal should ordinarily receive a full seven-day discussion period before closure. This allows interested editors adequate time to consider the additional proposal. The editor who relists the discussion should leave a note below the nomination explaining the circumstances.

Relisting and participating[edit source]

An editor who relists a requested move discussion may subsequently participate in the discussion or close it, provided that they remain able to assess the arguments impartially and comply with the relevant closure procedures.

Only move involved pages[edit source]

A request to move page X to page Y should not be closed in a way that requires page Z to be moved if Z was not included in the original request. See Moves of other pages below.

Where the discussion would result in the original title pointing to a disambiguation page, such as "Foo (disambiguation)", page movers have sometimes moved the disambiguation page to the base title in accordance with BP:MALPLACED. This should only be done when justified by the applicable naming conventions and the circumstances of the move. A disambiguation page generally belongs at the base title unless that title is occupied by a primary topic.

Write a clear, concise closing statement[edit source]

There are generally three possible outcomes when closing a requested move discussion. The closer should state the outcome clearly so that editors can understand the consensus reached and the current status of the title.

  1. Not moved (or consensus not to move) should be used when consensus supports retaining the existing title. For example, a proposal to rename Bob Dylan to Squeezy Joe would ordinarily be closed as not moved if the discussion establishes that the proposed title is unsuitable. This outcome indicates that the community has reached a positive consensus in favour of retaining the current title. Further requests proposing the same change should normally provide new information, arguments or circumstances.
  2. No consensus should be used when neither moving the page nor retaining its current title has achieved consensus. This may occur when several alternative titles have been proposed without any clearly preferred option, or when substantial arguments on both sides remain unresolved. Ordinarily, no change should be made at that time.
  3. Moved (or consensus to move) should be used when consensus supports changing the title. If there is any uncertainty about the precise destination, the closing statement should identify the title selected, for example, "moved to Squeezy José". A successful move establishes consensus for the new title, and further requests to change it should ordinarily present new information or arguments.

It is generally inadvisable to submit another request for a move after consensus has been reached against it, unless circumstances change. However, submitting a new request after a previous discussion ended with no consensus is acceptable.

A renewed request following a no-consensus outcome will often be more useful after sufficient time has passed, such as three months, although this is not a mandatory waiting period. An earlier request may be appropriate if the previous discussion identified a clear new approach or relevant information that was not adequately considered.

Discussions involving multiple options[edit source]

Most requested move discussions involve a straightforward proposal. One editor proposes moving page X to title Y, other editors contribute their views, and an uninvolved closer assesses whether consensus supports the change.

However, some discussions involve several possible titles. For example, one editor may propose moving X to Y, another may raise concerns about Y and suggest Z, while others may prefer retaining X.

If no proposed title has sufficient support and there is no clear consensus, the discussion should generally be closed as no consensus. An editor may then submit a new request proposing a more appropriate or specific title.

In some cases, the discussion may establish that the current title is unsuitable, even though no consensus has emerged for any single alternative. There may be persuasive arguments for Y and Z, but virtually no justification for retaining X.

In these circumstances, the closer may select the most appropriate title from the available options, provided that the choice is supported by the discussion and applicable policies. The closing statement should make clear that consensus rejected the former title but did not establish consensus for the title selected by the closer.

Because such closures require greater independent judgement, the closer is strongly encouraged to provide an explicit explanation of the outcome and the reasoning behind it.

Since this outcome does not establish consensus for the selected title, an editor who disagrees with the decision may submit another move request at any time. Such a request is generally preferable to seeking a move review when the disagreement concerns the title selected in the absence of consensus.

If selecting an alternative title would require disambiguating a title that was not included in the original proposal, and no notice has been provided on the corresponding talk page, the closer should not make that change immediately. Instead, the proposal should be relisted and notice placed on the affected page's talk page.

No title should be disambiguated as a result of a requested move without giving interested editors an opportunity to participate.

Closing the requested move[edit source]

After completing a requested move discussion, whether the proposed move was accepted or rejected, remove the {{requested move/dated}} tag from the talk page or replace it with the appropriate closing template, where supported.

The closing editor should add and sign a comment in the discussion area stating whether the request was accepted, rejected, withdrawn or closed without consensus.

Scripts may be available to assist with this process. Editors should use only tools that are compatible with Bharatpedia and permitted by its policies.

Historically, different methods have been used to close requested move discussions. Where the relevant templates are installed and supported, use the paired templates {{subst:RM top|result of the discussion.}} and {{subst:RM bottom}}.

Step-by-step closing procedure[edit source]

After opening the edit interface for the move discussion, follow these steps to close it:

Before closing After closing Description
==Requested move== ==Requested move== Leave the heading unchanged; the closure begins below it.
{{Requested move/dated|Foo}} {{subst:RM top|'''RESULT.'''}} Replace the dated request template with the appropriate closing template and result. Include any required non-administrator closure parameters.
DISCUSSION DISCUSSION Leave the body of the discussion unchanged.
{{subst:RM bottom}} Add the closing template at the end of the discussion.
  • If additional explanation is required, add it immediately after the result statement in the closing template.
  • Save the page with an appropriate edit summary, such as "Closing requested move discussion; page moved/not moved".

After closing, the discussion should resemble the following example. The templates and formatting shown below must be supported by the relevant Bharatpedia templates and interface.

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors wishing to challenge the closing decision should first discuss it with the closer and may consider a move review, where applicable. No further edits should be made to this discussion.

The result of the move request was: RESULT. [Additional comments]. (non-administrator closure) Example (talk) 14:07, 18 October 2026 (UTC)


Foo → Foobar – rationale of nominator. Example (talk) 14:07, 18 October 2026 (UTC)

  • Supports/Opposes with discussion
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Add {{Old moves}} to the talk page if so desired[edit source]

After completing a move, the {{Old moves}} template may be added to the top of the talk page, or updated if it already exists. This allows editors to find earlier move discussions that might otherwise be archived.

The template is particularly useful for titles that may be challenged again, as it allows future nominators to review earlier arguments and understand how consensus was reached. Where a page has been the subject of multiple move discussions, the template should be added or updated after each closure, where appropriate.

Automatic removals[edit source]

If Bharatpedia has a bot configured to maintain the requested move list, the entry may be removed automatically after the relevant talk page has been updated and the discussion closed.

Similarly, any automated removal of title notices or other maintenance templates depends on the bots and scripts configured on Bharatpedia. Editors should verify that the relevant automation is operating correctly rather than assuming that entries or notices will be removed automatically.

Using move protection during RMs and immediately after RM closes[edit source]

Some requested move discussions are contentious. Unilateral page moves made without discussion while a request is open, or immediately after a closure in opposition to its outcome, may disrupt the process and undermine the discussion.

Administrators monitoring requested move discussions should use their discretion to apply move protection when an early or unilateral move is likely to disrupt the discussion. The same discretion may be exercised immediately after closure where protection is necessary to preserve the outcome.

Under ordinary circumstances, move protection should be limited to 30 days or less. Longer protection may be justified where the circumstances warrant it and applicable protection policies permit it.

The closing statement should mention any move protection applied in connection with the discussion.

Moving procedures[edit source]

Edit history of destination page[edit source]

Many proposed destination titles already exist as redirects to the current article title. Before carrying out a move, inspect the destination page's edit history to determine whether it is minor or substantial.

If the destination has only a minor history, generally meaning that it has existed solely as a redirect and has never contained a duplicate article or material subsequently copied or merged elsewhere, it may be possible to delete it before proceeding, subject to the applicable deletion procedures.

However, a destination with a substantial history should not simply be deleted. Its history may be necessary to preserve the attribution required by Bharatpedia's applicable copyright and licensing policies.

There are three common ways to handle destination pages with substantial histories, depending on the circumstances:

  1. For histories resulting from cut-and-paste moves, the appropriate solution is generally to merge the history of the current article and the redirect using the procedure described at Bharatpedia:History merging. This procedure should only be used when appropriate, because a history merge can be difficult to reverse. Editors may request a history merge through Bharatpedia:Requests for history merge, if that process is available.
  2. For duplicate articles, merged content or certain cut-and-paste moves, the histories of the article and redirect may be exchanged through a round-robin page move. This may leave a divided history in some cut-and-paste cases, but can reduce other complications. One possible procedure is to move the redirect with a substantial history to a temporary title, such as Draft:Move/NAME, without creating a redirect. Then move the article to the requested destination, again avoiding the creation of a redirect where necessary. Finally, move the redirect from its temporary title to the article's former title and correct its target. This process requires appropriate permissions and careful attention to page histories.
  3. Another option is to archive a redirect with a substantial history in a suitable talk namespace and place a link to the archived history on the article's talk page. For example, a page that once contained a duplicate article may be preserved separately when the main article is moved to another title.

Editors should follow Bharatpedia's actual technical procedures and seek administrator assistance when the correct treatment of a page history is uncertain.

Cleaning up after the move[edit source]

Do not close a requested move discussion unless you are prepared to carry out the necessary clean-up tasks or have arranged for another editor to do so.

Bharatpedia:Moving a page

Moves of other pages[edit source]

If a requested move would require moving additional pages, those pages should be mentioned in the original proposal, and notice should be placed on the talk page of each affected article unless that page is already hosting the discussion.

A request to move page X to page Y should not ordinarily determine the title of page Z unless the original request explicitly includes Z as part of a multi-page move, for example through {{multi-move request}}.

Editors interested in page Z may have relevant knowledge about its subject or naming conventions. They should be given an opportunity to participate before a decision affecting that page is made.

These situations can arise when an article such as Foo (barge) is proposed for a new title such as Foo (enormous sailing thing), and participants suggest that the barge is actually the primary topic. The discussion may then lead to a suggestion that the existing article Foo be moved to Foo (bar), even though editors interested in Foo have not been notified through Talk:Foo.

This can lead to disagreement and a further, more contentious requested move. If a discussion concerning X indicates that Z should be disambiguated, the proposal should be relisted and notice placed on Talk:Z so that interested editors can contribute.

Even when the discussion appears to have a clear outcome, or when applying BP:NOGOODOPTIONS, do not disambiguate a title for which no notice has been provided on the corresponding talk page.

Disambiguation can be contentious. In such cases, relist the request and notify editors through the affected page's talk page. Notice is generally unnecessary when an article is simply being moved to the base title of its existing disambiguated name, provided that the move does not otherwise affect another page.

Bot considerations[edit source]

Automated tools may be used to maintain the requested move list, identify malformed requests and remove entries after discussions have been closed. Their behaviour depends on the bot configuration and templates installed on Bharatpedia.

Editors should follow the instructions provided by the relevant Bharatpedia bot and report unresolved technical problems through its designated discussion page, if available.

Malformed requests[edit source]

If Bharatpedia uses a listing bot, a request may be placed in a special section for malformed requests when the bot cannot interpret it correctly.

To reduce the likelihood of such errors, use {{subst:Requested move}} rather than manually formatting the request, provided that the template is installed and supported.

Possible causes and solutions include:

  • The request was added to an existing talk page section. Add a new section heading immediately above the {{Requested move/dated}} template.
  • Changing the automatically generated level-two heading to a level-three heading may be appropriate when the requested move belongs under an existing discussion.
  • The proposed destination is a redirect. Check the applicable requested move procedures to determine whether the request is appropriate or should instead be handled as a technical move.
  • The signature timestamp does not follow the expected system-generated format, such as HH:MM, D MMMM YYYY (UTC). Use a valid, automatically generated signature rather than manually changing the timestamp.

"Time could not be ascertained"[edit source]

If Bharatpedia uses a listing bot, a request may be placed in a special section when the bot cannot determine when the request was made.

Use {{subst:Requested move}} rather than manually formatting the request, provided that the template is supported. Possible causes and solutions include:

  • The request is not signed. Sign the request to provide a timestamp. If an editor is adding a signature on behalf of another person using {{Unsigned}}, the appropriate timestamp must also be supplied. For example, {{subst:unsigned|Foo|~~~~~}} uses five tildes to generate a timestamp. A valid timestamp copied from the page history may also be used, provided that it follows the required format and includes the time zone.
  • Remove any unnecessary comments or text following the timestamp if they prevent the bot from recognising it. Follow the actual limits and requirements of the Bharatpedia bot in use.
  • A missing endash (–) between the proposed move and its description may prevent the description from being recognised. Add the missing endash where required.
  • An unusually formatted signature or timestamp may prevent the bot from identifying the end of the proposal description. Use the standard signature format and correct the timestamp where necessary.

Header confusion[edit source]

Occasionally, two sections with the same heading may appear on a talk page. If a listing bot links to the wrong section, give the current requested move a distinct heading, such as "Requested move 2", or rename the older section to something more specific, such as "Requested move (month year)".

A duplicate heading for the same discussion may be removed if it is genuinely redundant and doing so will not remove useful discussion content.