This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
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.
Most discussion seems to have stopped, and I think this RfC has reached its natural conclusion.
Summary: there is consensus to YUpdate the padlocks with grey shackles, without bias towards other discussions as to design specifics
Extended rationale:
There is an overwhelming majority of editors in favour of the new padlock designs. While sheer force of numbers alone does not determine consensus, this proposal is in a somewhat unique position of "I like this side more" to be a pretty valid rationale.
There were a total of 3 editors opposing this proposal.
Two stated that they had a preference for the old design.
One stated that they would support if the icons were removed. I weighted this opposition less because I felt it was more of an "implementation" issue, which I considered separately.
Most people who had an opinion either way stated that they preferred the version with the grey shackles, although I don't really buy (get it?) the assertion that Wikipedia could be mistaken for an ecommerce website without the grey shackles.
The question as to whether or not the padlocks improved accessibility was never really settled. As most editors supported the change anyway, this didn't seem to matter too much. As implementation wouldn't have decreased accessibility, the argument itself wasn't too important in the decision to close.
Much discussion was had over the specifics over the contents of the icons themselves.
Some editors preferred letters over symbols and vice versa. Boing! said Zebedee's suggestion that symbols were easier to learn than colours seemed to be generally agreed upon
Feedback was incorporated into the padlocks (viz. the symbols)
The discussion did not start with the padlocks that were finally agreed upon. While I think that most editors who supported would be generally happy with the final result, I believe that there should be no bias towards further discussion of specifics
Note that this doesn't mean that there should be another discussion - Zebedee's point that requiring another discussion would be needlessly bureaucratic is correct.
Page-protection padlocks are icons at the top right corner of protected pages. However, the current padlock designs have several flaws, many of which harm people who have visual impairments.
1. The padlocks were not designed for viewing at such a small size.
The edges on the icons have a white glow, which makes them appear to blend into the backgruond.
The shackle is thin and light, contrasting poorly with the background.
2. Many of the padlocks do not have adequate color contrast.
Per WP:COLOR, the contrast of text (or in this case, small icons) with its background should reach at least Web Content Accessibility Guidelines (WCAG) 2.0's AA level. This is because some readers of Wikipedia have visual impairments such as partial or full color blindness.
However, current lock icons like pending changes protection (light grey) and create protection (cyan) fails to meet the AA standards.
3. Most users cannot tell the type of protection each lock represents from a glance.
There are no visual aids that help people understand what the different padlocks mean.
This proposal redesigns the current padlock icons with more accessibility and minimalism in mind. Unnecessary elements such as textures and shadows are removed, and all of these redesigned icons have AA-level contrast.
Symbols are embedded in the padlocks to further help in identifying different locks. For example, upload protection now has an upload icon inside the purple padlock, and cascade protection, where pages transcluded onto the protected page are also protected, now has a link icon.
People have noted that these padlocks are similar to the ones used at Wikidata. I wasn't aware of that, but it would be great if the folks there implement the embedded icons too.
Alternative designs (padlock redesign)
@Ahecht: has suggested changing the shackles to grey to make them look more realistic.
Support, neutral/unspoken on shackle color (padlock icons)
I like the proposed new icons. They are crisp and mainly easy on the eye, plus it solves the problem that colors alone are no longer helpful since so many new forms of protection have been created. Minor change requests aside, I think generally we can support updating the look based on this proposal and discuss individual icons if needed. Regards SoWhy10:41, 25 October 2018 (UTC)
Pending whatever minor tweaks might be needed (and based on my comments in the discussion below), I'm happy to support this as a significant improvement. Boing! said Zebedee (talk) 10:55, 25 October 2018 (UTC)
Strong support, I don't make a big deal of it but this is one of the many Wikipedia things which don't work for me. The symbols mean the fact I don't see the colors is less of a problem. — Frayæ (Talk/Spjall) 11:17, 25 October 2018 (UTC)
Support. They are non-invasive and simple. It also solves the problem of being dependant on colour (i.e. black/white prints/screenshots, colour blindness, etc). Rehman11:21, 25 October 2018 (UTC)
Support in principle. Colors alone re no longer useful with so many different levels of protection. Some design tweaks based on discussion below may still be warranted though. MarginalCost (talk) 11:27, 25 October 2018 (UTC)
Support. Great effort here. Minor tweaks can be done, but updating these old icons to solve the outlined issues is a solid idea that refreshes an older outdated icon set. -- ferret (talk) 11:33, 25 October 2018 (UTC)
I am strongly supporting this proposal as they are more accessible and more colourful to make it obvious what the level of protection is. Pkbwcgs (talk) 11:57, 25 October 2018 (UTC)
Support but there may exist some non-obvious problems with their design. It is impossible to say without a full scale trial. Ruslik_Zero20:14, 25 October 2018 (UTC)
Support I love the new locks. However I would suggest that semi-protection has 'IP' in the lock (or similar, perhaps S for semi), because a plain gray lock is unclear in meaning on its own. Headbomb {t · c · p · b}21:07, 25 October 2018 (UTC)
Support - 1. Neutral/apathetic on grey shackles. 2. Prefer letters on the lock bodies. (For cascade protection, which I have never actually seen in the wild, use the chain link to avoid conflict with create protection.) For the most part, people will determine the type of protection by means other than what appears on the lock body: by the tooltip; by clicking on the icon which should take them to a full description of the protection type (as happens today); and to a lesser extent by color after some experience with the new icons. But, if we must put something on the lock bodies, let it be something that is more readily associated with the protection type. I think the letter M (for example) would be more likely to make people think of move protection than would a right-arrow. We're used to using graphic symbols I guess because of the widespread use of that on signs of all kinds. That's done so the signs can be understood by speakers of different languages. This is the English Wikipedia, all users are expected to have a certain level of competence in English, so language independence is not a consideration here and we should think outside that box. ―Mandruss☎04:03, 26 October 2018 (UTC)
As newly created pages are marked with an "N" in edit histories, I think an N could be used for the creation protection icon if desired.--John Cline (talk) 04:25, 26 October 2018 (UTC)
Support - as a small but clear improvement to the encyclopedia. I'm agnostic on the grey shackles. Thanks for your work on this! Ajpolino (talk) 06:49, 26 October 2018 (UTC)
Strong support - I deal with protected pages all the time since I work on edit requests and review pending changes. I am also moderately colorblind. With all of the locks together like in this proposal, I can tell them apart fairly well (though the semi and PC1 locks still look the same color no matter where I see them). With a lock alone at the top of a page, I have no chance. It's habit anytime I see a lock to mouse over it and check the popup. The more accessible versions would be much nicer. I agree that neither set of icons means anything if you don't already know what they mean, but I do know what they mean, and the existing color-coding might as well not exist. Make the shackles any color you want, put any symbol or letter you want on any of the locks - any of the proposals I see here would be a vast improvement for me. ‑‑ElHef (Meep?) 15:21, 26 October 2018 (UTC)
Support I often have to look twice (or hover over it) to be sure about a specific protection icon, especially when just quickly skimming over articles. I am sure GUI experts will be able to fine-tune minor details and tweaks. GermanJoe (talk) 17:48, 26 October 2018 (UTC)
Support Like the new versions, much more clear and noticeable. Personally I prefer the colored shackles, as I don't really think we need "realism" when the real point is to be as clear as possible. Keeping the shackle color the same as the body would mean we might be able to enlarge the letters/symbols to make them more readable while still having enough color to be identifiable. Gray shackles are merely aesthetic and add no informative value. However, either proposal is an improvement over the original. CThomas3 (talk) 19:28, 26 October 2018 (UTC)
Support these icons make it much more obvious what type of protection is being applied. They are also stand out slightly more, are easier and clearer to look at. --Tom (LT) (talk) 22:38, 26 October 2018 (UTC)
Support These newer icons are an improvement upon accessibility as far as meaning of the different lock-levels, although I too would prefer the person icon to be changed to an "S" as the extended protection and full protection already contains an E and an F. This is English Wikipedia, so having the letters makes sense. Spintendo 23:33, 26 October 2018 (UTC)
Support. May need some minor changes before implementation, but these are a big step up from the old ones in terms of design and accessibility. TeraTIX01:27, 27 October 2018 (UTC)
Excellent job here! This is a good idea. I don't buy the idea that if you don't know what the current ones mean, you won't understand what the redesigned ones mean. I didn't know what the colors meant for years, and I'm quite sure the symbols would have been more distinctive to me long before I finally started to internalize what the colors mean. It probably won't help new users much, but those who've been around for a month or two will have a much better shot of getting this collection of new locks. Kevin (aka L235·t·c) 09:10, 28 October 2018 (UTC)
I support this but I also think that if the padlocks are redesigned the other topicons like the featured and good article icons should be changed too. 🌸 WeegaweeK^ 🌸 10:49, 28 October 2018 (UTC)
Support These single 2D colour padlocks, with extra information included, are much more clearer. I find the current set of padlocks quite confusing. talk to !dave15:15, 28 October 2018 (UTC)
Support - these redesigned padlocks will make it clearer what protections are in place, due to the fact it would have a symbol that can clarify that. Kirbanzo (talk) 18:42, 28 October 2018 (UTC)
Fine Among other things, the current colors seem to want to signify something (except, who knows what) the new ones are marginally better in that regard (even if it were, 'yes, we really are trying to tell you something with this, not just dress up in colors') -- Alanscottwalker (talk) 12:27, 29 October 2018 (UTC)
Support New icons look way better (current design styles trend toward flatter, cleaner looks, as opposed to the early 2000s gradients on the current protection icons). The colors also are not accessible to people without full color vision, so the icons inside the locks are really helpful. – FenixFeather(talk)(Contribs)21:21, 29 October 2018 (UTC)
Support I can barely tell the difference between the current pending changes and cascading protection icons. The new icons clearly delineate what they are for. spryde | talk00:48, 31 October 2018 (UTC)
Support. This improves accessibility without impeding those who don't currently have an issue with the current set, so there are no downsides that I can see. Thryduulf (talk) 13:56, 1 November 2018 (UTC)
Support, with the proviso that Mandruss mentions above that letters are used, not symbols. As is said several times in the oppose section, the whole thing is non-intuitive or non-informative and requires exploration/explanation the first time one comes across it, but letters are slightly easier to remember or work out and, for example, i'm finding it quite difficult right now to tell the difference between the arrow for move protection, that for upload protection, and the plus sign for creation protection. Happy days, LindsayHello09:36, 4 November 2018 (UTC)
Support. I have the majority human level of color vision, but I've long found the current ones to not be clear enough. I find it impossible to remember what each color means, because I don't see them every day, so I always have to check the tooltip—the current color-coding provides no benefit to me. A little symbol or letter in the lock would make it much easier to remember what icon corresponds to what protection level, so I could tell at a glance. Also, the old ones just look excessively 3-dimensional and skeuomorphic to me. I have no preference for colored or gray shackles—I find that they look equally like shopping bags (or not), and that they look equally distinct from the other colors. I like the symbols on some of the proposed icons, but I'd also be OK with them all being letters. – PointyOintment ❬‽ · ✍❭03:58, 8 November 2018 (UTC)
Support: These seem more understandable than the old ones. This would improve accessibility, and not just for colour-blind people. Like, I looked at the current ones, and I didn't remember what white was, and then there's all those shades of blue. I don't really like the person icon for semi-protection though. Maybe a padlock slash two would be better. Or a padlock with a slash in the middle. The "semilock" that someone suggested (half dark-grey, half light-grey) might also work. Coloured shackles or grey? Maybe that could depend on the size? – Pretended leer {talk} 21:04, 9 November 2018 (UTC)
Support proposal as a whole but oppose proposed redesigns for some. I don't like how some padlocks are based on the first letter and some others are based on the kind of protection. Either way, it's pretty good and personally if the semi-protection was not just a person placeholder icon. Imo, it should be more contextual or the letter. I'd prefer keeping it like the standard protections (full/semi/PC) being first-letter basis and the other kinds being contextual. The current designs look pretty but lack uniformity. --QEDK (後 ☕ 桜)07:52, 11 November 2018 (UTC)
Support with colored shackles (padlock icons)
Note: This is only the people who explicitly stated their preference to the version with colored shackles.
These look great, and should be easier for all readers to understand. 28bytes (talk) 14:03, 25 October 2018 (UTC) (Adding: I prefer the single-color redesign to the version with the grey shackles, but either one is an improvement.) 28bytes (talk) 01:51, 26 October 2018 (UTC)
I prefer the single-color design over the ones with grey shackles to maximize the colored area. Single-color icons are clearer. feminist (talk) 16:19, 26 October 2018 (UTC)
Absolutely. I prefer the one without gray shackles, since single-colored looks better in my opinion (and probably because I'm used to flat designs), but I'll accept it either way, gray shackles or not. theinstantmatrix (talk) 20:54, 26 October 2018 (UTC)
Support - Although the symbols aren't all intuitive, the colors certainly aren't either, and it may increase accessibility for people with colorblindness or visual impairments. I don't see much value in the grey shackles, as they can hardly be distinguished at the size they will be used, and it's more important for an icon to be recognizable than realistic. Jonathunder (talk) 21:36, 29 October 2018 (UTC)
Absolutely. I prefer the one without gray shackles, since single-colored looks better in my opinion (and probably because I'm used to flat designs), but I'll accept it either way, gray shackles or not. theinstantmatrix (talk) 20:54, 26 October 2018 (UTC)
Conditional support with the gray shackes (as per File:Protection redesign - ahecht.png). They look more like locks and less like shopping bags. Shopping bags are often seen as icons on webpages selling things, and I'd hate to give the impression that Wikipedia is an ecommerce site. --Ahecht (TALK PAGE) 18:59, 25 October 2018 (UTC)
Support' grey version above, which are clearer. There also needs to be an S for semi-protection, and maybe the others should be converted to letters as well since there's only one overlap? ---- Patar knight - chat/contributions21:00, 25 October 2018 (UTC)
Support with preference for grey shackle versions: if it means that colourblind people will be able to use Wikipedia a bit better, although updating the templates may be a problem. Regards, User:TheDragonFire300. (Contact me | Contributions). This message was left at 02:46, 26 October 2018 (UTC)
Support with grey shackle While the letters won't allow people with no idea of protection to know it instantly, it'll still allow people learning which is which to do it easier (I at-least remember forgetting that the "gold" (actually really brown) padlock was full protection) Galobtter (pingó mió) 08:34, 26 October 2018 (UTC)
I oppose my comment being refactored in this way without any discussion and without having been notified. My original comment in support of redesigning the graphics can be found here. Ivanvector (Talk/Edits) 16:56, 30 October 2018 (UTC)
Support, with some preference for the grey shackle. I very much like the idea of both (a) improving accessibility, and (b) conveying which kind of protection it is. But I also have an alternative suggestion: we really don't need a different color for each one. The identifier inside each padlock accomplishes the distinction between one padlock and another, and many of the colors are not intuitively related to the kind of protection they represent. And personally, I feel like some of the colors look too candy-colored for a serious encyclopedia. I think it would be fine to make all of the new icons black on a white background (as in the office action example, and with a black shackle), and white in dark mode. --Tryptofish (talk) 20:47, 26 October 2018 (UTC)
Support, provided the shackles are grey per others' concerns that the original proposal looked too similar to shopping bags.
However, I would prefer dropping the letters from the full, template, and extended confirmed protection symbols and the protection by office action symbol. The letters are only understandable by those who would already know what the colour denotes and, with the exception of the office action one, they are all very common types of protection. Additionally, I would have never guessed the O to have been an O; it looks like a combination lock.
I would also be inclined to drop the person icon from the semi-protection symbol. The icon is also understandable only by those who would already know what the colour denotes. This is in contrast to, e.g., the move protection symbol. Its arrow icon's meaning might not be readily apparent to the average reader, but it would still be most useful to reminding an editor of its meaning given that one doesn't come across move protection too often. The other issue with the semi-protection symbol is that the person icon representing registered users really doesn't help the very common issue of people forgetting that IPs are human too. 142.160.89.97 (talk) 21:44, 26 October 2018 (UTC)
Support with grey shackles Much better, simpler and cleaner than the current ones, the letters seam like they could be helpful to some editors. – BrandonXLF(t@lk)02:08, 27 October 2018 (UTC)
Support great improvement. support for grey shackles versions with "O, E , T" same size/height and new "semi-protect of half diagonal light vs dark grey padlock icon. CASSIOPEIA(talk)09:33, 27 October 2018 (UTC)
Support as per my previous comment on the idea lab page. This proposal will be accepted easily since there are only three oppose comments out of the tons of support comments here. Grey shackles would look a lot better in my opinion. 344917661X (talk) 02:00, 26 October 2018 (UTC)
I support the icons' implementation, although I would prefer for minor changes to be made first (as below). Jc86035 (talk) 14:04, 25 October 2018 (UTC) Moved to section supporting grey shackles. Jc86035 (talk) 11:26, 2 November 2018 (UTC)
Support with grey shackles. Love the new design, especially with regards to making the protection level clear in a way that isn't just color. (Accessibility is important!) The grey shackles make it more clear that these are padlocks to everyone except those with achromatopsia so we're good on that front. To be honest, I had a knee-jerk dislike of them at first, but I realized it was just because I've been used to the old ones being around for.... what, a decade now? After I read the comments here and really thought about it, I got pretty excited about this! It's a nice, clean, modern redesign. cymru.lass (talk • contribs) 18:36, 5 November 2018 (UTC)
Oppose (padlock icons)
I prefer the current ones and think they look nicer, so I guess I’m opposing, but I also don’t see this as a big deal either way. Also, just as a note, I find both sets of icons equally uninformative unless you already know what they mean, so I’m really not getting the arguments for this on those grounds. Again, don’t think this is a big deal, but this is just a graphic redesign, and it’s not particularly informative to the non-insider reader. TonyBallioni (talk) 19:21, 25 October 2018 (UTC)
@TonyBallioni: The redesign is more informative because it doesn't solely rely on color. A colorblind user would be able to eventually learn the different icons with the redesign, whereas they might never be able to do so with the older design. – FenixFeather(talk)(Contribs)21:25, 29 October 2018 (UTC)
That’s not more informative: they’re equally indecipherable without knowing the key. It is more accessible, but the colourblind person still has to lookup the key. If it was more informative someone who knows nothing about Wikipedia would be able to look at them and tell you what they mean, and that’s still impossible. TonyBallioni (talk) 21:30, 29 October 2018 (UTC)
It is more informative to a color impaired user, is what I'm saying, in the sense that there is more information where there was none before. It can be more informative to a non-color impaired user as well. For example, I don't always remember what the blue, gold, and gray locks mean and get them mixed up, but the new icons are extremely helpful with reminding me what they are. Therefore, there is actually additional information. Obviously an icon is not going to magically tell you what the icons mean, though I think the non-letter icons are well chosen and generally do line up with usage outside of Wikipedia. – FenixFeather(talk)(Contribs)21:41, 29 October 2018 (UTC)
I disagree. I still view them as significantly more ugly with no added value, but I also don’t want to continue arguing over something that I don’t care that much about and that is going to pass, so this will be my final reply in this RfC. TonyBallioni (talk) 21:57, 29 October 2018 (UTC)
I prefer the current ones and think they look nicer - Yeah, me too. I just didn't want to be the first to say it. If you just put the icons in front of me and asked mt to tell you what they meant, assuming I hadn't seen them previously, I'd have no more clue with the new set than the old set. For example, this is my first time encountering the "office protection" padlocks. Never seen them before. The "o" on the new padlock gave me no more information to work out what it meant, than the blank black padlock did. I had to go work out what it was myself – note; I saw this yesterday before the links were placed. Mr rnddude (talk) 05:39, 26 October 2018 (UTC)
No. It isn’t. They’re equally as indecipherable unless you already know what they mean: so it’s the exact same as the current situation. This is obviously going to pass, but it’s not an improvement for anyone but admins who are trying to figure out if they need to change the protection level, and only then if they have trouble remembering that gold=full, grey=semi, and blue=ECP. The others are rare enough or obvious enough through the page history (PC), that it doesn’t matter what the design is as no one will remember it anyway. TonyBallioni (talk) 01:26, 29 October 2018 (UTC)
Isn't the point that the new ones are meant to be easier to see for those with vision impairments? What we personally like or dislike or what admins might prefer is presumably irrelevant, isn't it? Boing! said Zebedee (talk) 07:46, 29 October 2018 (UTC)
@TonyBallioni:Proposed redesign of protection locks under red-green colour blindness. 8% of males are colour blind, we should be using something other than colour to differentiate the lock symbols. While true that "They’re equally as indecipherable unless you already know what they mean"; once you know what they mean, the new symbols ARE decipherable, while the old symbols may just be indistinguishable from each other due to colour blindness issues. See the comparison image at right which indicates what the padlocks look like to somebody who has red-green colour blindness, the symbols give a way of distinguishing that is independent of colour. — Insertcleverphrasehere(or here)08:10, 29 October 2018 (UTC)
I was referencing point 3 of the proposal, which is what I took the “easier to understand” supports to be referencing, not the accessibility issue. I’m still not personally sure it’s worth moving to significantly uglier graphics over, and think there is likely a better way to handle this from an accessibility standpoint (mouseover providing a description or something like that or even just a better design.) TonyBallioni (talk) 12:06, 29 October 2018 (UTC)
Another point that's just struck me, while looking at some tiny icons on my Mac, is that computer interface technology in general seems to be moving away from 3D appearances and fuzzy/shaded borders for very small graphics, because it is harder on visual impairments, and is using more symbols that might immediately look cryptic but which can be relatively easily learned. Boing! said Zebedee (talk) 12:27, 29 October 2018 (UTC)
That's true. Of course, even though I supported I quiet agree with Nihlus' point. And of course, I would prefer the minimalist style that get rid of the symbols and any shading like the ones used on Wikidata. Clear boundaries and distinctive colors.–Ammarpad (talk) 12:41, 29 October 2018 (UTC)
Yeah, those are fair points. I suppose my (Quixotic) view here is that while you could make a case for a redesign this particular redesign isn’t the one. I’d prefer something with colours that don’t look like a candy shop and where the icons don’t look so bleh. Clearly in the minority on this though, and it’s not that big a deal. TonyBallioni (talk) 12:50, 29 October 2018 (UTC)
@TonyBallioni: I guess that is a reasonable gripe with the current icons. Given the support section is completely full of various suggestions of different opinions on what the symbols should be (and in the discussion below), I would consider that there is support that the padlocks should change to be more accessible (differentiation other than by colour), but not necessarily that this specific set of lock images is the final draft). Indeed the locks have changed substantially while this conversation has been ongoing. I suggest that the overall !voting be closed as a SNOW support for changing the locks to be more accessible, but that we have a new discussion on what exactly the locks should look like. As is I think that the various designs look very disjointed, some with letters, some with rather arbitrary symbols, etc., and a more focused discussion on various options for what they might look like is advised. — Insertcleverphrasehere(or here)16:44, 29 October 2018 (UTC)
Do we really need that much bureaucracy? The various tweaks suggested during the course of the discussion are relatively minor, and there's a strong consensus for something close to what has been suggested. I think there's sufficient consensus to just change them to the most recently tweaked proposed versions, whether that's the grey shackle or the coloured shackle versions - whoever closes can decide where the consensus most closely lies. Then minor tweaks can just be made via the usual editing process, and a new discussion would surely only be needed if there's significant disagreement or if someone wants to suggest a radically different set of icons. Boing! said Zebedee (talk) 16:53, 29 October 2018 (UTC)
Presumably making tweaks as needed would require further discussion and consensus. Why not do that now rather than later? The effort is the same, the difference is in the amount of disruption. One change to the icons is better than two. Further, I prefer letters for all, I think my case for that is strong, and I don't think it has received a full hearing because of all the other discussion going on. That's the problem with doing !voting and development concurrently, which is what WP:VPI tries to address with little cooperation from the community. ―Mandruss☎17:11, 29 October 2018 (UTC)
I'm also a fan of letters for all (with the pesky issue that we have two 'C's). While I like the Upload Arrow, and the Move arrow as natural symbology, letters make for the best cohesiveness and identifiability. But trying to discuss in the middle of all this is pretty difficult if not impossible. — Insertcleverphrasehere(or here)17:56, 29 October 2018 (UTC)
The E, T and O letters should have the same height.
The arrow of the upload protection icon should be a little taller since it's currently a little difficult to see what it is.
I think you should make the images squares (like the originals), since this would make the images easier to resize. You might also want to fit some of the objects to the 20×20 "grid".
@XYZtSpace: Thanks. I think there are still some issues with the letters, though. The letters should probably have the same stroke width (i.e. the four bars making up the E should be the same width as the two bars forming the T); and the letters probably should be a little narrower – the E and F look a bit stretched out right now. Maybe you could try [width-to-height ratios] 3:4 or 1:1.618. Jc86035 (talk) 18:19, 26 October 2018 (UTC)
For the Upload protection one, just have a vertical arrow rather than the line at the bottom (At first glance I thought this was a ± sign). What is the Icon on the cascade protection lock supposed to be? Would it be better to have a 'C' here instead? — Insertcleverphrasehere(or here)09:02, 25 October 2018 (UTC)
Do the colors meet accessibility requirements when readers invert their displays? (light text on black background)? Why is semi-protection different from all of the rest? Why are there no tool tips? —Trappist the monk (talk) 09:21, 25 October 2018 (UTC)
I think this is a great idea, with a little refinement as suggested in this discussion. I have added tooltips to the Old/New table. Alt text is still needed. – Jonesey95 (talk) 10:15, 25 October 2018 (UTC)
Judging by my eyes I think the icons should be fine with inverted colors. I left Semi without an embedded symbol because it is the most common protection [citation needed] and most people should be familiar with it. – XYZt (talk | contribs) –15:10, 25 October 2018 (UTC)
Oh. Thought by "inverted colors" you meant high contrast mode. With black bg only, I think a different set of images will be needed. Either that or implement a white outline that is invisible normally but shows up in dark mode. – XYZt (talk | contribs) –17:01, 25 October 2018 (UTC)
My first thoughts are that they look a lot clearer and crisper than the old ones. Even without any visual impairment other than age-related long-sightedness, I find them significantly easier to see. Most of symbols on them were not immediately obvious to me, but it's much easier to learn and remember what symbols mean than what colours mean, so I see that as a positive step forward too. Boing! said Zebedee (talk) 09:26, 25 October 2018 (UTC)
I agree with Boing! said Zebedee's assessment that learning symbols is easier than colors. This would seem to follow MOS:COLOR's suggestion that color not be the only method used to convey important information. The use of a colored lock symbol seems to pass that requirement—in that the lock is a symbol itself—but because there are different lock levels, the use of a third symbol matched to a legend would be an improvement. Spintendo 10:15, 25 October 2018 (UTC)
Maybe the third symbol (semi-protection) could be a half-filled padlock (indicating the "semi" status)? Regards SoWhy10:54, 25 October 2018 (UTC)
(edit conflict)Just add an "S". It's already a little odd that the semi is the only one without an icon. I'd actually probably just prefer letters for all of them rather than symbols. We have the added benefit that (if you use O for office), each starts with a unique letter other than Create and Cascade. GMGtalk11:04, 25 October 2018 (UTC)
@XYZtSpace: At the small resolution I think the "person" icon looks a bit deceptive – I thought it was a normal keyhole at first. I don't know what would be better, though. Jc86035 (talk) 18:57, 26 October 2018 (UTC)
Further along that path, change the slashed circle in the fully protected icon to an 'F'. Similarly, change the move protection arrow to an U+003E>GREATER-THAN SIGN (>, >) or U+232A〉RIGHT-POINTING ANGLE BRACKET and rotate the selected character 90° ccw for upload protection. Small detail at small rendering size is too hard to decipher. —Trappist the monk (talk) 11:13, 25 October 2018 (UTC)
Done for Full Protection though I still think that icons should be used over letters, we just have to find the right ones; will replace arrows with chevrons & rmv upload dash tomorrow. – XYZt (talk | contribs) –06:50, 26 October 2018 (UTC)
However, the current padlock designs have several flaws, many of which harm people who have visual impairments. Harm? Really? Are you really claiming that those of us who are visually impaired will suffer further degradation should we chance to look upon the old icons? Hyperbole has its uses, I suppose, but not here. —Trappist the monk (talk) 11:05, 25 October 2018 (UTC)
I suggest that each symbol should also be accompanied by a mouse-over text explaining what it does. E.g., the "cascade protected icon" should make text appear that explains in one sentence what cascade protection is, and provide a hyperlink to the policy page that explains it. Sandstein 11:34, 25 October 2018 (UTC)
Should we consider changing some of these colors while we're at it? Taking a look at a basic color-blind filter, full protection and move protection end up with basically the same color, as do template, pending changes, and cascading protection. Fixing the first set would be higher priority, since those are used more commonly. MarginalCost (talk) 11:38, 25 October 2018 (UTC)
Some of the suggestions have to do with that the icons have changed a bit from presented at VPI (e.g crossed out circle for full protection padlock, addition of E to extended confirmed padlock). Also VPI has the third the watchers that VPR has. Galobtter (pingó mió)
Also VPI has the third the watchers that VPR has. Precisely. If the community is not going to use VPI as intended to a much larger degree, we should get rid of it as unjustifiable complexity in the environment. Way off topic, of course. ―Mandruss☎11:51, 25 October 2018 (UTC)
Not sure if this is the correct place for this, but would it be possible to add some CSS or JS to make the icon enlarge when hovered over? Just to make it even easier to see what the icon is? zchrykng (talk) 14:40, 25 October 2018 (UTC)
If you want to know the type of protection, that's the purpose of the tooltip. But if you really want a better look at what's on the front of the padlock, click on it for a larger version. I would oppose adding any size and complexity just to save you that click. ―Mandruss☎15:34, 25 October 2018 (UTC)
If you go to Preferences → Gadgets and check "Navigation popups" under the Browsing header, you will get a considerably larger preview of the icon when you hover on it. I recommend you give that a try.--John Cline (talk) 15:55, 25 October 2018 (UTC)
While I have no specific suggestion for changing colors, a complete overhaul of color scheme would be good if it helps create a more clear and understandable structure. It might be good to go with all letters or all symbols, instead of a mix. Perhaps make semi-protect / extended-protect / full-protect into a clear and visible sequence of some sort. The full protect symbol makes sense, but the color feels particularly confusing. T was clear for Template, but I imagine { instead. For semi I imagine thin diagonal white lines, making it more transparent or "semi". Create and Move were easy to guess. The upload symbol was confusing. A plain up arrow would be better. The pending symbol makes sense, although I was stumped when I tried to guess. If we want a symbol for office, maybe an ! or big X. Cascade wasn't clear at first. It makes sense when explained. Down arrow was an interesting suggestion and it extends the pattern of arrow symbols. Alsee (talk) 16:28, 25 October 2018 (UTC)
The problem is with the limited height, not width. Curly brackets are thin enough that the width of three of them combined can fit in the padlock width. However, the limited height of the padlock and the tallness of the brackets means the brackets have to be squashed down, which makes them resemble less like brackets. – XYZt (talk | contribs) –18:22, 26 October 2018 (UTC)
Color: I kinda miss the red fully protected icon. That red color was declarative; the fuzzy brass colored lock, meh, not so much. I have suggested elsewhere in this discussion that move and upload protection might be marked with '›' or '>' (perhaps also consider U+3009〉RIGHT ANGLE BRACKET). We could extend that idea to the cascade lock by doing pairs of those characters: '››', '>>', or '〉〉'. Alternately, there are these: U+300B》RIGHT DOUBLE ANGLE BRACKET and U+00BB»RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK (»).—Trappist the monk (talk) 11:29, 26 October 2018 (UTC)
Locks with gray shackles look less like shopping bags
It was mentioned briefly above, but I vastly prefer the versions with grey shackles, as they look more like locks and less like shopping bags. Shopping bags are often seen as icons on webpages selling things, and I'd hate to give the impression that Wikipedia is an ecommerce site. --Ahecht (TALK PAGE) 16:47, 25 October 2018 (UTC)
The new version has a problem in that the top padlock and the third padlock down now look exactly the same. Why does the top padlock no longer have a symbol? — Frayæ (Talk/Spjall) 17:58, 25 October 2018 (UTC)
Looking at the proposed icons, they do not appear to render uniformly; Full, Pending, Office, and Cascade look bigger than the others, I tweaked the sizes in the table marked "Alt1", and believe they are a bit better there.--John Cline (talk) 19:02, 25 October 2018 (UTC)
@John Cline: I was changing the size of the padlocks based on a suggestion above, which is temporarily making the sizes inconsistent. they are fixed now and I removed your table.
As green symbolizes an action is possible, and the point of a protection icon is to restrict actions, should the green move-protection padlock be changed to orange? – XYZt (talk | contribs) –23:41, 25 October 2018 (UTC)
@Funplussmart: Superprotect did not use a padlock, since it was only used on one page (not on the English Wikipedia, it was on the German Wikipedia in this edit) and that was the common.js page, which transcluding templates (like a protection template) would either be impossible or probably a very bad idea. SemiHypercube✎01:15, 29 October 2018 (UTC)
@XYZtSpace: I think the no symbol looked better than the "F". I think the no symbol would at least be a bit clearer to a new user who happens upon it, since "F" on its own doesn't really impart the same "no entry" meaning. Jc86035 (talk) 17:19, 26 October 2018 (UTC)
The point of the symbols is to differentiate the protection levels when the colors can't. Though I think I might change it back to the 🚫 icon, but that doesn't look very clear when scaled down. – XYZt (talk | contribs) –18:15, 26 October 2018 (UTC)
@XYZtSpace: You probably have so many pings right now, but do you think you could also upload an SVG version of my suggestion for the office-protected padlock with the WMF logo on it? SemiHypercube✎17:33, 26 October 2018 (UTC)
Or possibly put the "no" symbol on the office lock, since office protection tends to be the "thou shalt not touch" variety. ‑‑ElHef (Meep?) 20:52, 26 October 2018 (UTC)
Agree with Trappist the monk. That, and the x-con lock was blue to start with, so there probably isn't a connection between that and the flag of Israel (would you rather have the lock be blue, white, red, green, and black as a compromise, even though 30/500 protection isn't just used for Arab-Israeli conflict-related articles anymore?) SemiHypercube✎16:15, 27 October 2018 (UTC)
A good and a bad suggestion. The pending changes protection should contain an eye like the user right icon, because check marks have been historically written with a pencil on a piece of paper, which is the NPR user right's icon. Full protection should contain a mop. wumbolo^^^13:46, 27 October 2018 (UTC)
The horizontal lines of E are not that long, and in most fonts the middle line is slightly shorter (see E). The lower horizontal line of F is slightly shorter (see F). O is hardly ever a perfect circle (see O). Particularly at such a small size, such details have a very significant effect on legibility; just ask any professional typographer. ―Mandruss☎09:30, 28 October 2018 (UTC)
No offense intended, but it's apparent that you're fairly clueless about the subtleties of letter recognition. You don't improve recognition by distorting overall shape. ―Mandruss☎08:38, 30 October 2018 (UTC)
@XYZtSpace: Thanks. The new "O" is indistinguishable from a perfect circle at that size, and there appears to be room to elongate it more, but I'll settle for the other two improvements. ―Mandruss☎06:45, 4 November 2018 (UTC)
Considering the Office Actions icon is white in Dark Mode, why not make it red instead of black? Red indicates a serious problem. ANDROS1337TALK04:40, 30 October 2018 (UTC)
I think the alt text for semi-protection should be changed from This article is semi-protected until... to Register an account to edit this article! to encourage users to edit instead of redirecting them to the more technical page protection policy page. – XYZt (talk | contribs) –05:11, 30 October 2018 (UTC)
Hate to rain on this, but the "more yellow" version has very poor contrast. It needs to either be a darker shade to provide better contrast with the white background, or have a dark border of some kind, to meet WP:ACCESSIBILITY. Ivanvector (Talk/Edits) 17:28, 9 November 2018 (UTC)
As of November 3[update], there has not been any additional discussions for over 3 days. There is a 96.2% support for the main proposal (75/78) and a 75.9% support (22/29) for the grey shackles variant. It seems like there is a strong consensus for the main redesign and a mediocre consensus for the grey shackle version. When will the switch occur? – XYZt (talk | contribs) –05:19, 4 November 2018 (UTC)
@XYZtSpace: It's pretty obvious that the majority of people want the new padlocks, but what isn't obvious is wether people want the new locks to have grey shackles or coloured shackles, so I would suggest doing a separate proposal for voting on which type of shackle should be used on the new locks. 344917661X (talk) 17:46, 10 November 2018 (UTC)
As a colorblind user, I don't have any problem with the current padlock system. The problem with using color to convey information is that it's generally done in place of conveying it in some other manner, whether in text or in images. With the current padlocks, however, this isn't a problem — you can always generate a tooltip to see what the protection level is, or you can attempt to edit the article. Either you'll be blocked from doing what you're trying to do (and you'll get a link to the protection log), or you can check the page history and view the logs. (If you don't know how to do this, and you're able to edit a page, you probably don't know that the page is protected in the first place and don't care.) Moreover, there are just so many padlocks already that it's hard to keep track of them; even if I could tell the difference between purple and blue, or gold and olive (I can't), I'd have to check because I just don't remember what's what. Nyttend (talk) 02:21, 5 November 2018 (UTC)
I was a qualitative researcher in schools for several years. I once heard a high school teacher, when describing source reliability, refer to the "locks" on Wikipedia articles as denoting quality, meaning that the pages are vetted/protected. I wonder if the lock icons are altogether the wrong metaphor. (not watching, please {{ping}}) czar17:35, 10 November 2018 (UTC)
Per my comment, I think we should have uniformity in the padlocks atleast on the distinction of the kind of protection, because the semi-protection and PC padlocks are still pretty vague (PC not as much). I think we keep the standard protections (full/semi/PC and maybe even ECP) on first-letter basis and the rest contextual. --QEDK (後 ☕ 桜)07:55, 11 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I found about the new icons today. I would like to point out that templates such as {{Extended confirmed topicon}} are still using the old icons. P.S. If they are implemented, I'd suggest the new icons be just an unlocked blue lock, rather than a blue lock + Wikipedia globe. Hdjensofjfnen (♪ Oh, can I get a connection? Alternatively, trout me.) 01:56, 14 November 2018 (UTC)
I like it, now for Template (I'll do it)! Not for the topicon though, fiven the differences, but I'm sure the unlocked icon will be useful somewhere. ∰Bellezzasolo✡Discuss12:27, 15 November 2018 (UTC)
I agree with Bellezzasolo that this is not suitable (by itself) for the topicon, although I like the design and it should be useful. - tucoxn\talk16:58, 15 November 2018 (UTC)
Some people are very sensitive about their topicons, if changing the icons around building in a 'legacy' switch is advised! — xaosfluxTalk18:36, 15 November 2018 (UTC)
(edit conflict) For autoconfirmed and extended confirmed user topicons, I'd say use the key and the symbol, but put the symbol next to the key, not on a padlock. The open padlock could be misunderstood as "This page has this protection, but because you're autoconfirmed (or extended confirmed), you can edit this it." A key and a symbol probably won't get misunderstood that way. – Pretended leer {talk} 18:37, 15 November 2018 (UTC)
"This page has this protection, but because you're autoconfirmed (or extended confirmed), you can edit this it." That could actually be a feature. IIRC the mobile version gets rid of the lock icon if you have the rights to edit the page. – XYZt (talk | contribs) –19:43, 15 November 2018 (UTC)
When you go to protect a page, the banner has the "Full Protection" icon by default. This had me kind of confused because it looked like the page was already protected. Eventually I figured out it the icon was just being used in a generic sense. Perhaps we need another "generic protection" icon which doesn't correspond to any particular level? -- RoySmith(talk)19:01, 16 November 2018 (UTC)
Thanks for that. I think, however, we'd do better with no symbol in it. It's a little hard to make out exactly what the symbol is. In retrospect, it's obviously a keyhole, but at first glance, it looked like a letter but I couldn't quite make out what letter. The plain lock with no symbol would be clearer. -- RoySmith(talk)22:05, 27 November 2018 (UTC)
Just found this RFC. If the new icons are better for colorblind editors, great, but it probably won't benefit readers, and the supporters were obviously influenced by preconceived notions about "modern design" and "new looks". I doubt non-editing readers even notice those icons (my father doesn't). I don't see any evidence presented here about what they perceive on pages, what's useful to them, and whether there really are colorblind readers who notice the icons and can't tell them apart. I hope someday Wikipedians let go of their unrealistic ideas about what's best for "the readers". Not that this problem is unique to them, of course... ♫ekips39(talk)❀05:42, 17 November 2018 (UTC)
The "edit page" button doesn't directly benefit readers either, yet we keep that around. I read Wikipedia much more that I edit it, but I'll still fix tyops when I see them. I never managed to learn what the old icons meant, and now I don't need to as the meaning is clear. There is nothing wrong with making small positive changes, be it to articles or Wikipedia itself. — crh23 (Talk) 22:16, 28 November 2018 (UTC)
@XYZtSpace:@Bellezzasolo: Hi while reviewing semi-protect edit requests I used the haverights version of {{ESp}} which produced the icon was this by design? [3] Shouldn't there be a icon created called "Semi-protection-unlocked" based on this > to avoid confusion between the new types of icons? ♪♫Alucard16♫♪11:30, 23 November 2018 (UTC)
Latest comment: 5 years ago5 comments2 people in discussion
Requests for page protection is the venue where editors request protection for pages, and admins review the requests and implement or reject them. It is an important venue for the encyclopedia, and activity there is often reviewed during RfAs. Personally, as someone who feels protection is often over-applied, I am frequently interested in finding out the context in which page protection was originally applied. I imagine that admins looking to protect a previously-protected page are interested in the context of its previous protections. All these purposes are frustrated by the inexplicable fact that RFPP only has a rolling 7-day archive, after which you are left to sift through the page history. I was inspired to come here by my experience finding the RFPP request that resulted in the current protection of International Space Station, and I challenge anyone thinking that the page history is a good enough record to do the same.
I propose that RFPP be archived in a complete fashion. Building retrospective archives would be awesome, but to avoid technical issues this proposal is specifically for the archiving of future requests. Implementation could look a number of different ways, but I think the ideal scenario would replicate the WP:PERM archive (surely a less important thing to archive than RFPP!), where MusikBot sorts completed requests into "Approved" and "Denied" and archives them by date. If I can auto-archive my talk page, and we can archive requests for rollback, then Wikipedia can archive its page protection requests. A2soup (talk) 17:40, 28 November 2018 (UTC)
Do you know how to access the protection log for a page? You don't have to use the page history, and RfPP requests themselves contain no information that can't be found in the protection log, so I don't see what the point of permanently preserving every single one of them would be. Swarm talk 21:34, 28 November 2018 (UTC)
I know very well how to access the protection log. I don't at all agree that RfPP requests contain no information that can't be found in the protection log. Just very cursorily looking at our current RfPP, I see (excerpts):
Drive-by IP vandalism due to rumors swirling in the college football world right now.
not sure if full is best but considering ec/compromised accounts are messing around significantly, requesting something a bit stronger.
The issue should mostly blow over in a month or two, so that period of protection ought to be enough.
All of these are valuable information about the context of the protection that is lost in the log entries. This is not to mention declined protection requests that obviously leave no log entries but may be important to access later. A current example: Declined, they stopped after warning. Please let us know if disruption resumes.A2soup (talk) 21:43, 28 November 2018 (UTC)
Okay. Well, I'll drop a note by WT:RfPP and see if anyone has any issues with this. If not, this can likely just be handled as an uncontroversial technical request. Swarm talk 21:35, 29 November 2018 (UTC)
Latest comment: 5 years ago14 comments7 people in discussion
Not sure if this is the best place to start this thread but going to give it a try. For some time I've been kicking around the idea of a better chat platform for Wiki users who want to have real time communication with eachother. I was considering starting a Slack workspace and was curious if anyone would be interested in joining? Just gauging interest. --Zackmann (Talk to me/What I been doing) 18:10, 21 November 2018 (UTC)
We already have a chat platform for Wiki users ... It's called a talkpage, Sorry for the bluntness but I don't really think we need a chat platform when we have talkpages..... –Davey2010Talk18:38, 21 November 2018 (UTC)
Such a workspace would be bending or at least testing policy; per Wikipedia:ConsensusDiscussions on other websites, web forums, IRC, by e-mail, or otherwise off the project are generally discouraged, and are not taken into account when determining consensus "on-wiki". In some cases, such off-wiki communication may generate suspicion and mistrust. Most Wikipedia-related discussions should be held on Wikipedia where they can be viewed by all participants. we shouldn't use offwiki venues unless there is a good reason for, and regular article work almost certainly does not qualify. Jo-Jo Eumerus (talk, contributions) 19:31, 21 November 2018 (UTC)
I think "are generally discouraged" probably should be removed as it does not add to the point of the policy, and almost certainly doesn't take into account the current reality of how many different ways there are to communicate about Wikipedia. The sentence would objectively read better as Discussions on other websites, web forums, IRC, by e-mail, or otherwise off the project are not taken into account when determining consensus "on-wiki". I also don't think Most Wikipedia-related discussions should be held on Wikipedia where they can be viewed by all participants. is framed particularly well or particularly necessary either. --Izno (talk) 19:35, 21 November 2018 (UTC)
I would personally prefer that it be made clear that the only prerequisite for participating fully in community discussion is access to the web site. I'm not sure if a rewording of the last sentence is needed to ensure this. isaacl (talk) 22:36, 21 November 2018 (UTC)
I think probably we should have the converse of the first sentence (with my suggested removal) or similar to enter into that same sentence, rather than the weak item at the end. Something like "Consensus is developed on Wikipedia by editing its pages and on its talk pages by discussing. Discussions elsewhere—i.e., on other websites, web forums, IRC, by e-mail, or otherwise off the project—are not taken into account." --Izno (talk) 23:04, 21 November 2018 (UTC)
My experience with IRC (granted, less than many others, but an occasional lurker for some years) is that #wikipedia-en is largely a social venue. There's some pointing to vandalism, problematic new pages, talking about Wikipedia goings-on, but it's not where substantive discussions happen such that it might purport to constitute some part of the consensus-building process (responding to Jo-Jo's point). There's the occasional canvassing, but it's sufficiently well populated with people who understand off-wiki coordination for that sort isn't ok. It's useful sometimes if you see someone there that you're involved in a discussion with, to hash something out directly (presuming it's something that doesn't involve other people), but other times I wonder about its usefulness. Right now people are talking about music, the death of George Bush, and commiserating about spending time on Wikipedia. In other words, it's socializing. That's not a bad thing, to be clear; it may help community (even if a particular subcommunity of IRC users). But I wonder if there's a need for more of that. What would happen in such a Slack channel? Would it be another place for socializing, or do you foresee other applications? Would it be the same as IRC but less....ancient? I use Slack for other purposes and would likely join to check it out, but I'm not sure what it adds. — Rhododendritestalk \\ 07:04, 1 December 2018 (UTC)
I'm surprised nobody's objected that Slack is closed-source and can be shut down at any time by the company, whereas IRC is open-source. (I use IRC very frequently, so I'm quite biased here, but anyway...) Enterprisey (talk!) 03:52, 2 December 2018 (UTC)
Should administrators be able to unblock themselves?
Latest comment: 5 years ago177 comments70 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As raised on this thread at WP:BN, it has been questioned if we should still allow admins to unblock themselves. Therefore, I am proposing three versions, based on what was stated:
Clarification I'm not talking about policy, I'm talking about the technical ability (the (unblockself) permission) to self-unblock. SemiHypercube✎20:29, 23 November 2018 (UTC)
Er, what? Version C is pretty much diametrically opposite to the status quo, which is Version A other than in the case of self-blocks, as spelled out in weary detail at WP:NEVERUNBLOCK; if an outright vandal were to compromise an admin account and block me with a block summary of "fuck you" I'd still not be allowed to unblock myself. If you're asking us to recode MediaWiki to make it technically impossible to self-unblock, that's not going to happen, as we're not the sole users of the software and some smaller wikis with only one admin need the technical ability to self-unblock in the case of mistakes. ‑ Iridescent15:01, 23 November 2018 (UTC)
@Iridescent: my reading of this is that it is about technical measures. And it should not be hard to remove the 'unblockself' permission from the sysop group if we really wanted to for just our project. — xaosfluxTalk15:17, 23 November 2018 (UTC)
Removing unblockself could create a security hole if a rogue or compromised admin manages to block all other (active) admins. Doubly so since apparently phab:T19014 implies that blocked bureaucrats would not be able to stop the compromised account. You'd have to wait for steward action which would prolong the time it takes for damage to be constrained. Also, added a phab task where this RfC question is being discussed. Jo-Jo Eumerus (talk, contributions) 15:24, 23 November 2018 (UTC)
@Jo-Jo Eumerus:, but with 'option B' above, a blocked crat (who is also an admin) could unblock themselves, then block the offender, then start unblocking admins who could then in turn unblock other admins. — xaosfluxTalk15:29, 23 November 2018 (UTC)
It seems like common sense to me that if there is a clear cut case of a compromised admin account or an admin gone rogue blocking numerous other admins, an exception to the prohibition on self-unblocking should be in place. Otherwise, in the course of more normal circumstances, neither an admin nor a 'crat should be able to self-unblock. bd2412T15:38, 23 November 2018 (UTC)
@BD2412: I think this is about 'technical controls' not policies. Currently the only practical ways to stop a rogue admin is: (a) desysop them, (b) get a steward to globally lock them. — xaosfluxTalk15:42, 23 November 2018 (UTC)
Version B, assuming that we're talking about technical capabilities. The only generally acceptable reason for an admin to unblock themselves is if they self-blocked, and there's really no reason to do that. Self-blocking by mistake or to enforce a wikibreak is easily rectified by pinging another admin, and we have test accounts for admins to test the block functions. An admin blocked by a rogue account can and should contact a 'crat immediately. The community has already basically strongly rebutted all other previous and potential uses of self-unblock; there is no good reason for it to be available, and several very good reasons why it should not. But as Jo-Jo Eumerus and xaosflux already suggested, disallowing 'crats from self-unblock is a Bad Idea. Ivanvector (Talk/Edits) 15:46, 23 November 2018 (UTC)
Can we get some stats on how often admins unblock themselves, and under what circumstances? The only bad self-unblock recently has come from Fred Bauder. If there has even been one legitimate self-unblock between now and whenever the last bad one was before Fred, I would be hesitant to remove this permission. -- Ajraddatz (talk) 16:38, 23 November 2018 (UTC)
@Ajraddatz:quarry:query/31445. Of the other 8 self-unblocks since 2017-01-01, 4 are undoing accidental self-blocks, 2 are undoing self-blocks for retirement/wikibreaks, and 2 are undoing self-blocks made without any comment. Anomie⚔19:55, 23 November 2018 (UTC)
Status quo our current policy works fine. One person self-unblocking themselves is not a big issue that we need a large RfC on. Admins occasionally do block and unblock themselves and that's perfectly fine. There's no real need for any sort of technical controls such as removing the ability, because self-unblocks that violate policy happens really rarely, and when it does, no real harm is caused. Galobtter (pingó mió) 17:01, 23 November 2018 (UTC)
I agree that the status quo works just fine. As a practical matter, when I first became an admin, the first user I blocked was myself, to explore how the tool worked. And, then (after a vaguely amusing thread where I asked for help), I unblocked myself. It's not entirely clear if this proposal is intended to address can (as in, the software allows it), or, may (as in, policy allows it). Ether way, what we've got now needs no modification. -- RoySmith(talk)17:14, 23 November 2018 (UTC)
Oppose technical restriction – I oppose any technical restriction on self-unblocking for one reason. That's because the bright line that exists is useful for weeding out bad administrators. All administrators have the ability to unblock themselves, but very few will ever actually use that power. Any administrator that is bewitched by the temptation to use it to try and get out of a block placed by another administrator clearly doesn't deserve the administrator bit. The status quo is, in-and-of-itself, a test of fitness to serve. We trust administrators to be able to use their tools responsibly. If they cannot do so, they should be removed. RGloucester — ☎17:15, 23 November 2018 (UTC)
Status quo – No rationale has been provided for the need to remove the technical ability to unblock yourself as admin. Unblocks in violation of WP:NEVERUNBLOCK can be handled by desysops as it is done right now. --AFBorchert (talk) 17:26, 23 November 2018 (UTC)
Keep as is Admins should have the technical ability, but (by policy) are generally not permitted to self-unblock (although I can't see why restoring talk page or e-mail, if needed is generally OK). Crouch, Swale (talk) 17:31, 23 November 2018 (UTC)
Status quo - the timing for this is interesting. Old admin accounts are being hacked and blocks to active admins applied. They should certainly have the ability to reverse this trolling. Flare ups like the the that brought this proposal about can be dealt with on an individual basis. MarnetteD|Talk19:53, 23 November 2018 (UTC)
No reason to change. What if someone finds an admin's password (two examples in the last 48 hours) and uses a script to block every other admin? Johnuniq (talk) 22:42, 23 November 2018 (UTC)
I assume in such a situation, the fix would be for a developer to do some direct database manipulation to block the rogue user and unblock all the admins. -- RoySmith(talk)04:37, 24 November 2018 (UTC)
In 2015, when we were doing the batch adminbot blocks for the Orangemoody socking case, it took 14 minutes to block 381 accounts, and it was blocking based on an account list posted on enwiki; it's my understanding that blocking was throttled to 30/min. I'm pretty sure if we suddenly saw 30 accounts a minute being blocked, someone would be able to get it globally locked within the first 3-5 minutes of action, and I'm also sure that blocking the bad-guy account would disrupt the process, as well. But it wouldn't take very long to unblock, especially if someone had an adminbot handy. Risker (talk) 05:18, 24 November 2018 (UTC)
With Version B, if every other admin were blocked, a bureaucrat could unblock themselves and then desysop the rogue/compromised admin account and unblock the previously blocked admin. SemiHypercube✎18:06, 24 November 2018 (UTC)
Status quo - The number of appropriate self-unblocks (i.e. for self-blocks) far exceeds the number of inappropriate ones. This hasn't really been a serious issue for years, and I've long considered not self-unblocking to be like a cardinal rule of being an administrator, to the extent that it begs the question: if we can't trust an administrator not to unblock themselves, then why should we trust that user to be an administrator at all?Mz7 (talk) 00:09, 25 November 2018 (UTC)
Striking my comment in light of the new information below – apparently removing (unblockself) from the administrator package will not prevent the administrators from unblocking themselves if they were the ones who blocked themselves. I will have to think this over some more, but that takes care of the main issue I had with Versions A and B of the proposal. Mz7 (talk) 03:12, 26 November 2018 (UTC)
Version A The commonly cited objection of accidental self-block isn't a real issue given Anomie provided statistics above. Worry over a rogue admin account blocking every other (active) admin accounts and presumingly then being able to go on a wrecking spree unchecked is perhaps misguided. When there's a rogue admin account, we already require either crat desysop or outside assistance (steward lock) to stop them precisely because such an account is able to self unblock. Removing unblockself means a rogue admin account can be stopped immediately by another admin blocking them. In the scenario of a rogue admin account blocking every other admin, given the throttle mentioned by Risker, the rogue account would be locked long before they're able to finish what they're doing. -- KTC (talk) 02:03, 25 November 2018 (UTC)
@Xaosflux: Thanks for the response, but are you sure? I just remembered someone admining through a block back in 2015 by doing revision deletion on a page while they were blocked (and was desysop as a result partly because of that). -- KTC (talk) 02:30, 25 November 2018 (UTC)
I think there are a few random things that are still allowed even if you are blocked. I did go over to testwiki/test2wiki (where I am an admin), blocked myself, and found that I could not block anyone else. --Rschen775402:34, 25 November 2018 (UTC)
Status quo It might seem like a good idea at first, but we have a lot of test blocks and accidental block to oneself, as well as when rouge admins block legit ones. Even when problems occur, they can get resolved by other means (ArbCom, desysoping) quite quickly. funplussmart (talk) 05:14, 25 November 2018 (UTC)
Version A solves a number of problems both in general situations (two admins wheel warring for example), but also, more so IMHO, in the security of accounts, one block by any admin immediately stops a compromised account. As well as for compromised accounts this will also likely remove the necessity for emergency desysops since a normal enforcement method, used on every other account, will actually be able to stop an admin account. Stewards have shown in the latest series of compromised admin accounts that they are very able to respond quickly if there is a problem. Regarding the comments about blocking oneself unintentionally, there's already a warning which appears when trying to do that, so if there's a concern that people will miss that it can be made more obvious. Callanecc (talk • contribs • logs) 07:48, 25 November 2018 (UTC)
Just coming back to reinforce my support for version A after I found that admins even without the selfunblock permission can still remove blocks they imposed on their own account. Callanecc (talk • contribs • logs) 06:42, 26 November 2018 (UTC)
(Non-administrator comment) Is it possible to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself? (I am not watching this page, so please ping me if you want my attention.)wumbolo^^^10:22, 25 November 2018 (UTC)
Not as currently implemented in the software. It would require asking the developer community to work on that for us, and that seems like a nontrivial task. But we could always ask, I suppose.Mz7 (talk) 11:37, 25 November 2018 (UTC)
@Wumbolo: According to John Cline and Ajraddatz below, this is apparently precisely the functionality that removing (unblockself) would result in. So yes, it is possible, and if this RfC is successful, that is the functionality that we will get. Mz7 (talk) 03:12, 26 November 2018 (UTC)
Very bad use of developer resources. Malicious self-unblocks happen maybe once every decade. They are grounds for immediate loss of sysop access. On the other hand, admins accidentally block themselves fairly often. It’s easy to click the wrong link. This is a trivial block that they are allowed to undo. Don’t waste real peoples time trying to solve a problem that almost never happens, and create a new problem that happens more frequently. JehochmanTalk12:35, 25 November 2018 (UTC)
Resources wise, we're talking seconds to add or remove a right to a userground. Malicious self-unblocks once every decade, did you miss the 3 compromised admin accounts in the last 3 days doing it? Accidental self-block unblock, 4 in last 2 years. It's really not as commons as everyone think it is, or maybe as it used to be. -- KTC (talk) 18:50, 25 November 2018 (UTC)
One would think that an organization that spends many millions of dollars on software development would have long ago changed the wiki software so that if you click the wrong link and block yourself a big red ARE YOU SURE??? would come up with the user having to type in the three letters "yes" (not just "y") to continue. Alas, we have a culture where making the software elegant, easy to use and generally excellent is not a priority, and administrators are especially prone to putting up with software that is OK but not great. This attitude is not new: during the Civil War cannonballs were slow enough so that if you noticed one coming at you you had time to duck. The problem was that it wasn't considered manly to duck.[citation needed] --Guy Macon (talk) 19:37, 25 November 2018 (UTC)
Adding that big red ARE YOU SURE??? would be a good thing to combine with taking away the ability to unblock anyone while you are yourself blocked. I'm just saying. --Guy Macon (talk) 19:44, 25 November 2018 (UTC)
Does it make you type the word "yes" (not just "y" or clicking on a button)? It is a well known effect in human engineering that people who see a lot of "are you sure?" warnings tend to click the OK button or hit the yes key on autopilot no matter what the text of the message is. making them type something different for the rare warnings is a proven method of avoiding such errors. --Guy Macon (talk)
@Guy Macon: If you try to block your self you get 2 differences: (1) A big red warning (2) You have to check an extra "confirm block" box before proceeding. — xaosfluxTalk17:43, 26 November 2018 (UTC)
Note that even without unblockself admins can still remove self-imposed blocks - tested and confirmed with technical staff. -- Ajraddatz (talk) 17:51, 26 November 2018 (UTC)
Yeah, I should clarify—in case my comment directly above yours was confusing—that revoking the ability to unblock oneself is a solution that has indeed already been implemented, and it would be trivial work to remove that right from administrators, and that is what this discussion is about. What hasn't been implemented is "to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself".Mz7 (talk) 20:39, 25 November 2018 (UTC)
Mz7, this modification from 2011 ostensibly allows an admin to remove a self imposed block even if ever the unblockself permission is removed from the admin bundle. Whether it is still valid or not, I do not know.--John Cline (talk) 02:01, 26 November 2018 (UTC)
Fascinating. I just tested and it is still valid; removing the unblockself permission will not prevent admins from unblocking themselves unless this is changed. -- Ajraddatz (talk) 02:09, 26 November 2018 (UTC)
@Ajraddatz and John Cline: Wait... really? This is a game-changer, actually. If this had been advertised from the start of the RfC, I think it would have changed some minds. I will go and strike my comments above as I rethink. Mz7 (talk) 03:14, 26 November 2018 (UTC)
Yep, just did some more tests to confirm. On the beta cluster, I created a user group with only the block right and not unblockself. My test account was able to block itself and remove the self-imposed block. When I blocked my test account with my main account, my test account was unable to unblock itself. Tl;dr if we remove the unblockself permission from admins here they would still be able to remove self-imposed blocks. -- Ajraddatz (talk) 04:21, 26 November 2018 (UTC)
Support Version A. The rest of us can't unblock ourselves if an admin has a moment's idiocy, I don't see why, in the case of a self-block, the person who had the moment's idiocy should be allowed to unblock themselves, and if they've been blocked by someone else then they should follow the same procedures to request an unblock as the rest of us. DuncanHill (talk) 19:42, 25 November 2018 (UTC)
Comment would it be possible to add a ten-minute "cooldown" before the unblock can occur? The recent hijacking-vandalism has involved multiple admin-self-unblocks, and a ten-minute cooldown would be a benefit for all of them. power~enwiki (π, ν) 19:50, 25 November 2018 (UTC)
Support Version A. Administrators should not be more equal than others. Even in the event of a mistake and blocking themselves, the administrators are enough of a clique they can contact another administrator and at worst suffer the indignity of being blocked for a few minutes. How many of them already have multiple accounts, much less the email addresses of some of their cohorts? Or at worst, sign in as an IP. If someone is blocked for cause, there should be enough documentation that anybody of the stature of an administrator should be able to make a rational decision as to whether the block is for cause or an accident. Trackinfo (talk) 20:00, 25 November 2018 (UTC)
Support A. How many of you remember the Robdurbar incident? An admin went rogue, blocking a collection of people and deleting a bunch of important pages, and it took a good while to find anyone able to desysop him. Three times he was blocked, and three times he unblocked himself — there was no way to stop him from continuing his rampage until he lost sysop rights. From a technical perspective, any admin should be able to stop any other admin and any bureaucrat from acting until someone else intervenes: we're too big for a single user to be able to block everyone else without getting noticed and stopped (and we also have the stewards who could intervene), and in the event of a rogue admin, there will be no difficulty whatsoever in unblocking all the wrongly-blocked people once the rogue has been stopped. Note that I've three times attempted a self-unblock: once after blocking myself, once after someone else blocked me (I requested a block to do some testing, so I unblocked once the test was complete), and once after autoblocking myself via blocking my alt account (I had to request assistance for that one). In the final situation, I had to wait only ten minutes despite some confusing technical issues; if you can demonstrate that a compromised account has blocked you, the unblock should be nice and quick, and you can use the opportunity to say "User:Soandso is compromised or rogue and should be blocked before you unblock me" so others are aware of the situation. Nyttend (talk) 22:21, 25 November 2018 (UTC)
Version A. If there is a disagreement or issue as to why, like everybody else, a discussion can be had at an appropriate place to work out the next step. There is no emergency as to why an admin will need to unblock themselves to do something. This ability IMO is strange and prone to disruption; the ability of an admin to go on a short break without admin tools does not justify it. --Tom (LT) (talk) 00:31, 26 November 2018 (UTC)
Version B. If a crat account goes haywire, it would be very difficult to deal with, but the difficulty is only increased marginally with version B. Furthermore, version B prevents 'Crats from being locked out by a hijacked admin account, and hence unable to unblock admins, or indeed perform a desysop (probably? I don't know for sure). The status quo allows havoc until a desysop occurs - in one recent case, version B would have reduced the vandalism of the main page to one occurrence, rather than two. Of course, a legitimate alternative is to allow blocked admins to unblock users other than themselves, but in the context of recent compromised accounts, that's unlikely to prevent the attacks, since multiple admin accounts have been hijacked. And there's the old idea of allowing sacrificial desysopping by admins, which I would suggest is probably a better solution than any of the current options. ∰Bellezzasolo✡Discuss01:11, 26 November 2018 (UTC)
Bellezzasolo, I've supported that in the past, and I'd support it again if it were proposed; it would resolve the issue at hand here without affecting people who have good reason to unblock themselves uncontroversially. I just doubt that such a proposal would go anywhere. Nyttend (talk) 01:42, 26 November 2018 (UTC)
Someone wrote an extension to do that some time ago. Since stewards have a ~2 minute response time, and compromised accounts should typically be locked before they are desysopped, I'd say that there would be limited benefit to actually implementing this extension. -- Ajraddatz (talk) 01:49, 26 November 2018 (UTC)
@Ajraddatz:WP:BEANS and all that, but a compromised crat account plus an automated script might take a concerted effort of stewards to solve. Actually, that's something that none of the proposals here address, I've emailed the beans. ∰Bellezzasolo✡Discuss14:49, 26 November 2018 (UTC)
Yes, we can all think of doomsday scenarios. But the better approach is to focus on attacks that are likely to happen and reduce the risk that they do. Version A helps in both a doomsday blockbot scenario and the previously-seen compromise attacks, since any "good" admin can stop the abuse immediately without steward intervention. -- Ajraddatz (talk) 16:02, 26 November 2018 (UTC)
I strongly disagree. We should make Wikipedia resistant to attacks that haven't happened yet. Ignoring a known vulnerability because nobody has exploited it yet is a classic indicator that idiots are in charge of security. (To be clear, I am talking about those in charge of security, not anyone here. We aren't expected to know about such things. Also, the WMF people in charge iof security appear to be doing an excellent job.) "That would be really easy to correct if it ever happened and a lot of work to prevent" is a good argument for ignoring a known threat, but "nobody has tried that one yet" is not. --Guy Macon (talk) 17:49, 26 November 2018 (UTC)
Version B - self-unblocks only add fuel to the drama fire. (Ideally, would support version A, but there might be a security risk with blocking CRATs). Renata (talk) 02:31, 26 November 2018 (UTC)
@Renata3: What would the security risk be? Stewards have shown that they're very quick to respond to a compromised account. Having a compromised crat account which can remove userrights as well as everything else is worse than an admin account. Callanecc (talk • contribs • logs) 07:15, 26 November 2018 (UTC)
There are certain hours of the day (at least when I was a global sysop looking for a steward) when there are fewer around. Won't say what those are onwiki, of course. Personally, I would like to see self-unblock restricted to a group like CU/OS or even interface admin, as those groups are pragmatically required to take extra precautions with their accounts. A lot of our bureaucrats are sadly as inactive as the admins who are getting their accounts compromised. --Rschen775407:41, 26 November 2018 (UTC)
None of the above I don't really like any of these options. With option A, yes, stewards could self-unblock if everyone was desysopped, but the response time to clean up the damage would be significant, especially if it is a time of day where stewards are not that active. With option B, I'd rather that it wasn't the bureaucrats, as many are sadly as inactive as the admins who are getting their accounts compromised. I'd rather have the self-unblock right be held by CU/OS or even interface admin since they already have to take precautions with their accounts. If I had to go with any I'd say option C, but of course that has its flaws too. --Rschen775407:46, 26 November 2018 (UTC)
@Rschen7754: So basically you're saying a tighter version of version B, right? I mean, that's not a bad idea either, while bureaucrats can desysop it wouldn't be needed with Version A or B if this was just a rogue/compromised admin account, since blocking them would stop since they couldn't self-unblock. SemiHypercube✎14:15, 26 November 2018 (UTC)
It would be kinda cool if unblockself could only be used by admins with 2FA enabled. Now that the previous security hole has been patched, it is nearly impossible that a 2FA-enabled account could be compromised. So admins that hate 2FA could continue to not use it, but if their account gets compromised they could be stopped by someone with a safer account. -- Ajraddatz (talk) 16:01, 26 November 2018 (UTC)
Status quo: It's interesting to note that this RfC meets four out of five of Goode and Ben-Yehuda's characteristics for a moral panic. I bet that after some time has passed, it'll end up meeting all five of them. Spintendo 08:12, 26 November 2018 (UTC)
Version A -- No legitimate reason to unblock yourself. I would honestly go further and remove an admin's technical ability to block themselves as well. -- Dolotta (talk) 17:04, 26 November 2018 (UTC)
Version A - Ofcourse admins have blocked themselves accidentally in the past (or have done so as a test) however both are extremely rare these days (those that block themselves usually ask to be blocked and unblocked) so I don't really see a reason as such to allow self-unblocking. –Davey2010Talk18:07, 26 November 2018 (UTC)
Status quo. @Nyttend: as one of the affected accounts of the robdurbar incident I still feel, that the DOS affect of the other options is worse that the dangers of leaving the technical abilities as they are. Also since then we have given crats the ability to desysop. Back then we had to wait for a steward. Agathoclea (talk) 18:27, 26 November 2018 (UTC)
Agathoclea, while I disagree with your conclusion, I have to respect it more strongly because you were involved in the incident. Just one question: DOS affect? If you mean "denial of service", I'm unclear how that fits, so more details would help. Nyttend (talk) 01:57, 27 November 2018 (UTC)
@Nyttend: while this is a moo point now, It allows for a wiki to be shut down if the assailant is fast enaugh and hits the active admins first. Back in the day, the suggestion was made that blocking an admin should result in a automatic desysop. That would stop a rampage in its tracks. the auto de-sysop would be quickly reversed in obvious cases. In not so obvious ARBCOM would decide which of the two gets his bit back Agathoclea (talk) 08:52, 27 November 2018 (UTC)
Version A I'm pretty sure version A is going to happen soon regardless of the outcome of this discussion. It's not necessarily permanent, though. Right now, accounts are being compromised left and right, a number of them are sysops. Drastic times call for drastic measures. Sometimes every second counts, for example when graphic pornography is placed on the Main Page. The time it takes to go to IRC and type !steward please lock <user> and wait for action is just too long. — MusikAnimaltalk18:48, 26 November 2018 (UTC)
Status quo - Wrong approach to dealing with compromised administrator accounts; better to elect a few more Bureaucrats who are highly active and in various time zones so that emergency desysops are less of a worry. — Godsy (TALKCONT)20:12, 26 November 2018 (UTC)
These options all have problems. Perhaps a solution could be for blocked admins to be able to block other admins and for admins to be unable to unblock themselves. --Yair rand (talk) 20:28, 26 November 2018 (UTC)
User:Yair rand, I'm not quite clear what you mean. Currently, you can't block someone if you're currently subject to a block, at least here at Wikipedia (is it different at Wiktionary?). Are you proposing that blocked admins be given this permission (and if so, why?), or do you mean something else? Nyttend (talk) 02:00, 27 November 2018 (UTC)
@Nyttend: That is what I'm proposing, yes. In case of a rogue admin, the priority would be to stop damage from being done as soon as possible. If self-unblocking is allowed, blocking can't stop a rogue admin. If self-unblocking is not allowed and blocked admins can't block other admins, the rogue admin could preemptively block the other admins and remain as the only unblocked admin. If self-unblocking is not allowed and blocked admins can block other admins, any admin can block the rogue admin immediately and shut down all further actions other than the possibility of blocking the remaining admins. On further thought, however, I'm not sure that would be an improvement: All admins being temporarily unable to fix things up (like vandalism) until a steward or bureaucrat shows up might actually be worse than the alternatives... I am unsure. --Yair rand (talk) 05:49, 27 November 2018 (UTC)
Not of fan of anything out there right now, so status quo for me. For example, if you have a self block, I'm fine with a self-unblock. If an account is compromised, or appears to be, then de-sysop until the account is back under control. Headbomb {t · c · p · b}20:48, 26 November 2018 (UTC)
At that ticket, Ajraddatz said "self-imposed blocks can always be self-removed". I've just blocked and unblocked myself, so I can confirm that this is still the case. Could someone block me (and then ping me) so we can see whether the new settings are live yet? Please be careful to disable autoblock and enable talk-page access, of course :-) Nyttend (talk) 02:12, 27 November 2018 (UTC)
Already did these tests and reported back a few comments up, but that's ok, you guys can test it out again if you want ;-) -- Ajraddatz (talk) 02:24, 27 November 2018 (UTC)
Ah, sorry, I guess I didn't read as much as I thought I had. The test went as expected; when I tried to unblock myself, I got a new message:
Considering that the devs have gone and removed the problem for us, should this RfC be closed then? — AfroThundr (u · t · c)02:33, 27 November 2018 (UTC)
I think so. I wish they'd waited for this discussion to close (someone mentioned this discussion, so they were aware of it), but since they didn't, there's no point in continuing. The only possible change would be a consensus to request the return of unblockself, and since they removed it on their own accord, I doubt they'd grant a request to revert themselves. Nyttend (talk) 02:35, 27 November 2018 (UTC)
I say let the RfC play out. I for one can't fucking believe this was done behind the scenes without community consent. I find it hard to believe that the devs can't see the double-edged blade staring directly back at them us. If the inability to self-unblock can be used as a weapon against these rogue/compromised/abusive accounts, it can be used by these accounts, against us. I really don't think "Robdurbar" would have attacked the main page if he knew it would be over the second he did so. He may have instead strategized the best way to evade a block for as long as possible while inflicting as much damage as possible. This is a big project, with plenty of dark corners. It's really not hard for me to brainstorm creative ways to go rogue without being immediately blocked. I'm sure whoever is behind the compromised admin accounts is not terribly stupid either. There's not that many admins active at any given time. If we're lucky, there will be a crat or steward around to perform an emergency desysop when needed. Some nonsensical IP user can commit blatant anti-Semitic vandalism on an obvious target for that sort of thing, and no one will notice for nearly 48 hours. Or, they can go on an unhinged BLP violating/edit warring spree, while their name sits in a backlogged administrative noticeboard. If IPs can fly under the radar, do you really think that rogue/compromised admins can't get away with it if they really try? We're just giving these people reasons to engage in pre-emptive admin blocking, not to mention stealth sprees, and that can cause far more damage than anyone has ever tried to cause before. Yeah, it sounds like a good idea with no downsides at first, but there's a huge potential for this shit to backfire. Smdh. Swarm talk 02:40, 27 November 2018 (UTC)
Swarm, No point in it now, I guess. FWIW if you're interested in numbers, I've been watching them for a while. On average there are 40-60 admins active on enwiki per hour, and about 500-700 per week. SQLQuery me!02:50, 27 November 2018 (UTC)
Imagine if you looked at the numbers where you take the body of "active" admins in a given time, weed out the ones who aren't actually working on/involved with the administrative backlog proper, spread them out across every venue where there are outstanding reports or requests for admin action, and then compare the rate of admin work that can be, or is being, completed with that workforce, relative to the rate of new admin work being created. Reports at AIV can sometimes sit for hours. Reports at AN/I, RfPP, PERM, or AN3 can sit for days. There's basically one person who has been handling the histmerge backlog over the years. It doesn't do me much good to know that there's 60 active admins here at any given hour when I'm waiting two or three days for a simple report to get an admin's response. We're not as on top of things as you'd think. Swarm talk 03:11, 27 November 2018 (UTC)
I know we are all very enwiki-centric here but this was also done globally. How about those small projects where there are two or three admins? Block, block, and you have the run of the place until a steward steps in. --Majora (talk) 02:43, 27 November 2018 (UTC)
For what it's worth, before this change such rogue admin account already had the run of the place until a steward interfere since no blocks can stop them, and their crats don't have the power to desysop. -- KTC (talk) 12:31, 27 November 2018 (UTC)
Version A – I originally supported maintaining the status quo, but I have been persuaded by two arguments. Firstly, per this 2011 change found by John Cline and confirmed by Ajraddatz above, removing (unblockself) from the administrator toolset will not prevent administrators from unblocking themselves if they were also the one who blocked themselves. Most self-unblocking events on Wikipedia are administrators accidentally blocking themselves, and this proposal, as written, will not hinder administrators' ability to correct such uncontroversial errors. Secondly, per Callanecc above, this proposal would be useful in the event that an administrator account is compromised, which does occur every few years. Currently, the only effective way to stop a compromised administrator account is for a bureaucrat or steward to do an emergency desysop/global lock. The wait time for this can take several minutes, whereas this proposal would shorten the response time by allowing any administrator—not just stewards and bureaucrats—to neutralize the compromised account via a block. As MusikAnimal notes: in such a case, every second counts. Mz7 (talk) 03:12, 27 November 2018 (UTC)
Here's why I didn't support this option: what if someone did succeed in running a script to block all (active) admins? We have to weigh the time we save with option A and compare it against the probability of someone succeeding in doing this and the length of time it would take for intervention in that scenario. --Rschen775403:55, 27 November 2018 (UTC)
Version C I basically agree with the latter half of User:Mz7's stricken post (the bit about whether someone who can't be trusted not to self-unblock can be trusted to be an admin, which is basically unrelated to whether self-blocks would be included, although I do applaud the detective work that was apparently involved there), with the addition that it seems to be in only extreme cases where admins get blocked at all (I've seen admins do/say things that would get any experienced non-admin blocked on-site, but with admins a more popular approach seems to be to ask ArbCom to desysop, as though it was taken as a given that if someone does something blockworthy their mop should be taken away first), and admins having the ability to self-unblock would seem to be useful to weed out the really extreme cases. I should also say that one way or the other this question would be better resolved after Wikipedia:Arbitration/Requests/Case/Fred Bauder is resolved, since desysopping someone for abusing an admin tool that has already been removed from all admins is ... well, it serves a function, but still feels kinda silly. Hijiri 88 (聖やや) 07:42, 27 November 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Nuclear Option
So devs have decided to pull "Option A" on all projects in phab:T150826. Note admins that SELF-block can still self-unblock. In theory if we wanted some local group to be able to 'unblockself' still we could argure for it here on enwiki only (e.g. int-admins, or 'crats, expect to get a lot of pushback if we asked for sysops to have it back). — xaosfluxTalk03:42, 27 November 2018 (UTC)
In order of preference as to who to give unblockself to, it would be "admins that have 2FA enabled," then CU/OS, then arbs (since you would have to create a separate usergroup for them), then bureaucrats (since they don't handle private info and thus might not take precautions on their accounts), then interface admins. I just worry that we might be opening up the door to someone who runs a script and blocks all the admins, at a time of day when stewards are not around. --Rschen775404:00, 27 November 2018 (UTC)
Striking my first suggestion as I think there is a potential security problem in that, and in giving certain privileges to admins based on whether they have two-factor or not. --Rschen775404:14, 27 November 2018 (UTC)
The config change is quick and easy to make. Think of developer-forced "option A" as a temporary measure until more robust technical solutions are developed. For now, we should accept it. — MusikAnimaltalk04:19, 27 November 2018 (UTC)
I'm somewhat peeved that the devs went ahead and partied like it's 1945 -- the issue was dealt with, the question of how to deal with the ongoing threat was being discussed, and this was sent to all Wikimedia wikis. I think there's some valid points being made on the Phabricator and while I'm partial to option A myself I'm concerned at the trigger-happiness. Best, ProgrammingGeek talktome04:21, 27 November 2018 (UTC)
Eek, "Old admin accounts are being hacked and blocks to active admins applied"? Oof. I wonder if a fix for this would be to make it harder to block admin accounts? Somehow... dunno how tho. Anyway, yeah, if admin accounts are being wrongly blocked isn't keeping it easy to unblock themselves called for? Herostratus (talk) 09:48, 27 November 2018 (UTC)
I would support adding this right to bureaucrats and/or int-admins (but obviously not those who are in both, that would be one person) because having nobody be able to self-unblock seems like a security flaw to me. SemiHypercube✎12:14, 27 November 2018 (UTC)
CUs are mainly the ones dealing with the current spate on compromises, so I guess there's that, but I'm pretty meh about it either way. Hardcore opposed to IAdmins having it as it's literally just a flag that any admin who requests at BN with a sufficient reason can get and we shouldn't be adding anything to that userright beyond maybe the ability to edit the main page/other security risks. TonyBallioni (talk) 16:36, 27 November 2018 (UTC)
Also because there is a significant risk of private data being leaked if CU/OS is hacked (even if blocked), so we're already in trouble. --Rschen775419:24, 27 November 2018 (UTC)
Those are reasons that people with a CU flag should be particularly concerned about security (although I've heard the complaints about requiring 2FA for CU/OS several times), but why would it make sense for them to be able to unblock themselves? Natureium (talk) 20:03, 27 November 2018 (UTC)
Suppose unblockself was a right that could be exchanged as in a changing of the guard per say, and perhaps 5 or 10 admins, coordinated at wp:an were vested with the right at all times after satisfying some form of active acceptance implying a commitment to remain active until at least such time as when another admin similarly accepts the right and commits to the role. It would not be difficult at all to maintain these 5 or 10 in-house go-to admin-guards and such an active rotation would capably foil any script a wannabe rogue could practically devise while ensuring wiki-continuity by en-means. Anyway, that's an old soldier's 2 cents worth of outside the box thought, given with no dividends due. Cheers.--John Cline (talk) 16:32, 27 November 2018 (UTC)
Thank you xeno, I appreciate your reply; in its grounded truth. Considering that I support option A, and that is effectively what we now have, I'd have done better leaving the other changes unpublished. I agree with your regards. That said, I would like it known that I am in full support of the foundation's leadership demonstration in implementing this global change. Bravo.--John Cline (talk) 01:35, 28 November 2018 (UTC)
I don't see that the ability to unblock oneself has been removed or even decided. It's been my understanding as long as I've been an admin that we can unblock ourselves but it's a really bad idea to do so unless there is an absolute emergency. Jonathunder (talk) 21:58, 27 November 2018 (UTC)
Throttling
Slightly separate to (unblockself), I can't see any rate limits applied to administrators. I'm open to correction on that, but I can't see anything. After all, admins have (noratelimit). More concerning perhaps, should a 'crat account get hijacked, is no throttle on making sysop accounts (or, indeed, 'crat accounts). I'd suggest we have a throttle on administrators blocking other administrators (2/minute?) and a 24 hour cooldown on new bureaucrat accounts before they can user their new rights. WP:BEANS is why the cooldown is necessary, if in doubt email me and I might spill the BEANS. ∰Bellezzasolo✡Discuss13:52, 27 November 2018 (UTC)
I'll spill them. It's important that everyone knows and acts with knowledge rather than ignorance. Now that the devs have acted in their infinite wisdom and removed selfunblock, and because there is no rate throttling, at the risk (or outright ignorance) of WP:BEANS, I'm proposing this godawful idea that the next compromised sysop account simply uses the API to mass block all other administrators. Then we're fucked until a staff, dev, or steward comes by. This is a bad bad bad idea and it's going to bite us in the ass really hard.--v/r - TP14:14, 27 November 2018 (UTC)
@TParis: Not only that, but if they got into a bureaucrat account, they'd be able to create new bureaucrat accounts through the API, and only stewards would be able to desysop them. It would be a bad case of whack-a-mole. But that's a threat even with (selfunblock), because crat accounts are also able to desysop! Only active crats and stewards would be available to fight the hacker. ∰Bellezzasolo✡Discuss15:06, 27 November 2018 (UTC)
I'm glad we've given up WP:BEANS, as it is my least favorite essay. Is it ever necessary for a single crat to +/- sysop or crat more than 2 accounts per day? It seems like a pretty strict limit would rarely cause actual problems. Natureium (talk) 15:31, 27 November 2018 (UTC)
At the start of each month, sometimes up to a half-dozen sysops have the perm removed by a crat per WP:INACTIVITY. Otherwise, well, we used to have multiple concurrent RfA's, and it's possible for multiple sysops to return at the same time (pretty nearly happened this week) so still useful if not strictly necessary. ~ Amory(u • t • c)16:26, 27 November 2018 (UTC)
@Natureium and Amorymeltzer: We could set the desysop throttle to something high like 20/day or 30/day. That way, although a lot of damage is done, there should still be active admin accounts to block the hacker, and then unblock the crats so they can re-sysop. If we separate +sysop and +crat, you could then have a 5/day throttle for +sysop and 1/day throttle for +crat (I don't see 2 concurrent RfBs in the foreseeable future). The +crat would need a 1 day cooldown on the new account is the main thing, as it stops a malicious script hopping between accounts. ∰Bellezzasolo✡Discuss13:49, 28 November 2018 (UTC)
This is pretty painful to read. Under the status quo, someone could already compromise an admin and go on a mass blocking spree, and if another admin was able to block them the compromised admin could just self-unblock. A compromised crat could already go on a desysopping spree, and self-unblock if blocked. In all of these situations, either steward or bureaucrat intervention is already required to stop the abuse. With the removal of unblockself, any admin can put a stop to it, because the compromised admin vandalbot can be blocked by any other admin and cannot undo the block. This is a helpful move, not a harmful one. It gives more power to local admins to stop abuse in situations involving account compromises.
There's also a question of likelihood here. All of the previous compromises would have been stopped earlier without unblockself, and honestly the various doomsday situations you describe would still have the possibility of being stopped earlier since any admin could stop it immediately. Now, I'm not saying that the implementation is without concern - specifically the part of removing unblockself from small wikis too - but I think that the reaction here is honestly quite ridiculous. -- Ajraddatz (talk) 16:44, 27 November 2018 (UTC)
The difference is that we can all unblock ourselves and go right back to cleanup. Once unblockself goes away, a rougue admin can run a script to block 1300 sysop accounts (not hard) and then have free roam of the place. In fact, if hacker were to write the bot well, they'd start by scanning the admin logs for active admins and block those first. Honestly, if you're blowing this scenario off, you haven't really given it due weight.--v/r - TP16:49, 27 November 2018 (UTC)
And it would be trivial for even a moderately skilled hacker to write the bot that well in advance, since mediawiki is freely available software which they can practice offline. Only in death does duty end (talk) 16:51, 27 November 2018 (UTC)
I'm not blowing it off, I'm saying that it is incredibly unlikely and could be stopped by one admin under the new scheme, whereas it could not be stopped without steward/crat intervention before. The actual clean-up is trivial compared with stopping ongoing damage. A rogue admin cannot instantly block all 1300 sysops, and even if they did (which is incredibly unlikely and no compromise before has involved this) stewards still have a four minute response time, on average, over the last three compromise situations. Bad policy is made by looking only at fringe cases, there needs to be a balance between possible harm and what would help in 100% of the situations that have happened so far. -- Ajraddatz (talk) 16:54, 27 November 2018 (UTC)
I'll also clarify that I wasn't trying to single out your idea as ridiculous: I've seen all sorts of situations explained over the last two days that are very unlikely and would still be better solved without unblockself than with it. The reality is that regardless of unblockself there are still far worse things that the attackers could have done with a compromised admin account, and we're lucky nothing worse has happened. Ensuring that admin accounts are secure is going to be an important consideration moving forward. -- Ajraddatz (talk) 17:04, 27 November 2018 (UTC)
"could be stopped by one admin under the new scheme" I'm trying to tell you that all active sysops could be blocked before anyone even realizes whats happening.--v/r - TP17:14, 27 November 2018 (UTC)
I know what you think could happen, I'm saying it wouldn't happen that way. Even without rate limits there is a physical limit to how often an action can be processed through the API. Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min. It would take 21 minutes for a bot at that speed to go through the list of 1300 admins. Lets say the attacker made a bot that was 4x faster than that - it would still take 5 minutes to block all admins. During the last compromise, the response time from the first action to first block by an admin was 2 minutes. This is still a better solution than the status quo. And as usual, I'll note two things that people here are ignoring: a) the likelihood that this would happen, since it's never happened before and removing unblockself would have helped in 100% of the past compromises, and b) the fact that there are far worse things that a compromised account could do than block every admin, so if we are dealing with someone who has inside MediaWiki knowledge and a good familiarity with our systems we'd be in trouble for more reasons than a list of blocked admins. -- Ajraddatz (talk) 17:22, 27 November 2018 (UTC)
I'm not entirely sold yet, but I kind of like the idea from the phabricator ticket to allow blocked sysops to block the user who blocked them, i.e. retaliate. It might lead to escalation in the more routine "sysop goes rogue/dumb" scenario, but it would be limited. In the compromised/mass-attack scenario, it would stop the threat of mass-blocking. In either way, basically stop the bleeding and give time to sort it out. Short-circuits the issues with an elegant(ish) solution to uncommon and very uncommon problems. ~ Amory(u • t • c)17:25, 27 November 2018 (UTC)
@Ajraddatz:SQL did the math. There are about 60 admins here per hour (300 per day/600 overall per week on average). Even with the limit you've given, all admins active on the project within the last hour could be blocked within 1 minute.--v/r - TP17:32, 27 November 2018 (UTC)
Ok, fair, in which case someone would need to get a steward..... which they would need to do anyway. Again, doomsday scenario, unlikely to happen, far worse things could be done. I'll end by saying that there are also ways of reducing this one theoretical vulnerability and it looks like the devs are going to work on it. -- Ajraddatz (talk) 17:34, 27 November 2018 (UTC)
Amorymeltzer, It would solve the problem, so long as something crazy doesn't happen like 3 admin accounts being compromised at once. But, what are the chances of that happening? SQLQuery me!17:37, 27 November 2018 (UTC)
Maybe I'm crazy, but is there some way we could test this out? Obviously not on enwiki, but setting up some test wiki with 1300 admins and with a similar configuration, and then see how long it takes. --Rschen775419:22, 27 November 2018 (UTC)
I'd actually like to do it. I was half tempted to say something like "I could write such a bot in 10 minutes" but I suspected some busybody would accuse me of threatening the 'pedia or going rogue and ask Arbcom to remove my bit over it. It'd help if we could get 1300 psuedo accounts with active log entries being made with a random 60 active during a given hour so that we have an accurate environment.--v/r - TP20:14, 27 November 2018 (UTC)
Well, I'm not sure if it's needed... as you said above, it would be easy enough to just block the active ones and that would have the same impact. A better use of time would be to help the devs work around this one theoretical abuse angle. -- Ajraddatz (talk) 23:03, 27 November 2018 (UTC)
@SQL: Fair point, but if the attacker is using one or two accounts to bulkblock every sysop and saving the third to vandalize freely, we're no worse off than we were yesterday, and we've forced the attacker to burn two or three logins instead of just one. Obviously the more accounts an attacker has at their disposal the worse/harder it will be, but I'll take the net positive of half a loaf over none any day. ~ Amory(u • t • c)20:01, 27 November 2018 (UTC)
"Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min." @Ajraddatz: my personal record is 2000 edits in 5 minutes. This is by no means a hard limit, there are several users who managed over 1000+ edits/minute. And if you wanted, you could go faster. Blocking the top 500 admins would take 75 seconds at 400 edits/minute. - Alexis Jazz05:04, 28 November 2018 (UTC)
And so far my personal best that I have actively noticed was around 181 edits within a minute with TheSandBot, a feat which it has accomplished a few times. --TheSandDoctorTalk21:18, 30 November 2018 (UTC)
Toolforge job-array is designed for running massive parallel math problems but can run massive parallel worker bots. I tried it once but the speed caused problems with disk caches and logging so I backed off but for the right bot it might be extremely fast. -- GreenC22:04, 30 November 2018 (UTC)
Yeah, I'm not buying this whole "it gives admins more power to stop disruption" angle. It can just as easily be argued that "it gives rogue admins more power to disrupt". If the risk/benefit ratio was the same, fine, whatever, but honestly, what's a harder scenario to deal with, one admin who is able to unblock themselves a few times before they get locked/desysopped, or dozens if not hundreds of admins blocked and unable to unblock themselves before anyone realizes what's going on? Even worse, what's harder to deal with, a rogue admin who knows they can unblock themselves and thus isn't worried about detection, or a rogue admin who knows they can't unblock themselves, thus goes stealth-rogue and does something like delete hundreds of obscure articles with misleading rationales, or modify the protection on hundreds of articles, or something even worse like abusively merging histories, or create vandalism articles with their autopatrolled rights. There's any number of ways to go absolutely fucking nuclear without being immediately detected, and that's what removing the ability to self unblock is going to encourage. It's clear the people who unilaterally made this decision weren't thinking about the potential downsides at all, it was just a rushed, boneheaded move, not to mention a slap in the face to the supposed concept of a volunteer-run project. It's not remotely an uncontentious security improvement as you would have us believe, and it arguably increases the potential for harm. Swarm talk 22:17, 27 November 2018 (UTC)
No, it can't be just as easily argued. Removing unblockself earlier would have helped in every single one of the compromise cases that have actually happened across this network of websites since I've been in a position to respond to them, which is going on five years now. You are taking a remote possibility (but still a possibility, I'll give you that) and railing against an otherwise positive security change because of it. I'll also add that attackers are already incentivized to be stealthy, since there is an end point to attacks even with unblockself when the compromised account is locked. I don't think that moving the possibility of stopping an attack sooner than it can currently be stopped (2 minutes instead of 4 minutes in the last case) would cause a significant change of behaviour in the attacker. I'd say that these public discussions about all the possible things someone can do with a compromised admin account are much more likely to cause future problems than removing unblockself from the admin toolkit.
I'm not saying that the possibility should be ignored, and maybe I haven't been very clear on this up until now. I think we should be working with WMF security staff to identify and fix vulnerabilities, not rejecting their efforts outright. Ultimately they are the ones who are subject matter experts in what they do, and should be allowed to make decisions to protect the security of our site, but it should be a collaborative process. I think there's improvements to be made on both sides in that respect. Your own sarcastic comments thanking the WMF for their change are just as unhelpful to that effort as them forcing technical changes without community consultation - they feel like the community is too busy hating the WMF to work with them, and the community feels like the WMF doesn't care. In this particular case, staff are willing to both work towards fixing this vulnerability and allowing projects to opt-in to adding unblockself to the sysop kit with consensus, but feel that removing the permission is a better option to have by default. From the arguments I've heard, that seems fair to me. -- Ajraddatz (talk) 23:03, 27 November 2018 (UTC)
I get it, you like the positive aspects of this change, but you're also just repeatedly rejecting perfectly plausible scenarios in which it can backfire, which is something plenty of people are concerned about by the way, without resolving the actual concerns. The concerns don't just dissipate because you point out that we can stop a rogue account in 2 minutes instead of 4 now. And you're also acting like it's unreasonable to be outraged when the WMF makes a contentious global change to a longstanding status quo, willfully ignoring an ongoing community discussion that clearly shows said change to be controversial at best. I would think that as a Steward, your priority in this situation would be "customer service", but apparently it's to aggressively beat back those of us who dare to question a WMF staff member's decision that quite blatantly contradicts the fundamental principles that supposedly govern us. Chastising us for being "haters", really? The devs won't work with us because we just mindlessly hate the Foundation? What?? Please extend my sincere apologies to the Foundation for hurting their feelings with sarcasm. I should have realized that it's our fault when Foundation staff arbitrarily makes decisions without the community's input, without sufficiently acknowledging the community's concerns, without providing any explanation to the community, and without being accountable to the community. I totally understand how it's retroactively our fault, for using sarcasm, after the fact. You've convinced me that the devs always make the right call, and that we should not waste time critically thinking for ourselves. Academic experts aren't given any special preference here, but the staff are. Got it. Sarcasm aside, when the Foundation does something silly, and people get pissed off about it, it's not a good look to boil it down to "hating the Foundation". I have nothing against the Foundation, I don't know anything about the Foundation and I'm entirely indifferent about the Foundation. But the merits of this "content dispute" itself aside, the Foundation should not be making decisions like this in the midst of an active community discussion, and if they for some reason feel the need to, the responsible parties need to be accountable to the community. It's not unreasonable to call them out for failing in this regard, and it's actually pretty bizarre to see a Steward try and frame that kind of criticism as unreasonable. You just come across as a shill for the Foundation. If you want to actually facilitate a better working relationship between the Foundation and the community, use your weight as a Steward to remind staff not to do things that will very obviously piss people off, like ignoring community discussions, take our concerns seriously, rather than arguing with everything and sweeping dissent under the rug, and take a leadership role in bringing us together. Swarm talk 01:56, 28 November 2018 (UTC)
I have not tried to aggressively beat down anyone here; I think that the concerns are overemphasized, that the problems exist with or without unblockself but the benefits only exist without. Responding to that effect is not intended to prevent discourse or criticism, nor has it done that. As to bring the community and staff together, I've tried to do that with this situation, and have been somewhat successful in other places. Here obviously wasn't one of them. -- Ajraddatz (talk) 04:46, 28 November 2018 (UTC) I've thought about this some more, and if I was coming off as obtuse and dismissive then that's probably what was happening - my apologies. I thought I had The AnswerTM here and it was just a matter of explaining it better, but that's probably not the case and even if so I obviously haven't done that. I do think your concern is valid and hope that the patch Tim linked to above will help resolve it. And if Commons was hit with edits that fast I'm probably remembering things wrong at Meta, confirming that this is something deserving of more thought. -- Ajraddatz (talk) 05:36, 28 November 2018 (UTC)
@Tim Starling (WMF): I tend to be biased toward my idea of a solution over others, but I can't say that I can think of a reason why your solution doesn't work.
@Ajraddatz: I appreciate your comments, but you'd still have been my favorite steward after this regardless. I'm guilty of thinking I have The AnswerTM all the time.--v/r - TP16:48, 28 November 2018 (UTC)
@Tim Starling (WMF): Well, yes, I have articulated concerns in my comments other than the potential for a rogue account mass blocking admins. However, that is a major concern, and allowing a retaliatory mutual block seems like it would be a reasonable countermeasure, even if not perfect. I can accept the fact that the status quo wasn't perfect, and there likely is no 'perfect' way of dealing with this, but the point of contention about WMF staff showing a complete disregard for the community is a bigger issue. Completely unacceptable in any business situation, additionally insulting coming from an NPO towards its own volunteers, and even more so in the context of the precedent that Jimbo set to purportedly let the community govern. If you're going to take a decision out of the community's hands while they're actively discussing something, at least have the decency to be accountable for that. @Ajraddatz: Sorry if I came across as too aggressive towards you as well, I was directing my other frustrations at you, and it wasn't necessary. Best, Swarm talk 17:52, 28 November 2018 (UTC)
I know it can be surprising when we change the MediaWiki configuration without community consensus being demonstrated, but that is in fact the usual process, we change configuration details every week. We especially do not consider it necessary to consult with the community before making security-related changes, and this change was recommended by our security team. But in this case, there effectively was consultation, since Brian Wolff indicated that he had read the village pump discussion and taken it into consideration before he uploaded the configuration change to Gerrit. Most village pump comments seemed to focus on the prospect of a compromised admin account using a script to block all other admin accounts, a concern which was of course known to us, as it was the subject of the third comment on the Phabricator task in November 2016 and was also discussed at length on Phabricator this month. In my opinion, there was a need for judgement in weighing up the various concerns. Our judgement was influenced by the current vandal, who appears to be technically unsophisticated, and yet is damaging Wikipedia's reputation by, for example, twice placing a Goatse image on the main page 5 days ago. I think we should first deal with the vandals who are attacking the site right now, and worry about hypothetical technically competent vandals later. As for the precedent Jimbo set, well, it cannot be so easily distilled to a single principle. In the early days when Jimbo was highly active, he didn't tell developers to always defer to community consensus, in fact we were pretty much able to make any change to the software we wanted. This was an era before bureaucrats, stewards, oversighters and checkusers, I took on all those roles by means of shell access. When I introduced the block-by-name feature in September 2003, I established the policy of allowing administrators to unblock themselves with essentially no community consultation. I recall consulting on blocks in general, and in fact the feature was initially disabled on the French Wikipedia due to Anthere's objections, but I brushed off complaints about this detail, because allowing admins to unblock themselves was the simplest thing to code, and as a volunteer I didn't have much time to spend on it. So it's strange to see the status quo defended in such strident tones when it was an arbitrary, unreviewed decision by me in the first place. -- Tim Starling (talk) 23:30, 28 November 2018 (UTC)
I appreciate you taking the time to offer an explanation, I can understand where you're coming from, and I can also understand that you guys can make judgment calls without the community's approval. But, you're still suggesting that you don't even see what the big deal is here. There's a contentious community discussion going on, you guys make a judgment call on your end to handle it unilaterally, and to you, that's the long and short of it. To us, okay, you've unilaterally overridden a community consensus-building process, something we hold sacred, something that no member of the community, regardless of standing, would ever be able to do, and you don't even have the decency to explain to us what you're doing and why, not even to give us the slightest indication that you're listening to the community's concerns, or even that you take the concept of a community-based project seriously, at all. The fact that you find this backlash 'strange' suggests that you don't understand the high level of importance that longstanding precedent, and transparency, and communication, and accountability have here, and it's all just happily arbitrary on your end, that's concerning, because it reveals a large disconnect between the culture at WMF and the culture within the community itself. I don't think the WMF has disdain for the community, but those are the optics you project in situations like this. Not intending to single you out to give you a hard time, but I think you guys can maybe do with a reminder that the community deserves a degree of courtesy in situations where you might be perceived as stepping on its toes. Swarm talk 21:27, 29 November 2018 (UTC)
"Even without rate limits there is a physical limit to how often an action can be processed through the API. Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min. It would take 21 minutes for a bot at that speed to go through the list of 1300 admins."
No policy decision should be made based upon the assumption that the Wikimedia servers won't suddenly become thousands of times faster. All it would take is a decision that certain tasks have the potential to bog down the existing servers and thus should be moved to a dedicated high-speed server for the slowness we are depending upon to vanish.
Fair, and as pointed out above, it is likely that they could already go significantly faster with up to 2,000 actions/minute. -- Ajraddatz (talk) 19:42, 28 November 2018 (UTC)
Blocking the admin who blocked you
Replying to this change that allows a blocked admin to block the admin who blocked them, I see three problems:
It allows for messy escalations of disputes between admins. What would have happened in Wikipedia:Arbitration/Requests/Case/Fred Bauder if Fred Bauder, instead of unblocking himself, had blocked Boing! said Zebedee (the admin he was edit warring with)?
It still allows for a "stalemate" situation in which all 1300 admins end up blocked. That might be better than some of the doomsday scenarios described above, but it is still very disruptive.
It still doesn't prevent the doomsday scenarios described above if two admin accounts are compromised. (First compromised admin blocks all the other admins while second compromised admin wreaks havoc. Second admin could even be scripted to repeatedly and rapidly unblock the first admin.)
Look at it this way. The vandal/hacker has the advantage of time, speed, and stealth. They have lots of time to plan, tweak, and automate, while we have to respond at normal human speed. We have the advantage of numbers and power: there will always be more good admins than compromised admins, and eventually the 'crats will swoop in for the kill. A good solution will take away the hacker's advantage without significantly affecting our day-to-day. A throttle is an obvious answer. Why not throttle the blocking of admins at, say, 1 per 10 seconds. Wouldn't it be be better to end up with 10 or 20 blocked admins than 1300? I'm sure there are other technical alternatives as well if throttling is too difficult. I just don't think this retaliatory block power is the answer. pinging Tim Starling & TParis & Swarm~Awilley (talk)18:00, 6 December 2018 (UTC)
Regarding item 1, Fred and BsZ would both be blocked and then... nothing would have happened. Clearly it offers an avenue for retaliation, but it doesn't escalate beyond that. Maybe an issue on small wikis, but not here. As for items 2 and 3, okay it doesn't solve every problem, but it solves some problems without making any others worse. That's a Good Thing to have, regardless of any other remedies/protections put in place. ~ Amory(u • t • c)20:03, 6 December 2018 (UTC)
Removing Facebook tracking parameter from external links
Latest comment: 5 years ago20 comments10 people in discussion
Following on the prior tracking discussions, this has general support and doesn't need another month for this specific parameter. This is ideal work for bots, and there is no issue if multiple bots work on it so long as they have approved BRFA's. — xaosfluxTalk20:11, 6 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hello all, I'd like to propose that we strip the tracking data from external links that Facebook seems to have added as of October 2018. It looks something like this. This information adds nothing to articles and removing it is in our interest to protect the privacy of our editors and readers. Jon Kolbert (talk) 12:25, 20 November 2018 (UTC)
@Jon Kolbert: I was looking for some actual diffs of the content being added - to see if there is any additional information that we could use to stop it in the first place. Side note, your BRFA has been approved for trial. — xaosfluxTalk12:36, 20 November 2018 (UTC)
I have no problem with this, though it reminds me of the bot that was stripping certain parameters from Google (books) links. Was that KolbertBot? Might be better for that bot (whoever's bot) to do that. --Izno (talk) 18:20, 20 November 2018 (UTC)
@Izno: I'm guessing most editors inserting these have no idea they are doing it, we can set up a 'log' only filter to start tracking these and see where they are coming from. Edit filter warnings don't always play well with mobile editing and I'd rather someone put in a reliable source with this link than just abandon their edit. — xaosfluxTalk18:41, 20 November 2018 (UTC)
I'm guessing most editors inserting these have no idea they are doing it 100% agreed, as with most of the garbage that social trackers and websites using any sort of tracking add to URLs. I'm fine with logging too just to get a sense of it--just some thoughts in general--and would regardless support a bot to remove these (under previous precedent for tracking type URL parameters removal). --Izno (talk) 18:45, 20 November 2018 (UTC)
The only "anonymizing" that KolbertBot did was change country-specific links to an "international" domain. I recall doing similar edits removing referral data from YouTube links on my personal account, but those weren't automated so I didn't submit a BRFA. Jon Kolbert (talk) 18:55, 20 November 2018 (UTC)
Would definitely support removing these, thanks for unarchiving SQL. Seems like PrimeBOT is already the best place for this, so I'd agree it makes most sense to fold this into its purview, especially as this doesn't appear to be an overwhelming issue. ~ Amory(u • t • c)01:55, 4 December 2018 (UTC)
Go for it. I was thinking that we had a similar Bot job. (Must have been thinking of PrimeBOT 17.) It's easy to cause this problem if you just cut and paste URLs, and it is hard to detect on long ones. Hawkeye7(discuss)00:36, 6 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Time to incubate the substubs
Latest comment: 5 years ago57 comments28 people in discussion
NOT DONE
I think everyone here appreciates that Dr. Blofeld is trying to remedy an issue they perceive with their own work. However, in the weeks this has been open a consensus has emerged that any mainspace content is better than hiding it away in draft or user space (The article incubator having been closed for some years now) He is of course still free to tag them individually for speedy deletion, but mass userfying/draftifying is not supported by the community at this time. Beeblebrox (talk) 19:19, 9 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I propose that any stub I created which is below 200 bytes of readable prose/a one line stub without actual information be incubated/moved to user space until they can be fleshed out properly. Most will be at least 5 years unexpanded. It was wishful thinking at the time but there's a lot of currently unacceptable ones which really shouldn't be swamping the categories. There's enough crap content here as it is. There's a lot of "xxx is a village in xx. As of xxx it had a population of xx". Those are bare minimum useful with one fact but I think if there's hundreds of them like that in one category redirect and listify it by district into an A-Z table with population would be more sensible rather than incubate. I was browsing through some places in Nepal etc I created and to be honest a lot of them have degraded with local ips adding dubious, unsourced factoids. Small villages in the developing world are off most people's radars. In a lot of cases we're better off having a list with the population until somebody can write a half decent article and watch it.♦ Dr. Blofeld12:48, 14 November 2018 (UTC)
Absolutely not. Some places (which are automatically notable) have stub articles <200 bytes long. 'Incubating' these stubs isn't going to help if they just languish in draftspace forever. If they're not being improved now, there's even fewer chances that they'd be improved later. It's a bad idea. Thanks for your suggestion, though -- I'm prone to some less than stellar ideas at times, moreso than most editors. ProgrammingGeek talktome14:46, 14 November 2018 (UTC) Okay, so apparently I didn't read the proposal closely enough, sincere apologies! Striking in favour of new comment below. (15:59, 14 November 2018 (UTC))
I'm not a renowned fan of mass stub creation, but fact of the matter is, it's easier for a new editor to improve an existing stub than it is for them to create one. GMGtalk14:53, 14 November 2018 (UTC)
I'd also like to see automated or semi-automated stub-suggestions for new editors, but I'll let you know when someone somewhere cares about my opinion. No luck so far. GMGtalk14:54, 14 November 2018 (UTC)
Well, I meant for example, if someone registers an account, and their first edit is on a rugby player, something like SuggestBot comes by (probably using category information) and says "I see you know that rugby is a thing that exists, here are some stubs (read: things we know you can work on that probably won't get deleted)". But if the user has to configure SuggestBot themselves...well...if they could do that then they know enough of what they're doing that they ain't the target audience. Having said that, queue 4.5 million angry comments about how that is too close to automated welcoming and perennial yadda yadda yadda (even though we've long identified finding work as a barrier to entry for new users). GMGtalk15:01, 14 November 2018 (UTC)
I think we've hit on a separate discussion here, but I for one like the idea of automatically welcoming new users (or, say, newly autoconfirmed users) and offering them some "getting started" suggestions, like filling out a stub or de-orphaning something or I don't know what. Or make something so more experienced users can trigger suggestions, like putting some derivative of a SuggestBot template on their page along with a welcome template. Ivanvector (Talk/Edits) 16:09, 14 November 2018 (UTC)
Could we just be clear that the stubs concerned here are only those created by Dr. Blofeld. Maybe if he could give us a few representative examples that would be helpful. – Uanfala (talk)14:58, 14 November 2018 (UTC)
Dr. Blofeld is in the top 50 by edit count not sure exact number but over 350,000 which means XTools doesn't work for finding a list of article creations. One can find them using this but it also includes redirects and page moves. The limit=5000 will work .. probably a huge number in total. -- GreenC15:04, 14 November 2018 (UTC)
Comment I've come across Dr. Blofeld stubs over the years on obscure topics (regional German language poetry awards) and they have been useful for creating blue links when backlinking or filling in a few details. Sometimes the titles need to be adjusted for English. Not sure it would be helpful to delete unless there are some known cases of bad ideas like every fire station in Belarus. -- GreenC15:01, 14 November 2018 (UTC)
@ProgrammingGeek, Knowledgekid87, and GreenMeansGo: I think you've misread the question. What Dr. Blofeld is asking for is authorisation to conduct a mass transfer of any stub I created which is still below 200 bytes of readable prose (my emphasis). Dr B would be the first to admit that some of his earlier stubs have problems with sourcing and accuracy, and because there are so many of them (I don't have the numbers but at a rough estimate we're talking between 10,000 and 100,000 pages, many of which are genuinely unexpandable substubs bot-created from databases with no text other than "X is a building in Y" or similar) it would require a bot to perform a bulk move of the relevant pages to a {{noindex}}ed space where the sourcing and prose issues can be cleaned up at leisure, and such a bot would require community consensus. What the three of you are effectively saying is that you're better placed than him to assess his own contributions. ‑ Iridescent15:08, 14 November 2018 (UTC)
No, I understand the question. I also understand the Dr. B is so prolific it's hard to separate an attitude toward his stub and an attitude about stubs. GMGtalk15:15, 14 November 2018 (UTC)
I've not been prolific in a very long time, I used to create an enormous number of placeholder stubs pre 2012 which if they've not been expanded this since probably won't soon. My attitude means all stubs not my own but I can't control those.♦ Dr. Blofeld16:04, 14 November 2018 (UTC)
But other than the fact that they are your stubs, that's not really an argument that doesn't apply equally to all stubs, of which we have 3.2 million (about half the project). If they're non-notable, then yeah. They should be deleted and never should have been created. If they're notable, then it's a waste of time to delete them when they need to at some point in the future be recreated. Besides that, I'm fairly confident in saying that automatically deleting tens or scores of thousands of articles is probably not what the community had in mind when authorizing G7. GMGtalk16:17, 14 November 2018 (UTC)
The vast majority are notable, but there's a lot of things like one liners on small rivers, obscure villages etc with no real information, a lot which are hardly vital articles and more marginally notable. A great deal of them might be better listified. If G7 is a problem then they can be moved to user space of course.♦ Dr. Blofeld18:13, 14 November 2018 (UTC)
But again, you're mostly making an argument against stubs in general, and not some critical flaw in these stubs in particular. GMGtalk21:42, 14 November 2018 (UTC)
Support in case it's not obvious from my comment above. That we automatically delete any article without question from the mainspace if requested in good faith and provided that the only substantial content of the page was added by its author has been a basic principle of Wikipedia for a decade; all that's being requested here is that it be done by technical means rather than Blofeld be forced to manually move 10,000+ pages and tag the resulting cross-namespace redirects for deletion. ‑ Iridescent15:12, 14 November 2018 (UTC)
Sure We can incubate (do you mean draftify?) these stubs that only you worked on. That way anyone who wants to work on one and get it main worthy can do so. Alanscottwalker (talk) 15:22, 14 November 2018 (UTC)
Some way of removing what we would call "sub stubs" from the mainspace. If they've not been expanded in six years plus years they're unlikely to be soon. I say under 200b as a lot are fleshier and decent. Basically anything which is a one liner xxx is a bla bla bla, get shot of, if it's that notable somebody will write it later. I did mostly create notable subjects but a lot are ones which most people will hardly be looking for information on. I just think it's time we took this project by the scruff of the neck and had a giant cleanup.♦ Dr. Blofeld15:55, 14 November 2018 (UTC)
Oppose Yes a lot of the sub-stubs are bad and cannot be expanded, and when this occurs they can be individually deleted for lack of notability. I do not see why they should all be deleted because of this, many of the articles are presumed notable. This would set a precedent to delete in excess of a million articles. Maybe more. — Frayæ (Talk/Spjall) 16:11, 14 November 2018 (UTC)
Support On reflection I think a certain level of minimum quality would be reasonable given what we hold as the standard at AfC. None of these articles would meet the requirements we insist on there so deleting/incubating them is reasonable. — Frayæ (Talk/Spjall) 17:00, 14 November 2018 (UTC)
Yes, nothing is being deleted, just moved behind the scenes until they have adequate information. I did identify a lot of notable subjects but if they're still placeholders after years then they're not going to be developed soon.♦ Dr. Blofeld16:23, 14 November 2018 (UTC)
If you approve a bot capable of moving substubs to draftspace then it can potentially be used to remove maintenance backlogs to draftspace as well. Incubated articles are deleted after 6 months via G13. This is a bad idea. — Frayæ (Talk/Spjall) 16:30, 14 November 2018 (UTC)
Then we'll put them in a special category so nothing gets deleted and they're linked in a place people can work on them if they wish.♦ Dr. Blofeld17:08, 14 November 2018 (UTC)
There are no exceptions to G13 and looking at previous RfC discussions on the subject it is going to stay that way. If you want to keep the pages more than 6 months you should make sure they are put in your userspace where you have some say on the matter. — Frayæ (Talk/Spjall) 17:17, 14 November 2018 (UTC)
Support. Deletion criteria should take into account number of backlinks to non-dab mainspace articles; number of external links; byte count of plain-text article body. -- GreenC16:22, 14 November 2018 (UTC)
Comment. I do not have a strong opinion either way, but if this gets closed as oppose or no consensus, we might still want to make a list of such articles so that interested parties could work on it.--Ymblanter (talk) 16:37, 14 November 2018 (UTC)
A typical stub of mine will look like Thüringische Muschwitz, that's 7 years old. Has an infobox and length but little else and the whole category is flooded with ones like it. I think ones like that would be better off in a List of rivers in Thuringia with a table giving information on source and mouth and length so no information is lost until somebody can write a better article.♦ Dr. Blofeld17:50, 14 November 2018 (UTC)
Comment I thought we had generally considered that WP functions as a gazetteer, and thus justifying stubs of any officially recognized town/village or natural landmark, with the basis that local sources potentially could be used to expand these (keeping in mind, no deadline exists for that). I understand if we were talking stubs on persons or other less permanent elements to userify them, but places seemed to have been handled differently in the past. --Masem (t) 18:08, 14 November 2018 (UTC)
True, but the issue I think is people searching through categories and wanting to read and find decent articles and finding almost every entry is xxx is a village and no real information. I've been browsing some and it is frustrating when viewed from a reader's perspective. For a lot of those you could currently represent the same information in one list instead of having to browse dozens of articles just to retrieve one figure.♦ Dr. Blofeld18:22, 14 November 2018 (UTC)
I can see listifying these then by logical groupings to give better context to readers, but this would still demand that redirects be left behind (as a gazetteer, these are searchable terms) and to that end, it doesn't make sense to necessary userify them and instead just appear a redirect to the history. --Masem (t) 18:27, 14 November 2018 (UTC)
Oppose - I think removing them on grounds of quality (vs normal deletion grounds) is incorrect - I don't think it functionally harms Wiki and they can be beneficial if and when someone does want to write on one. Obviously most go a long time without being edited, but there are so many the rate of at least some having edits made must be reasonably high. Nosebagbear (talk) 18:34, 14 November 2018 (UTC)
Leaning oppose. I honestly don't see what's the problem with having these mini-stubs in mainspace, as long as the factual correctness is not in dispute and they have a minimum of sourcing. I would have found Thüringische Muschwitz useful (even in its pre-Ymblanter state), not least because there's the language link to the more developed version on deWP. Also, as noted above, expanding a stub is easier than creating a new article. And every so often someone comes along who does specialize in Nepalese hamlets, even if it does take longer than 6 years - why not make it easy for them to get going? --Elmidae (talk · contribs) 19:24, 14 November 2018 (UTC)
Redirecting these villages to the district where we can put a list of all of them would be the preferred way to go. Don't dump them all in userspace or draft where no one will work on them and they will just need to be managed with the tens of thousands of other abandoned pages there. Legacypac (talk) 21:58, 14 November 2018 (UTC)
A huge number did get expanded though, I'd forgotten how many valuable subjects I'd started too! Yeah maybe the ones with hundreds of villages and one liners belong in a list.♦ Dr. Blofeld23:01, 14 November 2018 (UTC)
Oppose deletion or moving to userspace/draftspace or anything else. If the subject of the article is sufficient to survive deletion discussions, there is no reason to delete or move or do anything to such sub-stubs. If the article should exist, there's no reason to delete beyond the obvious (copyvio, etc.) and just "being too short right now" is not a reason. If the article shouldn't have existed in the first place, by all means, delete it, but if it could be expanded properly, but merely hasn't, please don't.--Jayron3203:47, 19 November 2018 (UTC)
Oppose moving them to draftspace or userspace. Firstly, it could mean we end up with two articles for some subjects, one in draftspace/userspace and another in mainspace when someone recreates it. Secondly, it drastically reduces the number of people who are likely to improve the stub. If you want to improve them, then improve them in mainspace and give others the opportunity to help. If the vast majority are notable, then it is inappropriate to delete them. I like the suggestion that some articles be changed into redirects to lists where the small amount of information can be preserved, avoiding the issue of the articles being recreated by editors who might be unaware of the previous article or this discussion. If the information in the list is expanded, it would be easy enough to split it and replace the redirect. Jack N. Stock (talk) 05:01, 19 November 2018 (UTC)
Oppose removal of stubs: When the info is presented neutrally, a bit of information is better than no information. Also, the mere existence of the article is also informative as it tells the world that a certain topic exists (a town, for example). Moreover, from the editors perspective a stub is more inviting for multiple editors to make small contributions that collectively add up to a better article. In contrast, removing the article from the main space makes it more daunting for any one editor to have to draft a more fleshed out article before publication. Thank you. Al83tito (talk) 18:42, 21 November 2018 (UTC)
Strong Oppose. Outside of articles with serious issues, a short article is much better than no article. In the case of a town, for instance, even a substub can tell you where a place is located, what state/province/county it's in, and basic facts like its elevation and postal code (which may be in the infobox and not the readable prose). A short article also makes a topic more likely to be expanded, especially by new editors (who can't write new articles, probably won't find drafts as easily, and may think anything without an article isn't notable). TheCatalyst31Reaction•Creation22:27, 1 December 2018 (UTC)
Oppose These stubs can be useful even if they are short. Doing this would likely remove any possibility of improvement on the vast majority on them. Linguistical (talk) 07:12, 2 December 2018 (UTC)
Oppose as incubating is an almost useless process. Being in place they are more likely to receive the heat of editors. They has some small use, so geographical stubs are better there than not. Graeme Bartlett (talk) 08:03, 2 December 2018 (UTC)
Oppose Whats the harm of the article? As above, these articles would likely not be touched for improvements, so readers and new editors who may want to expand the content of this stub won't be able to find it. If the article is that small that it needs to be moved to draft space, even when the article is 5 years old and isn't likely to be expanded on, then it should be sent to AfD. 17:34, 2 December 2018 (UTC)
Oppose moving out of namespace 0. If they're a definite net negative, delete them (this can be a good decision if, for instance, a bot could easily create them from scratch from Wikidata data in the near future). Otherwise, keeping them in namespace 0 is the only way for them to have a chance to be improved and attract contributors, while in another namespace they would just rot and amass dust which makes the site less healthy. Nemo16:24, 9 December 2018 (UTC)
1,500,000 divided by 43,000 gives 34 pageviews per article per month, or one view per day. That's lower than the traffic one would expect just from search engine crawlers and people clicking Special:Random; to put it another way, each of these pages is averaging 1⁄30 of the traffic our article on Cats That Look Like Hitler gets. ‑ Iridescent17:52, 9 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Proposal- Allow song pages on Wikipedia to have lyrics
Latest comment: 5 years ago21 comments16 people in discussion
Should we provide lyrics to songs that have a Wikipedia page? I was thinking we provide, after the lead-in and background/composition/content section, a Lyrics section that provides the full lyrics to the song, retrieved from any one of the multiple lyrics site on the web today? Schoolbus777 (talk) 02:40, 4 December 2018 (UTC)
We can't include full lyrics. What we can do is provide snippets of the lyrics to the extent that reliable sources quote and discuss those lyrics, and explain what the sources say about them. A good example of this can be found in Sympathy for the Devil. bd2412T02:56, 4 December 2018 (UTC)
Copyright restricts this but where discussed by RS and where copyright is not a problem, on a case by case basis it is ok. Legacypac (talk) 05:24, 4 December 2018 (UTC)
Comment I would say, as a general rule, it's not appropriate to provide full lyrics even when copyright is not a problem. That's more what Wikisource is for than Wikipedia. That said, I don't see any need for a blanket rule against it. --Trovatore (talk) 23:27, 4 December 2018 (UTC)
Could we have an example of a national anthem under copyright? Specific performances of a national anthem, sure, those are copyright but the closest I'm seeing to any legal restrictions is that some countries make parodies of their national anthem illegal. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)
If the copyright hasn't expired because of age, and the country has passed no special legislation passing the song into the public domain as a national symbol, then a national anthem is copyrighted like any other musical work. As an example, the Swiss National Anthem was updated only three years ago and rewritten by a living person. GMGtalk17:35, 6 December 2018 (UTC)
Lyrics for songs that are out-of-copyright should go on Wikisource, with a link to them in the article. Short extracts can be quoted on arcticles, to illustrate points being discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:57, 5 December 2018 (UTC)
Question I'm aware that lyrics are copyrighted, but why are there so many lyric websites on the Internet at large? Surely they're violating copyright by publishing them, and are probably not paying any sort of royalties. — Frεcklεfσσt | Talk16:39, 6 December 2018 (UTC)
In theory, it is possible that sites like Genius and YouTube have purchased an ASCAP and/or BMI license, which is what radio stations and clubs have in order to be able to play copyright-protected music. I see no reason why such a license would not also permit republication of the lyrics. For the most part, however, lyrics-republishing sites seem a bit dodgy. Wikipedia can't republish lyrics subject to a license, because then our own articles could not be freely licensed. I think we should expand Wikipedia:Lyrics and poetry to provide a more thorough guideline specifying, both legally and stylistically, when and how it is appropriate to present portions of song lyrics. bd2412T16:51, 6 December 2018 (UTC)
Not just theory; as you can see from the Genius article, it acquired licenses in 2014. As I understand it (and mentioned in the cited New York Times article), the music publishers started cracking down at that time. LyricWiki, for example, was acquired by Wikia and entered a licensing agreement with Gracenote. (On a side note, there are lots of different rights in play. As I recall, radio stations pay for a license to perform a recording; this covers the rights for the lyrics, the music, the specific recording, and in some countries, the performers who were recorded. It wouldn't allow for publication of the lyrics themselves.)
Regarding YouTube, I imagine it doesn't worry as much about lyrics as the actual audio and video. YouTube has its content ID program, where it scans uploads looking for copyrighted material, and blanking out audio for unlicensed music, or blocking the video entirely. Some music publishers opt to allow the uploaded video in exchange for getting a cut of the advertising revenue. isaacl (talk) 18:29, 6 December 2018 (UTC)
After exerting no real effort for all of two minutes to find the WHOIS data for lyrics sites, the only one I nailed down was Panama, which has a reputation for not being especially strict on copyright and has a nominal GDP per capita about a quarter of the US's. Whoever set up the site I was looking at could be quite well off locally but still well under what any record company would consider worthwhile to sue for lost royalties. They also make a "fair use" claim that wouldn't hold up in a US court but I could well see a non-US court accepting as being US law. And this is all assuming that it's not just a shell company running through Panama. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)
No Even ignoring the copyright issue, printing full lyrics of songs is outside of what Wikipedia should do in its articles anyways. It isn't really the realm of Wikipedia, which should have encyclopedia articles and not merely be lyrics. Wikisource would be more suited for this. On top of that, add the copyright issues, and that's a double "hell no". --Jayron3218:36, 6 December 2018 (UTC)
A big fat no for the most part. This is Wikipedia, not Wikisource. Unless the lyrics in question is needed for commentary, e.g. fluff about why is it impactful or controversial, that is. Blake Gripling (talk) 09:32, 7 December 2018 (UTC)
Proposal: Pending changes for reference desks, admin requests and other areas.
Latest comment: 5 years ago4 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This may seem like feeding the troll or something along the lines of pre-emptive protection, but wouldn't it hurt to place them under pending changes protection to keep the flood of trolls from disrupting the normal flow of things? Of course, semi-protecting them indefinitely wouldn't cut it as there may be anonymous users who would like to ask a legitimate question or two, but there are those who have a gross sense of schadenfreude and delight at creating drama 4chan or Dramatica-style. Blake Gripling (talk) 09:35, 7 December 2018 (UTC)
No, it would be pointless because his shit will still be in the history until we rev-delete it, and also no because the nature of his attacks is to rapidly hit the desks over and over until they are fully protected. PC stops exactly none of that. --Jayron3215:06, 7 December 2018 (UTC)
Additionally, between the high level of his activity and the high inherent activity level of these pages, PC becomes rapidly unworkable as it is exponentially more complicated to keep good edits and remove bad ones as they get inter-mixed in the pending queue. Nosebagbear (talk) 19:24, 7 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Request for Ideas About Mediation
Latest comment: 5 years ago3 comments3 people in discussion
On 12 November 2018, in this project, a Request for Comments was closed which shut down the Mediation Committee. The question, was asked by the minority who opposed the shutdown, what would happen when there was a dispute that would have been handled by MedCom that was beyond the scope of DRN. Some of the answers were that DRN could be expanded, or that something would be done if an issue arose for which heavy-weight mediation was in order. I have a time-sensitive question for those who supported the shutdown (and also for those who cautioned against it) of how to resolve a specific open dispute. The content dispute, which is waiting for a moderator at the Dispute Resolution Noticeboard, concerns Origin of the Romanians. It is clear from the record and the number of times that issues about this article have been around that improving the article will take longer than the one to three weeks that disputes at DRN take. It appears to be a content dispute, not much affected by conduct issues, but too complex to be easily addressed in one to three weeks. In short, this is just the sort of dispute that the Mediation Committee used to handle when it had a workload and mediators. So my question for anyone is: Does anyone have any suggestions for how this dispute should be resolved?
I have asked for a volunteer to conduct heavy-weight mediation, possibly lasting several months. I haven't found one. I have one volunteer who is willing to try tag-team mediation with two or three volunteers taking turns mediating, but I don't have the second or third volunteers. So my question for anyone who said that we did not the Mediation Committee is: How should this dispute be resolved? Does anyone have any creative ideas for how to handle this? Does anyone have any obvious ideas that have been overlooked? What should be done next? There is a dispute waiting for a mediator.
From a cursory glance at the relevant dispute, all that needs to happen is enforcement of the existing discretionary sanctions. What's happening there is not a 'content dispute', it's groups of nationalist editors fighting to push their respective points of view. No matter how much you 'mediate' such a dispute, some vested party will not be satisfied. RGloucester — ☎04:39, 10 December 2018 (UTC)
I don't think the Mediation Committee would've helped at all. In these sort of nationalistic battlegrounds, everyone involved in the dispute aren't going to agree to mediation nor are they going to accept the result if it doesn't go their way. Galobtter (pingó mió) 07:34, 10 December 2018 (UTC)
Should IPs be barred from turning redirects into articles?
Latest comment: 5 years ago13 comments9 people in discussion
Hello everyone, I am going to propose that redirects should plausibly be expanded into an article by registered users and not by IPs. I've noticed many serial sock puppeteer and even paid editors often use IPs to turn redirects into articles. --Saqib (talk) 15:21, 2 December 2018 (UTC)
We have been adding lots more restrictions as of late (article creation to autoconfirmed, removal of patroller from autoconfirmed, removal of admin rights to unblock themselves) isn't the page curation enough since that lists redirects converted into article as far as I'm aware (example). Crouch, Swale (talk) 15:30, 2 December 2018 (UTC)
The concerns about speedy deletion and being bitey don't (generally) apply with redirects, if a redirect is converted into an article and its not fit for inclusion, it can just be changed back to a redirect. Crouch, Swale (talk) 15:50, 2 December 2018 (UTC)
I don't know if there are stats on this specifically, but generally it's an extremely low percentage of logged-out editing that turns out to be problematic, like less than 2%. There are stats on that number, but I don't have them at hand. As for ACREQ, a redirect is kind of a predetermination that a title might be expandable to an article at some point, if anyone comes along that wants to bother doing the work. I think we should not impose new restrictions on the very large majority of logged-out users expanding redirects constructively because there are a relatively tiny bunch doing small amounts of harm. A while back we identified an issue with anons hijacking dabs and redirects to get around ACREQ, but we mostly dealt with that. In this case it seems the proposal would bring more harm than benefit. Ivanvector (Talk/Edits) 03:52, 4 December 2018 (UTC)
There's some stats that could be imported from WP:PERENNIAL, actually, but they're about a decade old and based on very small samples. The page gives 76-82% constructive edits from logged-out editors. I know there are better stats than "I picked the most recent 250 IP contribs and judged which among them were constructive" but that's all I can find right now. Ivanvector (Talk/Edits) 03:55, 4 December 2018 (UTC)
I would propose that there should be some kind of a public log that gets updated every time a redirect is retargeted or converted into an article, and indicates which editor or IP carried out the retargeting or conversion. That would give us a quick and useful sense of the scale of this as a problem. If there already is such a log, I'd love to know about it. bd2412T04:15, 4 December 2018 (UTC)
As someone who frequently patrols these articles for NPP, I'm pretty ambivalent; if we keep the current method fine and I wouldn't object if we changed it. On the one hand it's easy to fix in the ways many other new articles aren't - simply restore the redirect. On the other hand many of the articles appear instantly in Google because of the age of the redirect which is less than ideal. These are fairly easy to patrol on the whole but NPP is also getting progressively further backlogged so not spending time on these could be good. It is consistent with ACPERM, but again restoring the redirect is very simple and sometimes we might get new notable encyclopedic content out of it. Best, Barkeep49 (talk) 05:14, 13 December 2018 (UTC)
Patriarch is not misogyny (see misogyny)
Latest comment: 5 years ago5 comments5 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Create a layman option for the people that do not know all the rules but see a glitch that needs fixing. Example: Misogyny list PATRIARCH as a word that defines it. This is wrong. {Biblically} Patriarchy is not meant to be misogynistic. It is the one person in every family that is the head of that family. There can only be one head of family responsibilities. It was the God of all mankind that assigned the man to be head of the family. So each man must treate his family with love. Man is commanded to treat his wife as he would treat his own body. This is a direct contrast to misogyny.
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.
Proposal: Applying Value-Sensitive Algorithm Design to ORES
Latest comment: 5 years ago2 comments2 people in discussion
ORES has been out and served for the Wikipedia community for a while, for the purpose such as counter-vandalism. Having seen the wide usage and effectiveness of ORES in the community, we'd like to continue working on ORES development. We plan to improve and redesign ORES algorithms by incorporating feedbacks of all the stakeholders involved in the entire ORES ecosystem, such as ORES application developers, ORES application operators, etc. We want to understand their concerns and values, and come up with effective algorithmic designs that can balance trade-offs and mitigate potential conflicts of interests (such as edit quality control v.s. newcomer protection) to further improve ORES performance.
We will work with Aaron Halfaker (User:EpochFail) and his team to make improvements on ORES quality control models, and identify its limitations. Here is the project proposal on Meta-Wiki. If you are interested or have any thoughts, please feel free to reach out to me. Thanks! Bobo.03 (talk) 14:43, 13 December 2018 (UTC)
See mw:ORES for more information about ORES. In short, ORES is a machine learning platform that my team maintains. It helps with vandalism detection, new page patrolling, WikiProject task lists, and a few other types of Wiki work. --EpochFail (talk • contribs) 14:48, 13 December 2018 (UTC)
Accessibility of links in header at the administrators' noticeboard for incidents
Latest comment: 5 years ago1 comment1 person in discussion
Tagging fair use images with the date of their freedom
Latest comment: 5 years ago4 comments3 people in discussion
As I'm sure most on here know, in just three weeks, for the first time in the history of Wikipedia, the United States will see a year's worth of copyrighted works become public domain. There are a number of images currently being used under a claim of fair use that will be able to be re-tagged as public domain (for example, most any image in an article in Category:1923 films). Something that would be nice to help with that effort would be if we can start tagging images with the date that they will become public domain (if known). Obviously, some things won't be known because their authors are still alive and others are not easily ascertainable because we have no idea when it was originally published, but for those things with a clear publication date, it would be nice to have Category:Public domain in 2019, Category:Public domain in 2020, etc. Perhaps a bot could go through and tag all fair use images as Category:Public domain date not assessed and then if it's unknowable, we move it to Category:Public domain date unknowable, but otherwise put it in a correct yearly category. That will facilitate uploading or restoring high-res versions and retagging it as public domain once the respective date hits. --B (talk) 20:39, 11 December 2018 (UTC)
It doesn't sound too bad of an idea, but there are some questions on how far would the bot tag into the future. I would not want different categories for every single year, as that would be kind of unnecessary. Instead, the bot could do something like Category:Public domain by year/2020, like how many bots sort alphabetical lists. I would also appreciate some information on how you would plan on making the bot functional? Integral Python click here to argue with me14:37, 12 December 2018 (UTC)
@IntegralPython: A human is going to have to review a lot of them, maybe even all of them. In the fullness of time, the various templates and the upload form could be modified to incorporate the necessary fields (publication year, publication country, author's death year) so that the templates can be self-tagging. For example, for File:HairyDawgSanfordStadium.jpg until Thomas Sapp (the guy who designed the mascot) dies, we have no idea when the copyright will expire. Or for File:Batman181.JPG, it doesn't give us the publication date in anything machine-readable (or the publication country for that matter), but a human can see that it was published in the US in 1966 and so the copyright will expire January 1, 2062. So for that case, if the upload form and templates allowed you to specify such things, the date could be calculated automatically. But for now, a first step is to create the categories and allow things to be moved there manually (with the goal that templates can automatically categorize images in some cases). --B (talk) 19:11, 12 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I want to make a suggestion that Wikipedia only be open for non-admin editing M-F 6am-10PM UTC, Saturday and Sunday 8AM-4PM UTC. Except, weekend hours should apply on major holidays, Christmas Eve, and NEw Years Eve. The site should be locked from non-admin editing all day Easter Sunday, Thanksgiving Day, and Christmas Day. 2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:50, 16 December 2018 (UTC)
I want to make a further suggestion that Wikipedia only be open for non-admin editing M-F 6am-10PM UTC, Saturday and Sunday 8AM-4PM UTC. Except, weekend hours should apply on major holidays, Christmas Eve, and NEw Years Eve. The site should be locked from non-admin editing all day Easter Sunday in the US, Thanksgiving Day in the US, and Christmas Day.2602:306:3357:BA0:E529:2E38:525C:E658 (talk) 22:38, 16 December 2018 (UTC)
What are all of the wikipedians that don't celebrate Christmas going to do while they're bored because all the stores are closed? Natureium (talk) 22:45, 16 December 2018 (UTC)
Not everyone observes Christmas, and Wikipedia has not burned to the ground despite accepting edits the last seventeen Christmases. Mz7 (talk) 22:45, 16 December 2018 (UTC)
So block only US-based IP addresses (unless they are being used by admins) for Thanksgiving and Easter, but based on UTC time zone? My observation is that Easter is not a holiday in the US, it's basically just another Sunday, so why should this apply in the US? Jack N. Stock (talk) 22:52, 16 December 2018 (UTC)
Easter Sunday is not a federal or state holiday in the U.S. (especially since it falls on a Sunday) – it is a religious holiday observed by Christians worldwide. We have plenty of non-Christian/non-American users who do not observe Thanksgiving, Christmas, or Easter who would be happy to fill in for recent change patrolling on those days. Even on New Year's Day, we have plenty of users who would be happy to do recent change patrolling not because they feel any kind of obligation to do so, but because they want to. Mz7 (talk) 22:58, 16 December 2018 (UTC)
Leaving aside the time zone issue, for what reason does this need to be done? Also, many people work third shifts or other odd hours that this idea does not account for. 331dot (talk) 22:55, 16 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Can we have an AfroCine deletion sorting list?
Latest comment: 5 years ago2 comments2 people in discussion
If its not against any guideline, I think it will be a smart idea to have an Africa cinema AFD list. I think this will increase participation of Wikipedians in AFDs, especially for African countries that do not have an active on-wiki WikiProject. Another thing is that aside few AfroCine countries, the cinema industry are similar in terms of their online coverage. What I mean is that we should have something like Wikipedia:WikiProject Deletion sorting/AfroCine, where topics related to African cinema should be listed. Pinging the initiator of AfroCine for if he has inputs cc @Jamie Tubers:HandsomeBoy (talk) 09:47, 17 December 2018 (UTC)
I totally agree with you regarding this! It's something I intended to bring up in the long run....so nice that you've brought it up now.--Jamie Tubers (talk) 19:37, 17 December 2018 (UTC)
GlobalFactSyncRE/DBpedia project proposal
DBpedia, which frequently crawls and analyses over 120 Wikipedia language editions, has near complete information about (1) which facts are in infoboxes across all Wikipedias, and (2) where Wikidata is already used in those infoboxes. GlobalFactSyncRE will extract all infobox facts and their references to produce a tool for Wikipedia editors that detects and displays differences across infobox facts in an intelligent way to help sync infoboxes between languages and/or Wikidata. The extracted references will also be used to enhance Wikidata. For more see https://meta.wikimedia.org/wiki/Grants_talk:Project/DBpedia/GlobalFactSyncRE
Please let us know what you think, your opinion is important to us! Thank you! — Preceding unsigned comment added by M1ci (talk • contribs)
"Editnotice manager" user right
Latest comment: 5 years ago7 comments6 people in discussion
I propose a new right the sole ability to edit editnotices. Currently this is appended onto filemover, and I find this a bit odd that you would have to request a completely different user right to get the ability to edit editnotices. Surely it would be useful to have a right that simply allows editing of editnotices and nothing else. — Preceding unsigned comment added by Username Needed (talk • contribs) 10:14, 18 December 2018 (UTC)
Filemovers have it as a byproduct of the (very) recent addition to override the title blacklist; previously, only template editors had the ability, which makes sense. Don't see a need. ~ Amory(u • t • c)11:59, 18 December 2018 (UTC)
Both page movers and template editors have this access already, and there is generally no backlog on edit requests in this area. — xaosfluxTalk14:17, 18 December 2018 (UTC)
You know what would be really useful? The ability to turn off the sidebar on the left. If it could turn into a "sidebar" tab so that clicking the tab brings it back, that would be icing on the cake. --Guy Macon (talk) 13:13, 17 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This is my idea for a new user warning template under uw-selfarticle.
While the autobiography template already exists, what would be nice is a template to tell people to stop inserting papers that they themselves have written as references. Natureium (talk) 19:39, 17 December 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
There are some XfD proposal
Latest comment: 5 years ago2 comments1 person in discussion
Update the padlocks with grey shackles, without bias towards other discussions as to design specifics
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.png)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
looks like 
Done for all three points for the main variant. Other versions will be updated in ~9 hours (assuming the alarm works). – XYZt (talk | contribs) – 06:09, 4 November 2018 (UTC)
I think that if these icons are changed the other topicons should be changed too for visual continuity. I have created some ideas for simple versions of the good and featured article icons: File:Minimalist good article icon.svg and file:Minimalist featured article icon.svg. 🌸 WeegaweeK ^ 🌸 16:57, 30 October 2018 (UTC)
, feedback appreciated. ProgrammingGeek talktome 16:13, 27 November 2018 (UTC)
was this by design? [3] Shouldn't there be a icon created called "Semi-protection-unlocked" based on this > 
