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

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 is already included in autoconfirmed - what is the point of doubling it here? — xaosflux ^Talk 02:14, 17 April 2016 (UTC)

Oops. Removed. –xeno^talk 02:48, 17 April 2016 (UTC)

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? –xeno^talk 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 AnomieX would know. –xeno^talk 03:12, 17 April 2016 (UTC)

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)

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)

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)

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)