The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Do administrators have the delete-redirect right yet? I would like to see how it works in practice. What sort of record is left in the logs, whether a deleted revision is left behind that an administrator could restore, etc. – wbm1058 (talk) 14:05, 30 December 2020 (UTC)[reply]
I don't see delete-redirect listed as an admin user-right at Special:ListGroupRights. Granted, admins don't need this right to perform this action. But, will admins doing this without the right be functionally different than page movers doing it with the right? wbm1058 (talk) 14:50, 30 December 2020 (UTC)[reply]
Administrators have every user right that page movers have. Before an RfC is started to expand this right to other users, it should first be granted to administrators. – wbm1058 (talk) 15:00, 30 December 2020 (UTC)[reply]
These deletions will still be logged in the deletion log. From my reading of the code, they will be indistinguishable from deleting single-revision redirects to the same target by moving over them in Special:Log (although I could be wrong here). The deletion tag log is an entirely unrelated feature, and entries in it are generated when a new page reviewer (or administrator) nominates a page for deletion (either speedy deletion or a deletion discussion) using the PageTriage extension* Pppery *it has begun...15:39, 30 December 2020 (UTC)[reply]
I don't see the need for the new revocation clause, because this proposal doesn't grant page movers the right to do anything significant they couldn't already do, only do things they can do in a less convoluted way. A page mover could already delete single-revision redirects by moving their targets over them, and then moving their former target back to the original location without leaving a redirect. Except for the deliberate misuse of the feature that I described above as already possible, any redirect deleted by a page mover falls under WP:G6 (deleting redirects ... blocking page moves). Aside from that, the proposal looks good. * Pppery *it has begun...15:24, 30 December 2020 (UTC)[reply]
mw:API:Logevents (API help) lists all the possible values (codes) of log actions. Where is it documented what all these codes mean? Specifically what do delete/delete, delete/delete_redir, and delete/delete_redir2 mean? Can you list each of these specific log actions on the Special:Log page? I hadn't noticed the "Type of deletion" dropdown on that page before. How is the "Type of deletion" queried using the API? wbm1058 (talk) 03:23, 31 December 2020 (UTC)[reply]
Deletion of a content page or a redirect that has multiple-edit history or doesn't target the page moved from
Administrators only?
"delete_redir"
"Redirect overwrite"
Deletion of a redirect without multiple-edit history that targets the page moved from
All autoconfirmed editors
"delete_redir2"
??
Deletion of a redirect without multiple-edit history that targets a different page than the page moved from, by a non-administrator granted the delete-redirect right
Page-movers only
How will "delete_redir2" be located in the deletion log? I don't see a new drop-down menu option for this.
API lookup for "delete_redir2" finds nothing, as expected because nobody has the delete-redirect right yet.
Why does Pppery have 25 entries (in 2016) in the "Page deletion" log? If only admins are supposed to be able to do this? Software glitch? My first entry in this log was on 1 September 2015 (I was granted adminship at the end of August 2015).
I don't believe that there was a separate log for redirect overwrite until after it was first introduced, which may explain why it was being logged as normal deletions originally, but I'll look through the history. For the "Type of deletion" on Special:Log, delete_redir2 will be the same as delete_redir ("Redirect overwrite") and the two subtypes will be shown together DannyS712 (talk) 23:48, 31 December 2020 (UTC)[reply]
Moving a page over the redirect leaves an abandoned row in the revision table "I think the issue here is that if you move a page over a redirect, the old redirect is gone forever, rather than being moved to the archive table." I had assumed that this was by design rather than a bug. The reason being it wasn't necessary to save the redirect since you knew where it redirected to. Why I have been sooo concerned that there would be no record of where these new "delete_redir2" redirects redirected to. It is reassuring to know now that these will be recorded in the log, and the deleted redirects will be recoverable from the deleted revisions.
My understanding of how moves worked formed from my earliest experience, before I became an administrator. My move log from early 2012 shows several "over redirect" moves but there are no deletion log entries from this timeframe, i.e. these "over redirect" moves did not leave an entry in the deletion log for the redirect they deleted. For example, at 15:19, 16 July 2012 I moved page Rental shop to Video rental shop over redirect. I don't see any deleted edits sitting under Video rental shop – that redirect is gone. I hadn't really noticed that this behavior had changed until now, on reviewing this. – wbm1058 (talk) 01:50, 1 January 2021 (UTC)[reply]
Just got this ping and made some revisions. It looks good without them though, so feel free to revert whatever is not an improvement. The changes were too much to explain in an edit summary so I'm elaborating here. This seems good to go honestly, so I added some top-matter to get it ready to post. It includes the RFC tag and cats as well as a short question for the feedback request service bot. The {{draft proposal}} tag can be changed to {{proposal}} when ready, and then just remove the no wiki tags. I also added an empty discussion section.
I tried to streamline the background section. The first paragraph is substantially the same, but I tried to phrase it so that the antecedents are clear. I removed the paragraph on deletion with a note, though looking at it now I might want to add it back in the logging section. Getting into the weeds of how the deletions happen (or that they're deletions at all) is probably not necessary for the background and better to bring up on request in the discussion, imo. I added a paragraph on the page mover group and how it relates to these move types and this proposal.
I simplified the table and moved it into background. I removed the "API action" column since most people won't understand it and it may confuse the proposal. For example, delete_redir and delete_redir2 weren't mentioned and are easily confused with the delete-redirect right under discussion. Since most people won't care about the API specifics, better to avoid any potential misunderstandings. I tried to clarify the "type of deletion" column header but maybe made it worse? May edit that again later. I copyedited the "page deletion" description as well. For all of them, I standardized the forat of the "who can do this" column stating the user right that allows the action and in parenthesis gave the user group that contains it.
I modified the proposal section so that the proposals are imperatives and start with verbs. I made "example use cases" a subheading but might undo that. Still, I think it would be worth writing up how this will simplify/obviate most round-robin moves which imo is the biggest gain from this proposal.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
RFC on granting delete-redirect to page movers
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Support The right would only slightly expand on the abilities already granted to autoconfirmed users, and is on par with the suppress-redirect right already given out with page mover. The right would substantially lower the work load for page movers by eliminating the need for round robin moves in many cases. That process is complicated and error prone; if a page mover forgets to suppress a redirect anywhere in that process then they may need to start the whole thing over again. Not only will this eliminate that strategy for a whole class of page moves, it also allows page movers to fix mistakes (like not suppressing a redirect) they make in the course of more complicated page moves. Low risk, but high reward. Unconditional support. — Wug·a·po·des23:54, 18 February 2021 (UTC)[reply]
Support For something that could be done without it, just in a more cumbersome round robin approach, I see only upsides for adding this to page movers. PaleAqua (talk) 02:56, 19 February 2021 (UTC)[reply]
Support. I think I'll need to give one of my socks the page-mover right to see how it works. I think this is a first; a right that some non-admins will have, that admins won't. – wbm1058 (talk) 16:15, 19 February 2021 (UTC)[reply]
without getting in to very esoteric permissions, some common permissions that non-admins have that admins do not are: abusefilter-modify, bot, torunblocked — xaosfluxTalk16:22, 19 February 2021 (UTC)[reply]
Neutral (if only to avoid a whiteout). All my pagemoves have been WP:ROBIN swaps, and I've never seen the need. On the other hand - you have to make a solid case to be granted the privilege, and I can't see any responsible editor who's jumped through that hoop and not been kicked out abusing this extra function. Narky Blert (talk) 01:13, 21 February 2021 (UTC)[reply]
Support: Not much more than the regular move right; page movers can be trusted with this additional ability without too much additional potential for abuse. Twassman | Talk | Contribs01:49, 27 February 2021 (UTC)[reply]
Support - seems like a pretty easy call here. Slightly reduces strain on administrative backlog, and moves things along faster. Users with the "page mover" right are already trusted to know how this works. Eagles24/7(C)19:22, 1 March 2021 (UTC)[reply]
Support for page movers. In the phabricator discussion at phab:T239277, granting it to autoconfirmed users was mentioned as an idea; I'd like to note that I oppose this idea as it allows any autoconfirmed user to overwrite redirects with vandalism pages, leaving damage behind that is cumbersome and requires sysop tools to repair. ~ ToBeFree (talk) 19:24, 1 March 2021 (UTC)[reply]
Support since a redirect with no history isn't a problem but I'd log where the target was such as if someone moved "Apple" to "Orange" and "Orange" redirected to "Banana" you would see "Deleted redirect to "Banana"". Crouch, Swale (talk) 19:26, 1 March 2021 (UTC)[reply]
support per SD0001. But to be honest, I like, and enjoy performing round robin moves. Most of the moves I've performed are round robins. —usernamekiran (talk)19:38, 1 March 2021 (UTC)[reply]
Support essentially per Wugapodes: seems like a reasonable slight expansion of the existing ability to overwrite redirects that autoconfirmed users already possess. Mz7 (talk) 19:42, 1 March 2021 (UTC)[reply]
Support for pagemovers per ToBeFree. This is anyway already nearly de-facto possible for page-movers via the process of WP:ROBIN (an admittedly interesting process), but yes there are some cases were this might further simplify things, and if we trust the users then simplifying things is not a bad idea. RandomCanadian (talk / contribs) 21:03, 1 March 2021 (UTC)[reply]
Support. I was rather taken aback when I saw the proposal, but having read the details, it seems fine. The piece that convinced me was that this only applies to single-revision redirects, and so opportunity for abuse is minimal. Vanamonde (Talk)22:00, 1 March 2021 (UTC)[reply]
Support, mostly harmless. Obviously useful. Will save quite a few requests for housekeeping speedy deletions. - Nabla (talk) 18:34, 3 March 2021 (UTC)[reply]
Support - This seems useful and low risk. It's only a small expansion of the permissions of this group of users that already has a level of community trust. - tucoxn\talk22:20, 3 March 2021 (UTC)[reply]
Support: an uncontroversial technical improvement with no real behavioural considerations to factor in given the level of trust page movers are already given. — Bilorv (talk) 01:18, 8 March 2021 (UTC)[reply]
Support. This would save a lot of time and free up admins for more important/higher priority tasks. -- Ϫ04:10, 12 March 2021 (UTC)[reply]
Support, though it's admittedly obvious what way the wind is blowing. This is a pretty trivial addition overall, and I say this as someone who's been vocal about the dangers of unbundling deletion even in part. Vaticidalprophet (talk) 12:20, 14 March 2021 (UTC)[reply]
Support as this will reduce my need to send pages to G6 for page moves of broadcast stations. Every month, I have at least one G6 need while implementing the latest FCC Media Bureau Call Sign Actions list. Sammi Brie (she/her • t • c) 07:20, 18 March 2021 (UTC)[reply]
Up until now, only trusted users with experience who have shown a need get this perm. Even if the requirements arent decreased on paper, I just hope only competent, long term, and trustworthy editors will get this flag in the future. I mean, the mentality of granting admins shouldnt change over time. —usernamekiran (talk)19:44, 1 March 2021 (UTC)[reply]
I would imagine scrutiny of editors that get the pm bit in the future will be somewhat higher given the extra abilities, but not extraordinarily so. Any time you give someone the ability to delete any page, you would expect care in the selection. Dennis Brown - 2¢11:48, 8 March 2021 (UTC)[reply]
This is a good idea, but when it's adopted, it will need to be very carefully advertised to all existing page-movers. At the very least, it makes certain mistakes possible: currently, if you mistakenly try to move over a redirect to a different target, you'll get an error message, but with the new userright, an unaware page-mover may not notice the mistake. Any announcement will also need to emphasise the need to ensure after a move that the previous target is accessible via a clear navigational path, for example from a hatnote. – Uanfala (talk)21:07, 11 March 2021 (UTC)[reply]
If I recall, the new behavior is, if the target is a single revision redirect pointing somewhere else, to show an error message that the target exists, but offer the options to delete it, like admins have for any existing target page DannyS712 (talk) 01:31, 12 March 2021 (UTC)[reply]
Point which just occurred to me and that I haven't seen discussed prior: This sounds like it would grant page movers the technical ability to close RfDs as delete. Would that be permitted, or would it be considered a misuse of the tools? Alternately, am I misunderstanding something? Vaticidalprophet (talk) 07:51, 15 March 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
at 18:54, 22 March 2021 Ammarpad deleted redirect Melbury Sampford by overwriting (G6: Deleted to make way for move)
at 20:06, 22 March 2021 Lugnuts deleted redirect Alexander Beckett by overwriting (G6: Deleted to make way for move)
at 14:34, 24 March 2021 TheAafi deleted redirect Massinissa by overwriting (G6: Deleted to make way for move)
hmm, an edit conflict with Anthony Appleyard? Anthony restored 397 revisions, apparently including the redirect that was deleted to make way for the move.
I re-deleted what I believe was the redirect that was deleted to make way for TheAafi's move. Note the previous move:
Barcelona12345 moved page Masinissa to Massinissa of Numidia: There are quite a few Massinissa's (including other monarchs). He was the founder of the Numidian Kingdom and is known as Massinissa of Numidia.
...not only moved to "of Numidia" but also changed the spelling (added an "s").
Lugnuts, please take care to add a hatnote at the top of an article when you establish it as the primary topic by moving over a redirect to the former primary topic, as I did with this edit. – wbm1058 (talk) 17:14, 24 March 2021 (UTC)[reply]