Jump to content

Wikipedia talk:Page mover/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Repairing WP:MALPLACED dab pages

Thanks Andy W. for creating this script. It will be very helpful for users who wish to perform uncontroversial page moves that cannot be done because a page is in the way.

As a matter of fact, I have seen one excellent way the developer has put his script to good use: take a look at the history of the pages listed as "malplaced" disambiguation pages. I have a habit of checking this list weekly and tagging pages that could not be moved with {{G6}}. The developer was able to move them all to their proper locations, and that is impressive and so I thought, "why not mention malplaced dab pages as a possible use for this new user right? It would save valuable time having to wait for administrators to delete the page and make the move themselves." As a user with the page mover right, now I can take care of it myself!

So why I am posting here? It's because I'd like to propose making a special use case for the page-swap procedure specifically for making these kinds of repairs. For example, the developer used the comment "db-move malplaced dab". This can easily be added to the description once it has been made (I have actually commented in such an addition just now), and I find this an excellent opportunity to bring this often-neglected but necessarily important concept to greater prominence. As such, I'd like to collect suggestions about whether this is worthy or not. I believe it is, and is going to change the way WPDAB takes care of matters like these!

Best, <<< SOME GADGET GEEK >>> (talk) 00:57, 28 August 2016 (UTC)

@Some Gadget Geek: Thanks, and no problem. I think you're referring to this? I didn't create Talk:One Way Ticket (disambiguation) as a redirect because nothing linked to it. Some Gadget Geek, feel free to use the script yourself as a page mover for similar moves if you'd like :)
I think your dab example isn't too distinct from the case when A ("Bonjour (disambiguation)") is the main page, and B ("Bonjour") is a redirect to A, which is covered in WP:PMVR#rr. There are some slightly anomalous cases where there are talk pages (and subpages) of both pages to be swapped. Handling these is probably case-by-case. I found those dab moves at the CSD category, and hence the edit summary I gave. Another possible venue to list these is at WP:RMT.
FYI, there's a similar scenario described at WP:RMCI#Moves of disambiguation pages to primary topic titles that seems to be a twist on the case you gave above (and needs a more complicated cleanup). — Andy W. (talk · ctb) 01:40, 28 August 2016 (UTC)

Moving subpages should be the default action

Tracked in Phabricator
Task T141545

No admin came forward to close this discussion and we have near-unanimous agreement among people involved, therefore I hereby invoke rule #1 of WP:ANRFC: Many discussions result in a reasonably clear consensus, so if the consensus is clear, any editor—even one involved in the discussion—may close the discussion. The proposal that moving subpages should be the default action is agreed and we can take action to implement it technically. — JFG talk 09:59, 28 July 2016 (UTC) Followed up in subsection below. — Andy W. (talk · ctb) 16:06, 6 October 2016 (UTC)

The following discussion 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.

I reckon that cases where subpages should not be moved are exceptional, whereas moving subpages is the routine expected behaviour. It's easy to overlook the relevant check box, especially when moving an article page where the only subpages are archives of its Talk page. Catching those archives after the fact can be burdensome and error-prone when there are many such subpages (see Talk:Syrian civil war for a recent case). Therefore I suggest that the option labeled "Move subpages" or "Move subpages of talk page" should be checked by default. Opinions welcome. — JFG talk 09:29, 6 July 2016 (UTC)

Personally would strongly support making this default in the software to keep subpages organized. Is it checked by default for sysops? — Andy W. (talk · ctb) 15:04, 6 July 2016 (UTC)
No. — xaosflux Talk 19:13, 6 July 2016 (UTC)
Not many comments yet… Pinging the regulars here and some frequent page movers, @QEDK, Xaosflux, Coffee, Anthony Appleyard, Godsy, Omni Flames, Anarchyte, BU Rob13, Jenks24, Music1201, SMcCandlish, PaleAqua, Ivanvector, IJBall, SSTflyer, Amakuru, QEDK, Some Gadget Geek, Tavix, Epicgenius, GeneralizationsAreBad, Oshwah, RGloucester, and MrX:, any opinions on this suggestion? (Sorry for spamming!) — JFG talk 15:58, 11 July 2016 (UTC)
Yes, I think moving subpages should be the default action. I can't think of a situation where subpages shouldn't be moved. — Music1201 talk 16:00, 11 July 2016 (UTC)
I'd support this. —Compassionate727 (T·C) 16:01, 11 July 2016 (UTC)
Would prefer it not to be honestly, but if the majority feel the opposite then that's fine. I think that, generally, if moving subpages is an option a bit of care first needs to be taken in actually looking at the subpages and seeing if they should be moved (often they can be redirects or something that shouldn't be moved). Also you almost never want to move subpages when doing histmerges or anything tricky like that. Just my two cents, as I say if the majority think it would be useful then I won't stand in the way. Appreciate the ping. Jenks24 (talk) 16:05, 11 July 2016 (UTC)
I agree with the proposed default behavior. Ideally, it would be configurable on per user basis. - MrX 16:07, 11 July 2016 (UTC)
I like the configurable idea. It would be even better if all the boxes were configurable; I'd consider unticking watchlist by default. Jenks24 (talk) 16:11, 11 July 2016 (UTC)
I'm kind of ambivalent (although leaning towards default), but I think a "per user basis" is a good idea. GABgab 16:45, 11 July 2016 (UTC)
Not sure how heavily watched this page is - perhaps a user-script to check the box would be the best option for now? — xaosflux Talk 16:17, 11 July 2016 (UTC)
  • @JFG and Andy M. Wang: As above, the "move the subpages" box should be ticked by default. And add a link to click to get easily a list of the names of those subpages, both the article's subpages and its talk page's subpages if applicable. Anthony Appleyard (talk) 16:19, 11 July 2016 (UTC)
  • Suggestion: Switch from checkbox to radio buttons with neither set as default. Force a conscious selection from the page mover. Support Anthony's idea of a list of subpages. for (;;) (talk) 16:24, 11 July 2016 (UTC)
  • The list would avoid such surprises as recently when I was asked to move a page and it had more than 500 !!!!! subpages. Anthony Appleyard (talk) 16:25, 11 July 2016 (UTC)
  • Default or force making a choice. List seems like a good idea, I've had to fix split page moves before. Associated subpages ( i.e. talk subpages ) need to be included in the list. That said when I go to the move page form it shows the subpages at the bottom but not the associated subpages. (I'm not a page mover here so not sure what would be different). I wonder if page moves that leave orphan subpages should be tagged some how as they can get left behind. For example recently fixed a talk subpage that got lost over a series of moves.[1] (edit conflict) PaleAqua (talk) 16:50, 11 July 2016 (UTC)
  • Support as the default, or forcing making a choice. While the latter option would slow down rapid-fire moves of things that usually have subpages, like templates and their /doc pages, that's probably not a bad thing. I'm glad that the code below will work in the interim. It just seems like a math matter to me: The number of times one needs to move subpages (/doc, talk archives, sandboxes and testcases, wikiproject subpages, etc., etc.) is going to outweigh (considerably) the number of times it is desirable to "orphan" a subpage or do a histmerge (and TE's can't do that, so maybe have this on/off-by-default thing vary between TEs and admins). The ultimate feature would be a widget near the checkbox that expanded to a checklist, so that you could show the list, check the box above it to check all the boxes in the list, then uncheck one that should not move, or show them all and check two that should move and leave the rest in place, or whatever.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:08, 11 July 2016 (UTC)
  • I support having that option ticked by default (and the choice to untick the box). Except in some vandalism situations, maybe... I also don't see any routine or typical situation where moving subpages would not be preferred over moving them. ~Oshwah~(talk) (contribs) 21:01, 12 July 2016 (UTC)
  • Looks like I'm outvoted here and fair enough. I'd suggest someone who knows what they're doing create a phab ticket for it. Jenks24 (talk) 09:49, 13 July 2016 (UTC)
  • This is the general case, I find one hard to find where you'd find a need to not tick that checkbox (except bad moves i.e.). But what we need is another bit of code so that when you move an associated talk page, you should also be able to move the talk page's subpages (which I believe is the subject of the phab ticket). --QEDK (T ☕ C) 17:24, 14 July 2016 (UTC)
  • @Xaosflux: We seem to have consensus on making "Move subpages" the default action. Is this feasible with a global setting or does it need developer attention? — JFG talk 14:23, 20 July 2016 (UTC)
    JFG There are many "ways" this can be implemented, someone should close this RfC to document the consensus. Using enwiki's Mediawiki:common.js to basically implement the DYI option below may be the simplest. Posting at Mediawiki_talk:common.js would be the best place to ask. — xaosflux Talk 14:29, 20 July 2016 (UTC)
@Xaosflux: Great, thanks! I'm willing to ask for this change at Mediawiki_talk:common.js but you're right, we need an uninvolved volunteer to close this discussion first. Tagging it as an actual RfC to raise attention. — JFG talk 14:39, 20 July 2016 (UTC)

List of pages

Tracked in Phabricator
Task T140026

Are pagemovers not seeing the list? When I press move at the bottom of the action page is "Subpages" listing all the pages. — xaosflux Talk 16:43, 11 July 2016 (UTC)

It shows up for me under the move log. Rebbing 16:49, 11 July 2016 (UTC)
I can see subpages of templates but I can't see archives of talk pages, and that's the most common case where overlooking the checkbox leads to trouble… — JFG talk 17:23, 11 July 2016 (UTC)
@JFG: Are you sure? I'm seeing plenty of archive and good article subpages here. Rebbing 17:38, 11 July 2016 (UTC)
@Rebbing: Because you're moving the talk page itself, not moving the article and ticking "move associated talk page". —Compassionate727 (T·C) 17:39, 11 July 2016 (UTC)
@Compassionate727: Oh! right. Thank you. So, even though associated-page subpages don't show up in the list, are they still moved? Rebbing 17:45, 11 July 2016 (UTC)
(edit conflict)  Works for me — xaosflux Talk 17:42, 11 July 2016 (UTC)
  • example 1
    example 1
  • example 2
    example 2
@Xaosflux: Fine if you move Talk:Chess explicitly, but try moving Chess instead… — JFG talk 17:48, 11 July 2016 (UTC)
@JFG: I see - I think the best option here wold be to file a phabricator task to add this functionality to that page. — xaosflux Talk 18:25, 11 July 2016 (UTC)
@Xaosflux: I have no experience with Phabricator and no time to learn my way through it this week; could somebody kindly formulate the feature request there? — JFG talk 21:22, 11 July 2016 (UTC)
OK I added phab:T140026 - you should follow that link and subscribe. NO IDEA when/if a dev will pick this up. — xaosflux Talk 22:03, 11 July 2016 (UTC)

DIY option

No matter what the default is going to be, you can set your own default by adding a little code to your common.js: 

/*
 * Automatically tick the "Move subpages" option when moving pages.
 */
var moveSubpagesBox = document.getElementsByName("wpMovesubpages")[0];
if (moveSubpagesBox !== undefined) {
  moveSubpagesBox.checked = true;
}

Cheers. Rebbing 16:32, 11 July 2016 (UTC)

Seems to actually want if (moveSubpagesBox !== null).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:13, 11 July 2016 (UTC)
Good catch—I updated my code. I meant "if moveSubpagesBox is not actually null", not "if moveSubpagesBox is not equivalent to null." (JavaScript isn't my native language.) Just curious, but could this actually make a difference here? That is, can a DOM element ever evaluate to null? Rebbing 17:34, 11 July 2016 (UTC)
Thank you, Rebbing, SMcCandlish - with this being so easy for those who want it, I'm in support of this method instead of a site-wide (or mediawiki wide!) change. — xaosflux Talk 17:20, 11 July 2016 (UTC)
@Rebbing: Actually, when I tried the !== version (per the error "Warning: Use '!==' to compare with 'null'."), it broke something else in my common.js page. I went back to != and the broken thing unbroke. Not sure what to make of this. I see another alleged error in that file, much further down, but after staring at the code, I don't see that it has an error in it, which suggests to me that the real error is somewhere else on the page. So, basically, ignore my debugging attempts until I figure out what's broken in my own common.js. I have all sorts of scripts in there from various people, so I'll probably have to remove them one by one to isolate the issue.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:45, 11 July 2016 (UTC)
@SMcCandlish: Eee, good luck with that. Also, I've confirmed that my snippet works either way, so it should stay as-is (with the !== bit.) Rebbing 17:49, 11 July 2016 (UTC)
@SMcCandlish: ...but I forgot to test for failure on pages without the move checkbox. The problem was that the first element of an empty array is undefined, not null. My first attempt worked because null == undefined. I've updated both this example and the code on the project page. Thanks for your help. Rebbing 21:02, 11 July 2016 (UTC)
Most welcome, to the extent it was helpful. :-)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:05, 11 July 2016 (UTC)
Very useful, thanks! In spite of this hack being available, I still think we should make moving sub-pages the default choice; comments above seem to support the suggestion, but obviously I'm biased. Could an uninvolved admin/tech expert assess the consensus here and request this change in the appropriate forum? — JFG talk 21:22, 11 July 2016 (UTC)
I agree—it does seem like the more sensible default. I'd particularly like to see the page handle associated subpages. Also, since moving subpages is the norm, I have to ask: why is it reserved for page movers and admins? Rebbing 21:29, 11 July 2016 (UTC)
@Rebbing: If a subpage move goes awry, it would go awry for dozens of pages, not that correcting it may be quick, but it can lead to a great mess if not used correctly. Subpage-moving is much more widespread and has the potential of breaking incoming links or causing unwanted effects on WhatLinksHere. Granted, it keeps pages organized, but it's easier to handle page move vandalism if the moves are not so numerous or widespread in general. So it's mostly preemptive in my understanding. Thanks for the DIY js option by the way — Andy W. (talk · ctb) 21:44, 11 July 2016 (UTC)

Thanks for the ping. I'm not fussed either way about this to be honest, though I can see why it might be useful given that it is the more usual option to choose, just as "move talk page" is, so happy to give a mild support. As Jenks says above, it's important to think about the impact of what you're doing either way. I would hope that people who are moving pages with complex structures, and especially those who have been granted the page mover or sysop privilege, are not the types to blindly accept whatever checkboxes are thrown at them anyway! Thanks  — Amakuru (talk) 21:39, 11 July 2016 (UTC)

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.

Technical implementation

Tracked in Phabricator
Task T141545

JFG Has the method for how to implement this been decided? (e.g. site javascript?) — xaosflux Talk 11:59, 28 July 2016 (UTC)

@Xaosflux: Not yet. I'd go with your suggestion of requesting a change in the site-wide common.js (seeing how the personal setting works fine). — JFG talk 12:50, 28 July 2016 (UTC) : Done I filed the request now. — JFG talk 13:34, 28 July 2016 (UTC)
I'd suggest if this is made to apply to admin moves as well that some sort of notice is made. Not sure how many admins watch this page, and it could lead to unexpected subpage moves / not moves during the transition. PaleAqua (talk) 14:07, 28 July 2016 (UTC)

Wanted to follow up that I've become opposed to having "movesubpages" be default on the mainspace to users who have them on enwiki. For some background, JFG opened the discussion above after my own suggestion on move specs at his talk. In the past few months, I've had to correct a couple malmoved talk pages of articles and put re-join them to their intended articles. (see WP:Page mover#Move-subpages for the scenario) An example: see Special:PrefixIndex/Talk:5/ for instance. If the page 5 is ever moved, Talk:5/16 inch star should not move, because it is the talk of 5/16 inch star, not a subpage of Talk:5. I suspect that making the option default will results in many more incorrect moves, not just by page movers. I've updated the phab ticket to address this. If anyone had comments, please ping. (JJMC89, courtesy ping, opener of the ticket) — Andy W. (talk · ctb) 05:00, 6 October 2016 (UTC)

Wow, good catch there Andy! The overloading of the "/" separator is unfortunate. Still, the most-frequent case is talk pages with lots of archives. Perhaps we could restrict the default move to include all "$PAGENAME/Archive*" subpages? In any case, it becomes all the more important to see a list of subpages prominently displayed on the move confirmation screen. — JFG talk 07:00, 6 October 2016 (UTC)
@JFG: Whoa, I can't see that being approved, even if "/Archive" is well-established here locally on enwiki. There are also /GA1, /FAQ pages, etc. Don't think the software needs to be aware of all that. Could instead elevate phab:T140026 — Andy W. (talk · ctb) 07:19, 6 October 2016 (UTC)
Just realized my revision of that ticket is not 100% valid. Technically, moves could involve as many as 4 namespaces (such as moving "Wikipedia:Foo" +talk+subpages to "Draft:Foo"). Will come back to this within 24 hours... — Andy W. (talk · ctb) 07:26, 6 October 2016 (UTC)
@JFG: Invoking Wikipedia:Closing discussions#Challenging other closures. The close can change if significant additional information or context was left out of the discussion and the closer was not aware of it I daresay the implications of mainspace not supporting subpages (the well-being of non-related talks in particular) qualifies as additional information/context left out. This discussion was not tagged nor was made as visible as it could to folks who have a stake in the action (namely, most other sysops), and perhaps a slightly wider venue could help gauge consensus for it...? Hope that's understandable. As one of the initial suggesters and advocates who've become opposed, I'll also be closing the ticket for now. It's reasonable to say I initially pinged you about making subpages default, and new issues have come to light that have not been discussed above.
I already followed up above that perhaps the notion of making it default should apply when both the subject and talk namespaces relevant to the move support subpages. Although I've realized this a fallacy: in many situations, the issue concerns both source and destination namespaces, which could be completely different, and it can be impossible to know offhand (pre-move) the namespace pair of the destination. Today, there is no default move confirmation dialog either.
This may be a bold move on my part, but I believe leaving the move config as-is is safer for reasons I highlighted above less than a day ago. Feel free to follow-up as needed. Thanks — Andy W. (talk · ctb) 16:06, 6 October 2016 (UTC)

Watchlists

FYI: The subsection, "Watchlists", I just added results from a notification on my talk page and an ensuing discussion at WT:Requested moves#Watchlists. I was unaware that my continued use of the same holding page, Draft:Move/pet page, added new, unwanted pages to users' watchlists, and I'm concerned that others might be using a distinctive page title as well. I thought it best to make others aware that the holding page should have a different title each time it is used for page swaps.  Paine  u/c 03:15, 4 November 2016 (UTC)

Discussion regarding redirect suppression at AN

I've started a discussion about a possible situation where redirect suppression may be used improperly at WP:AN#Possible improper use of page move redirect suppression. Editors watching this guideline page may be interested in that discussion. Ivanvector (Talk/Edits) 12:48, 10 March 2017 (UTC)

Proposal to add a new redirect suppression criteria regarding edit notices

I recently discovered what is possibly another reason a page mover may need to suppress a redirect. I believe that page movers should be allowed to suppress redirects when they need to move a subpage of Template:Editnotices to match the name of the parent page. So, here's my proposed addition to Wikipedia:Page mover#Redirect suppression criteria:

No. Criteria Shortcut
8 For non-admin page movers with the template editor user right only: Moving an editnotice to a subpage of Template:Editnotices to marry the editnotice with its appropriate page. (WP:CSD#G6) WP:PM/C#8

Thoughts on this? Steel1943 (talk) 06:40, 10 August 2017 (UTC)

Seems reasonable. — xaosflux Talk 11:33, 10 August 2017 (UTC)
  • Meh. Not opposed, but also don't really think it is necessary: page movers are already allowed to suppress redirects at their own discretion if any of the speedy deletion criteria could reasonably be said to apply: just type why in the move reason box. This is also only going to affect a very small subset of editors. If anything, I'd support reinforcing the existing text with a criteria that simply says Any other reason where the resulting redirect could be reasonably construed to meet the criteria for speedy deletion. TonyBallioni (talk) 13:59, 10 August 2017 (UTC)
    @TonyBallioni: I do not disagree with your idea to generalize the use of speedy deletion criterion in the least. I drafted this proposal to strictly go in line with the current formating of the section; that, and the section's current format seems to need/require specific examples of applications rather than generalizations. I like your idea though, and would definitely support such a change to the section. (However, I think the section is also there to give page movers ideas of what tasks they could perform ... if they are ever looking for something to do.) Steel1943 (talk) 16:44, 10 August 2017 (UTC)
    Steel1943, the current format lists reasons that are universally accepted as good reasons to suppress a redirect, but it is based on the guideline in the text above that make it clear that suppressing a redirect is to be used whenever it would otherwise require speedy deletion. I think the additional criteria you just proposed above is an example of something that is already allowed under current policy (clearly G6 eligible). I'd be fine with adding it, but I also think there are probably other G6-type suppressions that we currently don't have listed but would be reasonable to preform. Adding a catchall to the actual table expresses the bold but not reckless ideal that we want people to use on Wikipedia.
    TL;DR: I'm fine with adding WP:PM/C#8, but since we're on the topic, I'd like something like my above suggestion to be codified as WP:PM/C#9 as well :) TonyBallioni (talk) 16:58, 10 August 2017 (UTC)
  • Support –That would be useful and would do no harm. — JFG talk 18:06, 10 August 2017 (UTC)
  • Support seems reasonable, especially since I've just used it. Cabayi (talk) 18:32, 10 August 2017 (UTC)
    @Cabayi: I completely forgot that editnotices can appear at an incorrect parent page; thus, I just tweak the wording of my proposal a bit. Steel1943 (talk) 19:11, 10 August 2017 (UTC)
Due to fading participation in this discussion, I will add the new criteria shortly. (Also, TonyBallioni, are you still interested in proposing the 9th criteria? I have sort of lost track about what is going on, but a new proposal may help clear that up.) Steel1943 (talk) 03:25, 1 September 2017 (UTC)
  • Dropping a note here that all the criteria is not a case for strict-use policy but only means to highlight some common criteria. When the right was made, we didn't have a RfC to determine strict criteria (Godsy added them after/before iirc) and such is not required either - since this is primarily a discretionary right. I recommend you just be BOLD and add it. --QEDK (愛 • 海) 06:49, 2 September 2017 (UTC)
  • Prefer TonyBallioni's version, but also support the original idea if that's all we'll add.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:58, 10 September 2017 (UTC)
  • Sorry I missed the previous ping. I went ahead and added 9 as suggested above since there doesn't seem to be opposition to it, and there is some support. It will hopefully prevent the need in the future of listing out every possible use. TonyBallioni (talk) 16:07, 10 September 2017 (UTC)

Page movers implementing a primary topic

Imagine this scenario: there is no primary topic, so a disambiguation exits at [[Base title]]. Per conventions, [[Base title (disambiguation)]] redirects to [[Base title]], for the purpose of enabling intentional links to disambiguation. Now imagine that a consensus has formed that [[Base title (album)]] is the primary topic for [[Base title]]. The implementation procedure is to first move [[Base title]] to [[Base title (disambiguation)]], overwriting the redirect, without leaving a redirect behind, and then move [[Base title (album)]] to the newly-vacated [[Base title]]. Fine so far.

Now imagine a road block has been thrown up for page movers: [[Base title (disambiguation)]] has non-trivial history, so they can't move over the top of that redirect. What to do? There is nothing to swap this page with, as this scenario is like a game of musical chairs where a chair has been removed. Moving it to [[Base title (disambiguation) (disambiguation)]] is unnecessary and not supported by policy. Is there a solution for page movers, such as moving to some form of official "trash dump" where we can keep this unneeded crud hanging around without deleting it, or should the page mover request administrator help in this situation? wbm1058 (talk) 23:03, 8 September 2017 (UTC)

This is kind of difficult to understand without a specific example or two. Blueboar (talk) 23:50, 8 September 2017 (UTC)

How would a page mover perform these moves, if there is consensus for them:

@Wbm1058: This is actually one of the easiest types of moves to implement. It simply requires two round-robins and no editing to fix the redirects.
  1. Round-robin [[Base title]] and [[Base title (album)]]. The album is now at the primary topic and the disambiguation page is at the album page.
  2. Round-robin the new [[Base title (album)]] and [[Base title (disambiguation)]]. This results in [[Base title (album)]] correctly pointing as a redirect to the primary topic (so as to avoid breaking Wikilinks), and the disambiguation page being at the correct title.
If I have misunderstood your question, please let me know. TonyBallioni (talk) 16:35, 10 September 2017 (UTC)
Thanks, the has been turned on. You understood the question. Having never been a page mover before becoming an admin, I never had to contemplate this before. These instructions should be added, as a second scenario and example, to Wikipedia:Page mover § Round-robin page moves. What not to do as step 1: Round-robin [[Base title]] and [[Base title (disambiguation)]]. I've seen that done, which is what led to me starting this discussion. – wbm1058 (talk) 21:57, 10 September 2017 (UTC)
That would be a bit more obnoxious, but you could still do it. The steps would look like this:
  1. Round-robin [[Base title]] and [[Base title (disambiguation)]]
  2. Round-robin [[Base title]] and [[Base title (album)]]
  3. Manually retarget the redirect at [[Base title (album)]] that points at [[Base title (disambiguation)]] to point at [[Base title]].
The two-step version is easier, of course, but you can do it either way. TonyBallioni (talk) 22:05, 10 September 2017 (UTC)
This three-step procedure is, as you say, more "obnoxious". You end up with the history of an ambiguous title dumped into the history of a less-ambiguous title or an outright unambiguous title.
While this can be fairly benign if there isn't significant history there (maybe only one bot edit to tag with {{R to disambiguation page}}), there is also the chance of a disambiguation fork and even residue from a merge of two disambiguation histories, or an uncorrected cut-paste move of the disambiguation. For example, Coppel_(disambiguation) has a muddy history. The less-than-optimum three-step would leave that history in Coppel (department store), an unambiguous topic. Granted the history would be hidden such that few would notice if the manual retarget were completed, but if it isn't then confused editors could make it worse trying to fix it. You also may need to retarget [[Talk:Base title (album)]] and if that's not done then red flags may be thrown up due to templates stating it's a redirect to a disambiguation page when it's not anymore. To avoid all that, the two-step you first suggested should be strongly encouraged. While the three-step that includes manual retargeting may be marginally acceptable (it's the borderline logical equivalent of a cut-paste leaving an inconsistent-scope page history), I still think the page-mover instructions should discourage doing it that way. – wbm1058 (talk) 15:04, 11 September 2017 (UTC)
I've added the above example to the page. Please feel free to make any changes that would make it clearer for people. TonyBallioni (talk) 17:57, 11 September 2017 (UTC)

I just use pageswap.js and re-target any malplaced redirects. Why go through all this hassle when there's a semi-automated tool to do it for you? DrStrauss talk 19:33, 13 September 2017 (UTC)

I use pageswap too: you still have to follow one the above methods. The two-step method works with the tool as well. TonyBallioni (talk) 19:40, 13 September 2017 (UTC)
@DrStrauss: Please use the two-step method. It should actually be easier to do that way. Again, I had to clean up after your move of Salt water. – wbm1058 (talk) 16:56, 18 September 2017 (UTC)
TonyBallioni, can you add specific instructions to Wikipedia:Page mover § Establishing a primary topic that explain how to do it with the pageswap tool? Thanks, wbm1058 (talk) 17:34, 18 September 2017 (UTC)
@DrStrauss and Wbm1058: I've added this. The same exact procedure would be followed using pageswap. TonyBallioni (talk) 17:46, 18 September 2017 (UTC)

The tool is pretty neat. Every once in a while admins need to do swaps due to previously merged content forks, per WP:RMCI#Edit history of destination page (show the section on Procedure for redirects with major histories). I just installed pageswap.js and used it to swap-move Sonia Olschanezky. Nice. wbm1058 (talk) 19:26, 20 September 2017 (UTC)

RfC: Labeling page mover closures

There appears to be no consensus to support this change.

The primary rationale given in opposition seems to center around there being no inherent trust in those holding the page mover flag to judge consensus—at least, not any better than other non-admins without the flag—and should therefore be treated the same / not implied to be in any way special in the context of the closure.

Those in support seemed to feel that it was merely informative, and some felt it actually should connote that a user is likely to have greater experience just by gaining the flag.

--slakr\ talk / 02:10, 27 September 2017 (UTC)

The following discussion 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.

Should move discussions closed by page movers be labeled as such? — JFG talk 23:43, 17 July 2017 (UTC)

Anyone may close a move request, although non-admin closers are required to include a "(non-admin closure)" signature as a courtesy to other editors, via the {{RMnac}} template. A year ago, shortly after the page mover right was implemented, it was decided to create a special signature {{RMpmc}} for page mover closures, but to display the same message "(non-admin closure)". The {{RMnac}} version links to WP:RMNAC while the {{RMpmc}} version points to WP:RMPMC, a subsection of non-admin closure instructions dedicated to page movers.

Following a discussion on my talk page, I would like to gauge if consensus has changed. I contend that it would be more informative to discussion participants, admins and move reviewers to clearly label closures by page movers with a different text, such as "(closed by page mover)". Naturally, this does not confer more authority to such closes, as any move review must be evaluated strictly on the merits of the case, irrespective of who closed it, be they a newbie, an admin, a page mover or a BDFL.

I have enabled the alternate text and updated the documentation as a WP:BOLD experiment (with limited impact: few people have ever used {{RMpmc}} anyway – fewer than 200 in a year, out of thousands of RM closures). We can adjust or revert the text accordingly once this RfC is settled.

Finally, if the proposal is approved, I suggest adding the following paragraph to the WP:RMPMC guideline:

Page movers should use the special {{RMpmc}} signature as a courtesy, especially for sensitive cases. Like other editors, page movers should exercise caution when evaluating the outcome of contentious debates. When in doubt, don't close.

Let the comments flow! — JFG talk 23:43, 17 July 2017 (UTC)

Survey

Please indicate whether you Support (use "closed by page mover" or some equivalent text) or Oppose the change (use "non-admin closure" only), and provide a brief rationale. Longer arguments go to #Discussion.
  • Oppose Page move was intended to help with technical moves and does not grant special authority in making such closes. Would support ( but not prefer ) a change that says "non-admin closure (page mover)" or the like. PaleAqua (talk) 14:05, 18 July 2017 (UTC)
  • Support - This will be slightly more informative for participants in a RM. Perhaps "closed by page mover" would be slightly better wording. I don't understand the opposing argument that page mover does not grant special authority. It seems like a straw man argument.- MrX 14:48, 18 July 2017 (UTC)
@MrX: There was a typo in the survey heading: the proposed text is indeed "closed by page mover", not "closed as pm", thanks for spotting it. — JFG talk 14:53, 18 July 2017 (UTC)
  • Oppose - I commented at length on this during the original debate, and as I mentioned to JFG during a discussion on his talk page last night, I don't think anything has changed since last year really. As I see it, first and foremost we are all editors. Nobody ultimately has a greater say than anyone else. However, there are some "positions" which an editor can assume which are in certain ways elevated from others, because the community has bestowed that position on the editor. I'm talking about adminship, bureaucratship, oversight, ArbCom, etc. Someone holding adminship has been vetted extensively, in the very rigorous RfA process, and in most cases their closures of things like RMs and AfDs will face slightly less scrutiny than a non-admin because the community has already confirmed that they have good judgement etc. Now page mover, on the other hand, is what I think of as a technical privilege, alongside rollbacker, pending changes reviewer, file mover and so on. It is something which is granted by admins to an admin editor who looks competent, and looks like they could use the tools, to smooth things over in the Wiki, and make certain technical tasks easier for those users to carry out. While a page mover is very likely to be someone active in closing RMs, the two are not really directly linked, and the RfC which established the page mover right did not intend the holders of that right to have any more right to close moves, or any more authority in doing so than any other non-admin of good standing. Of course, being a page mover is a hat of sorts, and it's nice to get the nod from another Wikipedian that you're basically OK; as such, there's no problem with having a little user page icon to designate it, but I would leave it at that, not use it as a level above other non-admins who perform closures. Thanks  — Amakuru (talk) 20:38, 18 July 2017 (UTC)
@Amakuru: Surely you didn't mean "granted by admins to an admin who looks competent"
To the fundamental point you are making, signing a closure as a page mover does not imply that the closer is on "a level above" other editors; my proposal does not suggest that. A commenter said we could sign "non-admin closure by page mover" to emphasize that only admins are "special", although by policy they are not "above", they are just trusted to wield certain tools. So are page movers. I don't see the drawback of labeling their closures as such, and it promotes accountability. WP:ADMINACCT says admins are accountable for their use of admin tools. Similarly, I would say that page movers are accountable for their use of page mover tools, and that includes the ability to close RM discussions and execute the outcome. Template editors are accountable for their editing of delicate templates. — JFG talk 21:02, 18 July 2017 (UTC)
Oh, thanks. Yes... bestowing page mover privileges on an admin would be a little pointless! I guess you're right on the wider point, and certainly WP:NOBIGDEAL applies as with anything else. Admins aren't "special", they just have a little badge that says they've been voted in by the community and can do certain extra technical things as a result. I think my main point is that people shouldn't take the bestowing of this privilege in itself as a licence to start closing moves left, right and centre. There certainly was a lot of that in the early days - the backlog was suddenly whittled from humungous down to zero within a week, but the closes was highly varied in their quality. There were some page movers, for example, who thought an RM that had sat for a week with no responses should be automatically closed as "not moved". Ideally editors should work their way into non-admin closures slowly, starting with the clear cut ones, learning the ropes, studying other people's closes and so on. I spent about three years closing RMs regularly before I got the mop (and that was in the days before page mover existed), and it was a learning curve. I didn't think I had all the answers on day one. Like PaleAqua I could probably live with the "non-admin closure by a page mover" as a sensible compromise... Thanks!  — Amakuru (talk) 21:12, 18 July 2017 (UTC)
There was absolutely a collective learning curve in the early days of the page mover right; ultimately the unbundling served its purpose well, and we have a mostly well-curated backlog… except one case you and I know pretty well. — JFG talk 05:40, 19 July 2017 (UTC)
Hey Amakuru, even that 15-year-old case was finally resolved yesterday! Gives credence to eventualism… — JFG talk 14:42, 20 July 2017 (UTC)
  • Support Purely informative, I do not think it implies anything other than the extended technical information it provides, so be it. Since we clearly make a distinction between admin/non-admin closes already, even when there might be no credible difference in their expertise, I believe there is no reason to use the non-admin/page mover divide as a legitimate reason. --QEDK (愛) 20:39, 18 July 2017 (UTC)
  • Support non-admin closure by page mover, I also support the change to the language above. I think changing the wording to read that way makes sense because the text ideally should give the person clicking the link an idea as to what they are getting linked too. As a side benefit, it might get some more people who could be useful around the project applying for the page mover tool. TonyBallioni (talk) 22:43, 18 July 2017 (UTC)
Side benefit makes sense, thanks. — JFG talk 05:40, 19 July 2017 (UTC)
  • Oppose per Amakuru. I would go further and abolish the WP:RMNAC section entirely, and I don't follow it for my closes (I am a page mover, but I regard it as a purely technical privilege). Adminship is not a magic pixie dust which would suddenly make someone's judgement impeccable, and it cuts the other way too – I've closed quite a few RMs and I'm known to have screwed up up a couple. All experienced editors are entitled to close RMs, RfCs, MRs and other debates, provided they are thoroughly familiar with applicable policies and practices; and, thankfully, I witness that we're gradually moving into that direction lately, obviating the need for more admins (and compensating for their shortage). The close should be self-explanatory regardless of who made it, and if anyone's interested in closer's user rights, their talk page is one click and Special:UserRights is two clicks away. No such user (talk) 13:32, 21 July 2017 (UTC)
I wouldn't be against abolishing {{rmnac}} entirely either, but that's a different debate. If we keep this signature around, it should be able to display all categories of closers. We could even extend it to "{closed by admin}" for extra clarity. We can probably automate the appropriate signature depending on the closing user's rights. — JFG talk 15:39, 22 July 2017 (UTC)
  • Weak oppose as this wouldn't add any relevant information to a close. A page mover right is a technical ability granted to almost anyone who's asked for it and it doesn't confer any greater weight to the close and it doesn't entail any additional need of accountability for the closer (of course, page movers should be accountable for their page moves, but that happens that the level of the move itself, and not at the level of the discussion that preceded it, if there was one). – Uanfala 12:50, 22 July 2017 (UTC)
  • After thinking this through, I'm going to have to oppose this. While there may be some sort of advantage to making PMs label their moves as such, I don't think it's significant enough to warrant a change in protocol. Admittedly, I'm not active in requested moves and other page move-related pages (I was summoned by bot.), but, in general, the NAC template is used when a certain level of accountability for an action can't be met (ex. closing a discussion at ANI) and the user is being clear about that. To require PMs to use this would imply that they must have a similar level of accountability to admins when moving pages, which definitely should not be the case. If it were, PMs would have to go through an RfPM or something like that. Again, that simply isn't and never should be the case, ever. — Gestrid (talk) 20:16, 22 July 2017 (UTC)
  • Oppose We don't evaluate one's ability to judge consensus when the right is requested, this would imply some sort of higher standard. jcc (tea and biscuits) 20:32, 28 July 2017 (UTC)
  • Oppose. Page movers are set to the same standards when moving pages as non-administrators. Labeling moves as proposed attempts to circumnavigate that fact and almost creates the false understanding that the community has authorized such a distinction. This proposal is like putting the cart before the horse. Steel1943 (talk) 19:05, 2 August 2017 (UTC)
  • Support. This is a small alteration that discloses to involved editors whether or not the RM closer is an experienced page mover. Something may be said for "experience", IMHO. It's not a big deal, and certainly does not carry "page movers are better than other non-admins" connotations. Just an informative need, much like the {{Connected contributor}} disclosure, only smaller.  Paine Ellsworth  put'r there  15:34, 10 August 2017 (UTC)
  • Support, especially the longer version. The original proposal is acceptable to me; I prefer (as a page mover) PaleAqua's idea to extend it slightly for clarity, though I think "non-admin (page mover) closure" or "non-admin closure by page mover" would flow better than "non-admin closure (page mover)". It both informs that it's not an admin close, and also informs that the close was done by someone with experience. Two birds, one stone. There are different rationales for making both clear: Not everyone is an expert on user "bits" and might not be clear that PMs aren't a class of admin (after all, we have some effective and formal admin classes, like AE admin, Bureaucrat, and Checkuser). Not everyone is a memorizer of user names and access levels and drama incidents, thus may not recall who is a several-year veteran with sufficent community trust for PM, versus who's been here a month and has been hauled to ANI four times already and would no-way-no-how get the PM bit. So, help everyone with additional clarity.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:53, 10 September 2017 (UTC)
  • Oppose, for the reasons already given above. Page movers are no different than any other experienced editors for the purpose of deciding consensus. To the extent that the consensus of the community is that non-admins should identify themselves as such when closing discussions, page movers should not be further differentiated for this purpose. (I, personally, disagree with this consensus and think that discussions can be closed by anyone, and non-admins shouldn't need to identify themselves, but that is not currently the topic under discussion.)--Aervanath (talk) 09:19, 11 September 2017 (UTC)

Discussion

Extended debate goes here.
Correct, and the proposed change will have no influence on substituted versions. — JFG talk 00:54, 18 July 2017 (UTC)
  • @JFG:--Well, I would like in the lines of Page movers may use ......But does page-mover(s) have any more authority to close Move Reqs. than one who doesn't have the flag?Except the technical ability.Many users possess the flag just because they possess a non-controversial move-log and understand the guidelines well but has hardly any experience closing move-reqs etc.I, on the other hand, gained it on the basis of closing move requests and properly executing the consensus.What I mean to say is understanding guidelines well and aptly closing discussions are at best tangentially related.Abstaining from !voting until others join in!Winged Blades Godric 04:09, 18 July 2017 (UTC)
  • @JFG: So what I'm getting from this is that you want to distinguish between move requests closed by users without the PM right and requests closed by those who do. Am I right? If so, I'm not clear on the need for this. Could you clarify that as well? I'm gonna abstain from !voting for now. — Gestrid (talk) 07:53, 18 July 2017 (UTC)
Yes I believe this is an informative distinction to make, first because page movers can actually execute some of the moves for which ordinary editors are restricted, second because it promotes accountability of page movers in face of scrutiny: the bar should be set a little higher than for occasional closers who have too little experience or motivation to ask for the permission in the first place. — JFG talk 12:23, 18 July 2017 (UTC)
  • Comment page requests should not be closed by any of those involved in the discussion (unless seven days have passed and it is a snow). Those who do not have authority to move a page ought not to close it. -- PBS (talk) 11:20, 18 July 2017 (UTC)
Sure; nobody is contesting this rule. Are you suggesting the guidelines need a clarification on this? — JFG talk 12:23, 18 July 2017 (UTC)
While discouraged, NAC RM closes are allowed even when the closer was not able to do the move because of permissions. In such cases they are requested to file a technical move linking the discussion. See WP:RMNAC. One of the driving reasons for the page mover right was that they should be able to help with backlogs of that list. PaleAqua (talk) 14:03, 18 July 2017 (UTC)
Well, with our roster of 160+ page movers in addition to admins, I believe it's time to stop this practice: a nac closure that can't be executed just creates an additional burden for other editors. — JFG talk 14:28, 18 July 2017 (UTC)
I believe it's perfectly fine for page movers to act as clerks for technical moves, saves time. Although, they do have to skim over it themselves anyway. --QEDK (愛) 20:37, 18 July 2017 (UTC)
It is not "perfectly fine" because it introduces yet another layer of bureaucracy. -- PBS (talk) 06:18, 19 July 2017 (UTC)
What? I didn't get you, how is it more bureaucratic if non-admins are allowed (technically, currently there's no restriction, just reminding) to close discussions they aren't technically capable of carrying out? --QEDK (愛) 20:14, 19 July 2017 (UTC)
See the most recent postings in this thread by PaleAqua and JFG. "in such cases they are requested to file a technical move linking the discussion", "just creates an additional burden for other editors". -- PBS (talk) 07:41, 20 July 2017 (UTC)
That doesn't make it more bureaucratic, that makes it less bureaucratic since non-admins aren't hindered on the basis of the lack of technical right. --QEDK (愛) 14:26, 20 July 2017 (UTC)
PBS, non-admins without the extended mover flag do currently have to file a request for an admin or page mover to implement their close at WP:RM/TR. There is simply no other way to implement many RM closes without either the ability to delete or the ability to execute a round-robin. QEDK is describing what is already the current state at RMs for people without the flag. There's no way to avoid this unless we debundle the right to suppress redirect even further (as in EC or AC by default), which I don't think the community is going to do. TonyBallioni (talk) 14:32, 20 July 2017 (UTC)
  • Comment - If this discussion would hugely affect future RM discussions, this discussion should be listed in Template:Centralized discussion. Thoughts? --George Ho (talk) 15:04, 18 July 2017 (UTC)
    • I wouldn't consider this a huge change: it would change the text that displays in a closure by a page mover to match the text that it links to. RMs are already very heavy with NACs by page movers, so I don't think there would be much change so much as making the text of the policy more reflective of what is already happening. I'm not neccesarily opposed to listing at CENT, but I also don't think this would have a huge impact on RMs. For what its worth, I'm also not sure what my thoughts are as of yet on this. TonyBallioni (talk) 15:29, 18 July 2017 (UTC)
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.

There is a followup discussion about what to do with the optional |PM= parameter in {{RMnac}} / {{RMpmc}}. @Aervanath, Amakuru, George Ho, Gestrid, JFG, Jcc, MrX, No such user, PBS, Paine Ellsworth, PaleAqua, QEDK, SMcCandlish, Slakr, Steel1943, TonyBallioni, and Winged Blades of Godric: please comment at Template talk:RMnac#Page mover. — JFG talk 03:55, 16 October 2017 (UTC)

Wikipedia_talk:Requests_for_permissions#Looking_for_consensus

Hi all, this is a notice that I have started a discussion about adding an addition rule to the guidelines for granting for Page Mover and Template Editor user rights. Please feel free to comment. Alex Shih (talk) 17:49, 21 March 2018 (UTC)

Raise the bar?

Should we consider raising the bar? This is a powerful, geeky, and fairly dangerous (in the mess-making sense) tool, and a tremendous number of requests for it are from noobs who don't know what they're doing. I think this would be more effective with a 1 year requirement as a frequent editor, and 2 years without WP:RM/WP:AT-related sanctions. Probably also several days of a request being open before being granted.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  09:18, 2 October 2017 (UTC)

How many users are actually a problem? There are only 191 page movers according to Wikipedia:Page mover, and the preferred solution has been to just remove the right. Has this been done yet, and to how many? If we're talking about 50-100 problem users,then that's a significant percentage (25%-50%), and there's definitely a need for tighter screening, especially if the majority of this percentage has been on WP less than a year. If it's less than 10-20 people, then removing the right is a better solution. - BilCat (talk) 22:11, 2 October 2017 (UTC)
Well, except that's it's liable to require an ANI or AN discussion, which is a time-drain on other editors. I just see looking through the request page that a large percentage of the requests are noob hat-collecting attempts.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  07:09, 14 October 2017 (UTC)
It's one of reasons that the removal criteria exist and specifically states "it can be revoked at any time by an administrator without any process or prior notice in any of the following circumstances". PaleAqua (talk) 05:21, 15 October 2017 (UTC)
I concur with PaleAqua, assuming that these users are using the right incorrectly. Please note that "hat collecting" isn't one of those listed circumstances. - BilCat (talk) 05:44, 15 October 2017 (UTC)
I don't know if there is a problem, but if there is, it would be much better (easier, cleaner, kinder) to raise the bar rather than relying on drama and bad feelings to have them removed if used unwisely. If "tremendous number of requests for it are from noobs" is substantiated, the bar should be raised simply to avoid wasting time. Johnuniq (talk) 04:17, 16 October 2017 (UTC)
  • I concur, this comes with flags which although not very misusable, can still make things messy. I'd agree with a 1 year age requirement (as status quo for a good-standing editor), with an uncontroversial move log compulsorily, as well as some participation at RM/MR to demonstrate awareness of policy. --QEDK (愛 • 海) 07:25, 16 October 2017 (UTC)
    • I wouldn't include a requirement for participation at RM: there's a wide range of uses of the page mover right (and hence situations which demonstrate awareness of policy) that don't have to do with RM discussions. – Uanfala 10:28, 16 October 2017 (UTC)
    • RM/MR isn't the only place where there is the need to move articles. It's an issue which often occurs at New Page Patrol. The idea of an RM/MR requirement was discussed & discounted when the right was created. I've not seen anything which would change that outcome. Cabayi (talk) 11:50, 16 October 2017 (UTC)
      • Anything to demonstate awareness of titling policy is fine, ofc the uncontroversial move log is mandatory as a bar for gauging need and experience. --QEDK (愛 • 海) 14:56, 16 October 2017 (UTC)
        • Awareness of and compliance with. Various RM-disruptive people are very well aware of title policy, naming conventions, MoS and other WP:P&G but defy them tendentiously, and should be kept away from this user bit. Anyway, something like RM experience or NPP experience or [insert whatever else] would be good to add. Granting of this bit should be more clearly tied to demonstrable need for it and competence in the sphere of its use.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  18:57, 1 December 2017 (UTC)
  • I'd oppose a 1 year requirement, but I'd be fine with either raising the edit count or specifying non-automated edits. This would help deal with some of the issue IMO, while still making the user right available to those who after 6 months need it and know how to use it. Like Cabayi mentions above, this has uses at NPP when moving to draft and that's something that if someone says they want to do with 6 months and 3,000 non-automated edits, I'd likely trust them. TonyBallioni (talk) 14:33, 16 October 2017 (UTC)
  • I would support raising the bar. My issue has been that the vibe I get from a lot of users requesting this at PERM is that they come across as hat collectors, often having deliberately checked off everything on the list so they can then get another userright. I don't really know how to combat that though because on the other hand it is a bit unfair if you have arbitrary guidelines and admins can just say "decline – looks like a hat collector". Perhaps something could be added about demonstrating a minimum level of clue? As an aside on issues caused, they got there in the end but check out the history and logs of Dalmatian dog. They got there in the end but clearly that is less than ideal. Jenks24 (talk) 23:18, 1 December 2017 (UTC)
If there is no need from either the NPP angle or RM closing etc., I don't find any convincing reason about why PM should be granted?!No demonstrable need of access has been a favourite decline reason for many PERM-admins.Winged Blades Godric 09:41, 2 December 2017 (UTC)
  • I am not much enthusiastic at the proposals without any backing evidence for such necessities and somehow, this entirely looks like searches in solution of non-existent problem.I must praise SMC's vigilance to prevent granting to controv. users but would urge SMC to put forward cases where the right was granted with laxity and was correspondingly mis-used.And flatly PM is not the "most sensitive unbundled right"; EFM is.And, SMC, Salvidrim's case has got nothing to do with increasing our requirements over here.Winged Blades Godric 09:29, 2 December 2017 (UTC)
And, I remain curious as to what my chances of being granted the PM right were, at that time, if the guidelines were upgraded:) And, I don't think I have messed up with the right.Winged Blades Godric 09:38, 2 December 2017 (UTC)
  • I don't visit RM that frequently, yet this is perhaps the most-used of the flags I have. Most of the use has been cleaning up user errors while doing move log patrol, and getting things out of projectspace. I have no issue with raising the age or edit bar, but I can't support "activity in a specific field" (be it RM, NPP, or both) as a requirement. – Train2104 (t • c) 15:17, 2 December 2017 (UTC)
  • I'd like to see evidence of problems with current page movers that can be addressed by applying stricter numerical criteria before raising the bar. Page mover should be easier to get than adminship was in 2004 (then, six months were more than enough). —Kusma (t·c) 15:25, 2 December 2017 (UTC)
  • I frequent PERM regularly. I would agree that a hat-collector with rudimentary knowledge of enwiki sees this flag as the easiest one to be collected. Account creator requires a solid need, MMS needs previous message requests, A-PAT needs 25 clearly notable articles with near perfect editing skills, and no doubt for undisclosed paid/misuse. Same goes for NPR. AWB, and TE requires technical knowledge, and these requests are very well examined. What's left is PCR, rollback, and PM. PCR is supposed to be most lenient flag to be granted.
    • The complications that can be caused by page move(er) are messy. I have been there. Failing to move talkpages is another thing. But a round-robin move is totally different thing. My first (and manual) Robin move was a failure. I never messed it up until very recently when the script failed, and as a result one of the pages was deleted. I had to immediately contact an admin, as there was no way for me to recover that deleted page.
    • I think we should raise the bar a little higher, something like, "1000 edits in mainspace, demonstration of clear understanding of WP:AT", and something that would demonstrate technical abilities regarding round-robin moves. But I don't know how to achieve that. Activity at WP:RM is not necessary, but the candidate's history should be able to demonstrate page-moving policies. Also, the candidate should demonstrate ability to communicate well with other users, as in many cases an editor turns up and demands explanation of a RM discussion closurem Most importantly, this flag gives two abilities: suppressing redirects, and access to Andy's round-robin script. So if the user doesn't want to perform round-robin moves, the flag is almost useless; as call for suppression is pretty rare, and can be done with speedy noms. I think, the requirements should be a little tighter than current ones, and "An administrator may grant page mover rights to users they otherwise deem competent and may deny the requests if they do not see a need for the tools or have other concerns." should remain there. —usernamekiran(talk) 03:05, 6 March 2018 (UTC)
I'm sorry, but this last comment is just another hypothetical musing on potential problems, other than the user's own rare mistakes. I'm still not seeing actual evidence of abuse of or major problems with PM rights, which is what this thread is about preventing. As of now, there are 208 Page Movers, so it should be relatively easy to document any problems. I'm not opposed to some tighter requirements, but it's telling to me that absolutely no actual evidence of abuse or major problems has been presented whatsoever. - BilCat (talk) 05:00, 6 March 2018 (UTC)
@BilCat: yup, they are hypothetical/potential problems :)
The "ability (history) to communicate well with other users" can be added as a guideline, and not as a solid requirement.
  • One of the reasons why I am cautious/uncomfortable about this being granted to editors with not so long tenure is the misconception about the flag itself. In the past, a now blocked paid editors thought a page mover can move page to a target which "creation blocked". (unfortunately, I cant recall when, or where this happened; but it happened for sure.) One suspected paid editor had actually requested for this flag (diffs available if required), and then there was this communication. From the comment it is not clear, but I think they believed a page mover can bypass the sating process.
  • My goodness, pagemover is considered a big deal now? Moving subpages and suppressing redirects is a scary thing? For the record, I oppose raising the bar. Hat collection is a non-argument, because it is not inherently disruptive. Any disruptive behaviour can and has been dealt with appropriately in the past, and there is no evidence here of a systemic problem that needs to be addressed with disruptive use of the page mover right. -- Ajraddatz (talk) 18:40, 21 March 2018 (UTC)
I've thought the same thing. Why are we denying tools for hypothetical problems? Natureium (talk) 20:11, 21 March 2018 (UTC)

Additional discussion

This has also been raised at Wikipedia:Requests for permissions/Page mover#Need and review, which may archive fairly quickly.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  18:48, 1 December 2017 (UTC)

Page movers causing confusion and disruption when swapping pages with different topics

Wikipedia:Redirects for discussion/Log/2019 February 8 § GTK+

Retarget Closed discussion, see full discussion. Result was: retarget

No, this has not been resolved. If this had been done cleanly, I wouldn't have noticed the move, and wouldn't be here. I'm here because in my routine patrol of Category:Articles with redirect hatnotes needing review, I found GTK was populating that category. Take a look at the revision history of GTK+].

  • 08:27, 9 February 2009‎ . . (moved GTK to GTK (API): GTK+ appears to be primary usage of GTK/gtk: have created dab page)
    Why should GTK+ redirect to GTK (API)?? Was GTK+ ever associated with the API? Are these the same topic? No.
  • 08:27, 9 February 2009‎ . . (redirect to primary topic, having moved and made dab page)
    GTK+ is redirecting to itself, which is an obvious error!
  • 14:01, 7 October 2009‎
    GTK may refer to:
    Now a page titled GTK+ is attempting to disambiguate GTK. Is this vandalism? Maybe just an error, since the next edit was a self-revert.
  • Then it took seven more edits to move a single page – an operation that an administrator could have done with one single edit.

This page history should have been buried, not swapped. Redirect edits generally should not be moved without a good reason to. And I'm not sure that the lack of page deletion rights is really that good of a reason. If a redirect edit is subsequently deleted after it's been moved, there is a risk of triggering T30819 if that edit is subsequently deleted on a different page than the page it was created on, because deleted edits are identified by datestamps rather than page IDs. The problem is that page moves create two edits with the same timestamp, one with content and one that's a #REDIRECT, and if both these edits end up on the same page and are deleted (which may be necessary to do a history-merge), then one of them cannot be restored without restoring the other as well–two deleted edits with identical timestamps can't be distinguished from each other.

Maybe this is putting it too strongly, but this swap would possibly be viewed as a sort of cut-paste (vandalism) if it weren't done by a "page mover".

I thought the theory behind creating the page movers group was to reduce page-move backlogs by allowing page movers to make simple swaps of titles redirecting to the same topic, removing the burden of simple page moves from admins and freeing them up to focus on the more complex moves, including changes in primary topics. But instead of seeing my time freed up, I find myself too often sidetracked into having to clean up after page movers. Swapping John Q. Public with John Q Public is fine, but if you want to make these kinds of moves, you should run for administrator so you can do them the optimal way (hint: you'll help your chances for passing if you show some clue by asking for admin help to do things you can't do without causing confusion and disruption). – wbm1058 (talk) 15:09, 9 February 2019 (UTC)

​I agree that it is necessary to make sure you have a handle on the permission when using it, but this was related to moves by a new page mover on the very first day of swapping pages, so it is understandable that an error might occur. The issue was raised on the editor's talk page yesterday, and hopefully that will be the end of it. I granted the permission for a monthlong trial period in this case, so I am to blame if things don't work out. Dekimasuよ! 01:19, 10 February 2019 (UTC)
OK, I realize I may come off as ornery above, and I'm sorry about that. I didn't realize this was a new page mover, but general advice is to wade into the shallow water before diving into the deep end. I just made this edit to clean up another overlooked cleanup task that this type of move creates. wbm1058 (talk) 13:15, 10 February 2019 (UTC)
I'm sure most of the page movers (me included) will not be given adminship rights for that basis. Honestly, we're just trying to fix things, unfortunately, we only have so many flags as not being an admin gets us. That's all I have to say. --QEDK (後 ☕ 桜) 16:21, 11 February 2019 (UTC)

File redirect suppression

Moved from MediaWiki talk:Movepagetext
 – DannyS712 (talk) 06:42, 23 June 2019 (UTC)

Hi. According to Wikipedia:Page mover#Redirect suppression criteria, suppressing a redirect for a reason that isn't listed as a criteria can result in the loss of page-mover rights. But, the "movepagetext" message (copied below) includes a suggestion that file movers suppress redirects as a matter of general practice - why is this included if it is not a part of the redirect suppression criteria? 

<div id="movepagetext">
Using the form below will rename a page, moving all of its history to the new name. The old title will become a [[Wikipedia:Redirect|redirect]] page to the new title. '''Links to the old page title will not be changed'''.

This can be a drastic and unexpected change for a popular page; please be sure you understand the consequences of this before proceeding. Please read [[Wikipedia:Moving a page]] for more detailed instructions.
<div class="sysop-show extendedmover-show" style="display: none;">
'''Note to admins and page movers:''' The "leave a redirect behind" option should only be unchecked in situations outlined by the [[Wikipedia:Page mover#Redirect suppression criteria|redirect suppression criteria]] as this will break any links to the current title and may make the page harder to find.</div>
{{#ifeq: {{NAMESPACE:{{#titleparts:{{PAGENAME}}|1|2}}}} | {{ns:User talk}} |
 {{#ifeq:{{#titleparts:{{PAGENAME}}|1|3}}||{{notice|If you want to rename your account, please make a request at [[Wikipedia:Changing username]].}}
 }}
}}{{#ifeq: {{NAMESPACE:{{#titleparts:{{PAGENAME}}|1|2}}}} | {{ns:File}} |
 {{#ifeq:{{#titleparts:{{PAGENAME}}|1|3}}||{{notice|Using the form below will rename a file, moving all of its history to the new name. This option is only available to administrators and file movers.

Leaving a [[Wikipedia:Redirect|redirect]] from the prior title to the new is the norm for ''page moves'' for various reasons, such as that the prior title often has numerous internal and incoming links that would be broken upon the move and that it may be a likely search term. By contrast, such concerns are not normally applicable to file titles, which are often only linked from the one or two pages on which the file appears. Accordingly, unless this file is included in many pages (check using [[Help:What links here|what links here]]; do not rely solely on the file links at the bottom of the file page), please consider manually changing all links to the old title to the new title, and then moving the file without leaving a redirect behind. The option to leave a redirect behind is checked by default, and must be unticked if you take this course.

Please remember after the move to revisit the file page and remove {{tl|rename media}} or any other code that requested the move. Please also consider [[Wikipedia:Moving files to Commons|moving this page to Commons]] if it is a public domain release or under a [[Commons:Licensing#Acceptable licenses|suitable free license]].
 }}
If a [[WP:TimedText|TimedText]] for this file exists, it is displayed below. Please move any along with this file.
<big>'''''{{Special:Prefixindex/TimedText:{{Str right|{{#titleparts:{{PAGENAME}}|1|2}}|5}}}}'''''</big> }}
}}
</div>

Its just confusing that it suggests suppressing a redirect, but says that suppressing a redirect should only be done in specific cases, which don't include general file moves. Am I missing something? Thanks, --DannyS712 (talk) 08:52, 22 June 2019 (UTC)

@DannyS712: back in the old days, file redirects didn't work - and then they didn't work reliably. This is probably a better discussion for Wikipedia talk:Page mover, that is to determine when file redirects should be suppressed. Practically, if there is "low" usage and the usages are updated, it is reasonable to think that the redirect could be speedily deleted - so if it qualifies for CSD it should qualify for suppression as well. — xaosflux Talk 12:56, 22 June 2019 (UTC)
@Xaosflux: I moved the discussion. --DannyS712 (talk) 06:44, 23 June 2019 (UTC)

Proposal to modify guideline #3

I have recently noticed a large number of PGM requests coming from New Page Reviewers who have little to no WP:RM experience but draftify a large number of pages then deleting the redirect. I would like to modify guideline #3 to include this as an additional sentence as a demonstration of need for the right. Primefac (talk) 20:08, 18 August 2019 (UTC)

  • I think that back door deletion method should receive a lot more scrutiny. —SmokeyJoe (talk) 22:16, 18 August 2019 (UTC)
  • My gut reaction is to agree with SmokeyJoe. I understand the intent behind draftifying new pages during NPP, but I think the backdoor to deletion is something deserving of more scrutiny and tagging them as R2 helps provide that. On the other hand, the guidelines already allow you to grant the permission to anyone you deem competent. I guess I'd rather individuals administrators use their judgement to determine if someone tagging a lot of R2s is clueful enough to be granted page mover, rather than risk page mover becoming an extension of the new page reviewer user group. If it's something that is widely useful to reviewers, it would probably be better to discuss whether new page reviewer should include suppressredirect. Wug·a·po·des​ 01:11, 19 August 2019 (UTC)
  • I agree with Wugapodes. I am not sure what Primefac wants to edit exactly, but PGM access should be given on the discretion of the individual admin as it has always be been. It shouldn't be something like "if an editor has been NPP for 90 days or more without any dispute, they may get PGM access". It is basically ability to perform "housekeeping speedy deletions". —usernamekiran(talk) 01:33, 19 August 2019 (UTC)
    • update: I think any candidate requesting PGM, should demonstrate/have knowledge of policies/guidelines regarding WP:AT, MOS, and related concerning stuff to page moves. Like the #3 currently says, participation at WP:RM, and move reviews; is a good way to gauge it. But if NPRer with good temperament requests PGM for suppressing redirects, the assessing admin can/should grant the flag upon their discretion. —usernamekiran(talk) 02:47, 19 August 2019 (UTC)
      I want to add in something like Experience in successful drafitication as an NPR can also be a demonstration of the need for this right. As I said above, there have been a fair number requests recently with 0 of the "normal" RM/move experience but a lot of NPR move experience, and rather than having that be implied in the "shows need", actually spell it out. I'm gathering from the replies so far that this is felt as some sort of CREEP that ends up validating a practice they already don't like. Primefac (talk) 07:03, 19 August 2019 (UTC)
      that makes sense. This statement discusses the need of the tool, and yet leaves the decision to the assessing admin. I support the proposed change of words. It's just, like the editors have raised concerns, I feel the same way. Even I have sort of "abused" this tool. I once accidentally created an article which was deleted few times, I was under impression that it was salted; hence the accidental creation. I immediately moved it to my userspace with a different title, while suppressing the redirect. An editor has raised a very valid concern of titles "being watched" in particular spaces. Unless the NPR is extremely well versed with CSDs, they shouldn't be granted PGM. But all this again boils down to "administrator's discretion" again. —usernamekiran(talk) 21:21, 21 August 2019 (UTC)
  • I think there is a lack of attention to Wikipedia:Drafts#Moving articles to draft space, aka WP:DRAFTIFY. Because the article is new, you can assume it is unwatched, except by the author. Because draftspace is overloaded, you can expect the page to be unlooked at there if never submitted. Draftification is therefore a backdoor CSD. It is less transparent than WP:PROD; PROD creates tracking categories and requires an admin to do the deletion. I don't think non-admin draftifiers are particularly conversant with WP:CSD. An example of concern, about the principles, is Tommy John (apparel company). Draftified and slow-deleted per "article was created by a possible SPA". Note the discussion at Wikipedia talk:Deletion policy/Archive 48#Undeclared Paid Editor (UPE) product is fairly conclusive that there is no consensus that an article being UPE product is not a reason for deletion. SPAs are far more common and less egregious than UPEs. Note that I actually think the page should have been deleted, see Wikipedia:Articles for deletion/Tommy John (apparel company). Is it too hard to get things deleted at AfD, and so people are looking for these backdoor deletions? CSD & PROD will give you a stained record of the reviewing admin fails to agree.
No. Nonadmin draftifiers must have an admin review their action; the admin deleting the CNR redirect guarantees this, the admin must be expected to be conversant with DRAFTIFY and be aware that they are countersigning a backdoor slow deletion. --SmokeyJoe (talk) 06:27, 19 August 2019 (UTC)
I'm not saying that every NPR (or even every NPR who asks at PERM) should get PGM. I'm saying that if an NPR with a demonstrated experience of good judgement in draftification asks for the right, they should get it. As mentioned above, yes, it's implied that the admin granting has it in their discretion to grant or deny based on whatever personal criteria they want, but at that point we might as well just remove the "shows experience in the RM process" piece as well - just "demonstrates need" and leave it at that. Primefac (talk) 07:03, 19 August 2019 (UTC)
The RM process is one of high drama and little consequence. Experience at RM is a poor indicator of wisdom in draftifying. I think you should look at their CSD_log and draftification log. Draftification combined with G13 is a pretty worrying hole in deletion policy, allowing untracked POV deletions and newbie biting and intimidation. —SmokeyJoe (talk) 07:15, 19 August 2019 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Page_mover/Archive_3&oldid=950097042"