Wikipedia talk:Page mover/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Include history merge tool?

Do you think the MergeHistory tool would fit in this rights package? –xeno^talk 23:49, 15 April 2016 (UTC)

That's an interesting question – I think Admins who do that a fair amount will have to weigh in on that question... --IJBall (contribs • talk) 02:35, 16 April 2016 (UTC)

Graham87? I'm thinking my argument below against unreversible buttons probably applies. Easy to stitch together, not so easy to pull apart. –xeno^talk 23:33, 16 April 2016 (UTC)

I think it's a bad idea - much harder to clean up that kind of problem - and the more you try to tack on to this proposal the more likely it will fail - see some of my comments below where it may already be going above and beyond what I'm assuming your primary goal is - enhancing the moving of normal pages. — xaosflux ^Talk 02:47, 17 April 2016 (UTC)

Quite right, query withdrawn. –xeno^talk 02:54, 17 April 2016 (UTC) written into archive

Exact permissions this would provide

Just double checking everything to make sure I understand this. The following rights will be assigned to this group:

suppressredirect

move-subpages

tboverride

noratelimits - Update the rate limit restriction to allow more frequent pagemove actions

---

What about move-categorypages and the ability to move over a redirect (which I can't seem to find a specific right for in Special:ListGroupRights). I feel like the ability to move over a redirect is probably the most useful ability this can confer as it would eliminate the need for an admin to step in to reverse a botched move that happens all too often. --Majora (talk) 23:57, 15 April 2016 (UTC)

I added skipcatcha (oops, not needed) and noratelimits to your list. All users can already move-categorypages , but if that changed, then it could be included here instead.

As for move over redirect. All users are able to do this, but only when the redirect has only 1 revision. What happens now when trying to move a page onto an existing redirect with more than 1 revision is it triggers admins to fire off a deletion process before performing the move. And because it would let users delete more than 1 revision, but not restore (or even view what they deleted, in case they made mistake or someone queried their action), this seems problematic. But moving without redirect should be enough to vacate the location, and the unwanted material can be held somewhere pending {{db-g6}} (or repurposed to point back to the new location from another location). –xeno^talk 00:06, 16 April 2016 (UTC)

My mistake on the move-categorypages. Didn't see that in the Users section. I struck out that part of my previous comment as it is moot. I'm just thinking, the most useful move related tool in the admin toolbox is the ability to move over an otherwise locked redirect. It seems like if we are going to trust people enough to grant them this right we might as well grant them all the move related admin rights. Else it just doesn't really seem like it is worth it. Just my two cents on the matter. Especially since there is a way around this anyways with the suppressredirect right (which is essentially deleting a page anyways). --Majora (talk) 00:22, 16 April 2016 (UTC)

But that's just the deletion tool being called during a pagemove. And I don't think letting users take one-way actions they can't reverse or review isn't the best way to go about it. But if there's consensus for that I'm sure that functionality can be obtained with a phab request. My thought was that if it was completely useless revisions the page mover needed to vacate, they could move it to a temporary delete location without redirect, perform the required move, and g6 the garbage revisions. It should help alleviate backlogs in the requested move process. –xeno^talk 00:34, 16 April 2016 (UTC)

What Majora is suggesting will probably require a new userright. That's why I haven't moved on this myself before now – I couldn't figure out if the userright needed to be created first, or the package had to be approved first before the userright would be created. But it wouldn't be "full deletion" – it would be a specific userright that would allow an editor to delete a page tagged as a redirect (even those with more than one revision in the page history). (I understand that there may have been technical issues with this idea before, but that they may not be true anymore, and the creation of such a right may be technically feasible...) I agree with Majora that without this, I'm not sure this package is useful. But I also acknowledge that opposition to the proposal would increase significantly with it because of (I think mostly unfounded) worries that this could be used to pursue sneaky "backdoor deletions" (i.e. tag an article with a redirect template, and viola! a pagemover could then "delete" it). I think the solution is to set the required qualifications for this right fairly high, and to make any "abuse" of tool a potentially a blockable offense. --IJBall (contribs • talk) 02:48, 16 April 2016 (UTC)

Unfounded indeed. We already have template editor rights and editing the wrong template can really mess up an enormous amount of articles which would then be locked from fixing except from another template editor or an admin. Same basic principle in this situation. If this does happen and a new usergroup is created, the threshold for granting should be as high as template editor and misuse should be grounds for blocking. Simple really. --Majora (talk) 03:03, 16 April 2016 (UTC)

The benefit is that the page mover doesn't have to tag the page and wait around for an admin to delete it before getting on with their desired move. If they determine a particular redirect holding up a move has no useful history that can be repurposed (***and this isn't usually the case! the offending page can usually be moved to a different redirect target, and still keep the history of who created the page, etc. while it points back to whence it came*** like so [1]) then they would just move that page without a redirect to [[User:PageMoverGuy/delete]] and then tag it for deletion. –xeno^talk 03:47, 16 April 2016 (UTC)

I'll admit – I hadn't considered that scenario: doing a series of "round-robin" moves (without redirects), in order to "move" to a location with a redirect with a "no-zero" revision history. But it also strikes me that forcing Pagemovers to jump through these kinds of hoops in all scenarios like this makes it somewhat unattractive – sometimes, the redirect at the destination only has a few (not significant) revisions, and probably doesn't need to be kept. --IJBall (contribs • talk) 04:21, 16 April 2016 (UTC)

These are the same kind of moves that I would typically make fulfilling requested moves even with deletion tools at my disposal. I don't think it would be really fair for me to eliminate the attribution of this 2003 edit, for example when I fulfilled these moves. People have varying opinions of significance as far as revisions go...

That said, the vanilla 'move over 1-revision redirect' that anyone can carry out has certain limitations (has to be pointing back to the originating location). Perhaps a true 'move-over-1-revision-redirect*without restriction*' would be in order. –xeno^talk 00:01, 17 April 2016 (UTC)

Here's an example of how this package could be used during RM: [2]. –xeno^talk 00:56, 16 April 2016 (UTC)

[sigh...] I wish I could understand exactly what you did there. But it's not quite clear to me... --IJBall (contribs • talk) 02:48, 16 April 2016 (UTC)

Honestly, I can't really follow that either (probably good thing that I am not interested in this right). --Majora (talk) 03:03, 16 April 2016 (UTC)

The target page at "Ukranian Choice" was holding up a move. I moved that page without a redirect to a temporary location (just deleted the space). I then moved the desired page ("Ukraine's Choice) to the target location [again, with no redirect] and moved the offending page (UkrainianChoice) to "Ukraine's Choice" and redirected it to Ukranian Choice. (The blocking revisions can now live on under a redirect without the need for deletion.) –xeno^talk 03:33, 16 April 2016 (UTC)

Lets talk about a few of these "includes"

skipcaptcha

This was redundant - removed from list
skipcaptcha is already included in autoconfirmed - what is the point of doubling it here? — xaosflux Talk 02:14, 17 April 2016 (UTC) Oops. Removed. –xenotalk 02:48, 17 April 2016 (UTC)

noratelimit

Will update move restrictions array instead

Further information: mw:Manual:$wgRateLimits noratelimits - is there a specific reason this is needed? The rate limit applies to all kinds of editing not just page moves. — xaosflux Talk 02:20, 17 April 2016 (UTC) Wouldn't moving very many subpages trigger the rate limit? –xenotalk 02:48, 17 April 2016 (UTC) Lets get an answer if this is true or not - this would for example also allow them to create unlimited accounts. — xaosflux Talk 03:04, 17 April 2016 (UTC) Yes, if it's not needed for move-subpages, then I'm fine leaving it out. Maybe Anomie would know. –xenotalk 03:12, 17 April 2016 (UTC) Okay, so it doesn't seem to be needed for moving subpages. But it could be triggered by moving several individual pages in succession, so I've asked if it has potential to impede someone fulfilling RMs. –xenotalk 16:02, 17 April 2016 (UTC) The rate limit allows moving 8 pages per 60 seconds. So a complex RM where a bunch of pages need to be moved would require noratelimits otherwise the person fulfilling the request would have to pause after every 8 pages. Since all these actions are logged and reversible, and the barrier for entry we're going to use in granting the permission is somewhat higher, I think it's safe to include noratelimits in the package. –xenotalk 16:28, 17 April 2016 (UTC) I'm assuming we could adjust this configuration, rather than blow away all limits, by adding the new group, example: // Page moves 'move' => array( 'newbie' => array( 2, 120 ), 'user' => array( 8, 60 ), 'pagemover' => array( 100, 60 ), — xaosflux Talk 16:56, 17 April 2016 (UTC) I'm not sure (Anomie?), but I'd be fine with that as an alternative to including noratelimits. –xenotalk 17:02, 17 April 2016 (UTC) Another one to check - but I'm in support of this option, removing more opposition! — xaosflux Talk 17:05, 17 April 2016 (UTC) @Xeno: That should work. Anomie⚔ 17:51, 17 April 2016 (UTC)

tboverride

tboverride - Why does the username and title blacklist need to be overrided for page moving? — xaosflux ^Talk 02:22, 17 April 2016 (UTC)

To fulfill a move request to publish a draft page to a forbidden title. –xeno^talk 02:48, 17 April 2016 (UTC)

How likely is this scenario (e.g. what percentage of moves would require this)? — xaosflux ^Talk 03:06, 17 April 2016 (UTC)

I'm not sure the percentage, but you'll see a request at AN every so often so I assume they show up at RM too. But if we are trusting users to close and fulfill requested moves, I think we can trust them not to override the title blacklist except when prescribed by article naming guidelines. –xeno^talk 03:12, 17 April 2016 (UTC)

OK, forgive my ignorance, but what's the "title blacklist"? --IJBall (contribs • talk) 05:05, 17 April 2016 (UTC)

@IJBall: The MediaWiki:Titleblacklist is a list of article titles that are forbidden (there is also a global blacklist located at m:Title blacklist). If a user tries to make an article that matches something on either list it will be blocked and the editor will receive this warning. --Majora (talk) 06:01, 17 April 2016 (UTC)

So, I assume that if someone tries to move an article to one of the blacklisted titles, they'll receive an auto-warning message first? Because I'd hate to be in the position of moving an article to a blacklisted title, and only finding out after the fact that it was "blacklisted"! --IJBall (contribs • talk) 06:04, 17 April 2016 (UTC)

I've never actually tried it myself but as far as I know the MediaWiki software will actually block the move completely and not allow it to go through at all. There is this other warning that I am assuming displays when you try to move something to a blacklisted title (as opposed to trying to create a blacklisted title outright) but I am not really sure. --Majora (talk) 06:08, 17 April 2016 (UTC)

So I just tried this, if you move a page in to a blacklist title (and you have override permission) you do not get warned. — xaosflux ^Talk 12:39, 17 April 2016 (UTC)

It's probably preferable to have a warning. Same thing when renaming someone to a blacklisted name (no warning). –xeno^talk 17:04, 17 April 2016 (UTC)

Without tboverride the Page mover priv will work differently for Template editors than for other users. Bazj (talk) 11:53, 19 April 2016 (UTC)

There's also no warning when moving a page from a blacklisted title, a move that can only be undone by editors with tboverride. Peter James (talk) 18:48, 20 April 2016 (UTC)

markbotedits

markbotedits The only non-admin group with suppressredirect at the moment is m:Global rollback which also has markbotedits. Given the volume/speed of moves being contemplated at #noratelimit above, would markbotedits be a logical addition to the set? Bazj (talk) 11:58, 19 April 2016 (UTC)

That particular right allows you to mark rollbacked edits as bot; it wouldn't work for moving pages. All of the rights in the global rollback group are for counter-vandalism, including suppressredirect for reverting pagemove vandalism. Ajraddatz (talk) 18:52, 19 April 2016 (UTC)

Comment from uninvolved user

I think that including suppressredirect, noratelimits, and skipcaptcha in this user right is a great idea. I'm not sure about tboverride or move-subpages though. Wouldn't that have the potential for page move vandalism? Regards, epicgenius, presented by reddit.com/r/funny (talk) 01:44, 16 April 2016 (UTC)

I just saw who this proposed toolset is going to be granted to. I got it now. Shouldn't we automatically include movefile as well (i.e. integrate filemover into this set of rights)? epicgenius, presented by reddit.com/r/funny (talk) 01:50, 16 April 2016 (UTC)

Filemover is relatively esoteric (for example, I've never need to do one, really...), with a specialized editor base. I would recommend leaving it out of Pagemover rights, and as a separate userrights package. --IJBall (contribs • talk) 02:50, 16 April 2016 (UTC)

I agree, but I am not proposing that filemover be dissolved altogether. I am proposing that any pagemovers become filemovers automatically. epicgenius, presented by reddit.com/r/funny (talk) 03:00, 16 April 2016 (UTC)

Some individuals may meet the requirements that we set out in 'page mover' but not that in 'file mover'. They're somewhat different skillsets. –xeno^talk 03:34, 16 April 2016 (UTC)

@Xeno: That's a good point. But wouldn't we want pagemovers to be able to move all types of pages except MediaWiki pages? At least that's what is implied by the name. If not, maybe we should change the name of the user right to something else, like "articlemover," so people don't get confused. epicgenius, presented by reddit.com/r/funny (talk) 22:34, 16 April 2016 (UTC)

It wouldn't be just articles though. And files are not technically pages, per se. They are data that have description pages attached to them. So I think there is enough distinction here. But I'm open to other suggestions for the name. –xeno^talk 22:38, 16 April 2016 (UTC)

I suppose "page mover" will suffice. I never really understood the movefile thing though. On the surface, it looks like a regular page, but inside, it functions like a category: very little documentation, and the real contents of the file (or category) are coded elsewhere. epicgenius, presented by reddit.com/r/funny (talk) 02:07, 17 April 2016 (UTC)

Two thoughts

Two thoughts:

1. I suspect not including (real) "moveoverredirect" in this package hobbles it to the point that it's not a very useful unbundling.
2. I think the "qualifications" need to be set fairly high (the current proposal seems completely amorphous on this), esp. if "moveoverredirect" is included (as I think it should be). I don't know what the qualification level should be (5,000 edits? 6 months of active editing? etc.), but I know it should be set higher than Pending Changes, which is what it seems to be at right now.

That said, it's possible that the best "political strategy" would be to propose this without "moveoverredirect", and then possibly add that to the package at a later time, once the usual naysayers realize that creation of this user rights package doesn't lead to the place getting burned down in the meantime...

As it is, I don't think many editors will pursue this right, with or without "moveoverredirect" – my guess is that it'll number about 100. But even than number could probably lighten the load over at WP:RM. --IJBall (contribs • talk) 02:33, 16 April 2016 (UTC)

The "moveoverredirect" right doesn't appear at Special:ListGroupRights. epicgenius, presented by reddit.com/r/funny (talk) 02:46, 16 April 2016 (UTC)

Yes, it needs to be created as a "new" userright (which is why I haven't yet pursued the proposal myself, even though I've been thinking about it for about a year...). Also, let me revise my numbers – based on the fact that there are almost 400 Filemovers(!), my guess is that as many as 500 or more editors might actually be interested in Pagemove rights. (That would be pretty impressive, if true, actually...) --IJBall (contribs • talk) 02:53, 16 April 2016 (UTC)

A technical implementation of what you're looking for would basically amount to a one-way delete button [callable only during a pagemove], and the actor would have no way to review or reverse what they'd done. –xeno^talk 03:38, 16 April 2016 (UTC)

Presumably Pagemovers would, 1) check very carefully before moveoverredirect'ing any redirect to check for substantial page histories, and 2) would simply call in Admin in any case where they, i) weren't comfortable making the move themselves because of "complexities", or ii) made a mistake that needed to be undone. But the latter scenario would likely be a very, very rare occurrence. But this gets to the heart of the issue – if we can't trust veteran editors with stuff like, then we can't trust them with anything, and we should simply "rebundle" everything and leave it to the Admins. [shrug...] --IJBall (contribs • talk) 04:13, 16 April 2016 (UTC)

I needed the delete tool to delete my own one-revision redirect in one of the round-robins today [3]. So a 'moveoverredirect' that allowed the holder to delete a 1-revision redirect without the restrictions applied to this innate ability right now (I think the redirect has to point back to the incoming page?) would probably fly. –xeno^talk 00:26, 17 April 2016 (UTC)

Just a random thought if a new right should be created to make this a useful userright how about making a lost and found namespace. When a page mover with this unnamed right moves a page over page with more than one version users, the page currently at the existing page would be moved to the lost and found namespace. Pages at lost and found can only be deleted or moved back into another namespace without leaving a redirect. A list for recently added lost and found pages would allow for easy detection of abuse as well as easy recovery of mistakes. Consider a page mover with this new use right accidentally moves the pages opposite of how it was intended. With "moveoverredirect" that would be unable to undelete the page and would require admin assistance. With a lost and found section is would be easy enough for them to undo without requiring undelete. Optionally, pages in the lost and found namespace could expire overtime which would be as if the page had been deleted. PaleAqua (talk) 04:31, 16 April 2016 (UTC)

That's a pretty nifty idea. A Limbo: namespace basically. Not sure if it would fly with the dev team but I like your out-of-the-box thinking! –xeno^talk 22:00, 16 April 2016 (UTC)

Or we can use the existing Draft: namespace for such a thing. Then, the move from the temporary namespace to the article namespace will be just like articles for creation. epicgenius, presented by reddit.com/r/funny (talk) 22:32, 16 April 2016 (UTC)

Because of the "round-robin" moves thing (due to the ability to "suppressredirect"), I'm coming around to the idea of proposing this without the "moveoverredirect" option, at least to start the proposal off. Once "Pagemover" actually becomes a "thing", adding a new "moveoverredirect" useright to it can always be proposed later, if it's determined that such an addition would be a good or necessary idea... --IJBall (contribs • talk) 23:00, 16 April 2016 (UTC)

Yes, the draft namespace is quite useful as a holding bay! Much better than my earlier examples of butchering the names temporarily. Perhaps the move dialog, upon encountering a page in the way, could ask the user with the appropriate privilege set if they'd like to move the target out of the way without a redirect. Then they could draftify it for a subsequent move to take the location of the old page and close the loop (or move it to a delete bucket). –xeno^talk 00:08, 17 April 2016 (UTC)

• Moving to the draft space without redirect and then moving the article sounds like a good workaround, but I would ultimately prefer to not have further unbundling of the sysop group. No pagemover group will be about to deal with 100% of the cases that arise, and moving to the draft space can separate article histories and require admin action anyway. I worry that moving too much of the sysop rights to subordinate groups will make adminship an even bigger deal, with an even bigger threshold of "proving you need the bit" to cross. As to this proposal in particular, it looks fine. All of the suggested rights included look ok, and I can't think of anything else that could be reasonably added to it. Ajraddatz (talk) 22:48, 17 April 2016 (UTC)

I'm not going to belabor the point, but with nobody wanting to run for Admin (and there are multiple reasons for this...), proposals like Xeno's are maybe the only things that are going to keep the lights on. (The backlogs at WP:RM have gotten especially bad lately, and this modest proposal may be the only thing that can help us deal with that.) YMMV... --IJBall (contribs • talk) 23:26, 17 April 2016 (UTC)

Yeah, I understand that. I just feel like ignoring the underlying problem (whatever that may be) won't make it go away. Ajraddatz (talk) 04:14, 18 April 2016 (UTC)

Comments

I'm in favor of this group having: suppressredirect, move-subpages. Throwing more and more flags in need to be carefully considered; focus should be on the 95% use case — xaosflux ^Talk 02:28, 17 April 2016 (UTC)

Adding support for increasing the page move ratelimit for members of this group. — xaosflux ^Talk 03:44, 18 April 2016 (UTC)

I'm not exactly sure what the primary driver for this is - but by not adding more and more rights, the bar to entry won't need to be as high. — xaosflux ^Talk 03:07, 17 April 2016 (UTC)

Basically to support non-admin closers at requested moves. This still requires some degree of trust and competence so I don't think the bar for entry should be too low. –xeno^talk 03:19, 17 April 2016 (UTC)

I'd still advise setting the "bar" for this pretty high – definitely higher than Rollback, for example. I think this should be a right only given to truly experienced editors. It's akin to File Mover, but not as "high bar" as, say, Template Editor, IMO. --IJBall (contribs • talk) 05:08, 17 April 2016 (UTC)

Agree - depending on options - for just suppressredirect/move-subpages structuring it around filemover is a good start - if it will be a backdoor to highspeed editing/deleting (see convo above)/account creator access/blacklist overrider - that pushes it much higher. — xaosflux ^Talk 13:27, 17 April 2016 (UTC)

I also agree with setting a high restriction for page movers. There will probably be more page movers than there are filemovers (because most files are on Commons), but overriding the title blacklist should be granted only to highly trusted users. Otherwise, we would have "epic fail" and "derp" as the titles of pages all over Wikipedia. epicgenius: unlimited epicness (talk) 19:50, 17 April 2016 (UTC)

I think having a good set of criteria will is likely a must if this is to succeed an RfC, but not only for granting but for revoking the right in the case of abuse. Consider the template editor it has both guidelines for granting, and revoking. PaleAqua (talk) 06:34, 18 April 2016 (UTC)

Good idea. Here are some criteria I think we should consider for granting: (1) No move wars within the past 6 months; (2) No unreversed blocks within the past 6 months; (3) Significant experience in RM and/or a number of moves that is above a certain threshold (say, 100 moves per month or 5,000 moves total). As for revoking: (1) Move-warring against consensus; (2) Abusing suppressredirect to create an undesirable or non-consensus page title. epicgenius: unlimited epicness (talk) 21:26, 18 April 2016 (UTC)

May I suggest some move protection for this page? The vandal-magnet level of moving the Page mover page seems high. Bazj (talk) 04:08, 17 April 2016 (UTC)

Extended confirmed

See xaosflux's comment above about limiting the group to suppressredirect and move-subpages; if that's the case, what do people think about just adding these rights to the extended confirmed group? In my opinion this is a reasonable bar for these rights. Kharkiv07 (T) 00:08, 18 April 2016 (UTC)

Extendedconfirmed is granted automatically, so any quick checkpoint to ensure competence would be skipped - I think that a quick check over by an admin before granting these permissions is a good thing. I also want to avoid policy creep; the extendedconfirmed group is for an arbcom protection level, and while I agree that numerically it might suggest that a user is competent enough to move pages properly, that wasn't the intention of the group. And of course, the usual concerns I have with any unbundling raising the barrier to adminship even more applies. Ajraddatz (talk) 00:59, 18 April 2016 (UTC)

(edit conflict) Move-subpages maybe. Definitively not suppressredirect. Suppressredirect is a semi-powerful tool that can lead to backdoor deletion of articles. Move article from mainspace to userspace, don't leave redirect. Request U1 deletion. If the patrolling admin doesn't notice that it was moved and deletes it that could be a large problem. Redirects left behind after moves are a good thing 99.999% of the time. Allowing people to suppress them just because they happen to hit 30/500 is a bad idea. Especially considering how many people who are extendedconfirmed but still have no idea what they are doing. --Majora (talk) 01:03, 18 April 2016 (UTC)

I wouldn't go anywhere near calling 'suppressredirect' powerful. It's a minor technical addition, and little more "powerful" than the ability to move pages already is. Actions are still logged, and the so-called "deleted" page still has links to where it ended up, just in the form of a "this page has been deleted" message rather than a redirect. For what it's worth, I've seen multiple people calling innocuous rights like this powerful, so it's nothing personal about your comment - I agree with your general sentiment that not every extendedconfirmed user necessarily has the competence to use this right properly. I just want to move away from the "abuse mentality" of assuming that every right will be abused if we give it to a wider group of users. If that was the case, this encyclopedia built on anyone being able to edit would be in a lot of trouble. Rather, we should look at the likelihood of people using the rights as intended (i.e. with clue) IMO. Ajraddatz (talk) 01:28, 18 April 2016 (UTC)

Fair enough. I just don't think we should be doling out additional rights just because someone hits an arbitrary level set by ArbCom. Abuse potential or not. Everyone can still edit without the suppressredirect right. So our founding principle is not impeded by being cautious with additional rights. --Majora (talk) 01:37, 18 April 2016 (UTC)

Yeah, I wouldn't even be in favor of doling out 'Pending Changes Reviewer' to the 'extendedconfirmed' group. 'Page mover' rights, as I allude to above, are significantly more powerful than that – if we're going to keep a lid on and demand some skills before handing out 'Rollbacker', we definitely need to have higher standards for 'Page mover'. That said, if 'Page mover' ever goes "live", it might not be a bad idea to advertise it to our more veteran editors in case they want might want to apply for it (note: I haven't thought about the details about exactly who should be notified – just throwing the idea out there...). --IJBall (contribs • talk) 02:40, 18 April 2016 (UTC)

I think Extended confirmed (maybe even autoconfirmed) should be allowed to move pages out of User-space and Draft-space without leaving a redirect – just those two namespaces. It's just a matter of housekeeping. There is still an audit trail, that even non-admins can follow if they like. The "Leave a redirect behind" might even be left not-checked by default, when initiating a move in these two namespaces. wbm1058 (talk) 15:28, 18 April 2016 (UTC)

Maybe Wikipedia talk space too (for these few AFC submissions that start with Wikipedia talk:Articles for creation/.... epicgenius: unlimited epicness (talk) 21:29, 18 April 2016 (UTC)

Where do I sign?

Not looking on the technical side of it, this is a beautiful idea. I can't attest to the fact that I have a perfect move log but I'd say, only 1 of them were called out till date. *gloats* --QEDK (T ☕ C) 16:51, 18 April 2016 (UTC)

Sign on the dotted lines below! –xeno^talk 00:45, 19 April 2016 (UTC)

And so, I have. --QEDK (T ☕ C) 09:42, 19 April 2016 (UTC)

Made an icon

File:Page mover icon.svg Decent only. I can't seem to be able to work with the main logo, so please overwrite this. --QEDK (T ☕ C) 16:53, 19 April 2016 (UTC)

Should the same arrow from the file mover and importer icons be used? Also, the file should probably be called "File:Wikipedia file mover.svg" to be consistent with the other permission icons. KSFT^C 20:39, 25 April 2016 (UTC)

Meh, I did some shoddy work on it. I will get it renamed, though, I am too lazy to work with Inkscape again. Funny thing is I tried to find the goddamn arrow, I couldn't. Also, I'd probably extract the arrow from the .svg but it's apparently invalid. --QEDK (T ☕ C) 06:11, 26 April 2016 (UTC)

• I had similar a similar thought to the one KSFT expressed, but in regard to the tree picture being the same as the file mover topicon.—Godsy^(TALK_CONT) 06:39, 26 April 2016 (UTC)

They're a part of the same icon set, so it's the same picture. --QEDK (T ☕ C) 06:43, 26 April 2016 (UTC)

• Helpful guy at Commons fixed it. --QEDK (T ☕ C) 13:25, 30 April 2016 (UTC)

  @QEDK: Should the File mover icon perhaps have the Wikipedia icon in the background, as File:Wikipedia File mover.svg does? --IJBall (contribs • talk) 15:38, 30 April 2016 (UTC)

  @IJBall: The one you're talking about is here. --QEDK (T ☕ C) 16:25, 30 April 2016 (UTC)

  Oh, nice! Me like-y. --IJBall (contribs • talk) 16:26, 30 April 2016 (UTC)

  Glad. (tbh, I like it too ;) --QEDK (T ☕ C) 16:45, 30 April 2016 (UTC)

Meesa think it's beautiful Annie! --TJH2018talk 19:57, 9 May 2016 (UTC)

An additional idea - allow leftover redirects to be Autopatrolled if the editor does not have the Autopatrolled user right

I have an additional idea of what to grant this new proposed group. I tend to do a lot of page moves, and lately, I have realized that some of the editors who patrol new pages have been approaching me on my talk page regarding redirect that I "create" as a result of a page move and erroneously thought that I created the redirect myself. Well, yes, I did technically since I moved the contents elsewhere, but I was not the one who originally created anything at the title of the original redirect. The leftover redirects are considered "page creations" that need to be patrolled. Well, since I do not have the autopatrolled user right (and don't even come close to qualifying for it, even though I have over 60,000 edits), the redirects left over from my page moves need to all be patrolled. So, I wonder if there is a way to allow this group to have the redirects created by page moves be autopatrolled if they do not have the "autopatrolled" user right? Steel1943 (talk) 20:17, 19 April 2016 (UTC)

I don't think that per-action automatic patrolling is currently possible with the software, but I'll look into it some more. If you are creating a lot of redirects and seem to know how to make articles that aren't immediately deleted, then I don't see why being added to the autopatrolled group would be an issue (just my opinion ofc). Ajraddatz (talk) 20:36, 19 April 2016 (UTC)

@Ajraddatz: To use myself as an example, I have created a large amount of disambiguation pages and redirects, but only 5 or 6 articles. Even with the article creation requirement being lowered from 50 to 25 recently, I still don't qualify. Steel1943 (talk) 20:43, 19 April 2016 (UTC)

Yeah, I just wonder if the requirements for the right could be reduced for those who are making many new pages in general, even if they aren't all content articles (as in your case). Probably a debate for another page/day though. Ajraddatz (talk) 21:38, 19 April 2016 (UTC)

Doesn't the WP:NPP tool ignore redirects anyway? Redirects can be patrolled, but they're usually not. Ivanvector 🍁 (talk) 21:46, 19 April 2016 (UTC)

Yeah... but with one click on Special:Newpages, you can see recently created redirects. epicgenius: unlimited epicness (talk) 16:39, 20 April 2016 (UTC)

I do believe "hide redirects" is also the default there - you have to purposefully go looking for redirects. — xaosflux ^Talk 16:48, 20 April 2016 (UTC)

That is actually a decent idea. Why can't we add "pagemover" to "autopatrolled" (for redirects only) automatically? epicgenius: unlimited epicness (talk) 16:39, 20 April 2016 (UTC)

This is a good idea, but I don't see why it should be limited to some class of users. Shouldn't every move that creates a redirect automatically be marked patrolled if and only if the page was marked patrolled before the move? Wnt (talk) 16:29, 21 April 2016 (UTC)

I'd make it automatic. We already have autopatrolled userright, this proposal requires more responsibility and it should be automatically bundled. Arguably, someone should have already been granted autopatroller before applying for this. Montanabw^(talk) 23:13, 27 April 2016 (UTC)

The level of trust is higher but in a different direction. Trust for page movers would be based on being able to navigate moving policy and correctly close move discussions. Trust for autopatrolled is based on reliably creating acceptable new articles. I can easily imagine someone achieving the first but not the second. Happy Squirrel (talk) 03:02, 3 May 2016 (UTC)

Introduced a few changes

I stole it off WP:TPE. If you agree or have better ideas, do say. --QEDK (T ☕ C) 18:19, 21 April 2016 (UTC)

RFC - Proposed: "Page mover" permission to be created

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Tracked in Phabricator
Task T133981

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)

Discussion

Summary of results (as of 02:19, 18 May 2016 (UTC))
Question	Support	Oppose	% support	Result
Creation of permission	97	8	92.4	Approved
Suppressredirect	75	12	86.2	Approved
Move-subpages	65	2	97	Approved
Title blacklist override	39	36	52	Denied
Pagemove throttle limit increase	31	21	59.6	Denied
Move protection	43	22	66.2	Denied

• 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)

---

Discussion: Creation of permission

• 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)

Support: Creation of permission

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)

Oppose: Creation of permission

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)

---

Discussion: Suppressredirect

• 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)

Support: Suppressredirect

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)

Oppose: Suppressredirect

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)

Discussion: Move-subpages

Support: Move-subpages

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)

Oppose: Move-subpages

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)

Discussion: Title blacklist override

• 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.

Support: Title blacklist override

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)

Oppose: Title blacklist override

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)

Discussion: Pagemove throttle limit increase

• 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)

Support: Pagemove throttle limit increase

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)

Oppose: Pagemove throttle limit increase

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)

---

Discussion: Allow moving of move-protected pages

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)

Support: Allow moving of move-protected pages

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)

Oppose: Allow moving of move-protected pages

1. Oppose until the details are more defined, RfC creep. — xaosflux ^Talk 15:36, 22 April 2016 (UTC)

   Continued oppose - I'm against creating entire new protection levels and everything that goes with it to support this. Are templates "pages" - should template editor get to move these, or should they not? Should page movers get to move templates that are template protected - I'd think not? Does anyone have any statistics on how often move maintenance is required on admin-protected pages? — xaosflux ^Talk 23:38, 22 April 2016 (UTC)

2. Oppose - as I've said above, it's the same user right for editing and moving protected pages. Until that changes, there's assumedly a reason why users without the sysop bit can't edit fully protected pages. Ajraddatz (talk) 17:19, 22 April 2016 (UTC)

   Oppose( Moving to conditional support) (at this time)—While I think something like this could make sense with page mover, I must oppose for now. I think this needs to be better defined and how it would be implemented needs to be figured out before I could support. Probably better to figure out the details and come back with a future RfC on this. PaleAqua (talk) 00:07, 23 April 2016 (UTC)

   • Regarding the suggestion of a new protection level similar to what was done for template editors, I do not believe such an approach is workable in this case. One of the biggest on many differences I see is that balance of extra work this would create vs. the template editor solution. For a template it just takes one time change of permission vs. many future edits to the template while for page protection the number of future page moves is likely to be few so the cost of changing permission on the page so that a page mover can move it is high compared to how often it will be moved. The complexities relations to edit protected also are concerning and need to be fully addressed. Page movers should not be able to edit pages pass protection that they wouldn't be able to otherwise without having much stronger criteria. What happens for example with office protected pages? Can this become a back-door way to protect / unprotect pages if it is implemented this way. How would pages be switched to the new move protection level—on demand, automatically, etc.? While I agree being able to move protected pages is desirable for page movers I'm still not convinced we have a good way of implementing this. PaleAqua (talk) 19:50, 4 May 2016 (UTC)
3. Weak oppose I can see the benefit, but I would like it to be more defined. Xaosflux's questions about interactions with template editor are of concern. I feel like discussion of changing page protection levels should take place after this/somewhere else to come up with better ideas and discussion. Wugapodes (talk) 20:21, 24 April 2016 (UTC)

   Oppose per above. Rubbish computer (HALP!: I dropped the bass?) 08:32, 25 April 2016 (UTC)

   • @Rubbish computer: You've listed yourself in both the support and oppose sections on this one.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:47, 25 April 2016 (UTC)

   @SMcCandlish: Sorry about that, I hadn't yet had my coffee. --Rubbish computer (HALP!: I dropped the bass?) 17:33, 25 April 2016 (UTC)

4. Oppose - There is no need. Requests of this nature can be easily handled by an administrator (better to leave contentious titles which warranted protection for some reason to them anyway), as the current rate of occurrence is low.—Godsy^(TALK_CONT) 02:12, 26 April 2016 (UTC)

   Oppose. If a discussion/topic is so contentious that it has led to a page being move-protected, probably best to let an admin deal with it. Not only are the most contentious discussions usually closed by admins, but also there may be a need for blocks. ~ Rob^Talk 02:33, 26 April 2016 (UTC) (changed my mind on this one; moving to support)

5. Oppose Certainly one step too far. Johnbod (talk) 12:04, 26 April 2016 (UTC)
6. Oppose There are enough sysops to handle with these type of requests. No need for additional. FiendYT ★ 04:02, 27 April 2016 (UTC)

   Oppose per comments by Xaosflux. We might be getting into dicey rights issues with the file mover right for this part of the proposal. See discussion section for this proposal above. — Andy W. (talk · ctb) 03:16, 3 May 2016 (UTC) After a ton of discussion and thought, I've become indifferent, can you believe it. Striking out my oppose, but I'm not voting in support. I still think protection is intricate, and there are a lot of ways in which the implementation can go wrong, but I'm sure that devs can figure something out if we have a lot of support votes here who genuinely think this aspect is worth it. I do hope then that protection behavior will be well thought-out and specified before it is completely rolled out. — Andy W. (talk · ctb) 15:15, 13 May 2016 (UTC)

7. Oppose - again, leave to admins. If we have a problem with too many RMs that fall under this, maybe we need more admins? I don't see such a problem demonstrated however. Would consider changing vote if someone could show me the need for this. EvergreenFir (talk) Please {{re}} 03:53, 3 May 2016 (UTC)
8. Oppose. If one needs to be an admin to impose move protection, then one should be an admin in order to lift it. --Tryptofish (talk) 22:16, 3 May 2016 (UTC)

   Note that the move protection is also moved along with the page begin moved. So it's more accurate to say that this allows pagemovers to ignore the protection, not to actually lift it. —Ruud 09:38, 4 May 2016 (UTC)

   It seems to me that moving a page effectively moves the content that presented a reason for an admin to make a decision that it needed to be move-protected. For a non-admin to be able to ignore that is to lift that protection for that non-admin. If a page were, instead, full-protected or semi-protected, we would want only an admin to be able to lift the full or semi protection. --Tryptofish (talk) 17:20, 4 May 2016 (UTC)

9. I support in theory as part-in-parcel with the function of the usergroup. However I oppose giving them the editprotected right which, currently, is the only way to do this as that would also allow them to edit fully protected pages. I'd also only support giving them the ability to override move protection if there were strict conditions on when it can be granted (stricter than what is currently being proposed/discussed). If there's consensus in favour (and when it can be done is decided on, probably only with community consensus) a phabricator ticket can be submitted to see if the divs can split editprotected into a permission for moving protected pages. Callanecc (talk • contribs • logs) 12:35, 4 May 2016 (UTC)
10. Oppose Admin actions should only be overwritten by other admins, therefore only admins should be able to reverse move protection. Joseph2302 (talk) 16:15, 4 May 2016 (UTC)
11. Oppose This could be ripe for abuse, as editors who have gone AWOL could totally trash the project. TJH2018talk 21:36, 5 May 2016 (UTC)
12. Oppose: there are people I would trust with suppressredirect, knowing they would never have the malicious intent to abuse it, but would not trust to overrule a page an admin has locked to a certain title, as edit wars create a bit of anger which could cloud their judgement. — Bilorv_(talk)^(c)(e) 22:15, 5 May 2016 (UTC)
13. Oppose per Callanecc. Mkdw^talk 14:21, 6 May 2016 (UTC)
14. Oppose BMK (talk) 18:31, 7 May 2016 (UTC)
15. Oppose - We should enforce unwritten and written moratoriums on article titles. Giving users a permitted rights to change titles of move-protected pages would not make auto-confirmed editors more trustworthy than they are. George Ho (talk) 22:03, 7 May 2016 (UTC)
16. Oppose, would prefer this is only done by sysops. Nakon 03:11, 9 May 2016 (UTC)
17. Oppose - If you move a move-protected page, it ends up being move-protected under a title no admin (or anyone) ever asked or intended for it to be move protected under. And you can't fix that without an admin, at which point it saves time to just have the admin do the move. It's a nice idea, but it doesn't actually pan out. A2soup (talk) 12:50, 9 May 2016 (UTC)
18. Oppose. This would be difficult to implement, so I'd need more info on how exactly this will be accomplished before I can decide permanently. There's a lot of risk associated with this, especially since page-move vandalism, though not very common, is an extreme pain to understand and clean up. If an account gets compromised, this would be a huge problem, and frankly, I'd like to not have such a basic rights as redirect suppression tied to as strict of a criteria as template editor currently has. –Compassionate727 ^(T·C) 19:13, 10 May 2016 (UTC)
19. No way! What is move protection for if it can be moved by non-admins? --Pokéfan95 (talk) 06:24, 17 May 2016 (UTC)
20. Oppose, too many risks. Stephen 23:20, 17 May 2016 (UTC)
21. No need demonstrated. Ruslik_Zero 12:45, 18 May 2016 (UTC)
22. Oppose, this is best left to admins within their responsibilities. Gmcbjames (talk) 18:28, 18 May 2016 (UTC)

---

Discussion - Include MergeHistory tool

Moved out of the RFC as this section was started on 16 May in an RfC scheduled to close on 19 May, see Include the MergeHistory tool below. 103.6.159.89 (talk) 14:08, 16 May 2016 (UTC)

Guideline for granting of the right

Further information: Wikipedia:Page_mover § Guidelines_for_granting

What should be the general guideline standard for granting of the right, specifically how many edits, months or editing, and page moves should applicants have?

Discussion: Guideline for granting of the right

• As per above: I believe it should be "6 months of active editing" and "demonstrated experience with page moves (or WP:RM)". I don't think we need anything else. Meanwhile the "Removal of this right" section looks about right, though removing the right after being "inactive for the period of a year" would be unique to this usergroup I believe and is likely to be controversial. --IJBall (contribs • talk) 02:28, 19 April 2016 (UTC)

  see also Wikipedia:Template_editor#Criteria_for_revocation, though this is not as "powerful" - and like any other time-based removal re-requests are normally swiftly handled. — xaosflux ^Talk 02:35, 19 April 2016 (UTC)

  FTR, I support removal of all "extra" userights after 1 year of inactivity (even Pending Changes Reviewer). I was just noting that including that here is fairly unique (outside of Template Editor, apparently – and I don't think Page Movers qualifications should be set as high as Template Editor's...). --IJBall (contribs • talk) 02:48, 19 April 2016 (UTC)

  So at the link above, I'd kill #2 and #3 (#5 and #6 are currently empty), and change #1 from "The editor should be a registered Wikipedia user for at least 6 months." to "The editor should be an active editor of [English] Wikipedia for at least 6 months." Then I'd add "The editor should demonstrate experience with moving pages, or demonstrate experience at WP:RM." --IJBall (contribs • talk) 02:55, 19 April 2016 (UTC)

• Comment I think that the guidelines for granting the right should be around the same level as file mover. So obviously sufficient experience with Wikipedia, possibly at least a few months editing would be needed. In addition, they should show some need for the right. Most likely through work at requested moves, or just generally experience with moving pages. Omni Flames ^{let's talk about it} 02:40, 19 April 2016 (UTC)
• Query – is there any tool that can assess WP:RM participation like AfD stats currently does for AfD? Something like this would make it easier for Admins to assess whether to grant the new Page Mover right to requestees (as well as making it easier for editors to assess their own WP:RM participation). For instance, I know I've voted in a number of !votes at WP:RM, but I currently really have no way to assess even how many I've participated in... --IJBall (contribs • talk) 03:01, 19 April 2016 (UTC)

  IJBall, it should be possible to create a tool that merely displays the talk pages a user has edited (and probably even the "requested move" sections on talk pages), but having looked through a few requests, there's no format of the sort that the AfD Stats tool exploits. It would probably be much easier to simply look at a user's number of Talk-namespace edits and a sample of said edits as a substitute for quantifying and examining WP:RM activity, respectively. APerson (talk!) 03:24, 19 April 2016 (UTC)

  @APerson: I know pretty much nothing about bots, but shouldn't it be possible to have a bot scan through a user's Talk page edits, look within for Talk pages with the RM template, and then look for support and oppose votes under the found Talk page topics? Even if the last part isn't possible, a bot that could scan for the number of RM discussions an editor had participated in (and list them?) would probably be useful. --IJBall (contribs • talk) 03:31, 19 April 2016 (UTC)

  D'oh. I obviously didn't check enough RM discussions to notice that they were conducted with bolded !votes. It would be pretty easy to make a tool that functions in the way you describe. I'll try to make some time to hack together a prototype, but to anyone else who is interested, I put the AfD Stats source code up on GitHub last year, so maybe you could use that for inspiration. APerson (talk!) 03:45, 19 April 2016 (UTC)

  IJBall, Many of the permission request pages are already clerked by MusikAnimal's MusikBot. Bazj (talk) 11:45, 19 April 2016 (UTC)

  Point taken. But that won't help me when I want to look up my own "move" stats!... --IJBall (contribs • talk) 02:35, 21 April 2016 (UTC)

  IJBall, after a bit of hacking, I conjured up https://tools.wmflabs.org/rm-stats. I didn't include the "voting matrix" AfD Stats has, but I can put a quick one in upon request. APerson (talk!) 02:42, 11 May 2016 (UTC)

• I don't think we need to require a specific number of edits. For number of moves criteria, I'd rather see that focused on involvement RM and MR discussions. In regards to strictness I think it's probably best to start slightly tight with any new right and loosen up overtime. Especially deletion related permissions have been talked about and might be considered in the future. I still like the limbo namespace idea, even if redirect suppressed moves to draft are mostly equivalent. PaleAqua (talk) 03:16, 19 April 2016 (UTC)

  As to the guidelines for removal, like they guidelines for granting they are applied though the judgment of an admin. As such I don't think we need to give the additional leeway of requiring a pattern of behavior. The right should be removable with a single case of extremely bad judgement. For example to say "The editor used the permission to gain the upper hand in disputes" means we effectively allow a page move a free one time use "I Win" card and like a pinball machine might require a few more tilts before it is noticed if spaced far enough part. Stating "The editor used the permission to gain the upper hand in a dispute" doesn't mean that a page mover will automatically use the right for a single mistake especially given that "The user right can be revoked..." is not "The user right must be revoked..." PaleAqua (talk) 16:27, 25 April 2016 (UTC)

• Atleast 1 year of experience on-wiki, must not have requested the right within one month, decent move log (and RM experience definitely), no admin complaints, no recent blocks or any big fuss over improper moves. Revocation should be the same as TE revocation guidelines. --QEDK (T ☕ C) 09:36, 19 April 2016 (UTC)
• Similar to TE, I think. QEDK is a bit strict, but I'd go with something to the effect of 6 months experience, sufficient RM experience (including non-admin closures), no recent block history (last year), no history of edit-warring/move-warring, and a demonstrated understanding of policies/guidelines surrounding moves. I don't think it's fair to require zero admin complaints and/or improper moves. Everyone gets it wrong sometimes, and I wouldn't let a single instance hold back the right. A pattern of problems is another story, of course. ~ Rob^Talk 16:58, 20 April 2016 (UTC)

Admin complaints as in, at PERM and they'd obviously be reasonable opposes. --QEDK (T ☕ C) 19:27, 20 April 2016 (UTC)

• Similar to TE if it includes tboverride, lower if not included. Bazj (talk) 17:07, 20 April 2016 (UTC)
• QEDK has the right idea. I agree with all of his points, especially the requirement for a decent move log. APerson (talk!) 17:14, 20 April 2016 (UTC)
• I will repeat a comment that I made on this page earlier: (1) No move wars within the past 6 months; (2) No unreversed blocks within the past 6 months; (3) Significant experience in RM and/or a number of moves that is above a certain threshold (say, 100 moves per month or 5,000 moves total). As for revoking: (1) Move-warring against consensus; (2) Abusing suppressredirect to create an undesirable or non-consensus page title. It should be stricter than rollback, but not as strict as Template Editor. Also, I think that a relatively clean move log should be a minimum requirement for page mover rights (not necessarily 100 RM participation in a month or anything like that). epicgenius: unlimited epicness (talk) 20:57, 20 April 2016 (UTC)

I don't know who are you kidding but even admins don't have 5000 moves. --QEDK (T ☕ C) 21:21, 20 April 2016 (UTC)

5,000 moves total is pretty high, but people have done it. If you have 5,000 moves, you are obviously automatically eligible for page mover. I say that 500 moves should put you for consideration. epicgenius: unlimited epicness (talk) 01:01, 21 April 2016 (UTC)

500 is still too high – I've done what I consider to be a relatively large number of page moves (I'd bet I'm in the Top 5%, at least the Top 10%, of editors doing page moves), and according to XTools, I still have only 231. Again, I wouldn't put a specific number on it, but I'd bet once you've gotten to 50 or more page moves on your own (i.e. not including NAC closings at WP:RM), you're probably to the point where an Admin should at least look deeper (e.g. WP:RM participation) to determine whether you qualify for this right... --IJBall (contribs • talk) 02:31, 21 April 2016 (UTC)

OK, but then the number of page moves that one must make to qualify for page mover will fluctuate a lot. I think I am in the top 10% too, but only because most people don't make page moves. I estimate that I moved over a thousand pages, and also participated in lots of RMs, so maybe I would qualify, or maybe not. epicgenius: unlimited epicness (talk) 00:21, 22 April 2016 (UTC)

Like I said, rather than tying this to an actual "hard number" 'move count' requirement, I'd rather we left it to Admins to use their judgement as to whether they think an applicant has the requisite experience and good judgement to perform page moves properly – that can come from numbers (and types) of page moves, WP:RM participation, or a combination of both. --IJBall (contribs • talk) 16:10, 22 April 2016 (UTC)

Nothing except autopatrolled is given on the basis of a hard count. An admin always uses his discretion. Hard counts are simply thresholds, a thumbrule to keep in mind. --QEDK (T ☕ C) 11:43, 24 April 2016 (UTC)

 Comment: from an uninvolved editor: If the criteria for the number of page moves is excessive, it might deter folks genuinely aware of guidelines from submitting requests. In my own tenure on Wikipedia (I started in 2005), it looks like I've only performed about 20 moves (not counting talks). Obviously this right is not for me, but I'm just saying how I feel that 60 moves for a 6-month-old account is even perhaps still excessive. Are Wikipedia pages really that badly named?  — Andy W. (talk · contrib) 08:06, 26 April 2016 (UTC)

• I suggest 9 months of active editing, some significant content expansion to ensure that an applicant understands the basic principles of Wikipedia, 30 requested move closures (definitely possible), and no reasons not to grant the right. Esquivalience ^t 22:46, 20 April 2016 (UTC)

Why do they have to be "requested" moves? – Plenty of us do uncontroversial page moves on our own without going through WP:RM (though I've done plenty through RM too...). I think you just needed to have demonstrated that you know what you're doing with page moves, and aren't violating policies or guidelines (except relatively infrequent mistakes...) with page moves. --IJBall (contribs • talk) 02:31, 21 April 2016 (UTC)

Right. What we want to see in varied and non-abusing participation in move-related processes, which might be manual moves, participating sanely in RM discussions, non-admin closures of RM discussions, listing things for non-controversial "speedy" RM, even other kinds of moves, e.g. at WP:CFD, or frequent participation at WT:AT, or something indicating they know what they are doing.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:14, 3 May 2016 (UTC)

Question: could the user right be requested by editors who are not actively involved in RM but nevertheless have plenty of experience with moving pages? For example, although I'm not active at RM, I have multiple times moved pages, usually either because the article subject is better known under another name, or because the original title is a typo. Narutolovehinata5 ^tccsdnew 16:05, 21 April 2016 (UTC)

The way the WP:Page mover proposal is written now, the answer seems to be yes, and I agree that granting this right shouldn't be predicated on just WP:RM participation – it should just require that editors have experience moving pages, and have done so sensibly. --IJBall (contribs • talk) 16:42, 21 April 2016 (UTC)

• Per my comments below, I think this right should also be granted to non-admins who have experience closing CFD discussions involving renames and merges. CFD is arguably more backlogged than RM, and allowing non-admins to suppress the creation of redirects while renaming categories would save the need for many G6 requests. SSTflyer 09:58, 22 April 2016 (UTC)
• In addition to experience moving pages, users with the right should probably also have experience closing discussions, as those two things likely go hand-in-hand. Users with the right are likely to be moving pages as the result of a discussion. Ivanvector 🍁 (talk) 17:26, 22 April 2016 (UTC)
• 1 year active, 10,000 edits, and demonstrated experience (the bulk of it not reeking of dispute) in direct and full-RM page moving. There must also be a lack of "negative experience" in recent memory: No move bans, admin/ANI warnings for movewarring, or other move-abuse disciplinary actions within that year. I have a concern about "RM campaigners", but I'm not sure how to address it with a criterion. I can think of at least half a dozen "title warriors" who are very tendentious (usually about annoying trivia like inserting a comma before "Jr." even though MOS:JR says not to, or capitalizing things that MOS:CAPS says not to), and am sure they will make a bee-line to get this "power" so they can use it to bypass normal RM process and force their way. There needs to be an approval process that either lets people oppose/support candidates for this userright, or at least admins granting this userright thoroughly reviewing a candidate's RM history for red-flags like tendentious, anti-consensus campaigning, or failure to properly understand WP:AT policy, WP:MOS, and the naming conventions guidelines. You'd be surprised how many long-term editors just really do not understand this stuff but are convinced they do and act aggressively on that righteous conviction. (The most frequent failure: belief that WP:COMMONNAME is the most important of the WP:CRITERIA – it's not one of the CRITERIA at all, but a default to check first to see if it fits the criteria. Second most frequent: the false belief that COMMONNAME is a style policy and has anything to do with style matters like capitalization and punctuation. Third: belief that WP:PARENDIS is preferred over WP:NATURALDIS, when the opposite is the actual case. Fourth: belief that every title must be as short as possible, i.e. that WP:CONCISE just means short number of characters, and trumps other criteria like WP:RECOGNIZABLE, WP:PRECISE and WP:NATURAL. Fifth: belief that disambiguation, even NATURALDIS, cannot be used for WP:PRECISION purposes, only when two articles are vying for the same title. Sixth: That a title cannot be used if it is technically a misnomer or non-neutral even if it is the overwhelmingly most common name.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
  • I strongly disagree with using an RfA style community approval vote for this right. Note that template editor which is a more powerful right doesn't require such. Something similar was considered during the drafting of the TE proposal and again during voting. Such a vote turns this more into a junior admin right and increases the likelihood that these rights would be consider required stepping stones for RfA. That is exactly the wrong direction. I also worry that it would paradoxically makes the right harder to remove. The right needs to have a strong criteria, the admin granting the right needs to be responsible for their judgement and abuse of the right needs to be dealt with correctly. This has worked well with TE in the past including cases where that right was removed for violating criteria. The criteria being consider for this right already cover the concerns about the types of misuse you talk about, mostly covered by "The editor used the permission to gain the upper hand in disputes" ( I do think that needs to be "in a dispute" vs "in disputes" btw ). PaleAqua (talk) 07:52, 25 April 2016 (UTC)

Fair enough. As long as the criteria for granting and for use are tight, this should cover the concerns I have.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:48, 25 April 2016 (UTC)

This is a bit of a rant, one which I happen to agree with, but you lost me at having a community process to support/oppose a candidate. That's an RfA, and if we're going to make candidates for pagemover pass something like an RfA, they might as well just run the RfA gauntlet and try for the mop, and then this userright is moot. I share your concerns, and I'm sure we can all think of a couple editors who probably should never get this right, but I also have difficulty coming up with a criterion. "No history of tendentious move discussion" comes to mind, but how do you define that? Ivanvector 🍁 (talk) 20:11, 29 April 2016 (UTC)

Repeat: "As long as the criteria for granting and for use are tight, this should cover the concerns I have." And it's not a rant, it's a list of several specific things that are already problematic, and which incautious granting of this userright would make notably more problematic.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:14, 3 May 2016 (UTC)

• 1 year of editing and 10,000 edits per QEDK. I don't have a lot of faith in this unbundling primarily because of ne'er do wells relishing an opportunity to force their interpretation of conventions. There's no reason we should let new-ish editors into this fray, as well. Chris Troutman (talk) 17:22, 25 April 2016 (UTC)
• 50 page moves and sign of intent to productively use the right as a rule of thumb, but most importantly, IAR if necessary. — Bilorv_(talk)^(c)(e) 22:15, 5 May 2016 (UTC)
• I'd say a minimum of 1 year and 10,000 edits. No minimum number of page moves, that would inspire disruptive behavior, we have too many stupid RM fights as it is. Maybe something like X months of doing non-admin closures at RM and a minimum number of those (maybe 5 or 10, again not so many to inspire gaming the system, but enough to show evidence of judgement). No quasi-RfA process, this should be a userright granted outside of a popularity contest. I'd suggest a clean or at least relatively clean block record. Montanabw^(talk) 04:05, 9 May 2016 (UTC)
• 6 months active editor, 1'000 edits including 25 moves or move requests (low threshold here to demonstrate genuine need to be a page mover but easy enough to reach without inviting abuse), no evidence of bad-faith move-warring, clean block log. — JFG ^talk 12:27, 9 May 2016 (UTC)
• One year of activity and 3000 edits. I believe this is the minimum over the course of which an editor shall be able to understand the subtle concepts of avoiding link rot (by overusing supressredirect) and ensuring that links point to the correct targets. This is especially important to make sure in case of round-robin moves. Page movers should also have a proper understanding of attribution. They should be able to recognise pages that were created as copy-pastes from elsewhere or with incomplete editing histories. 103.6.159.70 (talk) 16:12, 17 May 2016 (UTC)
• Something not super hard to achieve, similar to filemover. Someone mentioned 6 months and experience moving pages. That seems reasonable, although I would personally make it 3000 edits or 6 months, whichever is first. People who want to help should be able to. Page move can be easily be reverted after all, so it's not like this is giving rights for someone to deleting the mainpage.

"In disputes" vs. "in a dispute"

• "In disputes" vs. "in a dispute". Per PaleAqua's comment above, which which I agreed, I changed "The editor used the permission to gain the upper hand in disputes" to "The editor used the permission to gain the upper hand in a dispute". This change was reverted with an edit summary that didn't make sense to me (I don't know what "a wat" is). So, let's discuss it. Someone should not have to be found to have engaged in a long-term pattern of abusing the userright in multiple disputes; someone blatantly move-warring with it should have it removed or not at admin discretion. As PaleAqua again noted earlier, the provisions there don't mean that an editor must have the right removed for any single transgression, only that such transgressions are grounds for potential removal. Approach this like rollbacker: Inappropriate (including incompetent) use is grounds for removal at least for a while, even in the absence of bad faith.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:46, 25 April 2016 (UTC)
  • It was "a way", I did reply to one of your comments down below with a rationale. --QEDK (T ☕ C) 16:53, 25 April 2016 (UTC)
    • Assuming you mean the battleground comment I disagree. I think that any real abuse should be at least considered grounds for removal, even if it is one sided. Yes people will try to game the system and might try to annoy a page mover into crossing the line but ultimately the right comes with responsibilities. Any admin removing the right should consider the circumstances and even then the removal can be appealed. PaleAqua (talk) 17:49, 27 April 2016 (UTC)

Overriding sysop move protection

Some of the supporters above suggest allowing pagemovers to override sysop move-protected pages. If this gets added this would allow page movers to replace pages they can not edit, including highly transcluded templates and modules. If this gets passed I think the bar for entry to this permission has just become much much higher. — xaosflux ^Talk 10:52, 3 May 2016 (UTC)

That would seem to qualify under abuse that's grounds for removal. The general default all across WP is that virtually anyone can do destructive things almost anywhere, and a WP value is that we trust them not to, by default. Any "destruction" here is temporary anyway.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:14, 3 May 2016 (UTC)

Agree. Montanabw^(talk) 04:05, 9 May 2016 (UTC)

Stepping this back a little bit, as the software will prevent moving a page unless you can also edit the page - so edit protection will still override anything. — xaosflux ^Talk 02:50, 4 May 2016 (UTC)

I made a table to illustrate what I think the proposal is, versus the current technical limitations. Page movers would not be able to move full-protected pages unless they can also edit full-protected pages, and I don't think that's the intent. As I understand it, allowing page movers to move but not edit full-protected pages would require a change to the software. And page movers would not be able to move files or protected templates. I think. At the moment there are 56 pages under full protection (including 21 indefinitely), it's hardly a burden to leave potential moves of these pages to admins. Ivanvector 🍁 (talk) 16:56, 4 May 2016 (UTC)

@Ivanvector: Thank you for creating that table. That perfectly illustrates my understanding of this proposed userright, including the notes on moving files and protected templates/modules. — Jkudlick • t • c • s 14:40, 6 May 2016 (UTC)

@Ivanvector and Jkudlick: Note the parallel existence of the template editor protection group. See the protection level for Template:FlagIOCmedalist. Most pages that have edit=templateeditor also have move=templateeditor, which is not higher or lower than this proposed pagemover level. Currently, only template editors and admins can move that template. If the page mover protection level is added, I'm personally not in favor of switching move levels over to page mover. If it's possible to put two locks on it (templateeditor and pagemover), then a user can move it only if they have both userrights. (At least that's my understanding) — Andy W. (talk · ctb) 01:13, 7 May 2016 (UTC)

@Andy M. Wang: I'm not sure I understand what you're saying. The pagemover right will only apply to articles and associated pages, just as templateeditor only applies to templates and modules and filemover only applies to files. There is no need to apply two separate locks to anything, even if it were possible. — Jkudlick • t • c • s 11:04, 7 May 2016 (UTC)

@Jkudlick: filemover is actually not a thing. "Filemovers" have an "action right" called movefile, which isn't a protection level. The reason it was implemented like this is because MediaWiki blocks everyone from moving files in general. For page moving, there are situations where an autoconfirmed user will want to move an article, so it's not the same.

templateeditor was built without namespace guarantees. For example, this page here happens to be template protected (because it has a lot of transclusions). templateeditor happens to be a protection level.

Current protection levels are hierarchical. i.e. sysop > templateeditor > extendedconfirmed > autoconfirmed > none. There's no question that Ivanvector's table is missing where templateeditor fits in. (Pending changes is implemented in a different way that we won't discuss for now.) But something like pagemover should not be higher than templateeditor. It isn't right to let the pagemover level be higher than templateeditor (they don't meet templateeditor requirements), or visa versa (because template editors haven't demonstrated move knowledge or experience).

Now, if they implement "pagemover" as an action called movepage, it can be given to admins and pagemovers that allows them to move fully protected pages. (similar to the existing editprotected given to admins only). If the original proposer is thinking of a new move protection level, i.e. let something like pagemover be its own thing, there are dicey situations would involve pagemover and templateeditor rights, i.e. which takes precedence, etc. For example, what exactly would edit=pagemover mean? (It means that only admins and pagemovers can edit a page protected like that, which seems absurd.) Admins would have to know better and not apply a protection level like that, but I don't think Media Wiki prevents admins from setting that at the moment if it existed. Disclaimer: I haven't worked on the MediaWiki backend, so I might have some facts wrong, but my technical background/intuition suggests that a new protection level is very dicey. — Andy W. (talk · ctb) 15:53, 7 May 2016 (UTC)

My understanding (which is flimsy at best) is that pages in File space and pages with template protection can only be moved with permissions which we are so far not discussing giving to pagemovers. I thought I had addressed this in footnotes to the table. If I've got it wrong, I'm happy to correct. It's also my understanding that excepting these two cases, pagemovers would be able to move any page, not just articles. And yes, I left out pending changes, I've no idea how pending changes affects moving pages. Ivanvector 🍁 (talk) 18:45, 9 May 2016 (UTC)

@Ivanvector: Your table looks pretty good, except for the move/full protection boxes for page mover, which I think is technically infeasible for the MediaWiki backend to do. Take a look at Special:Permalink/719492327 for the table I'm suggesting (along with iffy boxes).

Ideally, a move=pagemover level disallows template editors, and the existing move=templateeditor level disallows pagemovers. But if protection is hierarchical, it may not be feasible. FYI, move=templateeditor should disallow page movers moving, because edit=templateeditor has to disallow page movers editing. And you cannot move a page if you can't edit it. Admins would need to be wary that edit=pagemover makes almost no sense, because it allows only page movers and admins to edit, the way it's been suggested. — Andy W. (talk · ctb) 01:00, 10 May 2016 (UTC)

Actually, I take back what I said about page movers not being able to move move-protected pages. It might work if they implement a userright (not a user right package) like moveprotected, which is an exception that says, if you have that flag, you can move the page. edit=sysop would prevent page movers from moving the page, because they are not sysops and don't have an editprotected flag. — Andy W. (talk · ctb) 01:13, 10 May 2016 (UTC)

Yes, that last one should work. Then I think that edit=templateeditor should also prevent someone who is a pagemover but not a templateeditor from moving the template, since they can't edit it. And then pagemover doesn't need to be a protection level. Pagemovers would be able to move any page that is not a File, not template-protected, and not full-protected. Right? Ivanvector 🍁 (talk) 20:07, 10 May 2016 (UTC)

@Ivanvector: Yeah sounds right. I believe that page movers wouldn't be able to move edit=templateeditor protected pages even with a flag. (they really shouldn't anyway) @Xaosflux and Anomie: If the move protection segment does pass, it may be worth discussing the pros and cons of a "flag" or "protection level" (as Ivanvector and I understand them) for page mover. Would be interesting to see how the devs implement it. — Andy W. (talk · ctb) 04:42, 11 May 2016 (UTC)

A protection level is pretty simple, it's just a configuration change. Enhancing the configuration to make it so certain combinations of protection level and action aren't available to be set would take some coding, but would probably be accepted as a general idea. Trying to convince the devs to add a 'moveprotected' user right that allows overriding normal protection checks is not likely to succeed, given that the old 'editprotected' right did just that for edit protection and it was removed/repurposed some time ago since it was somewhat buggy. Anomie⚔ 13:44, 11 May 2016 (UTC)

@Anomie: would adding a protection level allow page movers to protect pages? i.e. if page "A" is page-mover move protected and the page is moved to "B" and back to "A" would "B" become page-mover move protected as well? Can a page be both semi-protected and page-mover move protected? If so what happens to a page "A" with both those protections that is moved to "B" and then back to "A". PaleAqua (talk) 02:07, 12 May 2016 (UTC)

It seems feasible that a page is semi-edit-protected, pagemover-protected, and PC level 2 protected (just for fun), i.e. edit=autoconfirmed, move=pagemover, autoaccept=review.

Looks like settings will copied over to "B" upon move. From Wikipedia:Moving a page: "A successful page move will be recorded in the Move Log (against the old page name) and a "move has succeeded" message will be displayed... If the old page was protected, its protection settings will be copied to the new page, and this will be recorded in the Protection Log (against the new page name). If Pending changes was enabled, the settings will be moved but they will not be logged against the new page title." — Andy W. (talk · ctb) 07:06, 12 May 2016 (UTC)

@PaleAqua: No, adding a protection level does not allow protecting pages. That requires the 'protect' right. Moving A to B then back would copy the protection too, so the resulting redirect would be protected; if someone abuses this somehow, take it to WP:ANI. A page cannot be both semi-protected for moving and page-mover protected for moving, but it can be semi-protected for editing and page-mover protected for moving, and moving will copy these protections as they are. Anomie⚔ 10:29, 12 May 2016 (UTC)

Thanks, I'm not as concerned with abuse since the criteria and ANI would easily handle that. I'm more concerned about reversibility by the page mover. This seems to imply for example that a round robin move could spread page protection in a way that they would be unable to undo and might not be aware of happening at the time the move was made. PaleAqua (talk) 13:05, 12 May 2016 (UTC)

---

When suppressredirect should be used

"suppressredirect which is granted by this user right should only be used in the following circumstances with few exceptions:

• "Round-robin" page moves because content is blocking a move (i.e. 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) (covered by WP:CSD#G6)
• Reverting page move vandalism (covered by WP:CSD#G3)
• Moving a page within your own userspace to another location (already possible with User:Luke081515Bot/Queue) (covered by WP:CSD#G7)
• [To fix recent page moves of your own where the new title contains an error] (covered by below)
• When moving pages from a title unambiguously created in error [or in the incorrect namespace] [when a deletion log isn't advantageous and a speedy deletion criteria explicitly applies] (e.g. Talk:Example article/Archive 3 is moved to Talk:Example article/Archive 1 because Talk:Example article/Archive 1 and Talk:Example article/Archive 2 do not exist. This generally does NOT apply to [title errors] in the mainspace[, redirects themselves, or controversial titles (unless they are recently personally created) which should become redirects and be listed at be RFD if desired].) (covered by WP:CSD#G6 or WP:CSD#R3)"

@IJBall: Replying down here instead of making the thread longer above. A very rough draft, but what do you think?—Godsy^(TALK_CONT) 05:34, 21 April 2016 (UTC)

I've moved one 'strikethrough' as the first part of the last point appears to have some support... --IJBall (contribs • talk) 18:19, 22 April 2016 (UTC)

I'd also suggest a clause section similar to Wikipedia:Template editor#Editing disputes:
"Page move disputes: This right should never be used to gain an upper hand in page move disputes. You have a privilege that most people do not have. The normal BOLD, revert, discuss cycle does not apply because those without this right are unable to perform the "revert" step in some cases (e.g. round "Round-robin" moves). [Therefore, avoid making unilateral decisions, and revert upon request if your page move proves to be controversial.], and instead propose the change on the talk page, and then make the change if there are no objections after a few days. Do not change the title to your preferred version when consensus has yet to be achieved. Lastly, never wheel war with admins or other page movers."
—Godsy^(TALK_CONT) 06:06, 21 April 2016 (UTC)

Discussion: When suppressredirect should be used

@Godsy: Yep – that looks pretty good to me. I'd also advise that the WP:Page mover page have some kind of simple "tutorial" on how to do "round-robin" page moves to move a page to a location with a redirect with a non-trivial page history, in the same way that the WP:File mover page seems to have some tutorials for file moves... --IJBall (contribs • talk) 05:42, 21 April 2016 (UTC)

Didn't see this before I commented above, but it looks good to me. I would take out "with few exceptions", it should be clear whether suppressredirect can be used or not, not open to individual users' interpretation of "a few exceptions", that's bound to lead to disputes. If you think there might be an exception, start a discussion. Also, regarding disputes, page movers probably shouldn't perform actions resulting from discussions they've started themselves. If this right is turned on then there should be plenty of other users available to close and perform the action. Ivanvector 🍁 (talk) 18:26, 21 April 2016 (UTC)

@Ivanvector: I struck some things according to your suggestion and made a couple of changes in brackets.—Godsy^(TALK_CONT) 20:16, 21 April 2016 (UTC)

@Godsy: Could you please explain the "This does NOT apply to [title errors] in the mainspace..." part? To give you a concrete example, I once accidentally moved a page (in mainspace) to a title that was missing a letter from a word (and, so was basically an erroneous "nonsense" title error) – I then moved it to the correct title, and tagged the incorrect title (which was now a redirect) with WP:G6. Are you suggesting that page movers should not use suppressredirect in situations like this, and should leave the erroneous redirect in place and tag it with WP:G6? Because, if so, that seems unnecessary "WP:BURO-y" and a waste of everyone's time (including the Admin that would have to clean up the WP:G6 erroneous redirect...) --IJBall (contribs • talk) 20:25, 21 April 2016 (UTC)

@IJBall: If it is your own error it's fine (and also covered by WP:CSD#G7), and I've added that in above. If another user creates a page with the wrong capitalization, a typo, etc. and you move it to the proper title, that should always become a redirect. There is no consensus to speedily delete page titles in most of those cases (e.g. "a title that was missing a letter from a word" if created by another user).—Godsy^(TALK_CONT) 21:18, 21 April 2016 (UTC)

"Do not change the title to your preferred version when consensus has yet to be achieved." I'm not sure a Page mover should do that even when consensus is achieved, under WP:INVOLVED – probably best to request an uninvolved Page mover do the move when consensus is achieved. So we may want to change this sentence too... --IJBall (contribs • talk) 23:01, 21 April 2016 (UTC)

Stricken.—Godsy^(TALK_CONT) 23:23, 21 April 2016 (UTC)

@Godsy: Suppressredirect should also be used when non-administrators close WP:CFD rename and merge discussions. Leaving category redirects when renaming or merging categories is often undesirable, because category redirects are effectively soft redirects due to technical limitations (see WP:CATRED for details), and are often not helpful. Categories are also rarely linked directly from articles (as in [[:Category:Moving and relocation]] instead of [[Category:Moving and relocation]], so it is rarely needed to update wikilinks after performing category renames/merges. In most cases, when categories are renamed through the CFD process, the old category name is not left as a redirect, but the deletion log links to the new category location. See Wikipedia:Categories for discussion/Log/2016 April 10#Category:Futsal forwarders and Wikipedia:Categories for discussion/Log/2016 April 1#Category:7th century in the Rashidun Caliphate for examples of admin closures, and Wikipedia:Categories for discussion/Log/2016 April 3#Category:Mayors of Fayette, Mississippi for an example of a non-admin closure, where the old category name is deleted per G6. I would argue that CFD is even more backlogged than RM, so allowing page movers to use suppressredirect while performing CFD closures would help reduce the CFD backlog. SSTflyer 09:52, 22 April 2016 (UTC)

@SSTflyer: The redirect still ends up existing when "round-robin" page moves for technical deletions when a page is blocking a move are used for RMs. In both examples you provide, entries were created in the deletion log (Category:Futsal forwarders and Category:Mayors of Fayette, Mississippi), which doesn't happen when redirects are suppressed. This would work for category rename discussions, but I think it is preferable to have the deleted page link to the new category in the deletion log which is displayed on the page, hence "proper" deletion is preferable (furthermore they don't seem to explicitly be covered by WP:CSD#G6). This wouldn't work for category merges, as the old category would have to be moved somewhere else, and would still require deletion. Unless I'm misunderstanding something, it doesn't seem like it would work with the abilities this right provides.—Godsy^(TALK_CONT) 13:41, 22 April 2016 (UTC)

@Godsy: see Wikipedia:Categories for discussion/Log/2016 April 11#Category:Election result formatting templates for an example of a CFD closure that involves suppressredirect. SSTflyer 15:58, 22 April 2016 (UTC)

@SSTflyer: It seems that it wouldn't work for merges, and there would be no need in regard to renames unless it meets one of the criteria already listed above (e.g.: I understand category redirects must be soft redirects due to technical limitations; they would be eligible to be suppressed per the last criteria above if they contained errors and weren't simply less common synonyms). I'll ask Ivanvector and IJBall to weigh in on this.—Godsy^(TALK_CONT) 01:27, 23 April 2016 (UTC)

I'm no help here – I understand categories barely at all. I'll defer to those who know more about it. There are several category "experts" who might be worth pinging, Ser Amantio di Nicolao and Liz being two that immediately come to mind... --IJBall (contribs • talk) 02:37, 23 April 2016 (UTC)

• I've mainly stricken the last point above, it seems like more trouble than it is worth upon further reflection. Someone else can re-propose it if they like. It opens the door to interpretation and grey areas, which is a slippery slope. Things of that nature can be easily handled by a speedy deletion request.—Godsy^(TALK_CONT) 14:14, 22 April 2016 (UTC)
  • I actually think leaving "When moving pages from a title unambiguously created in error" is just fine as is, without any qualification. The key words there are "unambiguously created in error" (e.g. typos) – that's perfectly clear. --IJBall (contribs • talk) 16:00, 22 April 2016 (UTC)

Yeah I agree, that's clear enough. Adding a bunch of qualifiers to that statement is what opens it up to interpretation and messy inclines. Also, "unambiguously created in error" really covers recent page moves which contain an error, doesn't it? Ivanvector 🍁 (talk) 17:23, 22 April 2016 (UTC)

Added R3 to the rationale. Bazj (talk) 10:39, 24 April 2016 (UTC)

@Bazj: WP:R3 explicitly doesn't apply to redirects resulting from page moves.—Godsy^(TALK_CONT) 01:16, 25 April 2016 (UTC)

Godsy, you're right. Thanks for fixing. Bazj (talk) 06:02, 25 April 2016 (UTC)

• Added a cleaner version to the proposed right with these edits.—Godsy^(TALK_CONT) 02:40, 25 April 2016 (UTC)

• @QEDK: Mind if we leave the "guide" there to advertise the anchors, encourage linking to a specific criteria, and make it easy to copy and paste? Modeled it after WP:CSD to a certain extent.—Godsy^(TALK_CONT) 05:23, 25 April 2016 (UTC)

• It renders quite weirdly since the line doesn't wrap properly due to the template which has been forcefully aligned right and that was the only reason I removed it. --QEDK (T ☕ C) 06:07, 25 April 2016 (UTC)

• @QEDK: How's that?—Godsy^(TALK_CONT) 06:16, 25 April 2016 (UTC)

Better. --QEDK (T ☕ C) 06:22, 25 April 2016 (UTC)

• @QEDK: I converted it to a table. —Godsy^(TALK_CONT) 06:36, 25 April 2016 (UTC)

• Generally agreed with how this is shaping up; any kinks can be worked out later. My #1 concern is people with a recent history of 1) movewarring, 2) actual AT policy cluelessness, or 3) tendentious campaigning and "language activism" at RM, should not have this userright, or it will be a huge vat of disruption and drama until its taken back away from them.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
  • If a dispute is enough for someone to get their right revoked, it'd be a literal battleground. Often someone not doing it on purpose might just get the title stuck. Whatever happened to ROPE. Anyone who's against one of these page movers just needs to make it stick once and there are people who will, I know it. Let's not make it legalese and let the community decide if anything like that happens (because one's something's set in stone, it takes a while to remove it round here). --QEDK (T ☕ C) 15:57, 25 April 2016 (UTC)
• The list looks good to me. That said and this is a minor detail, I'm not sure I'd want to lock step them with the CSD. It makes it difficult to make changes in the future after experience of how page mover works and two it implies a strong tie between deletion and suppress redirect which might mean other deletion guidelines and restrictions implicitly get considered as allowed under this right. Because this is an RfC if it passes it will have it's own strength as a policy. I'd rather instead of "covered by CSD#", the links were "see also CSD#". That way future allowances and restrictions can be considered separately from CSD and future changes to CSD criteria don't have to worry about breaking page mover. PaleAqua (talk) 17:36, 27 April 2016 (UTC)

• @PaleAqua: I wrote them that way because if a redirect is suppressed, the former page title needs to meet one of the speedy deletion criteria, otherwise it should become a redirect. The speedy deletion criteria itself would need to be expanded to allow for more cases (i.e. "future allowances", though "future restrictions" could be decided here). If an editor that is not an administrator and doesn't hold this right moves a page, the only way to delete the redirect resulting from that page move is if it meets one of the speedy deletion criteria, or by to taking it to RFD. We shouldn't create another class of deletion that allows those with special privileges to make unilateral deletion decisions. That was part of my concern with this right in above sections, editors need to explicitly understand when this can be used, and that it cannot be used to circumvent the existing deletion policy.—Godsy^(TALK_CONT) 02:47, 29 April 2016 (UTC)

• @Xeno: Technical question: Can suppressredirect be used when moving a file? I'll propose a fifth criteria concerning suppressing redirects resulting from file moves per WP:FNC#9 under WP:CSD#G6 if that is the case.—Godsy^(TALK_CONT) 04:51, 29 April 2016 (UTC)

  @Godsy: suprress redirect it also available on File:'s however, you must ALSO have movefile access (e.g. via "filemovers") before you can even get there. If this passes and a user was a file mover AND a pagemover they could suppress file redirects as well. — xaosflux ^Talk 04:09, 3 May 2016 (UTC)

• Added a fifth criteria.—Godsy^(TALK_CONT) 04:23, 3 May 2016 (UTC)
• 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. --QEDK (T ☕ C) 12:13, 3 May 2016 (UTC)
  • I mirrored it to Wikipedia:File names#What files should be renamed?. I strongly disagree that "we must realize that everything happens at our own discretion, restricting a flag to the few obvious cases is not useful". If a page title doesn't explicitly meet a criteria for speedy deletion, the right should not be used.—Godsy^(TALK_CONT) 20:35, 4 May 2016 (UTC)
    • No where does it say that the cases under FNC are the only uses of the filemover right. All flags on Wikipedia are used at the holder's discretion and there's no reason to override that for one specific flag. The pre-established criteria is merely a thumbrule and does not mean there's to be no scope for other usage. --QEDK (T ☕ C) 10:07, 5 May 2016 (UTC)

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