Wikipedia talk:Page mover

Talk page redirects

There have been (at least) two recent moves in which a page mover has suppressed redirect creation and the result has been that valid talk page links have become redlinks.

See User talk:Iffy#Move of Capitol Limited (Amtrak train) for the first of these that I noticed, and the discussion that followed.

More recently, Talk:Phenomenological sociology has become a redlink following this move:

21:30, 17 October 2018‎ Dreamy Jazz (talk | contribs | block)‎ m . . (10,164 bytes) (0)‎ . . (Dreamy Jazz moved page Talk:Phenomenological sociology to Talk:Phenomenology (sociology) without leaving a redirect: Move per WP:RM discussion on the talk page)

I think that the documentation on this page needs an update in order to make it clear that such redlinks need to be tidied up after a move. Andrewa (talk) 22:44, 17 October 2018 (UTC)

The truth is, nobody cares. I consider myself a particularly anal diligent mover, but talk page redlinks are pretty high on my "least concerns" list; I usually bother to resolve self-links, but I'm completely oblivious to redlinks. We have the duty to the mainspace, and it sometimes gets real hard work to redirect or disambiguate incoming links, but talk space is really not of immediate concern. No such user (talk) 21:05, 25 October 2018 (UTC)

You appear to be right. But the practice and policy do not match, and should... otherwise, why have the policy? Andrewa (talk) 01:21, 8 November 2018 (UTC)

I personally think it's a page mover's responsibility to do proper clean up after a page move. We have a whole detailed section on what needs to be done. I don't believe we can expect all page movers to know all the trivia here, (for example, moving, or requesting to move, editnotices that would have been attached to previous titles), but some basic actions like correcting talk page redirects, checking subpages, creating newly red-linked talk pages (especially with incoming links) is standard imo. — Andy W. (talk) 18:22, 20 December 2018 (UTC)

Another case

17:28, 4 November 2018‎ Flooded with them hundreds (talk | contribs | block)‎ m . . (12,254 bytes) (0)‎ . . (Flooded with them hundreds moved page Talk:AdWords to Talk:Google Ads without leaving a redirect: discussion at Talk:Google Ads#Requested_move_08_October_2018)

More than 30 pages currently link to the now nonexistent talk page Talk:AdWords, including for example this recent contribution which is what brought it to my attention. And there may also be incoming external links of course, which we can neither change or even for the most part detect.

And again it was a round-robin move:

• (cur | prev)  17:28, 4 November 2018‎ Flooded with them hundreds (talk | contribs | block)‎ . . (24 bytes) (+3)‎ . . (z) (rollback: 3 edits | undo | thank) (Tag: Redirect target changed)
• (cur | prev)  17:28, 4 November 2018‎ Flooded with them hundreds (talk | contribs | block)‎ m . . (21 bytes) (0)‎ . . (Flooded with them hundreds moved page Move/Google Ads to AdWords without leaving a redirect: restore) (undo | thank)
• (cur | prev)  17:27, 4 November 2018‎ Flooded with them hundreds (talk | contribs | block)‎ m . . (21 bytes) (0)‎ . . (Flooded with them hundreds moved page Google Adsto Move/Google Ads without leaving a redirect: vacate for rm) (undo | thank)

I think we need to fix this. Andrewa (talk) 01:21, 8 November 2018 (UTC)

• Page movers suppressing redirects that should not be suppressed should be cause for removal of the pagemover right. --SmokeyJoe (talk) 01:28, 8 November 2018 (UTC)
  • Agree but this is not that simple. The suppression is valid in order to do the round-robin move. The problem is, the process should then be to restore the talk page redirect, not just the article space redirect. And the documentation doesn't say this... or, perhaps commonsense indicates that it does, but the letter of the instructions isn't clear on this, and as we've seen above, there's not even a consensus here that the talk page redirect should be restored. Andrewa (talk) 05:17, 8 November 2018 (UTC)
    • People requesting advanced permissions should carry the onus of responsibility in using it. If consensus is lacking, don’t use the advanced permission. —SmokeyJoe (talk) 02:47, 10 November 2018 (UTC)
      • Agree. But it's a bit unfair to expect them to follow commonsense and preserve talk page links when the procedures don't require it, and we don't even have consensus that it's the right thing to do. I'm working here on building that consensus. It is the right thing to do, and we waste everyone's time by not documenting that in the procedures. Andrewa (talk) 12:00, 18 December 2018 (UTC)
• This is a side effect of the page swapping script, which does not automatically modify the redirect, so editors usually correct the mainspace redirect manually, but sometimes neglect to do the same for the talk page redirect, which now points to itself. That is bad form by page movers, but honestly they may be fooled by the apparent simplicity of executing a script-assisted swap. Perhaps that tool could be made a little smarter? @Andy M. Wang: can you help? — JFG ^talk 20:23, 20 December 2018 (UTC)
  • @JFG: As I've already pointed out here and here, here, here, here, etc, the script is just a move-assisting tool, and wasn't designed to correct, or edit, mainspace/talk/subpage redirects. The intent was to alleviate the need to issue 3 Special:MovePage requests, but step 4 and the potentially massive post-move cleanup yielded too many nuances and corner cases to consider at the time the tool was made. I'm now looking back at the tool and am unimpressed and think that if I were to consider feature suggestions, I'd want to do a bit of an overhaul in the design itself. I do think it's a good habit (and responsible) to do "Step 4" and "post-move cleanup" — Andy W. (talk) 20:48, 20 December 2018 (UTC)

A generalized post-move cleanup would certainly be out of scope and too complex to automate; the burden is clearly on page movers to examine in detail what needs to be fixed. However, the most common case requiring the page swap tool does leave a redirect to self, and I have a feeling this could be corrected automatically without much fuss. Happy to discuss further, and possibly help with the MVP specs, if you feel like giving it a try. — JFG ^talk 21:06, 20 December 2018 (UTC)

Not asking for help for now, but just putting some cases out there: if one swaps A with B. Should a self-redirect at either A or B be corrected? If, post-move, A redirects to A, but Talk:B redirects to Talk:B, what should the script do then? Should it correct the mainspace or talk? Or should it point A to B and Talk:B to Talk:A? Or, if A redirects to A, Talk:A redirects to Talk:A, but Talk:A/sub doesn't redirect, and Talk:B/sub2 redirects to Talk:B/sub2, what gets corrected then? Does the tool account for the potentially several dozen subpage redirects or self-redirects? Maybe the MVP is just to correct mainspace, but there are reasonable counter-arguments as soon as redirect correction/creation come into play.... I'll try to think this over... real-life says I probably can't in a reasonable amount of time (I'm not really that quick). With due respect to all page movers, I think the burden to check for self-redirects is on them for now. I'm totally okay if someone else wanted to look into some basic handling and improve the tool separately — Andy W. (talk) 21:36, 20 December 2018 (UTC)

Is there a talk page for your script where we could move this conversation? — JFG ^talk 21:41, 20 December 2018 (UTC)

Just a thought

Regarding the deletion of talk page redirects as a result of round-robin moves: I know this isn’t documented, but whenever I perform a round-robin move that results in a talk page redirect being deleted, I recreate the page as a redirect to its new talk page target and tag it as {{R from move}}. What Andrewa states above does happen, and I do care and think that it is common sense, so I do this to fix any possible damage. Steel1943 (talk) 17:15, 17 December 2018 (UTC)

Thanks Steel1943. That is IMO of course the correct course of action exactly, and IMO that should be uncontroversial... as you say, to me it is pure common sense. But evidently not so common, and so sometimes it's not being done, and when I ask why not I'm told (correctly) that the procedures don't require it. So at the risk of instruction creep I think we need to document it as a requirement. Andrewa (talk) 21:00, 17 December 2018 (UTC)

@Andrewa: I think that’s probably a good course of action at this point. It may need a discussion though since it seems actually doing it is controversial; but then again, that’s what this section is here for, so I’m 50/50 on which course of action to take. Steel1943 (talk) 15:11, 18 December 2018 (UTC)

It's common practice to create redirects from redlinks after completing a round-robin move, and the script that most of use for this purpose already instructs the user to check their contributions for redlinks after performing the move. I'm sure this is an oversight on the part of the movers. Regardless, the redlinks can easily be created by any other editor who comes along, so it's no big deal.

If any other page movers are reading this section, consider this a reminder to properly clean up your round-robin moves. Bradv🍁 15:50, 18 December 2018 (UTC)

It is common practice, but it's not universal, and it's not even universally agreed that it is the right thing to do... not sure I can be bothered finding the diffs of page movers who have protested to me that they have followed the swap procedure and have no intention of ever going to the trouble of fixing the broken redirect. But there have now been several. Yes, it's easily fixed, just as soon as someone who knows how to fix it (and cares enough to do so) notices the redlink, but meantime links are needlessly broken. I think we have consensus here that it should not be necessary for someone else to fix them. Andrewa (talk) 20:02, 18 December 2018 (UTC)

Andrewa, I would say that's an accurate summary of existing consensus, and I would point anyone who fails to clean up after their round-robin moves to the instructions at WP:ROBIN. Bradv🍁 20:09, 18 December 2018 (UTC)

OK, just to clarify... I've given above two examples of page movers not IMO cleaning up adequately. Are you saying that one or both of these clearly violated WP:ROBIN? If they both did then you're right, no need to modify the instructions, and I might even gently take it up on the talk pages of the page movers involved to avoid any repetitions. Andrewa (talk) 14:31, 19 December 2018 (UTC)

Andrewa, yes, both of the moves you listed above were round-robin moves, and the talk page redirects should have been created as part of the cleanup. I wouldn't say "violated", as the cleanup procedures are not policy, but yes, the page movers missed this. Bradv🍁 15:06, 19 December 2018 (UTC)

Yes, I guess that is a bit strong, and violates the spirit and letter of wp:NPA as it was originally intended (but that was long ago). But someone should gently bring it to the attention of the page movers involved, don't you think? Andrewa (talk) 21:05, 19 December 2018 (UTC)

Including the recreation of the talk page redirect in the script (ping Andy M. Wang) would probably fix the issue. Though, TBH, it has never been much of a problem for me to recreate the redirect and I always do so. Galobtter (pingó mió) 16:59, 18 December 2018 (UTC)

Andy is now less active, may not respond here. Automatic recreation of the redirects was intentionally not included because of potential drawbacks, see this talkpage archives 1, 2. It's quite easier for human to figure out correctly where the redirect should go. May be because I usually do it, I don't see this as an issue, and a bit surprised it's being discussed. –Ammarpad (talk) 04:45, 19 December 2018 (UTC)

It could be an checkbox option when performing the move, though I do know there are more complex cases where one doesn't want to create the redirect. Galobtter (pingó mió) 04:49, 19 December 2018 (UTC)

• Another alternative is to not use page swaps in the first place. In the majority of cases these aren't really needed: if you can think of a plausible redirect that doesn't exist yet then it's simpler to use that as the destination of the blocking redirect: the sequences of moves B -> C, A -> B is simpler than the page swap process B -> X, A -> B, X -> A. – Uanfala (talk) 18:03, 18 December 2018 (UTC)
  • ...Which is impossible for a page mover to do in cases where "C" already exists if it is not targeting "B" already and/or has more than one edit in its history. This problem comes up frequently with disambiguation pages since their only community-accepted titles are either the ambiguous title or the ambiguous title (disambiguation). Steel1943 (talk) 04:19, 19 December 2018 (UTC)
    • But that's not the scenario. The scenario is that C does not exist; It's the plausible redirect that doesn't already exist, and is created in this process, also preserving the page history of one of the two pages. Neat. Or am I missing something?
    • And it's not generally true of disambiguation pages that their only community-accepted titles are either the ambiguous title or the ambiguous title (disambiguation). See yesterday (song)f or example. Or again, am I missing something? Andrewa (talk) 06:23, 19 December 2018 (UTC)
      • @Andrewa: Yesterday (song) is a {{R from incomplete disambiguation}} redirect that tells our readers that the disambiguator "(song)" is ambiguous and could refer to multiple existing Wikipedia subjects; it wouldn’t be the name of the disambiguation page itself. Steel1943 (talk) 12:21, 19 December 2018 (UTC)
        • All true, but we seem to be at cross purposes. The point is just that it's a plausible redirect and if it didn't exist it could provide an alternative to the relative complexity of a round-robin move. Andrewa (talk) 14:31, 19 December 2018 (UTC)
          • Right, and I understand that and even take such action myself in the event of moving edit histories. And I was stating that this will not always be an option. For this I think we are both agreeing about the same thing at this point. However, for what you are saying for this part: I do not believe that trying I avoid round-robin moves in this manner should be enforced since that would also require that the page mover be familiar with useful redirect titles that would basically be able to survive a WP:RFD without page history, which is currently not a requirement for getting the page mover right and in my opinion shouldn’t be. Now that ... I would call unnecessary instruction creep. Steel1943 (talk) 20:34, 19 December 2018 (UTC)
            • Agree it shouldn't be a requirement. But it's an interesting option. Andrewa (talk) 21:00, 19 December 2018 (UTC)
      • ... And I’m saying there will not always be cases where there is a valid nonexistent "C" to move the edit history, given that moving edit history to a title that is not a useful search term as a redirect is, in my opinion, problematic and creates a new problem after solving another. Steel1943 (talk) 12:28, 19 December 2018 (UTC)
        • Agree that there will not always be cases where there is a valid nonexistent "C" to move the edit history and that moving edit history to a title that is not a useful search term as a redirect is... problematic.... All I am saying is, if such a term does exist (and that means it is a useful search term, otherwise it's not a plausible redirect at all), then this seems a very neat alternative to a round robin, and creates no new problem at all. I'm not sure how common these scenarios will be, and think that we should wait for a concrete example before deciding that. Andrewa (talk) 14:31, 19 December 2018 (UTC)
          • (I think I may have also answered this in my other response during this edit, but if I did not, please point it out to me as I’m not sure how to respond to this inquiry separately.) Steel1943 (talk) 20:34, 19 December 2018 (UTC)
          • The only new problem that I would see is that non-admin page moves are supposed to be easily reversible in the case of misuse, and the original page histories easy to locate. If a requested move discussion requested that two pages swap locations (for example, swapping a primary topic with a disambiguation page), then it's expected that the histories of both of those pages will be in those locations, rather than in some third location. The round-robin procedure makes that straightforward, and a reversal of the round-robin consists of exactly the same steps in the same order. Bradv🍁 20:37, 19 December 2018 (UTC)
            • Agree. But you and I see any broken link, even a talk page link, as important. I'm afraid many do not! See above and many other discussions, and maybe even User:Andrewa/Incoming links. Andrewa (talk) 21:00, 19 December 2018 (UTC)
            • I'm a bit lost now. Could someone give an example of a situation where a page swap is the actual intended outcome of an RM? If it's dab page vs. primary topic scenarios, I can only think of two at the moment: either Foo -> Foo (disambiguation) and Foo (bar) -> Foo, or Foo -> Foo (bar) and Foo (disambiguation) -> Foo. – Uanfala (talk) 22:15, 19 December 2018 (UTC)
              • @Uanfala: As far as I’ve seen, there is never a reason to swap two pages with content (neither one are redirects.) However, a few hours ago, I closed a move discussion and performed a move that requested moving a page with content to a title that was blocked by a redirect with more than one edit, and had to perform a round-robin move: Talk:Apostolic administration#Requested move 29 November 2018. (I think you are referring to the first sentence of my statement, but I’m providing an example of a round-robin move just in case.) Steel1943 (talk) 22:42, 19 December 2018 (UTC)
              • There may be scenarios in which content needs to be swapped but they are rare. What is common however is needing to move a page where both the new and old page titles each have significant page history that relates to the content of one of them. All of this history needs to be preserved (and presumably, reasonably and logically accessible) under our copyleft requirements. Any talk page contents are best kept with the page to which they refer, obviously, and we don't want to break links (and again would in some circumstances break our copyleft obligations if we were to do so, notably if there's been page merge or split activity in the past). It's a rather subtle requirement in some ways, and perhaps page movers should not be doing it at all. Andrewa (talk) 03:17, 20 December 2018 (UTC)

Another and not a round robin this time

I'm not quite sure how this happened, but I have just recreated Talk:Spiral Scratch (EP) thus restoring four broken wikilinks and any (undetectable) incoming external links. And again the closer was a non-admin page mover. Andrewa (talk) 23:56, 26 December 2018 (UTC)

Bot

I think it's best to just have a bot that recreates these talk pages according to the accompanying main page. Because a lot of the times, especially if a page mover is doing a batch move, it's just messy and that's besides tedious. --QEDK (後 ☕ 桜) 18:03, 27 December 2018 (UTC)

A bot could work. PageSwap can be a pain but it's the best way to do it, I'm not sure why it deletes the "source" talk pages but anything to remove a step from the cleanup would be appreciated! SITH (talk) 14:34, 29 December 2018 (UTC)

Since we want to swap the talk pages as well, it takes the history of the new talk redirect (none) with the one we want to swap (the talk to be moved), essentially deleting it. The pageswap tool could potentially also include a feature to redirect the swapped pages automatically after it's done but the tool creator is not active as of now, so a new maintainer could possibly achieve the same, I'll put a VPT thread. I'll tag @Andy M. Wang: for now. --QEDK (後 ☕ 桜) 16:41, 29 December 2018 (UTC)

QEDK, good idea, see my proposal for script modification below SITH (talk) 18:18, 14 January 2019 (UTC)

@StraussInTheHouse: Just for reference to future readers of this thread, my fork of PageSwap does prompt to create talk redirects in these situations. --Ahecht (TALK
PAGE) 19:26, 16 October 2019 (UTC)

A case of unnecessary round robin

I did a round robin because the target page already existed I couldn't move over it, even if the history was insignificant. I use the PageSwap script for moves which have extant targets and its default setting is a round robin move.

It is agreed I think that in this case there was no need to preserve the page history (in fact IMO it would even have been better not to in this particular case). See User talk:StraussInTheHouse#Akhil Bharatiya Hindu Mahasabha for the discussion if curious, but my point here is just that perhaps it would be good to give page movers better tools and/or instructions. And if we did, maybe the other (perceived?) problem(s?) would just go away. Andrewa (talk) 17:09, 29 December 2018 (UTC)

Andrewa, I've just finished closing a mammoth RM where most of them required pageswap (link). I wouldn't mind so much if the script didn't either delete the talk page redirect or just leave both the page and the talk page as redirects to themselves. Surely there's a way to amend the script to pull out the variable of "target page" and make it edit the original page and its talk page to make the post move cleanup less of a hassle? I mean, we can archive talk pages with one click so it can't be too difficult to do this. Otherwise, admins could just delete the insignificant redirects to make way for a move but that would be as easy because page movers would be constantly needing help. SITH (talk) 18:17, 14 January 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)

RfC: Should Page Movers be permitted to move move-protected pages?

Howdy fellow Wikipedians, thought to float the idea of page-movers getting access to move WP:GREENLOCKed pages.
Just to make the process easier with WP:RM/WP:RM/TR and the likes. In my opinion it seems a logical inclusion to the permission, with the 6mo/3000edit requirements and only ~291 of us mere mortals, I don't see this as being particularly risky. — IVORK _Discuss 23:36, 15 October 2019 (UTC)

Survey

• Support in principle, but one solution would be for admins to stop regularly using indefinite full move protection (and for all current indefinite full move protections to be reviewed and changed to either indefinite ECP, time limited full protection or unprotected altogether), when this practice is already strongly discouraged for edit protection. Iffy★Chat -- 12:26, 16 October 2019 (UTC) Update: I'd also support Hut 8.5's alternative proposal. Iffy★Chat -- 10:32, 17 October 2019 (UTC)

  There are some cases where indefinite and strong protection is a good idea; for example, when it comes to high-use templates, the move protection is typically at least templateeditor and above. Sceptre (talk) 18:05, 16 October 2019 (UTC)

  I was primarily thinking of articles (not templates) when I suggested that admins stop using indefinite full move protection. Iffy★Chat -- 10:32, 17 October 2019 (UTC)

• Support; as I've mentioned in the below section, it's something that would make sense to have and be nice to have. It's not urgent, but it would allow for page movers to work through the backlog a lot easier. My preference for the technical aspect would be by splitting the editprotected right into editprotected and moveprotected. Sceptre (talk) 19:05, 16 October 2019 (UTC)
• I'd be happier with creating a new protected level of "admins and pagemovers only" and using that as the standard for preventing page move vandalism. I strongly suspect there will be some cases where we do want to prevent non-admins from moving a page. Hut 8.5 21:47, 16 October 2019 (UTC)
• Support as nom? Hut 8.5 That is fair, but I feel that the majority of those cases would also have full edit-protect on. Additionally page movers would still be required to only make changes they deem uncontroversial/that reached consensus. Per below, the intent is that anything not full-edit protected but full-move protected would automatically become "admins and pagemovers only" if this is successful. — IVORK _Discuss 04:00, 17 October 2019 (UTC)
• Conditional Support I still have similar concerns as during the RfC that created the page mover right. Assuming that the technical and overhead concerns can be dealt with I support otherwise oppose. While a new level made sense for TE, I don't think it is the right solution for page mover as the amount of work from handling the new levels seems like it would override the amount saved by not having to ask admins to assist when moving a protected page. I also worry about accidentally protecting pages during moves that might not be easily reversible by the page mover. Any solution should not make it easy for a page mover to back themselves into a corner that they need admin assistance to undo. See also Overriding sysop move protection from the same RfC. Unless these concerns can be addressed though consider this an oppose but only for technical reasons. PaleAqua (talk) 04:17, 17 October 2019 (UTC)
• Oppose as proposed but support Hut 8.5's suggestion about a new lower level of move protection. - Tom | Thomas.W ^talk 09:21, 17 October 2019 (UTC)
• Oppose as proposed for lack of technical feasibility. Neutral on the lower level of protection proposed above. * Pppery * _{it has begun...} 11:43, 17 October 2019 (UTC)
• Oppose as proposed. There is no way to determine which pages the protecting admin thought okay for page movers to move and which not. Adding a new lower protection level as Hut 8.5 suggests would be okay, because then it would only apply to newly protected pages and thus be clearly what the protecting admin wanted. That said, is this really something that happens sufficiently often that we need more people able to do it (and possibly create a new protection level)? Regards SoWhy 13:37, 17 October 2019 (UTC)
• Oppose. "only ~291" page movers? That's not a small number, it's about the number of successful requests for adminship in the last ten years. Round-robin moves are an inferior kluge, something the community reluctantly settled on due to the shortage of administrators. Page-movers shouldn't be viewed as permanent second-class administrators; rather this position should be a stepping stone. Any page mover with a decent track record (minimum questioning of your closes) should make the step up and please, run for administrator. We should stilll have enough admins to deal with complex and controversial moves, including from protected pages. – wbm1058 (talk) 22:38, 17 October 2019 (UTC)
• Oppose No reason to give essentially bureaucrats (appointed by admins) permission to deal with pages restricted to users trusted by the community. If a page is full protected, the admins should already have noticed the problem. From AnUnnamedUser ^{(open talk page)} 23:25, 17 October 2019 (UTC)
• Oppose. A permission granted based on the discretion of one administrator should not be allowed to deal with fully-protected page titles. I know I myself am a non-admin page mover and would benefit from this provision, but I've seen too many cases of users making major mistakes after being granted the page mover right, and also that the right may be granted too leniently. For example, sockpuppet account Frayae was once granted this right. feminist (talk) 02:50, 18 October 2019 (UTC)
• Oppose This seems too much like partial-adminning, which doesn't work; to paraphrase the section of PEREN, if an editor can't be trusted with a fully-protected page (as evidenced by their being an admin), they shouldn't be changing it, period. Having said that, I would support Hut 8.5's proposal. – John M Wolfson (talk • contribs) 05:19, 18 October 2019 (UTC)
• Oppose – I really think that anyone who consistently runs into this problem should consider running for adminship. We always need more admins, and experienced page movers tend to do well at RfA. With respect to the move-protected pages, I suspect most of those could have their protection lowered, especially the ones which aren't edit-protected. – bradv🍁 01:37, 20 October 2019 (UTC)
• Oppose. On those extremely rare situations where a pagemover wants to move a fully moved-protected page, they can ask for assistance. Notwithstanding the report that Danny712 has generated below, there are only a tiny number of pages in Article and Article talk space that are fully move protected. There are only about 2500 protected pages in article/article talk space that are fully move protected, and almost every one of them would warrant a full and proper discussion before contemplating a move. I don't see any good rationale for pagemovers to move the fully move protected pages outside of mainspace; a lot of them are in userspace, and many are "special" pages for which there is almost no reasonably foreseeable reason to move them. It is possible to consider dropping the move protection down to "extended confirmed user" level for many of the article space pages, but realistically these are pages that aren't going to be moved. Risker (talk) 04:30, 20 October 2019 (UTC)
• This seems to be a solution in search of a problem. If feasible, protection should be lowered, which also requires administrator eyes. If lowering protection isn't feasible, then having an administrator close the discussion is probably advisable in most cases. Not because page movers would be unqualified, but because of WP:NACPIT/WP:BADNAC (e.g. "The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial"). Dekimasuよ! 09:28, 20 October 2019 (UTC)
• OpposeI'm unconvinced there's a problem here that needs solving, and I also oppose yet another kind of protection. In my opinion we already have to many kinds of protection and too many levels of user rights, we should only be adding more when there is a demonstrable, serious problem that can't be resolved with the current tools at our disposal. Beeblebrox (talk) 20:14, 23 October 2019 (UTC)

Non-Technical Discussion

• @IVORK: Question on goal: if a page is edit-protected past the current users ability to edit, and fully page-protected, would you be thinking "page movers" should still be able to move it? — xaosflux ^Talk 20:00, 16 October 2019 (UTC)

  @Xaosflux: (this is technical, but) MovePage::checkPermissions requires that the user be able to edit both the source and target for them to be able to move the page; this would allow protection of (in the form of edit/move): 'none/moveprotected', 'semi/moveprotected', 'ecp/moveprotected', or 'template/moveprotected' (though its unlikely that a page would be template-protected for editing but moveprotected (or whatever the new level is) for moving. DannyS712 (talk) 01:31, 17 October 2019 (UTC)

  I feel it is fine working within the above restriction as it exists. EC or Template edit protected max depending what the mover has. — IVORK _Discuss 03:43, 17 October 2019 (UTC)

• Is this a real problem? I honestly have no idea, are there regular RM backlogs due to move protection? Beeblebrox (talk) 23:27, 16 October 2019 (UTC)

  At the moment, most of the closures at RM seem to be done by non-admin page movers. Sometimes, RMs come from move-warring and act as an ersatz dispute resolution, so those pages are often move-protected as a result of move-warring. Sceptre (talk) 00:54, 17 October 2019 (UTC)

  So if the dispute is settled, shouldn't the protection get lifted? — xaosflux ^Talk 01:44, 17 October 2019 (UTC)

  While that is ideal, it is often not the case, e.g. recent cases like this. While the page may still need protection so auto-confirmed can't just push their wishes, it would allow for it to be moved without hassle only once a consensus has been achieved. Ultimately it would only lessen the tasks sysops need to do if it passes. And as others have said below, not an urgent task, but something that seems logical to a few of us here. — IVORK _Discuss 03:43, 17 October 2019 (UTC)

• Use case: There are currently (05:22, 17 October 2019 (UTC)) 9248 pages that are fully protected for moving, but not for editing. See table at Special:Permalink/921678062 - gives full move protection expiry, namespace, title, if it is a redirect, the edit protection level, and the edit protection expiry. I count just over 2300 pages in the main namespace (articles). Hope this helps --DannyS712 (talk) 05:22, 17 October 2019 (UTC)

  @DannyS712: thanks for the dump - sounds like a good place to have an admin cleanup drive to remove no longer needed full protections. — xaosflux ^Talk 11:39, 17 October 2019 (UTC)

• @IVORK: as far as I can tell this change would effectively allow page movers to replace a fully protected page with new content: they could move it to a new title, suppress the redirect, and then recreate the page with something else. Not being able to edit the original page wouldn't help because everybody looking for the page would see the recreated version and not the original. For sensitive pages (such as highly used templates) this could be a serious concern. I'm sure page movers can be trusted to abide by consensus but that doesn't necessarily help if, say, someone's account is compromised. Hut 8.5 17:41, 17 October 2019 (UTC)

@Hut 8.5: There has been discussion either way on the possibilities, I was basing it off the fact that implementing something like this would only enable page movers to ignore move perms and not be able to move if the page is edit-protected to a level above them, be it template or sysop. If this cannot be achieved then I definitely see that this issue could cause more issues that it would fix. — IVORK _Discuss 00:10, 18 October 2019 (UTC)

Technical discussion

• I'm not sure this is technically possible? It's my understanding from mw:Manual:User_rights#List_of_permissions that in order to move a page, one must have the ability to edit a page, and so we would have to give pagemovers the ability to edit full protected pages if we wanted to allow them to move greenlocked pages. @Xaosflux: do you know more about this? Wug·a·po·des​ 00:32, 16 October 2019 (UTC)

  @Wugapodes: so not quite - we certainly can have pages that are editable but not movable, which is the special condition that I assume IVORK is presenting here. From Special:ProtectedPages, User talk:Fuzheado is an example right on top of the list. There is no permission that exists that can be assigned to groups that would enable this without also enabling editing of protected pages (it is in "protect"). As this is such a niche case, I can't see mediawiki developers spending time to work on it (it being the entire system that checks permissions during moves) either. Practically, this would create new situation that may need to be dealt with: If Page xxx is move only protected, but needs to be moved anyway - why? Should it just be unprotected? If not, what is the expectation, that the resultant page would still be move protected? What about the prior name, is it just a normal page now? Are there some practical examples of when these moves are needed, and what the expecting results would be? — xaosflux ^Talk 00:44, 16 October 2019 (UTC)

  There's a bunch of requested moves right now that rely on WP:NCC, and a good few of those are move-protected (Hawkeye (comics) (edit | talk | history | protect | delete | links | watch | logs | views) → Hawkeye (Clint Barton) (edit | talk | history | protect | delete | links | watch | logs | views)). Like the option to move articles over existing articles without a round-robin, it's something that would make sense for page movers to have and would indeed be nice to have, but it's something that isn't urgent to have. Personally, I'm much more concerned with the side-effect of RCAT being that moves over redirects have to be done via round robin. Sceptre (talk) 02:16, 16 October 2019 (UTC)

  @Sceptre: so for your example at Hawkeye (comics), the move protection has been in place for 6 years, supposedly per Wikipedia_talk:WikiProject_Comics/Archive_46#Marvel_Heroes_-_Voice_Actors. Is this protection really even needed anymore? We should be removing protection that isn't actively needed. As far as the question I had above, what would you expect the end result of this will be? Should anything still be protected? — xaosflux ^Talk 02:43, 16 October 2019 (UTC)

  Like I said, it's a thing that I think would make sense to have, but isn't an urgent thing to address, IMO. There are some pages – mostly templates – that should be move-protected because they're in high use, but there can be a consensus to move them at some point and technical restrictions make backlog maintenance difficult; {{Infobox hurricane}} is another example from today. For what it's worth, as someone who keeps an eye on edit protected requests (i.e. template/semi/500-30), indefinite full protections makes WP:RCAT-work more annoying than it should be, and, philosophically, is an argument for devolving more of the admin suite, but that's beside the topic. Sceptre (talk) 02:56, 16 October 2019 (UTC)

  @Sceptre: so I'm still a bit lost, so let's assume that Template:Infobox hurricane was able to be moved right now by "page movers" (via an imaginary permission that overrides full-move-protection), after the moving was done which pages should still have which protections applied at the end of the work? — xaosflux ^Talk 03:19, 16 October 2019 (UTC)

  Oh, in that case: the same as would happen if an admin were to move the article; basically, it would be splitting editprotected into two rights, editprotected and moveprotected. Sceptre (talk) 03:36, 16 October 2019 (UTC)

  @Sceptre: ideally, what would happen is an admin would review the protection levels and decide if they are still warranted then adjust or remove the protection levels as appropriate. The default is to "move the protection" with the page, but the protection policy says we should only protect pages that have a reason to be protected. — xaosflux ^Talk 11:04, 16 October 2019 (UTC)

• like Xaosflux is saying, there are too many technical things here to be discussed/thought about. Like what happens to the newly moved page, would it still remain move protected? The logical solution is to keep it protected. What happens to the leftover redirect?
  In the past, I've come across a few pages that I had to move, but couldn't. Most of them were from RM. I can't recall any of their names, but currently, assassination of JFK is editable, but move protected. I had also thought the same. But in practice, instances of moving the move-protected pages are very low. And after all, the protection is/was placed there for a reason. I think it is better to contact an admin or RM/TM rather than making changes in the software. —usernamekiran(talk) 03:48, 16 October 2019 (UTC)
• @Xaosflux and Sceptre: (edit conflict) As for whether this is possible:
  1. create a new protection level, eg moveprotected
  2. Grant the moveprotected right to administrators and page movers
  3. When admins protect pages, rather than, eg semi-protection for editing but full protection for moving (or template/full, etc) protect with autoconfirmed for editing (semi-protected) and moveprotected for moving

  While the protection options would exist for both editing and moving, it should be clear that administrators should not use moveprotected for editing protection. If this RfC passes, I can add a patch on gerrit (its literally 3 lines of code, and 14 lines of new system messages, that are changed). Hope this helps --DannyS712 (talk) 03:50, 16 October 2019 (UTC)

  Creating an entire new protection level just for this small edge condition seems like bad idea for me, and requires that all administrator comply with a new process and re-review every existing protection. Overall, I think creating new permissions for moveprotected and editprotected are a good idea though, but have them work with the existing protection levels. — xaosflux ^Talk 10:59, 16 October 2019 (UTC)

• Question would page-movers be able to move-protected pages that have also have higher protections on them, like template protection, without having access to those rights? Headbomb {t · c · p · b} 18:28, 16 October 2019 (UTC)

  @Headbomb: No. If either the current "editprotected" is split into "editprotected" and "moveprotected", or a new protection level is added, page movers will only be able to move pages that are fully protected (first option) or specifically have a move protection of "moveprotected" (second option) --DannyS712 (talk) 18:44, 16 October 2019 (UTC)

• Technical question (xaosflux?), when you move protected pages, don't the protection settings get replicated? –xeno^talk 18:30, 16 October 2019 (UTC)

  @Xeno: when you move a page, current protection and pending-changes protections are moved to the destination page. — xaosflux ^Talk 18:38, 16 October 2019 (UTC)

  The redirect left behind is unprotected? –xeno^talk 18:40, 16 October 2019 (UTC)

  From a non-technical perspective, when a fully protected page is being moved, it is certainly a good time to review and make any protection adjustments appropriate on the new page, and/or the old title/redirect. — xaosflux ^Talk 18:38, 16 October 2019 (UTC)

  @Xeno: no, the protection is copied, and remains with both the old redirect and the new page (if a redirect if left behind). However, if a redirect is suppressed, anyone will be able to recreate the page in terms of protection; nothing is left behind (though title black list and abuse filter still matter). Hope this helps --DannyS712 (talk) 18:54, 16 October 2019 (UTC)

  Yes, I didn't specify that this was only "if a redirect is left behind". — xaosflux ^Talk 19:58, 16 October 2019 (UTC)

  Thank you DannyS712, it does. So if implemented there would need to be a guidelines advising Page Movers not to take a protected page on a walkabout to apply protections to unrelated locations. –xeno^talk 19:12, 16 October 2019 (UTC)

• See brief, recent discussion at Wikipedia:Village_pump_(policy)/Archive_153#Changing/Adding_restriction_on_moving_pages_to_allow_"Pagemovers"_to_move_pagers_where_right_now_only_admins_can_do_so. ~ Amory (u • t • c) 19:46, 16 October 2019 (UTC)

• There's a very similar discussion going on here about giving main page regulars this permission so they can help out more at the main page. One of the issues we're discussing is the fact that this permission also enables editng/moving through protection on other pages and changing levels of protection, so our rights request proposal addresses that by specifying that the Main page editor userright cannot be used to edit through protection/change protection levels on other pages and that making those kinds of edits would be considered inappropriate uses and grounds for removal of the right. The right would be a new right, so we wouldn't have the problem of a group who had been given the right under lesser requirements. Maybe you can solve your problem similarly by making this an additional right rather than adding it to the current right, then having people apply for this additional right? Protected mover or something? --valereee (talk) 10:21, 17 October 2019 (UTC)

Issue with Move to Draft

Hi. At some point today, the "move to draft" option on my TW drop down menu went away. And apparently this is happening to other editor as well. Anyone know what is going on? Onel5969 ^{TT me} 23:12, 21 October 2019 (UTC)

It's still there for me onel5969, so unsure — IVORK _Talk 00:42, 22 October 2019 (UTC)

@Onel5969: It was gone, now the script was fixed DannyS712 (talk) 01:57, 22 October 2019 (UTC)

Thanks.Onel5969 ^{TT me} 02:18, 22 October 2019 (UTC)