විකිපීඩියා:ආයාචිත ගෙනයෑම්/නිමකිරීම සඳහා උපදෙස්

විකිපීඩියා වෙතින්
Jump to navigation Jump to search

The following are guidelines for closing Wikipedia:Requested moves discussions. Please only apply these after the normal seven day listing period has elapsed. These guidelines 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 uncontroversial requests section can be simply removed after they have been processed. Where uncontroversial moves are contested, move the listing to the incomplete and contested proposals section and notify the editor with {{RMinc}}.

Who can close requested moves[සංස්කරණය]

Conflicts of interest[සංස්කරණය]

In closing a discussion, it is important to avoid conflicts of interest, because such circumstances cast doubt on the fairness of the closure, and often make the closure unstable. Even the appearance of conflict of interest is worth avoiding, for the same reason. Remember that there is no harm in erring on the side of caution.

Apparent conflicts of interest can arise in different ways:

  • Any editor who has participated in a move discussion, either in support of the move or in opposition to it, will very likely not be seen as an unbiased judge of that discussion.
  • An editor who has previously closed a move request relating to the same article may not be seen as unbiased, especially if the previous request they closed is similar to the new request.
  • Conflicts of interest may arise, or appear to arise, in many ways, and it is good to be alert to these possible circumstances.

No user, whether an administrator or otherwise, should ever close an unwithdrawn requested move discussion in which they supported or opposed, and in which the result of discussion is not a unanimous result. However, it is fine for a discussion participant to close a requested move in the following circumstances:

  • If the discussion reaches a unanimous result after a full listing period (seven days).
  • If the nominator wishes to withdraw a proposal about which no one has yet commented, or which is unanimously opposed. In this case, the nominator may close the discussion as "withdrawn".
  • If the closer's participation in the discussion has been limited to clarifying questions, or is otherwise neutral with respect to the proposed move.

If any question of conflict of interest does arise, the best solution is for the potentially conflicted editor to recuse him or herself from closing the discussion, and leave it to someone who is more clearly neutral.

Non-admin closure[සංස්කරණය]

Experienced editors in good standing are allowed to close some requested move surveys.

Non-administrators should restrict themselves to moves:

  • Which result in unanimous or nearly unanimous discussions after a full listing period (seven days);
  • Where there is no contentious debate among participants;
  • Which do not require a history merge or history swap; and
  • Which do not have large numbers of subpages that need to be moved along with the move of the project page, such as voluminous archives (administrators have the ability to move up to 100 pages in a single click).

Where a move is not technically possible without administrative intervention, non-admins closing a discussion and then tagging the redirect with {{db-move|1=PAGE TO BE MOVED HERE|2=REASON FOR MOVE}} should be actively monitoring that speedy deletion request, and ready and willing to perform all tidying after the move (as instructed below), such as fixing all double redirects created and fixing fair use rationales of images included on the page. If you are not willing to wait for the deletion and follow up in this manner, please only close requested moves that do not require administrative abilities.

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.

Unlike articles for deletion, where lack of participation requires relisting, no minimum participation is required for requested moves because for most moves there is no need to make a request at all; the need arises only because of a technical limitation resulting from the target article name existing as a redirect with more than one edit. Thus, if no one has objected, go ahead and perform the move as requested unless it is out of keeping with naming conventions or is otherwise in conflict with applicable guidelines or policy. Further, any move request that is out of keeping with naming conventions or is otherwise in conflict with applicable guideline and policy, unless there is a very good reason to ignore rules, should be closed without moving regardless of how many of the participants support it. Remember, the participants in any given discussion represent only a tiny fraction of the Wikipedia community whose consensus is reflected in the policy, guidelines and conventions to which all titles are to adhere. Thus, closers are expected to be familiar with such matters, so that they have the ability to make these assessments.

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 the closer feels that no consensus has been reached, they may move the article back to the most recent stable name. If the most recent stable name is itself a matter of dispute, closers are expected to use their own judgment in determining the proper destination.

Relisting[සංස්කරණය]

If a discussion is ongoing or has not reached a reasonable conclusion, you may elect to re-list the discussion, though it is entirely optional and up to the closer. Relisting simply consists of stating Relisted. ~~~~, or some variant; see this diff for an example. This gives the request a new timestamp which RM bot will use as the date to relist the entry on the requested moves project page. (You may also relist the discussion with {{subst:relisting}} )

If the discussion has become stale, or seems that it would benefit from the input of more editors, some editors will notify at least one relevant WikiProject of the discussion, in addition to (or instead of) relisting it. These WikiProjects can often be found by means of the banners placed at the top of many articles' talk pages.

Moving procedures[සංස්කරණය]

Edit history of destination page[සංස්කරණය]

The majority of target names for move requests already exist as redirects to the present names. Whether a redirect or otherwise, that existing target title should be investigated to see whether it has a minor or major page history. If it has a minor page history, generally meaning it only existed as a redirect, and was never a duplicate article, never had content that was cut and pasted to the present title, nor merged there, it may simply be deleted. However, if the target page title has a major history it should never be simply deleted, as we need to retain such page histories for proper copyright attribution. There are three ways to deal with target pages with major histories, dependent on circumstances. In the event this situation presents itself on a move, click "show" below for instructions.

Cleaning up after the move[සංස්කරණය]

It is important that you clean up after any move you perform. Accordingly, you should not close any move if you are unwilling to do the necessary clean up tasks listed below.

Fixing double redirects[සංස්කරණය]

Moving a page changes any redirects that pointed to the original page location, into double redirects. These make for an unpleasant experiences for the reader, waste server resources, and make the navigational structure of the site confusing. It is the responsibility of the closer to fix these. Periodically a bot will attempt to fix any double redirects missed but that does not relieve the closer of the responsibility which should be handled soon after the move.

The "move succeeded" summary page that you are taken to directly upon a move provides a link entitled "Check what links here" specifically geared to listing offending double redirects created by a move. Fix any double redirects shown on the resulting page.

Some talk pages, archive pages and subpages that you may also have been moved, may also have had redirects that have become double redirects. These associated moved pages are listed at the bottom of the move succeeded page. Open up the prior page names (which should now be themselves all at redirects) and click on "What links here" in the toolbox on the left hand side of the page, then click on "Hide transclusions" and "Hide links". This is the manual procedure to perform the same search the move succeeded page provides with the "Check what links here" link noted above.

Fixing fair use rationales[සංස්කරණය]

Please check whether there are any images on the moved page with fair use rationales (any Commons images can be immediately excluded, easily recognizable by the logo on the image page: Commons-logo.svg). If you find such fair use images images present, change all mentions of the prior article name, to the retitled name, so that the image is not marked for deletion as orphaned.

Fixing category sort keys[සංස්කරණය]

Many pages have a template above the page categories in the form {{DEFAULTSORT:Name}} Where the name field provided in the template is the old title of the page (pages are sometimes categorized in other ways), change it to the new title. Alternatively, in some pages categories are piped in the category links themselves, e.g., [[Category:Monty Python films|Name of Film]]. In the example you would fix the name of the film.

Fixing hatnotes and DAB pages[සංස්කරණය]

Though not as common as the above, a move may occasionally render a hatnote obsolete. The documentation page at {{Hatnote templates documentation}} may be instructive in finding a suitable replacement, if one is needed. Often the reason for the hatnote is because there is either a disambiguation page related to the topic, or another topic pointing to yours and vice-versa per WP:TWODABS. In such cases you should visit either the DAB page or the other article with the hatnote, and replace the old name of the article you have just moved, with its new name.

Closing the requested move[සංස්කරණය]

When you complete an entry on the project (whether the move was accepted or rejected), don't forget to remove the {{movereq}} tag from the talk page (or change "movereq" to "movereq old"). You should also add and sign a comment to indicate whether the move was accepted or rejected in the discussion area for the requested move. This can take the form of an informal note or a more formal close (see below).

There are a few options for formally closing the move request survey on the affected article's talk page. One is to use the templates {{subst:RM top|Closing decision and comment}} and {{subst:RM bottom}} (although some editors prefer {{polltop}}/{{pollbottom}} or {{discussion top}}/{{discussion bottom}}). The other is just to leave a statement like "This article has been renamed per the above move request". For requests that for some reason did not apply, you can use {{notmovedmalformed}} or a similar statement based on the circumstances.

Removing any relevant {{movenotice}} tags[සංස්කරණය]

Users who have initiated move discussions may have also tagged the relevant pages with {{Movenotice}} to draw attention to the proposed move. After closing, these tags should also be removed.

Bot considerations[සංස්කරණය]

Malformed requests[සංස්කරණය]

A request will be listed in a special section on Wikipedia:Requested moves if the listing bot cannot ascertain the date on which the request was made. There are two causes of this:

  1. The {{move}} template was not substituted, and as a result, the expected [[OldName]] → [[NewName]] string is not found on the page. • To fix this, substitute the {{move}} template, and the bot will list the request anew.
  2. If the template is a bare {{move}} without any page specified. • In that event, try to figure out what the intended request was; otherwise, use {{subst:move|?}}.
  3. 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.

Header confusion[සංස්කරණය]

Because the instructions state that the talk page section containing the move request should be called "Requested move", and {{subst:RMtalk}} creates a section called "Requested move", occasionally two sections with the same name will appear on a talk page. When this happens, the bot will link to the first one, even if the current move request is the second one. This can be remedied by giving the section containing the current move request a different name, such as "Requested move 2" or "Requested move (month year)".
https://si.wikipedia.org/wiki/%E0%B7%80%E0%B7%92%E0%B6%9A%E0%B7%92%E0%B6%B4%E0%B7%93%E0%B6%A9%E0%B7%92%E0%B6%BA%E0%B7%8F:%E0%B6%86%E0%B6%BA%E0%B7%8F%E0%B6%A0%E0%B7%92%E0%B6%AD_%E0%B6%9C%E0%B7%99%E0%B6%B1%E0%B6%BA%E0%B7%91%E0%B6%B8%E0%B7%8A/%E0%B6%B1%E0%B7%92%E0%B6%B8%E0%B6%9A%E0%B7%92%E0%B6%BB%E0%B7%93%E0%B6%B8_%E0%B7%83%E0%B6%B3%E0%B7%84%E0%B7%8F_%E0%B6%8B%E0%B6%B4%E0%B6%AF%E0%B7%99%E0%B7%83%E0%B7%8A
si.wikipedia.org
crawl=CC-MAIN-2022-27
100732
application/http; msgtype=response
sha1:MXI6AK6EKXSX4XPYFD4ITQWQVIO6YNJ4
<urn:uuid:30eaffba-8f3a-49d4-9b00-0caf5fe75753>
2022-07-04T10:02:15Z
208.80.154.224
text/html
sha1:4E2WFBVDF4XXEYIAUEXRHJPKHI4L76TC
<urn:uuid:c05cc683-6ab2-4aae-b1ef-b67b2f62e7db>
https://si.wikipedia.org/wiki/%E0%B7%80%E0%B7%92%E0%B6%9A%E0%B7%92%E0%B6%B4%E0%B7%93%E0%B6%A9%E0%B7%92%E0%B6%BA%E0%B7%8F:%E0%B6%86%E0%B6%BA%E0%B7%8F%E0%B6%A0%E0%B7%92%E0%B6%AD_%E0%B6%9C%E0%B7%99%E0%B6%B1%E0%B6%BA%E0%B7%91%E0%B6%B8%E0%B7%8A/%E0%B6%B1%E0%B7%92%E0%B6%B8%E0%B6%9A%E0%B7%92%E0%B6%BB%E0%B7%93%E0%B6%B8_%E0%B7%83%E0%B6%B3%E0%B7%84%E0%B7%8F_%E0%B6%8B%E0%B6%B4%E0%B6%AF%E0%B7%99%E0%B7%83%E0%B7%8A
response
<urn:uuid:c6fc355a-cf71-4fc9-a277-efb5e9b157d5>
isPartOf: CC-MAIN-2022-27
publisher: Common Crawl
description: Wide crawl of the web for June/July 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-180
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.3-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/