With thanks to everyone who provided input and insight, I would like to put forth a proposal to create the Wikipedia:Page mover permission. My suggestion is that page movers would receive

suppressredirect (The ability to move pages without leaving behind a redirect)

move-subpages (The ability to move subpages when moving their parent pages)

tboverride (The ability to override the title blacklist)

modified $wgRateLimits, allowing them to move pages more frequently than most users

Add the ability for administrators to add/remove members from this new group.

Add the ability for bureaucrats to add/remove members from this new group (corollary of previous).

This userright would be especially useful to editors who assist at Wikipedia:Requested moves. –xeno^talk 00:17, 19 April 2016 (UTC)

Added the line above to empower the sysop group to manage membership. — xaosflux ^Talk 16:16, 22 April 2016 (UTC)

We don't normally add +- for the crat group anymore - unless there is a special reason? See Special:ListGroupRights (compare the admin list to the crat list). — xaosflux ^Talk 14:06, 6 May 2016 (UTC)

• Note - If a user opposes the creation of the right as whole (i.e. "Creation of permission"), they won't necessarily continue down the RfC and oppose each question individually, though it should be counted as if they had [if they don't take positions on any below — 08:11, 26 April 2016 (UTC)]. In that aspect, this summary is misleading, at least in its current state (permalink).—Godsy^(TALK_CONT) 10:18, 25 April 2016 (UTC)

  Not at all. Because you oppose the creation of permission doesn't automatically affect your stance on other proposals. --QEDK (T ☕ C) 10:45, 25 April 2016 (UTC)

  Both editors who oppose creation of the right as whole (at this point in time) have participated in !votes on the component parts with no predictable bias for or against. There's no need to assume implied !votes. Bazj (talk) 11:04, 25 April 2016 (UTC)

  On the other hand, I supported the top proposal with the assumption that my support will carry through the other proposals.--v/r - TP 21:40, 3 May 2016 (UTC)

• I've thought this concept over quite a bit, though it makes more sense in the oppose aspect, any way of looking at it in this way has flaws (especially as sections for the inclusion of extra tools have been added late).—Godsy^(TALK_CONT) 07:16, 18 May 2016 (UTC)

• Comment: Please fix the typo in the RFC at "The ability to move pages would leaving behind a redirect". What is intended? Also, just to be picky, is there a logic behind the naming scheme for these sub-permissions? Some have hyphens, some don't; some start with a capital letter, some don't. (Fixed.) – Jonesey95 (talk) 00:33, 19 April 2016 (UTC)

  Thanks. I guess they should all be lowercase. –xeno^talk 00:37, 19 April 2016 (UTC)

• Um... Am I missing something? I thought any registered user could already move a page... It's one of the little buttons in the tool bar at the top of the screen. Blueboar (talk) 00:38, 19 April 2016 (UTC)

  @Blueboar: This would allow them to move pages without leaving redirects, to move subpages when moving the parent pages, and to override the title blacklist - although most users can move pages, they cannot perform such abilities. They are also limited to 8 moves every 60 seconds, page movers would be able to move up to 100 per 60 seconds. –xeno^talk 00:41, 19 April 2016 (UTC)

• I believe that this RfC was probably advertised too soon. What are the general criteria for the right? "Experienced" is a very vague term. What justifies revocation of the right? What are proper and improper uses of the right? When to use the right to close a requested move, and when to delegate that responsibility to admins? Much more detail is needed as this is probably the most significant admin-level right "package". Esquivalience ^t 00:51, 19 April 2016 (UTC)

  I think this would be a useful package in general, however I agree that its usage needs to be controlled - this is not as dangerous as template-editor, but probably slightly more so than file-mover so I suggest modelling after that framework. — xaosflux ^Talk 01:10, 19 April 2016 (UTC)

  @Esquivalience: I put some draft guidelines for granting/removing on the project page - please review and make contributions (anyone). — xaosflux ^Talk 01:29, 19 April 2016 (UTC)

  Yes. But the wording for granting things like File Mover are equally vague, referring only to "experienced" users. I'd probably prefer something a little more specific, like "6 months of active editing" to qualify. On the actual "page mover" side of things, I'd support leaving the qualifications a little vague: something along the lines of "...demonstrated experience with page moves..." rather than a specific numerical criteria – I trust Admins can figure out who should be granted this right on their own... --IJBall (contribs • talk) 02:13, 19 April 2016 (UTC)

• However, without specific criteria, the Dunning–Kruger effect will take over, and applicants will apply early (particularly the hat collectors). Esquivalience ^t 02:19, 19 April 2016 (UTC)

• That's why I'd put something like "6 months of active editing" and "demonstrated experience with page moves (or WP:RM)" as the minimum qualification. Meanwhile, I don't have it out for "hat collectors" – I'd don't care if you're a "hat collector" as long as you intend to use the tools you obtain for the good of the project (even if it's relatively infrequently). (Frankly, I tend to view "hat collecting" as a mild incentive for useful activity around here...) And anyone who is out of their depth after gaining this right won't keep it for long. --IJBall (contribs • talk) 02:25, 19 April 2016 (UTC)

• To accomplish a page move to a title which already exists as a redirect, would it be proper for a page mover to first move the redirect page to a different title while suppressing the redirect normally created and then tag it for deletion? For example if "A" is a redirect to "Alphabet" and an article is created for "A", the redirect could be moved from "A" to "A (delete)" and then tagged for deletion while the article could then be moved directly to "A". In my opinion, if this would be allowed, a standard procedure for doing it should be created.--John Cline (talk) 07:37, 19 April 2016 (UTC)
  • I don't like that, it would make the logs more of a mess than they should be and would presumably have us end with a lot of deleted "Page X (delete)" types for no benefit. Considering an admin would have to delete them anyway, it would be easier IMO to just stick with the current practice of tagging the page for deletion. Jenks24 (talk) 10:19, 19 April 2016 (UTC)
    • "A (delete)" would be unnecessary; it could just be moved to the former title of the article moved to "A". Peter James (talk) 22:44, 20 April 2016 (UTC)

      Thank you Peter James, your suggestion may indeed be a better means. My question was not framed to suggest how a work-around ought be, but rather to see if it should be done at all, and then to suggest that a standardized procedure be outlined for doing it if it was a thing worth doing. While it seems worthwhile to me, it clearly is not free of contention and I suspect it will require more discussion than this question will engender.--John Cline (talk) 05:51, 22 April 2016 (UTC)

• Question: would this userright include the ability to move pages through move protection? Through create protection? Ivanvector 🍁 (talk) 21:49, 19 April 2016 (UTC)

  Not any more than what autoconfirmed users can do. Overriding move or creation protection requires the same user rights as editing, so 'editsemiprotected', 'editprotected', and whatever other levels have been made up recently. Ajraddatz (talk) 22:08, 19 April 2016 (UTC)

• Question, the user rights groups are convoluted enough, is there any chance to add these rights to existing groups? Vague idea, template editors and image reviewers are supposed to know their stuff. –Be..anyone 💩 03:22, 20 April 2016 (UTC)
• Enh this is all fine but what I really need is the ability to move pages over existing redirects. Very often the desired new name already exists as a redirect (and if not, why not? Why are renaming an article to a title which up til now it was assumed no one would even search on?) Never in my life had cause to move a page with subpages, to move a page without leaving a redirect, or to move to a blacklisted title (or at high speed, but I'm not a bot). Not saying these abilities wouldn't be useful to someone, but not me. Is this a solution in search of a problem? It would be for me, but OTOH that's just my narrow experience. Herostratus (talk) 23:54, 20 April 2016 (UTC)

  @Herostratus: You may want to peruse the discussion on this page above this RfC – originally, I also thought that this proposal wouldn't be useful without a new moveoverredirect userright (basically what you're suggesting), but I was convinced by the above discussion that a series of "round-robin" moves combined with suppressredirect achieves largely the same result (though with a little extra work involved), and removes the issue of the people who would oppose the proposal because of moveoverredirect's possible potential for "backdoor deletions". (Or, at least, it should have removed the objections to "backdoor deletions" from this discussion!...) --IJBall (contribs • talk) 01:21, 21 April 2016 (UTC)

  • Oh OK. Sure, it makes eminent sense to make a proposal that's actually passable. Herostratus (talk) 05:29, 21 April 2016 (UTC)

• Note I updated the table, but couldn't really tell what the color scheme was. I set it to follow the RfA margins, so green above 75% (likely to pass), yellow for 65% to 75% (discretionary), and red for below 65% (unlikely to pass). If anyone has problems with this, feel free to suggest changes. Wugapodes (talk) 18:19, 29 April 2016 (UTC)

  There was not really much thought in it - I think I stole it from the last RFARFC. — xaosflux ^Talk 19:47, 29 April 2016 (UTC)

  I don't think the colours are necessary. Especially since folks can't seem to agree on the thresholds. This isn't a vote, I'm sure the closure can do without colour scheming. –xeno^talk 12:54, 4 May 2016 (UTC)

• I agree with the above note by User:Godsy. I oppose the creating of any and all of these rights and features proposed here, since I think the systems works fine and strongly oppose the increasing bureaucracy of Wikipedia. Please count my voice as "opposed" on all accounts. I am sure more people expressed their opposition on one field, but mean to oppose all of them together as a result. Perhaps we should create a section "Oppose the whole proposal"? Debresser (talk) 12:44, 11 May 2016 (UTC)
• According to https://phabricator.wikimedia.org/T133981 , it looks like this new group will be called extendedmover. The right contains flags for suppressredirect and move-subpages. No rate limit increase, no title blacklist override, no move protected ability. — Andy W. (talk · ctb) 09:01, 16 May 2016 (UTC)
  • They are waiting on the close ( not the "staled" ) so what is there can match the close of this. Some of the patchset versions at gerrit do have those other flags and some don't. PaleAqua (talk) 16:03, 16 May 2016 (UTC)

• Comment - Unbundling isn't a solution to a broken RfA process; it's a band-aid fix, and one that I worry will further increase the status of admins and make it harder for people to demonstrate a need for the sysop bit. People could increasingly be told that if they want to help in the area, they shouldn't bother with RfA, but rather just request these incomplete permissions. Then again, others think that this might be a stepping stone to proving trustworthiness with the sysop tools. I think that this is a good, well thought out proposal, and will be helpful for reducing RM backlogs - I just worry about the underlying cause and the future impact it will have. Ajraddatz (talk) 18:58, 19 April 2016 (UTC)
  • Everyone continues to assume that the problem is a "broken RfA process" – everyone continues to ignore that no one wants the Admin job because the Admin job sucks. As long everyone keeps viewing this as a "we need more Admins problem" rather than "we have a bunch of veteran editors that don't want to be Admins – how can we put them to work for the project?" problem, this project will continue to go into steady decline with growing backlogs. It's been 10 years, folks – the problem isn't "RfA": it's the current system that assumes that everyone who isn't an Admin, even our veteran editors, is a potential sneaky vandal who wants to take down Wikipedia and can't be trusted to do anything... --IJBall (contribs • talk) 23:24, 19 April 2016 (UTC)
    • The admin job doesn't suck, or at least it is no worse than editing here in general. Users without sysop tools can maintain the site in a way that is intrinsic rewarding to them, and users with sysop tools can do the exact same thing - if anything, it's nicer to be able to press the buttons yourself rather than tag pages and wait for other people to do it for you. I certainly agree that there is an underlying problem (and I think your conceptualization of it is correct as well), but it culminates at RfA. If adminship was actually treated as just another few rights that could be given to trusted users, then we wouldn't need to create these incomplete permissions groups that really shouldn't need to exist at all. Ajraddatz (talk) 00:08, 20 April 2016 (UTC)
      • That ship has sailed: the "no big deal" vision of Adminship has gone away, and it's not coming back. What matters is that lots of us do think the job is unattractive, and I don't think anyone's changing our minds about it. The truth is, even if RfA became a "cakewalk" overnight, there's still a large numbers of editors who won't sign up because they don't want the hassle of the whole bit, but might be willing to do some smaller portion of it. --IJBall (contribs • talk) 01:44, 20 April 2016 (UTC)
• Comment shouldn't pagemover be combined with filemover permissions? -- 70.51.46.195 (talk) 05:06, 24 April 2016 (UTC)
  • Nope – I understand page moves, but know nothing about file moving. I'm sure there are some File movers that feel the reverse. Best to leave them separate. --IJBall (contribs • talk) 21:28, 25 April 2016 (UTC)
    • There is no longer a functional difference, with modern versions of MediaWiki. There used to be a difference, but that was in old versions. Current versions of MediaWiki just lets you move files and redirects on filepages work just as expected. We seem to have some archaic imports from WikiCommons encumbering our process rules, but that's the only thing. -- 70.51.46.195 (talk) 13:01, 26 April 2016 (UTC)

1. Support support this in general, agree that criteria for assignments needs development. — xaosflux ^Talk 01:05, 19 April 2016 (UTC)
2. Support in principle, as it could help reduce the RM backlog drastically. Esquivalience ^t 01:08, 19 April 2016 (UTC)
3. Support this will help reduce backlogs in easily reversible housekeeping areas (ex: getting an accepted AfC promoted on top of a pre-existing redirect), as well as at RM. I especially hope this can help make userfication a more attractive alternative to deletion in the case of new editors' clueless contributions. Happy Squirrel (talk) 01:37, 19 April 2016 (UTC)
4. Support – the same idea for this has been rattling around in my head for about a year, and I was thinking of proposing the same myself this summer. With the growing backlogs at WP:RM, this is needed – any maintenance area that can be adversely affected by the absence of a single Admin needs to be unbundled for the good of the project. --IJBall (contribs • talk) 01:55, 19 April 2016 (UTC)
5. Support a good idea in general and will help reduce the backlog. --Tom (LT) (talk) 02:01, 19 April 2016 (UTC)
6. Support. This look useful. I don't see any downsides. NinjaRobotPirate (talk) 02:02, 19 April 2016 (UTC)
7. Support, as a great idea. APerson (talk!) 02:05, 19 April 2016 (UTC)
8. Support – Seems like common sense. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
9. Support because this could be very helpful for non-admins involved in WP:RM, and help them carry out uncontroversial technical moves. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)
10. Support, there is a need as this could help with RM backlog. PaleAqua (talk) 03:17, 19 April 2016 (UTC)
11. Support Yes, please! --QEDK (T ☕ C) 09:33, 19 April 2016 (UTC)
12. Support entirely support the principle. If nothing else, reducing the size of leap up to Admin should help in the general campaign to make RfA less of a battleground. Bazj (talk) 11:08, 19 April 2016 (UTC)
13. Support. It is becoming increasingly apparent to me that unbundling is the only answer to our admin problems. Biblio (talk) 18:28, 19 April 2016 (UTC)
14. Obvious support Not worried about suppress redirect right, we have logs.--v/r - TP 20:00, 19 April 2016 (UTC)
15. Support in general, regardless of the determination of suppressredirect (I oppose it being included, but if it's included per consensus, no worries. A user group such as this has been long overdue.) Steel1943 (talk) 20:49, 19 April 2016 (UTC)

    However, I just realized that if suppressredirect isn't approved, then this right would only apply to moving several pages in a short period of time, essentially neutering the entire foundation for this proposal. This might as well be called "Mass page mover" if suppressredirect isn't approved. Steel1943 (talk) 21:07, 19 April 2016 (UTC)

    Yes, if you oppose including suppressredirect, it effectively means you oppose the proposal (as the proposed usergroup is worthless without it). So you might consider changing your !vote to "oppose". --IJBall (contribs • talk) 23:07, 19 April 2016 (UTC)

    @IJBall: I gave it some thought, and overall, I support this proposal. Non-admins having suppressredirect could save a lot of editors' and administrators' time alike, and that's a plus. I still have my reservations since it blanks a title in the process, but I definitely see its usefulness. Steel1943 (talk) 17:02, 21 April 2016 (UTC)

16. Strong conditional support (sorry) - as long as this is not going to take page moves away from users without the new userright. Anyone can move pages. As a way to enable the other advanced permissions discussed below, sure. Ivanvector 🍁 (talk) 21:35, 19 April 2016 (UTC)

    • No part of this is proposing removing the move permission from existing groups, notably that permission is not actually listed in this group - the ability to do any of these tasks at all is dependent on the general editor ability to move pages. — xaosflux ^Talk 21:56, 19 April 2016 (UTC)

17. Support. This is a longtime coming and could hopefully reduce (or dare I say end) the permanent backlog at WP:RM. Calidum ¤ 22:56, 19 April 2016 (UTC)

    • How does this reduce the WP:RM backlog? The issue with the backlog is pages existing that block moves (which require a page deletion before the move can even happen), not ensuring no redirect is left over after a move. Steel1943 (talk) 00:10, 20 April 2016 (UTC)

    • A pagemover could move the old page out of the way to accomplish this, round-robin style. The deletion would still be needed wherever it was parked though. — xaosflux ^Talk 01:33, 20 April 2016 (UTC)

    • Yes, it's clear that a number of voters have not ready the entire discussion up-page – it would be advisable that they do so. This "backdoor CSD" argument holds no water... (And I don't think it would "require" a deletion to whereever it was parked – that's what the "round-robin moves" is for: the original "blocking" page is moved to the original redirect location, and it would only be deleted if subsequently tagged for CSD.) --IJBall (contribs • talk) 01:49, 20 April 2016 (UTC)
    • (edit conflict) @Xaosflux: That course of action would just shift the place where work needs to be done and misplace the deleted page history. Administrative action would still be needed to delete a page. WP:RM/TR and WP:G6 are quick and efficient enough, without the problems and potential for abuse. The vast majority of page moves should leave a redirect per our deletion policy. Generally, the only time it would be appropriate to use this proposed right in a straightforward manner is in the event of page move vandalism, which can already be handled by applying a WP:CSD#G3 template.—Godsy^(TALK_CONT) 02:26, 20 April 2016 (UTC)
    • (edit conflict) @Xaosflux: Right, so even with that, you would be clearing one backlog (WP:RM) while contributing to another (WP:CSD). And then, since the page which was moved out of the way will most likely be converted to a redirect (if it wasn't one already), if the speedy deletion of that redirect is denied, it will end up listed at WP:RFD. This solution will seemingly keep on "passing the buck" until either CSD or RFD anyways (with the RFD being the page at the title that the "page mover" created.) This seems rather counterproductive. Steel1943 (talk) 02:30, 20 April 2016 (UTC)

    See User:IJBall's comments above - other than for vandalism - the "old name" may still be kept, and would now be a redirect to the new name - not actually needed a deletion. — xaosflux ^Talk 02:35, 20 April 2016 (UTC)

    @Xaosflux: Right, which would mean that if there was a leftover redirect, it would be eligible for WP:G3 speedy deletion. Again, that is a CSD, and non-admins notice the issues and tag the pages, and then an administrator verifies it correct and takes responsibility for the page's deletion after the tag is placed. Allowing a non-administrator to circumnavigate this goes against the very first sentence of the Wikipedia:Criteria for speedy deletion policy page itself. Steel1943 (talk) 02:47, 20 April 2016 (UTC)

    (edit conflict) You mean whatever title the page is moved to that is "out of the way"? That would potentially lead to the creation of superfluous redirects.—Godsy^(TALK_CONT) 02:48, 20 April 2016 (UTC)

    @Godsy: Right, such as the redirects that have been appearing lately at WP:RFD with the suffix "/version 2" or "(version 2)". These redirects have been seen as troublesome since they are useless search terms. Steel1943 (talk) 02:53, 20 April 2016 (UTC)

    @Steel1943: "Round-robin moves" as I understand it: b is moved to c without leaving a redirect, a is moved to where b was without leaving a redirect, then c is moved where a was without leaving a redirect (technically those deletions would be non-criteria deletions unless the csd was expanded to cover them). So superfluous redirects wouldn't exist if executed properly. I still don't support the expansion of suppressredirect to non-administrators due to my concerns about abuse and the lack of a real need I as express below.—Godsy^(TALK_CONT) 03:33, 20 April 2016 (UTC)

    So, to be clear, you don't trust the veteran editors to whom this right would be granted ('cos it's not going to newbies), and you don't trust the Admins who would be doing the granting of this right to check that an editor is ready for it? And, if so, why aren't you opposing the whole package like Andrew D.? --IJBall (contribs • talk) 04:09, 20 April 2016 (UTC)

    @IJBall: I don't see a need for it and concerns about abuse ≠ not trusting veteran editors who would be granted this right, and I prefer the consensus of the community in an RfA to grant the specific right in question as opposed to the judgment of an individual administrator. I'm not opposing the whole package, because I don't oppose giving move-subpages and upping the rate limit restriction a bit, however trivial just those rights alone may be.—Godsy^(TALK_CONT) 04:22, 20 April 2016 (UTC)

    Well, that's big of you, but the "package" is completely useless if reduced to move-subpages. (And it is about not trusting veteran editors.) In any case, I'd encourage Xeno to withdraw this proposal if looking like it's going on without suppressredirect, as it won't do much to help with the backlogs at WP:RM (which is the whole point of this, remember...). Meanwhile, good luck on waiting for the so-called "consensus of the community in an RfA" – no one's applying for it (and rightly so). --IJBall (contribs • talk) 04:31, 20 April 2016 (UTC)

18. Support This would make life a lot easier when moving pages over a redirect. That way editors won't have to constantly seek out an administrator when they want to do so. Kurtis ^(talk) 02:50, 20 April 2016 (UTC)
19. Support as long as the suppressredirect right is included. I notice that most editors opposing the inclusion of suppressredirect are active at RFD but not RM. As someone active at both venues, I can see how RFD discussions are usually closed punctually, unlike RM, which has been almost perpetually backlogged. Mass page moving would only aid moves of article talk page archives, which usually exist for more contentious articles that may not be appropriate for non-admin closures. SSTflyer 04:23, 20 April 2016 (UTC)

    • I previously handled WP:RM quite a bit in the past, but since we edit on "Wikipedia-time", there are no deadlines or editing location requirements, etc. FYI, the backlog that RM is seeing right now was not a regular occurrence a year or two ago. For this reason, I don't think that creating a new user group to resolve just one of many backlogs here is the resolution. Steel1943 (talk) 07:25, 20 April 2016 (UTC)

20. Support - this seems like a harmless quality-of-life improvement with no major drawbacks that would make editing Wikipedia that little bit easier for many editors. Specifically suppressredirect, which would come in handy for fixing pagemove vandalism or moving pages from userspace sandboxes to mainspace (the latter being quite common). And maybe bundle in File Mover, which is a borderline useless userright atm. Satellizer el Bridget ^(Talk) 12:24, 20 April 2016 (UTC)
21. Support We are talking about a group of editors who have satisfied a certain criteria and have demonstrated they could be trusted with the safety of the project. If they violate this trust, it is easy to have the permission removed, easier then an admin. McMatter ^(talk)/_(contrib) 13:28, 20 April 2016 (UTC)
22. Support a creation of page mover right. Not sure whether it should be distributed at first, until all the privileges have been sorted out. epicgenius: unlimited epicness (talk) 15:26, 20 April 2016 (UTC)
23. Support. Obviously useful. While I've seen some concern that this will result in less RfAs (successful and total), I think the opposite is true. This is one more way for those involved in requested moves to show they're trusted by the community and trustworthy when given new tools. ~ Rob^Talk 15:33, 20 April 2016 (UTC)
24. Support This would be very helpful for non-admins (who are assigned this right, of course). Peter Sam Fan 18:25, 20 April 2016 (UTC)
25. Support. Useful. Little, if any, downside as User:Mcmatter notes. Donner60 (talk) 05:58, 21 April 2016 (UTC)
26. Support. I've generally supported unbundling as a way to deal with the troubles involving admins. Wnt (talk) 16:12, 21 April 2016 (UTC)
27. Support Peter James (talk) 08:18, 23 April 2016 (UTC)
28. Support - I find the rationale for the creation of this user group far more compelling than the rationale I've seen from those who oppose.--John Cline (talk) 18:00, 23 April 2016 (UTC)
29. Strong Support Page-move vandalism is somewhat of a problem, but even more importantly, good-faith page moving from unexperienced editors is something I commonly come across. — Music1201 ^talk 19:08, 23 April 2016 (UTC)
30. Support - I would want the requirements to get this right to be significantly more stringent than other non-admin rights (reviewer, rollbacker, etc.), but this seems like a sensible move (not so unlike the way the filemover right on Commons eases one of its many administrative/maintenance duties). I would find it useful for being able to move over a redirect and move without leaving a redirect, but there's certainly potential for some big messes. — Rhododendrites ^talk \\ 21:10, 23 April 2016 (UTC)
31. Support The more good users can do for themselves and others the better. Alanscottwalker (talk) 00:55, 24 April 2016 (UTC)
32. Support – The only argument against this seems to be that it won't solve every problem with page moving. Unbundling the admin tools seems like the best way to fix a lot of problems Wikipedia has right now. KSFT^C 19:21, 24 April 2016 (UTC)
33. Support Seems reasonable enough. Wugapodes (talk) 20:21, 24 April 2016 (UTC)
34. Support: Definitely. This would be very useful in particular, and in general we need to unbundle more tools away from our dismal failure of an admin system.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
35. Support if given to highly experienced users, with specific criteria established. Rubbish computer (HALP!: I dropped the bass?) 08:09, 25 April 2016 (UTC)
36. Support If someone is trustworthy and experienced enough to use this right, go for it! FiendYT ★ 03:59, 27 April 2016 (UTC)
37. Support: This is one of my biggest aggravations on WP. Time to unbundle this tool. Long overdue. Montanabw^(talk) 23:15, 27 April 2016 (UTC)
38. Support - I concur with the need to unbundle some tools and allow trusted veteran editors to handle some of the more mundane tasks. — Jkudlick • t • c • s 09:59, 28 April 2016 (UTC)
39. Support. Would be very useful for experienced editors. White Arabian Filly ^Neigh 21:18, 28 April 2016 (UTC)
40. Support. I'm in favour of unbundling rights generally, and this seems like a sensible one to me with no major drawbacks. Boing! said Zebedee (talk) 23:54, 2 May 2016 (UTC)
41. Support. Sounds like a really good addition to Wikipedia. Looking forward to it. - CentreLeftRight ✉ 01:31, 3 May 2016 (UTC)
42. Support. I've been keeping an eye on this. The pioneers have been getting it right, I think. — Andy W. (talk · ctb) 01:59, 3 May 2016 (UTC)
43. Support - Unbundle makes sense. Page move vandalism is by far the most disruptive and obnoxious vandalism to deal with. Creating special permission will avoid some of the LTA accounts from using this form of vandalism. It will also prevent good-faith but disruptive page moves. EvergreenFir (talk) Please {{re}} 03:42, 3 May 2016 (UTC)
44. Support I have to say this is an absolute no-brainer for me. This is a very sensible and dare-I-say-it conservative unbundling. No drawbacks I can see. Let's do it! Peacemaker67 (click to talk to me) 04:26, 3 May 2016 (UTC)
45. Support - The unbundling of these tools is both a safe and an effective move that will result in a potentially huge net positive for Wikipedia. I vandal patrol a lot, and there are many times that sock puppets or blatant vandals will move user pages, talk pages, and article pages with the pure purpose and intention of causing mayhem and vandalism. Simply moving such vandalism back still causes work for administrators, as they have to delete the redirect that exists where the vandal originally moved it. Some of those vandals even manage to edit the redirect, making me unable to revert the move at all. Unbundling these tools and giving them out to senior or highly experienced vandal patrollers would give them another tool to revert vandalism easily and instantly without the need for an administrator to clean up (we need them at AIV instead :-)). I completely support the unbundling of these tools, and I think that doing so would yield very high benefit. ~Oshwah~^{(talk) (contribs)} 06:23, 3 May 2016 (UTC)
46. Support unbundling admin permissions where possible. —Ruud 10:09, 3 May 2016 (UTC)
47. Support Absolutely in this case. This will help so much with vandal patrolling like Oshwah said, and give less of a burden to the admins who already have enough on their plate as it is. RickinBaltimore (talk) 12:20, 3 May 2016 (UTC)
48. Support for the reasons stated by OP and others; this would ease the load on admins and help deal with the backlogs. --Gimubrc (talk) 17:10, 3 May 2016 (UTC)
49. Support - I support this classification, as it may limit who can move pages to those who prove that they can do it right. --Jax 0677 (talk) 17:11, 3 May 2016 (UTC)

    @Jax 0677: Just to be clear, no part of this proposal will remove any existing abilities from anyone. — xaosflux ^Talk 17:13, 3 May 2016 (UTC)

    Reply - @Xaosflux:, understood, this will simply control and monitor who gets extra editing priveleges. --Jax 0677 (talk) 17:19, 3 May 2016 (UTC)

50. Support. I see no harm to the project, and much good, viz. taking weight off the sysops. Bearian (talk) 21:10, 3 May 2016 (UTC)
51. Support. We need to try more ways of unbundling, and this looks like a relatively safe way to do that. --Tryptofish (talk) 22:01, 3 May 2016 (UTC)
52. Support. Would greatly simplify trivial maintenance work. — JFG ^talk 22:27, 3 May 2016 (UTC)
53. Support, unbundling is long overdue. Darmokand (talk) 22:29, 3 May 2016 (UTC)
54. Support -FASTILY 23:41, 3 May 2016 (UTC)
55. I believe this would help the project, just like the other user rights. Regards—UY Scuti ^Talk 05:58, 4 May 2016 (UTC)
56. Support - Clearly harmless and assuring better vigilance. Sainsf (talk · contribs) 06:59, 4 May 2016 (UTC)
57. Support: Yes please. This is trivial maintenance that by no means requires the intervention of someone daring to go through the hazing and snakepit of RfA. Ravenswing 10:55, 4 May 2016 (UTC)
58. Support Sounds like a great idea that has been kicked around for a while, so I'm glad it's finally happening. Callanecc (talk • contribs • logs) 12:18, 4 May 2016 (UTC)
59. Support Will heavily remove the page move backlog, which doesn't in most cases need an admin. Joseph2302 (talk) 16:10, 4 May 2016 (UTC)
60. Support. It's a useful right, reasonable to give to editors with solid experience. Lwarrenwiki (talk) 17:53, 4 May 2016 (UTC)
61. Support - Per above. The Master ---)Vote Saxon(--- 02:36, 5 May 2016 (UTC)
62. Support This will occasionally be useful for me when I need to undo page move vandalism, or when I need to deal with users who move their userpages prematurely at WP:CHUS. —k6ka 🍁 (Talk · Contributions) 11:46, 5 May 2016 (UTC)
63. See my comment in the following section.--Alexmar983 (talk) 16:47, 5 May 2016 (UTC)
64. Support, based on review and experiences herein over time. Kierzek (talk) 18:16, 5 May 2016 (UTC)
65. Support, this will be quite helpful at Wikipedia:Project Merge, which has its own backlog issues. GenQuest ^{"Talk to Me"} 20:55, 5 May 2016 (UTC)
66. Support This would be a great way to suppress malicious page moves --TJH2018talk 21:31, 5 May 2016 (UTC)
67. Support Awesome change that will reduce the WP:RM backlog by tons. Given our dwindling admin count as it is, this can certainly be delegated to a permission. NottNott|talk 21:40, 5 May 2016 (UTC)
68. Support because I broadly support the idea of unbundling, and I think at least some of the rights listed should be available to non-sysops. — Bilorv_(talk)^(c)(e) 22:15, 5 May 2016 (UTC)
69. Support Unbundling the tools so we can assign them to editors who need them is the path forward. Mkdw^talk 14:16, 6 May 2016 (UTC)
70. Support, will be of great use in patrolling de-userfications by new users, without all the additional responsibilities of admins. - HyperGaruda (talk) 05:34, 7 May 2016 (UTC)
71. Support, unbundling seems the way forward. Martinevans123 (talk) 18:02, 7 May 2016 (UTC)
72. Support - BMK (talk) 18:26, 7 May 2016 (UTC)
73. Support - Why not? Let's go ahead with this then. George Ho (talk) 05:05, 8 May 2016 (UTC)
74. Support – this will definitely help with the backlog at RM Snuggums (talk / edits) 06:35, 8 May 2016 (UTC)
75. Support – I do not see a reason not to. Double sharp (talk) 10:34, 8 May 2016 (UTC)
76. Support—indopug (talk) 05:48, 9 May 2016 (UTC)
77. Support- give the tools that are useful and needed to people who will use them. • • • Peter (Southwood) ^(talk): 11:22, 9 May 2016 (UTC)
78. Support – Necessary user right. --Zyma (talk) 05:35, 10 May 2016 (UTC)
79. Support I see no reason not to. Bronze2018 (talk) 14:17, 10 May 2016 (UTC)
80. Support as this would make it much easier for trusted non admins to move pages created at incorrect titles without needing admin help, assuming users with this right can move pages without leaving a redirect behind. Everymorning (talk) 16:00, 10 May 2016 (UTC)
81. Support. This will be useful, allowing admins to focus on things that actually require their experience. –Compassionate727 ^(T·C) 18:23, 10 May 2016 (UTC)
82. Support per arguments above. MB298 (talk) 00:02, 11 May 2016 (UTC)
83. Support - I don't see why not. -- The Voidwalker ^Discuss 00:42, 11 May 2016 (UTC)
84. Support - The page move process would benefit greatly from a group of users specifically dedicated to it. I especially like the suppress redirect and move subpage suggestions. These will ease the burden on administrators to delete unnecessary redirects and moving large numbers of pages. Eventhorizon51 ^(talk) 02:44, 11 May 2016 (UTC)
85. Support per arguments above. Tessaract2 (talk) 19:32, 11 May 2016 (UTC)
86. Support, especially if you can move over a redirect that actually should be the page name. Funandtrvl (talk) 17:56, 13 May 2016 (UTC)
87. Support. There's basically no reasons not to. Anarchyte (work | talk) 06:54, 14 May 2016 (UTC)
88. Support and unbundle more rights from the admin toolkit while you're at it (protection, blocking, deletion). --Bigpoliticsfan (talk) 17:18, 15 May 2016 (UTC)
89. Support, this will reduce RM backlogs and time waited for moves by a large number. ^{My name is}not^dave (talk/contribs) 15:40, 16 May 2016 (UTC)
90. Support. This would help non-admin gnomes like me immensely. I always find it absurd when I need to interrupt my flow of 100s of edits to ask for permission to do something so relatively simple. giso6150 (talk) 03:01, 17 May 2016 (UTC)
91. Support Will help the encyclopedia. ThePlatypusofDoom (Talk) 15:32, 17 May 2016 (UTC)
92. Support - Yes, per everyone :) Mlpearc (open channel) 15:42, 17 May 2016 (UTC)
93. Support - Gmcbjames (talk) 03:48, 18 May 2016 (UTC)
94. Support per User:Kurtis, having read all 'oppose' arguments. I do think this particular 'unbundling' of admin privs is appropriate. Donama (talk) 05:19, 18 May 2016 (UTC)
95. Support: Will be helpful. --Tito Dutta (talk) 06:25, 18 May 2016 (UTC)
96. Support: Unbundling is good. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)
97. I'd certainly Support extending the move function. VegasCasinoKid (talk) 12:09, 18 May 2016 (UTC)

1. Oppose per the comments of Ajraddatz above and WP:CREEP. Andrew D. (talk) 22:22, 19 April 2016 (UTC)
   • This is like, the opposite of creep. This is cutting process out.--v/r - TP 22:37, 19 April 2016 (UTC)
     • Nonsense. The proliferation of policies, processes, permissions and powers turns Wikipedia into a baffling, Byzantine bureaucracy rather than it being the encyclopedia that anyone can edit. Lately my watchlist has been dominated by the passing out of "extended confirmed user" rights – another absurd complication which further enhances the power of the incumbent establishment to shut out new users. Andrew D. (talk) 10:04, 24 April 2016 (UTC)
2. Oppose - looks like this will pass without much issue, so I can hop down here. It's very apparent that this proposal does not grant all of the required rights to move pages. The system of "round-robin" moves is a poor substitute for deletion, and there will still be all sorts of cases that can't be handled by the page movers despite obvious technical competence on their part. As such, I cannot support this band-aid solution to not getting new admins. There's a reason why those rights are given together, and without that, we'll continue to create two classes of editors here - one which happened to join pre-2007 and thus can be admins, and those who joined after and can't (as a matter of averages). Ajraddatz (talk) 17:22, 22 April 2016 (UTC)
   • Perhaps. But I really think it's worth it to start this up with the proposal as it. If it is determined after "Page mover" is created that it really needs moveoverredirect, then a subsequent discussion can be held about that to determine if there's consensus to create such a userright and add it to the "Page mover" package... Also, (and this comment isn't directly at Ajraddatz particularly, as I've seen others make the same point), but I have never understood the logic of "Well, this unbundling doesn't solve 100% of all possibilities, only 80-90%, therefore it doesn't make sense!" Firstly, lightening Admin loads by 80-90% on a particular task or in a particular area does help (e.g. with backlogs). And since no one is talking about "doing away" with Admins, it's expected that "Page movers" and "Template editors", etc. are still going to have call an Admin in to help in certain special cases – but that's as it should be. --IJBall (contribs • talk) 18:13, 22 April 2016 (UTC)
     • You hit the nail on the head with your last comment. These users still need to call in admin help. If they were around in 2007, then almost all of the people that we trust with these permissions would already be admins. Instead, we have a strange class system in which non-admins face social and technical restrictions. They need to specify "NAC" when closing a discussion, as if their lack of sysop tools somehow makes their judgement inferior by default compared with someone who became an admin with 1,000 edits in 2007 with 20 supports on their RfA. Unbundling isn't just not a solution, it actively perpetuates this problem by giving users a technical means through which they can participate in 90% of the process, while still being assumed to be less trusted than an admin because they haven't passed an RfA. There shouldn't be a reason to bring in admin help; these people should just be admins instead. Dear Lord, I think I just turned into a wiki-Marxist. PS - creating a moveoverredirect right wouldn't be technically possible. The system already can identify a redirect-only page history and let you move over it, but beyond that there is no way to tell if you would be deleting revisions by moving a page over a redirect which might have a history attached. It would be the exact sort of back-door deletion that people are somehow arguing applies to 'suppressredirect' below. Ajraddatz (talk) 18:31, 22 April 2016 (UTC)
       • FWIW, the way I've heard it told iz that while moveoverredirect was not technically feasible originally, it may be (or is) technically feasible now. --IJBall (contribs • talk) 20:52, 22 April 2016 (UTC)

   I'd say the job isn't getting new admins but making Wikipedia easier to use for non-admins. Satellizer el Bridget ^(Talk) 09:10, 23 April 2016 (UTC)

   Absolutely. And a so-called band-aid solution is better than no solution. All kinds of things about WP are duct-tape-and-bailing-wire, yet we live with them just fine.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:45, 25 April 2016 (UTC)

   I'd generally agree, hence why I'm only putting an oppose here after it is clear that the proposal will pass. But if we're going to discuss things, we might as well fix the problem. Ajraddatz (talk) 23:23, 27 April 2016 (UTC)

3. Oppose this and all ingredients; solution in search of a problem. Stifle (talk) 13:22, 29 April 2016 (UTC)
4. Oppose This creates yet more complexity in our user permissions and I don't think proponents have made the case that this is actually necessary. Oiyarbepsy (talk) 00:17, 4 May 2016 (UTC)
   • Some additional comments. I've read some of the discussion of a need for this (all of it off-topic on boards designated for a completely different purpose, please don't do that again), and, while I appreciate some of the problems, I don't really think a new user right is necessary for this. I would suggest making the move subpages option part of the existing extended-confirmed right and not creating a new group. Oiyarbepsy (talk) 03:02, 8 May 2016 (UTC)
5. Oppose per Andrew Davidson. Down with the Bureaucratic Oligarchy.--Catlemur (talk) 16:35, 4 May 2016 (UTC)
6. Oppose It will lead to concentration of rights to a kitchen cabinet and a strong bureaucracy will get created undermining the motto of Wikipedia where everyone can edit.InspireTheWorld (talk) 13:49, 8 May 2016 (UTC)
7. Oppose unbundling of admin abilities. Promote trusted people to admin instead. —Kusma (t·c) 02:30, 9 May 2016 (UTC)
8. Strong oppose This makes admins more useless. What is the point of having admins if their privileges will just be broken out to different groups? --Pokéfan95 (talk) 06:18, 17 May 2016 (UTC)

• Comment – I see the massive lack of trust of our veteran editors continues... --IJBall (contribs • talk) 23:14, 19 April 2016 (UTC)
• People need to understand that deletion of redirects is not a deletion of content/revisions because it's entirely moved. --QEDK (T ☕ C) 06:06, 21 April 2016 (UTC)
  • I'm also struggling to see how this is a deletion. This is not about overwritting existing redirects which editors can already do and is a sort of deletion. This is about not doing an automatic page creation during a move. Without it round robin moves would end up with temporary stub redircts along the way. For example ( and note this can be already done without this user right ) A to A prime leaving redirect, C over the new redirect at A leaving a redirect at C. B would then be moved over the C redirect and leaving a redirect at B and finally the problematic move A prime would over the new redirect at B leaving a redirect at A prime. With this permission the move from A prime over the new redirect at B could be done without leaving a redirect at A prime. These types of moves can happen when a page move with disambiguation pages switches what is the primary topic and or disambiguation page. Yes this can be used in a beans way which is why it should have a good criteria to get the userright, but the problem isn't deletion. PaleAqua (talk) 16:32, 4 May 2016 (UTC)
    • Stopping titles from redirecting is something very different. We should title it prevent-redirect Discuss-Dubious (t/c) 14:45, 5 May 2016 (UTC)
      • These are the names of flags which are technical bits named by the wizards at WMF. We're not creating a new flag or anything (or modifying the name, whatever), just assigning it to a new user access level. --QEDK (T ☕ C) 15:29, 5 May 2016 (UTC)

1. Support This permission is really the key to what is missing with unflagged page moves. — xaosflux ^Talk 01:06, 19 April 2016 (UTC)
2. Support Seems to me to be the whole point of this. Happy Squirrel (talk) 01:38, 19 April 2016 (UTC)
3. Support - part of the core idea behind this proposed group. Also not nearly as scary as some make it out to be; moved pages are still linked to from the original title in a deletion message. Ajraddatz (talk) 01:49, 19 April 2016 (UTC)
4. Support – this is the heart of this usergroup proposal: without this, there's no point in even proposing it. --IJBall (contribs • talk) 01:57, 19 April 2016 (UTC)
5. Support as above. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
6. Support as this is basically what the user right is all about. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)
7. Support This is an essential requirement for this user right. PaleAqua (talk) 03:19, 19 April 2016 (UTC)
8. Support This is the whole point, why are we bothering with this, again? --QEDK (T ☕ C) 09:33, 19 April 2016 (UTC)
9. Support It's already the core of m:Global rollback, a local permission is only logical. Bazj (talk) 11:10, 19 April 2016 (UTC)

   More the periphery of global rollback. I'd say the 'rollback' permission is the core of that group :-) Ajraddatz (talk) 20:14, 19 April 2016 (UTC)

10. Support. The idea of having page movers seems relatively useless if this permission isn't part of the package. Calidum ¤ 22:57, 19 April 2016 (UTC)
11. Support, as it's essential to the proposal. APerson (talk!) 01:44, 20 April 2016 (UTC)
12. Support because this allows non-admins to carry out requested moves that involve disambiguation pages, and also carry out WP:CFD category renames without leaving category redirects. SSTflyer 04:08, 20 April 2016 (UTC)
13. Support We are talking about a group of editors who have satisfied a certain criteria and have demonstrated they could be trusted with the safety of the project. If they violate this trust, it is easy to have the permission removed, easier then an admin. McMatter ^(talk)/_(contrib) 13:27, 20 April 2016 (UTC)
14. Support because it is useful when moving old redirects out of the way. Sometimes redirects have more than 1 edit, so it's not possible to move an article from a certain title to another title that redirects to it. epicgenius: unlimited epicness (talk) 15:31, 20 April 2016 (UTC)
15. Support as useful, assuming thresholds for receiving this user right are sufficiently high to put it in the right hands. ~ Rob^Talk 15:36, 20 April 2016 (UTC)
16. Support Per comments below. Peter Sam Fan 18:29, 20 April 2016 (UTC)
17. Support: The most useful right of this package for editors who close RMs. This is not in practice deletion, as a) the target of the page move is included in the log and b) the revisions are still on the target page. Esquivalience ^t 22:51, 20 April 2016 (UTC)
18. Strong support, if only to cancel out the ridiculous opposing rationales below. I do applaud the heavy mental gymnastics required to justify turning not creating a redirect when moving a page into a page deletion, I really do... Satellizer el Bridget ^(Talk) 00:57, 21 April 2016 (UTC)
19. Support. A useful housekeeping tool not likely to be abused and needed to fill out the page mover permission as well. Can be limited and monitored. Donner60 (talk) 05:58, 21 April 2016 (UTC)
20. Tentative support. If I look at a regular redirect from a moved article, the only entry in its history is the creation of the redirect. That makes it harder for editors to track WTF happened to the article if it isn't made. However, searching Special:Logs for the page as target still comes up with an entry for the move itself. Provided that still works when a redirect is suppressed, I can't reasonably vote against the proposal. However, I think it might be desirable to have logs come up more conveniently when you look at at history of a nonexistent page, for example with a direct link to see logs for that target. I could not support the proposal if suppressredirect allowed any means by which an ordinary page mover could dispose of a page so that an ordinary user or IP can't figure out where it went at all! Wnt (talk) 16:12, 21 April 2016 (UTC)
    • @Wnt: I proposed some guidelines related to the concern in your last sentence below at #When suppressredirect should be used.—Godsy^(TALK_CONT) 17:52, 21 April 2016 (UTC)

    @Godsy: Those guidelines don't tell me if there is a way to make it completely impossible to tell where a page went or not. I don't think you can, but if you can, then guidelines aren't enough to reassure me. Wnt (talk) 20:03, 21 April 2016 (UTC)

21. Support useful for RM (and possibly with new page patrol) - experience with RM (or RFD) should be necessary. Peter James (talk) 08:35, 23 April 2016 (UTC)
22. Support - --John Cline (talk) 18:42, 23 April 2016 (UTC)
23. Support Very useful, instead of tagging the articles for speedy deletion I could just move without leaving a redirect. — Music1201 ^talk 19:32, 23 April 2016 (UTC)
24. Support - This seems a pretty fundamental aspect of this proposal, and I do not share the concerns of those opposing. — Rhododendrites ^talk \\ 21:21, 23 April 2016 (UTC)
25. Support Same reason as above. Alanscottwalker (talk) 00:58, 24 April 2016 (UTC)
26. Support – This is a very important part of this right; it would be just about useless without it, and all the opposes have been responded to. KSFT^C 19:34, 24 April 2016 (UTC)
27. Support Per above. I don't see this as "deletion" and am not terribly worried about it. Seems rather integral to the whole proposal honestly. Wugapodes (talk) 20:21, 24 April 2016 (UTC)
28. Support: Central to the proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
29. Support. Rubbish computer (HALP!: I dropped the bass?) 08:11, 25 April 2016 (UTC)
30. Support per discussion above. FiendYT ★ 04:00, 27 April 2016 (UTC)
31. Support per the discussion on restrictions below. I firmly believe this can be deployed responsibly by the users who will be granted the userright. Ivanvector 🍁 (talk) 16:36, 27 April 2016 (UTC)
32. Support - This is a key part of this userright. Without it, the rest is moot. — Jkudlick • t • c • s 10:02, 28 April 2016 (UTC)
33. Support. This does seem to be the main point of the new user right (and I'm not convinced by the opposes - as long as no *page* is being deleted, I just don't see a problem). Boing! said Zebedee (talk) 23:57, 2 May 2016 (UTC)
34. Support per above. Major consensus is that this right is meant for suppressing redirects. — Andy W. (talk · ctb) 02:04, 3 May 2016 (UTC)
35. Support integral to the idea. Peacemaker67 (click to talk to me) 04:27, 3 May 2016 (UTC)
36. Support. It would be rather nice to have this ability. Not every redirect is useful. I don't see a problem with giving this out to trusted users. NinjaRobotPirate (talk) 06:59, 3 May 2016 (UTC)
37. Support. Important reason for the permission and doesn't allow for deletion of actual content. —Ruud 10:12, 3 May 2016 (UTC)
38. Support As stated above, not every redirect is useful, as we have seen with a major issue last year. RickinBaltimore (talk) 12:21, 3 May 2016 (UTC)
39. Weak support. I do not feel strongly about this, but I think that any harm can probably be overcome simply by recreating a redirect. --Tryptofish (talk) 22:08, 3 May 2016 (UTC)
40. Support. Necessary for most purposes. — JFG ^talk 22:27, 3 May 2016 (UTC)
41. Support Per above -FASTILY 23:42, 3 May 2016 (UTC)
42. Support. Critical to the proposal, sorely needed. The Drover's Wife (talk) 03:54, 4 May 2016 (UTC)
43. This I consider the main aspect of page mover rights, strong support. Regards—UY Scuti ^Talk 05:59, 4 May 2016 (UTC)
44. Support One of the big parts of having the userright is being able to do this. Callanecc (talk • contribs • logs) 12:19, 4 May 2016 (UTC)
45. Support. Agreed that this is a key element of the page mover right, and will help new page movers leave fewer messes in their wake. Lwarrenwiki (talk) 17:55, 4 May 2016 (UTC)
46. Support - Per above. The Master ---)Vote Saxon(--- 02:36, 5 May 2016 (UTC)
47. Support Per above. If you can be trusted with a page mover right, then you should be trusted to do this. —k6ka 🍁 (Talk · Contributions) 11:46, 5 May 2016 (UTC)
48. Support Only prevents things from redirecting; no edit history removed. Discuss-Dubious (t/c) 14:44, 5 May 2016 (UTC)
49. Support I tried to move a page yesterday for the first time in my existence here yesterday, because it was titled incorrectly, and I was denied permission. I didn't like that very much. :-) Pocketthis (talk) 16:33, 5 May 2016 (UTC)
50. Support dvolution of "power" to lower flags is standard in advanced communities. We discussed on itwiki years ago, it was considered "bureaucracy". Than we crated the file mover. Then we gave filemovers the suppress redirect. And it worked just fine. Plus, many users before becoming sysop can now get both the filemover and the rollbacker flag, and get experience, and learn progressively. it works.--Alexmar983 (talk) 16:44, 5 May 2016 (UTC)
51. Support Per IJBall --TJH2018talk 21:44, 5 May 2016 (UTC)
52. Support: I used to assume that it was impossible for non-admins to move a page without leaving a redirect because we didn't have deletion rights. When a few months ago, I discovered suppressredirect was a separate right, I was confused as to why it wasn't available to everyone. The opposers have made me question slightly whether everyone with the page move right should also get suppressredirect, but they have not convinced me trusted users specifically selected to be given the page mover right would do more harm than good. — Bilorv_(talk)^(c)(e) 22:15, 5 May 2016 (UTC)
53. Support: per Bilorv above. GenQuest ^{"Talk to Me"} 11:54, 6 May 2016 (UTC)
54. Support Not including this feature will be problematic and ultimately devalue the creation of a new user right. Mkdw^talk 14:18, 6 May 2016 (UTC)
55. Support per Bilorv. - HyperGaruda (talk) 05:39, 7 May 2016 (UTC)
56. Support The strength of my support is conditional on whether bots delete pages, especially redirects. I do many things in my userspace (almost always realted to Wikiversity). I hesitate to correct misnamed pages in my userspace because I presume it is not handled by bots. If the deletion of a page redirect is usually people, not bots, then I strongly support.--Guy vandegrift (talk) 16:02, 7 May 2016 (UTC)
57. Support - Issues addressed by opposers are inevitable. If that person abuses the power of deleting a redirect page, the editor may not deserve it and may lose the rights. Same for those with conflicts of interests on harder discussions. In the meantime, let's not wait for administrators to decide on easy results (i.e. snow results). George Ho (talk) 05:14, 8 May 2016 (UTC)
58. Support, as this is after all one of the key points of this proposal. Double sharp (talk) 10:35, 8 May 2016 (UTC)
59. Support, seems reasonable. Nakon 03:10, 9 May 2016 (UTC)
60. Support, is part of the total package; don't even know if it could be unbundled. Montanabw^(talk) 03:34, 9 May 2016 (UTC)
61. Support. Useful part of the package. • • • Peter (Southwood) ^(talk): 11:29, 9 May 2016 (UTC)
62. Support—indopug (talk) 17:56, 9 May 2016 (UTC)
63. Support. Will be useful for NPPs moving pages back to draft/userspace. No reason for those people to need to have an admin then come along and delete the redirect. –Compassionate727 ^(T·C) 18:31, 10 May 2016 (UTC)
64. Support - Would be useless without it. -- The Voidwalker ^Discuss 00:44, 11 May 2016 (UTC)
65. Strong support - I was honestly shocked when I learned that this permission is only available to admins and global rollbackers. This permission does not carry much influence with it at all. Redirects are just pointers to the contents of an article, hence they do not contain any content in and of themselves. Therefore, the argument that redirect suppressions are akin to deletions doesn't make a lot of sense. This would definitely lift a substantial burden off administrators by distributing this cleanup tool to more users. Eventhorizon51 ^(talk) 02:51, 11 May 2016 (UTC)
66. Support. I supported the basic idea, so why should I oppose one of its critical points? ;) Biblio (talk) 16:23, 12 May 2016 (UTC)
67. Support. This is one of the main reasons for this usergroup. Anarchyte (work | talk) 09:16, 14 May 2016 (UTC)
68. Support per all above. --Bigpoliticsfan (talk) 17:27, 15 May 2016 (UTC)
69. Support Unnecessary redirects can cause major problems when moving. ^{My name is}not^dave (talk/contribs) 15:42, 16 May 2016 (UTC)
70. Support Another no-brainer. This should be a permission to grant to trusted editors. giso6150 (talk) 03:05, 17 May 2016 (UTC)
71. Support. Yes this is probably the most important part of this permission. Deryck C. 13:59, 17 May 2016 (UTC)
72. Support - Mlpearc (open channel) 15:44, 17 May 2016 (UTC)
73. Support - Gmcbjames (talk) 03:50, 18 May 2016 (UTC)
74. Support per arguments above, having read all 'oppose' arguments. Donama (talk) 05:23, 18 May 2016 (UTC)
75. Support: Unbundling is good. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)

1. Oppose Non-admins should not be able to create entries in the deletion log. There's already enough problem with people attempting to have old titles deleted (old page gets moved, and they try to get the original title deleted as implausible, or whatever) in violation of policy; there's no good reason to encourage this farther. At least right now, this kind of abuse can be caught sometimes, because it requires an admin to look at the situation; if we approve this proposal, catching this kind of abuse will become far more difficult. Nyttend (talk) 12:16, 19 April 2016 (UTC)

   Suppressredirect doesn't create entries in the deletion log. As nothing is deleted it can even be monitored by an unregistered user, and in most cases missing redirects can be created by a new user with no edits. Compare with the ability to move over a redirect, which autoconfirmed users already have, which makes the original redirect invisible to administrators, and possibly even to users with oversight and checkuser rights. Peter James (talk) 19:04, 20 April 2016 (UTC)

   @Peter James: You're wrong. The page title is deleted and it is logged. Correct Nyttend (who already has the right as an admin)? "Compare with the ability to move over a redirect, which autoconfirmed users already have, which makes the original redirect invisible to administrators, and possibly even to users with oversight and checkuser rights.", that isn't a problem as both titles still exist.—Godsy^(TALK_CONT) 22:25, 20 April 2016 (UTC)

   The most recent use of suppressredirect by Nyttend was on 30 March (it shows another way of dealing with the old redirect - move to a talk subpage - an alternative would have been to keep it in main namespace but disambiguate based on other characters in the series). Check the deletion log for Nyttend for that date - empty, as it is not recorded there. Peter James (talk) 23:12, 20 April 2016 (UTC)

   I've stricken part of my comment above. It isn't logged as a deletion, though it would still show as red in the move logs if something hadn't been moved there.—Godsy^(TALK_CONT) 23:53, 20 April 2016 (UTC)

2. Oppose. A page deletion is a page deletion, no matter how it's classified. Deletions of anything should only be the responsibility and permission for administrators. (But if the community believes otherwise, I have an idea for another permission coming soon.) Steel1943 (talk) 19:57, 19 April 2016 (UTC)

   It isn't deletion though. It's just not creating a redirect. Deletion involves the removal of revisions, which doesn't happen here (or at least doesn't result in the removal of revisions with content in them). For example, if I were to consider creating a page with the title "This is just a test page", but didn't, would that be deletion? Ajraddatz (talk) 20:13, 19 April 2016 (UTC)

   It sort of is a deletion since that title formerly had content. Sure, the editor would not click a "delete" button, but it's still a deletion of content from a title. Steel1943 (talk) 20:19, 19 April 2016 (UTC)

   Fair. As I have said above though, there is still a link to the new page from the original title - it just isn't automatically redirected. Ajraddatz (talk) 20:24, 19 April 2016 (UTC)

   Yeah, I get that since the receipt of the move is recorded in the log, but still. Steel1943 (talk) 20:26, 19 April 2016 (UTC)

   Not really – it would involving moving the content to a different title – see the "round-robin moves" discussion above. It would only get "deleted" if it was subsequently tagged for housekeeping deletion (which would require Admin approval). As the current proposal lacks a new moveoverredirect userright, it involves no deletion power whatsoever... --IJBall (contribs • talk) 23:11, 19 April 2016 (UTC)

   Again, I am fully aware that this is not a loss of edit history. It's a deletion of a title. As others after me have said, that's what WP:RFD and WP:CSD are for. suppressredirect essentially gives non-admins permission to "execute" specific WP:G6 CSDs, which I oppose. Steel1943 (talk) 23:20, 19 April 2016 (UTC)

   G6 is limited to administrators only for a technical reason. This proposal is an attempt to overcome that technical reason so you oppose for a reason that would no longer exist? Peter James (talk) 19:04, 20 April 2016 (UTC)

   But the loss of edit history is literally what deletion is defined as. By your type of logic, if I were to move my bedside lamp from one side of the bed to the other, I'll basically be erasing said lamp from existence(!). RFD is only for controversial redirects only, so unless you'd be willing to argue that one requires permission to move back page-move vandalism or move a completed article from sandbox to mainspace, this argument doesn't really make sense. RFD and CSD are also irrelevant when there's no page to be deleted and one only wants to move a page without creating a redirect. Besides, like the comment above me says, G6 exists only as a technicality. Satellizer el Bridget ^(Talk) 01:25, 21 April 2016 (UTC)

3. Strong Oppose - Unless a page title meets a criteria for speedy deletion, it is inappropriate to speedily delete it, and therefore most of the time it is inappropriate to move the content to another title without leaving a redirect. Titles resulting from a page move vandal can be easily put up for speedy deletion per WP:CSD#G3. Titles blocking moves of content from another title can be put up for speedy deletion per WP:CSD#G6. Redirects from temporary locations are sometimes kept because they can be useful, though the author can generally put them up for WP:CSD#G7 (the redirect should remain in place if it isn't moved by the author). I don't see a need for this user right, as the processes we already have in place work. The potential for abuse per Nyttend, which would be hard to track, outweighs the benefit. [General concerns with suppressing redirects under WP:PM/C#3: As it has been established that suppressed titles don't show up in the deletion log, the new title won't be linked from the deleted title when this is used, where it is with traditional deletion. This will make it hard to find previously accessed desired content in some cases, especially for inexperienced editors and readers. 05:28, 30 April 2016 (UTC)] [Non-admins can already close requested moves when they lack the technichal ability to fulfil the request per WP:RMNAC. That being said: I fail to see how this proposal will help lighten the backlogs at WP:RM as has been suggested above. 10:47, 1 May 2016 (UTC)]—Godsy^(TALK_CONT) 20:56, 19 April 2016 (UTC)

   It wouldn't be hard to track, although a database report would make it easier. The Users by log action report seems to exclude moves, although they are recorded in the logging table. Peter James (talk) 19:15, 20 April 2016 (UTC)

   Just putting it here that CSD is routinely backlogged, there's a 93-page current backlog as we speak. I requested a G6 deletion just 2-3 days ago that was unnoticed for 24+ hours. Minimising this backlog is most certainly a benefit; the current system "works" the same way a clogged toilet works. Satellizer el Bridget ^(Talk) 01:25, 21 April 2016 (UTC)

   Make that 212 pages. System is working great. Satellizer el Bridget ^(Talk) 08:22, 21 April 2016 (UTC)

   Just a note about your recent addition: because suppressing the redirect isn't deletion in any technical sense of the word, of course there is no entry in the deletion log. However, there is an entry in the move log which specifies that the redirect creation was suppressed, and there is a red box that appears on the old title with a link to the new one. That red box is removed if someone creates a new page at that title, but it would be the same for a redirect. Ajraddatz (talk) 17:04, 30 April 2016 (UTC)

   Strong oppose (struck per conversation below, in spite of a certain editor's badgering Ivanvector 🍁 (talk) 16:35, 27 April 2016 (UTC)) - having been trawling redirects for discussion for a couple years now, it's painfully obvious that most users have only a very flimsy understanding of the purpose of {{R from move}}ses and why in most cases they should be created. Allowing non-admins (any non-admins) to suppress creation of these redirects is bound to be very, very messy. Besides, redirects are pretty harmless. Ivanvector 🍁 (talk) 21:30, 19 April 2016 (UTC)

   Yet WP:RFD is conveniently backlogged, and (no offence) but your comment is borderline fearmongering. Giving more editors the tools to help out only reduces the mess already present, not make it larger. Perhaps most users don't understand [R from move], but most editors won't be getting the userright. It's only for those who've demonstrated a clear need and understanding of it. Satellizer el Bridget ^(Talk) 08:28, 21 April 2016 (UTC)

4. Oppose This is what RfD is for. Andrew D. (talk) 22:24, 19 April 2016 (UTC)

   No, this is a page mover right, RfD is not for page moves. Sometimes people who don't know about RM put requests at RfD, but RM is the correct venue. Peter James (talk) 19:04, 20 April 2016 (UTC)

   @Peter James: This right gives the ability to delete titles that would become redirects, which is what I believe Andrew Davidson was trying to state.—Godsy^(TALK_CONT) 22:02, 20 April 2016 (UTC)

   It doesn't delete anything, it optionally prevents a redirect page from being created when moving a page to a new title. — xaosflux ^Talk 22:07, 20 April 2016 (UTC)

   @Xaosflux: If page title x is moved to page title y without leaving a redirect, page title x no longer exists, that is deletion.—Godsy^(TALK_CONT) 22:25, 20 April 2016 (UTC)

   I suppose its semantics - in stark contrast to our actual deletions, no edits or attributions are removed during a move. — xaosflux ^Talk 23:23, 20 April 2016 (UTC)

   Deletion has to be restricted to administrators because it's necessary to access deleted revisions to undo it, for which community consensus level of trust is needed. After a move with suppressredirect any non-blacklisted title can be created by a newly registered user. Peter James (talk) 23:29, 20 April 2016 (UTC)

   Nope, that's not what deletion is. When one moves something, he changes the location of an object from point A to point B. If he deletes something, he erases the existence of something from point A. If I drive my car from A to B, do I delete my car? Moves don't even show up in the deletion log so it's a non-argument. Satellizer el Bridget ^(Talk) 01:25, 21 April 2016 (UTC)

   @Satellizer: A itself is erased if a redirect isn't left. The car (i.e. the content) remains, but the former page title (i.e. A) is deleted.—Godsy^(TALK_CONT) 03:03, 21 April 2016 (UTC)

   What you don't seem to get is that suppressredirect only needs to be used in those cases where a series of "round-robin moves" needs to be carried out in order to complete a WP:RM to a location which has a preexisting redirect with a non-trivial page history. The only other time I can even conceive of it being used is to move from an article location that is an obvious WP:AT violation (e.g. moving "Ye Old Bunghole" back to "John Smith VII" after a vandal page move). In all other cases, a simple page move (incl. leaving a redirect) will be carried out. You are literally worrying over a situation that will basically never happen. --IJBall (contribs • talk) 03:13, 21 April 2016 (UTC)

   Heck, promoting the limited use of suppressredirect (e.g. "You should only use suppressredirect in these situations... Failure to follow these guidelines can lead to the loss of the privilege...") can even be written into the WP:Page mover guidelines if somebody wants to come up with something concrete. --IJBall (contribs • talk) 03:16, 21 April 2016 (UTC)

   @Godsy: Again, that's not what "delete" means in the English language. A isn't deleted, it's just moved to B. But what's more concerning however is the community's resistance to any form of userright change or unbundling of tools, as if it were a zero-sum game where giving tools to more people means more work for the admins; it doesn't work that way - in fact, there's less work for the admins now because there's less mess to clean up. It's like an analogy where after you spill a drink you clean it up yourself instead of demanding that a janitor do it for you. At the end of the day admins are basically internet janitors who've been given a set of tools to maintain an internet encyclopedia - nothing more, and this us-vs-them mentality of admins vs other users and refusal to make even small improvements, like allowing non-admins to move back page-move vandalism or move sandbox articles to mainspace without leaving behind a redirect, fosters mistrust and drives people off the project. WP:NOBIGDEAL may as well be a big joke at this point. Oh, and CAT:CSD has bloated out to 212 pages, and WP:RFD and WP:RM are both clogged. The answer is more tools for more people, not more restrictions. Satellizer el Bridget ^(Talk) 08:22, 21 April 2016 (UTC)

   That's precisely what "delete" means in English. What you mean is that it has a different meaning in our site jargon. If a reader comes to look for an article that was previously located at x but it has been moved to y, there is no other way for the reader to find the information they're looking for if we do not create the page-move redirect. From the reader's perspective, the technicality of whether the page has been moved or deleted is irrelevant: they see a redlink. We break external links and dead-end readers, all for no benefit. Enough users get this wrong that we should leave it to admins to figure out. Iff there are very clear rules about this within the userright instructions, then I will be less opposed. And RFD is not backlogged, it just moves slowly. Ivanvector 🍁 (talk) 18:07, 21 April 2016 (UTC)

   "Delete" literally means to remove or obliterate, not move it somewhere else. But the crux of my argument is that I very seriously doubt granting suppressredirect to non-admins would result in en masse abuse, there's no conspiracy out to destroy Wikipedia and your average Joe won't be getting the userright anyways, only those with experience and expertise in page titles who have demonstrated it over a long period of time. Perhaps even more than some admins, I might add, and there's no need to trust these guys any less or withhold from them userrights that would clearly be a net positive for Wikipedia and reduce the workload for admins, see my posts above. RFD is for potentially controversial redirects only and it was backlogged when I posted my message, and is also backlogged right now. WP:RM and CAT:SPEEDY still retain their old backlogs. Satellizer el Bridget ^(Talk) 09:10, 23 April 2016 (UTC)

5. Oppose, solution in search of a problem. Stifle (talk) 13:23, 29 April 2016 (UTC)

   You've got to be kidding me. Have you ever tried to move a page over a redirect with a non-trivial revision history? If you haven't, then you have no idea how non-trivial this part of the proposal is. --IJBall (contribs • talk) 18:19, 29 April 2016 (UTC)

   Not for anything, but I do that all the time. You get the page deleted by asking an admin, who also usually makes the page move for you. Discussions like this seem to me to be for those who are skittish about asking admins for help for one reason or 'nother.  Stick to sources! Paine  19:50, 29 April 2016 (UTC)

   It's simple enough to apply a WP:CSD#G6 tag or make a request at WP:RM/TR. As the WP:RM backlog is the concern, we ought to just make an exception and allow users to close Wikipedia:Requested moves when they lack the technical ability to fulfill the request, then use the aforementioned processes.—Godsy^(TALK_CONT) 21:50, 29 April 2016 (UTC)

   [boggle!] Do you people get that we're creating this because we're trying to save Admins from needing to do stuff like this? Seriously, is anyone looking around and seeing the growing backlogs around and the lack of new Admin candidates?! --IJBall (contribs • talk) 22:13, 29 April 2016 (UTC)

   No, I don't get that. What I do get is that an admin has always helped me with such things well within a 24-hour period, and I really don't see any reason why any admin would give me priority, so thus far the existing moppers have done a hekuva job. With all due respect, if that's your reason, it just bogged down into the muck of reality.  Stick to sources! Paine  08:54, 30 April 2016 (UTC)

6. Strong oppose Suppress redirect is deletion, plain and simple. In fact, our current way admins do it is not sufficient - they should be require to list both a move and a delete reason. Oiyarbepsy (talk) 00:10, 4 May 2016 (UTC)
7. Strong oppose As per the above opposers, I believe that it is a deletion, and deletions should only be done by admins. Joseph2302 (talk) 16:11, 4 May 2016 (UTC)
8. Oppose for all the reasons stated above; we should not devolve deletion power to non-admins. --Gimubrc (talk) 14:07, 5 May 2016 (UTC)
9. Oppose per Nyttend BMK (talk) 18:32, 7 May 2016 (UTC)

   So, you oppose on the grounds of somebody else's erroneous rationale?... Interesting. --IJBall (contribs • talk) 21:18, 7 May 2016 (UTC)

   Nyttend's first sentence is a misstatement, the rest holds true.—Godsy^(TALK_CONT) 03:55, 8 May 2016 (UTC)

   Ah, so we're back to not trusting our veteran editors (or the Admins at WP:PERM for that matter). Got it. And, if so, then why aren't the people here opposing the entire proposal outright? – If our veteran editors can't be trusted to do a series of "round-robin" moves, they clearly can't be trusted to do anything. --IJBall (contribs • talk) 05:29, 8 May 2016 (UTC)

   • @IJBall:I've seen plenty of bad suppress redirects over the years. I've seen admins move a page without redirect when the old title had been used for 5 years, for example. Round Robin moves is a rather unusual case - ordinary page renames is very common. The common stuff is what matters, and moving without leaving a redirect is the wrong thing to do 99% of the time. If it is really important for the old redirect to be gone, speedy deletion covers it, and if it doesn't, it needs to go to RFD. Oiyarbepsy (talk) 04:23, 10 May 2016 (UTC)

   • When you saw this did you mention it to the Admin? Did you get a satisfactory response? Did you recreate the redirect that wasn't left behind? However, I'm not sure this is germane, as all of this is covered by WP:PM/C – if a page mover doesn't basically stick to that list, they could lose the right. Bottom line: I still think it is disingenuous to "support creation of the permission" while simultaneously "oppose including suppressredirect" (and I realize this doesn't include you) – if you don't trust veteran editors with suppressredirect then you basically don't trust veteran editors at all, and you should oppose the proposal outright. (And there's no "proposal" worth having here without suppressredirect anyways...) --IJBall (contribs • talk) 04:43, 10 May 2016 (UTC)

   • @IJBall: I agree that "if a page mover doesn't basically stick to [WP:PM/C], they could lose the right", but QEDK seems to disagree below, and has softened the wording (i.e. "I disagree that there's a fixed criteria for using a flag. We must realize that everything happens at our own discretion, restricting a flag to the few obvious cases is not useful, well because it's obvious. As a result, I've removed the word, "only" from the criteria."). On a side note, I'd also like to point out that you supported this section of the proposal before WP:PM/C was proposed.—Godsy^(TALK_CONT) 05:26, 10 May 2016 (UTC)

   • Of course, I did – I trust veteran editors, and don't worship at the alter of RfA/Admin shamanism. I also agree with QEDK that guidelines are exactly that – guidelines – and as such won't cover all eventualities. I also trust the Admins at WP:PERM to use their judgment and common-sense when handing out this userright. All that said, if the Page mover guidelines can be written in such a way to put some opposers' minds at ease, then all the better. --IJBall (contribs • talk) 05:32, 10 May 2016 (UTC)

   • Perhaps I'm interpreting QEDK's statement too stringently, and I apologize if that's the case QEDK.—Godsy^(TALK_CONT) 05:51, 10 May 2016 (UTC)

10. No. I believe supressing redirects is deletion. Redirects are useful most of the time. --Pokéfan95 (talk) 06:16, 17 May 2016 (UTC)
11. Oppose. I've seen enough redirects get incorrectly deleted under G7 after being incorrectly tagged for deletion by the page mover who was not the author of the original page to know this is not a good idea. Suppression of redirects by non-admins will only encourage this behavior when even admins can barely handle this correctly. — ξ^xplicit 06:52, 18 May 2016 (UTC)
12. Oppose No need demonstrated. Ruslik_Zero 12:49, 18 May 2016 (UTC)

1. Support this seems appropriate, and will have no impact on articles; will be useful for moving non-protected templates and their subpages. — xaosflux ^Talk 01:07, 19 April 2016 (UTC)
2. Support: Can cause damage and waste time if WP:BEANS but obviously useful. If this right was to be added to the package, there better be reasonably high standards. Esquivalience ^t 01:10, 19 April 2016 (UTC)
3. Support - makes sense. It is also a relatively harmless permission, just as easy to revert as normal moves if done properly. Ajraddatz (talk) 01:45, 19 April 2016 (UTC)
4. Support, as an excellent idea, provided that there are high standards for the granting of the right. APerson (talk!) 02:03, 19 April 2016 (UTC)
5. Support – of course: this proposal wouldn't be useful without this, as it will be needed for even some relatively simple moves (e.g. involving Talk pages with Talk page archives, etc.). Without this, some page moves will become needlessly complicated for those within this usergroup. --IJBall (contribs • talk) 02:08, 19 April 2016 (UTC)
6. Support per above - a very useful permission. --Tom (LT) (talk) 02:09, 19 April 2016 (UTC)
7. Support: This would be so helpful. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
8. Support would be very useful for trusted users who could use the right. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)
9. Support While it doesn't seem absolutely necessary but would obviously be beneficial for those with the right to have this. I do agree this does require slightly higher criteria than without. PaleAqua (talk) 03:23, 19 April 2016 (UTC) Edit: Actually I think this is necessary because of talk page archivs. I've seen page moves where archive pages get separated and can get messy at a series of moves. PaleAqua (talk) 03:33, 19 April 2016 (UTC)
10. Support - not seeing an upside to leaving the sub-pages behind. Bazj (talk) 11:37, 19 April 2016 (UTC)
11. Support. Makes perfect sense. Steel1943 (talk) 20:21, 19 April 2016 (UTC)
12. Support per above.—Godsy^(TALK_CONT) 21:02, 19 April 2016 (UTC)
13. Support useful when talk page archives are involved. SSTflyer 09:37, 20 April 2016 (UTC)
14. Support. You don't need to use it in most page moves (which have no subpages), but when subpages are involved, it's always a good thing to have. epicgenius: unlimited epicness (talk) 16:02, 20 April 2016 (UTC)
15. Support. Useful adjunct to page mover permission. Leaving subpages behind to be handled separately, or puzzled over, does not seem sensible. Donner60 (talk) 05:58, 21 April 2016 (UTC)
16. Support Definitely. --QEDK (T ☕ C) 16:09, 21 April 2016 (UTC)
17. Support - of course, the userright doesn't make sense otherwise. Ivanvector 🍁 (talk) 18:08, 21 April 2016 (UTC)
18. Support Only makes sense. — Music1201 ^talk 19:36, 23 April 2016 (UTC)
19. Support - Can't think of any reason to oppose -- in fact since we already have limiters in place, I don't know why this isn't just given to autoconfirmed. — Rhododendrites ^talk \\ 21:22, 23 April 2016 (UTC)
20. Support Peter James (talk) 23:07, 23 April 2016 (UTC)
21. Support Wugapodes (talk) 20:21, 24 April 2016 (UTC)
22. Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
23. Support: Definitely. This is also central to the proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
24. Support as appears a central part of the subgroup. Rubbish computer (HALP!: I dropped the bass?) 08:14, 25 April 2016 (UTC)
25. Support - This is a useful ability with a limited potential for abuse in my opinion.--John Cline (talk) 05:11, 26 April 2016 (UTC)
26. Strong Support No apparent abilities to vandalize with this right. Generally helpful and useful. FiendYT ★ 04:04, 27 April 2016 (UTC)
27. Strong Support - This should be obvious. — Jkudlick • t • c • s 10:03, 28 April 2016 (UTC)
28. Support. Seems like a fairly obvious part of it. Boing! said Zebedee (talk) 00:00, 3 May 2016 (UTC)
29. Support. If we're going for this userright, not moving subpages seems awkward. These folks that will have the right surely understand policies — Andy W. (talk · ctb) 02:04, 3 May 2016 (UTC)
30. Support - If you have pagemover permission, you should be able to move subpages as well. Being unable to would create either a mess for lazy page movers or a headache for fastidious ones. EvergreenFir (talk) Please {{re}} 03:44, 3 May 2016 (UTC)
31. Support a necessary component if this is to improve things and reduce the RM backlog. Peacemaker67 (click to talk to me) 04:29, 3 May 2016 (UTC)
32. Support Shouldn't it actually be the failure to move subpages that should require additional permission? —Ruud 10:15, 3 May 2016 (UTC)
33. Support This would go hand-in-hand with the other rights. RickinBaltimore (talk) 12:22, 3 May 2016 (UTC)
34. Support. I can't see any downside to including this. --Tryptofish (talk) 22:03, 3 May 2016 (UTC)
35. Support. Obviously. — JFG ^talk 22:27, 3 May 2016 (UTC)
36. Support -FASTILY 23:42, 3 May 2016 (UTC)
37. Support This one makes a lot of sense, but as I'm opposed to new permissions, this could just be part of that whole extended confirmed thing we got now. Oiyarbepsy (talk) 03:35, 4 May 2016 (UTC)
38. Naturally!—UY Scuti ^Talk 06:01, 4 May 2016 (UTC)
39. Support Absolutely, probably the biggest area of need for this right is to move subpages. Callanecc (talk • contribs • logs) 12:22, 4 May 2016 (UTC)
40. Support Makes complete sense to move subpages of a page that is being moved. Joseph2302 (talk) 16:12, 4 May 2016 (UTC)
41. Support. When subpages exist, streamlining the page moving process makes perfect sense, and the downside is very limited. Lwarrenwiki (talk) 17:57, 4 May 2016 (UTC)
42. Support - Per above. The Master ---)Vote Saxon(--- 02:37, 5 May 2016 (UTC)
43. Support Only makes sense. Even if this wasn't the case, that wouldn't stop daring users from manually moving the subpages themselves. —k6ka 🍁 (Talk · Contributions) 11:46, 5 May 2016 (UTC)
44. I see no problem in trying that too.--Alexmar983 (talk) 16:48, 5 May 2016 (UTC)
45. Support No reason to oppose. Peter Sam Fan 19:58, 5 May 2016 (UTC)
46. Support Absolutely. I don't see why not, as this will reduce admin workload (for other, more important things) TJH2018talk 21:41, 5 May 2016 (UTC)
47. Support: Of course. GenQuest ^{"Talk to Me"} 11:55, 6 May 2016 (UTC)
48. Support No reason to bar this if they could do it simply in smaller steps. Mkdw^talk 14:19, 6 May 2016 (UTC)
49. Support - HyperGaruda (talk) 05:40, 7 May 2016 (UTC)
50. Support BMK (talk) 18:28, 7 May 2016 (UTC)
51. Support as eminently useful (e.g. talk page archives). Double sharp (talk) 10:36, 8 May 2016 (UTC)
52. Support part of the total package, really. Montanabw^(talk) 03:51, 9 May 2016 (UTC)
53. Support. Useful part of the package. • • • Peter (Southwood) ^(talk): 11:32, 9 May 2016 (UTC)
54. Support—indopug (talk) 17:56, 9 May 2016 (UTC)
55. Support. –Compassionate727 ^(T·C) 18:33, 10 May 2016 (UTC)
56. Support -- The Voidwalker ^Discuss 00:45, 11 May 2016 (UTC)
57. Support. If someone can be trusted with suppressredirect, certainly they can be trusted with the ability to move subpages. This is probably one of the least "dangerous" of all the rights being proposed. Biblio (talk) 16:26, 12 May 2016 (UTC)
58. Support. Anarchyte (work | talk) 09:17, 14 May 2016 (UTC)
59. Support otherwise things would become a mess when moving pages. ^{My name is}not^dave (talk/contribs) 15:44, 16 May 2016 (UTC)
60. Support Of course. giso6150 (talk) 03:06, 17 May 2016 (UTC)
61. Support. Yes please. It seems obvious to me that this should be bundled into a permission that is specifically about moving pages. Deryck C. 13:52, 17 May 2016 (UTC)
62. Support - Mlpearc (open channel) 15:45, 17 May 2016 (UTC)
63. Support - Gmcbjames (talk) 03:51, 18 May 2016 (UTC)
64. Support as is more useful than dangerous. Donama (talk) 05:24, 18 May 2016 (UTC)
65. Support: Unbundling is good. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)

1. Oppose don't really see the need for it other than as a sneaky way to get around CSD:G6 on talk pages of controversial articles and policies. --Bigpoliticsfan (talk) 17:31, 15 May 2016 (UTC)
2. Oppose No need demonstrated. Ruslik_Zero 12:48, 18 May 2016 (UTC)

• Comment: I could maybe support this, provided that anyone trying to move to a blacklist title was warned about it first. Without a warning before moving, I'd be inclined to oppose... --IJBall (contribs • talk) 02:00, 19 April 2016 (UTC)
• General comment: I'm neither supporting nor opposing at this time. While opponents of this proposal make good arguments (such as, there's a reason for blacklisting certain titles), I think the block list is targeted mainly against page-move vandals, not against trusted users who might be able to move pages without leaving a redirect. But I prefer a warning like MediaWiki:Moveuserpage-warning, except the text can be changed to "Warning: You are about to move a page to a title listed on the title blacklist. Please be careful." or something. (Obviously not the "Please Be Careful" part, but everyone should know what I mean.) epicgenius: unlimited epicness (talk) 16:35, 20 April 2016 (UTC)
• Anyone who gets this right is considered vetted by the admin (and it's time we upped the requirements for PCR). I wouldn't say tboverride is very necessary but it's barely necessary for admins either (I'd say around 10s know about its existence altogether), considering it to be a flag for admins is not a suitable reason for oppose because it's not like we vet them based on their knowledge of the blacklist. --QEDK (T ☕ C) 19:33, 20 April 2016 (UTC)

The infrastructure supporting Wikipedia:Editnotices is built around the title blacklist. I'd say every admin has a passing acquaintance with the blacklist (and the redlinks to Group notice and Page notice when editing this page for example), not just 10s. Bazj (talk) 10:17, 24 April 2016 (UTC)

Meh, yes, people have heard the name. You know it's there but you can't quite place it, sorta like your birth mark or Bill Cosby's ethics. --QEDK (T ☕ C) 18:46, 24 April 2016 (UTC)

• What happened to proposing a permission to become a title black overrider? The role might be similar to seeking a permission to rename files, right? George Ho (talk) 08:20, 7 May 2016 (UTC)

My bad; I didn't notice "creation of permissions" section.

1. Support - the blacklist exists as a block on recurrent vandal themes. I think editors trusted with this privilege can be trusted to ensure they're not being played as a cat's paw. Removal of the privilege is always hanging over those using it carelessly. A cautionary notice, as suggested by User:IJBall above would be useful ~ just add it to the shopping list when the permission is created. Bazj (talk) 11:16, 19 April 2016 (UTC)

   Comment Failure to include it would mean that Page mover would work differently for template editors. Not sure the intention here was to create two classes of page mover. Bazj (talk) 11:35, 19 April 2016 (UTC)

2. Support per IJball (with a notice to the mover) and Bazj. The blacklist is an anti-vandalism tool, users with this right should be trusted not to be vandals and only override the blacklist with good reason. Ivanvector 🍁 (talk) 21:41, 19 April 2016 (UTC)

   Wait, is the title blacklist separate from create protection? Ivanvector 🍁 (talk) 21:47, 19 April 2016 (UTC)

   Yes it is, this would not be able to override a protection level. In brief: SALT is used for specific pages, titleblacklist is used for patterns and also applies to usernames creation and managing editnotices. — xaosflux ^Talk 10:52, 20 April 2016 (UTC)

   Well, that's even better. There's always going to be exceptions to an automated blacklist. Ivanvector 🍁 (talk) 18:09, 21 April 2016 (UTC)

3. Support We are talking about a group of editors who have satisfied a certain criteria and have demonstrated they could be trusted with the safety of the project. If they violate this trust, it is easy to have the permission removed, easier then an admin. I believe the goal of this flag would be to lessen the burden on Admins, by giving a trusted group of editors who have proven they aren't out to break the project, this flag will lessen the load on admins. McMatter ^(talk)/_(contrib) 13:33, 20 April 2016 (UTC)
4. Support after further consideration. The community has determined that this right may probably be granted to trusted users only. So, why not let them override the title blacklist? Some of these title blacklist entries were done because of a few single-purpose accounts, and this hurts the rest of the community, even productive editors who must go to admin's noticeboard to request that their page be created. Why not let trusted non-admins do that? We already let trusted non-admins modify edit filters and highly visible templates. epicgenius: unlimited epicness (talk) 20:51, 20 April 2016 (UTC)
5. Support As said, it would be granted to vetted users only. I don't see a problem considering TE gets the same flag through the same process. In any case, the wizards at Phab can easily patch up a warning if that's a cause for opposing. --QEDK (T ☕ C) 15:40, 21 April 2016 (UTC)
6. Support. Ugggh, I didn't even know there was a title blacklist. I am not inclined to put much value on it. It seems a hell of a lot more useful to have some someone look if an article is a serious BLP violation than to rely on some machine to catch every possible permutation of title terms. I'd rather have trusted users be the final say than machines. Wnt (talk) 16:18, 21 April 2016 (UTC)
7. Support would occasionally be useful, particularly if suppressredirect is included. Template editors already have this. Peter James (talk) 09:17, 23 April 2016 (UTC)
8. Weak support I've been convinced to support in part by the above arguments. While I still think the criteria should take this into account I think this is something that can be occasionally useful and abuse would quickly result removal of the right at the least. I also suggest that guidelines be given to page movers on how to protect their account similar to that given to template editors. PaleAqua (talk) 17:13, 23 April 2016 (UTC)
9. Weak Support I don't know why this would be needed, and could potentially be abused. But it could be useful. — Music1201 ^talk 19:37, 23 April 2016 (UTC)
10. Weak Support I'm not entirely sold on how useful this is, and honestly agree with a number of the opposes, but Bazj's point above about how those with template editor would be a higher class of page mover makes me wary of not including this because I think having a system where some page movers can move over blacklisted names and some can't is a bad situation. Wugapodes (talk) 20:21, 24 April 2016 (UTC)
11. Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
12. Support with caveat, per IJBall: "provided that anyone trying to move to a blacklist title was warned about it first. Without a warning before moving, I'd be inclined to oppose".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
13. Support - It is a misnomer that admins are inherently better suited to push this button than other trusted users who clearly have Wikipedia's best interest at heart. I've pushed it myself when it was part of the account creator permission and the sky did not fall.--John Cline (talk) 06:00, 26 April 2016 (UTC)
14. Support - Reading the comments has given me a better understanding of the differences between the blacklists and SALTing an article. I still believe that creating an article that has been SALTed should be left to sysops, and I am in favor of a warning notice of sorts that the editor is about to create a title on the blacklist. — Jkudlick • t • c • s 10:07, 28 April 2016 (UTC)
15. Support Only if we make the conditions stricter than having a Wikipedia account for half a year. Peter SamFan 23:53, 2 May 2016 (UTC)
16. Tentative support – provided Page movers are warned that they are moving to a "blacklist" title before the move is completed, so that they have a chance to cancel a move to a blacklist title. Either we trust our veteran editors to be sensible, or we don't (and if we don't, we need "un"-unbundle everything up to an including "confirmed"!!). --IJBall (contribs • talk) 04:16, 3 May 2016 (UTC)
17. Support necessary for technical reasons to avoid two types of mover, and no reason not to. Peacemaker67 (click to talk to me) 04:30, 3 May 2016 (UTC)
18. Support. I don't think this is as big a deal as the opposers make it out to be. If a page mover shows such stunning lack of wisdom that they abuse the right, it can be taken away from them. I don't think the sky is going to fall if we let people a few trusted non-admins create articles with bad words in them. But I agree we need to have a warning. NinjaRobotPirate (talk) 07:05, 3 May 2016 (UTC)
19. Conditional support if a warning is displayed. As far I'm understanding this, the blacklist is only used to prevent vandalism and to prevent anyone from creating edit notices. That's no reason not to give this right to trusted editors (and template editors already have this right as well). —Ruud 10:22, 3 May 2016 (UTC)
20. Support with a warning displayed per Peter James, SMcCandlish. Baking Soda (talk) 14:46, 3 May 2016 (UTC)
21. Support, with the important caveat that the userright must not be given out carelessly. It should only be for established, trusted users. I think an established user can be trusted to do this correctly, without needing to pass an RfA. --Tryptofish (talk) 22:11, 3 May 2016 (UTC)
22. Support with warning. Sufficient level of trust already granted; potential bad decisions here can easily be reversed by admins. — JFG ^talk 22:27, 3 May 2016 (UTC)
23. Support The blacklist exists to stop vandals, and nobody else. Dubious that someone trusted with this right would so readily abuse it for harm. -FASTILY 23:51, 3 May 2016 (UTC)
24. Support As trusted users being given the ability to move a larger range of pages being able to override the blacklist is necessary. There are requests for this on AN occasionally and I experienced it reasonably regularly when I did WP:AfC stuff before becoming an admin; given that tboverride is a necessary ability of this new usergroup. Callanecc (talk • contribs • logs) 12:25, 4 May 2016 (UTC)
25. Support - Per above. The Master ---)Vote Saxon(--- 02:37, 5 May 2016 (UTC)
26. Support; makes perfect sense for a trusted group such as this to be able to override the blacklist. Kharkiv07 (T) 12:30, 5 May 2016 (UTC)
27. Weak supportI prefer to give people trust and than proved to be wrong, than remain doubtful. I think that a trusted group could do that as well.--Alexmar983 (talk) 16:52, 5 May 2016 (UTC)
28. Weak support Only if users are scrutinized heavily at time of request, and still have to be monitored after acquiring the permission. TJH2018talk 21:39, 5 May 2016 (UTC)
29. Support But DEFINITELY with a warning ahead of time, even for the responsible folks who might inadvertently miss something, particularly for things like "obscure ASCII characters" and stuff that may not always be picked up on by users with variously differing dialects of English. Montanabw^(talk) 03:54, 9 May 2016 (UTC)
30. Support per Montanabw. • • • Peter (Southwood) ^(talk): 11:36, 9 May 2016 (UTC)
31. Support—indopug (talk) 17:58, 9 May 2016 (UTC)
32. Support mainly per Fastily. There's no reason to assume that responsible editors would misuse this tool. But a warning should be displayed before a page is moved to a blacklisted title. 103.6.159.86 (talk) 08:48, 10 May 2016 (UTC)
33. Support. I don't see why experienced editors shouldn't be trusted with this. As others have noted, this list is mostly for vandals. Non-vandals ought to know better. Biblio (talk) 16:28, 12 May 2016 (UTC)
34. Support but with a stern warning to those given the right to not act stupid. --Bigpoliticsfan (talk) 17:33, 15 May 2016 (UTC)
35. Support. It is actually offensive how much you need to prove yourself to some admins… giso6150 (talk) 03:14, 17 May 2016 (UTC)
36. Conditional support - Per Ruud Koot Mlpearc (open channel) 15:47, 17 May 2016 (UTC)
37. Support mostly per John Cline. Admittedly, it won't need to be used often, but that's not really a good reason to oppose. kennethaw88 • talk 02:30, 18 May 2016 (UTC)
38. Support more value to give this permission for its usefulness and remove the priv from a user who misuses than to deny it in the first place. Donama (talk) 05:26, 18 May 2016 (UTC)
39. Support: Unbundling is good. Anyone that abuses this would pretty much lose this right instantly, so there's really nothing to worry about. WP:BOLD and all. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)

1. Oppose I think this is excessive and not needed for the majority of page moves as it applies to all blacklist operations, including page creation and username creation. — xaosflux ^Talk 01:08, 19 April 2016 (UTC)
2. Oppose - there are generally reasons for titles to be blacklisted. I'd say better to let admins handle those cases. Ajraddatz (talk) 01:42, 19 April 2016 (UTC)
3. Oppose per above - may require more discretion than a non-admin is trusted with. --Tom (LT) (talk) 02:00, 19 April 2016 (UTC)

   • Non-admins are already trusted with it. Peter James (talk) 16:36, 24 April 2016 (UTC)

4. Oppose as per others. There are rarely move operations that would need this right and the ones that do could be handled by admins. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)

   • (Edit moved to support) Oppose per above. Doesn't seem like it would be needed that often and it would increase security pressure on the accounts with it. PaleAqua (talk) 03:28, 19 April 2016 (UTC) Reconsidering, leaning to towards neutral based on some of the support comments. PaleAqua (talk) 22:42, 20 April 2016 (UTC)

5. Oppose. I support the above rights, but not this one. This should require a higher level of access. – Jonesey95 (talk) 03:49, 19 April 2016 (UTC)

   • Do you think template editor is a higher level? Peter James (talk) 16:36, 24 April 2016 (UTC)

6. Oppose Allowing users to override the blacklist would probably raise the bar for getting this userright and decrease the number of people with it (and thus also their collective effectiveness). Admins can handle these cases — Preceding unsigned comment added by Happysquirrel (talk • contribs) 03:53, 19 April 2016 (UTC)
7. Oppose. Makes sense for this user right to be part of the template editor group, but not this one. If an editor has both this proposed user right and is a template editor, problem solved. Steel1943 (talk) 20:00, 19 April 2016 (UTC)
8. Oppose. This is infrequent enough that there's no real need. Admins can handle the few that pop up every once in a while. ~ Rob^Talk 15:37, 20 April 2016 (UTC)
9. Oppose: Rarely needed and requires that all accounts with the right have a strong password, as a malicious (censored per WP:BEANS) can damage the encyclopedia easily and even cause BLP issues. Esquivalience ^t 22:48, 20 April 2016 (UTC)

   Just as much damage and BLP issues could be caused by any autoconfirmed user, with words individually considered less offensive but with the same meaning, and with fewer capitals, punctuation marks and obscure symbols. Peter James (talk) 23:25, 20 April 2016 (UTC)

   @Peter James: To change my vote to Oppose, I would need to be convinced that there is a serious security liability and not just a risk that some celebrity is mentioned in an embarrassing Google hit because that company can't wait ten minutes before they put a brand new article made by nobody who nobody knows as one of their top-ranking hits... and can't bother to delete it afterward for two days. They've made themselves the god on the internet, let them be responsible for their own actions! Wnt (talk) 16:22, 21 April 2016 (UTC)

10. Oppose best left to admins. SSTflyer 08:45, 24 April 2016 (UTC)

    • So you would support removing this right from template editors? Peter James (talk) 16:36, 24 April 2016 (UTC)

    • I wouldn't, for one the bar for template editors is very high - I suspect will continue to be tougher than this page and would rather make this easier to get, additionally this is the mechanism used to protect the editnotice pseduo-namespace (which primarily holds templates). — xaosflux ^Talk 16:40, 24 April 2016 (UTC)

    • It isn't. You just need to show that you absolutely need the right, that's all. --QEDK (T ☕ C) 17:22, 24 April 2016 (UTC)

11. Oppose as the risks of allowing creation of blacklisted titles appear to outweigh the benefits: how often would this actually be needed? Rubbish computer (HALP!: I dropped the bass?) 08:16, 25 April 2016 (UTC)
12. Oppose per above.—Godsy^(TALK_CONT) 02:13, 26 April 2016 (UTC)
13. Oppose This is uncommon enough that there is no need for this. There is no problem to solve. It can however introduce new problems where we had none. HighInBC 21:06, 29 April 2016 (UTC)
14. Oppose. As it's so uncommon, I don't really see sufficient benefit to outweigh the risk. Boing! said Zebedee (talk) 00:03, 3 May 2016 (UTC)
15. Hesitant Oppose, but oppose nonetheless. Very much in sync with comments from Steel1943 and Xaosflux. Personally think implications of tboverride for this right hasn't been discussed fully. I think administrators should have another look at fulfilling a request to start a page with a blacklisted title in general, and an admin should make the move. I'm neutral about Pagemovers creating editnotices. — Andy W. (talk · ctb) 02:17, 3 May 2016 (UTC)
16. Moderate oppose - Best left to admins. I see very very few cases where a page mover would want/need to move to a blacklisted title for legitimate reasons. Such handful of cases can be done by admins. EvergreenFir (talk) Please {{re}} 03:47, 3 May 2016 (UTC)
17. Oppose This is a case where admins need to be admins and have this role assigned to them. Pages are blacklisted for a reason. RickinBaltimore (talk) 12:23, 3 May 2016 (UTC)
18. Oppose per above: this is one case where an admin needs to make the call. --Gimubrc (talk) 17:14, 3 May 2016 (UTC)
19. We don't get an influx of requests for tboverride. No need to ease the tenuous load from admins here. Regards—UY Scuti ^Talk 06:12, 4 May 2016 (UTC)
20. Oppose per above, an admin protects/blacklists article names, and so it should also be an admin who unprotects/unblacklists the articles. Admin actions should only be overwritten by other admins. Joseph2302 (talk) 16:14, 4 May 2016 (UTC)
21. Oppose. I don't expect that there would be willful abuse, but there's too much potential for a page mover to use the right without being fully informed of the reasoning behind a blacklisting. Lwarrenwiki (talk) 18:01, 4 May 2016 (UTC)
22. Oppose. I assume anyone who needs to move to a title could just request that the problematic titles be moved from the blacklist first. (However, I would support this user right for template editors.) Can you give any examples of where it is needed (for things that aren't templates)? Discuss-Dubious (t/c) 14:33, 5 May 2016 (UTC)

    @Discuss-Dubious: Someone may need to move to a blacklisted title but the actual blacklist entry would need to stay in place - any number of blacklisted words, to start. –xeno^talk 17:04, 5 May 2016 (UTC)

23. Oppose: Not needed for this scope. GenQuest ^{"Talk to Me"} 11:57, 6 May 2016 (UTC)
24. Oppose. I cannot really imagine when this right would be needed. IMO, it is best if a second opinion (i.e. admin) is consulted before un-blacklisting a title, if there is any need for that in the first place. - HyperGaruda (talk) 05:46, 7 May 2016 (UTC)
25. Oppose BMK (talk) 18:30, 7 May 2016 (UTC)
26. Oppose - Blacklisted titles shouldn't be decided by an editor, unfortunately. Allowing this encourages more vandalism and disruption. --George Ho (talk) 05:08, 8 May 2016 (UTC)
27. Oppose as an uncommon occurrence that would usually require admin discretion. Double sharp (talk) 10:37, 8 May 2016 (UTC)
28. Oppose, would prefer this stay as an admin function. Nakon 03:08, 9 May 2016 (UTC)
29. Oppose: best left part of the admin toolkit. Jonathunder (talk) 23:43, 9 May 2016 (UTC)
30. Oppose. There is very little good reason to need to move a page to a title that's blacklisted. This should simply be left to the admins to prevent abuse. –Compassionate727 ^(T·C) 18:36, 10 May 2016 (UTC)
31. Oppose: Will probably create more harm that good, the other two permissions are understandable but this should be for admins+ only. Anarchyte (work | talk) 09:16, 14 May 2016 (UTC)
32. Oppose: Per above. ~riley (talk) 23:29, 14 May 2016 (UTC)
33. Oppose Taking a look at the title blacklist, I don't believe this is a necessary permission. ^{My name is}not^dave (talk/contribs) 15:48, 16 May 2016 (UTC)
34. Oppose Overriding the title blacklist? Seriously? It just make us prone to page-move vandalism. --Pokéfan95 (talk) 06:21, 17 May 2016 (UTC)

    Oh yes, trusted editors who are granted the page mover right are going to engage in page move vandalism. 103.6.159.70 (talk) 06:42, 17 May 2016 (UTC)

35. Oppose - I agree - would prefer this stay as an admin function. Gmcbjames (talk) 03:57, 18 May 2016 (UTC)
36. No need demonstrated. Ruslik_Zero 12:47, 18 May 2016 (UTC)

• What is the current threshold for non-admins and admins? FWIW, I have often had to make over 100 moves in a short space of time due to subpages. Jenks24 (talk) 10:15, 19 April 2016 (UTC)

  @Jenks24: Non admins; 8 moves per 60 seconds, admins unlimited. Moving subpages along with their parent pages only counts as one move, so 100 per 60 seconds should be enough for most applications. –xeno^talk 13:46, 19 April 2016 (UTC)

• I'd want to hear what the developers say about this. Is there any actual strain from all the page purges? Wnt (talk) 16:27, 21 April 2016 (UTC)

  Please note in case it got lost in the reading, this increase is only for members of this new group, not for all editors; currently administrators are set to unlimited and perform these moves whenever needed. — xaosflux ^Talk 21:19, 21 April 2016 (UTC)

  I understand, but ... I've heard crazy things over the years like the entire wiki getting locked in read-only mode because some admin deleted the Sandbox. So I don't actually know that the admins can't break the wiki if they do something wrong with their unlimited pagemoves. This isn't a No vote; I just don't know enough to vote Yes. Wnt (talk) 22:33, 21 April 2016 (UTC)

  Server strain can be caused with actions that affect massive numbers of revisions. Admins can't delete the sandbox for that reason; with 620000+ revisions, it probably would break the site. This is also why renames of accounts with over 50k global contributions require sysadmin approval. However, separately initiated small actions like moves would be very unlikely to cause server strain, and it isn't something to worry about. As Xaosflux says, users with the 'noratelimit' right can already bypass these restrictions, and expanding the number of people with access to higher ratelimits won't break the site. Ajraddatz (talk) 23:37, 21 April 2016 (UTC)

• Can people actually hit the limit? I doubt I can go beyond 2/60. --QEDK (T ☕ C) 20:31, 22 April 2016 (UTC)
  • @QEDK: This mainly concerns move-subpages because every subpage move counts as 1 (e.g. moving a page and its twenty subpages counts as 21 moves). At least that's how I understand it.—Godsy^(TALK_CONT) 04:06, 23 April 2016 (UTC)
    • Hitting 8/60 is easily possible with tabbed browsers; and trivial if using a script (acting like a bot). — xaosflux ^Talk 13:41, 23 April 2016 (UTC)
      • Ehhh, as I understand it, this right is to be used with discretion, not for making spam-like edits. Also, I thought I read someone here saying that move-subpages does not count as extra moves. --QEDK (T ☕ C) 15:53, 23 April 2016 (UTC)
• Up top Xeno says "Moving subpages along with their parent pages only counts as one move", but Godsy says "every subpage move counts as 1". Which is it? That's the difference between support and oppose for me. If subpages don't each count individually, I can think of no good reason to support. — Rhododendrites ^talk \\ 21:28, 23 April 2016 (UTC)
  • I think ( not fully verified ) currently that a page with subpage moves count as a single move. I know that request such as phab:T76263 have talked about making sub pages count towards the limit. And it seems like it may have been considered at different times from some of my diving into Village Pump (technical). PaleAqua (talk) 22:45, 23 April 2016 (UTC)
    • Summoning Anomie. --QEDK (T ☕ C) 11:36, 24 April 2016 (UTC)
      • Each submission of Special:MovePage counts as one towards the rate limit, no matter how many actual moves the submission results in. Anomie⚔ 11:44, 24 April 2016 (UTC)

  In closing a "Move all x (y) to x (z)" request, one may have to move dozens of individual pages; 8 per minute would be a hindrance, 100 per minute should be more than plenty (any more or faster and you're looking at a bot task). –xeno^talk 11:51, 24 April 2016 (UTC)

• Can you give an example? I don't know what you mean by x(y) and x(z). X=namespace? Base page? If each submission of the form counts as one, and therefore subpages don't count, why would a non-admin with this right need more than 8/minute? Maybe I'm being daft here, but I guess I'm off to start the oppose list. — Rhododendrites ^talk \\ 19:10, 24 April 2016 (UTC)

• Consider a succesful RM that required all the "X in Hong Kong" moved to "X in (some other name)". You could easily exceed 8 per min using tabbed browsing. –xeno^talk 21:45, 24 April 2016 (UTC)
• To clarify, I get that there could be a rush of very straightforward requests for move such that you might get through more than 8 in a minute. I also figure there are some rare requests that require many pages on the same level of page hierarchy (i.e. not subpages). It seems like those would be very uncommon, though, no? So raising the limit would allow people with this right to do those rare moves, but those requests could also simply be among the moves still best handled by admins (unless a pagemover wants to take a bit longer to do it). On the other hand, if an account is compromised or if there's a lapse in judgment, this provision is the difference between some damage and a huge mess. So because (a) it doesn't seem like it would be needed very often, (b) the cost when it is needed is very low (taking a bit longer or deferring to an admin), and (c) it significantly increases the potential for damage someone with this right could cause... I don't understand why there's such overwhelming support for this. — Rhododendrites ^talk \\ 19:17, 24 April 2016 (UTC)

• NOTE: Users who want to experiment how many moves they can make in a minute, head to WP:Requested moves/Old AFC submissions. Actually, it's quite difficult to go beyond 8. 103.6.159.79 (talk) 13:13, 15 May 2016 (UTC)

1. Support with a maximum of 100/60. I would also support any lower thresholds. — xaosflux ^Talk 01:11, 19 April 2016 (UTC)

   If if it clear that "move subpages - up to 100" count as "1 action" for this throttle, then 100/60 is more than should be needed, so recommend something lower like 30/60 max. — xaosflux ^Talk 01:58, 1 May 2016 (UTC)

   Still probably don't know enough here to give a truly meaningful opinion, but 20/60 or 30/60 sounds to me like a reasonable level – page movers should get a higher throttle limit than just regular confirmed users, but practically it probably doesn't need to be too much higher if "moving subpages" along with the page counts as "1" move... --IJBall (contribs • talk) 05:46, 1 May 2016 (UTC)

2. Support an increase. 100/60 sounds good to me, though any number that allows these users to effectively close RM requests would work. Ajraddatz (talk) 01:43, 19 April 2016 (UTC)
3. Support. I'll leave it to the experts to figure out what the exact limits should be. --IJBall (contribs • talk) 01:58, 19 April 2016 (UTC)
4. Support with thanks to the editors wielding these small non-admin sized mops. --Tom (LT) (talk) 02:00, 19 April 2016 (UTC)
5. Support, and I agree with the above !voters' arguments. APerson (talk!) 02:05, 19 April 2016 (UTC)
6. Support at the abundant rate at 100/60, as individual articles will most likely not have 98 archives/subpages, and this removes the possibility in most cases of being throttled. Esquivalience ^t 02:10, 19 April 2016 (UTC)
7. Support a rate of 100/60. Few move-subpages operations would need a better rate than that. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)
8. Support Not only because of subpage moves but multimoves could run into the limits. No real preference on the exact rate limit but 100/60 does seem reasonable. PaleAqua (talk) 03:30, 19 April 2016 (UTC) Edit: clarify my support is about multimoves which are impacted by the limit as compared to subpages moves which are not currently though there have been proposal's from other wikis to include subpages in the limit. PaleAqua (talk) 20:47, 24 April 2016 (UTC)
9. Support. Makes perfect sense. Steel1943 (talk) 20:02, 19 April 2016 (UTC)
10. Support - sure, although if moving a page with all its subpages counts as a single move anyway then I don't really see the need. Basically I think the limits for users granted the permission should be the same as those granted to admins. Ivanvector 🍁 (talk) 21:43, 19 April 2016 (UTC)
11. Support but put a limit on it. 120 pages/60 seconds (2 pages per second – page and associated talk page) sounds like a good deal. epicgenius: unlimited epicness (talk) 16:21, 20 April 2016 (UTC)
12. Support. Makes sense. A limit sounds ok but like User:IJBall, I would let experienced or expert users determine the parameters. Donner60 (talk) 05:58, 21 April 2016 (UTC)
13. Support with a maximum of 100/60 and no more. If it were any more, I'd oppose. Peter Sam Fan 23:07, 21 April 2016 (UTC)
14. Support Makes sense to me. — Music1201 ^talk 19:39, 23 April 2016 (UTC)
15. Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
16. Support within reasonable limits, per xeno: "100 per 60 seconds should be enough". If it is not possible for some reason to set that limit, then I tentatively support no limit, as with admins, but a disgruntled editor on their way out (perhaps after being subjected to some kind of punitive action at ANI or something) could make a temporary mess if this were totally unlimited.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)

    Support up to a certain limit. Rubbish computer (HALP!: I dropped the bass?) 08:24, 25 April 2016 (UTC)

17. Support - Since subpages do not count toward the limit, I find it difficult to imagine how a user not using a script could move even 8 pages in one minute. If there is a large group of similarly named pages to be moved, e.g. all "X in [Place]" pages need to be moved to "X in [New Place]," then a script would likely be used, but I don't see a real need to be able to move 100 pages per minute. I would support a limit of no more than 60 moves per minute. If there are so many pages to be moved that the increased limit would be broken, then perhaps it should wait for a sysop. — Jkudlick • t • c • s 04:32, 29 April 2016 (UTC)
18. Support no technical reason not to, and means these editors can get stuck in as necessary. Peacemaker67 (click to talk to me) 04:32, 3 May 2016 (UTC)
19. Support As this would be a help with the other rights if rolled out. RickinBaltimore (talk) 12:23, 3 May 2016 (UTC)
20. Support Harmless imo, and potentially useful -FASTILY 23:50, 3 May 2016 (UTC)
21. Support. This is only an increase in throttle limit. A limit still exists, and if a page mover abuses this, the page mover can be blocked and the page moves can quickly be reverted by an admin. SSTflyer 05:39, 4 May 2016 (UTC)
22. Reasonable—UY Scuti ^Talk 06:13, 4 May 2016 (UTC)
23. Support - Per above. The Master ---)Vote Saxon(--- 02:37, 5 May 2016 (UTC)
24. Weak support Only if a consensus is reached on the limit by admins. TJH2018talk 21:38, 5 May 2016 (UTC)
25. Support—indopug (talk) 17:58, 9 May 2016 (UTC)
26. Support votes on other components under previous username, Bazj - for (;;) (talk) 13:49, 11 May 2016 (UTC)
27. Support 120/60. May as well make the limit an even number of moves per second. Biblio (talk) 16:33, 12 May 2016 (UTC)
28. Support making it unlimited. No need to have unnecessary restrictions. Admins anyway have an unlimited limit so what's the point? Page movers are not going to abuse their rights by making nonsense moves. If they do, their rights should be removed. 103.6.159.79 (talk) 13:07, 15 May 2016 (UTC)
29. Support 180/60 or 240/60, but no more. Otherwise what's the point of making admins have unlimited page moves? --Bigpoliticsfan (talk) 17:40, 15 May 2016 (UTC)
30. Support. If "move 100 subpages" counts as "100 moves" then it is absolutely necessary to lift the throttle if we give this new permission the right to move subpages. Even if not, I don't see much harm in bundling this permission to a flag that specifically appoints somebody to move pages. Deryck C. 13:51, 17 May 2016 (UTC)
31. Support with a maximum of 100/60. Mlpearc (open channel) 15:49, 17 May 2016 (UTC)

1. Oppose - I'm still not certain I understand this correctly, but I'm also not sure the supporters do. If all subpages combine with the base page being moved to make one move request towards the limit, I don't see how this would be a hindrance for 99.99% of users. On the other hand, in that worst case scenario of a compromised account, vandal, or spree of bad judgment, it would allow for much bigger messes to be created (i.e. I'd rather have the very few people who would do more than 8 moves in a minute to have to wait a few seconds than make it easier for this right to be misused). — Rhododendrites ^talk \\ 19:10, 24 April 2016 (UTC)
2. Oppose per Rhododendrites. If subpages don't count towards the limit, then I don't see why this is necessary. Like Rhododendrites above, I'm wary of making the tradeoff between making the lives of a few power users easier and making the right easier to abuse. Wugapodes (talk) 20:21, 24 April 2016 (UTC)

   Do you have any other suggested limit that is more than 8/60 that you would be comfortable with? — xaosflux ^Talk 21:57, 25 April 2016 (UTC)

   @Xaosflux: To be honest, I'm not sure I know enough about rate limits to have a particularly educated opinion. I agree with Godsy below that the suggestions in support are way too high. It should be high enough that a user going to a page, moving it, going to another, moving, etc could do so uninterupted manually. This isn't a right for automated moving, so I don't see how it is possible or even recommended that someone do 100 moves in 60 seconds (that's like a page move every half second! I take longer to type the new title!). If I were to support some increase, it would have to be below 30/60, so 2 seconds per page move basically. And I'd be hard pressed to support that. I think rate increases should largely be on a case by case basis. Wugapodes (talk) 03:39, 28 April 2016 (UTC)

   Since ratelimits are assigned to a certain right, it'd not be possible to do this on a case-by-case basis. --QEDK (T ☕ C) 04:02, 28 April 2016 (UTC)

   That is news to me, thanks. Given that, I don't see a particular need for the increase, I'd be willing to compromise on 20/60 as Godsy said below, but I'd prefer no increase. Wugapodes (talk) 04:09, 28 April 2016 (UTC)

3. Weak oppose due to the potential for this to be misused. Rubbish computer (HALP!: I dropped the bass?) 08:30, 25 April 2016 (UTC)
4. Oppose - There is no need. Requests that require an increased throttle rate are currently at a low enough occurrence that they can reasonably be handled by an administrator or bot. The potential for abuse per Rhododendrites outweighs the benefit. "Increase" isn't specific enough, and the most popular numbers are too high in my opinion. I think 15-20/60 would be reasonable (60/60 would be the absolute most I'd consider supporting).—Godsy^(TALK_CONT) 02:04, 26 April 2016 (UTC)
5. Conditional oppose Since subpages count as one move, there's no need of this flag. People need to understand this power granted by the page mover right is to be used at discretion. --QEDK (T ☕ C) 03:55, 26 April 2016 (UTC)

   I would be satisfied with a compromise of 30/60 at most. --QEDK (T ☕ C) 13:31, 3 May 2016 (UTC)

6. Oppose - Having given my assent for the creation of this user group, I have also given thought as to the editing environment, and the types of editor best suited to excel as a page mover. In general, for example, I think template editors would make good page movers because they tend to be deliberate and methodical, meticulous and thorough, alert and keen on detail. Editors of such comprise will not be hurried along at the risk of shoddy results, and they won't be hindered by the throttle limit in place and I prefer they abide by their traits to remain steadfast and true.--John Cline (talk) 10:17, 28 April 2016 (UTC)
7. Oppose I simply don't see a need for this loosening of the throttle. This is rarely needed to be exceeded and the current limits mitigate damage. HighInBC 21:08, 29 April 2016 (UTC)
   • I've run into the limit before, and I don't even move things that often. When many pages are nominated at once, the most efficient way to move them is to switch from tab to tab and hit submit in sequence. ~ Rob^Talk 16:01, 30 April 2016 (UTC)

   Weak oppose. If subpages count as one move, I'm sure that 99.9% of cases don't involve more than 8 moves in a minute. I'd change my vote if the proposed limit were something like 10 per 15 seconds, or 30 per 60s (yes I know the ratios here are different). 10/15, because if these movers are batch moving something like annual sports pages (and there are 40 editions of this annual event), the page mover can still get it done in a minute. The risk of abuse depends on how high we're setting the bar, and the bar seems decent, so I'm not too worried about move vandalism or anything, especially if the rate were lower, like 10 per 15. Page moves with a script sounds like a good idea, but there's never really a rush, and you can't be too careful. — Andy W. (talk · ctb) 02:37, 3 May 2016 (UTC) Not opposing or supporting anymore (may give off wrong information). I'm fine with an increase to 20 per 60 or 30 per 60. — Andy W. (talk · ctb) 15:21, 13 May 2016 (UTC)

8. Oppose - Would support a minor increase, but not 100 per minute. I find it hard to imagine moving so many pages without some sort of automation anyway. Potential for misuse seems too great for this. If you need that many pages moved, enlist an existing bot to do it. EvergreenFir (talk) Please {{re}} 03:51, 3 May 2016 (UTC)
   • I'm wondering if this one should be "re"-proposed with 20/60 or 30/60 rather than 100/60 – it seems like that might cut the opposition to this proposal in half... But I agree with Rob above that the throttle for Page movers should be increased over 8/60. --IJBall (contribs • talk) 04:19, 3 May 2016 (UTC)
     • Well this is a "discussion" not a vote - so I expect the eventual closer to read all of these comments :D — xaosflux ^Talk 13:37, 3 May 2016 (UTC)
9. Weak oppose If moves with subpages are always just counted as one move, it would seem very hard to hit the existing limit in practice. And in the worst case, you'd just have to wait a minute. The potential mess in case of an account compromise is somewhat of a legitimate concern. I'd support a smaller increase like 20 per minute, or increasing it if we start seeing actual reports of people with this right hitting the limit. —Ruud 10:31, 3 May 2016 (UTC)
10. Strong oppose, even though I otherwise support the proposal here. This kind of rapid mass action is exactly the kind of thing where problems can arise, and for this, I want users to have passed an RfA. --Tryptofish (talk) 22:14, 3 May 2016 (UTC)
11. Oppose Let's be cautious here; rate-limiting guards against account hijacking and involuntary blunders (can happen to the best people). — JFG ^talk 22:27, 3 May 2016 (UTC)
12. I support an increase but not so high as 100/60. I support from 50/60 down (30/60 is my preference though). Callanecc (talk • contribs • logs) 12:30, 4 May 2016 (UTC)
13. Oppose - I've moved more pages than 99.99% of users and I've still never hit a rate limit. Mark Schierbecker (talk) 08:04, 5 May 2016 (UTC)
14. Weak oppose: I think 8/60 is sufficient. An increase up to or less than 20/60 sounds like unnecessary complexity to me (it's such a small difference that it would be better to change a normal page mover's throttle rate to 20/60 if 7/60 is a problem). Anything from 20-100/60 sounds unnecessary and borderline dangerous to me, and unlimited (or over 100/60) would worry me. — Bilorv_(talk)^(c)(e) 22:15, 5 May 2016 (UTC)
15. Oppose BMK (talk) 18:30, 7 May 2016 (UTC)
16. Oppose - It would encourage more disruption and more vandalism by such increase. Also, with preexisting move requests, including discussions, the increase is not necessary. George Ho (talk) 21:59, 7 May 2016 (UTC)
17. Oppose: unnecessary if subpages don't count. Double sharp (talk) 10:38, 8 May 2016 (UTC)
18. Oppose, would prefer a bot/sysop flag for this. Nakon 03:09, 9 May 2016 (UTC)
19. Oppose per Rhododendrites. –Compassionate727 ^(T·C) 18:47, 10 May 2016 (UTC)
20. Weak Oppose: Don't really see a need for this one, but if you need to exceed that limit, likely you need to be a bot. I'd rather have a WP:BOTREQ for these type of things. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)
21. No need demonstrated. Ruslik_Zero 12:46, 18 May 2016 (UTC)

Thread retitled from "Move protection".

Similarly to how templates that were once fully protected have been changed to template protection, could/should we start phasing move protection to allow page movers to move pages? Kharkiv07 (T) 14:27, 22 April 2016 (UTC)

Once the reso ends successfully, definitely. --QEDK (T ☕ C) 14:31, 22 April 2016 (UTC)

Great idea. Moved into RFC proper. –xeno^talk 15:30, 22 April 2016 (UTC)

I don't like this creep in the middle of the RfC - and it is not clear exactly what is trying to be accomplished. @Xeno:: are you proposing that we add a new protection level, and make it restrict actions from everyone except pagemovers and administrators (maybe bots too?) ? — xaosflux ^Talk 15:35, 22 April 2016 (UTC)

Oops, this came from @Kharkiv07:, not Xeno - though all clarifications are welcome! — xaosflux ^Talk 15:38, 22 April 2016 (UTC)

It's still early in the RFC, this particular rider can run for a full 30 if need be. I guess we would need a special protection level. –xeno^talk 15:43, 22 April 2016 (UTC)

Yes xaosflux, just as template protection is currently done. @IJBall: There are an enormous amount of move protected pages for page-move warring; a conflict this group should be able to settle in a RM. Kharkiv07 (T) 16:11, 22 April 2016 (UTC)

My guess is that this is needed in so few cases that it's probably not necessary. Not that I'm against it. I just suspect that it's really not needed – the only instance I can think of where it might come up would be after the closing of a WP:RM request that set off some "move warring" (prompting an Admin to "move protect") during the run of the RM discussion. But I suspect that doesn't happen very often at all. --IJBall (contribs • talk) 16:06, 22 April 2016 (UTC)

You'd be surprised, especially in template namespace.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)

• Sounds like a cool idea, I doubt there is much scope for moving move-protected pages but certainly is useful. (Written while listening to Death Cab For Cutie) --QEDK (T ☕ C) 20:30, 22 April 2016 (UTC)
• I'm not sure whether to support this but move protection should be reviewed; some pages were semi-protected with full move protection after a few IP vandalism edits nine years ago then had semi-protection removed but remain move-protected (and other pages have had "move=autoconfirmed" since 2007). Peter James (talk) 23:52, 23 April 2016 (UTC)
• Question - If a move protected title is moved, does the move protection remain in place for the new title?--John Cline (talk) 06:47, 26 April 2016 (UTC)

Yes, though the logs will point that the protection is on the old page when it actually isn't. --QEDK (T ☕ C) 06:49, 26 April 2016 (UTC)

• Question: @Kharkiv07, QEDK, SMcCandlish, and Xaosflux: File movers can move "move-protected" files. Can page movers do so too? How distinct is this from movefile? (movefile has been mentioned only twice on this page) — Andy W. (talk · ctb) 02:50, 3 May 2016 (UTC)

@Andy M. Wang: To be clear, filemovers can move normal files, normal users can not move files at all; however file movers can not move move protected files. — xaosflux ^Talk 02:55, 3 May 2016 (UTC)

@Xaosflux: Thanks. But the proposal is that page movers can move move protected pages, and not move protected files, right? Because if page movers can move files, they'd have to understand file renaming policies. — Andy W. (talk · ctb) 02:59, 3 May 2016 (UTC)

This section isn't very well defined - it is primarily about creating a new protection level (e.g. "page mover protected") that admins could apply to pages to prevent them being moved except by page movers (who would get the access given) and admins. The policy of how that should be applied would need to be more well defined. There is no "move protected files" protection now, this could be used for it, but they wouldn't be able to actually move the file unless they also were a filemover. — xaosflux ^Talk 03:05, 3 May 2016 (UTC)

We would probally need to update the protection policy to be very clear on the authorized use cases, e.g. this protection level is probably inappropriate for edit protection (though it COULD be applied if it were created). — xaosflux ^Talk 03:06, 3 May 2016 (UTC)

Personally, I think this is overkill - all of the other editing type protections are currently available for move protection if needed, and I don't really see a lot of use cases where this would ever be needed to justify its existence. — xaosflux ^Talk 03:05, 3 May 2016 (UTC)

Thanks for the clarification, and I agree. This is getting into extremely dicey rights issues that isn't well defined. If page mover protected is going to be a thing and is approved, I think it should be completely distinct from files, or, if applies to files, the filemover userright should be needed to move the file, i.e. movefile should take precedence. Unfortunately, this doesn't seem well thought-out, and I'm casting an oppose vote in this category. — Andy W. (talk · ctb) 03:14, 3 May 2016 (UTC)

Just to be clear, for the FILE: namespace no moves would be possible with this group if it is implemented by a new protection level; however files could be additionally protected with this level - requiring someone to be both a filemover and a pagemover to move it. — xaosflux ^Talk 03:25, 3 May 2016 (UTC)

• Are we creating a new protection level or no? --QEDK (T ☕ C) 17:08, 4 May 2016 (UTC)

  @QEDK: (This section still need to pass.) But since "move protected" means move=sysop is set, a new protection level (essentially a "group") is clearly the most viable way of implementing this. Page movers cannot move if the page has move=sysop, and granting page movers sysop makes no sense. sysop has implications outside of move, such as edit=sysop (we all know that). To allow pagemovers into the more exclusive list of move-protected pages, a new "group" that includes admins and pagemovers is the easiest way. (move=pagemover)

  The tricky thing about this is, what exactly does edit=pagemover mean? That means that only admins and page movers can edit that page, which is kind of absurd, but it's a murky side effect of a new group. I don't know if MediaWiki prohibits setting edit= certain levels. We'd be saying that template editors and extendedconfirmed users cannot edit that page (because they're not part of the pagemover group.

  @Xaosflux: Another drastic way to implement this is to split the monolithic sysop into sysopedit, sysopmove, sysopsomething, and grant admins into these new groups, deprecating sysop. Then, we can invite pagemovers into sysopmove. The only way this could work is if MediaWiki prohibits edit=sysopmove and move=sysopedit, and I'm completely clueless if certain restrictions like these are/can be implemented. — Andy W. (talk · ctb) 22:33, 5 May 2016 (UTC)

  Edit: I forgot editprotected for a second there. I'll be quiet, I might not have my facts right. — Andy W. (talk · ctb) 23:12, 5 May 2016 (UTC)

  This is a very confusing section - and exactly what it is trying to accomplish, and how, has multiple competing viewpoints in the discussion! — xaosflux ^Talk 00:36, 6 May 2016 (UTC)

  I'm with you – I suspect this is complicated enough it would require a separate, standalone RfC, assuming the bulk of the original proposal passes. But this is complicated enough that I haven't even rendered an opinion on this section yet – I think it needs more discussion... --IJBall (contribs • talk) 01:56, 6 May 2016 (UTC)

• Question, regarding disputes: As this right wouldn't be granted by the community, only a single admin, under what threshold would removal of the right be approved regarding a possible disputed move by a community-rights-granted (sysop/bcrat/etc.) editor? Nakon 04:03, 9 May 2016 (UTC)
• Question to opposers - I notice that some editors are opposing because they think that page movers should not be allowed to do this at all, while several others seem to be opposing just because it will be technically difficult/impossible/uncertain to implement. Can I ask you to clarify: if it's possible to implement technically, would you support? I think your clarification will help whoever closes this. Fine to say that you'd like to wait to see exactly what the implementation looks like, or state your conditions. It's entirely possible it will have to be worked out after this RfC. Ivanvector 🍁 (talk) 19:56, 10 May 2016 (UTC)
  • As I said in my oppose I support the concept but can't support in practice without a well considered implementation. My concern is not just the feasibility but the tangential effects. For example a new protection level comes with management issues and the possibility of changing the protection level of other pages without a way for the page mover to reverse without admin assistance. The major reason for page mover is to reduce backlog. I don't want to see page protection become an area that requires more admin support. PaleAqua (talk) 20:20, 10 May 2016 (UTC)
    • Same. I'm not concerned about the technical details of all of this, its certainly possible, and should be quite simple for our developers. I'm more concerned about how sweeping this would be. I would oppose demoting all pages which have move=sysop to move=mover, like pretty much happened with all templates when template editor came out. The reason is that I don't want a simple right like this, which has some basic things like suppress redirects, to have such a huge requirement that template editor does. –Compassionate727 ^(T·C) 21:58, 10 May 2016 (UTC)
      • I may support if: 1. page movers cannot move template-protected pages, 2. template editors cannot move "pagemover-protected" pages, and 3. if pagemover is a new protection level, edit=pagemover should a setting completely disallowed by the backend. It's a tad more intricate than other protections we've seen, but if devs do this without needing an overhaul of the system, then sure. — Andy W. (talk · ctb) 04:57, 11 May 2016 (UTC)
• Comment – It might be worth it (assuming this part passes) to restrict Page movers to moving Move Protected pages only after the result of a WP:RM. IOW, Page movers shouldn't move Move Protected pages aside from those "OK'ed" by a WP:RM discussion. (This can be added as a "restriction" to the WP:Page mover instructions page.) Thoughts?... --IJBall (contribs • talk) 04:46, 13 May 2016 (UTC)

I assumed that would go without saying. Other than cases of non-controversial maintenance. Ivanvector 🍁 (talk) 13:50, 13 May 2016 (UTC)

1. Support perhaps the most useful right that this group could possibly have when closing RM discussions. Kharkiv07 (T) 16:11, 22 April 2016 (UTC)
2. Support, come on, this userright is titled page mover... Users who obtain this right have obviously enough experience to move move-protected pages, which are usually locked due to petty content disputes or page-move vandalism. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
3. 'Support as Xaosflux outlined it: "add a new protection level, and make it restrict actions from everyone except pagemovers and administrators (maybe bots too?)" (I would support it for bots that need it, too). The potential for abuse of this is actually less than that of the speed increase. Obviously, ANI (or some other process) would strip pagemover from anyone who abused it to get their way in a movewar, so there really is no big deal here. In particular, the problem Peter James points out is rampant. As a templateeditor, I quite frequently encounter TE-protected pages that have full move protection for no reason any longer, and I keep having to request that it be changed at RFPP (often twice, because people processing requests there frequently don't notice that it's a request for a change of move protection not edit protection, so I end up having to file the request two or more times; sometimes this bureaucracy runaround slows down my template-namespace cleanup work for 2 days or longer (which often means I just drop it and move on, leaving cleanup projects unfinished indefinitely).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
4. Support as appears central to the group's overall purpose. Rubbish computer (HALP!: I dropped the bass?) 08:26, 25 April 2016 (UTC)
5. Support Since we're making this a restricted right, I do not suspect any misuse of this right. I doubt page move requests on protected pages will be granted much but still an useful bit to add to the right. --QEDK (T ☕ C) 03:52, 26 April 2016 (UTC)
6. Support Yes, we need this. Since the title of many move-protected pages are often debated at RM, which those which have this right would most likely work at a lot, this would be an extremely helpful right to have. Omni Flames ^{let's talk about it} 05:42, 26 April 2016 (UTC)
7. Support - it defies logic to set someone to a task while precluding their ability to use the very tools they would inherently need. Let's embrace logic instead, and deliberately equip members of this group as best we conceivably can! Let's maximize their abilities regarding page moves, and increase in turn the dividend we derive by their service and the free gift of their time.--John Cline (talk) 06:52, 27 April 2016 (UTC)
8. Support - I'm not against creating another move-protection level, but I don't think it's necessary. We should be able to trust users given this right to know when to move pages. It can come with a caveat that pagemovers moving a protected page should check the protection log first to understand the reasons for protection, and consult with the protecting admin in unclear cases. This is similar to how pending changes works: reviewers are expected not to approve edits which perpetuate the reason for PC-protection. Unlike the necessity to sometimes full-protect pages when [auto]confirmed editors are edit warring, a user using pagemover to move-war should just have the right stripped. Ivanvector 🍁 (talk) 16:42, 27 April 2016 (UTC)
9. Support - If we're going to call this userright "Page Mover," then they should have the authority to move protected pages, otherwise what is the point? — Jkudlick • t • c • s 10:09, 28 April 2016 (UTC)
10. Support I think if an entire user right is going to be created, it's users ought to be able to move move-protected pages. — Music1201 ^talk 18:54, 1 May 2016 (UTC)
11. Support Yes, I agree with everybody above. Peter SamFan 23:51, 2 May 2016 (UTC)
12. Tentative support Not sure it is actually necessary in terms of backlog reduction, but makes some sense to bundle it with the rest of the page move toolkit. Peacemaker67 (click to talk to me) 04:35, 3 May 2016 (UTC)
13. Support Per Ivanvector above. This again seems pretty central to the permission (acting on requested moves that have gained a clear consensus). No need for extra protection levels, just remove the right in case of abuse. —Ruud 10:35, 3 May 2016 (UTC)

    @Ruud: @Ivanvector: Without creating a new level what are you specifically supporting from a controls level? Are you suggesting that we get the developers to change the existing permission system to allow "pagemoves" to move pages that are otherwise specifically protected to only allow moves by administrators (such as high risk templates with a million transclusions)? — xaosflux ^Talk 10:48, 3 May 2016 (UTC)

    Note: This would include pages that they can't even edit - allowing them to move a page or template away and replace it with an arbitrary and unprotected page. — xaosflux ^Talk 10:49, 3 May 2016 (UTC)

    @Xaosflux: Ah, good point. Now I think about, what I proposed probably isn't technically feasible at the moment. I'm not sure if the developers would like to change the permissions system, so adding an extra protection level (like we had to do for template editors) may be the only way forward.

    I'm not too concerned about abuse. Taking a permission away from one specific editor seems preferable over pre-emptively protecting a whole class of pages from a whole class of users.

    I do understand your concerns below, now. Having page movers being able to move protected pages seems like a good idea in principle, but implementing it using a new protection level would could get rather messy in practice (e.g. when should admins apply "pagemover-only protection" and when "full protection"?). —Ruud 11:00, 3 May 2016 (UTC)

    Oh I don't know the technical ins-and-outs of protection levels at all, really, I was just giving an opinion. My core point is I think that users given this access level should be trustworthy enough that we can count on them not to make irresponsible page moves, and/or to ask for help, otherwise they will have the right revoked. In that regard I think that pagemovers should basically have the same rights as admins when it comes to moving pages, much the same way that template editors basically have the same rights as admins with regard to editing templates, and file movers have the same rights as admins with regard to moving files. This, basically. I don't see a reason to complicate it: if a page mover misbehaves in almost any way, they lose the right immediately. Ivanvector 🍁 (talk) 19:42, 3 May 2016 (UTC)

    Just to correct myself a little bit - you can't move a page you can not also edit, so edit protection will trump move protection - just an FYI. — xaosflux ^Talk 02:49, 4 May 2016 (UTC)

    Ah, I thought they were entirely separate, but that makes sense. How does pending changes impact moving? Ivanvector 🍁 (talk) 14:15, 4 May 2016 (UTC)

    Ok I updated the table, and I think I see what you mean. To be clear, I support that page movers should be able to move protected pages, even though due to technical restrictions they may not actually be able to move a full protected page. I don't think we should create a new protection level to enable this. If we need admins to move full-protected pages, well that's not a huge burden. Ivanvector 🍁 (talk) 14:47, 4 May 2016 (UTC)

14. Support This would tie in to the right being given, so this is an obvious one. RickinBaltimore (talk) 12:24, 3 May 2016 (UTC)
15. Support per . Kharkiv07, Satellizer. Baking Soda (talk) 14:42, 3 May 2016 (UTC)
16. Support. Seems obvious. Steel1943 (talk) 19:40, 3 May 2016 (UTC)
17. Support. Helps do the job. Appropriate trust level is already implied. — JFG ^talk 22:27, 3 May 2016 (UTC)
18. Support Appropriate for the right being granted -FASTILY 23:52, 3 May 2016 (UTC)
19. Allow good standing editors to move a potentially controversial page after discussion. A weak support for this one—UY Scuti ^Talk 06:22, 4 May 2016 (UTC)
20. Support: I am all for breaking up the tools, admins are not gods and are not infallible but it can be extremely difficult to have their bit removed. By breaking up the tools into pieces such as this we lower the bar for removal of these bits from any user which misuses it, same as rollbacker, reviewer and template editor. McMatter ^(talk)/_(contrib) 13:24, 4 May 2016 (UTC)
21. Support. It's reasonable to trust approved page movers with this right. Lwarrenwiki (talk) 18:03, 4 May 2016 (UTC)
22. Support - Per above. The Master ---)Vote Saxon(--- 02:38, 5 May 2016 (UTC)
23. Support Per above.--Alexmar983 (talk) 16:50, 5 May 2016 (UTC)
24. Support: Appropriate per request. GenQuest ^{"Talk to Me"} 12:00, 6 May 2016 (UTC)
25. Support, as per above. Martinevans123 (talk) 18:05, 7 May 2016 (UTC)
26. Support. Common sense says a page mover ought to have the ability to move all pages. The reasons given in opposition don't hold much water. Calidum ¤ 22:09, 7 May 2016 (UTC)
27. Support as reasonable. Double sharp (talk) 10:41, 8 May 2016 (UTC)
28. Support: Like anything, it could be abused, but the rules on wheel-warring should apply to anyone with this userright. Montanabw^(talk) 03:56, 9 May 2016 (UTC)
29. Support. Page mover => moves pages. If you dont trust a user dont give the permission. • • • Peter (Southwood) ^(talk): 11:55, 9 May 2016 (UTC)
30. Support. Perfectly analogous to the template editor user right, which has been successful. The opposition seems to stem from either (a) distrust of potential editors with this right, (b) a general disagreement with unbundling the tools, or (c) technical concerns over this allowing editors to edit fully protected pages. (a) is solved by sufficiently high standards to get the right. (b) is something I fundamentally disagree with. And (c) is more or less answered by the spirit behind Wikipedia:Don't worry about performance; let the developers figure out how to unbundle the tools so editors with this user right can move any move-protected pages without editing fully protected pages. If they can't figure it out (highly unlikely), we can address that then. ~ Rob^Talk 12:07, 9 May 2016 (UTC)
31. Support—indopug (talk) 17:59, 9 May 2016 (UTC)
32. Support It would be silly not to give this right to the group of users called "page movers". It makes the package mor efficient and meaningful. But I suggest that the page movers exercise this tool only upon successful RM discussions. 103.6.159.85 (talk) 06:55, 11 May 2016 (UTC)
33. Support votes on other components under previous username, Bazj - for (;;) (talk) 13:49, 11 May 2016 (UTC)
34. Support. Of course. The whole point of the right would be severely impaired without this. Biblio (talk) 16:35, 12 May 2016 (UTC)
35. Support – OK, the supporters have won me over. I personally don't think it's crucial for this to be included in the package – for one thing, I think moving Move Protected pages will not come up that often. But it's probably a net positive to let trusted Page movers move them in those few cases where it comes up. --IJBall (contribs • talk) 04:40, 13 May 2016 (UTC)
36. Support - This should definitely be among the tools that come with being a page mover. This is a very significant (if not the most significant) permission that would be valuable for this user group. It doesn't seem to me that this would be very difficult to implement. All that needs to be done is to add this pagemover group to the list of users able to move move-protected pages. Eventhorizon51 ^(talk) 22:25, 13 May 2016 (UTC)
37. Conditional Support - I still have implementation concerns but support in theory. Ideally the biggest things I want ensured are that when moving a move-protected page that a page mover is made aware that it was protected, that moving a page —for example during a round-robin page move— doesn't end up unnecessarily protecting other pages, and that they can revert any page move that they made in mistake without the final protections needed to be fixed by an admin. Secondary concerns are that I would like to avoid if possible a huge amount of permission churn or an increase in complexity of managing permissions as in the implementation. PaleAqua (talk) 03:12, 14 May 2016 (UTC)
38. Strongest possible support as no-nonsense as it gets IMO. --Bigpoliticsfan (talk) 17:44, 15 May 2016 (UTC)
39. Support -- yes! Isn't this right all about these sorts of pages? ^{My name is}not^dave (talk/contribs) 15:50, 16 May 2016 (UTC)
40. Support with implementation concerns per PaleAqua. Deryck C. 13:58, 17 May 2016 (UTC)
41. 'Support - Per everyone. Mlpearc (open channel) 15:51, 17 May 2016 (UTC)
42. Weak support per above arguments that will be more value to give the right than deny it because of potential misuse. Donama (talk) 05:29, 18 May 2016 (UTC)
43. Support: Would be immensely useful. Headbomb {talk / contribs / physics / books} 09:35, 18 May 2016 (UTC)