Wikipedia talk:Page mover

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)

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

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.

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)

Discussion

Summary of results (as of 23:23, 23 April 2016 (UTC))
Question	Support	Oppose	% support	Result
Creation of permission	31	2	93.9	-
Supressredirect	25	5	83.3	-
Move-subpages	20	0	100	-
Title blacklist override	12	11	52.2	-
Pagemove throttle limit increase	14	0	100	-
Move protection	1	4	20	-

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)

---

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)

Support: Creation of permission

• Support support this in general, agree that criteria for assignments needs development. — xaosflux ^Talk 01:05, 19 April 2016 (UTC)
• Support in principle, as it could help reduce the RM backlog drastically. Esquivalience ^t 01:08, 19 April 2016 (UTC)
• 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)
• 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)
• Support a good idea in general and will help reduce the backlog. --Tom (LT) (talk) 02:01, 19 April 2016 (UTC)
• Support. This look useful. I don't see any downsides. NinjaRobotPirate (talk) 02:02, 19 April 2016 (UTC)
• Support, as a great idea. APerson (talk!) 02:05, 19 April 2016 (UTC)
• Support – Seems like common sense. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
• 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)
• Support, there is a need as this could help with RM backlog. PaleAqua (talk) 03:17, 19 April 2016 (UTC)
• Support Yes, please! --QEDK (T ☕ C) 09:33, 19 April 2016 (UTC)
• 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)
• 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)
• Obvious support Not worried about suppress redirect right, we have logs.--v/r - TP 20:00, 19 April 2016 (UTC)
• 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)

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

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

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

• 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)
• 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)
• 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)
• 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)
• 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)
• Support. Useful. Little, if any, downside as User:McMatter notes. Donner60 (talk) 05:58, 21 April 2016 (UTC)
• Support. I've generally supported unbundling as a way to deal with the troubles involving admins. Wnt (talk) 16:12, 21 April 2016 (UTC)
• Support Peter James (talk) 08:18, 23 April 2016 (UTC)
• 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)
• 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)
• 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)
• Support The more good users can do for themselves and others the better. Alanscottwalker (talk) 00:55, 24 April 2016 (UTC)
• 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)
• Support Seems reasonable enough. Wugapodes (talk) 20:21, 24 April 2016 (UTC)
• 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)
• Support if given to highly experienced users, with specific criteria established. Rubbish computer (HALP!: I dropped the bass?) 08:09, 25 April 2016 (UTC)

Oppose: Creation of permission

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

---

Discussion: Supressredirect

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

Support: Suppressredirect

• Support This permission is really the key to what is missing with unflagged page moves. — xaosflux ^Talk 01:06, 19 April 2016 (UTC)
• Support Seems to me to be the whole point of this. Happy Squirrel (talk) 01:38, 19 April 2016 (UTC)
• 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)
• 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)
• Support as above. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
• 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)
• Support This is an essential requirement for this user right. PaleAqua (talk) 03:19, 19 April 2016 (UTC)
• Support This is the whole point, why are we bothering with this, again? --QEDK (T ☕ C) 09:33, 19 April 2016 (UTC)
• 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)

• 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)
• Support, as it's essential to the proposal. APerson (talk!) 01:44, 20 April 2016 (UTC)
• 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)
• 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)
• 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)
• 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)
• Support Per comments below. Peter Sam Fan 18:29, 20 April 2016 (UTC)
• 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)
• 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)
• 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)
• 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)

• 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)
• Support - --John Cline (talk) 18:42, 23 April 2016 (UTC)
• 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)
• 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)
• Support Same reason as above. Alanscottwalker (talk) 00:58, 24 April 2016 (UTC)
• 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)
• 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)
• Support: Central to the proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
• Support. Rubbish computer (HALP!: I dropped the bass?) 08:11, 25 April 2016 (UTC)

Oppose: Suppressredirect

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

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

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

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

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

Discussion: Move-subpages

Support: Move-subpages

• 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)
• 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)
• 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)
• 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)
• 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)
• Support per above - a very useful permission. --Tom (LT) (talk) 02:09, 19 April 2016 (UTC)
• Support: This would be so helpful. Kevin (aka L235 · t · c) 02:14, 19 April 2016 (UTC)
• 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)
• 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)
• Support - not seeing an upside to leaving the sub-pages behind. Bazj (talk) 11:37, 19 April 2016 (UTC)
• Support. Makes perfect sense. Steel1943 (talk) 20:21, 19 April 2016 (UTC)
• Support per above.—Godsy^(TALK_CONT) 21:02, 19 April 2016 (UTC)
• Support useful when talk page archives are involved. SSTflyer 09:37, 20 April 2016 (UTC)
• 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)
• 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)
• Support Definitely. --QEDK (T ☕ C) 16:09, 21 April 2016 (UTC)
• Support - of course, the userright doesn't make sense otherwise. Ivanvector 🍁 (talk) 18:08, 21 April 2016 (UTC)
• Support Only makes sense. — Music1201 ^talk 19:36, 23 April 2016 (UTC)
• 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)
• Support Peter James (talk) 23:07, 23 April 2016 (UTC)
• Support Wugapodes (talk) 20:21, 24 April 2016 (UTC)
• Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
• Support: Definitely. This is also central to the proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:15, 25 April 2016 (UTC)
• Support as appears a central part of the subgroup. Rubbish computer (HALP!: I dropped the bass?) 08:14, 25 April 2016 (UTC)

Oppose: Move-subpages

---

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)

Support: Title blacklist override

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

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

• 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)
• 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)
• 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)
• 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)
• Support would occasionally be useful, particularly if suppressredirect is included. Template editors already have this. Peter James (talk) 09:17, 23 April 2016 (UTC)
• 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)
• 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)
• 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)
• Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
• 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)

Oppose: Title blacklist override

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

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

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

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

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

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

---

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)

Support: Pagemove throttle limit increase

• Support with a maximum of 100/60. I would also support any lower thresholds. — xaosflux ^Talk 01:11, 19 April 2016 (UTC)
• 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)
• 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)
• Support with thanks to the editors wielding these small non-admin sized mops. --Tom (LT) (talk) 02:00, 19 April 2016 (UTC)
• Support, and I agree with the above !voters' arguments. APerson (talk!) 02:05, 19 April 2016 (UTC)
• 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)
• 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)
• 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)
• Support. Makes perfect sense. Steel1943 (talk) 20:02, 19 April 2016 (UTC)
• 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)
• 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)
• 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)
• 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)
• Support Makes sense to me. — Music1201 ^talk 19:39, 23 April 2016 (UTC)
• Support, seems harmless and may be potentially useful. Satellizer el Bridget ^(Talk) 02:11, 25 April 2016 (UTC)
• 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)

Oppose: Pagemove throttle limit increase

• 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)
• 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)
• Weak oppose due to the potential for this to be misused. Rubbish computer (HALP!: I dropped the bass?) 08:30, 25 April 2016 (UTC)

Discussion: Allow moving of move-protected pages

Template:Formerly

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)

Support: Allow moving of move-protected pages

• Support perhaps the most useful right that this group could possibly have when closing RM discussions. Kharkiv07 (T) 16:11, 22 April 2016 (UTC)
• 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)
• '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)
• Support as appears central to the group's overall purpose. Rubbish computer (HALP!: I dropped the bass?) 08:26, 25 April 2016 (UTC)

Oppose: Allow moving of move-protected pages

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

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

---

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)

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

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

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 ensures that admins granting this userright thoroughly review 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)

---

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)

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)

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)

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)

Revocation challenges

@MusikAnimal: Wikipedia:Page mover#Criteria for revocation's appeal method was modeled on WP:TPEREVOKE. Whichever way, it should be consistent. The only thing I found discussion wise with a quick glance at Wikipedia talk:Template editor was Wikipedia talk:Template editor#revocation. There are precedents for appealing on the permission request page, User:Alakzi for one.—Godsy^(TALK_CONT) 04:41, 25 April 2016 (UTC)

Thanks. You found a very good example, but it normally doesn't work out that way. PERM is patrolled by a small handful of admins. It's one thing to re-request the right once you feel you're ready for it again, but it isn't the best venue for something controversial like appealing another admin's decision. If someone does post at PERM for this purpose I certainly won't revert it, but from my time working there I've found stuff like this ultimately gets moved to AN or AN/I — MusikAnimal ^talk 04:58, 25 April 2016 (UTC)

Agreed, but ANI also garners too much unnecessary attention. I was the one who based it completely on TPE. Maybe something like RfRevocation? --QEDK (T ☕ C) 06:09, 25 April 2016 (UTC)