WikiProject iconCounter-Vandalism Unit
WikiProject iconThis page is within the scope of the Counter-Vandalism Unit, a WikiProject dedicated to combating vandalism on Wikipedia. You can help the CVU by watching the recent changes and undoing unconstructive edits. For more information go to the CVU's home page or see cleaning up vandalism.Counter-Vandalism UnitWikipedia:Counter-Vandalism UnitTemplate:Counter-Vandalism UnitCounter-Vandalism Unit articles

Removing lock color labels

@Redrose64: The edit needed an explanation, but referring to the various protection levels and types using colors is non-intuitive and poor design from an accessibility standpoint. I agree with the editor that removing the color labels is an improvement so I removed them from the icon table and elsewhere. The visual clue of the colors is helpful on articles and the icons are great, but the alt text for the icons is the protection level or type and not a visual description of the icon for a reason. Daniel Quinlan (talk) 23:29, 25 January 2024 (UTC)[reply]

The textual lock colours (Goldlock, etc.) were added by BWikiBW02 (talk · contribs) on 17 May 2021 (to Template:Padlock list, which was transcluded to Wikipedia:Protection policy at that time); you need admin rights to view its history. It doesn't seem to have been discussed at that time, nor indeed over the ensuing year during which Template:Padlock list remained substantially unchanged before being sent to TfD. Personally I think that they're harmless, even helpful.
The shortcuts (WP:GOLDLOCK, etc.) on the other hand are longstanding, having been added by Purplebackpack89 (talk · contribs) fourteen years ago. They should definitely be reinstated and not removed without consensus. --Redrose64 🌹 (talk) 15:04, 27 January 2024 (UTC)[reply]
The shortcuts still work. I simply want do discourage people from using the color code shortcuts because they are bad for accessibility and add an extra layer of jargon that is unhelpful when they are actually used on Wikipedia. Also, bear in mind the WP:LINKBOXES guideline that they generally should list only the most common and easily remembered redirects.
I'll restore the shortcuts for the time being since there is disagreement, but I'll pose the question about whether they should be removed below. Daniel Quinlan (talk) 00:17, 28 January 2024 (UTC)[reply]
The color labels should be retained. I disagree with Daniel Q's removal of them. RedRose has a point that this is a longstanding listing. pbp 15:28, 27 January 2024 (UTC)[reply]
The shortcut names, and thus the labels of the shortcuts, should be maintained - as they are used. — xaosflux Talk 00:21, 28 January 2024 (UTC)[reply]

 Question: Should the color code shortcuts be removed from the shortcut boxes in order to discourage their future use? (Redirects will be maintained for backward compatibility, of course.) Daniel Quinlan (talk) 00:25, 28 January 2024 (UTC)[reply]

Reviewing the entire WP:RFPPI archive from 2023, the color-code shortcuts were used 12 times over the course of the entire year. That isn't exactly common usage given there were ~16,000 page protection requests last year. Daniel Quinlan (talk) 03:49, 28 January 2024 (UTC)[reply]
Support removing them to discourage use. I've actually considered taking at least some of these to Redirects for discussion in the past.
According to Wikipedia:Manual of Style/Accessibility#Color we should Ensure that color is not the only method used to communicate important information. One of the reasons for the widely supported 2018 redesign of the padlock icons was to add symbols and ensure they were not solely distinguished by colour. Here is a great simulation of what the locks look like for the large number of people with red-green colour blindness. Can you tell me what "GREENLOCK" refers to there?
Additionally there isn't any meaning to the colour choices (with the exception of gold and silver). Without looking, does anyone actually know what a turquoise lock means? Is WP:TURQUOISELOCK a helpful shortcut when we have WP:CASCADE? the wub "?!" 23:36, 28 January 2024 (UTC)[reply]

TFA protection

I just semi-protected the current featured article following a request by A smart kitten at page protection permalink. Apparently the bot that would normally do that is not working at the moment. The discussion to semi-protect the current TFA is archived here. The August 2023 close by CaptainEek includes "There is overwhelming consensus to semi-protect each TFA from the day before it is on the main page and through the day after." Does that wording mean a TFA should be semi-protected for 72 hours (24 hours before, during and after)? If so, Wikipedia:Protection policy#Preemptive protection should be updated with more detail, perhaps in a footnote and including a link to the RfC. Johnuniq (talk) 02:22, 5 February 2024 (UTC)[reply]

Courtesy ping: Legoktm as botop for TFA Protector Bot. Best, ‍—‍a smart kitten[meow] 02:29, 5 February 2024 (UTC)[reply]
I added some detail to the protection policy. Firefangledfeathers (talk / contribs) 02:41, 5 February 2024 (UTC)[reply]
@Johnuniq Yes, 72 hours was the consensus chosen there. CaptainEek Edits Ho Cap'n!⚓ 17:29, 5 February 2024 (UTC)[reply]

Long term semi of article talk?

WP:ATPROT does say that Talk pages are not usually protected, and are semi-protected only for a limited duration in the most severe cases of disruption. Are there cases outside of WP:CTOP where long term protection for an article talkpage would be within policy without the need for a larger discussion/RfC?

My specific example is Talk:Hacker. I can count on one hand the number of productive edits from IPs over the last few years, and there's a persistent problem with IPs either trying to hire computer hackers, advertising their own hacking services, or just random vandalism. Of the 477 total edits to the talkpage, 256 were either reverted edits or automated/semiautomated reverts of those edits. That's about 54% of the edits since the page was created in 2008, and the ratio is getting significantly worse over the last few years. I also went back and checked out the last 100 edits to the page (going back to April 2023), and only 3 were productive edits about the page itself for a whopping 97% vandalism/reversion rate.

I know semiprotection for article talkpages is frowned upon even short term, but it seems like there are some edge cases where it could be appropriate. The WordsmithTalk to me 18:53, 8 February 2024 (UTC)[reply]

I don't think you'll find anyone (other than the IPs) complaining about long-term semiprot for pages like this. Primefac (talk) 19:00, 8 February 2024 (UTC)[reply]
I agree, but the wording of the policy made me hesitate and discuss here first. Maybe it's worth adding a line to that section? Something like In rare cases where most non-autoconfirmed edits over an extended period are disruptive, long term semiprotection may be used. The WordsmithTalk to me 19:20, 8 February 2024 (UTC)[reply]
I was just thinking IAR until someone say something. Primefac (talk) 19:44, 8 February 2024 (UTC)[reply]
Trying a long, but limited, duration (like one or two years) first is often a good idea assuming shorter protections have been ineffective, but I agree with Primefac about IAR. I don't think we need to change that part of the policy at this point, but if we were to change it, I don't think it needs to be that wordy.
If you decide to go ahead, in some cases where this has been done, I've seen the protection log refer people to the Teahouse like this. Daniel Quinlan (talk) 20:59, 8 February 2024 (UTC)[reply]

File mover / Page mover

@Daniel Quinlan: Re Special:Diff/1210478149, they're not quite the same: to move a file you need to be an admin or file mover, to move a category you need to be an admin or page mover. -- John of Reading (talk) 07:47, 27 February 2024 (UTC)[reply]

Thanks. Without it being linked, I didn't see it being a different term. Fixed. Daniel Quinlan (talk) 13:56, 27 February 2024 (UTC)[reply]
Category