Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Suffusion of Yellow (talk | contribs) at 16:56, 6 April 2021 (→‎Survey (minor edits): q). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


    Promote Wikipedia:Video links from essay to guideline

    Wikipedia:Video linksmight have some shortfalls, but it is ready for edits and review to become a guideline. Talk page notified. 2601:601:CE7F:E270:5456:2939:9AB9:38F1 (talk) 07:08, 6 April 2021 (UTC)[reply]

    Convert all English variant notices to editnotices

    This proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

    One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u|Sdkb}} talk 14:34, 10 January 2021 (UTC)[reply]

    Survey (English varieties)

    • Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u|Sdkb}} talk 14:34, 10 January 2021 (UTC)[reply]
    • Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest "scribble" 15:34, 10 January 2021 (UTC)[reply]
    • Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paul ❬talk❭ 16:55, 10 January 2021 (UTC)[reply]
    • Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)[reply]
      Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.
      Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}} talk 19:12, 10 January 2021 (UTC)[reply]
    • Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers 18:50, 10 January 2021 (UTC)[reply]
    • Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)[reply]
    • Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf (talk) 22:06, 10 January 2021 (UTC)[reply]
    • Support we do this for a few Canadian articles already...like Template:Editnotices/Page/Canada....still not seen in mobile view :-( --Moxy 🍁 01:06, 11 January 2021 (UTC)[reply]
    • Oppose Arguments below convince me this is not a great idea. I think that it's better to use the "silent" {{Use American English}} etc and at worst let gnomes fix the problems. — Wug·a·po·des​ 23:07, 16 March 2021 (UTC) Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. — Wug·a·po·des​ 02:54, 11 January 2021 (UTC)[reply]
      • I also like the idea of removing them altogether. — Wug·a·po·des​ 21:45, 13 January 2021 (UTC)[reply]
      • Template editors and page movers may not want something else to do. It seems simple enough to write a bot with the necessary permissions to do this. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)[reply]
    • Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)[reply]
      Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}} talk 11:05, 11 January 2021 (UTC)[reply]
      No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken (talk) 21:26, 11 January 2021 (UTC)[reply]
      I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)[reply]
    • Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. --Tom (LT) (talk) 03:20, 11 January 2021 (UTC)[reply]
      • Having read through some comments below I have come to change my mind. As pointed out below this is likely to result in a large amount of editnotices that is likely to frustrate and deter editors. Tom (LT) (talk) 10:56, 6 April 2021 (UTC)[reply]
    • Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)[reply]
      Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)[reply]
    • Support per proposal ~ ToBeFree (talk) 11:09, 11 January 2021 (UTC)[reply]
    • Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpy‍talk 12:47, 11 January 2021 (UTC)[reply]
    • I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) --Izno (talk) 14:41, 11 January 2021 (UTC)[reply]
      • @Izno: I think it would be at most creating 41,000 edit notices with current use of the eng var module. --Paul ❬talk❭ 18:36, 11 January 2021 (UTC)[reply]
        • Just a casual 41k. Eyeroll. --Izno (talk) 18:44, 11 January 2021 (UTC)[reply]
          • Trivial for a bot. Thryduulf (talk) 19:57, 11 January 2021 (UTC)[reply]
          • Trivial or not, a very different figure to 6 mil. --Paul ❬talk❭ 21:14, 11 January 2021 (UTC)[reply]
            • Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. --Izno (talk) 01:39, 12 January 2021 (UTC)[reply]
    • Support This seems like a good idea worth pursuing. --Jayron32 18:16, 11 January 2021 (UTC)[reply]
    • Support Reducing talk page clutter is a good idea. Remagoxer (talk) 20:51, 11 January 2021 (UTC)[reply]
    • Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)[reply]
    • Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)[reply]
      @DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)[reply]
    • Oppose Will only worsen banner blindness. CaptainEek Edits Ho Cap'n!⚓ 20:41, 12 January 2021 (UTC)[reply]
    • Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)[reply]
    • Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)[reply]
    • Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich harass/hound 04:53, 13 January 2021 (UTC)[reply]
      This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)[reply]
      An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich harass/hound 17:27, 13 January 2021 (UTC)[reply]
      I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}} talk 00:06, 14 January 2021 (UTC)[reply]
    • Oppose We should save banners for the truly important stuff like BLP, rather than spelling. (t · c) buidhe 18:35, 13 January 2021 (UTC)[reply]
    • Oppose per Graeme Bartlett and CaptainEek. ~ HAL333 22:19, 13 January 2021 (UTC)[reply]
    • Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)[reply]
    • Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)[reply]
      @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}} talk 01:58, 15 January 2021 (UTC)[reply]
      I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)[reply]
      To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)[reply]
      Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"
      Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}} talk 13:05, 15 January 2021 (UTC)[reply]
    • Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)[reply]
    • Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutralitytalk 19:43, 15 January 2021 (UTC)[reply]
    • Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)[reply]
    • Oppose per Graeme Bartlett and CaptainEek. Cavalryman (talk) 03:14, 16 January 2021 (UTC).[reply]
    • Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)[reply]
      • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)[reply]
      Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)[reply]
      • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)[reply]
        • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
          Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader (talk) 20:26, 18 January 2021 (UTC)[reply]
          • The current editnotice should be terminated with prejudice. KevinL (aka L235 · t · c) 20:52, 18 January 2021 (UTC)[reply]
            • I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett (talk) 23:59, 18 January 2021 (UTC)[reply]
    • Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel (trees/nuts) 01:04, 20 January 2021 (UTC)[reply]
      Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel (trees/nuts) 01:06, 20 January 2021 (UTC)[reply]
    • Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 (talk) 06:41, 20 January 2021 (UTC)[reply]
      Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader (talk) 23:00, 21 January 2021 (UTC)[reply]
    • Weak oppose; how many times have you read on AN or ANI a reminder along the lines of, "Dear OP, did you miss the violently orange notice when you posted here?" If they miss that, do we really think that an editnotice will prevent page watchers from having to revert to the correct EngVar? Personally, i think that editnotices should be kept for the very most important things ~ things that if you cross or miss might end up with your privileges restricted. happy days, LindsayHello 14:10, 22 January 2021 (UTC)[reply]
    • Support but only if there's an option for logged-in editors to turn off the notifications. Lugnuts Fire Walk with Me 17:23, 22 January 2021 (UTC)[reply]
    • Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)[reply]
    • Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)[reply]
    • Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor(discuss) 22:10, 29 January 2021 (UTC)[reply]
    • Support, ideally with the notice stripped down to its bare essentials. Perhaps just United States This article is written in American English, and this should not be changed without consensus. Learn more. I see using editnotices as an improvement in multiple ways. Talk pages become less cluttered. Newbies who don't know about our approach to English varieties are more likely to learn about it and avoid making unwanted changes. And more experienced users editing articles without strong national ties can quickly see how they should write without having to either check the talk page or scan the article for clues as to the preferred variety. the wub "?!" 23:35, 30 January 2021 (UTC)[reply]
    • Support - this seems like a good idea. Rollo August (talk) 17:32, 3 February 2021 (UTC)[reply]
    • Oppose per Levivich and L235. AVSmalnad77 talk 04:04, 5 February 2021 (UTC)[reply]
    • Oppose. Edit notices make it harder to edit. They should be reserved for important matters. Espresso Addict (talk) 07:54, 11 February 2021 (UTC)[reply]
    • Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEP of the highest order, and is also an end-run around nearly two decades of consensus that no style matters aside from some key points about article titling rise to policy level. While we're at it, also just get rid of the talk page banners for this. The "silent" templates like {{Use British English}} at the top of the actual article is entirely sufficient.  — SMcCandlish ☏ ¢ 😼  18:01, 13 February 2021 (UTC)[reply]
    • Weak support, this is one option to reduce current clutter. These templates already exist as edit-notices, so whether or not they should be needs to be a different discussion. Either way, as a talkpage tag or edit notice, they should be sharply reduced in prominence/space in line with similar comments above, first of all by removing flags/other images per the spirit of WP:FLAGCRUFT. Frankly these notices could be reduced to two words (eg. "British English", "American English") left somewhere consistent on the talkpage/edit notice. CMD (talk) 17:46, 14 February 2021 (UTC)[reply]
    • Oppose per SMcCandlish. Editnotices should be reserved for important instrctions/information only. --NSH001 (talk) 10:04, 20 February 2021 (UTC)[reply]
    • Oppose clutters the editnotice space with hundreds of thousands of pointless editnotices, while making sure editnotices need to be even flashier for users to read them. Ideally, we'd have a standardized location in the editor displaying the English variety - and editnotices are a hacky - and bad - way to somewhat emulate this. Elliot321 (talk | contribs) 01:45, 28 February 2021 (UTC)[reply]
      Elliot321, a standardized location in the editor is an interesting thought. Where would you envision it going? Are there any phab tickets seeing if the WMF could look into adding something? {{u|Sdkb}} talk 07:08, 3 March 2021 (UTC)[reply]
      Sdkb sure, here's a mockup I made for source editor (what I use): File:English Variety mockup - source.png. I'm unsure of if there are any phab tickets. Elliot321 (talk | contribs) 07:21, 3 March 2021 (UTC)[reply]
      Elliot321, that looks pretty good to me! Hovering over the word "British" could perhaps provide a tooltip with word examples (ideally tailored to the actual words used on the page). If you go forward and turn the mockup into a more formal proposal, I'd support. My read of this discussion is that there's definitely desire to make the language tag less prominent but just disagreement about how to do it, so I think your solution might have strong support if it can be implemented. {{u|Sdkb}} talk 07:39, 3 March 2021 (UTC)[reply]
      Sdkb yeah, that would be my idea.
      Now, the question is how to set it? Though I suppose the {{Use blah English}} templates do that just fine, and that could probably be detected in the editor. Elliot321 (talk | contribs) 07:43, 3 March 2021 (UTC)[reply]
    • Support Most users don't bother to look at the talk page unless they want to post a discussion there. A new user might not even know that talk pages are there! This is a very useful proposal. 🐔 Chicdat  Bawk to me! 11:22, 5 March 2021 (UTC)[reply]
    • Opppose. I support aggressively cutting talk page clutter, but this notice to an even-more-visible edit notice does not accurately reflect its importance (it's a MoS issue, and I concur with SMcCandlish that we should not bludgeon editors about it, like an edit notice would do). — Goszei (talk) 16:37, 8 March 2021 (UTC)[reply]
    • I have long thought that the Variant notice should go on the Article page, and not the Talk Page. Just a simple one line hat note saying something like “This article uses UK spelling and grammar” at the top of the page would be enough. Blueboar (talk) 16:50, 8 March 2021 (UTC)[reply]
    • Oppose per above.  Spy-cicle💥  Talk? 18:52, 10 March 2021 (UTC)[reply]

    Discussion (English varieties)

    • If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Wikipedia:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia (Talk) 16:46, 10 January 2021 (UTC)[reply]
    • Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)[reply]
      • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)[reply]
      • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)[reply]
        • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)[reply]
      @Johnuniq, I believe that this will involve creating tens of thousands of edit notices. WhatamIdoing (talk) 20:01, 22 January 2021 (UTC)[reply]
    • Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest "scribble" 23:30, 10 January 2021 (UTC)[reply]
      • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)[reply]
        • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)[reply]
    • The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)[reply]
      • Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf (talk) 11:12, 11 January 2021 (UTC)[reply]
        • I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)[reply]
    • I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)[reply]
      Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich harass/hound 06:16, 13 January 2021 (UTC)[reply]
      You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.
      Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)
      Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)[reply]
      Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)[reply]
    • Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)[reply]
      @Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux Talk 11:45, 16 January 2021 (UTC)[reply]
      @Xaosflux: Is there evidence that such refactoring has been a significant problem thus far? Because if not then I think that Blueboar's suggestion is correct. Nsk92 (talk) 00:31, 4 April 2021 (UTC)[reply]
    • At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)[reply]
      I agree that the banners should be trimmed down, but I think the flags are actually quite helpful as a visual shorthand, so they're an element I think we should keep. {{u|Sdkb}} talk 21:15, 14 February 2021 (UTC)[reply]
    • My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)[reply]
      Trialpears, as I mentioned a bit in my !vote, I see this as an underlying problem—there are lots of situations in which anyone autoconfirmed ought to be able to edit a page's editnotice but can't (not because of any editorial consensus, but just because of something about the back-end technical structure of editnotices). That's a problem that we should solve (and if this goes through, it might nudge us toward doing so), but I don't think we should handicap ourselves here and reject this because of it. To do that would both obscure the level of need to resolve the issue and give ourselves more work down the road once it is resolved. {{u|Sdkb}} talk 00:12, 13 February 2021 (UTC)[reply]
      I feel like that would in general be a good idea, but I still see some reasons for the protection. Vandalism at editnotices would likely not be detected most of the time and even if it was detected most editors would probably not be familiar how to solve it. Putting misinformation in them could be significantly worse. I would definitely support enabling it for extended confirmed users though. With regards to implementation the restriction is governed by MediaWiki:Titleblacklist which can easily switch it to requiring autoconfirmed. It should also be possible to use a editfilter instead which could implement an extended confirmed restriction instead. --Trialpears (talk) 21:26, 16 February 2021 (UTC)[reply]
      Sdkb I don't see an issue with keeping editnotices to people who can override the blacklist - needing to edit editnotices is quite niche and they should, in most cases, be using templates which are not on the blacklist and thus can be edited.
      As long as edit requests are fulfilled quickly, this is fine. Perhaps more people should apply for page mover? Elliot321 (talk | contribs) 07:29, 3 March 2021 (UTC)[reply]

    Pending-changes protection of Today's featured article

    The idea of automatically applying WP:Semiprotection to WP:Today's featured article (TFA) has been thrashed to death; see WP:PERENNIAL#Protecting Today's Featured Article on the Main Page. I think the most recent discussion was in July 2020, at WT:Today's featured article/Archive 14#Question about protection. The key argument (for me at any rate) is that the last thing we want to do is discourage new editors.

    Nevertheless, any time an article with a hint of controversy is TFA, it turns up at WP:ANI. For some recent examples, see Wikipedia:Administrators' noticeboard/IncidentArchive1057#The Holocaust in Slovakia—TFA subject to ongoing vandalism (27 January 2021), Wikipedia:Administrators' noticeboard/IncidentArchive1057#Guadeloupe amazon—Today's TFA subject to ongoing vandalism (28 January 2021), Wikipedia:Administrators' noticeboard/IncidentArchive1057#Pyramid of Nyuserre —Today's TFA subject to persistent vandalism (30 January 2021) and WP:ANI#Hitler's prophecy—TFA undergoing ongoing vandalism (30 January 2021). They may also get posted at WP:AIV, which is less easy to search. I haven't seen reports of problems with WP:DYK articles.

    During that last discussion, I suggested that TFA might be WP:Pending changes-protected for only so long as it is on the Main Page; and this idea seems to be new. IPs and unconfirmed editors would be able to post, even if their contributions didn't display immediately; and vandalism could be speedily dispatched where it belongs. A TFA's godaprents could be encouraged to help the regular pending changes patrollers. It would also solve the problem of working out when the vandalism occurred and who did it (a perennial problem with the small amount of vandalism I deal with - mostly involving links to DAB pages - which can be buried behind several recent good edits and require copy&paste from the last good version). It shouldn't be technically difficult to implement; it could be part of the script which adds articles to and removes them from the Main Page. Some other editors seem to like the idea, and it was suggested that I open a discussion here. (For the record - I'm in favour.) Narky Blert (talk) 10:36, 2 February 2021 (UTC)[reply]

    I'll note that one of the primary reasons for rejections of auto semi on TFA in the past is giving the impression that Wikipedia isn't so free to edit by having our most visible page be uneditable to the majority of the audience of TFA. Pending changes protection avoids this by still allowing users to make the edit, even if there is a slight delay in publishing it live, so it would be a decent compromise between unfettered access and maximum accessibility for our most visible page, and avoiding wasting of the community's time and potential risk of bad content being put up for all to see. Regards, User:TheDragonFire300. (Contact me | Contributions). 11:01, 2 February 2021 (UTC)[reply]
    As a further thought - the protection template text should be tailormade for TFA, and welcoming. Narky Blert (talk) 13:35, 2 February 2021 (UTC)[reply]
    And another - WP:ANI#Pacific swift - Today's TFA receive high level of IP Vandalism (4 February 2021). Narky Blert (talk) 08:59, 5 February 2021 (UTC)[reply]
    Another one, for which protection was declined - WP:ANI#Cheadle Hulme - Today's TFA receive high level of IP Vandalism (5 February 2021). Narky Blert (talk) 11:42, 7 February 2021 (UTC)[reply]
    This is every edit made to Cheadle Hulme during its day at TFA. I see a grand total of two IP vandals, one of whom made two edits and one of whom made one, while every other IP edit is constructive. If any admin had protected it under those circumstances, then unless there's something I've missed they'd have been instantly hauled off to Arbcom for admin abuse. ‑ Iridescent 12:37, 7 February 2021 (UTC)[reply]
    I am not an admin, and have no comment on whether any particular page should or should not have been protected. Nevertheless, I have felt it right to post here every relevant ANI post since I opened this discussion, no matter whether they help or harm my proposal. All evidence is important towards reaching a consensus. (I have not monitored WP:AIV or WP:RFPP, which would be much more difficult.) Narky Blert (talk) 20:10, 19 February 2021 (UTC)[reply]
    Another one - WP:ANI#Apollo 14 - Today's TFA receive high level of IP vandalism and unsourced content (8 February 2021). Narky Blert (talk) 12:53, 9 February 2021 (UTC)[reply]
    And another - WP:ANI#Bernard A. Maguire - Today's TFA suffered persistent vandalism (11 February 2021). Narky Blert (talk) 00:23, 12 February 2021 (UTC)[reply]
    WP:ANI#Vandalism on TFA Grant Memorial coinage (12 February 2021). Narky Blert (talk) 05:42, 13 February 2021 (UTC)[reply]
    Another - WP:ANI#Vandalism on Saturn (magazine) (14 February 2021). Narky Blert (talk) 07:30, 14 February 2021 (UTC)[reply]
    Today's installment - WP:ANI#Vandalism on Silesian Wars (15 February 2021). When this one got reported to ANI, it had only a couple of hours left on the main page. Cluebot and something like six registered editors had already dealt with edits to it; add in the protecting admin, and that's a lot of work.
    I spotted something I hadn't noticed before - User:TFA Protector Bot had stuck {{pp-move}} on the article on 26 January, with automatic expiry at midnight 15 February. Narky Blert (talk) 17:34, 16 February 2021 (UTC)[reply]
    @Narky Blert: For several years now, it has been normal for all upcoming TFAs (which don't already have move protection) to be given a short-term move prot, set to expire the moment the article stops being TFA. Until November 2013 it was a manual process; since then it has been tasked to TFA Protector Bot, see the BRFA. This prot is usually applied some time in advance (I believe soon after the calendar slot has been approved), see the bot's log; and the use of {{pp-move}} is supplementary to that. --Redrose64 🌹 (talk) 22:33, 16 February 2021 (UTC)[reply]
    I didn't know of that procedure (which was why I mentioned it), but it strikes me as an excellent one. Even a good-faith move of a reviewed and queued article would be disruptive, in the greater scheme of things. We don't want redirects on the main page.
    Also - WP:ANI#Vandalism on Meteorological history of Hurricane Dorian (19 February 2021). Narky Blert (talk) 20:00, 19 February 2021 (UTC)[reply]
    And another two - WP:ANI#Vandalism on SS Mauna Loa (19 February 2021) and WP:ANI#Multiple IPs adding porn or offensive image in supposedly TFA article (20 February 2021). On the second one, I count (among other reversions) seven WP:REVDELs while the article was on the main page. Narky Blert (talk) 00:53, 21 February 2021 (UTC)[reply]
    Another - WP:ANI#Vandalism on Margaret (singer) (23 February 2021; also mentioned by Levivich, below), which illustrates a problem. An admin WP:SILVERLOCKed the page for 3 days (which IMO is too much in both duration and level); a non-admin closer thought that the problem should have been posted at WP:RFPP not ANI. Narky Blert (talk) 21:49, 24 February 2021 (UTC)[reply]
    @Narky Blert: It was I who closed that thread; in that case, there was already a duplicate at WP:RFPP, so having an ANI thread seemed redundant. Regards, User:TheDragonFire300. (Contact me | Contributions). 04:57, 2 March 2021 (UTC)[reply]
    PC is widely agreed not to work/be practical on highly edited pages. That's why no one suggests it, probably. --Izno (talk) 15:44, 2 February 2021 (UTC)[reply]
    This is something that was proven during the PC backdoor attempt, by the Barack Obama and George W. Bush articles. The volume of edits was so high that the queue on those articles were perennially backlogged, and so it was and still is agreed that PC is not suitable for pages that would see high volumes of edits, something which would happen with TFA as a matter of course. —A little blue Bori v^_^v Takes a strong man to deny... 16:43, 2 February 2021 (UTC)[reply]
    At least the TFAs as considered in this discussion. I have seen some fairly quiet TFAs of late. --Izno (talk) 17:17, 2 February 2021 (UTC)[reply]
    Unfortunately I suspect the set of TFAs that would be suitably quiet for PC to work is almost identical to the set of TFAs where PC is not needed. Thryduulf (talk) 01:30, 3 February 2021 (UTC)[reply]
    As a supporter of the proposal, and an active PCR, I don't think this would be insurmountable for most TFAs. I note that the two given examples are highly political topics, one of whom was at the time President of the United States and the other of whom had been less than a full term ago. Vaticidalprophet (talk) 06:04, 3 February 2021 (UTC)[reply]
    I'm against preemptive protection of any kind, especially pending changes which makes more work for volunteers and is rarely useful. — Wug·a·po·des​ 01:53, 3 February 2021 (UTC)[reply]
    • Support some sort of protection it's unacceptable to have editors (very predictably!) vandalizing articles like The Holocaust in Slovakia while they're on the main page. This diminishes our reputation much more than any protection would do. (t · c) buidhe 04:16, 3 February 2021 (UTC)[reply]
    • I should note that "highly active" is a fairly low boundary - PCR starts having real issues well before, say, editors would be frequently edit-conflicting. I'm also not sure how accurate a prediction of a TFA's likely edit rate we can do. Obviously we can predict the "very active" and "not likely to be edited much" buckets, but there'd be a large middle category that is tough to order. As such, I continue to believe PCR remains distinctly problematic for any TFA use that would actually warrant PCR. Nosebagbear (talk) 07:35, 3 February 2021 (UTC)[reply]
    • To be honest, I'm not totally against this. The utility of pending changes is different from semi-protection: the goal is not to reduce the workload for administrators and recent change patrollers (as others have correctly pointed out above, pending changes effectively does the opposite), but rather, to prevent the vandalism from being seen by readers and thus possibly bringing the project into disrepute. As a matter of fact, if my memory serves me right, for a brief period a few years ago, we actually did start preemptively putting PC protection on the TFA after an WP:AN discussion because of a particularly nasty LTA that would replace images on TFAs with extremely shocking ones. The traditional problems with PC on highly edited pages don't seem to be a big concern here because the protection would only last for one day, and most TFAs don't seem to be edited so frequently that large backlogs might become a problem. At the very least, I would probably support a trial period for this idea. Mz7 (talk) 07:53, 3 February 2021 (UTC)[reply]
      Thinking about this a little further, I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA. Pending changes works best on articles where vandalism has a hard time getting reverted quickly, and now that I think about it, because the TFA already has a lot of eyes on it in general, it may be the case that most vandalism is already reverted within seconds, rendering the need for pending changes moot. Mz7 (talk) 08:02, 3 February 2021 (UTC)[reply]
    So far as I can tell, TFA vandalism is rarely if ever reverted within seconds. I've heard averages around 10-15 minutes, which is enough to be problematic for those articles, especially with heavy or grotesque vandalism. Vaticidalprophet (talk) 11:39, 3 February 2021 (UTC)[reply]
    Looking at the edit histories of the articles I mentioned in the opening paragraph (a very small statistical sample): if ClueBot spots it, within seconds; if a human, 1-40 minutes (median 8). Narky Blert (talk) 14:24, 3 February 2021 (UTC)[reply]
    I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA This is the crucial question for me. If our goal is to prevent disruption to the reader, we need to know how much vandalism is currently disrupting readers. I don't think a trial would change our ability to look at that, we just need someone to crunch the numbers from the page history. It could also be crossed with the day's page hits to estimate the number of readers who actually saw the vandalism, e.g., this vandalism was up for 5 minutes, so with a total of 60 thousand page views that day---5 thousand people probably saw this instead of the article. In my experience it's as you describe with the added eyes bringing faster reversions, but knowing the average and other statistics would be useful and quite possibly change my mind. If PC protection really is a substantial benefit, I'd be willing to support its use on TFA. It at least allows users without accounts to edit, and if we craft a nice message as Narky suggests, it could minimize the potential newbie biting. So my main concern in this case is usefulness because I've rarely seen PC solve more problems than it caused. — Wug·a·po·des​ 20:13, 3 February 2021 (UTC)[reply]
    (I guess the maths in your example isn't meant to be taken literally but 5 mins of 60,000 pageviews is about 209 views—5000 would be 60,000 per hour. A limitation of this approach is that vandalism lasts longer the less-viewed the page is, and the pageviews vary based on time zones in areas where most of our readers are from. But I think some API somewhere can give you hourly pageviews.) — Bilorv (talk) 20:43, 4 February 2021 (UTC)[reply]
    • Support pending changes protection as a trial: TFA is different from other highly-viewed pages in that there is very likely a highly active editor who is passionate about the article (the one who just promoted it to FA), and activity is limited to 24 hours (maybe the next few days as well, while it's still linked on the main page). I can't really speak for all such editors (I've only been that person once) but perhaps some would be able to look through all the changes at the very least after the dust has settled, and collect any of the changes which are productive. A counterargument is that TFAs are, well, featured articles, and so much less likely to have issues that new and unregistered users will be able to solve. But there are likely still small prose improvements that one might expect to be made in the TFA period. An alternative is maybe pre-emptively semi-protecting only some TFAs based on topic. — Bilorv (talk) 20:43, 4 February 2021 (UTC)[reply]
    • Support Few useful changes are made, vandalism is a serious problem not for the number of vandals but for the black eye we get for allowing it on the front page. Volume of changes we are talking about is not great. So this is an excellent use of PC. Hawkeye7 (discuss) 04:33, 5 February 2021 (UTC)[reply]
    • Support test, in my view, this is the ideal balance between preserving both the integrity of our "anyone can edit" mantra, and quality of our featured articles. I tend to agree with Hawkeye that "few useful changes are made"—to the point where the amount of vandalism or unhelpful edits vastly outnumbers the occasional random spelling fix (and any major edits/errors would better be discussed on the talk page anyways). But either way, this protection could address both the vandalism and occasionally helpful edits. Aza24 (talk) 09:07, 5 February 2021 (UTC)[reply]
      • Would just like to reaffirm my support; when my Portrait of a Musician went to TFA a couple of days ago, there was a lot of vandalism, almost all of which could have been prevented by PC; the other proses fixes and edits were by users who would not have been restricted by PC. A test is certainly worth it. Aza24 (talk) 23:37, 1 March 2021 (UTC)[reply]
    • (nom) I agree that any change should be on a trial basis.
    My idea for the template text is along the lines of: "Welcome to Today's featured article. It is an unfortunate fact that these articles attract vandals. Therefore, changes by new editors are reviewed by experienced editors before they show up for everyone to see. This usually takes only a few minutes. If you are here to be part of the community whose goal is to improve Wikipedia - Thank you, and happy editing! You might find Help:Editing a useful beginners' guide. If you are here only to disrupt - Be off with you!" Narky Blert (talk) 18:04, 5 February 2021 (UTC)[reply]
    • Support Would prevent instant publication of toxic or copyrighted material on such highly visited articles. ~ HAL333 02:58, 6 February 2021 (UTC)[reply]
    • Upon notice I haven't explicitly said it here yet, support as one of the parties in the original conversation. Vaticidalprophet (talk) 13:53, 6 February 2021 (UTC)[reply]
    • Oppose. PC protection generates significant amount of work for minimal benefit, and doesn't work on pages with a high volume of editing; those pages which attract enough vandalism to make protection worthwhile, are also going to be those pages on which PC won't work. PC also comes with significant additional drawbacks in addition to the maintenance backlog it generates; there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary; for BLP issues PC has little impact since it doesn't affect what Google scrapes (they pick up the most recent revision even if it's been unapproved); to approve/disapprove changes to an article at FA level often requires specialist knowledge of the topic, which the handful of people who work the Special:PendingChanges queue are unlikely to have; the whole proposal appears to be predicated on the idea that every, or at least most, FAs are going to be on peoples' watchlists, which just isn't the case. ‑ Iridescent 08:00, 7 February 2021 (UTC)[reply]
    (Interesting to see you here -- I was literally just wondering what you would think of the proposition.) For what it's worth, "there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary" is incorrect -- the edit summary box is...huh, PC queue is empty as we speak, so my plan to take a screenshot for "right here" will have to wait, but it's prominently placed complete with giant "ADD AN EDIT SUMMARY IF WHAT YOU'RE REVERTING ISN'T BLATANT VANDALISM" bold text. Vaticidalprophet (talk) 06:37, 8 February 2021 (UTC)[reply]
    In lieu of screenshotting the edit summary box itself, here's a screenshot from my recent PCR contributions showing them. Vaticidalprophet (talk) 06:42, 8 February 2021 (UTC)[reply]
    It's alarming as a standalone thing to learn that Google is scraping the most recent revision on PCP pages—albeit I understood it to have a bit of a delay for general vandalism reasons (possibly it's just that it takes a few minutes for Google to scrape the article again). However, this is Google's problem, not ours. I don't want them having a single say in any of our decisions in any way. They need to change to suit us, not the other way around. Other search engines are available. — Bilorv (talk) 00:56, 13 February 2021 (UTC)[reply]
    In around 2014, I was told that Google scraped a well-known social website every 20 minutes. Our goal as volunteer moderators was to take down heavy commercial spam within that time. IDK if that's a typical number, but our leader tried and failed to get them to increase it to 30. Narky Blert (talk) 06:05, 13 February 2021 (UTC)[reply]
    • Support The only backlog this would generate in terms of PC is one page which would need to be checked regularly for the duration (and, well, PC isn't that large of a backlog, compared to some other places). And, well, while it might not stop everything, at least any vandalistic edit (which would need to be reverted anyway, PC or not) won't be prominently displayed to every person who gets there... RandomCanadian (talk / contribs) 01:21, 12 February 2021 (UTC)[reply]
    • Support as a pending-changes reviewer, I think the added workload would be minimal compared to the benefits. With the number of eyes on the page, good changes will be accepted quickly, while bad ones won't be prominently linked from the main page. Elliot321 (talk | contribs) 05:57, 14 February 2021 (UTC)[reply]
    • Support - This strikes me as a reasonable compromise that both allows IPs to edit TFAs and combats vandalism. Put another way, it's the least restrictive means of effectively protecting our most prominent articles. (Protecting one article a day certainly won't overwhelm PC, and the article will be widely watchlisted anyway.) Let's at least give this scheme a try: I think it would be effective. Extraordinary Writ (talk) 07:18, 14 February 2021 (UTC)[reply]
    • (nom) To repeat a point I made earlier, in case it might get lost. This idea has both carrot and stick. It would provide a means to speedily welcome new editors and to point them in the right directions. Experienced editors know where to look or to ask for help; newbies, by definition, don't. Narky Blert (talk) 07:50, 14 February 2021 (UTC)[reply]
    • Support. This is about balancing Wikipedia's positive reputation as the encyclopedia 'anyone can edit', agains the potential negative reputation for vandalism and inaccuracies being introduced and not being caught. I think pending-changes protection is an excellent compromise, allowing people to edit, but preventing stupid nonsense from showing up on our most prominent article of the day. ƒirefly ( t · c ) 14:02, 14 February 2021 (UTC)[reply]
      • Changing to strong oppose after learning that FlaggedRevs (i.e. the module behind pending changes) is effectively abandoned, with nobody on the MediaWiki dev team having responsibility for it, and that it has various odd bugs (phab:T275322, phab:T275017) that seemingly aren't getting resolved. The last thing we want is weird MediaWiki bugs on display on TFA. ƒirefly ( t · c ) 09:42, 2 March 2021 (UTC)[reply]
    • Support as trial. I agree with RandomCanadian, a short period of time having pending changes protection isn't going to create much of a backlog and with so many eyes on TFA already.
      I've been wondering though (which is also why I'm voting here, for the first time at Village Pump), where would one go to suggest an entirely-new protection type? Because what if, instead of putting pending changes on TFA, there was instead a "delayed changes" protection? It would basically be pending changes, but with automatic approval after some set amount of time. Set the time to something a bit longer than the average length it's taken for vandalism to be reverted, and I'd bet it would drastically reduce the workload on heavy-vandalism days without contributing to a pending changes backlog. This would be protection for just TFA (a case of a page with high visibility/traffic for a short period of time). But since this would need to be created and isn't a matter of assigning an existing protection, it's more of a future-implementation kind of suggestion. --Pinchme123 (talk) 01:27, 18 February 2021 (UTC)[reply]
      @Pinchme123: Feature requests should be submitted at Phabricator. --Redrose64 🌹 (talk) 14:26, 18 February 2021 (UTC)[reply]
    @Redrose64: Thank you for pointing me to Phabricator, as I did not know about it beforehand. But my question isn't about "submitting" for a feature request, but suggesting one, to be discussed before requesting it. I see little point in requesting a brand-spankin' new feature without having a discussion about its merits, especially when feature requests appear to be made outside of WP (since Phabulator is merely an affiliated Wikimedia entity, and I had to create a new account just to see the feature request creation page). So where might I go to suggest the feature, for discussion? --Pinchme123 (talk) 16:16, 18 February 2021 (UTC)[reply]
    • Oppose, per Iridescent, and also because of the general principle of using TFA to highlight the "anyone can edit" principle. Editing with a delay is not the same thing as editing with an immediate impact, and using PC on such a prominent page would harm recruitment. --Yair rand (talk) 06:25, 18 February 2021 (UTC)[reply]
    • Comment. I'm in the knee-jerk oppose camp per Iridescent & Yair rand, but I can see the problem of adapting our processes as we evolve from "the encyclopedia that anyone can edit" to "the encyclopedia that anyone can edit". If we want to use the TFA for recruitment then the edit must be visible (almost) immediately; more than 30s would, I think, take away that little burst of joy that addicted me to editing here. I believe one of the major problems that Wikipedia faces as it matures is erosion of the editor base as it becomes harder and harder to get a foot in the door as a new editor. Is there any evidence that newbies take up editing via the TFA? I've seen multiple new editors converted via ITN, but rarely other sections of the main page. My DYKs have occasionally had substantive or typo-fixing edits by redlinks or IPs who are clearly interested in the topic, and I've even very occasionally had comments of thanks or opprobrium from IPs. Personally I hate pending changes and hardly ever accept significant revisions because it puts the onus on me to put my weight behind them, and I know others have the same problem. Is there some bot-mediated mechanism that could immediately auto-accept anything that looked good faith and not obviously problematic? Could Cluebot be set to run on every TFA edit immediately? Espresso Addict (talk) 12:19, 18 February 2021 (UTC)[reply]
    • Strongly support trying something after seeing today's TFA, Margaret (singer), be ceaselessly vandalized, spawning yet another ANI thread. I think the work combatting vandalism at TFAs is greater than the work involved in protecting the article, and the detriment from vandalism at TFAs is greater than the detriment of not allowing everyone to instantly edit it. I'm not sure if it's PC or semi or something else, but Something Must Be Done™. I'd support a trial of this or any type of protection. Or even a trial of both PC and semi, like an A/B test. What I strongly oppose is resigning ourselves to "well that's just how it is" and trying nothing. Strongly oppose trying nothing. Levivich harass/hound 22:44, 23 February 2021 (UTC)[reply]
    • Support As it's a featured article, the cost-benefit calculation here is very different than most. Newcomers vandalize many articles but also make good edits to make up for that. For featured articles, the likelihood of a newcomer making a good, constructive edit is greatly reduced (based on low potential for improvement of the article as a featured one), while the fact that it is on the front page means that the amount of vandalism increases substantially. Personally, I support pending changes protection on all featured articles because of the diminished benefit a newcomer editing them can bring. Plenty of featured articles have significantly declined in quality over time as for a pretty much completed article it is much more likely for any edit by newcomers to be unhelpful. I think people are overestimating that satisfaction people get to see their change immediately; as long as they are aware of the pending changes situation, what matters most is the fact that your work is published at all, not the exact time. Zoozaz1 talk 22:00, 24 February 2021 (UTC)[reply]
    • Support Most recent TFAs follow a pattern similar to Oryzomys gorgasi, the TFA on 26 February. There were 62 edits on that day. Of those, 27 (roughly 44%) were from IP addresses. With one exception that I saw, all were vandalism. The ‘legitimate’ edits were almost all from established users, and most of those edits involved repairing the damage caused by vandals. The 'anyone-can-edit' principle is, at least from my perspective, the means and should be subordinate to the end of creating an encyclopedia by drawing upon collective knowledge.Venicescapes (talk) 08:07, 28 February 2021 (UTC)[reply]
    • Support; generally works fine on dewiki on highly-viewed pages. All articles are PC-protected on dewiki, leading to a long backlog,(7500 pending changes) but this doesn't seem to be a concern when the protection is limited to 24 hours and done selectively on pages that are very likely to be reviewed. ~ ToBeFree (talk) 19:52, 1 March 2021 (UTC)[reply]
    • Support per proposal; yes anyone should be able to edit, which they will be in this proposal, but Wikipedia should not once again fall victim to being called the website with inaccuracies anyone can add. waddie96 ★ (talk) 20:44, 1 March 2021 (UTC)[reply]
    • Support I seem to remember suggesting this a few years ago in one of the periodic conversations about semi-protecting TFA. It would prevent vandalism from being shown live while still allowing IP editing. It can get complicated with many edits, but it's worth a trial at any rate. ~ ONUnicorn(Talk|Contribs)problem solving 20:57, 1 March 2021 (UTC)[reply]
    • I don't like protection much, and I loathe pending changes. But perhaps it is time to move away from TFA as our poster child for "anyone can edit" and look for other ways to draw new editors in (TFA really isn't the best place for editing tests). I'd prefer semi to PC, but I won't oppose the proposal. —Kusma (t·c) 21:25, 1 March 2021 (UTC)[reply]
    • Support. Prefer semi over PC. My first concern is with the reader, THEN the editor. Dennis Brown - 2¢ 22:26, 1 March 2021 (UTC)[reply]
    • Support because it will best serve readers. TFA gets a lot of traffic, and it's a disservice to readers if they encounter the article while vandalism is visible. Schazjmd (talk) 22:34, 1 March 2021 (UTC)[reply]
    • Begrudging support I think PC is bad, broken, and not hardly useful. I think semi is superior in effectively all cases. However, since we have decided against semi protection for FA's for years, I will settle with PC. I think it is ludicrous that we don't want to use semi on FA's. We have become stuck in a rules trap. It is written that protection should only be used after disruption is happening, so we wait until we see disruption. But we now hew to the letter of the law, not the spirit! The spirit is to prevent disruption. Sure, for most articles, we can't know when disruption will occur. But featured articles get vandalized like clockwork. Suddenly showing a page to 10 million extra people a day (including our LTAs!) makes it almost certain to get vandalized. A little dash of WP:IAR would save a great deal of time and frustration. TLDR: semi-protection would be superior, but I will settle for PC. CaptainEek Edits Ho Cap'n!⚓ 22:55, 1 March 2021 (UTC)[reply]
    • Comment and Oppose. The ability to instant create edits lies at the heart of this project. And I think many editor's very first foray into Wikipedia is through attempts at a main edit. It's our welcome mat. Seeing your change live instantly provides a thrill and confirms to newcomers instantly that their suspicions of how things work ("anybody can edit") were valid. Yes, this includes lots of immature vandal edits. But those tends to be stupid things like profanity inserted very visibly. But even this helps prompt good new edits to try to fix that. In other words, the "wild west" nature of the front page is an important way to engage new users which we need. And even some of the vandals turn into good editors as they mature. Using PC makes your first edits boring and people tend not to stick around for boring things. Jason Quinn (talk) 02:22, 2 March 2021 (UTC)[reply]
    • Oppose using PC for TFA, but support just about any other form of protection (semi, extended confirmed, etc). IMO, Pending Changes is an abomination that shouldn't be used at all, on any article, ever. It increases the amount of work needlessly and makes editors responsible for someone else' edits. It is also extremely confusing and difficult to understand as a feature, which for prospective TFA use makes it unacceptable. TFA will be viewed and edited by many inexperienced editors. We should not confuse the hell out of them with a monstrosity like Pending Changes. Just semi-protect TFA instead. Nsk92 (talk) 02:47, 2 March 2021 (UTC)[reply]
    • Oppose. It looks as if the wind is blowing strongly in one direction on this one, but my take is that this seems like an overkill solution in search of a problem--which proposed problem I think is substantially minimal by the very nature of the context. If TFAs somewhat gain additional traffice from IPs and neophyte editors, they are also gain increased scrutiny from a broad chunk of the community over the same 24 hour period that they are up on the main page. Additionally, these articles tend to be slightly more robust and reflective of engaged editing than the average article. In short, I can't see that adding pending changes will make all that substantial a difference to protecting the article against erroneous, bad-faith, or otherwise problematic edits over the course of its day of featured status. Meanwhile, it seems absolutely certain to have an impact on what has traditionally been one of the Featured Article's perceived benefits: editor recruitment.
    In fact, I would argue that having this process by which new editors are corralled into a different article each day (which article represents decent editorial standards) and that space becoming the first place in which they can appreciate the pleasure of contributing to the encyclopedia and enjoying the immediate feeling of seeing those changes go live, while simultaneously focusing community oversight on that article space in an organic fashion all sounds like precisely the balance we want to establish and why this is a "it's not broke, don't fix it" type of situation. Additionally, TFAs frequently benefit from the super-crowd-sourcing feature of the attention they get: the vast majority of even IP edits are beneficial, not deleterious, so why gum up the works by having a queue of (potentially overlapping) pending edits. And those queues don't always get addressed with alacrity: I'm a pending changes reviewer myself and have logged a fair amount of work in the area over recent years, and I can tell you that the queue being addressed is quite a variable thing with regard to both the subject matter of the article and the time of day. Lastly, this is just not the typical scenario (a n inherently problematic article) in which this form of protection is typically seen as most justified.
    In short, and with respect to the proposers and supporters above, the cost-benefit analysis runs strongly counter to the proposal, as I see it. Snow let's rap 04:28, 2 March 2021 (UTC)[reply]
    It's equally likely that a new editor attempting to edit a well established article (the TFA) will mess something up and get a notice or worse a stern scary looking warning on the their talk page. This also ignores that PC still allows the new editors to edit the article, while conveniently removing the incentive for at least some vandalism/LTAs. Ex. (had to dig for it a bit): TFA from May last year - the revdel'd edits are a well known LTA vandal (the same as for most of the articles on Wikipedia:Today's featured article/May 2020... - I know, this discussion is not a new idea); after the PC protection the LTA stopped, while still allowing other non-AC edits (a fair bit were common vandalism, some were good faith but misguided; but anyway PC does not create the same issues as semi-protecting would). While PC might not be effective on some articles, or maybe even on most, on the TFA it would probably be the best of both worlds: not showing vandalism to our readers, while still allowing new editors to intervene. Cheers, RandomCanadian (talk / contribs) 05:06, 2 March 2021 (UTC)[reply]
    • Support. Using PC on TFA is not actually a new idea. Myself and other admins have preemptively applied it many times to guard against long-term abuse, or in reaction to vandalism. These were emergency situations that necessitated stepping outside policy and lack of consensus, but each time to my knowledge we didn't see any of the problems others frequently cite when questing use of PC on TFA. Specifically, there are enough eyes and activity on this article that it doesn't have much detriment on the backlog. Shielding one of the most visible articles from defacement, while still allowing new users to contribute, is a win-win and frankly long overdue. — MusikAnimal talk 02:09, 3 March 2021 (UTC)[reply]

    Pending changes bugs

    (Moving discussion out of archive.) Unfortunately, there are a ton of bugs affecting pending changes right now: autoconfirmed users having their edits held back for review erroneously, administrators not being able to set pending changes protection, and apparently the pending changes codebase is completely abandoned (no active developers who understand the code). See also the discussion at Wikipedia:Village pump (technical)#Pending Changes again. I wrote a comment in the discussion above expressing some support for this idea, but if we can't ensure the software reliability of pending changes, I'm afraid I'm now quite hesitant to support expanding it. Mz7 (talk) 20:06, 12 March 2021 (UTC)[reply]

    As one of the more active PCRs and one of the original formulators of the proposal, I've been following the PC bug discourse with some interest. I haven't actually observed a ton of it in my work, so I wonder quite how big the problem is -- that is, what proportion of people who get false-positived go complain somewhere. (It's not just on VPs, I've seen it come up a few times at PERM.) If the majority of people who get it bring it up, it's pretty small; if this is just the tip of the iceberg, it might be a serious issue.
    In terms of the proposal -- the thing that stands out to me is most of the oppose votes are saying "We shouldn't do this, we should semiprotect instead", not "We shouldn't do this, TFA should be status quo". I wonder how the vote distributions would stand out for the following two proposals:
    "TFA goes under either pending changes or no protection, only two options, semiprotection is completely off the table and will never happen"
    "TFA either goes under semi, PC, or none; rank the options by preference"
    It'd be an interesting RfC either way. Vaticidalprophet (talk) 03:11, 13 March 2021 (UTC)[reply]
    I go through PC occasionally (when I'm not otherwise busy) and I don't encounter the bug too often (non-improvements and vandalism are, alas, more frequent), or when I do it's usually not too much of a hassle to just accept the change - if I have a particularly large amount of spare time I'll leave a notice about this to the affected editor. The fact that the code is unmaintained and apparently some form of a mess isn't a good sign, however, and well we'd have to weight whether the risk of further issues developping is less of an annoyance than potentially doing something about TFA LTAs... Cheers, RandomCanadian (talk / contribs) 05:42, 13 March 2021 (UTC)[reply]
    Update: I'm aware there's now a BRFA intended to address this issue. If that goes through, then I think I'll withdraw my hesitation. Mz7 (talk) 19:06, 15 March 2021 (UTC)[reply]
    I think hotfixes via a bot are untenable long-term. As more and more bugs crop up that can't be fixed in the extension, we can't keep using bots and other hacks to get around them locally. I'd personally like to see FlaggedRevs get picked up in the code stewardship review before expanding its use. ProcrastinatingReader (talk) 23:26, 15 March 2021 (UTC)[reply]
    As the botop who filed that BRFA, I entirely agree that patching the issue via bot is not ideal, and I would also oppose any expansion of PCP until the issues are resolved. ƒirefly ( t · c ) 09:42, 3 April 2021 (UTC)[reply]
    • Why don't we scrap pending changes reviewer? and grant the rights to extended-confirmed? I mean, the point of PC is a basic flag to stop vandalism/obvious DE, right? It's akin to a less extreme semi-protection. So it doesn't really make sense, imo, to put it to a separate right. The right should be bundled into extendedconfirmed and the separate right removed I think (+ EC is a reasonable level of 'trust' against pure nonsense vandalism + they can already edit areas like Israel-Palestine). That would also fix this particular bug. ProcrastinatingReader (talk) 17:17, 16 March 2021 (UTC)[reply]
      ProcrastinatingReader, honestly I'm not opposed. Back in 2018 I floated this idea on the idea lab village pump, and there was some mixed reception, and my interest in pursuing the change kind of just fizzled out. (Looking back I really wrote too much, heh. Concision was not/is not my strong suit.) Mz7 (talk) 19:42, 21 March 2021 (UTC)[reply]
      @Mz7: afaics there's two main objections there:
      1. That people would get a permission enabled without knowing what it does / directly asking for it. But this is true with autoconfirmed too: you get a bunch of buttons automatically and probably won't use many of them. And for adminship, too. You don't need to use a button just because you have access to it.
      2. That editors would game the system / increase edit count to gain it. I don't think this is true for a few reasons. 1) same could be said about the 'privilege' to edit in ARBPIA. 2) same could be said for pages currently autoconfirmed/ECP protected (gaming edits up means that you can now accept {{edit protected}} requests onto the page, and PCR is practically equivalent to {{edit protected}} except that it's directly supported by the software interface).
      So neither objection really makes sense imo. ProcrastinatingReader (talk) 19:55, 21 March 2021 (UTC)[reply]
      While we're at it why not scrap pending changes altogether? Is there any reason other than sunken costs to keep it, rather than use other forms of protection? I've often noticed that experiments on Wikipedia are hardly ever deemed to be failed, often because people are following that fallacy. Phil Bridger (talk) 19:53, 21 March 2021 (UTC)[reply]
      The main advantage of Pending Changes from my point of view, is that it acts as a form of protection against vandalism on pages without blocking their ability of IP's to actually edit. Asartea Talk | Contribs 07:54, 25 March 2021 (UTC)[reply]

    Trial duration

    There is substantial support for a trial (which would demonstrate any technical problems with pending changes), but no discussion on the length of a trial. I think 1 month is a good duration for a trial. User:力 (power~enwiki, π, ν) 02:30, 6 April 2021 (UTC)[reply]

    Fuck that. That that page even exists should tell you all you need to know. —A little blue Bori v^_^v Takes a strong man to deny... 02:34, 6 April 2021 (UTC)[reply]
    I'm aware there are problems with Pending Changes, if you oppose using it for TFA you should be voting in the voting section. I'm not sure what a ten-year-old RFC against pending changes (when later RFCs allowed it) is supposed to tell me; the fact that an RFC existed ten years ago tells me virtually nothing.. User:力 (power~enwiki, π, ν) 02:40, 6 April 2021 (UTC)[reply]
    That RfC took place long after the original trial of PC was supposed to end. —A little blue Bori v^_^v Takes a strong man to deny... 02:45, 6 April 2021 (UTC)[reply]

    RFC: Should certain succession box content be deleted?

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
    (non-admin closure) There is consensus not to have "Oldest-living British prime minister" as a succession box due to its trivial nature. There is no consensus on anything else. User:力 (power~enwiki, π, ν) 19:21, 2 April 2021 (UTC) There is a clear sense that "trivial" succession boxes should be removed, but no consensus as to what makes a succession box trivial (apart from on the specific example mentioned in the RFC statement). There is no consensus on how or where discussions to remove succession boxes should proceed; the status quo is that either this page or a WikiProject could host an RFC. There is no consensus on whether succession boxes in general should be re-worked or removed completely. User:力 (power~enwiki, π, ν) 19:21, 2 April 2021 (UTC)[reply]


    Should we delete succession box content such as the following? Examples: "Oldest-living British prime minister". What say all of you? GoodDay (talk) 21:57, 4 February 2021 (UTC)[reply]

    Survey (succession boxes)

    • Yes. We ought not to have any of that trivia in succession boxes. There are often many boxes, dozens even, and additional clutter is unhelpful. One would be very hard-pressed to find reliable sources discussing how James Callaghan "succeeded" Alex Douglas-Home as the oldest British prime minister, and I dare say that no biography of either of them mentions it. Surtsicna (talk) 22:15, 4 February 2021 (UTC)[reply]
    • Yes. Only posts with transitions (or successions) would need succession boxes. -- Kautilya3 (talk) 22:56, 4 February 2021 (UTC)[reply]
    • Not here. Trivia should be deleted, non-trivia should not be. Whether any specific succession is or is not trivia needs discussing individually at an appropriate forum - that forum is very much not here. Thryduulf (talk) 02:21, 5 February 2021 (UTC)[reply]
    • No As Thryduulf says trivial ones should be, non-trivial ones should not be. That needs to be done on a case by case basis. -DJSasso (talk) 18:03, 5 February 2021 (UTC)[reply]
    • Yes I find succession boxes unnecessary in general since they usually duplicate the infobox, a navbox, and/or the text. When it's not duplicative like this example, it's often trivial that doesn't need a box to itself. Reywas92Talk 19:36, 5 February 2021 (UTC)[reply]
      • You dislike them, whereas I find the clear, consistent presentation extremely useful. Succession boxes, infoboxes, navboxes and prose all serve different functions and so the same link appearing in more than one place is a Good Thing. Some succession boxes should be removed, but most should not be. Which is the case for any given succession box can only be determined by a consensus discussion about the succession box in question. Thryduulf (talk) 01:04, 6 February 2021 (UTC)[reply]
    • Yes and would support getting rid of them all. Redundant and pointless clutter. Why not have separate boxes for marriages, spouses, and works dispersed througout the article while we're at it? ~ HAL333 02:50, 6 February 2021 (UTC)[reply]
      • What are they redundant to? Links in prose and links in succession boxes have different purposes so they are not redundant to each other. Boxes (for anything) scattered throughout the prose would be completely disruptive to the prose, which is why succession boxes are not placed in the middle of the prose? Thryduulf (talk) 11:58, 6 February 2021 (UTC)[reply]
    • Yes - Not sure we even need them for positions, but definitely not for superlatives. Levivich harass/hound 17:22, 6 February 2021 (UTC)[reply]
      • All superlatives? What about tallest buildings and longest bridges? Those seem extremely useful succession boxes to me. Thryduulf (talk) 18:24, 6 February 2021 (UTC)[reply]
    • Comment: I feel the validity or triviality of succession boxes should be discussed on a case by case basis on their respective talk page. Not sure what a global decision one way or another on "trivial" succession boxes could achieve, when it does nothing to establish what is trivial and what is not. PraiseVivec (talk) 14:01, 7 February 2021 (UTC)[reply]
    • Yes for purely trivia succession box such as "oldest living X" - unless said role is notable in its own right (not sure if this actually applies anywhere). Elliot321 (talk | contribs) 05:54, 14 February 2021 (UTC)[reply]
    • Yes certain ones should be deleted. At a minimum, the spirit of WP:NAVBOX #4 seems applicable: There should be a Wikipedia article on the subject of the succession box.—Bagumba (talk) 10:11, 22 February 2021 (UTC)[reply]
    • Depends - Yes for "Oldest-living British prime minister" "successions" as trivia, but without a discussion on others is will depend on the case, this should not be used as consensus to delete non-cited examples. KylieTastic (talk) 10:15, 23 February 2021 (UTC)[reply]
    • Yes Succession boxes are not needed, in most cases it's a duplicate.Sea Ane (talk) 21:43, 26 February 2021 (UTC)[reply]
    • Oppose deciding this specific one here, support a general rethink of succession/navboxes and what they are good for (if anything). Most of the succession boxes at John Major are less trivial, but there are so many of them that they are not a useful way to navigate anything, and are hidden away by default (just like the ungodly amount of navboxes). Once an article has more than three succession boxes, they tend to stop being useful. —Kusma (t·c) 21:50, 1 March 2021 (UTC)[reply]
    • Yes - A lot of succession boxes seem to be pure trivia. If there isn't an article for the topic it shouldn't exist as a succession box. Nosferattus (talk) 04:05, 9 March 2021 (UTC)[reply]
    • ? Oppose Confused, how can this RFC decide anything? The RFC is vague and the answers equally ambiguous; everyone saying "Yes" is supporting something different. Who decides which ones are trivial? Aza24 (talk) 23:34, 15 March 2021 (UTC)[reply]
    • Yes, some succession box material should be eliminated, In the example given, Oldest-living Prime Minister is treated like being an athletic record holder, a recognized and lauded accomplishment as opposed to the simple inconsequential happenstance that it is. You might as well have 'Tallest living Prime Minister'. 'Poorest living Prime Minister', or 'Living Prime Minister with the smallest left testicle'. Agricolae (talk) 19:09, 2 April 2021 (UTC)[reply]

    Discussion (succession boxes)

    • Why? Ivanvector's squirrel (trees/nuts) 22:17, 4 February 2021 (UTC)[reply]
      Because, those are not political or party offices. They're merely trivial. GoodDay (talk) 22:19, 4 February 2021 (UTC)[reply]
      Why do we need a global policy or guideline or anything about this? If you think a given succession box is trivia, discuss that specific succession box somewhere (talk page, WikiProject, TfD, there are plenty of venues). I genuinely don't understand what you are trying to achieve here - there is no chance that there will be a consensus that we should have succession boxes for everything (10th place qualifier in a British Touring Car Championship race as an unquestionable example), but with the wording of the discussion you cannot get consensus (for or against) regarding any individual example. Thryduulf (talk) 02:18, 5 February 2021 (UTC)[reply]
      You expect there to be a separate discussion on each individual bio article? Anyways, I don't exactly know what you're posting about. GoodDay (talk) 17:29, 5 February 2021 (UTC)[reply]
      I expect you to get consensus for each individual succession. That could be on an article talk page or a centralised discussion. e.g. if you want to get rid of oldest living British Prime Minister, you need to have a discussion specifically about removing the "oldest living British Prime Minister" succession box from every article it appears on, with notifications to (at least) the talk page of all the affected articles. In other words you need to do exactly the same as you would for any other bulk change. Thryduulf (talk) 22:26, 5 February 2021 (UTC)[reply]
      That's too time consuming. There's too many 'useless' topics in these succession boxes, to go through one-by-one. GoodDay (talk) 22:30, 5 February 2021 (UTC)[reply]
      A centralised discussion about the succ boxes for oldest living British Prime Minister could be held at Wikipedia talk:WikiProject Politics of the United Kingdom. --Redrose64 🌹 (talk) 23:40, 5 February 2021 (UTC)[reply]
      But the British prime ministers example, is just one example of these trivial topics in suc-boxes. GoodDay (talk) 23:41, 5 February 2021 (UTC)[reply]
      The issue is that we have no idea what other succession boxes you regard as trivial so we (and most importantly editors of the articles they appear on) have no way of knowing whether we agree or disagree. While oldest living British Prime Minister doesn't seem very useful, others such as Prime Minister of the United Kingdom is very much not trivial, where to draw the line between them needs to be determined by consensus. Thryduulf (talk) 00:59, 6 February 2021 (UTC)[reply]
      Subjects like "Tallest President of country", "Fattest Prime Minister of country", "Oldest Stock Car racer", "Youngest 100 meter dasher", would be trivial topics for suc-boxes. GoodDay (talk) 02:18, 6 February 2021 (UTC)[reply]
      The first two undoubtedly would be trivial, the latter two maybe - it would depend if there was any significance given to this in reliable sources. However a short list of topics (which a cursory search suggests are not in use) that you consider trivial do not go any way towards addressing the issue in my comment. Thryduulf (talk) 18:20, 6 February 2021 (UTC)[reply]
      I don't know what your complaint is. Perhaps if you would put down examples of suc-box topics that you believe should & shouldn't be deleted, would help. GoodDay (talk) 18:26, 6 February 2021 (UTC)[reply]
      My point is that they need to be discussed individually or in small, closely related groups (e.g. perhaps succession boxes related to British Prime Ministers). No matter how many examples are listed here you cannot get consensus for anything not listed here, and the more examples you list here the greater the liklihood of a trainwreck. Thryduulf (talk) 00:10, 7 February 2021 (UTC)[reply]
      RFC is already in full swing. We'll see how it ends up. GoodDay (talk) 00:47, 7 February 2021 (UTC)[reply]
      Consensus that some but not all succession boxes should be removed, but no consensus for the removal of any one in particular - that will need further discussion. It's pretty much the only way it can end. Thryduulf (talk) 02:20, 7 February 2021 (UTC)[reply]
      Besides, I find Wiki-Projects tend to garner less attention. Was considering moving another RFC to Village Pump, for the same reason. GoodDay (talk) 23:55, 5 February 2021 (UTC)[reply]
      Your subjective opinion that something is "Too time consuming" does not grant you the right to ignore WP:CONSENSUS. If you propose a course of action on a WikiProject and advertise the discussion to the relevant talk pages but nobody opines after a reasonable time (~week) then you can go ahead and remove the succession boxes listed in the discussion. Thryduulf (talk) 00:59, 6 February 2021 (UTC)[reply]
      If you want to advertise this RFC on the related WikiProjects? then by all means, do so. GoodDay (talk) 02:18, 6 February 2021 (UTC)[reply]
      If this discussion was actually about specific succession boxes that would be appropriate, but as the discussion is actually a vaugie and unfocused attempt to get rid of an unspecified list of succession boxes you (or presumably any other editor) personally dislikes then it is impossible to know which projects and articles are relevant. On the other hand, if you did deign to list those boxes you deem trivia, then it would I suspect rapidly become a trainwreck due to the large number of disparate boxes editors will have different opinions about. Thryduulf (talk) 11:55, 6 February 2021 (UTC)[reply]
      Since my concerns grew out of the discussion at James Callaghan, one would link to Political WikiProjects. GoodDay (talk) 18:41, 6 February 2021 (UTC)[reply]
    All should be delete as links spam due to duplication of links and undue because of overwhelming size. Never understood why we have giant boxes with very few links in them overwhelming the sections. It's definitely a point of contention for content editor that these undue boxes are spamed automatically without consideration of over linking or unwarranted linking.--Moxy 🍁 00:04, 6 February 2021 (UTC)[reply]
    Very simply because many (not all) of the succession boxes are very useful for readers. Thryduulf (talk) 00:59, 6 February 2021 (UTC)[reply]
    Not sure how duplication of lnks and overwhelm sections is good for readers. We have protocols for these 2 points....just ignored by template spammers.— Preceding unsigned comment added by Moxy (talk • contribs) 01:19, 6 February 2021 (UTC)[reply]
    See my reply in the section above for why duplication is not a problem, and I disagree that the presentation is overwhelming. That some succession boxes are trivia does not mean every succession box is spam. Thryduulf (talk) 01:41, 6 February 2021 (UTC)[reply]
    We will simply have to disagree. By placement practice alone indicates there very low value to the community. See also links dumped at the bottom of articles because they duplicate existing links and the format is not responsible anywhere else in the articles. It's horrible that these boxes are more prominent than the actual topic-specific navigation boxes. Odd they were not omitted from mobile view as load junk.--Moxy 🍁 02:01, 6 February 2021 (UTC)[reply]
    How does placement indicate they are low value? Of course the format is not appropriate anywhere else in the article - see also links and links in succession boxes have a completely different purpose to links in the prose. You need to explain why the duplication is problematic. Thryduulf (talk) 11:55, 6 February 2021 (UTC)[reply]
    It's why we have a guideline on this..... distracts readers from the links that are actually important Wikipedia:Overlink crisis. They are so overwhelming that editors hide them in collapsible templates Abraham Lincoln#External links. In many other cases the amount of them is simply overwhelming...mass link spam John A. Macdonald#External links.--Moxy 🍁 17:59, 6 February 2021 (UTC)[reply]
    You've explained why you think having too many boxes is an issue, and reiterated your opinion that some boxes are low value (which basically nobody is disagreeing with). However you have not explained why having any boxes is problematic or why their position in the article indicates this. Thryduulf (talk) 20:24, 7 March 2021 (UTC)[reply]
    As I said in my oppose above, who ever closes this is going to find themselves in an impossible situation. There is no uniformity in any of the "Yes" comments. Additionally what does "certain succession box content" even mean?—who decides which ones are being discussed? Aza24 (talk) 23:08, 24 March 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    RFC: Citation Style 1 parameter naming convention

    MIXED

    Previous discussions

    Summary

    This is basically Option B with extra caveats.

    The following discussion is an archived record of a request for comment. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    To be honest, I wasn't sure how this was going to go. I decided that it was best for me to sit this discussion out just to see how things turned out. There are a lot of moving parts to this conversation, so I am going to break it down as easily as I can.

    For the most part, this is an Option B close with some severe caveats.

    Discouraged

    The first major aspect of this discussion was whether or not non-hyphenated parameters are still deprecated for the CS1/2 family of templates. Consensus can change, and the RFC establishing deprecation happened more than five years ago.

    On Wikipedia, "Deprecated" has come to mean something is basically disallowed for the future. If a template parameter is deprecated, it generally means it is onset to be phased out entirely and support for it replaced with an error message. Compare this process to what's outlined in Wikipedia:Deprecated sources.

    Therefore, are non-hyphenated parameters deprecated? From what I can tell, the answer is no in the following cases: |accessdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= (also like |author1link= etc. and whatever). These parameters fall into a state I think most could easily call developer discouraged.

    As such, these parameters should not be advertised in documentation, hidden maintenance categories added (and etc.) while still remaining available for use by long time editors. The five or so grandfathered parameters should only ever turned off following a later discussion which receives wide attention and clear consensus. In the meantime, any editor should feel free to manually change unhyphenated parameters into their hyphenated forms while they're doing something else on a page (like so).

    Monkbot 18

    As I said, this is basically an Option B close with extra steps. Therefore, the Monkbot 18 should not be run solely to replace the discouraged non-hyphenated parameters. Whether it could be run on pages to replace the remaining deprecated templates I do not see a consensus for either way (ie. no consensus).

    The issue of watchlist clogging was widely discussed. With so many objections to execution of the "hyphenate cs1|2 parameter names" section of Monkbot 18, it's hard to say there is consensus to enact it except if it was bundled with non-cosmetic changes or occurred on a CBD.

    I also don't know what to say about the rest of Monkbot 18 since it wasn't discussed.

    That's really all there is for me to say on the matter. If there are any questions about this close, please refer them to either my talk page, Help talk:Citation Style 1, or some other appropriate venue. –MJL ‐Talk‐☖ 21:03, 5 April 2021 (UTC)[reply]

    Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? Primefac (talk) 02:14, 10 February 2021 (UTC)[reply]

    Background (CS1)

    In 2014 an RFC determined that all parameter names in Citation Style 1 templates should have an alias which is in lowercase that has separations with hyphens between English words, between (not within) acronyms, or between English words and acronyms. The documentation is to show this lowercase, hyphenated version as the one for "normal use". This meant, for example, that |access-date= would be shown as the preferred parameter while |accessdate= was shown as acceptable but discouraged from use. In the following years there have been various trends and discussions formally deprecating many of the non-hyphenated parameters, from a small handful (2019 example) to the current list which contains over 70 entries. Many of these are the non-hyphenated variants of the preferred/hyphenated versions, which are being removed to decrease the maintenance burden and increase the uniformity between templates (i.e. "ease of use"). Other changes have included having RefToolbar give the hyphenated params and setting AWB's genfixes to replace some parameters.

    In October 2020, all non-hyphenated parameters were added to the "current list" linked above. In November 2020, a bot request was submitted ("Monkbot 18") to remove or replace these deprecated parameters so that they could be removed from the base module and simplify the template code further. While acknowledging that this task was largely cosmetic in nature, BAG and other venues (primarily templates for discussion) have historically sided with the idea of a "maintenance burden" as a valid reason for edits such as these; see for example Monkbot 17, which replaced (cosmetically) one parameter for a better-named value for ease of use.

    The issue for Monkbot 18 arises from the number of edits it is/was required to make; a conservative estimate would put the number of edits it has made for this task over a two month period (Nov 2020-Jan 2021) at around 1 million edits; as discussed on the task's talk page, this has essentially removed all but five of the non-hyphenated parameters, but another 2-3 million edits taking up to four additional months will still be required to fully "clear out" these parameters. Additionally, those opposed to the bot also expressed concern that the relatively small-scale discussions to deprecate these parameters had not reached a wide enough audience to merit what they felt were sweeping changes.

    Proposal (CS1)

    There are three main options with regard to the CS1/2 family of templates, and by extension Monkbot 18's task.

    • Option A: Non-hyphenated parameters should be deprecated and removed; the bot is free to continue its work.
    • Option B ("status quo"): Non-hyphenated parameters are formally deprecated, but should not be immediately removed. Deprecation can be bundled into genfixes or performed along with other non-cosmetic changes, but (ignoring a possible Cosmetic Bot Day) should not be done on its own by a bot.
    • Option C: Non-hyphenated parameters should not be deprecated; deprecation should not be continued and bot approval should be revoked. This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters.

    Please note that this discussion is primarily about the CS1/2 template parameters and whether two full sets of parameters should be kept/maintained. It is not the place to re-litigate the various discussions about Monkbot 18's task; Option B is provided for those who feel the task should not proceed.

    Survey (CS1)

    • First choice A, second choice B. I'd be happy to see AWB's genfixes take on some of this burden, and I'd be happy to see this happen a little more slowly, but it should happen, even though it's occasionally inconvenient for me. Also, when any individual parameter reaches a sufficiently small state (e.g., potentially still thousands of uses, but not hundreds of thousands of articles), the template should be updated to disallow that particular parameter (not merely advise against it in the documentation), so that they won't keep creeping back in, because, hey, it still works, so why should I bother? WhatamIdoing (talk) 19:12, 10 February 2021 (UTC)[reply]
      @WhatamIdoing: AWB's genfixes already handles this through WP:AWB/RTP, so manual edits and other bots can help whittle down the list while making other (non-cosmetic) edits. GoingBatty (talk) 04:12, 11 February 2021 (UTC)[reply]
      GoingBatty, are you sure that |accessdate= will be replaced by |access-date= by editors using the current version of WP:AWB/RTP? I think it was removed. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)[reply]
      @Jonesey95: You're right! While the functionality exists (and other parameters are still replaced), editors have removed some hyphenation replacement rules. GoingBatty (talk) 04:59, 11 February 2021 (UTC)[reply]
    • Option A. I support completing the nearly finished move away from unhyphenated multi-word parameters. See below for more details about this process, which is being questioned now by a very few editors after seven years of work, and when it is more than 90% complete. With any other template, it would have been the work of a few days to standardize on one style of parameter name and convert all of the transclusions. The only reason that the process for CS1/CS2 templates is different is that there are millions of transclusions instead of hundreds. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)[reply]
    • Option C. This is pointless make work; see extended comment in discussion section. Espresso Addict (talk) 07:08, 11 February 2021 (UTC)[reply]
    • Option C If it was only confined to a few thousand pages, it wouldn't be a big deal. But when it's upwards of 3 million pages, maybe it should be the other way round - IE no hyphen. Lots of pointless bot cloggage in going through millions of pages for a trivial change. Lugnuts Fire Walk with Me 08:20, 11 February 2021 (UTC)[reply]
    • B if not C As per comments above; many editors are clearly quite happy with the unhyphenated forms, so why not allow both? Changing is pointless. Lots of other templates allow aliases as parameter names. I fail to see the problem. But we are where we are, so I favour B rather than C. Peter coxhead (talk) 09:04, 11 February 2021 (UTC)[reply]
    • Option A (second choice B), per Jonesey95. Let's just get everything simplified, as it should be. Get on and finish the job. --NSH001 (talk) 10:18, 11 February 2021 (UTC)[reply]
      Update Add a qualification: I still very much hope that the bot will be allowed to resume, but subject to this condition: only if Monkbot 18 drops its removal of entirely blank lines within citation templates. For the reasoning behind this, see my conversation with Floydian in the discussion section (this is quite an easy change to make to the bot). While I'm here, I'll add a second qualification, also arising from the discussion: the list of articles on which the bot runs should be filtered to remove articles that have already been visited by the bot. This is in order to reduce the alleged problem of "bot spam" objected to by some editors (who says I don't listen to objections?). --NSH001 (talk) 06:52, 12 March 2021 (UTC)[reply]
    • Option C. It is a totally pointless exercise. The unhyphenated ones are better in my eyes as they do not wrap in the edit window and can be underlined as a typo so are clearly visible in the edit window. Keith D (talk) 13:01, 11 February 2021 (UTC)[reply]
    • C (first choice) or B (second choice). I've read many of the discussions about this issue and I've never yet seen anything the convinces me that deprecation actually benefits the encyclopaedia in any way. Even if we assume for the same of argument that it somehow does, the real and evident disruption caused by the bot so far and the extent of the changes the bot operator notes will be required to complete the task, very clearly and very significantly outweigh that benefit. Thryduulf (talk) 15:20, 11 February 2021 (UTC)[reply]
    • Option A this change is a bit painful, but better for editing in the long-run. It's better to make this change than to not make it. The best time would've been fifteen years ago - but the second-best is now. Allow the bot to continue its operation, get rid of all the parameters, and once all are removed, start generating cite errors. Elliot321 (talk | contribs) 17:09, 11 February 2021 (UTC)[reply]
    • Option A. Unfortunately, the visual editor exists... but isn't useful for large editing projects and thus many people still use wikitext editing - condensing to one form (specifically the hyphenated one as it is easier to read for editors) will help ensure consistency between articles at least in the CS1 templates. Obviously this won't make every article easier to edit as there are articles with non CS1 style citations, but it'll help the millions that do use CS1 look the same to editors instead of having a hodge-podge of hyphenated names. I further agree with the bot continuing to run now, and then running maybe once per week or so after this initial run to fix any CS1 non-hyphenated parameter names. -bɜ:ʳkənhɪmez (User/say hi!) 17:13, 11 February 2021 (UTC)[reply]
    • Option C. The point of templates and bots is that they should work to make editors' lives easier, not that editors should change the way they do things to make template and bot creators' lives easier. This bot has it completely topsy-turvy, and if the bot-approvals group has approved this then that is a problem with that group, not with a few unhyphenated parameters. I can't help feeling that that group is looking at the interests of a few bot operators rather than of the many more editors and still many more readers. There's no great complexity in having a few synonyms for template parameters, and there's no problem at all with exporting data - if the synonymic parameters point to the same place in code then they can be exported in the same format with no extra effort. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. Phil Bridger (talk) 18:21, 11 February 2021 (UTC)[reply]
      The point of templates and bots is that they should work to make editors' lives easier. Exactly so. That's what this bot is for. It makes the parameter names easier to read (taking them as a whole, not just access-date on its own), reduces the size of the template documentation, makes the parameter names all consistent. All these combine to make learning how to use the cite templates easier. It also makes maintaining the templates easier. a win-win situation. The only reason we're having this discussion is that Mediawiki's watchlist software is so bad at handling bot edits. Otherwise it would be a no-brainer. Some people here seem to be under the mistaken apprehension that this is just to advance the interests of "a few bot operators". Well, I'm quite sure Trappist (the operator of this bot) could do without the stress of planning, writing and running this bot. He does a bloody fantastic job, and deserves a huge amount of credit and appreciation for his work. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. The whole reason for this bot is to make users' life easier. FWIW, I also have experience of IT work more than 40 years ago (seconded for 2 years to work on a (very successful) project - mathematical programming on big data for a life insurance company) and frequently had to liaise with IT people since then. I'm well aware of the problems that can arise when you just allow systems to get more and more complex, so I appreciate Trappist's (and many other people's) efforts to simplify matters. --NSH001 (talk) 23:37, 11 February 2021 (UTC)[reply]
      Clarifying: Re-reading this again this morning, it might appear to readers who don't read carefully that I'm agreeing with Phil Bridger. Nothing could be further from the truth, I still support Option A. Option C makes no sense, for all the reasons set out by SMcCandlish. --NSH001 (talk) 08:35, 12 February 2021 (UTC)[reply]
      And Phil Bridger's hyperbole stance is fallacious. Option B imposes nothing on anyone. "I don't like option A" does not equate to "only option C can work". Option B is the status quo, and it has broken nothing. I'm rather shocked at how stark obvious this is, yet at least 10 editors don't seem to have noticed. I know that we have a lot of populism running around in the world – a lot of "I would feel very strongly about this, if it were true, and it feels good to pretend its true, so I'm going to pretend it's true" behavior. But that stuff needs to be left at the door.  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)[reply]
      No, my stance is not hyperbole or due to populism. The reason I reject option B is the word "immediately". It still leaves current consensus that unhyphenated versions of parameters will be removed, just not immediately, and it is that consensus that should change, however many years it has been stable for. I am happy with simplifying the documentation, but not with removal of the option. Phil Bridger (talk) 09:19, 12 February 2021 (UTC)[reply]
      As noted above: Deprecation is not synonymous with disabling. You're confusing replacement of the parameters as written in a template transcluded in a page, with removal of the runtogether parameter variant's ability to function in the template. Only option A would do the latter. We have many, many templates that support variant-spelling parameters but do not "advertise" them in the documentation, and it breaks nothing whatsoever to bot-replace them with the canonical version, just as the same bot will replaces calls to a redirect name for the template with the actual page name of the template. I.e., you're having a strong negative reaction to an argument that option B is not actually making.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)[reply]
      Option B very clearly says "but should not be immediately removed". Either the word "immediately" has some meaning, and this option would lead to removal, but just not immediately, or it has no meaning and has no business being there. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)[reply]
      SMcCandlish, this was explained in the previous discussion at CS1: ""Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go". So the intention is to error and then remove the functionality of these parameters, not simply not advertise them in the documentation. If you want to propose a variant of option C that removes the parameters from the documentation but still allows them to function, go ahead, but option B is not that. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)[reply]
      What I want to propose is a variant of Option B that removes the parameters from the documentation before letting some bot go around changing the articles on my watchlist as if the parameters are somehow bad. If the params are really bad, and if there's a consensus to that effect, then Step One is to take them out of the documentation (either by dragging them away in the dark of night, silently, like ninjas, or by transparently mentioning them as being deprecated, so everybody knows what's going on). The first phase of real deprecation is telling people to stop using something. Then you can start throwing up red messages and it's not so damned rude or surprising. — JohnFromPinckney (talk) 21:40, 13 February 2021 (UTC)[reply]
      Sure, I would support that variant, too. Or a variant that kept mention of those versions of the parameters but deprecated them. Whatever gets us closer to having consistency in the actual deployed templates being used in citations.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)[reply]
      This stuff should be in a tracking category, if that's what bots and other tools are going to work with. If we don't like the error messages, then we can disable them. This is just template and module code, it's not etched forver into a mountain face like Mt. Rushmore.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)[reply]
    • Option C I agree strongly with Phil Bridger here. In other words, I fail to see what exactly is accomplished by making millions of cosmetic edits and then deliberately breaking things that would otherwise have worked. * Pppery * it has begun... 20:21, 11 February 2021 (UTC)[reply]
      Option B breaks nothing. You, et al., are providing an argument against option A, not an actual argument for C, and just ignoring B. Also, a !vote for C is an !vote for overturning a status quo that has been stable for years, in favor of chaos, yet without an actual rationale to do so. The closer should take that into account, per WP:NOTAVOTE. In the event of a "no consensus" result we still end up with the status quo. Things like this are why I keep telling people they need to write RfCs better. "Anything that can be misinterpreted will be."  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)[reply]
      SMcCandlish, option B supports disabling of the non-hyphenated parameters - that is a breaking change. The difference between A and B is speed, not outcome. Your !vote below suggests you want the non-hyphenated variants to remain supported, but of the options provided only option C accomplishes that. Nikkimaria (talk) 16:18, 13 February 2021 (UTC)[reply]
      Nope. See my response to same claim by Phil Bridger, above.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)[reply]
      Yep - see above. You can also look at what has happened with previously deprecated CS1 parameters such as |authorfirst= - they don't work. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)[reply]
      Which is perfectly fine, given enough time that people stop actually using them. Thus remove them from the template documentation and replace them in deployed template translcusions. Eventually the "monkey see, monkey do" effect of being exposed to deprecated parameter variants goes away, through decreased and eventually zero exposure. I'm mean, come on, that's what the point of deprecation is. It seems to me that you [plural] are coming from a "give me C or give me death" perspective, artificially conflating A and B because you just will not tolerate the idea of any parameter name variants ever going away for any reason. If I'm wrong about that perception, then please explain.  — SMcCandlish ☏ ¢ 😼  04:18, 14 February 2021 (UTC)[reply]
    • Option C per Phil Bridger. Ealdgyth (talk) 21:28, 11 February 2021 (UTC)[reply]
    • Option C - Commenting here probably falls under my doctors' lists of "things HF shouldn't do while he has a concussion", but I don't want to miss this discussion. While I understand that maintaining the citation templates is not a particularly easy job, in the end, rigidness in the citation template is not desirable. The citation templates should be easy to use, and having a couple aliases for the most common parameters makes it easier to use. And a trout to the bot guild for approving a bot task that was designed to deprecate template parameters with no consensus for that deprecation. Hog Farm Talk 22:15, 11 February 2021 (UTC)[reply]
    • First choice A, second choice B. Wikipedia source text is becoming increasingly complex and difficult to manage making it less accessible, except for the type of experienced editors participating here. Anything we can do to reduce complexity is a win, fewer options the better when plainly redundant. -- GreenC 22:41, 11 February 2021 (UTC)[reply]
    • Option C per Phil Bridger, personally I prefer non-hyphenated parameters, and I find deprecating them to be an absolutely pointless exercise that breaks things for absolutely no reason other than to satisfy the cosmetic preferences of a few editors. Devonian Wombat (talk) 00:14, 12 February 2021 (UTC)[reply]
    • Option C. Largely per Hog Farm. Keeping extremely commonly used aliases is helpful for editors using these templates. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)[reply]
    • Support option C, neutral on option B, strongly oppose option A. My fingers are used to typing many of these parameter names without hyphens. Deprecating them and the accompanying gnomework of replacing them with the un-deprecated versions is already causing me significant hassle, both in trying to remember that really now they should be hyphenated, and in trying to pick out the important changes on my watchlist among all the pointless gnomery. Removing the unhyphenated forms altogether would be worse. —David Eppstein (talk) 01:41, 12 February 2021 (UTC)[reply]
    • Option C. I'm with Phil Bridger and Hog Farm. I don't know if this is bike shedding or yak shaving, but it's just not productive and a bad look. Alternatives exist because it's simpler than remembering which of two common possibilities are acceptable, rather than forcing one or the other (as the other options do). Discussing efficiency because of a off-row character on the other hand (oh, so we're making this choice based on everyone using QWERTY?) is the kind of ignore-practical-facts reasoning that yield platypus-shaped end results. -- Mikeblas (talk) 01:52, 12 February 2021 (UTC)[reply]
    • A is better in the long run, but B for now, and have the conversion covered by AWB genfixes and similar. Headbomb {t · c · p · b} 02:29, 12 February 2021 (UTC)[reply]
      Comment Unfortunately, in this case, leaving it to AWB genfixes alone would be neither effective nor desirable. Because there are likely to be so many of these parms on any given page, the genfixes are likely to swamp the main, intended change, causing understandable annoyance. Much better to leave it to this excellent bot, which is clear and open about what it is doing – no nasty surprises. That's why I prefer option A to option B, but either of these is vastly preferable to option C. --NSH001 (talk) 08:31, 7 March 2021 (UTC)[reply]
    • Option C per Phil Bridger. SarahSV (talk) 02:51, 12 February 2021 (UTC)[reply]
    • Option C. This "everything must be hyphenated" approach doesn't work well with the text editor. For some common parameters like |accessdate=, it is simply better being unhyphenated because the source text is quicker and easier for a human to parse because the parameter doesn't word wrap in the editor's textbox. Jason Quinn (talk) 03:09, 12 February 2021 (UTC)[reply]
    • Option B. We should stop listing the nonhyphenated ones in the documentation at very least, so that between editorial shift and AWB/bot genfixes cleanup, we get more consistent over time. It's too soon for option A, if ever, because the templates serve us, we don't serve the templates. It's perfectly fine for templates to quietly support non-hyphenated variants so they don't just break if people try them. But we should not continue listing those variants in the docs. It's antithetical to the purpose of templating, for us to perpetuate inconsistency (without good reason, like an ENGVAR color vs. colour distinction). And it pointlessly makes the documentation longer and more complex for no gain at all; no one looking for how to specify the Archive.org URL needs to know anything but |archive-date=, and telling them |archivedate= also works is just stuffing pointless trivia into their head. Yes, do continue converting to hyphenated versions in genfixes and other automated edits (when doing something more substantive at the same time). Finally, option C is rather pointless. We've regularly been (gradually) deprecating various old parameter names, and it has worked just fine. Option B will not break anything, and will have (already is having) positive results.  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)[reply]
    • Option B Option C. These are all valid aliases, as there is zero confusion between say |access-date= and |accessdate=. The status quo works fine: hyphenated is preferred because it's easier to read, but unhyphenated is acceptable because there is no ambiguity and evidently plenty of people type it that way. Cosmetic changes should adhere to policy. – Finnusertop (talk ⋅ contribs) 05:53, 12 February 2021 (UTC) Changed from B to C as I am opposed to the implications of the "formally deprecated" part of these valid aliases. – Finnusertop (talk ⋅ contribs) 09:26, 12 February 2021 (UTC)[reply]
    • Option C first choice (B second). Editors should be allowed to use either hyphenated or non-hyphenated versions. Consistency is not better than flexibility here: the only people reading the parameter are editors, so let the editors decide whether or not they want to use a hyphen in their template parameters. I share the general concern about the disconnect between code writers and content writers, and the frustration with some template and bot maintainers imposing decisions on everyone without consensus. Fait accompli editing across millions of edits or transclusions is kind of a big deal. Levivich harass/hound 07:20, 12 February 2021 (UTC)[reply]
    • I Like C: I especially echo Levivich, Thryduulf|, and Phil Bridger's comments regarding these perennial, periodic, new surprises where editing articles is concerned. That is disruptive and we should just stop it. C, therefore, will bring the sanity back. GenQuest "scribble" 07:42, 12 February 2021 (UTC)[reply]
    • Option C. These are templates for use by editors, they have no impact on readers, and it's a complete waste of time making rules and regulations about them and then writing bots to enforce those pointless rules. Not to mention that when AWB goes through "fixing" all these in an article, it can drown out the genuine edits and make it harder for people to track what's going on. Get rid of this ridiculous rule, delete it from AWB, and then maybe we can get on with actually building an encyclopedia.  — Amakuru (talk) 09:13, 12 February 2021 (UTC)[reply]
    • Option C (which is the status quo ante). I just don't see what problem people are trying to fix, so follow WP:NBDF. The hyphenated parameters are useful and improve wikitext legibility, I personally prefer them, but allowing both forms makes things easier for editors. Deprecating them appears pointless, and removing them entirely seems actively harmful. It's created millions of pointless busywork edits clogging up watchlists for no good reason. We don't have a problem with template aliases, so why the concern about parameter aliases? None has been convincingly articulated. Modest Genius talk 12:10, 12 February 2021 (UTC)[reply]
    • Since I have been pinged, neutral all round. I'm have nostalgia for the status quo for some reasons already presented (muscle memory, line breaks), but I recognize that once we pass through the valley of the shadow and emerge into the bright uplands yonder of a cleaner implementation, we'll have forgotten the pain. Mind you, I'll probably be 90 years old and beyond caring. But I have some implementation concerns in the Discussion. David Brooks (talk) 16:54, 12 February 2021 (UTC)[reply]
    • Option C - Standardization of this sort may be useful to researchers or developers, but not to regular users. Adding citations should be as easy as possible. To that end, I want to minimize the chances that the interface will not know what I'm trying to do, or that I'll get an error because I entered an underscore instead of a hyphen. The rest of the internet is trying to increase flexibility to make user experience easy and intuitive. We do that too in many ways. But here we seem to be doing the opposite: removing flexibility and requiring users to know how we've worded/arranged things.
      I don't care if there's a bot that goes in an standardizes them afterwards or if someone runs AWB behind me. Again, I get the appeal of standardization. We should just be doing everything we can to make the experience intuitive for regular users. — Rhododendrites talk \\ 23:04, 12 February 2021 (UTC)[reply]
      • Alternative: Option D - let the bot and/or AWB standardize, but never disable the parameters. Standardization is good; degrading usability is bad. — Rhododendrites talk \\ 23:12, 12 February 2021 (UTC)[reply]
        I would certainly support your option D if it was on the table, but cannot support anything that says that this functionality should be removed, as option B (despite the illiterate claims above that it doesn't) clearly mandates. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)[reply]
    • Option A with B as my second choice. Maintaining our complex citation templates is not an easy task, and if the people who are putting in the work want to do this to make their jobs easier, I'm in favor of it. Legoktm (talk) 23:48, 12 February 2021 (UTC)[reply]
    • Option C with Option B as second choice: Modest Genius makes an excellent comment, as do several others. The community needs to stop wasting its time on this citation formatting nonsense and do the hard labor of introducing citations in articles instead, the place we actually have a front-facing desperate crisis which damages our reputation. I use |accessdate= and I have no intention to stop. I remember very clearly the process I went through of learning citation templates in 2014—they were confusing at first but I never had a single confusion in parsing "accessdate" as the two word phrase "access date", very clearly meaning the date you last accessed a reference. I can see that in theory this would be marginally better for new users, and I can see that in practice some people who don't like the look of "accessdate" are escalating it ("my opinion" becomes "the correct view" becomes "a moral imperative to enforce"), but this just doesn't outweigh the actual genuine pain it will cause editors like me to retrain a years-long developed muscle memory; almost every mainspace edit I make for months will have a disrupted flow (interrupts my thought process, wastes my time re-typing) if this is to change.
      As for the bot that has been wasting several minutes of my time per day, I strongly opposed it in the first place and have had more than enough of it. (No, I can't ignore it, because if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit.) BRFAs need wider advertisement when their scope is so enormous and their violation of WP:COSMETICBOT so overt. I don't accept that option B reflects past consensus in practice in that I can't remember anyone ever approaching me about my use of |accessdate= or changing it to |access-date= manually. Past local consensus among technical groups who don't work in article space, sure. But enwiki community consensus? No. — Bilorv (talk) 01:07, 13 February 2021 (UTC)[reply]
      • @Bilorv: if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit -- this always takes me aback. Just curious, but why not enable the "Expand watchlist to show all changes, not just the most recent" + "Group changes by page in recent changes and watchlist" settings? I see no bot edits, and they don't cover anything up. — Rhododendrites talk \\ 02:50, 13 February 2021 (UTC)[reply]
        • @Rhododendrites: appreciate the suggestion! It's never occurred to me that combining those would produce that functionality (there are so many complex combinations of Watchlist filters and Preferences options), but I've enabled those two and kept "Latest revision" on and enabled "Human (not bot)" as the Preference option "Hide bot edits from the watchlist" didn't seem to do that and now I think (small sample size in my watchlist atm) I see the latest change only, including if it's a bot, but only if at least one non-bot edit has been made (which is exactly desirable). — Bilorv (talk) 11:34, 13 February 2021 (UTC)[reply]
    • Option A with B as my second choice. Maintaining the complex citation templates is not an easy task. AManWithNoPlan (talk) 02:52, 13 February 2021 (UTC)[reply]
    • Option A on the basis that standardization is good. I don't actually care whether the hyphens are there or not, but it's better one way or the other rather than having a mix. In general I'd rather see us migrate away from using wikitext for reference information, though, it's like doing your finances in a text document. Thanks. Mike Peel (talk) 18:26, 13 February 2021 (UTC)[reply]
    • Option A I have always preferred the hyphenated form personally because it allowed the spell checker to verify that there was no typo, whereas the unhyphenated form is always flagged as a typo, although the preview now informs me of errors. I disagree with the contention that humans can parse |accessdate= more quickly than |access-date=; spaces were invented for this reason. I also know the overhead that permitting multiple parameters that mean the same thing in templates entails. I'm aware that this has been cluttering my watchlist with Monkbot edits, but my !vote is to continue. Hawkeye7 (discuss) 22:12, 13 February 2021 (UTC)[reply]
      Note that this is mostly an WP:ILIKEIT rationale and dismisses the views of those who indicate that they can parse "accessdate" without issue as wrong without any evidence. It also dismisses the very real disruption caused to others as necessary to reduce overheads, whereas this overhead, even if it is a significant as some claim (for which no convincing evidence has ever been presented) it's still trivial compared to the disruption caused by Monkbot's edits and by the unnecessary disruption to editors using the templates. Thryduulf (talk) 15:29, 14 February 2021 (UTC)[reply]
    • B or C. I've no strong preference between accessdate or access-date, both seem useable, if one is formally preferred then fine. However, the massive ongoing bot spam for something that has literally no effect on readers, and barely any on editors, is unwarranted. In addition to being everywhere on the watchlist, Monkbot makes it much harder to disentangle various series of diffs in the edit history for little benefit. A user making an edit inserting "accessdate" isn't an egregious issue that should cause a bot to come running, and such a bot action then obscures the edit in question from watchlists. CMD (talk) 18:18, 14 February 2021 (UTC)[reply]
    • Option C. Removing a common way to type parameters in templates reduces ease of use for the end users. Having a bot going around and "fixing" these has a negative impact on the readability of page history and watchlists . No one in this conversation has demonstrated that the maintenance burden on the template is so significant that it would justify all of these downsides. It also seems that the maintenance burden is not something that would be difficult to track like accidental blue links to primary topic articles when non-primary topic articles were intended, since the template code are on the template pages.---- Patar knight - chat/contributions 18:53, 14 February 2021 (UTC)[reply]
    • Option C. The previous discussions linked above (a six-year-old RFC with seven people participating in it, which specifically promised that nothing would be depreciated, followed by a handwavy argument about maintenance burden), are not remotely sufficient to justify such a sweeping change. Yes, maintenance burden is a pain, but it affects a relatively small handful of bot authors; removing the most widely-used version of a template parameter affects a huge swath of editors, who need to be given deference here on account of being a larger group. And obviously there is not a standing consensus that maintenance burden justifies such changes (at least not one on a scale necessary to justify this), or this discussion wouldn't be so clearly split. Therefore, the unhyphenated version should never have been depreciated, which makes the bot's edits pointless clutter at best and an attempt to push through a controversial change without sufficient consensus via fiat accompli at worst. Furthermore, if maintenance burden is the only concern, obviously the solution is to reverse the 2016 RFC (which, again, had only seven people participating it and agreed merely to create the hyphenated versions as alternatives) and remove the hyphenated version, which currently sees little use and would therefore be far easier and less disruptive to discard. --Aquillion (talk) 22:12, 15 February 2021 (UTC)[reply]
    • Option B-ish. I think it's reasonable to have the hyphenated forms be the canonical version of the parameter, but I see no reason to make mass-edits to change from one form to another or to change the usual rules about cosmetic bots here. I see no harm in Option C, but implementing Option A will trade current problems for new ones. --AntiCompositeNumber (talk) 02:15, 16 February 2021 (UTC)[reply]
    • Strong Support A: standardization for template parameters is important & useful.
    Mild Support B: the # of |accessdate= per page is too damn high (much of the time), so much so as to interfere with checking regular WP:GenFixes (i.e. many single-screen diffs become many-screen diffs) — I would Strong Support B IIF Monkbot was allowed to continue & hyphenate at least this parameter.
    Strong Oppose C: antithesis of A.
    ~ Tom.Reding (talk ⋅dgaf)  19:23, 16 February 2021 (UTC)[reply]
    • To whom is standardization for template parameters important & useful? Phil Bridger (talk) 20:39, 16 February 2021 (UTC)[reply]
    • How and why is standardisation more important and useful than editors being able to improve the encyclopaedia without needing to know the exact format of parameter names and deal with watchlists and page histories full of cosmetic edits? Thryduulf (talk) 20:45, 16 February 2021 (UTC)[reply]
    • Are y'all suggesting we bring back all deprecated parameters, and adding more so that every user may choose to use the parameter names that are most comfortable/understandable/intuitive to them? I'm ok with soft-deprecation - allowing both but discouraging/converting one, in bulk once via bot, then gradually/passively via WP:GenFixes & other tools, but that is not one of the options.
      Re: "watchlists": may be configured to ignore bots until it's done.
      Re: "histories full of cosmetic edits": the bot only requires 1 edit; hardly "full of"; regardless, there is community consensus for WP:CBD.   ~ Tom.Reding (talk ⋅dgaf)  12:16, 17 February 2021 (UTC)[reply]
      Yes, I am suggesting that all the two-word parameters should accept hyphenated and non-hyphenated varieties. It's fine for one to be preferred over the other in documentation but both should work and continue to work as this is by far the least disruptive to editors and allows them to spend their time producing/maintaining content rather than worrying about finicky syntax. I don't have massively strong objections to general fixes substituting one for the other when making non-cosmetic changes to the page, but I wouldn't actively encourage it as it will clutter diffs for no benefit. I strongly oppose bulk bot runs and making one option non-functional in the future. Thryduulf (talk) 15:29, 17 February 2021 (UTC)[reply]
      Re "Are y'all suggesting we bring back all deprecated parameters" - yep, that's spot on. They should never have been deprecated in the first place. This is a template, which sits in the background, and exists for editor convenience, nothing more. Deprecating parameters reduces that convenience. And it's well-established that bots and editors shouldn't be running through making cosmetic changes to wikitext that do nothing to alter the page, so those need to stop as well.  — Amakuru (talk) 12:48, 18 February 2021 (UTC)[reply]
    • Option C, I guess, as I've not been persuaded as to the marginal utility of the hyphenated versions. Without that clarity, we shouldn't be doing these kinds of changes. (And if we had consensus, then B, but with documentation changes as the first step.) — JohnFromPinckney (talk) 01:48, 17 February 2021 (UTC)[reply]
    • Option C If it works don't fix it. Andrew🐉(talk) 13:01, 17 February 2021 (UTC)[reply]
    • Option A, strongly oppose option C: anybody working regularly on templates or modules will appreciate the value of settling on a single style for issues like parameter names. I don't care what the agreed style is, as long as it's consistent, and the argument about whether it should be hyphenated, underscored, camel-case or run-on has been settled with hyphenated as the preferred style. It is then nonsensical to fail to implement that style, and I'd prefer it was done as soon as possible. This whole debate is reminiscent of the date-linking wars where strong objections were made to unlinking dates, yet within a few months of a binding decision being reached to delink dates, everyone had moved on, and nobody today would even consider linking dates. Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is. --RexxS (talk) 19:46, 19 February 2021 (UTC)[reply]
    • A or B but not C per Scott, Hawkeye, and RexxS. Usingahyphenismoreuserfriendly, andwhilethereissomeupfrontworkonourparttomaketheswitch, itisbetterinthelongruntohavesomedelimiterbetweenwordsinsteadofrunningthemtogether. Just like we stopped linking dates and no longer SmashWordsTogether, this is worth the temporary inconvenience. — Wug·a·po·des​ 00:46, 20 February 2021 (UTC)[reply]
      Notwhen it'sjust twowords :-P Levivich harass/hound 08:10, 20 February 2021 (UTC)[reply]
      ...is what your comment would look like if we allowed people to use whichever method worked for them and still made it work. If we turn off those parameters, your comment wouldn't have appeared. If we allow people to use whatever works and use a bot to clean it up afterwards, your comment would look just like everyone else's after some period of time (during which your comment would still be functional, even if pairs of words were sometimes combined). :) — Rhododendrites talk \\ 20:15, 22 February 2021 (UTC)[reply]
    • Option A for all the arguments already made at length in the CS1/CS2 talk pages over the years and the good arguments brought forward above. Definitely not Option C. --Matthiaspaul (talk) 02:06, 20 February 2021 (UTC)[reply]
    • Option C. Such an absurd waste of time and energy and an enormous source of watchlist spam, all to achieve something that will make editing more difficult. Toohool (talk) 02:26, 22 February 2021 (UTC)[reply]
    • Option A as standardizing is better in the long term. Let the bot continue its work. If people have a problem with their watchlist getting spammed, they have the option to filter out bot edits. AVSmalnad77 talk 05:59, 23 February 2021 (UTC)[reply]
    • Option C if not B While I love consistency, I'm struggling to see what the actual issue is here. I guess they can be gradually changed by the bot along with other more useful changes, but this is just cosmetic to the code and clutters edit histories. Reywas92Talk 06:21, 24 February 2021 (UTC)[reply]
    • Option C. Benefits for bot or template builders don't outweigh the inconvenience for other editors. Fram (talk) 08:13, 24 February 2021 (UTC)[reply]
    • C. I don't see the argument for mandating hyphens. Just let people use both, consistency on this does not matter. Fences&Windows 17:00, 24 February 2021 (UTC)[reply]
    • Comment - my default is Option D... I refuse to use citation templates, and format my citations by hand. It means that I can ignore all the silly debates about parameters and what not. Blueboar (talk) 17:49, 24 February 2021 (UTC)[reply]
      Yeah and we can instantly clear the WP:PHAB backlog by writing articles with paper and pen. We can solve many technological problems by abandoning technology. Levivich harass/hound 00:52, 25 February 2021 (UTC)[reply]
    • Option C. Bots do some useful work but their code can be changed as needed. Here I am much more concerned about regular editors who use citation templates when making manual edits. These are live human beings and there are many more of them than bots. Making the template syntax too rigid will make their life much more unpleasant. Extra flexibility is both useful and helpful for regular editors. Nsk92 (talk) 02:26, 25 February 2021 (UTC)[reply]
    • Option C. I've been typing accessdate for the last 15 or so years, sometimes while reaching for my drink with my other hand (Qwerty keyboard). Why wreck my muscle memory and deprive me of a sip of tea?-gadfium 04:04, 25 February 2021 (UTC)[reply]
    • Option Cper Phil BridgerSea Ane (talk) 21:53, 26 February 2021 (UTC)[reply]
    • Option C, stop the craziness hitting watchlists (although most of that damage is already done). SandyGeorgia (Talk) 00:58, 2 March 2021 (UTC)[reply]
    • C sounds best, followed by B. Removing parameters that were widely used in the past will break old revisions of articles for very little practical advantage. —Kusma (t·c) 11:44, 2 March 2021 (UTC)[reply]
    • Option C. Others have already hit on why – watchlist spam, waste of time and energy for no genuine benefit, unnecessary imposition on editors, etc. I'm increasingly warming to the idea of writing out citations manually (as someone else here mentioned), just to avoid the constant tinkering around that seems to take place with these templates. JG66 (talk) 11:51, 2 March 2021 (UTC)[reply]
    • Option C per Aquillion. Monkbot should never have been approved --In actu (Guerillero) Parlez Moi 20:22, 2 March 2021 (UTC)[reply]
    • A or B This seems like a choice between having unnecessarily having several different ways to write a given parameter, and between standardizing after the fact with a lot of minor edits. Many of the arguments in favour of C appear to presuppose that editors will land in trouble for writing the unhyphenated parameters, but I don't see evidence of that. Jo-Jo Eumerus (talk) 10:30, 4 March 2021 (UTC)[reply]
    • Option A. From real world experience, I understand how difficult it is to maintain code without occasional deprecation. Opponents' fears of unacceptable disruption and inconvenience don't match what I encountered when the bot was running, and typing the hyphen quickly became second nature. --Worldbruce (talk) 05:07, 7 March 2021 (UTC)[reply]
      You may not personally have encountered disruption and inconvenience, but I did and there are a great many other editors in this and other discussions that have reported unacceptable disruption and explained exactly why the inconvenience is not justified. Thryduulf (talk) 20:29, 7 March 2021 (UTC)[reply]
    • Option A. Long term benefit is worth the short-term disruption. There is too much inconsistency in templates that causes me to waste far more time (e.g. is it "image=" or "Image=" or "photo=" in this particular template); we should move towards more consistency. I would support keeping the parameters functional for a few years (but undocumented and with a warning) for those who really are troubled by typing the hyphen, knowing the bot will come by and change them. MB 15:23, 7 March 2021 (UTC)[reply]
      The better solution to "is it "image=" or "Image=" or "photo=" " is simply to support all of them. That way there is no need for any disruption, short-term or otherwise. Thryduulf (talk) 20:31, 7 March 2021 (UTC)[reply]
    • Option A—standardization helps simplify code maintenance, and that means more time can be devoted to future improvements. Imzadi 1979 → 17:34, 7 March 2021 (UTC)[reply]
    • The question before us is: Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? Yes, absolutely, for most if not all of the reasons enumerated above. Consistent parameter naming should have been implemented c. 2007 when the various, independently-developed, cs1|2 templates were converted to use {{citation/core}} as the common citation rendering engine. In early 2013, en.wiki migrated to the Module:Citation/CS1 suite. Since then, approximately 180 other-language MediaWiki wikis plus some number of non-MediaWiki wikis have also migrated to the module suite. In the time since en.wiki switched to the module suite, we have added new parameter names to support new functionality while at the same time, we have pared away quite a few parameter names because of redundancy, peculiar name-style, non-use, and other reasons. This reduction includes most of the nonhyphenated multiword parameter names so that today, the only remaining nonhyphenated parameter names are |accessdate=, |archivedate=, |archiveurl=, |authorlink= (and its two enumerated forms), and |origyear= (there are 263 basic parameter names and 77 enumerated parameter names). The worldwide adoption of the cs1|2 module suite has caused us to add support for internationalization. Non-English wikis employing the cs1|2 module suite should retain all of the English parameter names because, very often, articles developed at en.wiki are exported and translated to those other languages. That means that a fully implemented module suite at a non-English wiki must support the 340 English parameter names plus 340 local parameter names. It is best, I think, to have a single consistent style for multiword parameter names so that translating editors don't have to learn about or deal with redundant parameter names (this same applies to beginner editors at en.wiki). The cs1|2 templates are complex enough, we don't need to add to that complexity by maintaining lists of synonymous parameter names that don't have semantic meaning (for example, |chapter=, |article=, |entry=, |section=, etc, are treated by cs1|2 as synonyms but, to editors, convey different meanings – the inclusion or omission of a hyphen conveys no meaningful distinction). So yeah, non-hyphenated parameters [should] be fully removed from the CS1/2 family of templates and since we can't go back to 2007 to do what we should have done then, we should do it now, we should do it quickly, and we should get it done. A is my preferred option but, if needs must, then (sigh) B; never that other option. —Trappist the monk (talk) 00:50, 8 March 2021 (UTC)[reply]
      Thanks for weighing in, Trappist; I just wish you had done it a month ago. Your explanation is persuasive, but I still think Option A is silly if we don't at least simultaneously change the documentation to tell users, "don't use that parameter anymore". Having the bots fight against the human editors is silly and inefficient and possibly even dangerous. — JohnFromPinckney (talk) 02:03, 8 March 2021 (UTC)[reply]
      So to summarise Trappist's arguments: It's much easier for developers to only have a few names so we should disrupt editors and thus the wiki to make their lives easier, regardless of the costs (it's been explained at length previously how having two names do the same thing is not at all a problem for editors). Sorry, but that is not persuasive in the slightest: templates exist to support editors not the other way around. Thryduulf (talk) 03:06, 8 March 2021 (UTC)[reply]
      No. Trappist said no such thing. He helpfully explained why this change is necessary. With the possible exception of watchlists, this change does not seriously "disrupt editors" (there's no way having to type in one extra character can be said to be a problem of that magnitude); on the contrary, in the long run it makes life easier for editors, because there is only one simple, easy-to-remember rule: all muti-word parameters use a hyphen to separate the words. On watchlists, see #Worth noting below, which seems to be a promising solution. And if the worst comes to the worst and that solution doesn't work for you, then I sympathise, but at least the "disruption" is only temporary until the bot is finished. --NSH001 (talk) 10:05, 8 March 2021 (UTC)[reply]
      No, the disruption is not temporary. Not only are people likely to continue using the "old" parameters, but removing support for these parameters from the templates means that millions of old revisions will have errors in them instead of simply displaying the references like they used to. Creating errors in the references of old versions of countless pages, so that you only have to maintain 340 instead of 349 parameters (well, not even that, 340 parameters + 9 synonyms)? That seems like a lot of disruption for little gain. Fram (talk) 11:13, 8 March 2021 (UTC)[reply]
      Doesn't really matter, it's relatively uncommon to cite old versions of pages, and the error messsages can safely be ignored – only the latest page matters. They also suffer from deleted templates (which can be much more serious for the page as actually displayed to the user) and wikilinks which have gone red because the target page has been deleted. No doubt other things I haven't thought of yet. One just accepts these imperfections. Doesn't seriously "disrupt" anything. --NSH001 (talk) 14:05, 8 March 2021 (UTC)[reply]
      A redlink because the target doesn't exist isn't an issue (it is even an improvement). The others are problems, and knowingly adding much, much more of the same is a serious issue. A version of Salvador Dalí from 5 years ago now already has 10 or so errors: the lang text ones are the most annoying. But the planned defenestration of e.g. accessdate will suddenly add 24 extra errors here. Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse, and no current of future versions which will become better. Fram (talk) 14:33, 8 March 2021 (UTC)[reply]
      "Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse". That's false. Monkbot 18's edits make no difference whatsoever to the display of error messages; in fact it will reduce (drastically) the number of error messages that are eventually displayed when and if the remaining are formally deprecated, where "formally deprecated" means changing the CS1/1 module suite to actually generate the error messages. --NSH001 (talk) 09:37, 11 March 2021 (UTC)[reply]
      Not false, just shorthand. One can see the number of errors that will exist by looking at the number of edits that Monkbot does for this. No, Monkbot doesn't cause the errors directly, the deprecation does; but the two belong together. If option C is chosen, then there will be no "when and if", the remaining will not be formally deprecated, and no error messages will be generated, not in historic versions, not in live versions. None. Fram (talk) 10:56, 11 March 2021 (UTC)[reply]
      "One can see the number of errors that will exist by looking at the number of edits that Monkbot does for this." That's very misleading. The number of edits by the bot has nothing whatsoever to do with the errors displayed in the live version (except that, as I've already explained, it reduces them). You're trying to mislead readers here by implying that every single edit by the bot causes an error message, when in fact it only does so for historic versions. Error messages in historic versions don't matter. --NSH001 (talk) 12:00, 11 March 2021 (UTC)[reply]
      No, that's not misleading if one reads the actual conversation, which is about historic versions. "removing support for these parameters from the templates means that millions of old revisions will have errors in them instead of simply displaying the references like they used to." and "Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse, and no current of future versions which will become better." That's what you replied to, and which we are still discussing. We can disagree whether errors in old revisions are a problem or not, or whether the maintenance cost of keeping a few synonyms alive is negligible or significant; but please don't start accusing people of "trying to mislead readers" (a bit rich coming from someone claiming that "access-date" is easier to use and more meaningful than "accessdate"). Fram (talk) 12:12, 11 March 2021 (UTC)[reply]
    • Option C And this issue is largely why I am of the current position BAG is not suitable for purpose and needs nuking from orbit. Only in death does duty end (talk) 15:31, 8 March 2021 (UTC)[reply]
      The BAG has a few functions. It does a good job of some of them - notably it's pretty good at ensuring bots do only what their authors intend them to do before they are unleashed. The main issue is with ensuring that only tasks with consensus to be done and consensus for a bot to do the job get approved - I can't recall an instance when it failed to approve something that should be approved, and it does stop the truly egregiously bad ideas from proceeding, but there are multiple instances (including this one) where bar for consensus has been set too low and a small local consensus has allowed a bot without wide community approval to operate. If we have bots then we do need some sort of approvals process, so don't nuke the one we have without coming up with something better first. Thryduulf (talk) 16:54, 8 March 2021 (UTC)[reply]
      "only what their authors intend them to do before they are unleashed." On a technical level this is correct - what BAG doesnt do is any sort of even half-decent job of confirming that bots *continue* to only do the tasks they were initially approved for, or that that approval in the first place has consensus amongst those editors who it will *affect* that the task is wanted or needed, or that there is a clear benefit to those effected by it. The problem with automated editing is rarely the technical aspect, its the business case for it. If we did a review of current active bot tasks (and editors using automated editing to perform mass edits) do you genuinely think they will all be able to point to a discussion that shows a level of consensus proportionate to their effect on the wider editing populace, rather than the walled garden (and the term I would actually prefer to use here as its more accurate is circle-jerk) of 5 or 6 data & machine readable obsessed editors who want it? Only in death does duty end (talk) 08:30, 11 March 2021 (UTC)[reply]
      On the technical vs business-case aspect, I agree, that was much of the point I was trying to make. I also agree that a regular review of bot and automated editing tasks should be undertaken. There are some that I'm sure still have community consensus (e.g. the anti-vandal bots) but I can't say that will hold true for every task. I also agree that there must be an active consensus of editors that will be affected before a task goes ahead - in the case of monkbot almost all affected editors were entirely unaware that it was even proposed. Thryduulf (talk) 14:20, 11 March 2021 (UTC)[reply]
    • Option B - I can easily see both sides of this debate. As someone who works in IT, I fully agree that IT should serve the needs of users first wherever possible, rather than simply making life easier for the people who maintain the systems. I see far too many systems that make life harder than the non-digital alternative, which is just ridiculous. There are of course times when things need to be deprecated because they're either incompatible with other things, have security holes, or take up too much development time to maintain. This case is one of the latter, although I'm not sure what extra burden the deprecated (non-hyphenated) paramaters actually add. I would recommend that we formally deprecate the unhyphenated parameters and clean them up with AWB genfixes but I can't support continuing to run Monkbot 18 given the strength of feeling here against such a task. Personally I do not care about 'watchlist spam', but clearly many people do, and we cannot simply dismiss their opinion because "it'd make life easier for us techs". ƒirefly ( t · c ) 07:42, 10 March 2021 (UTC)[reply]
      As I understand it, there's a framework for supporting parameter aliases, which are configured in Module:Citation/CS1/Configuration. As there are many other aliases supported, the framework would remain in place. isaacl (talk) 15:23, 10 March 2021 (UTC)[reply]
    • Option A / B per above.  Spy-cicle💥  Talk? 18:50, 10 March 2021 (UTC)[reply]
    • Option A, strongly oppose Option C. Hyphens should be standard and we should discourage them. I do not mind continuing to support the non-hyphenated version per B, but B also implies the bot isn't free to do its job, so A it is. SportingFlyer T·C 12:57, 11 March 2021 (UTC)[reply]
      Why should one version over the other be discouraged? What benefit to the encyclopaedia does it bring that outweighs the disruption that removing support for a long-standing and well-used feature causes? Why should the bot be free to continue to do a job it didn't have consensus for? Thryduulf (talk) 14:22, 11 March 2021 (UTC)[reply]
      We're trying to gain consensus here, right? I support standardising the reference tags, and I don't think the opponents have good counter-arguments. I'd appreciate if you just let me (and others) have our opinions without the need for commenting - you're not "correct" and we're not "wrong." SportingFlyer T·C 15:01, 11 March 2021 (UTC)[reply]
      I'm not trying to stop people having opinions. I'm trying to get people to explain them and to actually counter arguments left explaining preferences different to their own. Why is standardising reference tags more important than the disruption standardisation causes? Why is a desire to avoid this disruption "not a good counter-argument"? I may or may not be "correct" but unless you can explain why forcing standardisation against the wishes of a very significant number of editors (who will not see any benefit from such standardisation but will experience significant ongoing disruption due to it) is somehow desirable then there is no hope of getting consensus for your views. Thryduulf (talk) 16:02, 11 March 2021 (UTC)[reply]
      You're chiding me for not countering your argument, even though your argument above is simply "I don't see the point." We've been working on this for awhile, it's been discussed on talk pages, it makes it easier to maintain the encyclopaedia, and it's a good idea to finish the project as opposed to having it held back by users who don't like it. I also thought I was just !voting here, I think this is obvious and I don't want to be drawn into a long argument about this, so not only did I not appreciate your response, I'd appreciate it if you left this conversation alone going forward. SportingFlyer T·C 16:49, 11 March 2021 (UTC)[reply]
      As with many of these types of questions, the conclusion each person draws depends a lot on the weighting they give on the relative priorities of different factors. We lay out our lines of reasoning with the tradeoffs, and others can use it as they wish to figure out what tradeoffs they would like to make. isaacl (talk) 17:13, 11 March 2021 (UTC)[reply]
    • Option C Unless there is an issue with bots having to read accessdate and access-date as the same thing (and there doesn't appear to be a problem from what has been described, as bots can do this) then I'm not convinced that forcing users who already write accessdate to make an error when they continue to do so after its use is stopped that bots will then flag up for humans to solve is going to be a useful thing to do. Creating a situation which is going to frustrate and demotivate volunteers for no valid reason other than "conformity" doesn't sound like a good plan. Indeed, it was stressed in the original 2014 RfC that "Establishing this uniform parameter name convention does not preclude the existence of any other alias for a parameter, merely that a lowercase, hyphenated version will exist for each parameter." And some of those supporting did so because: "This will significantly reduce editor confusion. They don't have to think about: "Is this the parameter where the words are mushed together, or is it one where they are separated by an '_' ?" Hopefully this will make the templates easier to use." - User:Makyen. What we should be looking at is making bots read the varying ways that users may write a word or phrase in a template. I hate it when, for example, I use a capital letter by mistake, and the template doesn't work, and I have to work out what the problem is. I don't follow how frustrating, demotivating and alienating volunteers by changing how a template works and so creating problems for them will "decrease the maintenance burden" on those users. It is sometimes things like functionality being changed, that drives users away. SilkTork (talk) 01:09, 12 March 2021 (UTC)[reply]
    • Option C. I haven't checked whether this move was done under a six-year old RFC with seven people, or under a seven-year old RFC with six people. But no one disputed that it was an at least six years old RFC involving at most seven people. Now, it seems that there are a large number of users who disagree. Perhaps telling them they "don't see the larger picture" will be enough to silence the dissenters. Maybe the "Visual Editor reception" will happen again. Who knows the future? Pldx1 (talk) 15:07, 12 March 2021 (UTC)[reply]
    • Option A. I do not see any real argument for why citation templates should be a mish-mash of two different parameter names. It's an eyesore, it's a pain in the ass, and it brings zero utility. There are a couple ways of fixing it: for the new parameter names to be integrated into every tool, and every adjacent task, and every automated editing tool, and then maybe in ten years 90% of them will be gone (but the remaining 10% will be scattered willy-nilly across the entire project and impossible to hunt down). Or we could just have there be one short run and be done with it. I, for one, would be glad for the issue to be concluded. jp×g 05:33, 15 March 2021 (UTC)[reply]
      Have you actually ready any of the comments left by others? There are at least half a dozen different reasons given for the utility of multiple forms of parameteres. Even if option A is selected, disruption will not be short term but will continue for years for the reasons explained multiple times elsewhere on this page. Thryduulf (talk) 12:27, 15 March 2021 (UTC)[reply]
    • Option A. Over time, we evolve different conventions. Once we have done so, we need to clean up the uses of the old conventions. Option B will be too slow and leave this issue dragging on for many more years. So, firstly ensure that all documentation is unambiguous about using only the new names. Secondly, make sure that all editing tools use only the correct parameter names and all genfix rules are up to date. Wait for the bot to complete a full pass and then treat the old parameter names as solid errors — GhostInTheMachine talk to me 15:36, 15 March 2021 (UTC)[reply]
    • Option C. The encyclopedia should be run for the benefit of readers, and subject to that, for the benefit of editors. Creating busywork and random conventions for the sake of it is not useful. Stifle (talk) 10:19, 16 March 2021 (UTC)[reply]
    • Comment: The argument made here and elsewhere about how much easier things would be for template- and module-writers under Option A, is a completely misguided and arrogant one. It seeks to benefit a small subgroup who are neither the consumers of the encyclopedia, nor its principal creators. Namely, it calls for optimizing ease of work and convenience for the very small number of template/module writers, rather than optimizing for (the much larger number of) article editors. The trade-off must benefit the largest number; if you make it harder for editors, then the article readers will suffer, and they are the largest group of all and the reason the encyclopedia exists. This should be axiomatic, but the encyclopedia isn't here for the convenience of template and module writers. Personally, I'm happy writing and improving templates and breaking my head against squirrely, confusing, and sometimes infuriating template problems, just to make things slightly easier for editors. If it's too inconvenient or too much work for template/module-writers, then they should abstain from "helping", and just improve article content, rather than seek to make their own lives easier. Mathglot (talk) 23:42, 20 March 2021 (UTC)[reply]
      Thryduulf said it better (and briefer) than I, here: "Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third." Precisely. Mathglot (talk) 00:04, 21 March 2021 (UTC)[reply]
    • Option C (preferred) or Option B (seoncd choice) -Beyond My Ken (talk) 03:06, 23 March 2021 (UTC)[reply]
    • Strongest possible option C Per WP:KISS and WP:IFITAINTBROKE. If it ain't broken, don't fix it, and don't waste our time with meaningless bot tasks. We should be making templates easy to use. Having different aliases for the same parameter is helpful. Insisting on one particular format because of some concept about what is correct and what is not is WP:CREEP, and generally to be discouraged. RandomCanadian (talk / contribs) 01:59, 24 March 2021 (UTC)[reply]
    • Option C. If we were starting today, and writing brand new template to handle citations, I would strongly advocate using one consistent format for parameter names. But we aren't. Many thousands of editors are used to using the no-hyphen versions of those parameters, and I see no reason to disrupt their editing lives in order to (allegedly) make life easier for a handful of template editors. The system we have now works fine, I see no reason at all to waste anybody's time changing it. Chuntuk (talk) 20:41, 30 March 2021 (UTC)[reply]
      • This argument, and those like it, would be more persuasive if dozens of unhyphenated multi-word parameters had not already been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama. We are talking here about removing the final six, which would make the whole parameter system consistent instead of the current situation, in which nearly all multi-word parameters are hyphen-only, and six have unhyphenated options. Option C proposes to halt seven years of work when it is about 90% complete. – Jonesey95 (talk) 01:59, 1 April 2021 (UTC)[reply]
        • Fait accompli actions, where actions are justified by virtue of being already carried out, and difficult to reverse, are inappropriate. If it's a concern that some parameters have unhyphenated aliases and others don't, let's allow unhyphenated options for all. Nikkimaria (talk) 02:20, 1 April 2021 (UTC)[reply]
          • There has been discussion at Help Talk:CS1 prior to the deprecation of each multiword parameter over the past seven years, and then further discussion at the same page prior to the removal of support for those parameters. Millions of page changes have been performed over those seven years to remove the deprecated parameters from pages in affected namespaces. Until this last round of edits by Monkbot, I have been unable to find significant objection to these edits. All of that is very different from a fait accompli: the actions are not justified by having been carried out, they are justified by being repeatedly discussed at the relevant talk page and documented accordingly. Again, the only difference between this parameter standardization work and that done for hundreds of other templates is the scale. – Jonesey95 (talk) 15:30, 1 April 2021 (UTC)[reply]
            • Funny you should mention scale. This is the first large-scale discussion I'm aware of on this topic; as already noted, there are far more participants supporting option C here than have supported deprecation in any previous discussion. This suggests that, to the extent that consensus for these deprecations could ever have been said to exist, it was an extremely limited one - certainly not one strong enough to support millions of changes. Nikkimaria (talk) 00:25, 2 April 2021 (UTC)[reply]
    • Option A. Having done a fair bit of work with CS1 templates, I support the option that ensures the greatest consistency and ease of use among articles. While inter-article consistency is indeed not fully realized, with various articles having different ways to write dates or citations, I think, at the very least, disabling |accessdate= in favor of |access-date=, et al., would make it easier to search of instances of strings without the need to use regular expressions or two separate searches to get everything. In addition, the line breaks in the editing window make things easier to look at. It's nothing too major, but I think ultimately that moving everything to the hyphenated formats will do us much more good in the long run. -BRAINULATOR9 (TALK) 19:18, 1 April 2021 (UTC)[reply]
    • Option A now that the tasks have got this far. Regardless of personal naming preferences, standardization is far preferable to the alternative of having to maintain and support multiple template options indefinitely, which is what it boils down to. MichaelMaggs (talk) 13:04, 2 April 2021 (UTC)[reply]
    • Option C, though I don't think the proposal is completely accurate as MonkBot has been removing accessdate which is not officially deprecated, which is a problem on its own. Based on this discussion and the CBD proposal, there clearly is not unanimous consensus that a) non-hyphenated parameters should be deprecated and b) that millions of cosmetic edits are fine, but somehow both were approved with no opposition. I get the impression that the bot approvals group (or whomever makes these decisions) does not accurately represent the wider community. For now, these decisions which do not have consensus should be revoked. -M.Nelson (talk) 10:02, 3 April 2021 (UTC)[reply]
    • Option A. Template and module maintainers do a lot of work behind the scenes to ensure the rest of us have a smooth experience as possible. This often requires vast amounts of code with many edge cases. This in turn, makes maintaining big modules harder and more difficult as times goes on. For the editor experience, having a consistent style on any article they edit is always a benefit. I've spent many times looking at templates, trying to figure out what the correct parameter should be because of the existence of parameter aliases. I'm sure newer editors that find it harder navigating template documentation find it even more frustrating. Removing this burden would benefit both groups of editors and maintainers. The downside of having a watchlist "spammed" is very minimal and has a page should only have one edit (by this bot), that means that a watcher will view it once. The amount of editors that watch many pages and will be annoyed by it is extremely minimal that it is frankly absured that it is even a consideration. --Gonnym (talk) 12:52, 3 April 2021 (UTC)[reply]

    Discussion (CS1)

    Some suggestions regarding the options:

    • Pedantry: "Non-hyphenated parameters" should read "Non-hyphenated multi-word parameters" in all three options. Parameters that contain only a single word or acronym do not need a hyphen.
    • In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already.

    Some history and a status update, for those here on VPP unfamiliar with the long history of updates and changes to the Citation Style 1 templates ({{cite web}} and its siblings): As far as I can tell, there are only six unhyphenated multi-word parameters left – |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= – out of an original population of many dozens. So far, through the work of scores of editors and bots over the seven years since we standardized on hyphenation of multi-word parameters, we have deprecated, removed from pages in affected namespaces, and then removed from the CS1 templates themselves (as WhatamIdoing suggests above), many dozens of different unhyphenated multi-word parameters in CS1/CS2 templates. All new multi-word parameters during that time have been introduced using only a hyphenated form. This RFC is essentially asking: should we finish the job, or leave it at over 90% done, in a sort of limbo state, with six parameters as exceptions to the overall pattern, just because those parameters are used in a lot of articles? – Jonesey95 (talk) 04:38, 11 February 2021 (UTC)[reply]

    • Problem with "Option B": Option B is not the status quo. If it were, I'd be much happier. Since it's not, I don't know whether to !vote for A or B. The documentation at Cite web, for example, makes no mention of accessdate being deprecated. This means that users will be quite justified in blissfully adding and readding templates with accessdate, even after the bot has come through already and changed accessdate to access-date in 20 places. Each iteration tends to address fewer instances, but each run is a separate entry in my watchlist. Watchlist entries seem to be part of the complaint against this kind of work, so the first step should be turning off the faucet at the source, before spending energy to, um, bail out the boat. — JohnFromPinckney (talk) 06:37, 11 February 2021 (UTC)[reply]
      • The first sentence is true; all but six of the unhyphenated multi-word parameters have been formally deprecated and removed. As for "turning off the faucet at the source", that would be Option A, but in the past, when we have made red error messages appear in large numbers of articles as a first step in standardizing the citation templates and noting errors in them, there has been significant pushback. In order to avoid that pushback, the bot was acting to fix 90+% of the non-standard parameters before turning on the error messages, but that work has been stopped as well. Option A will allow that work to be completed. – Jonesey95 (talk) 15:09, 11 February 2021 (UTC)[reply]
        • I feel we are not understanding each other. "Deprecation" involves communication as a first step; removal is a second, later step. If we are going to have a bot changing pages (e.g., accessdate to access-date), causing some distress to the populace (and this is the status quo), then we should at least change the documentation to say that accessdate is deprecated, and is not a usable alias. I am strongly against a bot going around to change parameters to the "good" names when we don't ever tell the humans they shouldn't use the "bad" ones. That's just an endless cycle of watchlist-cluttering edits causing great irritation. If you want to avoid pushback, tell the people not to use the unhyphenated versions, then run the bot, then remove support some time later. — JohnFromPinckney (talk) 15:41, 11 February 2021 (UTC)[reply]
          • Deprecate in terms of the CS1 templates means to emit a red error message indicating deprecation. When we emit any red error messages for parameters in CS1 that are used often (or lack thereof for parameters that should be used more often), a lot of people get very irate. We do not change the documentation to indicate deprecation until after the module begins telling people inline about deprecation. So yes, you are not understanding each other, but it's a question of terms of art. --Izno (talk) 16:44, 11 February 2021 (UTC)[reply]
            • Why do people get irate? Because suddenly millions of readers go from nothing being wrong to seeing a load of red error messages all over hundreds of thousands of articles (and you couldn't seriously expect someone to debug a CS1 error as their first contribution). These citation templates aren't for us. They're for the reader and they need to be functional with low rate of error messaging 24/7 with no exception, because even small amounts of downtime have significant reputational damage. — Bilorv (talk) 02:54, 15 February 2021 (UTC)[reply]
        • That "we" (who is that, some class of super-techies whose opinions count for much more than those of us "normal" editors?) get significant pushback when creating error messages is simply a demonstration that the wider community does not agree with what "we" have decided. The answer is to stop doing what you are doing, not to do it more stealthily. Phil Bridger (talk) 18:37, 11 February 2021 (UTC)[reply]
          • You are welcome to participate at Help talk:CS1, the same as any other editor. Decisions are made by consensus there, inline with how consensus is practiced everywhere else on wiki. Don't like a decision "we" made? Get involved. --Izno (talk) 18:42, 11 February 2021 (UTC)[reply]
            • I saw absolutely no discussion of the removal of the freetext editors field on the talk page. Where did that happen? I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)[reply]
              • The difference is between those people who think this is an encyclopedia and those who think that it's a playground for techies. Phil Bridger (talk) 20:43, 11 February 2021 (UTC)[reply]
                • Your ad hominem has no welcome here. Move along if that's the best you can offer to the discussion. --Izno (talk) 20:47, 11 February 2021 (UTC)[reply]
                  • That is just the kind of reply that people who are here to create an encyclopedia tend to get from the techies. No response to genuine concerns but just an order to "move along". I have no wish to monitor whatever pages are used to ignore end users, but I have a right to expect that any decisions taken will respect the interests of everyone, not just a self-appointed clique of people who "know" what is right. Phil Bridger (talk) 19:53, 15 February 2021 (UTC)[reply]
                    • It's the kind of reply to people who needlessly create category A and category B and then line themselves up in one or the other categories. If you (specific/personal) don't want to monitor whatever pages, that's your prerogative. Do know that it is your choice and you are responsible for that choice, and choices have consequences. Changes are always announced ahead of time and consensus is sought for non-obvious changes (and even obvious changes with non-obvious implementations), so you have no excuse not to tune in at least once every couple months when the regular "Shit is Changing" post gets made. Secondarily, the scare quotes are not indicated by this discussion, nor any prior discussion that I can see, whatsoever. I have not seen any such 'clique' nor any of the users who would prospectively be in such a 'clique' claim they "know" what is right. As I said, if you have nothing to contribute but smears and attacks and divisiveness, move on. --Izno (talk) 20:22, 15 February 2021 (UTC)[reply]
              • In reverse chronological order: the patch notes indicating removal, the removal discussion, the patch notes indicating deprecation, the deprecation discussion. 4 times mentioned over a period of half a year on that talk page, a pre-existing maintenance category indicating a soft deprecation, and my removal of over 4k instances of the parameter over the year and a half preceding that deprecation discussion. Basically by hand (my hand, as it happens). --Izno (talk) 20:45, 11 February 2021 (UTC)[reply]
              • As for I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all., I invite you the same as I invited Phil Bridger. You may watch and edit Help talk:CS1 at any time, the same as me. "I don't recognize these people" is a trash association to make and is the same kind of ad hominem that I have asked Phil so kindly to stop employing. It is certainly not sufficient cause to say "I don't like this change". --Izno (talk) 20:49, 11 February 2021 (UTC)[reply]
                • I think there's a genuine problem here that there's a disconnect between the editors maintaining the citation templates and the editors employing them to write and maintain articles. I didn't make the decision to abandon years of using citation templates (CS2 actually, but the same parameter changes are happening there too, even less announced) lightly. Espresso Addict (talk) 21:35, 11 February 2021 (UTC)[reply]
                  The disconnect is real and significant. Someone whose skills and interest lie in writing or maintaining article content shouldn't need to care about what happens at pages like Help talk:CS1 (and how on earth is a new editor even meant to know that page exists?), let alone have to pay attention to discussions there. Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third. The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. We've ended up here because that hasn't been happening and a local consensus has ignored the needs of end users. Thryduulf (talk) 01:38, 12 February 2021 (UTC)[reply]
                  I almost commented last night, and then put that version into a text file and went to bed. Now I have been spurred by a comment above to reply here. The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. If we prioritize different qualities versus this other supposed separate group, it's because we have the experience to do so. If you don't, let me reiterate, get involved. Come and say "I don't like this" or "this is a painful interaction" or X, Y, and Z, and provide a suggested fix. That's how consensus starts forming, like every other page or process on this website. Others will say "I don't want this to work like that suggested fix because A, B, and C". Then you discuss the tradeoffs and make a decision. If you're unwilling to step up and discuss the paper cuts, then we end up having mass RFCs or AN drama or what have you over what would otherwise be small issues or ones that could have been discussed informally with the ordinary "let's figure it out" consensus view of the world. That's a disconnect too, and blaming editors interested in one page versus those apparently disinterested is not the right way to move forward. Want something to be better? Ask. Propose. Cajole. Make the effort to put forth the minorest of social interactions required to start a discussion in the one place where everything about that thing is discussed. We're all volunteers and our heart is in just a right a place as yours, but if we should have disagreements, then we talk to each other and find out how to fix the problem or agree to disagree on the points of interest. Not have constant complaints of "they didn't listen to me". Consensus is not unanimity.
                  The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. This is quite frankly an opinion lacking any community consensus whatsoever. We've recently approved an RFC allowing cosmetic edits on a regular basis and from what I could see in that discussion (and murmurings elsewhere), cosmetic edits might be closer to having consensus than not, it's just inertia that leaves us not performing them regularly. Moreover, hundreds of templates, and certainly all those which go through WP:TFD, have a process applied which causes breaking changes or which results in more-or-less cosmetic edits. Are you claiming that TFD does not have consensus as a process? That templates which are being cleaned up because of a talk page discussion on that template's talk page should be stopped? You want your cake (to not care about how things work) and eat it too (have all of your opinions and claims listened to, when they aren't even articulated in the first place). Get real. --Izno (talk) 20:22, 15 February 2021 (UTC)[reply]
                  I fear this just demonstrates the truth of what Thryduulf writes. "The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head." is self-evidently false, as well as impolite. Speaking only for myself, what I actually want is to be able to get on with writing & improving articles, rather than having long side discussions on matters that aren't directly relevant. Espresso Addict (talk) 00:10, 16 February 2021 (UTC)[reply]
                  get on with writing & improving articles Then do that. No-one is stopping you from not caring. I am just calling you hypocritical for raising a fuss when you don't and then changes happen elsewhere that affect you. Don't like it? Change your behavior. (I won't reply to you again.) --Izno (talk) 00:34, 16 February 2021 (UTC)[reply]
                  The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. Both uncivil and not even close to correct. While it is possible that some, maybe even many, of the editors maintaining templates also write and maintain articles there are literally hundreds of editors writing and maintaining articles who have never been near a discussion about the template code, let alone written any code. Writing encyclopaedic prose and writing computer code are very different skills; nobody is or should be required to do both. However given that the purpose of this project is to write an encyclopaedia everything that is not writing an encyclopaedia should be done for the benefit of (first and foremost) readers of the encyclopaedia and (secondly) those who write and maintain the encyclopaedia. The convenience of those dealing with tools is least important. Thryduulf (talk) 00:23, 16 February 2021 (UTC)[reply]
                  Writing encyclopaedic prose and writing computer code is a false dichotomy and a blatant misrepresentation of what the two paragraphs I had to say. I did not ask you to do both. Nor do I serve you (general) in your supposed role as an article writer. There are no (formal) hierarchies on this encyclopedia, and even considering yourself as supposedly above me or my efforts is the actual uncivil statement. Lastly, I place myself fully in both supposed groups given the thousands of articles where I have bettered their citations. (And as I said to Espresso, I will not reply in this section again.) --Izno (talk) 00:34, 16 February 2021 (UTC)[reply]
                  My role here is not as an article writer (I do very little of that), I spend the majority of my time on the project trying to ensure that readers can find the content they are looking for and those that do write and improve articles without needing to worry about nonsense like this that will needlessly make their job harder. There might not be a formal hierarchy but their should be: (1) Readers are head-and-shoulders above anyone else. (2) Those who write and maintain the encyclopaedia a short way above (3) Those who support those write and maintain the encyclopaedia are a long way above (4) Those who hinder any of the above. I place myself in the third category alongside many of those who maintain templates. Thryduulf (talk) 21:02, 16 February 2021 (UTC)[reply]
    • Comment. What is the merit of citation templates? Let alone the increasing creep to make them more and more rigid and harder and harder to use? The only reason I can see is to make it easier to export and sell data. No-one ever seems to give a thought to those who type citations manually; it is far harder to type "access-date" (which requires two hands and a hand movement) than "accessdate" (one hand, no move). I don't understand what the benefit of this change is at all. In fact, broadening this discussion, I don't understand why the freetext editors field was suddenly withdrawn this January. Personally I've decided to meet the latter change by reverting to writing out references by hand, which is easier, more flexible, and seems to have no downsides. Espresso Addict (talk) 07:04, 11 February 2021 (UTC)[reply]
      • Citation templates make standardizing citation style and look much easier. They can, for example, automatically standardize date display. Machine-readability is also a good thing, imo. I suppose access-date is slightly harder to type - but editors editing wikitext manually would probably not mind. Otherwise, tools for inserting these citations exist. Elliot321 (talk | contribs) 17:12, 11 February 2021 (UTC)[reply]
        • It's not slightly harder to type, it's a great deal harder to type for a touch typist. And here's an editor editing wikitext manually who does mind, enough to bother responding here. There's no tool I know of that creates citation template code in the form I prefer for ease of wikitext editing afterwards; they all make code soup that takes longer to fix than retype. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)[reply]
          A bit slower, yes, but I personally don't find it a great deal harder—touch typists generally have practised it a lot while learning. Nonetheless, I don't think ease of typing by some metric is the primary issue. isaacl (talk) 20:40, 11 February 2021 (UTC)[reply]
          Speaking as one of those touch-typists, and as a person who learned to type on an actual typewriter, I don't find the hyphenated version any harder to type, and I do recall my typing teacher saying that it was faster and easier to type words that were split evenly between hands, instead of all in one hand. WhatamIdoing (talk) 22:49, 11 February 2021 (UTC)[reply]
          Yeah, personally I imagine it has a greater effect for a hunt-and-peck typist. When I said a bit slower, I was thinking compared with a word of equal length that consisted only of letters. Of course, in this case, the hyphenated name has one more character which would comprise most of the difference for me. isaacl (talk) 23:02, 11 February 2021 (UTC)[reply]
          For me, not an issue on a regular keyboard, but a bit of a pain on a tablet. Then again, so much is a bit of a pain on a tablet... · · · Peter Southwood (talk): 05:39, 2 March 2021 (UTC)[reply]
        • I use citation templates myself, but I respect the wishes of those who prefer not to use them. It is precisely the fact that I use them that leads me to the opinion that obvious synonyms for parameters should not be removed, as proposed here. What on Earth is the problem with allowing both hyphenated or unhyphenated forms? All it means is a few extra bytes of storage, and no extra code if it is done properly. And the work has already been done, but this proposal is to undo it. Do we still live in the days when I started in IT working for one of the world's leading business information companies whose UK operations were all run from a computer with 1MB of memory and where all online programs were limited to 12KB? I thought we had moved on from there. Phil Bridger (talk) 20:34, 11 February 2021 (UTC)[reply]
          I am reminded of a story about a lady, who (decades ago) bought a large supply of personalized stationery and then discovered that the post office was renaming her street. She convinced the local postmaster into letting her continue to use the old address until her stationery was used up. This saved her some money and effort, but it had external costs. For many years to come, every mail carrier had to learn that "123 Main Street" wasn't on Main Street and wasn't number 123, but instead had to be delivered to the other side of town.
          Aliases are often low-cost in storage and computational terms, but they are not actually free. "Not free" can add up to a quite significant cost when it is repeated a million times. WhatamIdoing (talk) 22:56, 11 February 2021 (UTC)[reply]
    • Although I sympathize with the desire for all templates to align with one standard (from a user's perspective, I would personally find it easier), I just don't think it's feasible at this point in time. In which case, I sympathize with those who think computers should make our lives easier, and just accept both formats. On the third hand, from an implementer's perspective, I appreciate that it adds a lot of noise to template syntax, if not implemented with a Lua module. Since the CS1-based templates are implemented with Lua, the overhead can be minimized, and so I think both formats should continue to be supported. I don't feel there is much advantage to converting en masse, by any mechanism. isaacl (talk) 20:40, 11 February 2021 (UTC)[reply]
    • Pinging some previous participants in related conversations who may not yet be aware of this discussion: @SandyGeorgia, Jason Quinn, Oknazevad, Tom.Reding, Brainulator, DavidBrooks, SMcCandlish, David Eppstein, Matthiaspaul, Headbomb, Gracefool, Ss112, JG66, Mikeblas, Gonzo fan2007, Sariel Xilo, Modest Genius, and SlimVirgin:. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)[reply]
      Thanks for the ping, I was indeed unaware of this discussion. Modest Genius talk 12:16, 12 February 2021 (UTC)[reply]
    • Does anyone have any evidence that having alias for parameters makes things harder for end users? In my experience as a trainer and long-time user, having multiple ways to achieve the same ends allows editors to spend their time and energy working on content rather than puzzling over making sure that the template parameters are named in exactly the right way. I've never met anybody who was comfortable enough to be dealing with templates in the first place who was not completely comfortable with the idea that "you can write it as either access-date or accessdate, it doesn't make a difference." (or similar). Speaking personally, I don't want to have to learn whether it is "accessdate", "access-date", "access_date" or "access date", I just want them all to be accepted so that whichever I input the template works and I can worry about more important things. Thryduulf (talk) 01:29, 12 February 2021 (UTC)[reply]
      The inconsistency across all templates does make things harder. Users have to either remember which templates only support one form and which one, or look it up each time. I appreciate though that there is extra complexity in trying to support lots of aliases, particularly for ones that aren't implemented with a Lua module (either each use is going to become more elaborate and verbose, or the template could delegate the detailed implementation to a helper template, with the top-level one only doing parameter normalization), so personally I wouldn't want to require that every template must support aliasing. Thus I think we're kind of stuck with inconsistency. isaacl (talk) 02:12, 12 February 2021 (UTC)[reply]
      This inconsistency should be tolerated. Some, particularly high-use, templates having aliases is important for the great number of people who use these templates. They don't have to remember was it |access-date= or |accessdate=. If it doesn't work on some other template, well fine. But eliminating aliases and simply making the computer say no on all templates makes things a lot harder for the vast majority of users. That inconvenience is far greater than the fact that a few lesser-used templates don't support aliases and you might need to take a look at the documentation sometimes. – Finnusertop (talk ⋅ contribs) 06:05, 12 February 2021 (UTC)[reply]
      Yes, as I said in another comment, I feel both forms should continue to be supported for the CS1-based templates. I'm pretty sure the vast majority of templates don't support both hyphenated and non-hyphenated parameters—for example, from what I can tell from the code and a quick test, {{Infobox}} doesn't. That's just the way it goes when trying to make as many aspects of Wikipedia markup accessible to as many editors as possible: standardization won't always happen, and often simpler markup will be preferred by more editors than more complex markup, even if it would add more functionality for users. isaacl (talk) 22:22, 12 February 2021 (UTC)[reply]
    • In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already. This argument directly goes against WP:FAITACCOMPLI. Also, stop referring to them as "depreciated" - it is clear that there was insufficient consensus to declare them depreciated in the first place. I can understand that it's frustrating to have something you thought was decided fall apart like this, but it is extremely important that sweeping changes get more discussion before being implemented; the only way we can reasonably encourage that is by refusing to allow things like Monkbot's use here to determine policy, ie. it is necessary to make the work it did moot, or people will have a constant incentive to take the easy route and avoid bothering with time-consuming, often-frustrating, and unpredictable (but necessary) discussions before a change of this magnitude. That means, yes, allowing and even encouraging people to resume using non-hyphenated parameters even though you thought you were finally done with them; if you want to avoid that happening next time, seek larger-scale discussions first before making large-scale changes to avoid unexpected blowback if it turns out you don't have the consensus you thought you did. No matter how well-intentioned this was, we absolutely cannot risk rewarding the use of a tool to make a wide-spread change without sufficient consensus - which means, yes, as painful as it is, very deliberately taking the wrench to the kneecaps of the intended improvement this change was meant to establish, and intentionally ruining it even after the "cost' has been paid. It's not ideal, but it shows why it's so important to have broad discussions involving many users before making wide-spread changes; having policy effectively set by bots performing mass edits and establishing things as fait accompli is just not acceptable. I can sympathize with the amount of work that went into this that will be wasted as a result, but reaching a clear, unequivocal consensus involving a large number of editors should have been the first step for something of this magnitude, so you wouldn't suddenly run headlong into an RFC like this and find the consensus wasn't what you thought it was. --Aquillion (talk) 10:07, 4 March 2021 (UTC)[reply]

    Arbitrary break 1

    • Thanks to Nikkimaria for the ping based on my earlier involvement. I'm appallingly neutral (or torn) on the main topic but I earlier did some analysis that gives me concern about impacts on Template space in particular, if deprecation goes ahead fully. Here I'll use |authorlink= as a proxy for all six, because I personally type it more often. There are three areas that concern me: templates that indirectly invoke CS1, those that transclude CS1-invoking templates, and clones. I'm concerned about where and when red error messages appear, and documentation, in which I include both /doc and TemplateData.
    1. There are many CS1-friendly templates that invoke one of the canonical templates; {{Cite encyclopedia}} is often used for example. Some use parameter rewriting, converting |authorlink= to |author-link= before passing it on.
      1. Does their documentation always give precedence to |author-link=? I think we caught them all during the earlier discussion, but I can't guarantee the quality of the search.
      2. Because the CS1 code never sees the deprecated parameter, should this template emit a red error itself during the substitution? Or maybe just forget about the mapping and have CS1 do it? And how hard is it to find templates with the parameter substitution code?
      3. If |authorlink= ever moves from deprecated to invalid, then all those mappings and documentation need to be trimmed in one fell swoop. Well, I guess the mappings can stay in place although they could trip up inattentive longtime users.
    2. There are templates that simply transclude a pre-filled CS1-style template: for example embedding {{Cite book}} as a citation to a specific volume that is relevant to any use of this template. Have they all been fixed? If not, their user will see a red error message (correct?) that has nothing to do with their own usage.
    3. There may be templates that are modeled on CS1 but roll their own expansion, although I don't know of any such. If they happen to use |authorlink=, should they also be brought in line?
    Two final comments: there are more than six, if you consider variants like |author1link= and |authorlink1=. And in principle the arguments above apply to any page outside Template space that gets transcluded by someone, although I know that feature is rarely used. David Brooks (talk) 16:51, 12 February 2021 (UTC)[reply]
    Shoulda said: the above applies to A and to some extent B but you can probably figure that out. David Brooks (talk) 16:57, 12 February 2021 (UTC)[reply]
    DavidBrooks: There is a tiny army of editors at the ready to fix these templates. As far as I know, there are no transcludable templates that pass |authorlink=, your example, to any CS1 templates, so using those templates would not generate an error message. |accessdate= and the two or three remaining unhyphenated parameters being passed from template transclusions to CS1 templates were being processed by the bot before the bot was paused to hold this discussion. Once this discussion is closed, the bot will be able to resume that work, with human assistance, if the closure is a reasonable one. – Jonesey95 (talk) 17:13, 21 February 2021 (UTC)[reply]
    @Jonesey95: I just addressed a related issue in Help talk:Citation Style 1, where by modifying the example given I found 3 templates that use |authorlink= in a CS1-style template that's used to reference a specific source: {{Barmakids family tree}}, {{Citeer web}}, {{Alox2}}. But this less restrictive query shows a few more (ignore the "DYK" archive, I think). Not sure if you meant this type of usage in your comment; I may be missing the context. David Brooks (talk) 05:05, 22 February 2021 (UTC)[reply]
    @Jonesey95: OK, looks like you fixed {{Alox2}}. {{Barmakids family tree}} and {{Citeer web}} still need to be fixed (I'll do them later today). The documentation of "Cite book (short)" in {{Quicktemplates}} lists the not-incorrect |authorlink=, so that comes under the "prefer the hyphen forms in documentation" rule. I didn't look for |authorlink2= or |author2link= because they are unlikely to appear alone. David Brooks (talk) 19:17, 22 February 2021 (UTC) ... checkY, also {{Bach's compositions (sources)}}, which indeed had |author2link =. David Brooks (talk) 21:42, 22 February 2021 (UTC)[reply]
    • I would like to clarify what I meant when I originally wrote the options, since there is some confusion. My intention with "removal" was to refer only to removal of usage of nonhyphenated parameters by transclusions of the template, not removal from the implementation of the template itself (I will call this "disabling the parameter"). This is also distinct from deprecation, which is designating something in documentation and warning messages as discouraged. Remember that the original reason for this RfC is to clarify whether we should have a bot going through the article space removing the parameter usage as its sole action. A, B, and C are respectively continue removing now, remove only as part of other non-cosmetic edits or in a situation where cosmetic-only edits are allowed, or do not remove. In case of A or B, I did not intend for them to make a statement about whether we should disable the parameter when this is done. This is an important question, but orthogonal to whether the parameter usage is removed now or later. — The Earwig alt ⟨talk⟩ 22:11, 13 February 2021 (UTC)[reply]
      Thanks for clarifying (except the part where you formulated the options). Unfortunately, it now means I'm missing the option: Non-hyphenated parameters should be deprecated now and removed later. The actual status quo seems to be: Non-hyphenated parameters should be removed now and deprecated later, and the removal can occur by bot which does nothing else on the page (cosmetic only), but will revisit the page as often as necessary to re-remove the non-deprecated params that keep getting added. — JohnFromPinckney (talk) 23:01, 13 February 2021 (UTC)[reply]
      For context, this is how I originally phrased it; note B and C are swapped. Isn’t what you’re desiring exactly option B (in the current formulation)? It seems describing B as the "status quo" is confusing. Instead, view A as what the bot was doing before it was stopped, and B as what is currently happening with the bot stopped, but with clear, formal deprecation. — The Earwig alt ⟨talk⟩ 00:19, 14 February 2021 (UTC)[reply]
      Mmm, maybe, and in any case I'm very grateful for your link to the pre-RfC coordination at Primefac's Talk. And I can say that your original formulation was clearer than the formulation we're now using for the RfC proper. However:
      1. There appears to be no consensus for the removal of non-hyphenated multiword parameters. The 2014 RfC determined only that the hyphenated version must exist, and the close explicitly allowed for non-hyphenates.
      2. If this RfC is intended to determine whether non-hyphenates should be deprecated, it's poorly formulated to the extent that it mentions the current bot activities.
      3. I can't view Option A as what the bot was doing before it was stopped, because the parameter has not been deprecated. (The statement by Nikkimaria that deprecation "in the context of CS1/CS2" means a red maintenance message will be shown is not something I can accept, as any reasonable software provider knows that advance notice is the first part of deprecation. Unfortunately, I don't usually work "in the context of CS1/CS2", so haven't argued before against this unhappy definition.)
      4. Option B, as written on this page, is a garbled mess, not only because of the "status quo" mention, but also because of the "Deprecation can be bundled into genfixes..." bit. Deprecation, as above, is (first) a documentation task, followed by a (presumably small) step to cause red messages to be generated (I'm not sure what's involved here). I don't see what would need to be "bundled into genfixes". I had the feeling that many !voting here saw "removal" as meaning elimination of usages, but maybe that's due to my own confusion. Your Option C (and your original formulations in general) were much clearer.
      There should never have been any bot activities, because (a) there's no consensus, yet, to deprecate non-hyphenates, (b) the params are not yet deprecated, and (c) the bots' edits have been largely accessdate => access-date only, so violate WP:COSMETICBOT. So I guess I'll be !voting for B, although I'd much rather choose your original Option C. This RfC as written has been too unclear (at least for me). — JohnFromPinckney (talk) 11:20, 14 February 2021 (UTC)[reply]
      Re The 2014 RfC determined only that the hyphenated version must exist: As called out in the proposal, it also said The documentation is to show this lowercase, hyphenated version as the one for "normal use". Hence my comment above: some of us recently tweaked the documentation of a few high-use templates to make the hyphenated version the privileged one, but I can't guarantee we got both /doc and TemplateData for every template that indirectly uses CS1/2. If we end up with both hyphen and no-hyphen equally valid (is that C?), then tweaking the documentation will be the only change visible to current editors. SHould there be a more valiant effort to track them all down? David Brooks (talk) 19:45, 14 February 2021 (UTC)[reply]
      If the consensus is for Option C, then nobody has to track down anything; we can leave the documentation as it is. BTW, the claim written there, This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters is another red herring and would, it seems, not apply at all (as accessdate isn't even listed there yet).
      If we chose Options A or B, then yes, the documentation should be immediately changed. I can't believe it will take too much valor to find the Template:Cite web documentation, as it doesn't seem terrible exotic, but it should be included in the tweaking in those cases. — JohnFromPinckney (talk) 20:07, 14 February 2021 (UTC)[reply]
      • The 2014 RFC had a participation of only seven people and was six or seven years ago. It is patiently absurd to update documentation with such a sweeping change based on that alone, and any such changes ought to be reverted pending the outcome of a more clear RFC. Furthermore, the 2014 RFC specifically indicated that nothing would be depreciated, so if you are relying on it as a justification for any changes then obviously no non-hyphenated versions can be depreciated until / unless a new RFC overturns it. --Aquillion (talk) 22:19, 15 February 2021 (UTC)[reply]
      Please read the summary at the top of this Discussion section. Here's the summary of that summary: Dozens of unhyphenated multi-word parameters have been deprecated, removed from pages, and then removed from the Citation Style 1 templates over the last seven years. There are only six left. During those seven years, many new, hyphenated multi-word parameters have been introduced, without unhyphenated aliases. At present, the situation is that unhyphenated multi-word parameters are the standard, and there is just a bit more work to do to remove the final six outliers. Unfortunately, it appears that many editors have not enabled the useful settings "Expand watchlist to show all changes, not just the most recent" and "Group changes by page in recent changes and watchlist" so that bot edits can be hidden without losing visibility of bad human edits, so people are complaining about a bot "clogging" their watchlists. – Jonesey95 (talk) 23:59, 15 February 2021 (UTC)[reply]
      None of that is however relevant to Aquillion's comment in the slightest. That a flimsy consensus (at best) has been used to justify removing functionality in the past does not mean that that removal was a good thing or that the bot edits (which clog both watchlists and page histories with unnecessary edits, whether they hide other edits or not) should continue. Indeed, I strongly suspect there would be support for re-enabling the parameters already removed. Thryduulf (talk) 00:27, 16 February 2021 (UTC)[reply]

    Please note, folks, that this bot is a one-off; it may be processing some 2 or 3 million pages, but it's still a one-off, that is (unless reverted) it will only ever appear ONCE in any article history. So the idea that it's "clogging up" page histories is a big red herring. If you're bothered about it "clogging up" your watchlist, then please set the options recommended by Jonesey95 and others. So that objection falls by the wayside too. Please also note that this bot finishes the job. Once it's done, that's it – no more bots making this sort of change. To the charge that this bot is "disruptive" or that it's somehow "removing functionality", I can't do better than copy Rexx's observation above: "Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is." --NSH001 (talk) 19:30, 21 February 2021 (UTC)[reply]

    Except that, no, that's completely inaccurate. Consider List of University of Pennsylvania people. When I look at the last 500 edits just now, I see that Monkbot has been there SEVEN times: here (21:07, 19 October 2020) and here (01:02, 28 December 2020) and here (17:21, 14 January 2021) and here (21:21, 16 January 2021) and here (01:53, 18 January 2021) and here (15:30, 18 January 2021) and here (20:54, 30 January 2021). While that first edit (from October) did nothing with |accessdate=, the others all did, as often as it found new additions to the article. Note that the fifth and sixth edits both occurred on the same day.
    I don't ordinarily block bot edits from my watchlist because I want to know what's going on with "my" articles, and the bots generally do useful and interesting work. It's just that the (to me) sudden and unforeseen flurry of multitudinous edits (doing, it appears, nothing which really interests me) was quite irritating. The repetition on List of University of Pennsylvania people really got my blood pressure up, and that's not far off from "disruptive" to me. — JohnFromPinckney (talk) 21:15, 21 February 2021 (UTC)[reply]
    Hmm... The October edit is Monkbot 17 (not 18), so doesn't fall into the scope of this RfC. The edit on 28 December is the main application of this bot. That leaves 5 (mostly quite small) unexpected additional edits by the bot. They are all caused by editors adding parms that don't conform to the canonical standard. So yes, I should have qualified my statement by allowing for that possibility, sorry for that. Understandable that this should happen in the absence of a clear deprecation (so far) of the unhyphenated form. Perhaps the editors concerned are using some cite-generating tool that doesn't generate the canonical form, in which case the tool should be updated. Whatever, that strengthens the case for deprecating the non-canonical forms ASAP, and for moving forward as fast as possible with the main task. It's late now, and I will be going to bed shortly. Will comment on Phil Bidger's intemperate remark below in the morning. --NSH001 (talk) 00:06, 22 February 2021 (UTC)[reply]
    Naw, the editor concerned is/was just copying/pasting whatever they found in whatever articles they were looking at. (The user also hasn't learned that refs go after punctuation, or that a named ref copied from another article might not be declared on the target page, or that Wikipedia has a Preview function to allow checking for errors. Not that I'm bitter.) Agreed, without actual deprecation, nobody knows what they're supposed to use or not use, so watchlists get plagued with unnecessary repetition. And I can't point such a user to the deprecation or consensus not to use the non-hyphenated forms, because there aren't any yet. — JohnFromPinckney (talk) 00:21, 22 February 2021 (UTC)[reply]
    Thanks for that. If it is the case that editors on that page are simply copy-pasting cites from the original wiki bios, then that's good news – the problem will go away if the bot is simply allowed to continue and fix the problem in the source articles. I don't think it's true that there is no consensus for this change: the desired style was settled in an RfC several years ago, and has been 90% implemented in the years since, with no substantial objection. So there is an effective consensus, and it makes no sense not to carry the task through to its logical conclusion. The objections here amount to a dislike of large numbers of bot edits appearing on watchlists, not on the actual merits of the case. --NSH001 (talk) 07:34, 22 February 2021 (UTC)[reply]
    The RfC in question only had seven supports, and only concerned making sure a hyphenated version existed and was presented first in the documentation. I don't know how that could be read as effective consensus for deprecating a parameter that, prior to the bot run, seems to have been more commonly used than the hyphenated variant - and even if it could, it would be a limited one. The objection to the bot is not just that it edits a lot, but that it "fixes" something that isn't a problem. Nikkimaria (talk) 14:01, 22 February 2021 (UTC)[reply]
    Exactly this. — JohnFromPinckney (talk) 02:05, 23 February 2021 (UTC)[reply]
    Nikkimaria, the first fallacy in your argument is that you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. That isn't (quite) the case – I'm pretty sure that, out of the various choices available for multi-word parameters (runon, camelCase, under_score, hyphenation, etc), hyphenation would still be chosen, simply because it is the easiest to read in wikitext. Possibly underscore might be better (it won't line-wrap) but most people, apart perhaps from those with a programming background, will be much more comfortable with the hyphen, so that RfC came to a very sensible conclusion. The detail of its implementation is another matter, though. The second fallacy in your argument concerns the reason for the objection to the bot. Firstly, the observable fact is that some editors are now kicking up a huge time-wasting fuss about this bot, but said nothing about the many other bot runs for all the other CS1/2 parameters doing exactly the same thing. Secondly, and I see this repeatedly in other RfCs as well, that editors tend to focus solely on a perceived short-term problem, without taking account of the bigger picture and the wider context. That context has already been well described in the introduction to this RfC, and in the links given there. It's astonishing to me that people don't see that that the whole point of this work is to make the citation templates simpler and easier to use. Part of that process is to make the parameter names more meaningful and consistent. It's ridiculous to leave the mess inherited from the early days of citation templates, with these few remaining parameters sticking out like sore thumbs. --NSH001 (talk) 08:25, 25 February 2021 (UTC)[reply]
    Please explain how allowing e.g. "accessdate" is less meaningful, is less simple, is harder to use for regular editors. That is the bigger picture, the wider coontext: the benefits are actually only for a small group of people, who have every right to present their case and ask if their life can be made easier, but should not be astonished when it turns out that in some cases, their preferred solution is not supported by the larger group of people who don't do (or not as regularly) the template and bot stuff. Putting error messages on thousands of pages for things which are not an error but something which a few people decided is no longer allowed at all is losing sight of the bigger picture as well. Fram (talk) 09:24, 25 February 2021 (UTC)[reply]
    you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. I don't know that, and neither do you, because the wider community was never consulted. We can be reasonably sure that the discussion would have been far less one-sided, based on subsequent commentary. As to the second half of your point, as Fram notes, it's not at all clear why deprecating widely-used aliases would make the templates easier to use for the average editor. Nikkimaria (talk) 13:33, 25 February 2021 (UTC)[reply]
    (replying to both). Yes, that's easy. There's a very simple rule for all the CS1/2 citation templates: all multi-word parameters use a hyphen to separate the words. That's it. Dead easy to remember. Moreover, it's already implemented for the vast majority of the parameters (only 5 are left to do). I don't buy the argument that having to type ONE extra character is an insufferable burden. The only valid objection I can see is that the bot may flood watchlists, but that is temporary until the bot run is finished. So my sympathies to those who feel irritated (I don't – I have over 6,000 pages on my watchlist, and bot spam doesn't bother me), but the irritation will be temporary. If it really does bother you, others have mentioned a way to configure your watchlist to avoid the problem. --NSH001 (talk) 07:35, 8 March 2021 (UTC)[reply]
    I'm glad you personally are not irritated by this change - but others are, and others have explained why hiding the problem is not solving it. No one is proposing removing the hyphenated variation, simply supporting the (often more widely used) aliases. It's not appropriate to justify a change on the basis of it being mostly carried out. Nikkimaria (talk) 02:49, 12 March 2021 (UTC)[reply]
    On watchlists, see #Worth noting below for a possible way of reducing the "disruption". I forgot to reply to Fram's point about the wider context: I was thinking about the overall naming convention, and why the bot makes it easier, but Trappist's latest contribution to the survey section explains also the wider consideration that we need to consider all the non-English Wikipedias that have borrowed our CS1 templates/modules. --NSH001 (talk) 10:40, 8 March 2021 (UTC)[reply]
    So the solution to a bot editing against consensus is for those who object to stop watching it? You couldn't make this stuff up. Once again, this is a fucking encyclopedia, not a place for techies to dictate to editors. Find a playground elsewhere, or get a real job and you will find out that people can only get paid to write programs if thay do what their users want them to. Phil Bridger (talk) 21:27, 21 February 2021 (UTC)[reply]
    Phil, your first sentence is false. This bot was approved by consensus, following standard procedures. Indeed its operator went to extraordinary lengths to shout from the rooftops that it is a "cosmetic" bot. I'll ignore your intemperate and baseless personal attack. Finally, on the question of bot edits and watchlists, I refer you to Bilorv's conribution at 11:34, 13 February above, which looks like a good solution (I'll just add the caveat that I haven't tested it yet). --NSH001 (talk) 08:25, 25 February 2021 (UTC)[reply]

    Reading some of the above comments, I'm sorely tempted to add a new proposal here: every editor who deliberately makes a change which adds an error message to at least 10,000 pages is stripped from their template editor right. Excluding hidden cats of course, these aren't a problem; but no depreciation of any parameter justifies such mainspace disruption for readers. Fram (talk) 08:30, 24 February 2021 (UTC)[reply]

    Three responses: First of all, the error messages displayed by CS1 templates are displayed by consensus, not by a single editor. Second, the error messages, such as those displayed in articles within Category:CS1 errors: unsupported parameter, are shown not because a single editor changed a template, but because individual editors made errors when they used CS1 templates. Third, the objection to error messages being splashed across article space is why the bot was operating before the deprecation error messages were displayed. People hate the display of hundreds of thousands of minor error messages, so the bot was fixing the articles before the CS1 modules were changed to display deprecated-parameter errors.
    Fram's feedback offer give something to think about, however; if the logical options A or B are chosen here so that the last 10% of the hyphenation of multi-word CS1 parameters can be completed, perhaps we should not display deprecated-parameter error messages (except maybe in preview mode) in articles until the vast majority of parameter name replacements are complete. – Jonesey95 (talk) 16:29, 24 February 2021 (UTC)[reply]
    Thanks, but remember Wikipedia:Administrators' noticeboard/Archive313#Is there a semi-automated tool that could fix these annoying "Cite Web" errors? from 1 1/2 year ago? There also was "consensus" for that change, among a tiny group of editors, but disregarding the wider community. I hoped that that episode would have learned some of the people most active at these templates that, when they propose a change affecting many pages (and certainly when they propose a change adding error messages to many pages), they should get a much wider consensus first. Still, I see in the above discussion people arguing to activate the red error messages for this (most error messages we get now are either on very few pages or for actual errors, e.g. impossible dates), which isn't an error but something some bot operators and template builders don't like. Fram (talk) 17:06, 24 February 2021 (UTC)[reply]
    Three responses: First of all, the error messages displayed by CS1 templates are displayed by consensus, not by a single editor. One thing that this discussion has made crystal-clear, I think, is that many of the "consensuses" used to make sweeping changes like this are not remotely sufficient in terms of scale per WP:LOCALCONSENSUS; again, if they were, we wouldn't be having this conversation. If you want to make a change that significantly affects hundreds of thousands of pages, you should need a consensus involving a very large number of users, and it should be properly broadcast on high-traffic boards - a seven-person "consensus" is patiently insufficient for a change at this scale, and turning around and using bots or template messages to then try to enforce it amounts to WP:FAITACCOMPLI. --Aquillion (talk) 10:03, 4 March 2021 (UTC)[reply]
    I wish that people would stop repeating this "seven-person consensus" canard; it is a weak platform on which to base an argument. The consensus about hyphenated parameters has been in place for seven years, and has been reinforced by multiple discussions about deprecation of dozens of individual multi-word parameters during those seven years. The discussion page on which every single one of those discussions has occurred, Help talk:Citation Style 1, has 396 page watchers. – Jonesey95 (talk) 05:48, 11 March 2021 (UTC)[reply]
    This page has ten times that, and I'm willing to bet there are more people opposing deprecation here than there are who supported it in the discussions you mention put together. Repeating a local consensus for less used parameters != an appropriate level of consensus to get rid of other parameters from literally millions of articles. Not to mention that the consensus that was supposedly established seven years ago wasn't even for deprecation, just prioritization. Nikkimaria (talk) 02:49, 12 March 2021 (UTC)[reply]
    • I wish that people would stop repeating this "seven-person consensus" canard; it is a weak platform on which to base an argument. The consensus about hyphenated parameters has been in place for seven years To be clear, the consensus of that RFC was that non-hyphenated parameters are allowed, subject to the unambiguous restriction that no parameters can be depreciated. The RFC specifically did not favor non-hyphenated parameters over hyphenated ones, and the statement at its start specifically promised that no parameters would be depreciated as a result. There has never been any sort of consensus (not even a weak, highly-local one) to depreciate hyphenated parameters; nor, as a result, have any depreciations made on those grounds ever been valid. And it is clear from this discussion that such consensus would never have been reached if it had been sought (which it was not.) A discussion among a tiny number of people, without an RFC, which directly violated the very RFC they tried to use to justify their actions, with no further RFCs or any effort to get consensus from or even inform the wider community of what they were doing, is not a "consensus" in any way, shape, or form - longstanding consensuses get their weight from the large number of people who have seen and accepted them, and in this case the longstanding consensus is (and remains) to retain hyphenated parameters. --Aquillion (talk) 10:31, 16 March 2021 (UTC)[reply]
    This is uh, not a good idea. In some cases many templates are used in error, though they previously did not detect such errors. Detecting and fixing such errors is a good thing. IAR is policy, and if someone is breaking tons of things, sure, remove their rights, but simply displaying error messages isn't a clear-cut issue.
    As for non-silent parameter deprecation, yeah, replace first then deprecate. I don't think anyone disagrees with this. Elliot321 (talk | contribs) 20:30, 3 March 2021 (UTC)[reply]
    Well, I certainly disagree (and have, several times, on this page already). If there's consensus to do away with certain parameters, then the very first thing to do is deprecate them, that is, tell everybody not to use them anymore, next, run the bots to replace the usage, then, eventually, show the red messages and, ultimately, completely remove support for the deprecated params. Any other path is crazy. — JohnFromPinckney (talk) 03:54, 4 March 2021 (UTC)[reply]
    • One of the objections I raised with Monkbot18 which is not being addressed whatsoever in the "status quo" (option A) argument is that the bot also make other changes, including the removal of whitespace and line breaks from citation templates. This is unacceptable per MOS:STYLERET. In my mind, the time I have spent undoing these changes to the articles I focus on has been a far bigger burden than the lack or presence of a hyphen in a parameter. If this bot is tasked with swapping parameters, it should ONLY be changing "accessdate" to "access-date" (and vis a vis similar parameter hyphenations), and absolutely nothing outside of that. Option A should not be construed as approval of the bot code as currently written, but the task for which it was meant to be accomplishing. - Floydian τ ¢ 18:33, 7 March 2021 (UTC)[reply]
      Well, that's very odd, because Monkbot18 is very careful to preserve whitespace (with one very reasonable exception), so I don't see how it's going against STYLERET. It's true that it does remove empty/blank parameters, but that's a good thing, as it reduces clutter in the wikitext. It does a few other good things as well, see User:Monkbot/task_18: cosmetic cs1 template cleanup. Can you give specific examples of edits you think it's doing wrong, please? --NSH001 (talk) 19:13, 7 March 2021 (UTC)[reply]
      There's a nice list of reversions if you look at my edits for January 17, but here is an example. - Floydian τ ¢ 06:27, 8 March 2021 (UTC)[reply]
      Ah, that's the "one very reasonable exception" that I referred to. All the other changes that you felt you needed to make in your "cleanup and standardise first 150 refs. Revert stupid friggen MonkBot making stylistic changes to thousands of articles on a "consensus" of like 3 people, and block it from making further edits" edit are down to other editors/bots, not Monkbot18. I think a blank line within a cite template is always unnecessary, and uses up valuable space within the edit window, but if it bothers you that much, you can always ask Trappist nicely, and I'm sure he'll remove that tweak for you. --NSH001 (talk) 07:15, 8 March 2021 (UTC)[reply]
      In that case, Your Mileage May Vary, and STYLERET applies. The blank lines make it easier to pick out citations from text, and scroll bars overcome the "valuable space" argument. I tried to ask that behaviour to be removed. I was met with (*paraphrased) "bot code was approved, proceeding". So I just blocked the damn bot from the 300 articles I work on. Now if someone is that concerned about a hyphen in a parameter, they can go manually change it. Simple as that.
      Or, you know, the bot could stick to making the changes to parameters that it is supposed to. I shouldn't need to ask, it's not part of the bot's mandate, remove it. - Floydian τ ¢ 15:43, 8 March 2021 (UTC)[reply]
      First, you say I tried to ask that behaviour to be removed. I was met with (*paraphrased) "bot code was approved, proceeding". That is surprising, as I would expect Trappist to be amenable to such a request (it's important to get this job done, so a small change like this one to avoid pushback is worth making). Can you point me to the conversation where you made this request, and received that reply, please?
      (later) - ah, don't bother – found it myself User talk:Trappist the monk/Archive 17#Task 18 taking out reference spacing. Looks like you didn't explain yourself very well to Trappist. FWIW, I can see the rationale for the blank line for in-line cites within the article body, if it stops people from turning it into the (horrible) horizontal format. I touch on this again below, but I agree with you that Monkbot18 shouldn't be removing the blank line. (I hope Trappist is reading this). But the rest of the changes it's making are good, and should stay.(Actually, to be strictly correct, Monkbot should remove it within LDR or biblio listings, but not within the main body. For simplicity, I'd say simply don't bother trying to remove it.)
      Secondly, Or, you know, the bot could stick to making the changes to parameters that it is supposed to. That statement is false. The bot was approved to carry out the tasks listed at the link I've already given: User:Monkbot/task_18: cosmetic cs1 template cleanup, and that's exactly what the bot has been doing. Apart from the blank line issue, the other changes are good, and valuable, and will reduce the need for more bot runs in the future. One of the reasons I like this bot so much.
      The next bit is very interesting (to me) but is wandering mostly off-topic, so I'm putting it in small text. If you'd like to take it further, feel free to discuss it on my talk page. The problem of citation clutter in the main body of Wikipedia articles has been annoying me for years, and especially the huge problems caused by long, horizontally-formatted citation templates, which in my opinion make wikitext difficult or impossible to read and to edit. This is all set out on a very long "thread" (it isn't really a thread any longer): on my talk page. It is talking about a way of setting out citation templates that I call "ETVP" for "easy to visually parse", which is similar in many ways to the citations in your example, but also differs in some respects. The interesting point to mention here is that I had a difficult and bruising experience trying to introduce ETVP-formatted citations into article bodies. The excuse offered for reverting me was mostly "it takes up too many lines" in the edit box (hence "the one very reasoable exception" above), so in the end I gave up on that, and focused mainly on other solutions (ETVP within WP:LDR or ETVP within biblio listings using short-form referencing) which in most cases are actually a better solution anyway. It's a fascinating paradox that you seem to have gotten away with it by using more lines, not fewer, combined with a lavish use of white space – the exact opposite of what one would expect. So I am now thinking of adding a similar option to my ETVP script – and thank you for prompting that thought. Will need some thought, though.
      --NSH001 (talk) 10:02, 9 March 2021 (UTC)[reply]
      The blank lines is the only issue I'm having / pointing out here. I have no problem with updating deprecated parameters, I have no problem with my watchlist having a litany of bot edits. I do have a problem with going through 250 articles that have an average of 50 citations, to reinsert a blank line in each. This is not one of the 6 tasks listed at User:Monkbot/task_18: cosmetic cs1 template cleanup.
      There are also some automated tools that do similar nonsense that I revert on sight (e.g. Regex Citation Formatter). - Floydian τ ¢ 15:49, 10 March 2021 (UTC)[reply]
      We appear to be in agreement here, specifically that you support option A, but only if Monkbot 18 drops its removal of entirely blank lines within citation templates. If you could confirm that my understanding is correct, that would be very helpful. Thanks. --NSH001 (talk) 10:00, 11 March 2021 (UTC)[reply]
      You would be correct good sir! - Floydian τ ¢ 15:36, 11 March 2021 (UTC)[reply]

    Worth noting

    Trappist has kindly set out, very clearly, a suggestion on how to configure your watchlist to avoid the problems of large numbers of bot edits in watchlists. I copy it here, in case it is helpful to anybody:

    Note that I haven't (yet) tried this myself, since I'm already satisfied with the way my watchlist is set up. --NSH001 (talk) 09:09, 8 March 2021 (UTC)[reply]

    Note to RFC closer: the above instructions are a remedy for all of the people supporting Option C because of "watchlist clogging" and the alleged problems that the bot's edits cause for editors who watch for vandalism. As far as I can tell, no editor using the above settings is objecting to the bot's changes based on watchlist issues. Unless a valid objection is raised, I propose that all Option C support citing watchlist problems be discounted and guided to the above recommendation. – Jonesey95 (talk) 17:30, 8 March 2021 (UTC)[reply]
    This is a workaround that (a) should not be necessary, (b) doesn't work for everybody, e.g. those who want to see bot edits (I do for example) and (c) doesn't fix the problem only a symptom. It is additionally highly inappropriate to suggest that large numbers of editor's valid and rationally expressed preferences are discounted. Thryduulf (talk) 17:41, 8 March 2021 (UTC)[reply]
    I've been trialing this workaround for the last day or so. Back in December I cleared out my watchlist and took a two and half month wikibreak while the bot ran. I've just come back to Wiki and discovered that the bot has been stopped, but thought I'd try Trappist's suggestion. So far so good, it's a bit different but at least it makes the watchlist saner than during the bot attack! Martin of Sheffield (talk) 20:23, 8 March 2021 (UTC)[reply]
    I've always been puzzled that (some) editors get so triggered by large numbers of bot edits. I have more than 6,000 pages on my watchlist (which I have set to show bot edits), and bot spam has never bothered me. I even welcome it, as they sometimes remind me of articles I did a lot of work on perhaps 7 or 10 years ago, and which I really ought to look at again. That said, I do understand the problems of editors who want to deal with vandalism, so this new setting looks to be very valuable, and should indeed remove many (but probably not all) of the "watchlist spam" objections. --NSH001 (talk) 10:40, 9 March 2021 (UTC)[reply]
    And on the subject of editors like me who aren't bothered by bot spam, has anyone considered the silent majority who either aren't bothered by the "spam" or who, if they are, aren't concerned enough to come to this RfC to complain about it? Perhaps they ought to be weighed somehow in the balance when considering "consensus"? --NSH001 (talk) 10:51, 9 March 2021 (UTC)[reply]
    Well given that most of them will not know that this discussion exists and will just be getting on with adding the parameters, with and without hyphens, as they always have done I don't think was can say one way or the other what their opinion is - especially given that the bot has not been spamming its unnecessary changes for quite a while now (the discussion has been open a month tomorrow, and I think it was stopped a day or so before then, and more than a few editors are of the opinion that arguing against bots/bot operators is pointless). Instead of grasping at straws to discredit or dismiss the opinions you disagree with, perhaps you could instead try listening to why they disagree with the changes, not just the manner of the changes. I also note that you have completely ignored my explanation of why this will not actually solve the problem for everybody and ignored that there is no reason why the problem should need to be solved in the first place. Thryduulf (talk) 11:49, 9 March 2021 (UTC)[reply]
    None of this changes the fact that there is no consensus to depreciate non-hyphenated parameters, nor has any such consensus ever existed. Rather than trying to convince the RFC closer, you should be planning how you're going to get that consensus, if you intend to keep doubling down on that. --Aquillion (talk) 10:35, 16 March 2021 (UTC)[reply]
    • Comment It's easier for authors if every possible format is accommodated, and recognized as a synonym. There's no reason to delete any unless they;re actually confusing. DGG ( talk ) 05:59, 21 March 2021 (UTC)[reply]
    • Option A, then B, Strongly Oppose C. Citations should be standardized across the encyclopedia. Having a bot do these automated tasks does not spam watch lists, and if that was a concern then the solution is to ignore bots from watch lists, instead of stopping encyclopedia improving projects too many people are saying " watch list ".JackFromReedsburg (talk | contribs) 18:36, 5 April 2021 (UTC)[reply]
      Why should citation parameter names be standardised? How does it improve the encyclopaedia? Why is your opinion that the many bot edits are "not spam" more valid than the experiences of those who have explained why they experience them that way? What is your response to those who have explained that they do not support these changes for reasons other than watchlist spam and/or have reasons why they do not want to ignore all bot edits? Thryduulf (talk) 19:50, 5 April 2021 (UTC)[reply]
    • There seem to be many people responding to the "spamming watchlists" aspect of this. That is certainly not my objection. The problem is that we have lots of editors who for over a decade have been using the non-hyphenated parameters but if this is deprecated will get an error message when doing so. Everyone would say on seeing that that they know what they meant, so why on Earth remove the functionality that deals with the situation automatically? People are proposing very complicated artificial intelligence techniques in other areas, but are resisting synonyms for parameters that were considered simple even in the early days of computing. Phil Bridger (talk) 19:26, 5 April 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    notifications of indef blocked users

    This is something that just kind of bothers me and I'm not sure I have a good solution to it but thought a discussion might be productive. Sometimes, very long-term users end up indef blocked, and over time many things they created are nominated for deletion. Notifying someone who has been blocked for years seems unproductive and kind fo like kicking them when they are down. I'm not by any means suggesting these nominations or notifications are done in bad faith, in many cases the notifications are done by automated tools anyway. And that might be where a tweak could be made. I use a script that automatically puts a line at the top of any user page or talk page telling me how long a user has been registered, what user rights they have, and will also inform me if they are blocked. For example, right now on my own user page it displays as A checkuser, oversighter, and administrator, 13 years 7 months old, with 96,136 edits. Last edited 27 minutes ago. If that functionality is compatible with Twinkle or other such tools, they could pop up and ask if the user is sure they want to notify, something like <USER> is blocked and their last edit was 342 days ago, do you wish to proceed?. Does that make sense and/or seem reasonable to anyone else or is it just me? Beeblebrox (talk) 20:11, 9 March 2021 (UTC)[reply]

    I've been bothered by the same thing, and I think it's a reasonable suggestion. There are also people who've formally left the project, so it should account for people who haven't been blocked but are just plain gone. Acroterion (talk) 20:16, 9 March 2021 (UTC)[reply]
    (edit conflict) Seems reasonable to me. I prefer to nominate pages for deletion manually rather than using Twinkle, and skip notifying indefinitely blocked users, or users who have been inactive for a long time (I'm not consistent about how long). Although, I once got personally attacked on Meta for not notifying an indefinitely blocked user ... * Pppery * it has begun... 20:19, 9 March 2021 (UTC)[reply]
    • Leaving the same courtesy notifications that you would on any unblocked user's talk page is not WP:GRAVEDANCING, not kicking them when they're down. And it's a mistake to assume that those notifications serve only that user. There have been numerous occasions when notices on an indef blocked user's talk page helped me find an old deletion discussion, or discern a pattern in their behavior. Such patterns have led to further cleanup and to the unmasking of sockpuppets. Perhaps such breadcrumbs aren't as important to admins, who I assume can see deleted pages and revisions. As a non-admin, I hope no one stops leaving notices on the talk pages of blocked users. --Worldbruce (talk) 23:13, 9 March 2021 (UTC)[reply]
    • I agree with what Worldbruce said above. Also a surprising number of highly productive editors have been indef-blocked, and they have often created significant pages, templates, images, etc., where a wider notification pool may be good. Furthermore, an indef-block is not always forever, and they might return one day to address any issues, or catch up, even if they miss the relevant discussion at the time. And if a page is bothering you, you can always unwatch it. However I also agree with Beeblebrox that people should have the information in a convenient place to opt out of notifying users. Ideally people should be taking the extra few seconds to look at contribs anyway, before choosing the relevant tickbox in Twinkle, but it is what it is. I would guess that it would be relatively easy to implement in Twinkle if it isn't already - you would want to speak to the Twinkle developers. -- zzuuzz (talk) 23:56, 9 March 2021 (UTC)[reply]
    • How many of these scripts respect {{nobots}} and might that be something indef'd editors can be made aware of? I get the reasons above about the benefits of allowing these notifications, but it strikes me as similar to don't template the regulars: it's not wrong or forbidden, but just kinda tone-deaf. We should be up-front about the option, and let current editors make their own decisions on whether to template indef'd editors. I'd be fine preventing it by default. — Wug·a·po·des​ 01:36, 10 March 2021 (UTC)[reply]
    • The problem here is that productive users have been blocked. For example, I was just reviewing the history of a couple of articles and noticed that Hullaballoo Wolfowitz had made some useful contributions. But they are currently blocked for a period of six months – a remarkably draconian and unproductive punishment. In such cases of obvious injustice, I will typically put that user's talk page on my watchlist so that I may observe any such notifications and take appropropriate action. HW's talk page has over 300 watchers and the notifications are for them as well as the primary user. So far, in that case, we have had one of Gerda's Precious anniversaries which serves to remind us that this block is disruptive. So, the appropriate action in this case is to remove the block – the OP should please oblige. Andrew🐉(talk) 11:47, 10 March 2021 (UTC)[reply]
      • See the ANI discussion which led to the block and especially note the discussion following it where the length was explained and endorsed. Andrew you might want to read up on WP:ADMINSHOPping. — Wug·a·po·des​ 20:38, 10 March 2021 (UTC)[reply]
        • An overly harsh block for pretty insignificant abuse. The effect of the block is worse than what it was addressing. Anyway for a 6 month block, notifications are still worthwhile to get on the topic of this discussion. Graeme Bartlett (talk) 00:06, 11 March 2021 (UTC)[reply]
          • An ... block for ... abuse. fixed that for you Graeme. You might want to try reading the discussion I linked, especially the part where I said even people defending HW pointed out a pattern of incivility, they simply try to excuse it through various means. If you're interested in more than just taking cheap shots at me and want to challenge the close, you know where AN is. — Wug·a·po·des​ 00:53, 16 March 2021 (UTC)[reply]
    • This is one I have struggled with, I don’t like the perception of grave dancing, but when nominating an article for discussion I have sometimes left a message for blocked users wondering if (hoping) one of their former collaborators might maintain a watch on their TP and have an interest in or knowledge of subject matter. Cavalryman (talk) 22:02, 10 March 2021 (UTC).[reply]
    • This is an interesting discussion. I'm not so concerned about any perceived awkwardness or impoliteness in leaving such a notice on a blocked user's talkpage, as I am in the productiveness of it. As people are saying, it is better to leave such a message rather than none at all, because then the message is at least seen, but if the user has few or no talkpage watchers, or if the user is not blocked, but simply inactive, then notifying just the first editor may not be productive at all. And even if the first editor is still active, they may not be the person who is most interested in the article. Some first editors make just the initial edit or two, and then leave the article, and it may get built up by other editors. I think it may be useful to have an added functionality in the automated tool to notify the first editor AND the most productive editor (perhaps with some added clause such as that the most productive editor should be unblocked, and have made an edit on Wikipedia in the previous month). SilkTork (talk) 09:21, 12 March 2021 (UTC)[reply]
    • What Silktork said. There are articles where one creates, but another fleshes it out and has more of a vested interest in the article, so expanding notifications to those people is worthwhile. As for notifying someone who is indef blocked, I certainly don't see it as gravedancing, it is simply treating them like anyone else here, which is technically what we are supposed to do unless they are actually banned. It may be less than ideal in some ways, but it is the lesser of the two available evils. Even if indef blocked, by being notified, they can at least know it up for deletion, and ask someone else to look into it (which isn't the same as proxy editing), or a talk page watcher can look into it, putting more eyes on it. Not every solution is perfect, but I think the current system is the least un-perfect. Dennis Brown - 2¢ 10:13, 12 March 2021 (UTC)[reply]
    • Just to be clear, the only thing I was even thinking of proposing was to ask for Twinkle or other tools to just have the option to double check if you want to proceed if the user has been blocked and inactive for say, six months or longer. I don't think we need a rule or anything. An example is User talk:Richard Arthur Norton (1958- ). This user checks in once or twice year, clears like 20 deletion notices off their page, and goes quiet again. Again, I don't think anyone is doing this maliciously, it just seems rather pointless. Beeblebrox (talk) 06:17, 13 March 2021 (UTC)[reply]
      • Why not revisit a lot of those possibly unjust, indefinite blocks? These users might be thinking, "Now, I'll get over to Wikipedia now. Am I unblocked? Nope. Do I have the strength to request unblock? No, it'll just be declined. Is my talk page huge? Yes. Full of deletion notices, and I can't even give a rationale for keeping them. I have so many ideas for restarting, but the administrators act like I'm a fly they swatted. Makes me think I should get away from Wikipedia now. See you... never!" 🐔 Chicdat  Bawk to me! 11:22, 20 March 2021 (UTC)[reply]
    Alfred Dreyfus's talk page, 1895
    • This also bothers me when I see it. Especially since an indeffed user can't actually participate in the deletion process, it just seems unnecessarily cruel: "Hey asshole, that article you spent a bunch of time on is getting nuked, thought it might be funny for you to watch people debate about it without being able to respond in any way". Not nice! jp×g 18:43, 16 March 2021 (UTC)[reply]
    • The premise here is well-meaning, which we could always use more of, but I feel like this has maybe been over-thought. First off, if you're indef-blocked, why are you still logging in here? Do people do that, just so they can keep trying to edit? That is, does the audience even see the messages you're worried they'll see? Second, we're talking about people who were such fine folks that they got themselves indef-blocked and such fine articles that they're up for deletion. I guess I'm just being crusty, but I'm having a hard time kindling a lot of sympathy. I'd much rather expend time/effort/resources on the people who aren't dicks. Finally, the deletion is gonna happen or not regardless of the notification; isn't it just as likely - and perhaps more so - that the "nice" thing to do is to let people know what's happening rather than leaving them in the dark? We see a lot of questions on the help desk from people wondering where the hell the such-and-such article went. Matt Deres (talk) 20:13, 26 March 2021 (UTC)[reply]
    • Oppose per Worldbruce, Zzuzz, et al. If someone is long-term blocked or simply deciding not to be an editor any longer, they are free to change their site preferences to stop receiving e-mailed notficiations about posts on their talk pages, etc., if they are even receiving any at all. Editors do not own their talk pages, and their talk pages do not exist only for those individuals, but for the entire community. It's quite correct that the XfD and other notices on a troublesome user's talk page are often of direct and immediate use to other editors.  — SMcCandlish ☏ ¢ 😼  05:56, 3 April 2021 (UTC)[reply]

    RfC: make Template:Authority control more reader-friendly

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
    There's a strong support for an overhaul of the authority control template that uses human-readable names of the resources, in the interest of being recognizable to more editors. There is general support that Fram's proposal is preferable to the current version, but not any consensus on the exact form that an improved version might take. An alternative proposal which attracted some support is to scrap the entire template or replace with a link to wikidata, which could be discussed at another RfC to gauge if that proposal has consensus. (non-admin closure) (t · c) buidhe 01:24, 1 April 2021 (UTC)[reply]


    Should Template:Authority control be rewritten to make it more reader-friendly? Fram (talk) 10:12, 18 March 2021 (UTC)[reply]

    Authority control background

    Authority Control is a template that is included in 1.7 million enwiki articles by now: it shows as links a number of "unique identifiers" from organisations around the world. All the data is stored on Wikidata, nothing is stored here. The proposed RfCs won't change anything about how Wikidata deals with these: it is purely about how we want to show these at Enwiki.

    With an example taken from Kenzaburō Ōe, the current result of the Authority Control template looks like this;

    Authority control proposal

    Change the links to authority IDs: currently they are an acronym plus a unique but often meaningless ID. In the proposal they would become a readable, textbased link. The links could also be organized to make their use clearer, and to avoid repetition.

    The above is a very simple mockup of how it could look. This is an example, and not necessarily the end result. For other common groups of IDs (e.g. art-related websites), another line can be added. Fram (talk) 10:14, 18 March 2021 (UTC)[reply]

    I would like to ask people not to focus too much on the look of the proposal: the RfC is about the principles, the actual new look can be decided by people with more knowledge of and talent for user experience design. Fram (talk) 10:16, 18 March 2021 (UTC)[reply]

    • There's probably something I'm missing, but the lead reference "Integrated Authority File" leads to a German language website for the Deutsche Nationalbibliothek which I would have expected under "National Libraries"? Other than that issue it does seem a good and sensible proposal. Martin of Sheffield (talk) 10:25, 18 March 2021 (UTC)[reply]
      Yes, I wasn't certain where to put this one. It is, to my best knowledge, an international standard, but maintained by the German National Library, and the text on the page is in German. These details (well, it's an important one) will need to be decided upon if the general principle of the proposal gets accepted. Fram (talk) 10:43, 18 March 2021 (UTC)[reply]
    • Comment: Is the term "Authority control" even reader-friendly? Few readers other than librarians will have any idea what it means, and it sounds ... authoritarian? Should we talk about "Unique identifiers" for clarity? PamD 11:29, 18 March 2021 (UTC)[reply]
      No not really. Its a data/library term not a reader term. Only in death does duty end (talk) 11:41, 18 March 2021 (UTC)[reply]
      That would be better but is a separate discussion, I think. Fram (talk) 11:54, 18 March 2021 (UTC)[reply]
      I don't fully mind the term, as it is wikilinked, but it's not a major deal either way. Most casual readers likely don't even make it that far on the page. ɱ (talk) 13:58, 20 March 2021 (UTC)[reply]
    • Oppose removing WP links - I'm pretty sure this has been discussed before, but that hasn't stopped Fram before, either. The links to, for example, LCCN inform the user of the AC-granting institution, and the ID link(s) n81033861 provide the information. Both are needed.   ~ Tom.Reding (talk ⋅dgaf)  11:39, 18 March 2021 (UTC)[reply]
      • Why should you require a reader to click on obscure acronyms to get the information about who issued the ID string, if you can include it much more clearly in the template directly like above? Most readers of the Oë article will have no clue at all what "NLG: 71274" is. In the new template, they see directly that it is a link to the National Library of Greece. Do they need an actual link to National Library of Greece from the Oe article? I doubt it, it is not relevant information for that article. Do they still have the link to the NLG ID page? Yes, that is still included. But now at least they will have a better idea of what they are presented with, without needing to click either link. Your two reasons are "informing the reader of the granting institution", which is in the proposed version done directly instead of requiring a click: and the ID links to provide the information, which is in the proposed version also still there, as it still is a link which still leads to the same information. Oh, and feel free to link to previous discussions, perhaps without the personal comments though. Fram (talk) 11:53, 18 March 2021 (UTC)[reply]
        • You brought it up, here, at this Village pump (proposal) in June 2018. Search "Option 2Names", which spawned "Option 2Wikidata", "Option 2pencil", and "Option 2edit". I too, at first, and others, liked these options, before realizing my statement above. Nothing personal, just facts about your person. Unfortunately, they seem like WP:I didn't hear that and/or slow-motion WP:FORUMSHOPPING.   ~ Tom.Reding (talk ⋅dgaf)  15:43, 18 March 2021 (UTC)[reply]
          • Oh, that trainwreck discussion ending in no consensus, but with a lot of support for the type of changes I propose here? Yes, that kind of discussion doesn't stop me from bringing a new RfC two years later. I do like the "Nothing personal, just facts about your person." though. Fram (talk) 16:22, 18 March 2021 (UTC)[reply]
      • LCCN, etc., links serve the additional purpose of notifying the editor which parameter they may use (|LCCN=) to either override the WD ID, or to suppress the ID altogether. With the proposed scheme, this is much more difficult to determine. Such a lack of foresight could have been avoided if there had been any discussion on the talk page, instead resulting in this very poor RfC.   ~ Tom.Reding (talk ⋅dgaf)  00:42, 19 March 2021 (UTC)[reply]
        • Despit the template being used on 1.7 million articles, the possibility to suppress links was used on 43 pages before I created the ACArt template recently. Such a barely used possibility (which will remain available anyway, but may if the RfC is successful need better documentation) hardly justifies making the template much harder to understand (and thus less likely to be used) for our readers. This is not a "lack of foresight", this is getting your priorities right. Fram (talk) 08:23, 19 March 2021 (UTC)[reply]
          • You're ignoring the ~2400 pages using Category:Pages using authority control with parameters (1). Par for the course though.   ~ Tom.Reding (talk ⋅dgaf)  10:18, 19 March 2021 (UTC)[reply]
            • For a start, hundreds of those seem to be redirects, which shouldn't have an authority control templatein the first place. But let's look at some actual articles instead. First one I checked at random, Anthony St. John Baker, has the same ID in the parameter as in Wikidata. Siddharth Basrur, added by same editor on Wikidata and a minute later on enwiki, so not necessary either. And in any case, the possibility isn't removed, in the few cases where it is needed they will just have to check a bit harder to get it right. Fram (talk) 10:43, 19 March 2021 (UTC)[reply]
              • At least we agree that this proposal will hamper functionality.
                Also, 353 redirects, on which AC is encouraged per Wikipedia:Authority control "If necessary, create a new redirect to carry the template." For an RfC, you are stunningly misinformed.   ~ Tom.Reding (talk ⋅dgaf)  11:37, 19 March 2021 (UTC)[reply]
                Maybe it's time to stop attacking Fram ("IDHT", "FORUMSHOPPING", "stunningly misinformed", "just facts about your person", and others)? Read the room: consensus doesn't agree with you. ProcrastinatingReader (talk) 12:02, 19 March 2021 (UTC)[reply]
                All facts relevant to the discussion.
                "Read the room"? This isn't a vote; this is based on merit, of which there's none, other than "it looks pretty". Introduce a version where WP links are kept, then we can move on to discussing how much taller the template will get, but that's a better starting point than this.   ~ Tom.Reding (talk ⋅dgaf)  12:39, 19 March 2021 (UTC)[reply]
                If all you see in the proposal is "it looks pretty", then I think we are done discussing things. Uses of this template on redirects, which no one will ever see and which serve no practical purpose on enwiki, are hardly a reason to keep a template as uninformative and opaque as possible. Fram (talk) 13:13, 19 March 2021 (UTC)[reply]
    • Support improvements - Fram is right. The weird acronyms that no reader can be reasonably expected to know are utterly useless. You can hover over them to see what they mean, since they link to the respective article, but readers shouldn't have to do that to make sense of it. The presentation of the template currently is useless, and Fram's mock-up above is a leap of an improvement. Still, I think more can be done with this template. The "National libraries" presentation is good, the rest is still iffy imo. ProcrastinatingReader (talk) 15:19, 18 March 2021 (UTC)[reply]
      • When I hover of them, I get "Bibsys (identifier)", "BNF (identifier)", "CiNii (identifier)" and so on. Not very helpful. Fram (talk) 15:10, 19 March 2021 (UTC)[reply]
        When I hover over them, I get "BIBSYS is an administrative agency set up and organized by the Ministry of Education and Research in Norway. They provide the exchange, storage and retrieval of data pertaining to research, teaching and learning – historically metadata related to library resources." and other similar previews of the articles. I think it depends on whether you've got page previews (Preferences -> Appearance -> Enable page previews) or navigation popups (Preferences -> Gadgets -> Navigation) enabled. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)[reply]
    • As stated at the VPI discussion, I support the general change. I have some nits about the suggested appearance, but as requested, that's not the focus. --Izno (talk) 15:35, 18 March 2021 (UTC)[reply]
    • Support, broadly speaking, making it more readable. It's currently just acronyms no one knows with numbers that mean nothing. I exaggerate, but if a general reader would want more encyclopedic "structured" information, these should be easy to identify for them. I get that the acronyms link to the articles about the authorities, but this seems a secondary goal to achieve. —  HELLKNOWZ   ▎TALK 17:00, 18 March 2021 (UTC)[reply]
    • Support, to make the display more human-friendly. There is room for more improvement but the suggested display is vastly superior to the current example above. Schazjmd (talk) 17:02, 18 March 2021 (UTC)[reply]
    • Support the general idea of making the template more accessible to readers. Breaking it into categories is a good step. I'm less sure about removing the identifiers and linked acronyms: the former is useful if a reader wants to copy and paste it, the latter for understanding what they actually are. But those are details that can be worked out incrementally. I also agree with the sentiment below that, now Wikidata is a mature project, this template (which is a few years older) is now largely redundant. It might be an idea to go further and suppress links to authorities that don't provide any useful extra information, essentially turning the template into an automated component of the external links section. – Joe (talk) 17:12, 18 March 2021 (UTC)[reply]
    • Support of course, a no-brainer. Maybe add a TfD tag so more people see this discussion? Elli (talk | contribs) 17:15, 18 March 2021 (UTC)[reply]
      • TfD isn't a forum for RFCs. I'm listing it at WP:CENT. 力 (power~enwiki, π, ν) 17:18, 18 March 2021 (UTC)[reply]
        • I'm not suggesting to list it at TfD per se, but since the template is under discussion indicating that in the template would be helpful, and TfD has been used for this before (for example, for whether we should collapse {{WikiProject banner shell}}. Elli (talk | contribs) 18:06, 18 March 2021 (UTC)[reply]
          • I don't think advertising this RFC on 1 million articles is needed. I don't think the ‹See TfM› showing up with every {{tl}} is needed either ... 力 (power~enwiki, π, ν) 18:09, 18 March 2021 (UTC)[reply]
    • Support in a very general sense, as I believe there's room for improvement of the template. I'm hesitant about some of the specific changes proposed, though. Converting to just external links without wikilinks or numbers looks great for an item like the example above with tons of identifiers, but might not for items with fewer identifiers. Adding sections makes the template longer and more likely to be confused with a navbox. {{u|Sdkb}} talk 17:37, 18 March 2021 (UTC)[reply]
    • Oppose While the the template could definitely be made better looking, I don't trust Fram to do it. This RfC was started without any previous discussion that I've seen at Template talk:Authority control, which would have been the logical venue. Fram has nominated the template for deletion, campaigned for removal of properties from it (e.g., Musicbrainz), and most recently created {{ACArt}} to systematically remove content from it (it is currently up for deletion). They are generally hostile to Wikidata, and seek to reduce the use of Wikidata here. It feels like this RfC is a trojan horse to continue doing that. Thanks. Mike Peel (talk) 17:40, 18 March 2021 (UTC)[reply]
      That isn't a valid oppose reason. The proposal doesn't say who will implement it, and presumably the implementation itself will be subject to further discussions and/or scrutiny (+ AGF etc). The idea behind the proposal is sound (as you've said), which is the matter of discussion here. Fram left a link to this RfC at that template talk when the RfC was written (a local consensus cannot override community sentiment on this template, which is present on 1.75 million articles). ProcrastinatingReader (talk) 17:53, 18 March 2021 (UTC)[reply]
      If Fram's not going to implement it, then they should have found someone that would before starting the discussion here (like discussing it on the template talk page, not just posting a link to this discussion). I said that it can be made better looking, which is generally true of most templates, but not necessarily like this (some extra whitespace would make reading it easier). Thanks. Mike Peel (talk) 17:59, 18 March 2021 (UTC)[reply]
      It doesn't look like a particularly difficult LUA change. 力 (power~enwiki, π, ν) 18:06, 18 March 2021 (UTC)[reply]
      This opposition is unfounded. I too disagreed with Fram's decision to create and add AC art without seeking a community consensus (and as such, supported deletion at TFD) but this proposal a clear backtracking of Fram to go through the system properly; seeking community consensus for what is (demonstrably—by the amount of support) a reasonable suggestion. Its also worth noting reminding everyone that this proposal does not change the amount of links being shown, which was the cause for dispute at the AC art TFD in the first place. I would urge Mike to AGF. Aza24 (talk) 08:31, 19 March 2021 (UTC)[reply]
      @Aza24: I have interacted with Fram on numerous times about Wikidata-related issues. Assuming good faith with them has long been worn out, I stand by my opposition here. They are not the right person to do this. Thanks. Mike Peel (talk) 09:31, 19 March 2021 (UTC)[reply]
      Dude I hope you never propose an RFC. Levivich harass/hound 17:22, 20 March 2021 (UTC)[reply]
      @Levivich: I propose them regularly, but I do the background work first (including discussion with at least some people) so that it can be implemented if passed. Thanks. Mike Peel (talk) 20:17, 20 March 2021 (UTC)[reply]
    • Support, broadly, improving the template, though I'm not sure exactly what this would look like, I trust our technically minded editors. I somehow doubt that Fram is trying to secretly attack wikidata or something by proposing this at a highly visible page, certainly much more visible than the authority control talk itself. Eddie891 Talk Work 17:58, 18 March 2021 (UTC)[reply]
    • (edit conflict) Strong support These are inscrutable to readers -- you know, the people Wikipedia is supposed to serve -- in their current state. Honestly, I don't expect them to turn into the most earth-shatteringly popular part of the project after this either, but they'd be a lot better than "actively useless". Vaticidalprophet 18:00, 18 March 2021 (UTC)[reply]
    • Support There may be users who need the ID numbers, but this is a definite improvement. SportingFlyer T·C 18:51, 18 March 2021 (UTC)[reply]
    • Support Don't need wikilinks to the IDs for every instance of the template. That is what the general help link is for. Likewise the new version is more descriptive as to what the IDs are, and doesn't look like a binary dump of abstracted codes. -- GreenC 20:49, 18 March 2021 (UTC)[reply]
    • Support anything that makes this business easier for readers to understand, or else why are we even doing it? Beeblebrox (talk) 23:54, 18 March 2021 (UTC)[reply]
    • Support Common sense proposal, it's far easier to understand than the existing method. ThePlatypusofDoom (talk) 01:20, 19 March 2021 (UTC)[reply]
    • Support Removing the link to the identifiers Wikipedia article is a tradeoff that I'm more than willing to make in order to get a more understandable template where you don't need to know obscure acronyms and look at meaningless IDs when using. Clear improvement for readers. --Trialpears (talk) 10:14, 19 March 2021 (UTC)[reply]
    • Unsure - I think I support the basic question at the top -- that it could be more user friendly -- but regarding the actual example I'm not so sure... and that makes me unsure whether there is a straightforward way to make it more user friendly without significantly increasing the amount of space it takes up.
      For example, while the section for libraries seems helpful, why is a direct link to "SUDOC (France)" more helpful to a reader than wikilinking what that even is before linking to the identifier? I agree that displaying the identifiers themselves probably doesn't add all that much value, but it does seem valuable to have both a wikilink and an external link (in which case, why not link the identifier rather than something arbitrary like "external" or "link"). — Rhododendrites talk \\ 14:54, 19 March 2021 (UTC)[reply]
      • The SUDOC identifier is used on 235000 pages, but Sudoc only gets 12 pageviews a day (unclear how many of those through the current authority control template, and how many in another way). The proposed version (which can be improved upon, and the "other" section may be one opportunity for this) immediately indicates to our readers where the info comes from: perhaps it would be better to indicate in which language the linked page is instead, but the basics are the same: if you are interested in Norwegian authority control for Ôe, by all means click on Bibsys: but you don't need to visit our Bibsys page first to be aware of this. Fram (talk) 15:08, 19 March 2021 (UTC)[reply]
        • But this doesn't explain why a direct link which just adds "France" (or even "French") is more user friendly than wikilinking to what that resource is in addition to the direct link. It seems like removing the wikilinks is a major part of this proposal. What I'm worried about is that the wikilinks seem quite useful, and that retaining them and breaking the template into sections and/or spelling out what they are may increase the amount of space it takes up to a degree some find unacceptable. Here's another idea (one which I'm not entirely convinced of myself, but while we're spitballing a bit...): have a section for the non-English sources and collapse it by default? We obviously cover topics from outside the English-speaking world, so retaining them would be important, but it's true that the vast majority of users of the English Wikipedia would not be looking for non-English resources. — Rhododendrites talk \\ 15:22, 19 March 2021 (UTC)[reply]
    • Support per proposal. ~ ToBeFree (talk) 13:53, 20 March 2021 (UTC)[reply]
    • Support change so long as implementation is thoroughly discussed. ɱ (talk) 14:04, 20 March 2021 (UTC)[reply]
    • Mixed - my first choice would be to shift the entire Authority Control process over to Wikidata (so all we would have here on WP would be a small unobtrusive box pointing editors to WD.)... however, if we are going to have Authority control links here on WP articles, I agree with Fram that we need to make them clearer for the average reader to understand. Unexplained abbreviations and ID strings are not helpful. So a more expansive template gets my hesitant support. Blueboar (talk) 16:34, 20 March 2021 (UTC)[reply]
    • Alternative proposal, like User:Blueboar, I'd prefer if Wikidata handled this directly, with Authority Control being a default template, instead of something people manually add. That said, with the current template, I'd keep/use the wiki links, but improve the readability by adding sections (National libraries etc..) and more descriptive names. It would become a fatter template, and that's worth testing. We can measure its effectiveness, by tracking the view count of the Wikilinks before/after. It doesn't need to be useful to everyone, but for the few people it's useful for, experimenting is worth a try! Shushugah (talk) 19:26, 20 March 2021 (UTC)[reply]
    • Support; removing numbers with no human-readable meaning improves the signal-to-noise ratio. I would also support going further and displaying the links only on Wikidata; pace librarians and archivists, these links are only of interest to such specialists. The links by and large do not help readers, do not meet the standards of usefulness, excessive length, etc. that we would require of external links in any other context, and do not merit blanket inclusion across over a million articles. Adumbrativus (talk) 22:29, 20 March 2021 (UTC)[reply]
    • Alternative / support-ish: I agree with the general gist of this, including better layout and using more plain English. However, I agree with Blueboar that interfacing more directly with Wikidata would make sense, and with Tom.Reding that the wikilinks are important (they allow the reader to find out what these databases and other sources are and what RS say about them, i.e. why they should care about / trust what they're about to click an external link to.  — SMcCandlish ☏ ¢ 😼  21:11, 21 March 2021 (UTC)[reply]
    • Support the proposal as written, but ... I am more supportive of scrapping the template altogether per several others below. I am always wary of anything that removes control of what appears in an enwiki article from enwiki editors (acknowledging the less preferred option to manually override the template’s parameters), a simple link to Wikidata would be more appropriate. Cavalryman (talk) 22:17, 21 March 2021 (UTC).[reply]
    • Support the general principle. A bunch of random numbers and letters won't mean much to most readers, so I think adding context will help. I'm fine with using WikiData as well, as long as we still have the template for readers to easily click to. — Wug·a·po·des​ 22:20, 21 March 2021 (UTC)[reply]
    • Support a change like this. I think that, from a reader's perspective, the current blob of data looks like something only relevant for computers, something Wikipedia-internal that's not relevant for me. With this change, I think readers would be more likely to click through to the libraries etc. for more information. For the links to our own articles on these systems (all the (identifier) links), I think they should be added to Help:Authority control. That'll only be one click more for interested readers, and they won't clutter up every single article. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)[reply]
    • Support I was today years old when I actually figured out... vaguely...what authority control is. If it took me years to figure it out, then it's practically meaningless to newbies or readers. Our pages shouldn't have cryptic gobbledegook, it should all be plainly useful to the reader. CaptainEek Edits Ho Cap'n!⚓ 22:01, 22 March 2021 (UTC)[reply]
    • Support the concept or making this clearer. If it were collapsed by default, it would take less space and be more removed from the majority of readers who could care less while having the entire title bar to explain what it is to those that could make use of it: MB 03:45, 23 March 2021 (UTC)[reply]
    • Strong support all proposed changes: the encyclopedia serves readers, not editors or bots. The template is very non-user friendly. If it makes the information twice as accessible then it's worth halving the amount of it. Someone looking for the identifiers can find it from hovering over the URL, visiting the URL or visiting Wikidata. Fram makes a good argument about low pageviews meaning no-one is clicking on these wikilinks for identifiers that are supposedly useful to the reader (from what I can tell this is true as a rule, not just the one example given), so it's not a loss to remove them. Even if all else fails, I hope reorganization into sections by provenance of identifier, rather than the current alphabet soup, will be implemented as I don't think the opposers are opposed to specifically that part of the proposal. — Bilorv (talk) 00:47, 24 March 2021 (UTC)[reply]
    • Support I sympathize with those that want links the Wikipedia articles on the various databases, but that feature is not worth the inherit confusion that stems from giving readers a large set of unfamiliar acronyms, this is much clearer. Aza24 (talk) 02:06, 24 March 2021 (UTC)[reply]
    • Support making the template more human-readable. The specifics can be worked out later, but even if the exact proposed template was adopted, I think that would be an improvement. Ajpolino (talk) 21:21, 25 March 2021 (UTC)[reply]
    • Support anything to make the template more user-friendly, but prefer the suggestions of User:Blueboar and others of a more drastic overhaul and or replacement. TheEmeraldBeyond (talk) 23:04, 26 March 2021 (UTC)[reply]
    • Support making the template readableto the average reader Asartea Talk | Contribs 09:01, 28 March 2021 (UTC)[reply]

    Alternate formatting

    Discussion re: Authority control itself

    I am still confused by the purpose the Authority control template. I looked at the template page itself, and it explains WHAT it does, but not WHY it does it. Is there a page or discussion that explains the purpose of having such metadata in our articles? Blueboar (talk) 12:12, 18 March 2021 (UTC)[reply]

    It's linked in the template... Help:Authority control. Izno (talk) 15:03, 18 March 2021 (UTC)[reply]
    A lot of the information on that page is wrong though or severely outdated (compare the concise 5-link authority control template shown for Alexander Graham Bell with the current 27-link bloat). Basically, everything that is described there is done through Wikidata (and if there are outside applications that rely on the template on enwiki directly, they should be rewritten by someone more competent), not through Enwiki, except linking readers to some of the databases listed. Every researcher and application that needs unique IDs should do this through Wikidata, which is the source, and not through enwiki, which is a partial mirror for this information only. Bus this discussion, while necessary, is separate from the RfC. Fram (talk) 15:17, 18 March 2021 (UTC)[reply]
    I feel like this template only exists so folks can mass-add it to articles. Pretty sure it offers 0 benefit to readers, at least in its current structure which is just an obscure bunch of numbers and abbreviations. ProcrastinatingReader (talk) 15:22, 18 March 2021 (UTC)[reply]
    For what it's worth, I have found it useful in several cases, especially with regard to reconciling data about BLPs (not as a reliable source, of course). Occasionally I've had dates of births that didn't match across cross-wiki articles and I was able to use the various authority control to figure out what was most likely correct. I've basically treated it as an alternative to WikiData when needing structured information about somebody. The pitfall, of course, is that authority control isn't a reliable source in the same way that WikiData isn't. I would be interested to know what possible use cases it has for actual readers who aren't looking to edit the page it's on. Perryprog (talk) 13:05, 19 March 2021 (UTC)[reply]
    Agree with those above saying that the template is pretty useless almost anywhere in Wikipedia. Wikidata should do the matching of unique identifiers. Mirroring that in Wikipedia is odd at best (that is, for those understanding what it means); and completely incomprehensible for the majority. I can't support Fram's OP proposal of this RfC (neatly organized redundancy... is still redundancy... it just occupies even more space while I would reduce that space to zero), but I'd gladly support any proposal that would discourage the widespread usage of the template in English Wikipedia. --Francis Schonken (talk) 16:00, 18 March 2021 (UTC)[reply]
    It’s already been mass-added to every other article. With 1.75 million transclusions, I think the ship has sailed to discourage even more use. If we can’t get it blanked/removed (which I’d support), reforming it to not be useless is the next best thing imo. ProcrastinatingReader (talk) 16:09, 18 March 2021 (UTC)[reply]
    This isn't really mirroring it, it's displaying it. You could make a similar argument for removal of infoboxes. Elli (talk | contribs) 16:47, 18 March 2021 (UTC)[reply]
    Most infoboxes don't mirror Wikidata info though, but get their input locally: and more importantly, most infoboxes are self-explanatory, they add on their own understandable info with direct use for many readers (though there as well a significant group doesn't like them). Fram (talk) 17:01, 18 March 2021 (UTC)[reply]
    The infoboxes getting their input locally is arguable more of a "mirroring" than authority control pulling from Wikidata is. I do generally like your idea for reforming the template. Elli (talk | contribs) 17:03, 18 March 2021 (UTC)[reply]
    It's useful in the same way that references are. You can find more info in the links, or confirm content in the article. Thanks. Mike Peel (talk) 17:43, 18 March 2021 (UTC)[reply]
    References verify information written in the article. External links, which do not, are bound by the WP:EL guideline, which states: it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic. No page should be linked from a Wikipedia article unless its inclusion is justifiable according to this guideline and common sense. The burden of providing this justification is on the person who wants to include an external link. Authority control is the exemption to the rule, not the rule. ProcrastinatingReader (talk) 18:24, 18 March 2021 (UTC)[reply]
    "External links... are bound by the WP:EL guideline" Nope. It's a guideline. Nothing is "bound" by it. Besides, Wikipedia guidelines are supposed to describe, not proscribe, current practice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 19 March 2021 (UTC)[reply]
    As usual, WP:JUSTAGUIDELINE is the weakest of all possible rationales. How about WP:NOT#LINK? ProcrastinatingReader (talk) 15:52, 19 March 2021 (UTC)[reply]
    • Thank you for the pointer. Wouldn’t a simple (small) box with a link to Wikidata (perhaps saying: “Wikidata has a page on this subject: see here”) serve the same purpose? Blueboar (talk) 18:05, 18 March 2021 (UTC)[reply]
    Much like the link to Commons or Wikiquote? Thats sounds like a good idea too. Lugnuts Fire Walk with Me 08:04, 19 March 2021 (UTC)[reply]
    Wikidata is not exactly meant to be browsed, and it shows in its design, so directing readers that way is not ideal. It's meant for retrieval, which is what the AC template accomplishes. – Finnusertop (talk ⋅ contribs) 10:35, 19 March 2021 (UTC)[reply]
    • Beyond doing what's in the name, authority control puts a Wikipedia article about a subject in connection with other resources about the same subject. It basically does what our external links section does. But whereas lots of links in an EL section quickly bloat and take up too much page space, this template packs a ton of resources into a [relatively] small box tucked away at the bottom of a page. While most users probably don't notice it (ditto categories and other elements on the fringes of an article), I've talked to an awful lot of librarians, researchers, archivists, etc. who really value it. (This is a response to this sub-section, not an opinion about the RfC itself). — Rhododendrites talk \\ 14:41, 19 March 2021 (UTC)[reply]
    • Isn't itpart of the idea behind Wikidata that this sort of information woould be moved there? DGG ( talk ) 06:02, 21 March 2021 (UTC)[reply]
      @DGG: the data lives on Wikidata, this just makes it visible on Wikipedia. Elli (talk | contribs) 05:36, 22 March 2021 (UTC)[reply]
      • There is no question that the data is useful for librarians, etc. The question is: Do we actually need/want that data visible here on WP... or do we want the data to be visible at Wikidata. Blueboar (talk) 13:02, 22 March 2021 (UTC)[reply]
    there are times when such identifiers are needed to make it clear what the article is actually about, and they can be the best entry point into further information. But they are sometimes inconsistent, sometime erroneous, notably OCLC, and often reflect mere format variations, notably ISBN,. The practice of libraries confronted with this chaos is to record all available identifiers without trying to harmonize them--that's more in the realm of bibliographers. (Though I have sometimes resorted to analyzing them on WP, to elucidate the publication history of a periodical, usually on a talk p, because it is in a sense OR,). I have never tried to work with this on wikidata, as in the past the quality has been so erratic as to be discouraging, but I know the editors there are trying to clean it up as they can). The question then , as was said just above, is what part of this belongs in WP. For journal articles, I think the doi does--it's quite reliable. For books, I usually enter one ISBN, if possible for the print edition which tends to be more stable (unless OCLC record only th electronic version of what is actually a print book also). For identifying individuals, nothing that I know of is reliable. The one source for authors I know and can prove to be totally unreliable is LC after around 1960-70, and OCLC records or international cataloging records derived from LC, for if the information about the identity of the author is not immediately obvious from the title page of the book, they simply copy it from Wikipedia--and they seem to be doing so increasingly. . DGG ( talk ) 20:45, 22 March 2021 (UTC)[reply]
    Remember WP:SAYWHEREYOUREADIT If you've read it in a book, then use the ISBN printed in the book. Martin of Sheffield (talk) 22:23, 22 March 2021 (UTC)[reply]

    Authority control in mobile view

    This is another thing to consider about changing Authority control to be more reader friendly. Currently the template is not visible in mobile view at all. A template used in over 1.7 million articles must be visible to mobile device readers, who form a significant part of readership. current result of the Authority Control template looks like this; I am reading this from mobile and all I see is a blank line. AVSmalnad77 talk 17:47, 18 March 2021 (UTC)[reply]

    This is under discussion at the authority control talk page. That said, this is true of all navboxes today, which is a hard problem to solve. Izno (talk) 18:01, 18 March 2021 (UTC)[reply]
    {{Authority control}} is a navbox, and all navboxes are disabled in the mobile view. It's been an outstanding bug for several years; see T124168. – Joe (talk) 18:08, 18 March 2021 (UTC)[reply]
    Sad that it has been tagged as low priority. That explains why it has been pending for years. I hope they will provide more support for mobile users. AVSmalnad77 talk 02:55, 19 March 2021 (UTC)[reply]
    It is trivial to enable again, but if we did it would look like in this video https://www.youtube.com/watch?v=eaos1s3UfLs. I think that is worse than the status quo and the template would need a significant redesign to solve it. If we had an agreed direction to go in to improve it I guess it would be doable. --Trialpears (talk) 10:10, 19 March 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    What should the thanks confirmation be like?

    What should the message and interface that pop up when you click "thank" on a diff or history be like? On the talk page of Help:Notifications/Thanks, it was suggested that rewording the message and adding a link to the help page would make it less confusing. So we have:

    • Status quo: Publicly send thanks?  Thank Cancel
    • Option A: Send thanks?  Thank Cancel Help
    • Option B: Send thanks (help)?  Thank Cancel

    See here for the preliminary discussion (whose participants I'll notify). Note this has no binding force and there's no guarantee the result will be acted upon; it's just an informal poll to see if a change is due. Nardog (talk) 07:53, 21 March 2021 (UTC)[reply]

    • A or B, preferably A. While it is the case that the thanks are logged, the word "publicly" is highly misleading since only who thanked whom when, not even for which edit or on which page, is public, and only if one goes to Special:Log, which no casual user would even know the existence of. The following from the discussion illustrate the demand for the change. Diegodlh said:

      It wasn't clear to me whether my thanks had been sent already and if it was asking me if I wanted to publicly thank the editor on top of that, or if publicly thanking was the only way to go.

      Pdebee said:

      A few years ago, a new joiner wanted to thank me for my initial help with her first steps as an editor, but changed her mind because she thought that “publicly” meant that tens of millions of other registered editors were going to see what she’d hoped would be a simple, private signal of personal appreciation.

      Removing "publicly" will eradicate such confusion, and adding the help link will help newcomers know what the function does and hesitate less to use it, which will lead to increased editor retention if these studies are to be believed. Nardog (talk) 07:53, 21 March 2021 (UTC)[reply]
    • Support change, preferably A - I’ve always thought the ‘publicly’ wording doesn’t really match up with reality. ƒirefly ( t · c ) 08:20, 21 March 2021 (UTC)[reply]
    • Support change, preferably A - Thank you for considering this effort; if implemented, your solution should prove less confusing. Patrick. ツ Pdebee.(talk)(become old-fashioned!) 10:45, 21 March 2021 (UTC)[reply]
    • Comment: First off, I would have preferred the three given options to be given similar labels, i.e. Options A, B, and C instead of the cumbersome "Status Quo", making A and B more attractive simply to type. Secondly, the help page is considerably improved since the original discussion back in 2019 (if I may say so myself). The original discussion hones in on the word "publicly" and what that means. Go read the help page, I hope you will find it much more instructive than back in the day. Finally, here are the relevant issues I raised in the original discussion that never got addressed really: a) "Thank" and Cancel" should be buttons not links - they execute commands, they don't take you to new pages. This would make it easier to distinguish a help link. b) the help page is for the entire Thanks fuction, not merely to answer questions on "publicly" which suggests Option B as the more logical placement. c) As I understand PrimeHunter's argument (in the earlier discussion) option A requires developer intervention while option B can be done by only tweaking system messages. d) the degree of "publicness" of your given thanks is debatable - see the earlier discussion. Just so we make a change for the right reasons. CapnZapp (talk) 10:56, 21 March 2021 (UTC)[reply]
      To that end, here's an alternate poll:
      • Option A: Publicly send thanks?  Thank Cancel
      • Option B: Send thanks?  Thank Cancel Help
      • Option C: Send thanks (help)?  Thank Cancel
      • Option D: Send thanks (help)?  Thank Cancel
      CapnZapp (talk) 11:01, 21 March 2021 (UTC)[reply]
      You're throwing a monkey wrench in the middle of this discussion. Overriding the options when others have already participated will all but confuse people, and Option D isn't even comparable to the others! We can call the status quo "Option 0" if we want, and I don't mind you or anyone adding to the options (as long as it's a change on the equal level). Nardog (talk) 11:19, 21 March 2021 (UTC)[reply]
      I brought up the button/link issue in the 2019 discussion. Don't dismiss my reminder as if I had a chance to give my input any sooner, but blew it. (If you feel there is a better place where I should have brought up this directly-relevant-to-the-topic issue, you will have to tell me where) CapnZapp (talk) 14:49, 21 March 2021 (UTC)[reply]
      while option B can be done by only tweaking system messages That turned out not to be the case. See Xaosflux's comments. Both A and B require "developer intervention" (though B is easier).
      Okay, thanks. CapnZapp (talk) 14:50, 21 March 2021 (UTC)[reply]
      the help page is for the entire Thanks fuction, not merely to answer questions on "publicly" which suggests Option B as the more logical placement I don't follow this argument. What part of Option A suggests it's "merely to answer questions on 'publicly'" (when the word does not even appear in it)?
      buttons not links That would require even more of a drastic change than Option A. For now let's focus on what is within our reach (which both A and B are). You can request that change separately.
      the degree of "publicness" of your given thanks is debatable Um... so? Are you disputing my characterization ("only who thanked whom when, not even for which edit or on which page, is public")? Nardog (talk) 11:08, 21 March 2021 (UTC)[reply]
    • See technical notes at phab:T229168 for software changes that would be required upstream. — xaosflux Talk 12:25, 21 March 2021 (UTC)[reply]
      • @Xaosflux: isn't option B already possible? Can't we just create MediaWiki:thanks-confirmation2 with the content "Publicly {{GENDER:$1|send}} thanks? ([[Help:Notifications/Thanks|help]]) " ProcrastinatingReader (talk) 12:41, 21 March 2021 (UTC)[reply]
        • @ProcrastinatingReader: no, as the interface message does not support links (see the example here on testwiki). Enabling this would require a software change, I think this discussion is to help gather support to lobby for such change to be enabled. — xaosflux Talk 12:54, 21 March 2021 (UTC)[reply]
          • Oh I see. Indeed, that’s a problem. Shouldn’t the function that renders messages parse wikitext? For example in the FlaggedRevs page the standard msg functions are used and that template has wikitext working. Looking at the source for thanks, the message is rendered using JS (using mw.msg) ([1]). Presumably this function doesn’t support wikitext? Is there an alternate JS function that does? ProcrastinatingReader (talk) 13:16, 21 March 2021 (UTC)[reply]
          • Did some digging. See here. If mw.message().parse is used instead, it should parse the wikitext, right? So should be a quick change? ProcrastinatingReader (talk) 13:20, 21 March 2021 (UTC)[reply]
            • No, this also needs to change. I'm realizing Option A might actually be easier. Either way it's going to involve a change to jquery.confirmable.js. .parse() could raise XSS concerns, so it can be tricky. Nardog (talk) 13:23, 21 March 2021 (UTC)[reply]
    • Prefer Option B. The interface usually has (help) in brackets after the text, before the action, I think. For example the editnotice here about pending changes. ProcrastinatingReader (talk) 12:33, 21 March 2021 (UTC)[reply]
    • Status quo. It's important to note that thanks are public, not private (anyone can look at the thanks log), and it's good to keep consistency with other wikis (Wikidata, Commons, etc.). Having the help link always visible isn't particularly helpful, it's one more link to mis-click on, and if you don't know what 'thanks' is then you can easily find out (just google 'wiki thanks'). Thanks. Mike Peel (talk) 14:26, 21 March 2021 (UTC)[reply]
      @Mike Peel: The proposal will require a software change, so it will be "consistent with other wikis", with the link by default pointing to mw:Special:MyLanguage/Help:Notifications/Thanks (cf. the " Help" links seen in many parts of MW). Nardog (talk) 14:31, 21 March 2021 (UTC)[reply]
      @Nardog: So this should be a cross-wiki proposal, perhaps on meta, or the output is a suggestion to the developers? Enwp can't decide on its own to change MediaWiki's default config. Thanks. Mike Peel (talk) 14:45, 21 March 2021 (UTC)[reply]
      Yeah, the latter. As I said at the beginning, this is just to get a grasp of how many people would think it's an improvement. phab:T229168 has already been marked as "patch welcome", but I fear they wouldn't accept my patch right off if there wasn't "any research saying this will be a positive improvement", as they put it. Nardog (talk) 14:52, 21 March 2021 (UTC)[reply]
    • comment I think requiring a confirmation at all is unnecessary. "Thank" should be a one-and-done click. Schazjmd (talk) 16:10, 21 March 2021 (UTC)[reply]
    • As I recall, several people expressed concerns about warning users that thanks were publicly logged. Thus at present I support keeping the current message, and adding a help link to explain the thank you notification mechanism. isaacl (talk) 16:27, 21 March 2021 (UTC)[reply]
    • Support change, preferably B—the information about it being public is unnecessary and confusing, especially considering that almost everything is public on Wikipedia. When I was just starting on WP, I didn't thank people for a while, because I assumed the weirdly phrased/ambiguous "Publicly send thanks" would be an automated talk page post or something. Aza24 (talk) 17:58, 21 March 2021 (UTC)[reply]
    • Status quo regarding the word 'publicly', per Isaacl et al. No comment on the rest. --Izno (talk) 18:11, 21 March 2021 (UTC)[reply]
    • Status quo Really? This is even worth discussing? GenQuest "scribble" 18:53, 21 March 2021 (UTC)[reply]
      Quite. The "thanks" feature is simply a frippery to make us look like a social media site, not anything that should exercise our brain cells, which should be used to improve the encyclopedia. Phil Bridger (talk) 19:15, 21 March 2021 (UTC)[reply]
    • Status quo Total non-issue. ~ HAL333 02:30, 22 March 2021 (UTC)[reply]
    • Status quo I'd support option A or B but the help link is unnecessary imo. Just "Send thanks? Thank Cancel" would be fine. Elli (talk | contribs) 05:35, 22 March 2021 (UTC)[reply]
    • Support change, preferably B I have always thought this was confusing. You get there by clicking on "thank", and then you are asked if you want to "Publicly send thanks" sort of implying there is a private alternative. I'd even be OK with no confirmation on this one at all. MB 18:54, 22 March 2021 (UTC)[reply]
    • Status quo. The wording was changed for a reason. I sent an entire years worth of thanks into the bit bucket because the old query (which is closer to A/B above) made it sound like "you're sending thanks, do you want it to be public or private?" I of course just wanted the person I was thanking to be thanked, so clicked on the private option, which was really the "discard sending thanks at all" option. It's important to make clear that thanks are public, and there's no other option, so the status quo wording is fine. SnowFire (talk) 21:11, 25 March 2021 (UTC)[reply]
    • Status quo, plus the "Help" link from option A. "Publicly" is there for a reason; people need to understand that they are not engaging in private communication. However, a link to the Help page about this function cannot possibly be a bad idea.  — SMcCandlish ☏ ¢ 😼  05:45, 3 April 2021 (UTC)[reply]
    • Status quo. People should know that the thank actions are publicly recorded and the log can be viewed by anyone. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:34, 5 April 2021 (UTC)[reply]

    Edit conflict mitigation: early-warning tool

    I'm proposing an idea for a tool for reducing the number of Edit conflicts, and mitigating the annoyance and other ill effects of them when they are unavoidable, including the number of inadvertent errors resulting from them (or abandoned edits due to not being able to deal with them), by providing a tool that gives early-warning of an impending edit conflict, plus some hints or links about what to do to avoid or minimize the effects.

    Let's create a colored, rectangular badge that appears in Preview mode, initially green background, which means, "nobody else has changed this section" (or whatever is inside the Preview window). As soon as its recognized that something has changed (I'm thinking of the Watchlist notice, "View new changes since Timestamp" message that appears at the top of my Watchlist), then the badge background goes amber, and the message inside it changes appropriately (t.b.d. later), along with maybe 2 or three bulleted links or radio buttons or something, for possible actions to be taken. If the section I'm editing disappears entirely (as just happened yesterday, when a bot archived a Talk discussion, while I was replying to it), then the badge goes red.

    That would be for changes on disk; but we can go further. Let's have a checkbox in the badge, that says, "Let others know I'm working on this section (or page)" (Maybe also a second checkbox: "and let them know my identity".) Then, if they edit that section as well, their box will immediately go orange, letting them know somebody is working on the same section (and optionally, who it is, if I've allowed that). This is inspired by Pending changes review, which gives you the option to let others know that you are working on a particular change, presumably to avoid conflicts. If you tick the box, then if others also select that same change to work on, they get a little orange message that someone is working on it (maybe even their identity; I don't recall). Enhancement: a Preferences option, "Share my identity by default in the Preview badge when I'm editing a section."

    I see all sorts of possible advantages to this, and I have more ideas about what text to place in the badge, and what options might be possible, but this is getting longish for a proposal so I'll stop here for now, and open it to the floor. Mathglot (talk) 21:55, 23 March 2021 (UTC)[reply]

    • Support That would be useful. ~ HAL333 21:59, 24 March 2021 (UTC)[reply]
    • Support It would be great to be warned of a conflict when I hit "preview" instead of when I hit "publish". Not sure about the second part of letting people know an edit is in progress, perhaps implement it in two steps with first being the preview warning and the next step being enhancements. RudolfRed (talk) 22:56, 24 March 2021 (UTC)[reply]
    • Comment doesn't Paragraph-based edit conflict in beta features of preferences kind of address this? Aza24 (talk) 23:04, 24 March 2021 (UTC)[reply]
    • @Mathglot: I literally starting working on a script for the first part of this a few weeks ago. My long-term plan is to somehow highlight the words in the edit window that cause the conflict; I haven't even started on that part, yet. If anyone wants I can publish my (horribly ugly and buggy) work-in-progress. Suffusion of Yellow (talk) 23:13, 24 March 2021 (UTC)[reply]
      But I'd like to clear up a misconception. The automatic merging when you don't get an edit conflict is based on lines, not sections. Last I checked, it's just passing the three revisions off to diff3 (which was meant for merging code, not English text). What I want to attempt is something based on words, so there should be fewer conflicts. Suffusion of Yellow (talk) 23:17, 24 March 2021 (UTC)[reply]
    • If possible, Support. DMT biscuit (talk) 16:54, 1 April 2021 (UTC)[reply]
    • Support if feasible. However, I think this would need to be implemented at the MediaWiki level, so it will not be implemented unless it goes through the annual "wish list" process. I think those who care most about instituting this are going to have to figure out that process and make sure this gets listed in the next round of such voting.  — SMcCandlish ☏ ¢ 😼  05:43, 3 April 2021 (UTC)[reply]
    • If this is something you can accomplish with javascript, then no need to go through VPR right now, just get to it! Make a userscript and start testing, if it is robust we can make it an opt-in testing gadget, then an opt-in gadget. We'd come back here if you wanted to make it a default gadget. Things like 'share identity' would require mw changes (since it would need to be stored server-side) so will be a much bigger hurdle. — xaosflux Talk 11:07, 4 April 2021 (UTC)[reply]
      Yep, this has been a big WP:SQUIRREL for me. I've actually been thinking about this for years, just never got around to writing anything until a few weeks ago. About an hour ago, I got live as-I-type word-level conflict highlighting in the edit window to work for the first time! No need to even click "preview". Suffusion of Yellow (talk) 20:52, 5 April 2021 (UTC)[reply]

    Mass-deletion of more than 5500 stubs

    Main page: Wikipedia:Administrators' noticeboard § Large batch deletion probably needed

    There has been a mass-creation of more than 5500 articles which contain nothing but a coördinate, a Farsi name, and a statement that something is a "village". Unfortunately, the source database that was used to mass-create these actually includes pumps (fa:تلمبه), wells (fa:چاه), farms, and so forth; and the one prose fact in the resultant article is actually false, making these bad stubs that do not even give correct context for expansion. We have a specific list of articles that are likely these, based upon the article then asserting that "no population is reported" for the database entry; and editors are seeking consensus for an administrator to mass-delete them. There is also a separate discussion of the article creator. Please see, and discuss at, the hyperlinked noticeboard. Uncle G (talk) 08:47, 28 March 2021 (UTC)[reply]

    Shooters

    I'd like to propose that Wikipedia stop publishing the names of mass shooters. They do it for notoriety. They want to be remembered as a martyr for violence. Don't give it to them. It also stigmatizes their family members that had nothing to do with their vile acts. Publish where they're from, age, gender, race, background, but not their name. Don't give them the satisfaction of continuing to torture people. — Preceding unsigned comment added by Turtle595 (talk • contribs) 21:00, 30 March 2021 (UTC)[reply]

    • While I am sympathetic to your cause, Wikipedia is not censored. We do avoid using the names of minors and take other steps to protect the victims, it is our job as an encyclopedia to document notable events in a neutral manner. If we avoid using the names of guilty parties, it is unlikely it would make a difference in the amount of violence in the world. Dennis Brown - 2¢ 21:37, 30 March 2021 (UTC)[reply]
      That's not even true that we 'avoid using the names of minors'. Take Columbine, for example. They were minors (at least one of them was), and we print their names. As well as the names of the victims that were minors, and the bystanders that were minors, we print their names too. Notability and reliable sources are what determine what we print, and we don't censor the names of minors whose names are published in reliable sources. To some extent, I agree with the OP, in cases especially where the shooters name does not become notable. But...it is what it is.. Firejuggler86 (talk) 22:19, 2 April 2021 (UTC)[reply]
    • I'd also like to add that we almost always follow the reliable sources (in this case the media) on naming the accused. In basically all shootings we've covered, the shooter's name is already public knowledge. I think Turtle595's desire to deny recognition to mass murderers is admirable, but this really isn't something we can do as an encyclopedia. Spirit of Eagle (talk) 23:56, 31 March 2021 (UTC)[reply]
      • We're actually not required to. WP:BLPCRIME cautions us from including names of non-notable, non-public figures simply accused of a crime. Now, arguably, waaay down the road, if a shooter is caught, they will likely be tried and found guilty, at which point the name will obviously be appropriate to include, and the act of hiding the name before that point may seem pointless. My personal preference would be to omit until conviction, but obviously that's difficult to enforce, but I'd like to see more distinction made on including names of shooters or suspects where they were caught at the scene or nearby and where there is little doubt the person was reponsible for the action, compared to people that are arrested some significant time later and their connection is unclear. Eg in considering the D.C. sniper attacks, it took time for the authorities to identify the shooters, and while they were named shortly after arrest, it wasn't necessary clear they were necessarily the guilty parties, so between the time of arrest and the moment of conviction, we aught to not include their names. --Masem (t) 22:30, 2 April 2021 (UTC)[reply]

    Make access date automatically inserted for visual edit citation tool whenever we enter a new citation

    As a VisualEditor user I found it quite enjoying to use their visual citation services, but quite annoying to fill out the access date every time I create a new citation. It would be better for it to be automatically inserted whenever we made a new citation with the citation. --Regards, Jeromi Mikhael 02:08, 31 March 2021 (UTC)[reply]

    The accessdate refers to when you checked the page the URL points to, not to when you made the citation or edited the article. How would a tool know when you last checked the URL? Martin of Sheffield (talk) 06:04, 31 March 2021 (UTC)[reply]
    @Martin of Sheffield: Defaults to current day, I guess? When we make a citation we always see the page on the same day. --Regards, Jeromi Mikhael 07:32, 31 March 2021 (UTC)[reply]
    I don't think this will work. For instance, there are many instances where people just copy over a citation from one place to another, often without checking it anew. If it didn't have an access date in its original location, your mechanism would now give it the appearance of having been freshly checked, which in many cases would be false. Fut.Perf. ☼ 07:42, 31 March 2021 (UTC)[reply]
    Exactly. Also if I have a citation coming from Zotero that needs to reflect the date that the copy of the PDF (or whatever) was saved. Martin of Sheffield (talk) 07:45, 31 March 2021 (UTC)[reply]
    Alas, defaulting to current date is just what happens with WP:ReFill (sample edit). Just one more reason why that tool should be killed.
    —Trappist the monk (talk) 10:35, 31 March 2021 (UTC)[reply]

    Union between IP address and account

    Before joining Wikipedia I changed with the IP address. I would like "merge" the contributions of the IP address to my account. Dr Salvus 13:04, 31 March 2021 (UTC)[reply]

    • @Dr Salvus: There is no technical ability to do this. GMGtalk 13:06, 31 March 2021 (UTC)[reply]
    • If your intent is to claim responsibility for bad consequences of your previous edits then that can be done simply by linking IP addresses that you have used on your user page. If your intent is to use previous edits for the purposes of hat-collecting then that can only end in tears. Phil Bridger (talk) 19:57, 31 March 2021 (UTC)[reply]
    • Broadly agree with all the above comments, and I would add that using checkuser for this would run afoul of foundation-level policies regarding it's purpose and scope of use. Beeblebrox (talk) 19:36, 2 April 2021 (UTC)[reply]

    RfC on limiting minor edits

    Question: Should the minor edit functionality be limited to a group of users (such as autoconfirmed or extended-confirmed users)?

    • Option 0 (status quo): Limit minor edits to registered users.
    • Option A: Limit minor edits to autoconfirmed (or confirmed) users.
    • Option B: Limit minor edits to extended-confirmed users. (No change to bots or admins which currently have this access)

    This is a follow-up to this RfC on effectively disabling minor edits. As there was no consensus then, this is to establish clearer consensus regarding an alternative proposal. (This is my first time requesting comment, please let me know if I'm doing anything wrong.) Tol | Talk | Contribs (formerly Twassman) 00:02, 1 April 2021 (UTC)[reply]

    Survey (minor edits)

    • Question What about the Gordian-knot solution, just get rid of the concept of "minor edit" entirely? Was that considered? --Trovatore (talk) 00:23, 1 April 2021 (UTC)[reply]
      The aforementioned RfC demonstrates fairly clear opposition to removing minor edits entirely. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:30, 1 April 2021 (UTC)[reply]
      Well, that one says something like "limit by policy to anti-vandalism reverts", which is not really a simplification and adds another layer of things people can and can't do. What I'm talking about is, the whole concept of "minor edit" goes away entirely; it's not that some people can do it and some people can't; it's not that there are rules about when you can do it; it's that it just doesn't exist, period. Even historical edits would no longer distinguish minor vs non-minor. Like it never existed at all. I would support that. --Trovatore (talk) 00:37, 1 April 2021 (UTC)[reply]
      You are right that the RfC was specifically about restricting minor edits rather than removing entirely, but what I meant is many of the arguments in opposition would apply just as well for a proposal to remove them entirely, so I don't see that reaching consensus. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:45, 1 April 2021 (UTC)[reply]
      The !voters may not have taken into consideration the advantage of a genuine simplification, for once, given that none was offered. --Trovatore (talk) 00:47, 1 April 2021 (UTC)[reply]
      Given that the title was to "Disable minor edits" I doubt this. Tol | Talk | Contribs (formerly Twassman) 01:03, 1 April 2021 (UTC)[reply]
    • Support B, then A. As I said in the other RFC, currently it's about as useful as the evil bit. The point of the minor edit checkbox is to say "you can safely ignore this edit"; so long as vandals, spammers, and "what does this button do?" types can use it, "minor" edits still need to be reviewed. For new users, this will be one less thing to worry about, and one less thing to get yelled at for misusing. Suffusion of Yellow (talk) 00:34, 1 April 2021 (UTC)[reply]
      • Which strikes me as a good reason to remove the concept entirely, rather than to restrict who can use it. --Trovatore (talk) 00:42, 1 April 2021 (UTC)[reply]
        • Indeed, I would support that too. But in the other RFC there was significant opposition to this idea, so let's at least remove it for the users most likely to be spammers, vandals, or clueless. Suffusion of Yellow (talk) 00:49, 1 April 2021 (UTC)[reply]
          • Meh, can't get excited about that. If the concept is useless, remove it. If we're not going to remove it, then since I'm pretty much going to ignore it anyway, I don't really care who can use it. --Trovatore (talk) 00:52, 1 April 2021 (UTC)[reply]
    • Support B, then A Johnbod (talk) 00:39, 1 April 2021 (UTC)[reply]
    • Support A, Oppose B per my arguments in the previous RfC. I am not in favor of expanding the scope of EC if it means taking rights away from autoconfirmed users. The threshold for EC is too high for a feature as minor (no pun intended) as this one. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:53, 1 April 2021 (UTC)[reply]
    • Option A/B (as requester): minor edits are frequently abused or incorrectly used by new users, and this could limit this feature to users who can be better trusted not to misuse it. Tol | Talk | Contribs (formerly Twassman) 01:09, 1 April 2021 (UTC)[reply]
    • Support 0, strong oppose B: I'm shocked to find out the VPR discussion, which I'd filed away mentally as "some weird discussion between people with outlier opinions that's probably fizzling out", made its way here, and I at first thought this was an April Fool's RfC that hadn't been tagged properly. I can grudgingly recognize an argument for autoconfirmed (selects away some-but-not-all of the people with actively negative amounts of clue) but overall think that an example of over-bureaucracy at the terror of Spammers And Vandals taking away a minor, useful, and mostly noncontentious function. Limiting it to extended confirmed is beyond parody -- do you know what 500 edits sounds like to someone who isn't Into Wikipedia? We use extended confirmed protection as a last resort for the most massively controversial and abused articles to make sure they're only edited by people who are in too deep to continue it. I do not see the point of restricting something to vested contributors (B) or the patient (A) that can very well be better explained with replacing "This is a [[subtle link|minor edit]]" with "This is a minor edit [[less subtle link|(when to check this box)]]". Vaticidalprophet 01:12, 1 April 2021 (UTC)[reply]
      Also, should this have a watchlist notification? Vaticidalprophet 01:15, 1 April 2021 (UTC)[reply]
      I'd see your point if it was a feature that had any direct benefit to the user. But (like autopatrolled) it can only benefit other people. How is the non-extendedconfirmed user harmed by the removal? Suffusion of Yellow (talk) 01:21, 1 April 2021 (UTC)[reply]
      Autopatrolled not benefitting the end user is something I've always found more said than true -- having pages indexed by Google (and by extension around the top of it for most subjects) is indeed a benefit for the page's writer, in that it means their work will be viewed. Similarly, I don't believe minor edits are useful only to other people in either the corest sense of "to the editor, directly, in a void" or the sense of "the editor as they actually are, interacting with other people" (e.g. it is quite meaningful well before the point someone hits extended-confirmed if they have 10% minor edits or 90%). Even in the one-man-is-an-island sense, being able to tag your own edits is helpful for personal categorization and tracking. I'd like to flip the position you're presenting here -- to limit minor edits, especially to limit them only to people with edit counts that sound absolutely insane to people who are not themselves prolific Wikipedia editors, would in my opinion require a far more serious abuse than I've seen either in practice or that you're proposing. "This should only be possible for 0.1375% of the people who have joined Wikipedia" is a proposal that shouldn't happen without major cause. Vaticidalprophet 01:30, 1 April 2021 (UTC)[reply]
    • Support B/A Support B, but wouldn't mind A. There often are users(often newer) who use minor edit for things they think are minor changes but aren't Wikipedia minor edits. WikiVirusC(talk) 01:48, 1 April 2021 (UTC)[reply]
    • Question: What if I don't want to limit minor edits at all? — JohnFromPinckney (talk) 01:50, 1 April 2021 (UTC)[reply]
      • Then you would say "Option 0" and set up your own proposal on such a topic, I would think. Aza24 (talk)
    • Oppose B No real preference on A or 0. — UwU wug's this? 02:21, 1 April 2021 (UTC)[reply]
    • Support B as first choice, A as second choice. Most uses of minor edits by new users are by newbies exploring Wikipedia for the first time, vandals, spammers and sockpuppets, making the concept useless with respect to non-autoconfirmed users. Since autoconfirmed is so easy to game and it is unlikely a new user will get the point by that point, we should restrict minor edits only to those who understand what they are, and what their purpose is. JavaHurricane 04:03, 1 April 2021 (UTC)[reply]
      Are "most" uses of minor edits malicious? Does it take a month and the 99.8625th percentile of edit count to learn something that can be learned by clicking the link piped from 'minor edit'? Are minor edits as massively contentious as articles about intense global political disputes, our primary use-case for limiting an action to the 99.8625th percentile of editors? Vaticidalprophet 06:47, 1 April 2021 (UTC)[reply]
      Having been doing RCP and counter-LTA activities for quite a while now, I daresay most uses of the minor mark are either malicious, or tests, or rollbacks of tests and vandalism. And yes, it took me that long to get fully the concept of minor edits. JavaHurricane 08:13, 1 April 2021 (UTC)[reply]
      If you work in the part of the project that deals with the worst edits, you'll pattern-match the worst edits to everything. This does not mean that the majority of minor edits are bad, it means the majority of minor edits you personally encounter are bad. I have not seen any argument in favour of making minor edits more restricted than actual rollback (any autoconfirmed user can install Twinkle), or indeed as restricted as it, that doesn't sound like either "then we should make the link to Help:Minor edits more obvious" or "then you shouldn't filter minor edits in your watchlist". (I personally pay attention to every diff for the watchlist articles I care most about, including Amantio running AWB over it, in case a poor edit is hidden behind them.) Vaticidalprophet 19:58, 1 April 2021 (UTC)[reply]
    • Support B, then A per Suffusion of Yellow. ProcrastinatingReader (talk) 13:33, 1 April 2021 (UTC)[reply]
    • Option 0. What problem is this even trying to solve? Thanks. Mike Peel (talk) 14:50, 1 April 2021 (UTC)[reply]
    • Oppose B - Editors should become familiar with the edit summary system much before 500 edits. Anyone who is very concerned with missing something because it is marked minor can simply stop filtering those out of their watchlist. — Godsy (TALKCONT) 15:08, 1 April 2021 (UTC)[reply]
    • Procedural Oppose to B if that would remove this capability from admins or bots (@Tol: that isn't part of your intent here is it?). — xaosflux Talk 15:13, 1 April 2021 (UTC)[reply]
      @Xaosflux: No, I should have made this more clear. Option B would not remove this capability from admins or bots. I intended to mean removing minor edits from human users who have not been extended-confirmed (bots not being human and admins having been XC at some point). Tol | Talk | Contribs (formerly Twassman) 19:18, 1 April 2021 (UTC)[reply]
      Thanks, I noted it above and struck this !vote. — xaosflux Talk 23:09, 1 April 2021 (UTC)[reply]
    • Support A or B I have also seen this feature misused by bad actors. The purpose of this feature is to allow minor edits by trusted editors to be less prominent on watchlists, not as a privilege to certain editors. As I see it, adding an activity requirement before it shows up would make this feature more useful to those who review changes. (t · c) buidhe 15:21, 1 April 2021 (UTC)[reply]
    • Support something between B and A I was originally going to just support B but as stated above by Godsy, Wikipedia editors should become familiar with the edit summary before 500 edits.But becoming autoconfirmed (as far as I know, I'm not completely sure) is easy to do. However I completely oppose Option 0 because any user can register an account and then vandalize an article while marking it as minor. We need to take note that not all vandals are IP editors. So I think if we did something between A and B (maybe semi-autoconfirmed or possibly a separate thing entirely just for minor edits) then it would still make it harder for vandals to do what they do best while not making it too hard for good users to make minor edits. A Wild Wolf has appeared! | Gotta catch 'em all! (talk) 15:29, 1 April 2021 (UTC)[reply]
    • Support B, then A I personally believe every user uses minor edits differently, but only with WP:ECP users, is there going to even be a discernible pattern. Non ECP users by definition will have fewer than 500 edits anyways Shushugah (talk) 15:41, 1 April 2021 (UTC)[reply]
    • Support 0 - I vaguely recall participating in the previous RfC, but this is a case where what logically makes sense (either A or B) actually doesn't. One of the best RCP "tells" is mis-use of minor edits. It raises efficiency appreciably, and that alone makes me prefer to keep as-is. Nosebagbear (talk) 16:04, 1 April 2021 (UTC)[reply]
    • Support 0 with A as a very distant second choice. Despite all the discussion here and in the previous discussion, I've never actually been convinced that there is a problem that needs fixing here or that the proposed changes would actually fix things. The issues people have are one of user behaviour and limiting use of the minor edit feature is not going to solve that. Thryduulf (talk) 16:25, 1 April 2021 (UTC)[reply]
    • Support 0 As a sock and vandal detector, the minor edits checkbox is a fantastic honeypot. AdmiralEek (talk) 17:03, 1 April 2021 (UTC)[reply]
    • Support A, second choice 0, weak oppose B. The designation is almost entirely uninformative for very new users. (Contrary to the "honeypot hypothesis", I think it's essentially uncorrelated with vandalism, not reliably anticorrelated to any degree to actually be useful.) Even for the more experienced, there are different standards of what constitutes a minor edit. But it's also basically harmless. Somewhere between 10 and 500 it starts to acquire a small amount of usefulness, but given the choice I'd rather it kick in sooner rather than later. As for the preference for 0 over B, if nothing else it gives IPs one more incentive to register. MarginalCost (talk) 17:21, 1 April 2021 (UTC)[reply]
      The correlation is likely not between "minor edit" and "vandalism" alone. The correlation is between "minor edit & large diff size" and "vandalism". ~ ToBeFree (talk) 17:32, 1 April 2021 (UTC)[reply]
    • In all the years I have edited here, I do not recollect ever before having actually registered a comment in an RfC, only to say that I don't care. But I don't. If you don't want to take "you can safely ignore this edit" for granted, here's a very effective fix: don't. I can see requiring some additional experience before allowing it, but it won't really matter. --Tryptofish (talk) 19:19, 1 April 2021 (UTC)[reply]
    • Option 0, if we're limited to the options above. I don't see the point in limiting who can use the minor edit checkbox, if the problem is how it's being used. I might consider supporting a proposal that would add a technical limit on how many characters/bytes could be changed and still have the edit marked minor, such that minor edits are effectively limited to spelling corrections in one or two words, or the addition/removal of 3-5 bits of punctuation, but that option is apparently not currently under consideration and I have no idea if it's technically feasible or not. ~ ONUnicorn(Talk|Contribs)problem solving 19:29, 1 April 2021 (UTC)[reply]
    • Support 0. The fact that almost anything can be abused by a small minority is not a good reason to ban this feature from the majority that use it responsively. Also, doing it would be counterproductive as Nosebagbear points out. – Finnusertop (talk ⋅ contribs) 19:59, 1 April 2021 (UTC)[reply]
    • Support 0 - I edit in topics that are subject to frequent vandalism and POV editing... and often the vandals try to “hide” their edits by intentionally misusing the “minor edit” tag. Thus, when I see an edit flagged as a “minor edit” (in these topics), my reaction is the opposite of what is intended... I pay extra attention to the edit. I know this is not the purpose of the flag, but it actually HELPS me discover and correct vandal/POV edits... so I WANT the vandals and POV editors to keep misusing it. Blueboar (talk) 00:49, 2 April 2021 (UTC)[reply]
    • Support 0 Anon editors are human as well. I don't see why they shouldn't get minor edits. If anything, removing them will almost certainlyy increase bad edits as they allow for small changes and removing that will have severe consequences on the editing process. Swordman97 talk to me 01:22, 2 April 2021 (UTC)[reply]
      First, anonymous (IP) editors already cannot use minor edits; this RfC is to discuss whether the bar should be moved up from registered accounts to autoconfirmed or extended-confirmed accounts. This does not remove their ability to make edits which are minor edits as defined in Help:Minor edit, it only removes their technical ability to mark the edits as such. It has absolutely no impact on what edits they can make. It may help other editors who ignore minor edits, as by preventing these new editors (who may not understand what a minor edit is) from making minor edits, all edits by these new editors will show up on watchlists. Tol | Talk | Contribs (formerly Twassman) 16:35, 2 April 2021 (UTC)[reply]
    • Oppose B - While I support the idea of having to request a permission to make minor edits, extended-confirmed is not the right permission to bundle it with. Neutral between the status quo and auto-confirmed; certainly some minor edits by new users are vandalism or incorrectly tagged but it doesn't seem to be disproportionate. User:力 (power~enwiki, π, ν) 01:29, 2 April 2021 (UTC)[reply]
    • Strong Support 0 Misusing makes it easier to detect vandals per Blueboar. It also makes it easier to detect sockpuppets, since their previous account(s) likely learned about minor edits. 🐔 Chicdat  Bawk to me! 10:32, 2 April 2021 (UTC)[reply]
    • Comment I'm concerned that many editors appear to see the purpose of minor edits as a honeypot to trap editors. ProcrastinatingReader (talk) 12:35, 2 April 2021 (UTC)[reply]
      @ProcrastinatingReader:, would you care to elaborate? If you mean what I think you mean, nobody was talking about using minor edits to "trap" good-faith editors. For that matter, minor edits alone cannot trap anyone - they were saying as how minor edits assist them in spotting socks and vandals; but they aren't "busted" for using the minor edit feature, but for socking and vandalising. A good faith editor who is not socking or vandalling can't be wrongly accused of such just for using minor edits Firejuggler86 (talk) 22:02, 2 April 2021 (UTC)[reply]
    • Option 0 with a strong oppose option B (or removal of minor edits altogether). Editors supporting restrictions don't seem to be balancing the odds right—at least, not if we take their comments at face value. The question at hand is: are sufficiently many minor edits made by non-autoconfirmed/non-EC (a) unconstructive and (b) not caught by standard anti-vandalism procedures (ClueBot, Huggle, watchlisting, RCP) that it is a net negative to the system? From my own experience, I don't see how this could possibly be the case. The vast majority of unconstructive edits are not marked as minor. The proportion of minor edits which are unconstructive is lower than the proportion of major edits. And I think it's clear that anything minor by a new user that says (+2,167) is still likely to be caught by our existing processes (I think users above are saying "m (+2,167)" makes them more likely to read the edit, and it does for me too). The only thing minor edits really do is help someone with a large watchlist find the most important changes first, and I don't think we're doing these people a favour.
      I am also concerned by the attitude people are showing behind the purpose of marking an edit as minor. I mark an edit as minor if and only if I think "I would be very surprised if an editor wanted to know that this edit had happened (because they might want to discuss it or have some improvement to make on what I've done)". If an editor is repeatedly marking contentious edits as minor then approach them in the first (and maybe second) instance and if they continue and do not reply constructively then report them, because such malicious actions are sanctionable.
      Literally my first registered edit was minor (marked as such and genuinely such). There's a button saying "This is a minor edit", with an uncontroversially clear meaning. It's not hard for a beginner to use it correctly. — Bilorv (talk) 13:18, 2 April 2021 (UTC)[reply]
    • Support A Would ensure that editors understand its use. ~ HAL333 17:44, 2 April 2021 (UTC)[reply]
    • Option 0 I don't get the point of this RfC; status quo is fine. TonyBallioni (talk) 20:32, 2 April 2021 (UTC)[reply]
    • Minor edits are effectively worse than evil bits right now because they have an unclear meaning that's basically "hey you don't have to look at this edit"; this is a part of why I don't believe new editors don't use it (sort of vague meaning). At the same time though, restricting it to extended confirmed or autoconfirmed won't change that. Minor spelling and grammar corrections are often disputed as well as layout issues or whatever else; that's why the MOS pages/infoboxes are under discretionary sanctions and why there was endless discussions about the second Star Trek remake's capitalization. Minor edits should be replaced with a more robust tagging system to allow editors to self-tag edits as falling under different categories kind of like the common edit summaries tool. Right now minor edits are supposed to simply just mean "uncontroversial" but the subjects they're applied to can often be very controversial or need review. That or it's just used as a vandalism cover that doesn't work.
    A system where editors could tag edits as being grammar/spelling correction, style/layout issues, rv vandalism, wikilinking things, or a few other topics would serve the dual purpose of being a more useful tag for filtering/sorting purposes (maybe you want to see corrections of factual errors but not grammar/spelling corrections on your watchlist) and assist new editors who don't really know how to use edit summaries or the existing system. Said system has a slim to none chance of actually being implemented though (too busy making margins bigger) so I have to go with Option 0 for now. Chess (talk) (please use {{reply to|Chess}} on reply)Template:Z181 01:56, 3 April 2021 (UTC)[reply]
    • Option 0 per WP:BROKE. Strongly oppose Option B. There's virtually no evidence of disruption to demonstrate that limiting minor edits is actually necessary. This is a pointless proposal. OhKayeSierra (talk) 02:02, 3 April 2021 (UTC)[reply]
    • Option A. Too often I see noobs misusing this (intentionally or not) to semi-hide edits which are quite substantive (and often unconstructive). And too many "brand new editors" are socks of banned users, or other unhelpful parties, so they should not be able to partially disguise what they are doing from the scrutiny of many longer-term editors. It does not hurt us in any way for a brand new legit editor, already unfamiliar with the existence of a "[ ] This is a minor edit" feature, which was not available to them as an anon, will still not have that option until after they've been around long enough that we don't think they're a sock or troll. There's just no down-side to this. However, I think option B is excessive. We don't need to wait that long to permit fairly basic functionality to be available.  — SMcCandlish ☏ ¢ 😼  05:39, 3 April 2021 (UTC)[reply]
    • Option 0 or A From a new editor, it's a warning about half the time, based on the figures below. I and many of us actually use that waring. The change wouldn't remove disruption, but makes it harder to detect. I think it would be even more helpful to give unregistered editors the same ability; DGG ( talk ) 09:28, 3 April 2021 (UTC)[reply]
    • Support 0, maybe A We're going to inevitably require registration for edits eventually, but I see no point of this current proposal. I can maybe see minor edits for confirmed, though, as that's not too onerous.  – John M Wolfson (talk • contribs) 14:15, 3 April 2021 (UTC)[reply]
    • Support 0 Status quo: because, right now, the minor edit tick (when combined with a new account status), often acts like an indicator of vandalism and bears further scrutiny, especially when used on edits with the addition/removal of a whole paragraph, several sentences, or even several characters. GenQuest "scribble" 16:05, 3 April 2021 (UTC)[reply]
    • O first choice, but if we're doing this A. Limiting it to autoconirmed users as we do with other abilities such as creating or moving pages isn't entirely unreasonable, limiting it to ECP users is a rather large overreaction. Slightly favor status quo per the comments about vandal detection. Beeblebrox (talk) 19:12, 3 April 2021 (UTC)[reply]
    • Remove minor edits Honestly, what an editor considers a "minor" edit is based on perspective. A simple spelling change can meet opposition or what is deemed as a spelling correction could lead to a dispute. I've seen it happen before, disputes over trivial things such as spelling change marked as a minor edit. Just get rid of the whole "minor edit" system, even if it were used for a simple grammar correction. Filling out the edit summary will do just fine. If not that, at least have the "minor edit" system stop marking rollbacks and page moves as minor. Jerm (talk) 22:01, 3 April 2021 (UTC)[reply]
      • The problem there, as noted in the proposal, is that an RFC to basically do that failed less than two weeks ago with a strong consensus against it. Beeblebrox (talk) 22:05, 4 April 2021 (UTC)[reply]
    • 0 It's confusing if the interface changes and we should avoid confusing new users. Andrew🐉(talk) 08:52, 4 April 2021 (UTC)[reply]
    • B This make things simpler for new editors, the concept of minor edits can be introduced to them after they have made 500 edits. ϢereSpielChequers 09:09, 4 April 2021 (UTC)[reply]
    • Option 0 This seems like pointless bureaucracy. Who cares about a quite literal minor flag on an edit? Leave it be and focus on the stuff that realistically matters. Remagoxer (talk) 12:31, 4 April 2021 (UTC)[reply]
    • Option 0, plus new filters on the History panel of each page to filter out edits by extended-confirmed and/or autoconfirmed users. Those who want to only review edits by vandals, spammers, and "what does this button do?" types can do so. The current proposal of limiting minor edits does not help people who want to more effectively review problematic edits. feminist (talk) 05:24, 5 April 2021 (UTC)[reply]
    • Option 0 per hardly-a-problem looking for a major solution; also per all the other Option 0ers, who each present cogent arguments. ——Serial 13:14, 5 April 2021 (UTC)[reply]
    • Status Quo, Strongly oppose B. While it is true that there are lots of bad faith minor edits, lots of newer user also started up with minor edits. Not all people would be bold and change major things, some people started by minor edits such as fixing punctuation or capitalization, or adding minor facts, or doing minor rewording of sentences. If these new users are presented with "No you can't edit minor stuff because we don't trust you enough" it would be discouraging. Limiting minor edits to extended-autoconfirmed will be useless as vandals wouldn't care anyway. As someone who loves to revert vandalism (and made some bad calls too time to time) what stands out are the content of the vandalism, not whether it is minor edit or major edit. SunDawn (talk) 07:42, 6 April 2021 (UTC)[reply]
      How would making the "minor edit" checkbox vanish make users less likely to make edits such as fixing punctuation or capitalization? No one ever gets yelled at for failing to check that box when fixing a typo. Plus the newest users won't even know that it ever existed. The interface will just be a bit simpler. Suffusion of Yellow (talk) 16:56, 6 April 2021 (UTC)[reply]

    Data on usage of minor edits

    Quickly sorting through the past 100 minor edits to the mainspace by human editors of each of the following categories (specific revisions available here), I have some data. Note IP (unregistered) users cannot use minor edits. I am also erring on the side of assuming an edit to actually be minor.

    • Registered but not autoconfirmed users: 42% actually minor (many were also vandalism)
    • Autoconfirmed but not extended-confirmed users: 50% actually minor
    • Extended-confirmed users: 82% actually minor

    I had to remove ClueBot NG edits because apparently even the "Human (not bot)" checkbox doesn't exclude its edits. Tol | Talk | Contribs (formerly Twassman) 01:22, 2 April 2021 (UTC)[reply]

    I think this is only half the story—where's the control sample? The information I think we need is how many minor edits in each of the categories are vandalism/bad faith/unconstructive and how many major edits in each of the categories are the same. For instance, based on what I see in my watchlist (obviously selectively biased) I would expect more than 58% of registered-and-non-autoconfirmed edits to need reverting wholesale, so that 58% of minor edits that need attention is not necessarily a flaw in the system. — Bilorv (talk) 13:18, 2 April 2021 (UTC)[reply]
    Looking in each category on Recent Changes (new data), and highlighting edits tagged as reverted, 20% of minor edits by registered users were reverted, compared with 1% for autoconfirmed, and none for extended-confirmed. Tol | Talk | Contribs (formerly Twassman) 16:32, 2 April 2021 (UTC)[reply]

    Option C

    Apparently it isn't possible so it isn't worth debating. Oh well. Beeblebrox (talk) 20:49, 3 April 2021 (UTC)[reply]

    An edit filter that detects and informs when very new users are marking edits as minor. Seems like a middle road. Beeblebrox (talk) 19:14, 3 April 2021 (UTC)[reply]

    This seems unnecessary, it's already possible to filter for these on recent changes. See [2] User:力 (power~enwiki, π, ν) 19:17, 3 April 2021 (UTC)[reply]
    This is impossible (with an edit filter); the ability to detect minor edits was removed years ago. However, filter 970 (hist · log) detects new users making large changes with a summary like "fixed typo". Suffusion of Yellow (talk) 19:36, 3 April 2021 (UTC)[reply]

    Pop-up notice

    Part of the issue we have with minor edits is that our definition of minor is not intuitive, and this means that we have to assume that people misusing the box are doing so out of ignorance, which makes it very difficult to do enforcement. I propose that, should Option A or Option B be adopted, the first time an editor checks the minor edit box, a notice pop up with a brief definition of what we mean by "minor" (perhaps similar to the wording at {{uw-minor}}) that the editor would have to okay. This would ensure that everyone making a minor edit can be expected to understand what it means. {{u|Sdkb}} talk 16:00, 5 April 2021 (UTC)[reply]

    • Support as proposer. {{u|Sdkb}} talk 16:00, 5 April 2021 (UTC)[reply]

    RfC: Modification of Agatheira for syntactic compliance with linguistic precision guidelines

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
    Edit replacing hyphen with en-dash made. Please yell at me for closing my own RfC next April 1.[April Fools!] {{u|Sdkb}} talk 03:24, 2 April 2021 (UTC)[reply]

    Following workshopping at the most recent Wikimania and extensive consultation with the WMF, Blippers, and an external archeological consultant I happen to know off-wiki, I am pleased to present this landmark RfC regarding a significant stylistic overhaul of Agatheira that could establish an enduring precedent for our ancient Turkish city articles and reaffirm the Manual of Style's authoritative status vis a vis matters of punctuation.

    Background

    First, some essential context. Agatheira has long been known as one of WikiProject Classical Greece and Rome's articles. Although it arguably suffered an indignity or two on its talk page early on, its five primary editors have worked to develop it to its current status as a standout example of our coverage of ancient Lydian towns located near Halitpaşa. It has averaged pageviews per day and experienced a particular surge of popularity last August for obvious reasons. Many of you who edit in the area may also recall the major overhaul it underwent last December.

    Guiding principles

    Wikipedia's Manual of Style (MOS, Mos, or MoS) has provided authoritative guidance on grammatical matters on Wikipedia since its creation in October 2001. During this time, it has served as a crucial force for standardization of capitalization, punctuation, and more. One of the most comprehensive sections of the Mos, the section on dashes, stretches to more than 14,000 characters and covers a variety of dash-related concerns. Of particular relevance to this RfC is the clause within the "In ranges that might otherwise be expressed with to or through" level-5 subsection, which states the following: For ranges between numbers, dates, or times, use an en dash. The precise date when this clause was added is not currently known, but it has been present at least since last April.

    Proposal

    In the current revision of Agatheira, the second sentence of the second paragraph includes the phrase during the reign of Eumenes II (188-158 BC). This RfC asks whether it should be changed to during the reign of Eumenes II (188–158 BC), replacing the current hyphen with an en-dash. Feel free to share your thoughts on that question below. Given the potentially charged and controversial nature of this area, please remember to keep personal attacks to a minimum and to ground your arguments in Wikipedia policy (including IAR as needed). Please also remember to keep your comments concise to respect the volunteer nature of the project. - {{u|Sdkb}} talk 01:00, 1 April 2021 (UTC)[April Fools!][reply]

    Survey (Agatheira)

    • Weak support as nominator. I have serious reservations about this due to WP:BROKEN and WP:COSMETIC, but on balance I feel it would be an improvement. {{u|Sdkb}} talk 01:00, 1 April 2021 (UTC)[reply]
    • Support: It should follow MOS; using en dashes for ranges is generally considered correct. Tol | Talk | Contribs (formerly Twassman) 01:06, 1 April 2021 (UTC)[reply]
    • Question: En-dash? Is that an emoji? Suffusion of Yellow (talk) 01:07, 1 April 2021 (UTC)[reply]
    • Oppose It's a scientific fact that endash are satanic and cause young children to have diabetus. There also have been multiple unconfirmed reports of spontaneous combustion in mice exposed to endashes, proving clearly that endashes cause cancer. Headbomb {t · c · p · b} 01:28, 1 April 2021 (UTC)[reply]
      [3] EEng 02:35, 1 April 2021 (UTC)[reply]
    • Strong weak oppose malformed context ambiguity. Proposal doesn't discuss ancient Greek contributions to the hyphen. - Floydian τ ¢ 01:36, 1 April 2021 (UTC)[reply]
    • Just be bold and change it, there hasn't been any conflict and this survey serves no purpose. SportingFlyer T·C 01:39, 1 April 2021 (UTC)[reply]
    • Support in the strongest possible terms, but only if "BC" is changed to "BCE" in this and all related articles (where the definition of "related" is determined by a new RFC to be started immediately after the closure of this one). This is a hill I will die on, so come at me! – Jonesey95 (talk) 02:05, 1 April 2021 (UTC)[reply]
    • Opport or Suppose as long as a thin space is included somewhere on the page, or perhaps a hair space, but no minus signs, indifferent on whether the page has hyphen minus, and does anyone actually care about the em dash vs spaced en dash thingie. So confusing. 2A03:F80:32:194:71:227:81:1 (talk) 02:07, 1 April 2021 (UTC)[reply]
    • Prefer a 3/4 em-dash. –Fredddie™ 02:25, 1 April 2021 (UTC)[reply]
    • Please follow contemporary reliable sources. What did the historians at the time of Eumenes II prefer? Is there archeological evidence regarding the preferred chisel blade widths? What did the Library of Alexandria style manual specify? isaacl (talk) 02:28, 1 April 2021 (UTC)[reply]
    Question: is this a serious RfC or has the {{humor}} template been forgotten? JavaHurricane 04:06, 1 April 2021 (UTC)[reply]
    @JavaHurricane: the proposal is tagged with {{April Fools}}, though the fact that some people are aren't sure is a good sign this is at least somewhat clever. 2A03:F80:32:194:71:227:81:1 (talk) 05:26, 1 April 2021 (UTC)[reply]
    Either these are not true spies I wear in my head, or I don't see the relevant template anywhere. JavaHurricane 05:49, 1 April 2021 (UTC)[reply]
    @JavaHurricane: Probably the former as it's right after the signature (ctrl+f may be helpful). 2A03:F80:32:194:71:227:81:1 (talk) 13:55, 1 April 2021 (UTC)[reply]
    I see it now. It is already a small template; and on mobile it is hard to catch. JavaHurricane 14:20, 1 April 2021 (UTC)[reply]
    • Counter-proposal: the en-dash is slightly longer than the hyphen and it would therefore seem logical to link its usage to the period of time being described. My proposal is that, for spans of years of fifty and above, the en-dash be used - with the hyphen then reserved for shorter periods. This would give the alert reader a visual clue as to the length of time being described, even if they aren’t so good at mental arithmetic. The only potential flaw I can see with this proposal is that some editors may not cope with there actually being some logic behind WP's policy on dashes. MapReader (talk) 06:17, 1 April 2021 (UTC)[reply]
    Excellent idea. Could we use a central dot (•) for periods of less than a year. An em dash (—) ought to be used for millennia except for US-related issues when it could be used for centuries due to their shorter history. Martin of Sheffield (talk) 08:40, 1 April 2021 (UTC)[reply]
    • Comment. Having seen a WP:RFD where an experienced editor said that redirects from variant dashes should be tagged {{R from other spelling}} (to which {{R from other capitalisation}} should by that argument be redirected), I'm not going to comment. Narky Blert (talk) 07:20, 1 April 2021 (UTC)[reply]
    • This place isn't a TURKISH city at all, it's clearly a GREEK city and the Turks did not even show up there until thousands of years later. Please take care not to inflict symbolic violence on indigenous people. (t · c) buidhe 15:40, 1 April 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Question to the community: Should Arbcom members be restricted from discussing active cases and participants on forums outside Wikipedia?

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
    Withdrawn by nominator (see ending discussion comments for details). Lourdes 05:05, 3 April 2021 (UTC)[reply]

    IMP: This RfC has been modified subsequent to initial posting; all editors who commented are requested to re-read the RfC for clarity.

    Having recently been involved in such an Arbcom case and incident, where one active Arbcom member voting in a case defended his right to discuss active ongoing cases and the participants in those cases on public forums outside Wikipedia, I am requesting the community for their views:

    Should voting (non-recused) Arbcom members be restricted from discussing active cases and participants in such cases in public, non-WMF affiliated locations while the case is ongoing?

    As repeated above, the scope of this request is very limited to the period that the case is active on the Arbcom page. And scope outside Wikipedia is only non-WMF affiliated locations, and not private communication between Arbs or private communication between Arbs and participants/stakeholders relevant to any particular case or Arbs/Functionaries/Clerks IRCs, as broad examples.

    On advice from one of the arbitrators, it is clarified that this is intended to be a petition for amending the Arbitration Policy, under Wikipedia:Arbitration/Policy#Ratification and amendment. Thanks, Lourdes 07:40, 2 April 2021 (UTC)[reply]

    Petition explanation

    • Per Wikipedia:Arbitration/Policy#Ratification and amendment: "Proposed amendments may be submitted for ratification [...] having been requested by a petition signed by at least one hundred editors in good standing. Please note that as per policy, for this petition to be submitted for ratification, only number of supporting editors would be counted. This section has been added for clarity. Lourdes 17:55, 2 April 2021 (UTC)[reply]

    Support (Agree)

    1. I agree with Ymblanter in the Opposes below that such a gag order is virtually impossible to enforce, but I nevertheless think that it would be useful to have such a restriction in effect, primarily because I believe that the vast majority of Arbitrators are honorable and would voluntarily hold themselves to it without need of a formal enforcement mechanism, but also because any violation of the restriction could then play a part in any subsequent de-Arbing or de-sysopping discussion. Beyond My Ken (talk) 07:04, 2 April 2021 (UTC)[reply]
    2. Also I agree that this is not easy to enforce. However, this can result in situations where the trust in an Arbitrator can be seriously affected, or where the neutrality of the Arbitrator for the active case can be seriously questioned. As per BMK, any violation of such a restriction could play a part in subsequent de-Arbing, de-sysopping or (at a least) enforced recusal for an active case. --Dirk Beetstra T C 07:22, 2 April 2021 (UTC)[reply]
    3. It's a shame that Arbs should have to be told that this is expected behaviour from them to be honest. While it's not bullet-proof, at the very least it should remind the Arbs to be discreet and take their position seriously. Failure to comply should result in removal from the committee with immediate effect. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 07:47, 2 April 2021 (UTC)[reply]
      Moving here from down in the Neutral section. I agree with Beyond My Ken above that the primary value of this restriction would be to make it as clear as possible that arbs are expected to hold themselves to it, and that if an arb does not do so, it will be easier to address that with a restriction like this in effect. ezlevtlk
      ctrbs       08:12, 2 April 2021 (UTC)       Note: ezlevtlk[reply]
      ctrbs       struck this comment at 17:25, 2 April 2021 (UTC) because this issue has more complexity than I previously realized, and I don't feel fully comfortable with unconditional support for the restriction in its current form.      [reply]
    4. Disappointing that the Arbcom needs reminding that such a fundamental requirement symbolising trust and responsibility is necessary. Arbs should not be discussing cases externally before, during and after. Failure to comply should result in immediate removal. However, I’m concerned that during their tenure Arbs must see a lot of confidential information, as they obviously can’t all be trusted, there needs to be some form of legal requirement to maintain confidentiality. Giano (talk) 09:26, 2 April 2021 (UTC)[reply]
      • I still support with the re-wording, and I’m still incredulous that this hasn’t been a mandatory requirement of an Arb for eternity. Giano (talk) 19:18, 2 April 2021 (UTC)[reply]
    5. I assumed this was an unspoken rule, and kind of surprised we are having to discuss it. While a case is ACTIVE, it seems obvious they shouldn't discuss it on other public forums simply to maintain the trust in the community, and to keep any discussion or input on the case within the boundaries of enwp. Like the above, I recognize that it is hard to enforce, but there should be accountability where possible. Dennis Brown - 2¢ 09:55, 2 April 2021 (UTC)[reply]
    6. I would prefer if it was changed to "should recuse from cases" where they have posted in other public fora before or during a case, and yes that would mean that arbs who had recused in a case were free to discuss it elsewhere. To address Giano's point, I would expect that Arbs have signed some sort of agreement with the WMF re confidential information that they have access to, and any Arb breaking that agreement on or off wiki would one hopes be sanctioned if caught. As for the oppose argument that this is closing a barn door after a recent event, regardless of what you think of that event, surely now is the best time to review these rules? ϢereSpielChequers 10:23, 2 April 2021 (UTC)[reply]
    7. Support per the arguments of the supporters above. Johnbod (talk) 11:55, 2 April 2021 (UTC)[reply]
    8. I support the principle, although I'm surprised that this has to be codifed - while I'm aware of recent events, I still would have thought that this should be simply a given. Part of the problem is how the cases are run. The two sides present their evidence and discuss the issues together. We expect arbs to discuss it among themselves, but most evidence for and against is presented openly and discussed openly, with rare (mostly privacy-related) exceptions. What we don't expect is for an arb to take it to another public forum and in effect get input there such that those involved on-wiki are unaware and cannot respond. When the case is over people can discuss it wherever they like, but while it is ongoing, in the interests of transperancy and fairness, the public input should be occuring where it can be seen and commented on by those invovled. - Bilby (talk) 12:10, 2 April 2021 (UTC)[reply]
    9. Supporting reluctantly. "Reluctantly" because we already ask way too much of arbs, and because enforcement is tricky. But not discussing an active case or its participants off-wiki seems like a very very low bar. But this needs some clarification. Off-wiki also includes Wikipedia-l, Wikipedia IRC, etc. and I could envision some sort of really boring bit of information that could be helpful in those Wikipedia-adjacent spaces without betraying anyone's trust. Ultimately, context matters a lot. It took some digging to figure out what this was about. I still don't know all the context except to know that it concerns a Wikipedia criticism forum that's also a platform for aggrieved and/or banned editors to harass, insult, and at times dox Wikipedians. Apart from the most mundane clarification imaginable, I don't think there's any appropriate way of discussing participants in a case (open or closed) in that context. Perhaps the better way of dealing with this is with a direct question or request for commitment come election time. — Rhododendrites talk \\ 13:02, 2 April 2021 (UTC) Update: the proposal has been changed since I wrote this, so a little bit of what I said is outdated. Also, since several in the oppose camp seem to be under the impression that the only possible reason someone could support this is because of personal dislike for Beeblebrox or revenge for the RexxS decision, I'll just note that while I've seen the final decision, I didn't follow the case, don't have a strong opinion about it, and have never had an issue with either side here AFAIR. — Rhododendrites talk \\ 15:58, 2 April 2021 (UTC)[reply]
    10. Per above, and with something like this it should be enough to ask. Alanscottwalker (talk) 13:41, 2 April 2021 (UTC) Adding per some below, it's Arbcom's job all the time to interpret requests and policy reasonably, and there is no policy written that does not need interpretation, and no request that should be presumed to be in bad faith -- it also naturally seems rather unlikely that Arbcom will be too hard on Arbcom. Alanscottwalker (talk) 14:28, 2 April 2021 (UTC)[reply]
    11. Yes? I would have normally thought this was common sense. As to commentary re ARBPOL? I'm not sure I see why an RfC can't function as a petition with at least 100 signatures. GMGtalk 13:50, 2 April 2021 (UTC)[reply]
    12. I agree that this would be difficult to enforce and would create a gray area regarding exactly when it should apply, but Wikipedia is built on policies which are ambiguous and difficult to enforce. (Ask any ten editors what WP:NOT or WP:NPOV actually mean, and you'll get ten different answers.) Yes, this is a reaction to a single incident, but the very fact that there appear to be current arbitrators who don't see this obvious serious breach of trust as an issue because it's not explicitly forbidden is a sign that there's a problem here which needs fixing. We have things like Editors who have multiple accounts for privacy reasons should consider notifying […] the arbitration committee as written Wikipedia policy which editors are reasonably going to feel they should follow; yes, Wikipedia:Arbitration Committee does have the "you should not disclose sensitive personal information in your communications with us" disclaimer buried in there, but the intent behind that was "we can't guarantee the mailing list archive won't be compromised", not "arbitrators reserve the right to talk about participants on other websites for shits and giggles". ‑ Iridescent 13:59, 2 April 2021 (UTC)[reply]
      (responding to ping) I still support the revised wording, or any reasonable variation thereof; the important thing here isn't the exact wording but its spirit ("there are some circumstances when Arbcom discussions should take place in private, but there are never legitimate circumstances in which Arbcom discussions should take place in public anywhere other than on the on-wiki record"). With regards to some of the insinuations being made below, I didn't follow the RexxS case and have no idea if it was fair or not, have always got along fine with Beeblebrox, and would have supported this proposal whiatever circumstances it was proposed under. As per my comments here, "it's good that normal editors and admins engage with Wikipedia's critics, but Arbcom members need to avoid the potential appearance of impropriety and as such it's never appropriate for current arbs to be active on off-wiki criticism sites or to be discussing current cases publicly anywhere other than on-wiki" is something I've held for over 10 years. (This isn't singling out Wikipediocracy or a reheating of the whole WP:BADSITES issue, either; I'd consider it equally unacceptable for a current arb to be publicly tweeting about the participants in a current or recent Arb case.) ‑ Iridescent 16:28, 2 April 2021 (UTC)[reply]
    13. TLDR: Strongest agree: There's a few opposes that appear primarily based on the notion the community cannot modify ArbCom proceedings - and I don't believe that's true. We elect the arbitrators, we give them the authority that they have, and thus they should make rule changes when a consensus to do so is found. On the subject of WP:NOTBURO, it obviously isn't overly bureaucratic when an arbitrator was just recently discussing arbitration matters off-wiki. Now I didn't see any evidence that this arbitrator said anything "early" or released information that was supposed to be non-public, but as was said by others - if that's what this arbitrator does on a public forum, how many people is he talking to, or being talked at by, in private? Not a bureaucracy applies to everything except arbitration - they are the sole bureaucratic nonsense group on the wiki which editors can go to when non-bureaucratic methods have failed to resolve problems. They're designed to be bureaucratic - and part of why this one arbitrator thought it would be okay to do this is likely because there's no rule against it. I'd like those opposing to state whether they have a problem with arbitrators discussing on off-wiki places (especially those which harass Wikipedia editors) or not - because from what I've read, it seems like many people support the idea that arbitrators shouldn't be doing that - but they aren't supporting making it a rule? There's evidence that this is a current problem, and that it's not going to go away (the arbitrator in question doubled down multiple times) simply by the arbitrator realizing what a piss-poor idea it is to be doing so. Discussion by arbitrators about active or recently closed cases or amendments or enforcement requests should take place only on-wiki, on a WMF run mailing list, or on another WMF run wiki when necessary (ex: meta for things that may need steward involvement). Arbitrators should not comment on outside platforms, including forums, news websites, journalist interviews, etc while a case is ongoing - this should be common sense and I'm appalled that anyone can seriously argue that this shouldn't be implemented - in real life, this would result in recusal and perhaps reprimand - so why is it allowed here? -bɜ:ʳkənhɪmez (User/say hi!) 14:01, 2 April 2021 (UTC)[reply]
    14. per Iridescent. ---Sluzzelin talk 14:19, 2 April 2021 (UTC)[reply]
    15. How can a person engage in dispute resolution or impartial judgment if they're chitchatting about the case while it's going on, on a public, off-wiki Internet forum? No, an arbitrator shouldn't be hamming it up with banned editors on Wikipediocracy about ongoing parties and cases, or about the losing candidates in the last election, or who lost their bit, or who is about to, etc. If you want to explain your thinking about a case, do it on wiki. Imagine a judge, during a lunch break, goes across the street to the pub and starts talking to his buddies about the case he heard that morning. That would get any judge fired in any jurisdiction. We really shouldn't be tolerating it either. Oh, and Beebs isn't the only Arb (current or former) that does this. Levivich harass/hound 14:28, 2 April 2021 (UTC)[reply]
    16. To be honest, I'm surprised that this needs codifying. It's simply not a good look for members of the Committee to be doing so, and it calls their impartiality into question. The procedural concerns are unconvincing: surely once the number in the "support" column spills over a hundred and they are certified to be in good standing, this RfC would function as a petition as required by policy. Although I agree with WereSpielChequers, I can live with this version instead. It is not too much to ask for Committee members to be a bit more discreet when dealing with cases. If there are discussions to be made publicly for reasons of transparency, Wikipedia is the best place to make them. Sdrqaz (talk) 14:31, 2 April 2021 (UTC)[reply]
      For what it's worth, I don't have a strong opinion on the RexxS case, nor am I angry at Beeblebrox. Sdrqaz (talk) 15:50, 2 April 2021 (UTC)[reply]
      After reading the revised wording posted by Lourdes, my vote still stands. Sdrqaz (talk) 16:11, 2 April 2021 (UTC)[reply]
    17. (Summoned by bot) Agree. Not a good practice. Coretheapple (talk) 15:29, 2 April 2021 (UTC)[reply]
    18. To help ensure Arbcom's decision and process retain the support of the English Wikipedia community, this change should be made. I'm extremely surprised that this needs to be spelled out in our arbitration policy; I'd like to think that an active arb would have the common sense to realize that they shouldn't be posting in off-wiki forums about active cases. Unfortunately, a current arb's recent actions are quite concerning and prove otherwise. (I haven't followed the RexxS case.) Ed [talk] [majestic titan] 16:16, 2 April 2021 (UTC)[reply]
    19. Support This isn't about an arb, can we get past that defensive position, this is to clarify about what is going to be the best for any given case, and for our editors facing an arbitration. I've seen some vicious attacks on outside forums which carried over into Wikipedia RfAs for example. The best and safest situation is for Arbs to work among themselves but not to deliberately include others. I assume discretion in arbitrators. Isn't that common sense? As well, there is often shame connected to arbitrations; we are a community that should protect its own members. Talking in other forums before or during an arbitration can be shaming. Why would any one us do that to anyone else? Incivility is often seen as a few swear words or abrasive language, but true incivility is much larger that that. When we damage one of our own, we damage the community as a whole. That is true incivility. (Note to self. Do not check watch list when trying to take a break.) Littleolive oil (talk) 16:41, 2 April 2021 (UTC)[reply]
    20. per Iridescent. — Ched (talk) 16:49, 2 April 2021 (UTC)[reply]
    21. Support in principle. I've no objection to group discussions between past and/or current functionaries, and I've no objection to discussions in a group that is both small and private, with an expectation of confidentiality, or at least a reasonable effort to maintain the dignity of the people you're talking about. But talking about editors "behind their backs", in a forum where anyone can read it if they happen to know to look there, is non-transparent and destructive to the community. WhatamIdoing (talk) 17:11, 2 April 2021 (UTC)[reply]
      To expand on this: It's not unusual for long-time editors to have annoyed some people. There are off-wiki attack pages about many of us (e.g., see what a now-banned editor wrote about Gordonofcartoon and me on his personal website). Sometimes we wear these attacks by outsiders as badges of pride. But when you're involved in an ArbCom case – regardless of whether you are the accused or the accuser or an uninvolved editor; regardless of whether you are innocent or guilty or somewhere in between – you do not deserve to have the editors who are officially charged with seeing that case through to a conclusion talking about you in public during the case. I understand that Arbs need a safe place to talk through what they're doing and what they're thinking. What I'd like the Arbs to understand is this: A public internet forum is not a safe place. If you're writing to entertain, then write it now and post your entertaining story when it's completely over. If you're writing to vent or to otherwise manage your emotions, then keep your writing on your own computer. And if you're writing because sharing details and personal comments about our community increases your social status in another community – then quit. WhatamIdoing (talk) 18:01, 2 April 2021 (UTC)[reply]
    22. Strong Support This really should go without saying. I see absolutely no benefit to the encyclopedia in arbs discussing cases off wiki, and a lot of potential for harm. Paul August ☎ 19:42, 2 April 2021 (UTC)[reply]
    23. Largely per Iridescent. ARBCOND applies, sure, but there's no harm in specifying what type of conduct is not acceptable. TonyBallioni (talk) 21:52, 2 April 2021 (UTC)[reply]
    24. I'm not convinced that ArbCom actually needs to put this in writing, and I agree with the concerns that it would be hard to enforce in a fair manner. But I'm putting myself here in order to say that this is something that Arbs should be sensitive to, and they should not need anyone to tell them that. I don't care if an Arb simply participates at Wikipedia-criticism sites. The issue is that you shouldn't say things there that you would not say "to someone's face" on-wiki, and you should be silent about in-progress cases on which you are active. And, after that, I feel like saying "duh". I think it's appalling that this isn't self-evident. --Tryptofish (talk) 00:24, 3 April 2021 (UTC)[reply]
    25. Support I understand various points that the oppose section editors have placed, and to be candid these have been very educating and provide deeper perspectives to the position of ArbCom members during an active case. The spirit of this proposal is to not just encourage on-wiki discussions by ArbCom members during an active case, but to also re-emphasise that being the highest trusted members at Wikipedia, participating in off-wiki discussions with individuals who may consider this case as purely entertainment value should be at least reconsidered. Coming to the matter of editors mentioning that this is a result of one ArbCom case, the answer is that each ArbCom case presents, principals and remedies that get enshrined for future reference – and each case also provides perspectives to editors like me where improvements perhaps may be explored, off-wiki commentary during case progress by active ArbCom members being one of them. And what is this proposal trying to encourage? Productive discussions with stakeholders to ensure a pragmatic outcome of an ArbCom case? Surely! Providing views, say, on participants' proposals to individuals on outside public forums, esp individuals with no connection to the case? – It would be good to think that over again. I have intended this proposal to be only a reasonable one, and hope this encourages ArbCom to at least suggest to its members to review their off-wiki interactions. I am thankful to the supporters here, who resonate much of what I espouse, but also many of the oppose editors, who support the proposal in spirit but perhaps would be happier with changed wording. The message is well taken by me; quid pro quo, I hope that in future ArbCom cases, the spirit of the message that this proposal intends to forward, would be equally well taken by respective ArbCom members. Please uphold the principals of protecting the dignity of the participants and the high standards of case discussions. Thank you, Lourdes 00:43, 3 April 2021 (UTC)[reply]
    26. Support. I've had some concerns about what I've seen already at Wikipediocracy. While, yes, this will not be enforceable when it comes to Arbs using new, unique usernames at offsite venues, I agree with the first comment in this section that Arbs are generally honorable and will self-moderate their impulses. A rule need not be something that can be enforced with an iron fist to be useful. Otherwise most of our policies would have to be deleted.  — SMcCandlish ☏ ¢ 😼  05:14, 3 April 2021 (UTC)[reply]

    Oppose (Disagree)

    1. I provided there an argument why I think it is an extremely bad idea for an arbitrator to discuss the running cases on outside fora, but I just do not see how this can be enforced.--Ymblanter (talk) 06:49, 2 April 2021 (UTC)[reply]
    2. Not bureacuracy. It seems to me that in this particular case, it is the substance of the comments (and possibly the forum chosen in specific) that was the issue, not the mere existence of off-wiki comments. Arbitrators should be accountable for off-wiki comments they make under any profiles where the connection to their Wikipedia username is public. But preventing any comments as a rule seems like it would have a lot of unintended consequences. If an Arbcom case was getting media attention and an arb was contacted for comment, the rule makes it so that maybe all they can say is "No comment", but I don't see a disadvantage to them giving a generic answer "this is how Arbcom works... this is how arbs are elected... there's a misconception that we're staff but we're volunteers just like the people who write the encyclopedia".
      And then there's a whole host of situations that you can't really predict in advance where off-wiki comments could be desirable. Too broad a rule for what seems to be one instance of one problem about the content of a message (not its existence). I would maybe support something like "if an arb makes such a comment then they should link to it or copy it onto Wikipedia so vested parties will be aware of it if searching through the arbitrator's contributions". — Bilorv (talk) 09:32, 2 April 2021 (UTC)[reply]
    3. The request for comment is stated in completely neutral terms and, on the face of it, is a reasonable proposal that should be considered. However, being raised at this time, by this editor, in the particular circumstances of the associated case and the nature of the comments attributed to the Arb. concerned, I cannot support this request. There is also an element of knee jerk about it. Leaky caldron (talk) 09:58, 2 April 2021 (UTC) ..and what about nominators at RfA, involved Admins at ANI/AN and 'Crats in a Crat Chat passing comment off-wiki? Leaky caldron (talk) 11:40, 2 April 2021 (UTC) In light of the timing, the changes to venue and intention of the RfC/petition, I rescind my previous comments. Taking account the comments of others I regret that I now see more of revenge / vindictiveness in this proposal. Leaky caldron (talk) 16:23, 2 April 2021 (UTC)[reply]
    4. Invalid RfC. This is not a valid way to amend ARBPOL (in particular, the section that would be amended is Wikipedia:Arbitration/Policy § Conduct of arbitrators). No specific wording change is proposed anyway, and this RfC appears to be rashly drafted. ProcrastinatingReader (talk) 10:46, 2 April 2021 (UTC)[reply]
      More substantively: If you don't want arbs that do something, ask them about it at ACE, and don't vote for the ones that say they'll do what you don't want them to do. Excluding the mention about Lourdes, which was poor judgement and the arb in question has apologised, general offwiki commentary on cases doesn't compromise the Committee or its decision-making. A supporting editor stated I'd like those opposing to state whether they have a problem with arbitrators discussing on off-wiki places: as far as I can see only one arb does this anyway. That arbitrator made clear during their election they would participate on offwiki sites. They were elected anyway, implying that the broader community was okay with that. This is an attempt to create a rule in response to a single uncommon incident, which means it's more likely going to have negative effects than positives in the future.
      ARBPOL has only been amended two times in its history. The first was a rewrite and change in scope, the second was an amendment to allow the Committee to dismiss arbs. Both amendments came from the Committee, rather than from the community. That doesn't mean the community can't amend it. But if you look at the texts of those two changes, and compare them to this, one can guess why the Committee route tends to work better. No specific wording has been proposed, and the current vague question already has too many holes (per Bilorv etc), and as such should've gone to WP:VPI in the first instance even if this change were a good idea. Exactly what wording change would be submitted for ratification if this RfC did actually pass? It's unclear, indeed, and that's part of why this is a malformed RfC/amendment request. ProcrastinatingReader (talk) 14:29, 2 April 2021 (UTC)[reply]
    5. ... and Lourdes should WP:DROPTHESTICK. Also Per CrastinatingReader, if you want to change ARBPOL—you do—then follow ARBPOL. ——Serial 10:53, 2 April 2021 (UTC)[reply]
    6. Per Bilorv (substantially) and ProcrastinatingReader (procedurally). No such user (talk) 11:00, 2 April 2021 (UTC)[reply]
    7. This is likely unworkable, and is a general rule crafted in response to a single incident involving a single user. There's no pattern of behavior here that suggests that WP:ARBPOL is in need of amendment. There's a real cost to increasing bureaucracy with rules that either cannot be enforced or will be enforced selectively. Furthermore, the complained behavior already falls within WP:ARBCOND (1). Mackensen (talk) 11:12, 2 April 2021 (UTC)[reply]
    8. Ignoring the rights and wrongs of this discussion venue, as long as there is no leaking of privileged information (which should be utterly obvious, and hasn't happened AFAICS), I don't see why it should be any different from the parties involved (or indeed anyone else) discussing the case. Black Kite (talk) 11:31, 2 April 2021 (UTC)[reply]
    9. Per Serial Number 54129. WP:DROPTHESTICK definitely comes to mind. In general arbcom members are expected to exercise their good judgement and in the overwhelming majority of situations commenting about a pending arbitration case off-wiki is certainly inappropriate. However, creating a formal gag rule is still a bad idea. I can imagine some circumstances, involving some kind of a media inquiry or some significant amount of media publicity affecting a particular case, where a public comment of some kind may in fact be necessary. Arbcom members are elected for a limited term and the best way to hold them accountable is during the next arbcom elections. Nsk92 (talk) 11:38, 2 April 2021 (UTC)[reply]
    10. I fail to see the point of this requirement. * Pppery * it has begun... 11:41, 2 April 2021 (UTC)[reply]
    11. This appears to add too much bureaucracy for what it's worth, and I believe per the above comments (though can't say for sure) that this might be out of process for amending the arbitration policy. – John M Wolfson (talk • contribs) 12:54, 2 April 2021 (UTC)[reply]
      Hi John, this is very much in process for amending the Arbitration policy. As per Wikipedia:Arbitration/Policy#Ratification and amendment, "Proposed amendments may be submitted for ratification [...] having been requested by a petition signed by at least one hundred editors in good standing.". But of course, I appreciate your other comments. Thanks, Lourdes 13:25, 2 April 2021 (UTC)[reply]
    12. Lest we establish a new body of policy defining what constitutes commenting outside Wikipedia. — BillHPike (talk, contribs) 13:54, 2 April 2021 (UTC)[reply]
    13. Would be better to codify this as practice ArbCom members should be expected to follow and use best judgement in, but as others have said, a formal rule sounds like would be heck to enforce (both when and where external public discussion happens, and the difference between a statement "Yes, we have a current case about X but I can't speak to that more" (reasonable expected behavior if asked about a case directly in public) and "Here's all the juicy inside details on case about X." --Masem (t) 13:56, 2 April 2021 (UTC)[reply]
      This...would probably be more compelling if it wasn't essentially the job of ArbCom to police ArbCom. I'm not sure it's reasonable that they will so badly misinterpret the inention of the community in making such as statement. GMGtalk 13:59, 2 April 2021 (UTC)[reply]
      Yes, WP:ARBCOND does make ArbCom as a whole the judge when the conduct of an Arb is at question, but I would assume that this would incorporate community input if the behavior is clearly in a public venue. Obviously if the behavior is something only on private channels, I don't expect the community to be privvy to that until a decision is made. --Masem (t) 16:16, 2 April 2021 (UTC)[reply]
    14. Moneytrees🏝️Talk/CCI guide 14:11, 2 April 2021 (UTC)[reply]
    15. Oppose. Should they be barred from sharing private information obtained during the course of the case? Yes. Should there be a gag order barring them from discussing the case entirely? No. I think it is in everyone's best interest if this whole situation was allowed to end. See also the Streisand effect. -- Calidum 14:13, 2 April 2021 (UTC)[reply]
    16. This proposal is aimed at a single arbitrator, Beeblebrox. Lourdes is upset that Beeblebrox mentioned her real-life identity as a public figure on Wikipediocracy which was publicly revealed by Lourdes in some of her old edits (Note: Beeblebrox never mentioned this information onwiki) After Lourdes made a complaint about Beeblebrox bringing this up at the Arbitration Comittee talk page and about Beeblebrox discussing Arbcom cases offwiki Wikipedia_talk:Arbitration_Committee#Active_arbitrators_discussing_about_arbcom_cases,_and_RL_background_of_participants_in_external_forums as a result of the discussion, the edits were courtesy removed from the logs at her request, but the information had been previously declined to be oversighted, and the edits were public at the time Beeblebrox made his comments. Beeblebrox has apologised, and has stated that he will not bring it up offwiki again. Lourdes is also upset at Beeblebrox for his vote to desysop RexxS in the recent arbitration case. Taking this together, what's obvious is that Lourdes is filing this as a way to get back at Beeblebrox as part of the fallout surrounding RexxS's desysop. Nothing that Beeblebrox has said on Wikipediocracy warrants this kind of action, he did not leak or reveal anything about the arbitration commitee's internal deliberations. This is a clear attempt to forumshop after the Arbitration Committee talkpage discussion went nowhere.Hemiauchenia (talk) 14:19, 2 April 2021 (UTC)[reply]
    17. Oppose As Bilorv said earlier, it's what they say, not whether they say something. I'd be fine in principle with a possible rule stating "Arbs shouldn't talk smack about someone who is currently in an arbitration process", but there needs to be a really compelling reason to try and dictate what a volunteer does outside of Wikipedia Scribolt (talk) 14:27, 2 April 2021 (UTC)[reply]
      Breakfast time, User:OneInStinque[reply]! :)
      What I see in this RfC is a few members of the community lashing out at Arbcom in any way they can because they were upset by the outcome of a recent case. Let’s not forget that is what motivated this RfC. The case was handled with due process and it is closed. What we have now is a small handful of people attempting to rouse community support for a retaliatory sanction against one arb. Would the filer have initiated this RfC if the Arbcom case involved, say, banning an editor she didn’t like? Let’s please not waste any more of the community’s time with this. OneInStinque (talk) 14:41, 2 April 2021 (UTC) — OneInStinque (talk • contribs) is a confirmed sock puppet of Architect 134 (talk • contribs). [reply]
    18. Why don't we just call it the "I'm mad at Beeblebrox" rule and be done with it. This is blatant WP:FORUMSHOP. You don't like something one person did, so now we have to have a sitewide discussion disguised as a policy proposal after two previous discussion did not lead to me being burned at the stake. I thought we had buried the hatchet here, but I guess not. Beeblebrox (talk) 15:21, 2 April 2021 (UTC)[reply]
    19. How public is "public"? Would the clerks IRC channel be restricted even if it is Arbs, current clerks, and former clerks? What about Clerks-l which has Arbs, former Arbs, arb clerks and former clerks. What about the functionaries IRC channel or functionaries-l if an Arb has a question about why something was done a decade ago? Wikipedia is filled with mostly-private spaces that could be considered to be too public by some. Also, this is an extended exercise in lashing out at ArbCom for RexxS's desysop. Finally, this is not how you change ArbPol --In actu (Guerillero) Parlez Moi 15:23, 2 April 2021 (UTC)[reply]
    20. While I can appreciate the point of view, and indeed agree that in many cases doing this would be a bad idea, it would also cover things which are not a bad idea. For example, on at least two occasions I can think remember I've been involved in discussions IRL with an arbitrator about an ongoing case, where they were getting different perspectives on the case than presented on-wiki (e.g. from editors who don't routinely participate in dispute resolution spaces and drama boards) and getting familiar with the background to areas of the project or topics they aren't familiar with. If you believe an arbitrator has acted inappropriately then there are existing process that should be followed, and indeed the proposer did this immediately before coming here. That the process didn't give you the outcome you wanted does not mean the process is broken. Thryduulf (talk) 16:15, 2 April 2021 (UTC)[reply]
    21. I understand, and empathize with, the purpose behind this proposal. But the way I say it, this proposal conflates two different things: arbs making inappropriate comments about a case or its participants elsewhere on the Internet, and arbs making unobjectionable (and potentially very helpful and insightful) comments elsewhere on the Internet. Of course, not everyone will agree where that line is, but obviously inappropriate comments (outing, harassment, etc.) can be (and have been) dealt with under existing policies and procedures. Ultimately it is (or at least should be) up to those of us who vote on ArbCom candidates each December to decide how appropriate their commentary is. I don’t want a situation where, if I ask an arb off-site “why are considering banning/desysoping person X when you opposed banning/desysoping person Y, whose behavior was much worse?” they have to respond with “policy prohibits me from answering you until it’s decided.” I understand why people might disagree, but I think such a prohibition would do more harm than good, especially considering we can always vote out anyone who comments irresponsibly on or off Wikipedia. 28bytes (talk) 16:32, 2 April 2021 (UTC)[reply]
    22. Unneeded instruction creep. Arbs should follow WP:ARBCOND, everywhere. Beyond that I think we can trust elected committee members to exercise good judgement in how they use off-wiki forums. – Joe (talk) 16:38, 2 April 2021 (UTC)[reply]
    23. There might be a case to be made for some sort of limitation on arb com members discussing things outside of the wiki-verse, but this very flawed whatever-it-is is not it. Take the time to formulate the question correctly (so it doesn't need so much modification after going live) as well as taking a step back and getting input from folks not pissed off because of one particular case. Frankly, the look here is not good. I'd be happy to support something well thought out that is well formulated .. but not this created-in-anger and needs-continual-modification proposal. Ealdgyth (talk) 16:50, 2 April 2021 (UTC)[reply]
    24. This proposal, if it was going to amend ARBPOL, should have gone through proper workshopping. I think it's current form, if read in plain language, could cause issues down the line. Arbs are already prohibited from sharing private information. I would encourage them to be particularly careful about marginal information, especially off-wiki. However, I think an absolute prohibition on any discussion (complete gag orders) could cause multiple issues in certain circumstances. I would advise against it. Nosebagbear (talk) 17:06, 2 April 2021 (UTC)[reply]
    25. This proposal would not only be very hard to enforce, but it would also preclude times when certain information about certain cases involving users might involve information which would be impossible for most editors (revdel'd) or admins (suppressed) to see, an thus, effectively worthless to attempt discussion on-wiki. Regardless, it would be different if it was a guideline instead of a moratorium, something akin to "ARBCOM members are encouraged, but not required, to use on-wiki methods of discussing any active cases or sanctions in their official capacities." ~Gwennie🐈｟💬 📋｠ 19:52, 2 April 2021 (UTC)[reply]
    26. Per Scribolt if anything. Acknowledging that this oppose is somewhat pointless since the RFC morphed into a petition; analogies about piss-ups and breweries spring to mind. Jack Frost (talk) 21:14, 2 April 2021 (UTC)[reply]
    27. Urk. Yes, yes, 'petition'; I expect the horrible botchedness of this entire clusterfuck to prevent anyone from doing anything binding with an absolute minority of support anyway. This is almost a procedural oppose. Every single thing from the acceptance of Case/RexxS on was a horrible mistake on the part of all parties where no one comes out looking good and where many wonderful, respectable members of the Wikipedia community, who I otherwise hold in utmost esteem, tripped over themselves to be the worst version of who they are. I suspect Beeblebrox isn't going to make the same mistake twice. I hope no one else here does either, and I hope in a year we're all back together. Vaticidalprophet 22:18, 2 April 2021 (UTC)[reply]
    28. Oppose per ProcrastinatingReader. Setting aside the ARBPOL concerns, this seems like pretty clear WP:FORUMSHOPPING, as far as I can tell. In either case, this RfC is fundamentally flawed. If Lourdes really wants to amend ARBPOL, then I strongly recommend workshopping the proposal first at a bare minimum and wording the proposal in a dispassionate manner. Yeah, I know. It's kind of hard to do when you were wronged by the arbitrator in question, but I would say it's an even stronger reason as to why this RfC should be withdrawn. This just reads like a WP:PRAM-esque airing of grievances. OhKayeSierra (talk) 01:37, 3 April 2021 (UTC)[reply]
    29. Oppose Ridiculous, petty, and likely to be covered in some mainstream media article if y'all are foolish enough to implement it. Think of the optics if nothing else. →StaniStani 03:09, 3 April 2021 (UTC)[reply]

    Neutral

    1. Is this an application of Sub judice to Wikipedia? How would one enforce it? The arbiters discussing by phone or e-mail (on their list or Arbitration Wiki) would also run foul of this provision. I think that in some cases off-wiki discussion in a public forum would be inappropriate, while is other cases it might be beneficial to get unofficial remarks. In the case of really inappropriate posts, it would end up in a de-arbing (by whatever procedure that is possible), and this RfC would be moot. I think more nuance is required here: where comments are inappropriate, what type of comments are inappropriate, and what sort of sanction would apply to an arbiter who runs foul of this.--Eostrix  (🦉 hoot hoot🦉) 07:27, 2 April 2021 (UTC)[reply]
      I'm remaining neutral on this for pretty much the same reason as Eostrix directly above, and will likely strike this and change my !vote if more detail is provided as they have described. ezlev.talk 07:36, 2 April 2021 (UTC), struck by ezlevtlk[reply]
      ctrbs       08:03, 2 April 2021 (UTC)[reply]
      Eostrix, Ezlev, updated to include your views, without changing much of the intent. The proposal includes discussion of active cases by voting Arbs on public forums, not any other kind of private communication between Arbs and other stakeholders. Thanks, Lourdes 07:45, 2 April 2021 (UTC)[reply]
    2. I agree with the general idea that arbs should not gossip about cases they are arbitrating (either on or off wiki). But this needs a lot more thought before we begin to write rules.
      We also need to differentiate between cases where an Arb is acting IN THEIR ROLE AS AN ARBITRATOR, and cases where an Arb is acting AS AN INVOLVED PARTY in the case. Consider the scenario where an arb is in a dispute with non-arbs... the dispute goes to arbitration... and this arbitration ends up being discussed in outside venues. In this scenario, the involved arb is not acting as an arbitrator, but as a disputant. Are we saying that the disputants who are not arbs are free to comment on the case in outside venues (and potentially make accusations about the involved arb), but the disputant who happens to be an arb must remain silent (and so can defend himself/herself or present his/her side of the story)? That does not sound right.
      I could see having some sort of sanctionable “gag order” about active ArbCom cases... but surely it should apply to ANYONE involved in the case, whether they are arbs or not. Blueboar (talk) 15:33, 2 April 2021 (UTC)[reply]
    3. Oppose as written. Being a member of the enwiki arbcom doesn't preclude an editor and a case participant from also being active on other WMF projects where they may have local reasons to discuss each other. Additionally, a committee member shouldn't be barred from participating in a global discussion of any sort on meta-wiki just becuase there is also a local case. The discussion section below suggests that this part could be changed during implementation, in which case I'm neutral at this time on discussions that could occur on public non-WMF venues. — xaosflux Talk 14:41, 2 April 2021 (UTC)[reply]
      Also, what would the remedy/penalty for this be (would someone need to drag the committee member to arbcom)? Would recused committee members be constrained? — xaosflux Talk 14:44, 2 April 2021 (UTC)[reply]
      Moved out of oppose after the last rewrite. — xaosflux Talk 16:10, 2 April 2021 (UTC)[reply]
    4. Arbs should certainly be discouraged from discussing active cases and participants, but I don't think they need to be strictly forbidden. I can imagine a few scenarios where this may be necessary; and trying to enforce a prohibition seems problematic at best. User:力 (power~enwiki, π, ν) 17:48, 2 April 2021 (UTC)[reply]
    5. ArbCom, please get your house in order; loose lips sink ships. SandyGeorgia (Talk) 00:06, 3 April 2021 (UTC)[reply]

    Discussion

    (Non-administrator comment) Just to be clear, when you say outside public forums, you're referring to off-Wikipedia discussion boards, and off other Wikipedia channels like Discord and IRC? —Tenryuu 🐲 ( 💬 • 📝 ) 06:46, 2 April 2021 (UTC)[reply]

    Corrected. Thanks, Lourdes 06:48, 2 April 2021 (UTC)[reply]
    • @Lourdes: Regarding Eostrix's objection in the "Neutral" section, I did not interpret your proposal to mean to cover Arbitrators talking to each other privately by any means they choose. That would mean their internal discussions, whether by phone, e-mail, mailing list, or carrier pigeon, would not be affected. Is that how you meant the proposal? Beyond My Ken (talk) 07:41, 2 April 2021 (UTC)[reply]
    • Thanks BmK. As updated above, the proposal includes discussion of active cases by voting Arbs on external public forums, not any other kind of private communication between Arbs and other stakeholders. Thanks, Lourdes 07:46, 2 April 2021 (UTC)[reply]
    • I am sad that such a thing needs to be discussed. I should be clear without restrictions that talking about a case - which implies talking about living persons - outside that case should be handled with utmost care and caution, voluntarily. --Gerda Arendt (talk) 07:49, 2 April 2021 (UTC)[reply]
    • I'm having a little trouble with the formatting here. Does Support mean that one supports the concept that arbs should not use outside public forums, or does it mean that one supports the arbs ability to do so? With the question asked being Should Arbcom members be restricted from discussing active cases and participants on public forums outside Wikipedia (that is, till the case is open)?, I just don't understand how the answers can be Support, Oppose, and Neutral. SQLQuery me! 08:17, 2 April 2021 (UTC)[reply]
    • Hi SQL. Support means agree with restricting Arbs. Oppose means disagree with restricting arbs. I have added these two words for the benefit of readers. Thanks for pointing it out. Lourdes 08:22, 2 April 2021 (UTC)[reply]
    • "that is, till the case is open" why is that to be the rule? Obviously this is targeted at me specifically, so I feel like I must ask why this, exactly,is how I am to be restricted? Beeblebrox (talk) 08:36, 2 April 2021 (UTC)[reply]
    • In your case User:Beeblebrox! you should be restricted by not being allowed access to anything remotely confidential. You clearly have not the slightest idea of the behaviour expected of an Arb. Giano (talk) 09:31, 2 April 2021 (UTC)[reply]
    • I read this is a typo that should be "until the case is closed". Is it not? — Bilorv (talk) 09:39, 2 April 2021 (UTC)[reply]
    I boldly fixed that, as it seems obvious. Dennis Brown - 2¢ 10:15, 2 April 2021 (UTC)[reply]
    Thank you, both. Lourdes 10:18, 2 April 2021 (UTC)[reply]
    • There are relevant off-wikipedia forums that it is beneficial for them to be able to discuss (IRC and Discord come to mind). There may well be forums that it is not advisable, but I'm not sure cast-iron rules are wise here. Nosebagbear (talk) 09:42, 2 April 2021 (UTC)[reply]
      • To clarify, reading the details a bit more carefully, I realise I should clarify that this was meant for things like case requests or declined cases. If it's a private case then there's only limited groups they should be talking to, and any truly public forum wouldn't be suitable. There are some edge issues, like discussing the outcomes, mixed cases, information that is available publicly, despite the case being private etc etc etc Nosebagbear (talk) 09:55, 2 April 2021 (UTC)[reply]
    • Using the word 'Wikipedia' is odd. So it's OK for a discussion to take place on the French Wikipedia, say, but not Wikidata or Commons? Thanks. Mike Peel (talk) 09:59, 2 April 2021 (UTC)[reply]
    • Hi Mike, would you suggest any alternative that would capture the point better? The question I have put is purely to assess the broad sense of the community regarding off-site discussions of active cases by voting Arbitrators. One could of course scrutinise each word, but I hope the broad idea of the RfC is clear. Thanks, Lourdes 10:13, 2 April 2021 (UTC)[reply]
      "The English Wikipedia" would mean only here, on this project. Do you intend to restrict only committee members from referring to an active case in the scope of something larger like a global discussion on meta-wiki? Are you only trying to prevent discussion out side of all public WMF projects? — xaosflux Talk 11:16, 2 April 2021 (UTC)[reply]
    • @Lourdes: I can't tell which of my two questions you are responding to. What (if any) non-private venues outside of the English Wikipedia are you wanting to exempt? Some examples: Nowhere; the Meta-Wiki; other shared WMF projects (Commons, Wikidata); other WMF projects (the French Wikitionary). — xaosflux Talk 13:32, 2 April 2021 (UTC)[reply]
    • Sorry for being short on the previous response. To be candid, if this passes, I would leave it to the ArbCom's judgement to decide on this. They understand what is best for them, and in what form this should/should not be ratified. Lourdes 14:08, 2 April 2021 (UTC)[reply]
      • @Lourdes: I would suggest 'Wikimedia' plus one of 'projects', 'movement', 'Foundation websites', etc. depending on what exactly you are intending. Thanks. Mike Peel (talk) 14:28, 2 April 2021 (UTC)[reply]
        • You're right. I'm not sure whether now, after the participation of many editors, it would be appropriate to change the wording to, say, Wikimedia projects (given that some others may have voted considering the current wording). Lourdes 14:51, 2 April 2021 (UTC)[reply]
          • I think it would be good to change it, but others may well disagree. Thanks. Mike Peel (talk) 15:12, 2 April 2021 (UTC)[reply]
          • I'm guessing you don't want my advice since you keep trying to convince everyone I'm horrible, but years ago I wrote this essay which details what you should do before and during a policy proposal. Rule number one is to make sure you know what it is you are proposing before going live with the proposal. How to approach issues carefully and considering the details and repercussions is how good policy gets made. Rushing in when you're mad is not. Beeblebrox (talk) 15:37, 2 April 2021 (UTC)[reply]
            • For someone who just voted to desysop an admin who cared about accessibility, you're certainly trying your hardest to violate WP:LISTGAP. Furthermore, your attacks on the editor who proposed this are not acceptable - and quite frankly it's appalling that you think it appropriate to come cast aspersions against this editor simply for some minor wording problems that were quickly improved by community discussion (below) to capture the intended meaning. You've been digging your hole deeper ever since you were called out for your off-wiki activity - and you're now stooping as low as to make veiled attacks against other editors simply for disagreeing with them. This is certainly conduct unbecoming of an arbitrator - while I'm not suggesting you need to agree, you definitely shouldn't be showing up in discussions that started because of your poor behavior and behaving poorly in those discussions by attacking the people who proposed them. -bɜ:ʳkənhɪmez (User/say hi!) 15:40, 2 April 2021 (UTC)[reply]
    • This is a weird RfC. 1) why is an RfC happening on the AN? 2) this does not seem like a valid way to amend ARBPOL, in particular WP:ARBCOND, and it seems inappropriate to try to impose limitations on arbitrators in a backdoor fashion. So I'm not sure the outcome of this RfC is valid anyway (unless this is the petition signed by at least one hundred editors in good standing part?). ProcrastinatingReader (talk) 10:16, 2 April 2021 (UTC)[reply]
    • I just wish it to be known that I am not aware of whatever situation prompted this RfC, so my response is not about any specific circumstance, but about the RfC per se. In answer to other objections, the RfC seems to me to be legitimate, and I don't know why an RfC can't be held at WP:AN -- they're certainly held in much less-traveled areas of Wikipedia and held to be enforceable when closed, and it's advertised on WP:CENT, which it good. If the wording is currently a bit vague, this can be fixed if the RfC receives sufficient support. Beyond My Ken (talk) 11:04, 2 April 2021 (UTC)[reply]
    Side discussion on venue change from AN to VPR
    • Comment Just in case anyone reading this doesn't realize, I am an arbitrator - I want to get that disclosure out of the way up top. I had no idea until I reached the discussion that this was intended to be a petition to amend ARBPOL. I thought it was instead an advisory RfC. Since this is intended to be a petition that should be made clear - for instance the opposes don't mean anything. I've opposed ARBPOL amendment petitions before so that's fine but everyone should be clear what is going on here and that is, I feel, very much not the case. I would ask that the wording that this is a petition to amend ARBPOL be made clearer and the people who've participated before this clarification should be told so they may change their participation if they wish. I also suggest the wording of the CENT notification be changed. Second, as worded and read at its most literal it will prevent Arbitrators from using the listserv or ArbWiki for the case. It would prevent drafting arbs from using voice chat with each other when discussing the draft decision or prevent them from conferring with each other via email over a request made to, for example, have an extended word limit. Read slightly less literally it would still prevent arbs from telling clerks to do something related to a case on IRC. All of these limitations would severly impair the ability of the committee to work and seem like unintended consequences from the way this was worded. Barkeep49 (talk) 14:47, 2 April 2021 (UTC)[reply]
      Barkeep49, Petitioning Arbcom is advising Arbcom. And since by policy: "Wikipedia's policy and guideline pages describe its principles and agreed-upon best practices. Policies are standards all users should normally follow, and guidelines are generally meant to be best practices for following those standards in specific contexts. Policies and guidelines should always be applied using reason and common sense." This is often shorthanded to respect the 'sprit of policy'. So, Arbcom members are already expected to be able to not be absurdist literalists, and avoid being zealous infraction Jerverts. Alanscottwalker (talk) 15:13, 2 April 2021 (UTC)[reply]
      opening a petition to revise arbpol, which is what is desired here, has a very different impact than advising on community sentiment. And while I think the community elects Arbs who are not Javerts, intent gets washed away with time while the plain language remains with plenty of editors who are perpetually wary of Arbcom and their actions. I think critics and watchdogs have value but it would still be nice to avoid a situation where they rely on the plain language of a policy while others are like "no you have to look at intent." Best, Barkeep49 (talk) 15:46, 2 April 2021 (UTC)[reply]
      Barkeep49, What's the worst that could happen? Let's assume this gets in word for word (and that the consensus gathering is it has to be exactly these words), even long before it is ever applied, if the committee wants to tweek, they still have ways to tweek it. -- Alanscottwalker (talk) 15:57, 2 April 2021 (UTC)[reply]
      For the first time in history the community amendment option is successfully exercised at ArbPol and you think there would be tolerance for ArbCom putting forward tweaks? I don't think that's the case and indeed think it would be easier to try and get reasonable changes made now - as has happened - rather than after the fact. To me this whole process has worked how it should - an idea was put forth, concerns were raised not on the intent of the idea but the wording, the idea was adjusted in light of those concerns, and now the idea can continue to be considered for what it philosophically is trying to do. Best, Barkeep49 (talk) 16:11, 2 April 2021 (UTC)[reply]
      The proposition has been stated as a question, so it could never go in word for word into policy. And until the close is done, we don't know what the close will say about wording. In consensus, the consensus is not found in the proposition alone, it's found in the discussion. Alanscottwalker (talk) 16:18, 2 April 2021 (UTC)[reply]
    • I suggest a simple change in wording that captures the original meaning in my opinion: Should Arbcom members be restricted from discussing active cases and participants in such cases in public, non-WMF affiliated locations while the case is ongoing? - this allows for any WMF-affiliated location to be used (be it meta, a different WMF wiki, list-serv, etc) - and it also allows for the arbitrators to determine in their own best judgement, when private communication is necessary, where such may take place - i.e. it doesn't restrict their private communications amongst each other or between them and parties to cases. I think this is what the original question was designed to ask... but maybe I'm just confused. -bɜ:ʳkənhɪmez (User/say hi!) 14:51, 2 April 2021 (UTC)[reply]
    • I am in agreement with Berchanhimez over the wording change. Let me ping xaosflux and Mike Peel on their views. Barkeep49, would this wording p roposed by Bechanhimez satisfy your working requirements? Please advise. Also, with respect to the petition, I'll amend the top and ping all participants, but it would be good to get your comments on the wording before I do that. Thanks, Lourdes 15:10, 2 April 2021 (UTC)[reply]
      Yes I think that revised wording would alleviate my concerns about the ability of the committee to operate and manage cases as is done now (and doesn't appear to be what is intended to be restricted). Barkeep49 (talk) 15:14, 2 April 2021 (UTC)[reply]
    I put more in a contingent oppose above. In general, I don't think volunteers that are members of the enwiki arbcom should be saddled with WMF-wide interaction discussion bans on other projects with everyone that is a "participant" in a case here. — xaosflux Talk 15:18, 2 April 2021 (UTC)[reply]
    My interpretation of "discussing... participants in such cases" implies discussing the case or related facts with them - not simply interacting with them as a whole - and again, my proposal only applies "off-wiki" completely - thus you don't have a WMF-wide interaction ban with them, you simply have a "don't comment on them at all off wiki while the case is in progress" ban - which should be common sense. -bɜ:ʳkənhɪmez (User/say hi!) 15:24, 2 April 2021 (UTC)[reply]
    • Or else! Assuming this was passed, what would be the expected remedy/penalty for violations? — xaosflux Talk 15:20, 2 April 2021 (UTC)[reply]
      WP:DR. -- Alanscottwalker (talk) 15:23, 2 April 2021 (UTC)[reply]
      @Alanscottwalker: yup, that's gonna be fun! — xaosflux Talk 15:29, 2 April 2021 (UTC)[reply]
      People are already aware that disagreements are sometimes, and sometimes often, not fun. And in the Arbcom area, in particular, it's hard to think of anything most anyone thinks is fun, or fun! -- Alanscottwalker (talk) 15:35, 2 April 2021 (UTC)[reply]
      • So I assume the proposed changed wording is okay with you Xaosflux? To your second query, what is the remedy if an ArbCom member does not follow current policy on expected conduct? Lourdes 15:24, 2 April 2021 (UTC)[reply]
      • @Lourdes: I don't love it, but it is a bit better. Specifically, I think this is overly broad to include any "participant" (as opposed to just "parties"), but if that is the issue to be decided on then so be it. — xaosflux Talk 15:29, 2 April 2021 (UTC)[reply]
    • Act In Haste, Repent At Leisure springs to mind. The RfC was created, modified, relocated and is now being amended by a random group of editors with or without axes to grind. It's being changed from an RfC to a petition now, is it? Wow, what a shambolic way to make decisions. Leaky caldron (talk) 15:21, 2 April 2021 (UTC)[reply]
    • I thought I had seen just about everything on Wikipedia, but this really takes the biscuit. We have an arbitrator who posts about a case on a trolling forum because it is not expressly forbidden and another who insists that there is nothing wrong with that. Don't these people have the slightest bit of common sense that would tell them that there is something wrong with that? I'm not pretending to know what should be done about this matter, but I do know that we now have at least two members of the arbitration committee who nobody can trust to behave appropriately in dealing with cases. I hope other more sensible members of that committee will have the guts to come off the fence and say the obvious. Phil Bridger (talk) 15:31, 2 April 2021 (UTC)[reply]
    • I spent ages, with several edit conflicts, fixing this up but was undone by Hemiauchenia with an edit summary expecting me to fix things. No, I do not have more time than you, and you shouldn't expect so. Phil Bridger (talk) 16:04, 2 April 2021 (UTC)[reply]
    • Phil Bridger am I the second arb you refer to in this comment? Because I very much have not insisted that there's nothing wrong with it. I have instead tried to make points about how the intent of this idea could be expressed without hindering the committee and how it can be made clear, under policy, what is happening. Best, Barkeep49 (talk) 15:38, 2 April 2021 (UTC)[reply]
      No, you are not who I was referring to. Phil Bridger (talk) 15:42, 2 April 2021 (UTC)[reply]
    • A comment directed at no one individual but those opposing as a whole - please seriously reconsider whether you are opposing because of how and by whom this was put forth - or whether you're opposing because you actually think it should be acceptable for this sort of behavior to can occur. I've seen people who oppose such a rule (both on this page and elsewhere) saying that they oppose this because it is "retaliatory" - to which I say that if this is simply when this was recognized, then it doesn't matter. Furthermore, even if the exact wording is not something you agree with, remember that this is just a petition for Arbitrators to change their own policy - it is not set in stone, and wording can be discussed - the arbitrators have final say on their policy anyway, so I'm sure they'll do their best to make sure that it captures the community's guidance while not being ambiguous or restrictive outside of reason. Put simply, please rethink whether you actually are okay with this behavior or not - because many opposes say "this shouldn't be necessary to prevent this", yet apparently it is as multiple arbitrators have either violated this or condoned the same. If that's not proof a rule is necessary to codify what should be common sense, I'm not sure what would be. -bɜ:ʳkənhɪmez (User/say hi!) 15:34, 2 April 2021 (UTC)[reply]
      @Berchanhimez: A comment directed at no one individual but those opposing as a whole - please seriously reconsider whether you are opposing because of how and by whom this was put forth - or whether you're opposing because you actually think it should be acceptable for this sort of behavior to can occur. I am not opposing because of who proposed it, I am not opposing because of how it was proposed (although that is far from ideal), but I am also not opposing because I think the type of behaviour that Lourdes has alleged Beeblebrox engaged in (and which Beeblebrox has denied engaging in - I haven't looked closely enough to have my own opinion about what happened) is acceptable. I am opposing because it is so poorly worded that it would prohibit an awful lot more than just that sort of behaviour, much of which is, in at least some cases, a Good Thing. Not only would it throw out the baby with the bathwater, it would also throw out the bath and remove the discretion of arbitrators to decide whether the baby, bath and/or bathwater actually should be disposed of in any given situation. Furthermore there are already rules that prohibit arbitrators engaging in the sort of behaviour this proposal is intended to prohibit. Thryduulf (talk) 21:45, 2 April 2021 (UTC)[reply]
      My comment was directed at people who opposed because of "poor wording" but appeared to support the idea as a whole. It was not directed at any one oppose vote, but at a trend I identified in the oppose votes, where many of them are based solely on specific wording while still agreeing that it's not okay. I think a new RFC/petition may be necessary yes, due to this, but I figured I'd mention this as a comment. I agree with you that there are already rules prohibiting this - but then why are arbitrators not initiating proceedings against the arbitrator who's already violated this? Either they're too unwilling to investigate one of their own (which is another issue), or maybe (AGFing here) they simply don't realize the community considers this behavior unacceptable. In the second case, this proposal here, where even about half the opposes say "yeah, this shouldn't be okay, but this proposal is unnecessary" - which leads to about a 70-75% community consensus behind the idea that it's not okay (including supports) - this should show them that they need to act on it as a violation of the rules they already have in place. -bɜ:ʳkənhɪmez (User/say hi!) 23:43, 2 April 2021 (UTC)[reply]
    • @Phil Bridger: (and others) is the lack of rules the problem here? Wikipedia:Arbitration/Policy#Conduct_of_arbitrators lays out expectations for committee member behavior already (...Act with integrity and good faith at all times..., if there is a serious question about such behavior that the current process incapable of dealing with it? — xaosflux Talk 15:38, 2 April 2021 (UTC)[reply]
      I do not think that it's the lack of rules that is the problem, but a complete lack of moral compass amongst certain people [in a certain person] who have [has] been elected to pass judgment on us. Phil Bridger (talk) 15:45, 2 April 2021 (UTC)[reply]
      There is a serious question about such behavior and the current process' ability to deal with it - the current process of arbitrators being unilaterally enabled to decide what is "with integrity and good faith" has obviously failed, since even among oppose !votes many of them express that the act is unacceptable, but this proposal doesn't float their boat. From my reading, at least 70% of people commenting are against arbitrators participating in off-wiki discussion of current cases that they haven't recused from - with varying levels of exception. Not to mention that the arbitrator who spawned all this commented here with basically a this would be hard to enforce, so don't even make it a rule (so I can keep violating the unwritten rule). Not a single arbitrator has proposed a motion, admonishment, or removal of that arbitrator from the committee. As such, it's clear that ArbCom itself is incapable of interpreting "integrity and good faith" as the community wishes them to - because it's clear already that while this exact proposal/wording isn't fully supported, that a decent majority believes that arbitrators should generally not be commenting on active cases off-wiki. So yes, until/unless ArbCom decides to "police its own" and provides public indication they are doing so, this is necessary. Note that I don't personally care what happened in the RexxS case, as that's a separate issue - but the arbitrator(s) actions during and after that case have brought this issue to light. -bɜ:ʳkənhɪmez (User/say hi!) 18:48, 2 April 2021 (UTC)[reply]
      @Berchanhimez: has anyone started WP:DR (even by skipping all the way to the end) against a committee member that they think has violated arbcom policy? — xaosflux Talk 18:53, 2 April 2021 (UTC)[reply]
      Xaosflux, the community cannot remove arbitrators, only the arbitrators can. Multiple people have attempted to engage the arbitrator in question - he has doubled down on "I did nothing wrong" and even ventured into violations of WP:NPA against those who are attempting to tell him he is in the wrong. I am curious what steps other than explicitly requesting ArbCom make this explicitly clear in their policy you think have been skipped? Other noticeboards cannot do anything to remove an arbitrator from their position. To be quite blunt, if ArbCom would step up and initiate a motion to remove or suspend the arbitrator in question, this would be moot for now. That is, until this or another arbitrator thinks it's "acting with integrity" to participate in troll/harassment sites and to discuss active cases they are participating in. That's not integrity in anyone's definition. Sure it's hard to police, but that doesn't mean we should ignore what is obvious and blatant. -bɜ:ʳkənhɪmez (User/say hi!) 19:01, 2 April 2021 (UTC)[reply]
      @Berchanhimez: community members should be able to initiate an arbitration case against an arbitrator as a party to force the issue. If it is a bona fide complaint and the committee declines the case, it should be with a reason why it can actually be handled elsewhere. — xaosflux Talk 19:07, 2 April 2021 (UTC)[reply]
      Sure, they can do such, but the Committee should also, per their own procedures, be doing this themselves. I suspect that nobody wants to file an arbitration case if the committee should (and might) decide to take action on their own prerogative. Furthermore, this proposal ensures that, even if a case is necessary this time, the arbitrators have encoded in their policies that this sort of behavior is not "integrity and good faith", thus they will never again have to wait for a case to be brought. If you're seriously suggesting that an arbitrator should get away with gross violations of integrity and neutrality by participating in an active case while discussing it with a forum including banned editors - just because nobody has the balls to file an arbitration case against a sitting arbitrator, then that's crazy imo. Nobody wants to have to go through a case - it is a last resort - and I think trying to clarify the arbitration policy (or convince them to take action under current policy) is a last step prior to arbitration itself. -bɜ:ʳkənhɪmez (User/say hi!) 19:13, 2 April 2021 (UTC)[reply]
    ​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​This is a hidden ping to previously commenting editors to inform each one of them that post their comment on this RfC, the original wordings have undergone a change. Importantly, the previously placed question – "Should Arbcom members be restricted from discussing active cases and participants on public forums outside Wikipedia (that is, till the case is closed)?" – has undergone a change. Requesting your eyes on the top once again for your review. Thank you for your consideration. Lourdes 15:57, 2 April 2021 (UTC)[reply]
    @Lourdes: When you change existing wording like that, it may be somewhat more clear if you srike the previous text and underline the new text. GMGtalk 16:02, 2 April 2021 (UTC)[reply]
    You're right GMG. The issue is, new editors may just get confused seeing significant strikes. I have added the previous query to the hidden ping statement. Apologies for this quick-fix. Lourdes 16:18, 2 April 2021 (UTC)[reply]

    convenience break

    • I'd like to present a hypothetical scenario for consideration. Let us assume this already passed, and also that I had not recused from the current case request. Now let's say I were to post on one of the Reddit forums dedicated to Wikipedia the following "I was surprised at the sudden accusations of racism". No private info, no personal attacks, just my honest reaction to a weird aspect of a case. By the wording of this rule, I would have broken policy by saying that, but only because I said it where I said it, not because there is anything else at all wrong with it. Is that really something we want to start doing? Who is going to police every single off-wiki forum to make sure no arbs are commenting in any of them in a manner that goes against this gag order? What are the penalties if the gag order is breached? Beeblebrox (talk) 16:21, 2 April 2021 (UTC)[reply]
      • Geez, so because you feel it’d be hard to enforce it shouldn’t be a policy? That’s the complete opposite of acting if integrity - you basically just said “well it’d be difficult to monitor so I can do it!” Absurd. You really need to step back and see that even about half of the opposes here say this is inappropriate behavior for an arbitrator - making it around 70-80% of the community as a whole. Please stop digging and attacking others for attempting to codify what should be common sense - but apparently not your common sense, just everyone else’s. -bɜ:ʳkənhɪmez (User/say hi!) 16:51, 2 April 2021 (UTC)[reply]
        "attempting to codify what should be common sense" this is why WP:BURO exists. Beeblebrox is asking on-point questions because this is the sort of crap that will happen if this is codified. Headbomb {t · c · p · b} 17:48, 2 April 2021 (UTC)[reply]
      • OMG I expect arbs to know what discretion is without having the community explain it to them. Ideally arbs who have trouble understanding what discretion is would just resign, and ideally other arbs would encourage them to do so. I would have stayed out of this until I saw that you are still talking about this RFC on WO. It's like a bad addiction to gossip. Stop doing this ffs. Levivich harass/hound 16:57, 2 April 2021 (UTC)[reply]
        • My point is that this is a half-baked, dangerous proposal with significant risk of needless drama, for little benefit. I also wasn't aware that the gag order has now been expanded (in your mind at least) to include policy proposals. Beeblebrox (talk) 17:47, 2 April 2021 (UTC)[reply]
          • That you're referring to the concept of exercising some basic discretion as a "gag order"... I'm embarrassed that I voted for you. Levivich harass/hound 18:00, 2 April 2021 (UTC)[reply]
        @Levivich: the point is that this proposal would remove a lot of discretion arbs currently have. Whether it was or was exercised correctly in any given instance is not relevant. Thryduulf (talk) 18:22, 2 April 2021 (UTC)[reply]
        • Exactly. Look, I've heard what people have said. I told Lourdes that I understood her concern and would not make further comments of that nature. So I was a little surprised to see this after that. I am open to criticism, I'm very aware I am not a perfect person. And, should I decide to run again, if this incident tanks my candidacy, so be it. That's fair. But this .... I don't think anyone even knows what this even is at this point, but it was clearly not well thought out before being proposed. Knee-jerk rule making is particularly prone to unintended consequences. Beeblebrox (talk) 18:36, 2 April 2021 (UTC)[reply]
    • I hope it doesn't get so far that we have to find out. The current gig is a joke: started off at AN, now at VPP; started off as an RfC and is now a petition (or is it the other way round?!); started off saying one thing, now says another. Etc. And that's before getting into the weeds of the RexxS context. Still, at least the planning matches the execution. ——Serial 16:37, 2 April 2021 (UTC)[reply]
    • I sort of asked this in my !vote above... but it is worth asking again: Why is this focused purely on Arbitrators? Why not simply say that ANYONE involved in an ongoing ArbCom case (whether they be arbs, disputants, involved editors, etc) should not discuss it outside of approved channels? Blueboar (talk) 18:02, 2 April 2021 (UTC)[reply]
      @Blueboar, I think that the distinction is primarily about the power imbalance. You wouldn't want a real-world judge live-tweeting about witnesses that appear in a courtroom, or a professional arbitrator gossiping about a divorcing couple on a social media site. That kind of behavior doesn't show respect for either the participants or the process. Editors don't want ArbCom members to treat them disrespectfully when they feel like they're involved in a high-stakes, emotionally charged ArbCom case, either. WhatamIdoing (talk) 02:07, 3 April 2021 (UTC)[reply]
      I would not want ANYONE involved in an active court case live tweeting about it. Not the judge, not the disputants, not the lawyers... no one. Blueboar (talk) 02:30, 3 April 2021 (UTC)[reply]
    • I also asked about this in my Oppose vote (≠3). What about any involved functionary participating in any formal setting, RfA, 'Crat Chat, AN/ANI? They also contribute at WO. Leaky caldron (talk) 18:13, 2 April 2021 (UTC)[reply]
      • A more general WP:DECORUM guideline would make more sense than this narrowly-tailored change, which feels half like a vote to admonish Beeblebrox. User:力 (power~enwiki, π, ν) 18:15, 2 April 2021 (UTC)[reply]
        Half? Vaticidalprophet 22:31, 2 April 2021 (UTC)[reply]
    • Ah, I see that Lourdes has "clarified" things for us; this is now both an RfC (requiring a ~two-thirds majority in favour) and a petition (requiring a 100 supports and ignoring opposes). I think we're through the looking glass, people... ——Serial 18:27, 2 April 2021 (UTC)[reply]
    • On reflection, no, I don't think it's quite as clear cut as Lourdes suggests (perhaps unsurprisingly, as they only highlighted one sentence). It does seem odd, doesn't it, at first glance, that arb com—of all people on the English Wikipedia!—would renounce WP:CONSENSUS in favour of brown numbers, and a careful read of ARBPOL supports this interpretation. The first paragraph states: this policy will undergo formal ratification through a community referendum and will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it(my emph); that makes it clear that the 100 supports must be a majority, not 100 supports regardless of total !vote. Regarding proceedings such as this, it is clear that Amendments to this policy require an identical ratification process. Then comes the line that Lourdes quotes above; but it is clearly intended to be read as continuing the procedure as laid out originally.
      TL;DR: So yeah, consensus still rulez OK, people. ——Serial 18:41, 2 April 2021 (UTC)[reply]
      Except this is the first part of a two part process. This is attempting to see if 100 users request the change. Once that happens we have a ratification vote where there is a simple majority approval with at least 100 editors in support. So in that second step opposes would matter but for now we're just seeing if it can get 100 signatures. So the people opposing here are doing so more under "moral oppose" grounds than to actually haven effect. Personally I think the amendment process needs some cleanup - for instance I think there should be time limits so we don't get a Twenty-seventh Amendment to the United States Constitution situation but have also been of the opinion that it can wait until the next time ARBPOL needs to be amended for something else. Best, Barkeep49 (talk) 19:29, 2 April 2021 (UTC)[reply]
    • I'm seriously, honestly trying to parse this out. As worded, an active arb could go over to say, Meta, and post about an ongoing case, say some general remark like "this case is not going the way I thought it would." That's allowed, because it's a WMF site. If that same arb were to go make that exact same comment on reddit, that's not allowed, because it is not a WMF site. If the arb in question is recused for any reason, they can go ahead and say the same comment anywhere they like. I'd honestly like to know why an anodyne comment like that is somehow harmful when posted in one place, but not in another, harmful when active, but not when recused. Beeblebrox (talk) 19:28, 2 April 2021 (UTC)[reply]
      That's interesting. You're "seriously, honestly trying to parse this out" yet you've spent the last few days attacking anyone who is trying to explain it. I'm glad you've finally came to the realization that you should be listening and discussing instead of defending. That being said, it's simple: appearances. Wikipedia editors can be expected to have a relatively decent knowledge of the fact that there may be other projects other than the English Wikipedia, and discussing pertinent information to a case on another WMF project is in the spirit of cross-collaboration - for example, cases which have evidence of cross-wiki abuse or would require steward input (removal of bureaucrat, for example). It's not that the comment itself becomes harmful if posted off-wiki, but Wikipedia editors shouldn't have to look off-wiki to find an arbitrator's comments on a case. You signed up to be an arbitrator to serve the community - and part of that is appearing impartial and with "integrity and good faith". If you have opinions that you wish to make off wiki and you don't even let people know on wiki that you're making those comments, it appears very highly that you're either trying to hide something, or have conversations that are not permissible on wiki for whatever reason. I didn't say you are doing either of those, but that is exactly what it appears like. Let's ask you this - point blank - why did you post each post at that forum that you did, instead of holding discussion onwiki? If the answer is because the person you responded to was banned, you shouldn't be discussing your opinions on cases with banned users off wiki and if you have to ask "why not", you shouldn't be an arbitrator. If the answer is because "it was easier", well tough, tell them to come on wiki to discuss the active case with you in the interest of full transparency and record keeping. You have an extra burden to bear as an arbitrator active on a case - you are the judge of someone - and doing things like this seriously calls into question your "integrity and good faith" - even if you don't discuss any private information or remedies specifically. I count a couple dozen users who have at this point said this should be common sense - so I'm sorry, but if you don't get it at this point maybe it's time to step back and reconsider whether you understand what being an arbitrator entails - since you seem to forget that you should be the pinnacle of integrity and transparency if at all possible - which posting off-wiki doesn't provide. -bɜ:ʳkənhɪmez (User/say hi!) 19:36, 2 April 2021 (UTC)[reply]
    • Actually, Serial Number 54129, I think it now makes even less sense. Some of Lourdes' comments (and others') (eg [4][5]) seem to imply some editors think this is going to the Committee who will then draft up a wording and propose it for ratification, but surely that's not what this is? Despite the edits to this proposal, it still feels like the proponents don't really know exactly what they're asking for.
      Wikipedia:Arbitration/Policy § Ratification and amendment appears to describe the process for amending the policy. I imagine the community process works something like this: rather than the ArbCom motion method, a specific change (like this) is proposed and at least 100 editors must support that change. That change is then submitted for community (not ArbCom) ratification, which must receive at least 100 supports and a simple majority of supports. But since there's no actual change proposed here, how exactly are we meant to ratify a question? (unless Lourdes expects the RfC closer to write up the text for the change?) And then there's the issues of clarifying niche cases, and deciding what enforcement should be expected (should removal of arbs be invoked for breaches). It doesn't seem like everyone is on the same page with regards to the details here. For amending something as 'professional' and well documented as ArbCom, this whole section has devolved into a bit of a clusterfuck. I'd be surprised if anything productive comes from it, and even if it does it would be far more productive (and time efficient) to withdraw and workshop up a clearer change which addresses the questions/concerns. ProcrastinatingReader (talk) 19:51, 2 April 2021 (UTC)[reply]
    • After 17 years editing here, I’m amazed that this debate is even necessary, I always assumed this was a rule. Arbs, their clerks or anyone connected to them should not be discussing any case before, during or after anywhere but on Wikipedia. Any other site (even bona fide associated projects and sites) should be completely off limits for such gossip because once such subjects leave Wikipedia, scurrilous gossip is all it is, and it benefits no one. To be respected and for the Arbitration system to work, Arbs have to be like Caesar’s wife, if that’s too much of a struggle for them, then they need reminding the position is voluntary. Giano (talk) 20:11, 2 April 2021 (UTC)[reply]
    • As I mentioned in the earlier discussion on this topic: The default assumption is that editors can fully participate in the English Wikipedia community solely through engagement on this website. I think all editors need to be wary of contributing on other venues, including mailing lists, IRC channels, and other websites (including other Wikimedia Foundation websites), in a manner that affects this default assumption. If significant insight, influence, discussion, or other advantages can only be gained by participating elsewhere, I feel this increases the demand on time and access being requested of the community. I don't know if this needs to be written in policy, but I personally think it would be better to avoid changing the baseline for participation. isaacl (talk) 20:21, 2 April 2021 (UTC)[reply]
      • I don't think excessively pushing for a code of silence helps the project or contributors. User:力 (power~enwiki, π, ν) 20:55, 2 April 2021 (UTC)[reply]
        In my previous comments, I said that in real life, people discuss things in all sorts of places, and there's nothing wrong with that. Nonetheless, I feel editors should be aware of the potential effect of increasing the number of required venues for engagement in order to be full participants in English Wikipedia. isaacl (talk) 21:00, 2 April 2021 (UTC)[reply]
    • The general principle that has been espoused - arbitrators should act with professionalism and discretion - is critical but the current proposal is flawed in many ways that are certain to make it unsuccessful. If this is revisited in the future, I strongly recommend focusing not on the venue(s) in which we expect arbitrators to be able to discuss active cases but a broader principle of limiting discussions to venues, participants, and topics that are necessary and appropriate for the respectful advancement of the case. Or something along those lines that permit arbitrators to exercise discretion but make clear the parameters and principles that should be involved in their decision. We are all volunteers here but that does not mean we should expect or welcome unprofessional behavior, especially from those in positions of heightened trust and authority. ElKevbo (talk) 22:55, 2 April 2021 (UTC)[reply]
    • Arbitrators must be cautious and discreet in discussing any arbitration business and especially so when pending matters are involved. If anyone thinks a reminder of this precept would be helpful, this discussion (which the Committee members are aware of) has provided it. A formal policy amendment is not necessary. Newyorkbrad (talk) 04:44, 3 April 2021 (UTC)[reply]
    Newyorkbrad, your statement is more than enough for me. We can close this RfC/policy amendment here. Thank you for this. Warmly, Lourdes 04:58, 3 April 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Portal needs new section giving latest updates in the portal

    Each portal of the Wikipedia should have two more sections giving 1. new pages added last month and 2. major edits done last month within the scope of the perticular portal. That would assist in knowing the current trends in the subject area. --Dattatray Sankpal (talk) 15:48, 2 April 2021 (UTC)[reply]

    That would be totally unworkable. Most Wikipedia portals are totally moribund; those that are still active, like Portal:History, have such broad scopes that there are probably upwards of 100,000 non-minor edits within their purview in any given month. See a typical Article Alerts page for an idea of just how sprawling such a list would be, noting that Article Alerts only covers major changes in status like deletion proposals, and doesn't include vanilla editing. If you want a list of new articles within a given project's scope, see User:AlexNewArtBot#Currently supported. ‑ Iridescent 16:37, 2 April 2021 (UTC)[reply]

    Redesigning the featured, good, and article assessment icons

    WP:SNOW close. While there have been some in support of this proposal, there has been substantial opposition such that there is no consensus for replacing the current icons with those suggested at this time. There does not appear to be consensus in favour of the changes as proposed, but some are open to reviewing icons individually in their own independent—and well advertised—RfCs. However, the current proposed colour scheme has had issues illustrated by some community members around gray's usual User Interface meaning of "disabled/unavailable/non-applicable" and how geometric differences should be included in the icons to probable alleviate differentiation issues between the icons for those who are colour blind.

    Outside of this close but worth noting: there was also a suggestion in the "licensing" subsection which is a good idea for any future icon uploads. --TheSandDoctor Talk 17:26, 3 April 2021 (UTC)[reply]

    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.

    Related icons
    • Former good article icon
      Former good article icon
    • Good article reassessment icon
      Good article reassessment icon
    • Good article candidate icon
      Good article candidate icon
    • Former featured article icon
      Former featured article icon
    • Former featured article candidate icon
      Former featured article candidate icon
    • Featured article candidate icon
      Featured article candidate icon
    • Article for improvement icon
      Article for improvement icon
    • Good topic icon
      Good topic icon
    • Good topic candidate icon
      Good topic candidate icon
    • Featured topic icon
      Featured topic icon
    • Featured topic candidate icon
      Featured topic candidate icon
    • Former featured topic icon
      Former featured topic icon
    • Former featured topic candidate icon
      Former featured topic candidate icon

    This proposal seeks to establish consensus for new icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status, as well as the variant icons of these (candidate, former featured/good, former candidate). For the sake of consistency, it also proposes new assessment (A-B-C-Start-Stub-List-Disambig) icons.

    Background: There was recently a Village Pump proposal (here) discussing whether or not to change the FA and GA icons. Main issues brought up were the overly detailed FC icon, which causes it to render poorly as small sizes, as well as the confusing GA icon, as it also is used as a "support vote" icon. In short, Support for the proposal outnumbered opposition, 2-to-1. As such, I have created new icons that I believe alleviate these issues. I've made quite a few variants of these icons, a large number of them that can be found here: File:FA-GA icon proposal.png, but for the sake of streamlining this process, I have chosen what I believe to be the most clear and intuitive ones in the proposal. As opinions come in, we can make new proposal sets of icons.

    Proposal 1

    • New icons, Proposal 1
      New icons, Proposal 1
    • Side-by-side with old. Note that the default size of the image is such that the individual icons are 45px wide, which is around the size they would be rendered in talk pages.
      Side-by-side with old. Note that the default size of the image is such that the individual icons are 45px wide, which is around the size they would be rendered in talk pages.

    Key points:

    • FC icons simplified, with GA icons matching the format of FC.
    • GA icons changed to silver, as it is a very natural was to color these.
    • FC/GA former icons have dashed outline of a star, representing that they once held that distinction.
    • FC/GA candidate and reassessment are represented by the same icon, as they both serve the same purpose – assessing whether or not they should be classified as FC/GA.
    • FC/GA former candidates have an "x" representing that there were items not satisfied in the FC/GA criteria.
    • Start and Stub class articles get new icons.

    Support (article icons)

    • Support – As proposer. These icons are simple enough that they will render well as small scales, the new color and matching format for GA makes it clear and obvious that they are related, while FC is clearly a higher distinction, and the new icons have intuition behind them as to what they mean. Pbrks (talk) 21:02, 2 April 2021 (UTC)[reply]
    • Support with the following reservations I highly doubt that non-editors will know what any of this means, nor necessarily should they. In any event, the interwiki list has (I think) silver for a good article in another language (see James Thompson (surveyor)) and gold for a featured article in another language (see World War II for several examples of this). I think the colors should be brought to those respective standards if not already done so. The former article/former candidate, etc., stuff doesn't belong as a topicon and should instead go to the talkpage, IMO.  – John M Wolfson (talk • contribs) 21:16, 2 April 2021 (UTC)[reply]
      • I don't see anywhere suggesting that the former stuff would now be put on the article page (that would almost certainly require its own, separate proposal), I would assume their replacement is with their respective icons on the talk page. Aza24 (talk) 21:22, 2 April 2021 (UTC)[reply]
      • The former, candidate, etc. are only seen on on talk pages. You will only see the "Promoted" icons at the top right of the page. Pbrks (talk) 22:13, 2 April 2021 (UTC)[reply]
    • Support in principle Repeating my earlier comment: The icons should be changed to something the average reader is familiar with. The current icons are nice, but they're nice to Wikipedians. The average reader probably has no idea what this means. We should aim to use images which readers will understand. For example: silver star, gold star. A tick / double tick. Or something along those lines. It should be obvious to a reader what it symbolises. I'm not so sure about this specific set, though. ProcrastinatingReader (talk) 14:04, 3 April 2021 (UTC)[reply]

    Oppose (article icons)

    • Where exactly is the need to replace the current icons with some hideous Web Whatever.0 design? How have I been running into so many "well, everyone in the tiny discussion on VPR supported it" lately? Why did we have a watchlist notice for the worst, most heat-over-light RfC I've seen in my life and yet no watchlist notices for "people want to restrict minor edits to the 99.8625th percentile of editors" or "people have decided the current quality icons are bad for some unclear reason" that have impact on actually writing an encyclopedia? How many of the thirteen people in the prior discussion are highly involved in the article quality process? Vaticidalprophet 22:27, 2 April 2021 (UTC)[reply]
      @Vaticidalprophet: The prior discussion was widely advertised everywhere of relevance short of CENT (including at the article quality forums). I sympathize with the feeling of coming across a discussion I would've wanted to participate in after it's closed, but the rationale behind changing the icons was thoroughly discussed and won clear support, and the process at this point has moved to the next stage. This thread is seeking to figure out how to change the icons, not if we should change them. Let's please not relitigate settled terrain; the whole point of the prior discussion was to resolve that part. {{u|Sdkb}} talk 23:04, 2 April 2021 (UTC)[reply]
      The reaction thus far to this proposal does not sound like "whether to change the icons or not was uncontroversially litigated and everyone who might possibly have been interested decided there was a problem". (There are quite a few prominently missing names in that conversation -- pinging @SandyGeorgia, Ealdgyth, Gog the Mild, Wehwalt, Ian Rose, Casliber, The Rambling Man, Epicgenius, Vami IV, Lee Vilenski, JPxG, Johnbod, and Serial Number 54129 as a small selection of people I might expect to have opinions, and I'm probably missing tons of names.) Vaticidalprophet 23:12, 2 April 2021 (UTC)[reply]
      Never saw the discussion, and don’t see it as having any kind of broad consensus now that I have seen it. People, if you want to keep messing with content review processes at least notify them. This is make work. So while I’m here, Oppose the notion that any change is needed or helpful. SandyGeorgia (Talk) 23:38, 2 April 2021 (UTC)[reply]
      Nor did I, and mildly alarmed to find myself on the "selection of people I might expect to have opinions"! I seem to have arrived here just in time to see the stern of the ship sinking below the waves, so I'll just say that on a quick look the proposal seemed uncompelling. As Martin Poulter says below, the main problem with our icons is that most readers don't know we have them, nor understand them. Can't see this changing that. Johnbod (talk) 03:05, 3 April 2021 (UTC)[reply]
    • With respect, this seems like a solution in search of a problem. Insofar as, right now, readers see the gold star or the green icon in the top right of an article and know that means the article has been through some kind of peer review (which, anecdotally, I know is a benchmark many non-Wikipedia users use, for better or worse, to assess the veracity of an article), why we would want to change that for the sake of our own design preferences is beyond me. Minor cosmetic changes that keep the basic gold star and green icon for the FA/GA classes are fine, but I strongly oppose changing the green icon to something that is a completely different color. Go Phightins! 22:34, 2 April 2021 (UTC)[reply]
    • As well as thinking these changes are unnecessary, I view the symbols as being no more clear than the current ones, and in the case of the good articles, significantly less clear, as well as visualy unappealing. Nosebagbear (talk) 22:48, 2 April 2021 (UTC)[reply]
    • I don't think that the A–Disambig icons need to be changed. Just going to point out that with the change to flat, what about the other 10 icons that will be left with a shadow/3d, nothing quite like inconsistency. The stub/start will probably be harder to differentiate between since the icons are so small. I don't mind the FA/GA but I don't support replacing already acceptable icons. Terasail[✉] 22:51, 2 April 2021 (UTC)[reply]
      • The though process was, if we indeed do come to a consensus for the FC/GA icons, then the other icons (A - dab, the other 10 you are referring to) would/should be changed for consistency. No reason we couldn't keep the start/stub icons the way they look now just without the drop shadow stylization. Pbrks (talk) 23:19, 2 April 2021 (UTC)[reply]
    • There was weak to no consensus for the idea the icons needed to change at all (I never saw that discussion), and this has all the same issues I mentioned back in the other discussion at Wikipedia:Village pump (proposals)/Archive 174 that was broadly attended. Pretty much, the changes aren’t needed, please go write and review some articles people; better yet, please initiate a badly needed GA sweeps. On the surface, it appears that the proposed icons are obscuring the fact that no other content review process except FAC is a community-wide process, rather one person’s opinion at one time, rarely re-reviwed, and seek to elevate GA to the same plane as FA by demoting the bronze star to a gold something the same as GA’s silver. Misleading. Others ahead of me, in this and both discussions, have explained the problems. Or, as Johnbod said once, Oppose per the Opposers. SandyGeorgia (Talk) 23:28, 2 April 2021 (UTC)[reply]
    • I think the proposed logos are not only less clear (grey question mark in a circle means "Good Article Candidate" -- really?), but too childlike and less visually appealing. — Goszei (talk) 23:36, 2 April 2021 (UTC)[reply]
    • Sorry. Respect the effort you've put into this; I understand design is difficult... but I don't like the new icons, particularly for FA. It's generic and fades into the background at small scales. I don't think there's enough padding between the star and the border. I might support a change to the GA icon, but not sure this is the right one. It's unclear what is being communicated to me by the stub and start icons. The changes to the others are fine, but minor. — The Earwig (talk) 23:37, 2 April 2021 (UTC)[reply]
    • I don't know about these. I agree that, overall, the icons used on Wikipedia might benefit from some kind of comprehensive review. For example, the fact that "good article" and "support vote" use the exact same image is a profoundly dogshit situation. Who decided that was a good idea? The distinctions between "FA candidate", "former FA", and "former FA candidate" are also bizarre and non-intuitive (to someone who is not a hardcore Wikipedia editor, these all look like random injured starfish). Moreover, the scale of quality goes magenta, dark green, red, orange, yellow, green, blue, green, yellow. While I agree that some change ought to be made (and there should be an enormous watchlist-pinging WP:CENT about it with several suggestions for icon schemes), I don't think it needs an update, and this one in particular doesn't really spark joy for me. Notably, the "silver" being used to denote GAs is... that doesn't look silver, it looks gray. Also, it removes some good stuff: right now, the jagged former-GA icon very clearly shows that it was a GA and then was "broken", whereas a little dotted star shows nothing. jp×g 23:59, 2 April 2021 (UTC)[reply]
    • I don't think the proposed icons improve over the current ones aesthetically, but there are also more serious problems. The use of a question mark is too firmly associated with DYK and should be kept out of FA/GA icons to avoid confusion. Moreover, the proposed FA and GA icons have exactly the same geometric design and are distingished only by colors. IMO that already renders the entire proposal unacceptable. A substantial portion of our readers are color blind. They will face a great difficulty in telling the GA and FA icons apart and some just won't be able to do so. The FA and GA icons need to be clearly geometrically different from each other, and one should not have to rely on the color scheme to tell them apart. Nsk92 (talk) 00:06, 3 April 2021 (UTC)[reply]
    • I like the icons myself, but I must oppose the changing of the GA palette to gray. It does not and will not stand out against the default white background of Wikipedia. It must remain green. –♠Vami_IV†♠ 00:17, 3 April 2021 (UTC)[reply]
    • Comment Here's an icon for "Rearranging deck chairs on the Titanic": . EEng 03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.[reply]
    • Oppose the need for a redesign in general, and especially the use of gray to indicate a GA. SounderBruce 05:02, 3 April 2021 (UTC)[reply]
    • Oppose. "Ain't broke, don't 'fix' it." One obvious problem with the extreme anti-skeuomorphism that is the current trendy fashion in UI (but which is already seeing a lot of pushback and probably won't last long), is that it can't visually represent gold and silver, they just come out as yellow and grey, since adding white and dark highlights to simulate metallic shine is not possible in an anti-skeuomorphic approach. And grey in user-interface design means "disabled, unavailable, or inapplicable". So, FAIL.  — SMcCandlish ☏ ¢ 😼  05:30, 3 April 2021 (UTC)[reply]
    • Oppose: I do not see a strong enough reason to change the icons. I think Nsk92 raises some very good points about this. Aoba47 (talk) 06:20, 3 April 2021 (UTC)[reply]
    • oppose - some of the individual logos aren't fantastic, but the suggested ones are significantly worse. I'm not here to say that everything we have is perfect, but maybe we should update an image at a time? I agree that the difference between a former featured article, and a failed featured candidate is a bit odd, but then these are generally only used in templates next to where it rights what it means. I do think we would benefit from explaining to users what a good and featured article is (when I first used the site, I got what "stub" and "featured" was, but not much else), but changing the logo designed doesn't help. Best Wishes, Lee Vilenski (talk • contribs) 07:26, 3 April 2021 (UTC)[reply]
    • Oppose. Whatever consensus was reached at the previous discussion, the number of opposing opinions here suggests that it is not very strong. The previous discussion should have been advertised better (i.e. at RFC or CENT). – Finnusertop (talk ⋅ contribs) 08:47, 3 April 2021 (UTC)[reply]
    • Oppose. I actually like the old ones better (sorry). Cas Liber (talk · contribs) 09:37, 3 April 2021 (UTC)[reply]
    • Oppose - this seems to be a solution in search of a problem. I'm not entirely sure what changing the icons will accomplish. ƒirefly ( t · c ) 09:41, 3 April 2021 (UTC)[reply]
    • Oppose at least for now, I want to see the actual proposed image files (see discussion section below) - looks like we only have a picture of the pictures so far? Also, agree that greyscale icons aren't as useful. — xaosflux Talk 10:23, 3 April 2021 (UTC)[reply]
    • Oppose. I am not against changing the icons in principle, although I would want to see much fuller discussion, but the suggested alternatives are hideous. And I agree with the comments that this all seems to be a solution in search of a problem; for example, "the overly detailed FC icon, which causes it to render poorly as small sizes" - I have it at 15px on my user page and it looks fine to me.Gog the Mild (talk) 12:26, 3 April 2021 (UTC)[reply]
    • Oppose. I don't think that the consensus achieved at that October 2020 thread is very strong, judging by the response here. As for the actual proposed icons, gray does not mean "positive" or "good", that's universally green. Question mark is for help. The proposed stub and start-class symbols are too similar. As an aside, I can't wait for this current trend of over-simplifying symbols to go away soon. RetiredDuke (talk) 13:20, 3 April 2021 (UTC)[reply]
    • Opposed (echoed). A consensus of eight is insufficient to change the mechanisms—however superficially—of multiple, highly active projects. Regardless of whether This thread is seeking to figure out how to change the icons, not if we should change them, it looks like you arenow enjoying a consensus to overturn a consensus. Land ahoy! ——Serial 13:30, 3 April 2021 (UTC)[reply]
    • Oppose No need for this. Paul August ☎ 16:22, 3 April 2021 (UTC)[reply]

    Discussion (article icons)

    @Pbrks: (or anyone) can you make a table of before/after for these - that has been quite helpful in similar discussion about icons. — xaosflux Talk 21:18, 2 April 2021 (UTC)[reply]
    @Xaosflux: Yes, I will make them shortly. Pbrks (talk) 21:26, 2 April 2021 (UTC)[reply]
    @Pbrks: do you have these as actual files that are already uploaded that can be in a normal table instead of a picture of a table? — xaosflux Talk 23:45, 2 April 2021 (UTC)[reply]
    • I agree that the icons we use need to change and that they don't make much sense to casual users of the site, which is a loss because markers of quality are really important fo a critical engagement with Wikipedia. When I give training, it is almost always completely new information to people that Wikipedia even has a quality scale. I like the "promoted" and "former" icons, since "gold star" and "silver star" seem like a visual metaphor that people can understand from an early age, across a lot of contexts. The Featured buttons could be in a deeper hue to stand out more, but that's not much of a change. That said, the Candidate icons with a question mark in a circle, look like a "Help" or "Info" icon that a user would click on to get help with the user interface. The Former Candidate icons with a cross look a lot like the "Close tab" or "Close application" of some interfaces: buttons that a user would click to make something disappear. I can see what the List icon represents, but it looks an awful lot like the hamburger menu which is a very common navigational feature of web sites, and is the sort of thing that a user would click on to see a list of preferences or options. These potential confusions mean I can't support this iteration of the proposal, but I do think it is going in the right direction. MartinPoulter (talk) 21:26, 2 April 2021 (UTC)[reply]
    • The star outlines for former featured/good status are very thin—at small sizes I'd guess these are essentially just empty circles, which is presumably not the intention, right? I'd make them thicker. Even a full border (but hollow interior) would be visually distinct enough from current featured/good. At some point it would be good to play around with the individual image files in a sandbox, which you can't easily do with the icons all as one image, though I understand mass uploading of all the icons could be a bit tedious. — Bilorv (talk) 21:31, 2 April 2021 (UTC)[reply]
    • Meta point -- should the bullet points in support/oppose be converted to numbered lists for readability? Vaticidalprophet 00:12, 3 April 2021 (UTC)[reply]

    Taking a step back

    • I started this proposal after a closure request for the previous one decided that the outcome was fairly self evident with support ... editors interested in taking on this work have a mandate to do so. and the request moved forward at the Illustration workshop. It's fine that Prop 1 wasn't held in high regard, but it's just a proposition -- things can be changed, style can be changed. However, it's a bit disheartening and demoralizing to get comments of hideous Web Whatever.0 design and to go write and review some articles instead. I don't understand why people can't just give their opinion without being nasty about it. It's human nature to resist change, I get that, but the fact remains that this renders terribly at 20px and has literally confused people in the past, as it also is used for the "support vote" symbol. Moreover, the subicons for these (particularly the GA icon) don't make much of any sense. The former FC icon has a unsightly, stylistically different "X" through it. The reassessment icon is a broken GA icon? The former GA icon is the same as the former GA candidate icon ? All three of the aforementioned are the same except for color (in which Nsk92 makes a good point about color blindness)? To believe that nothing needs to be changed is beyond me. I don't see much of a reason to move forward with any different kind of proposition given the previous comments. Pbrks (talk) 05:31, 3 April 2021 (UTC)[reply]
      The only argument of the bunch that rings in any way true to me is 's ambiguity, and even that I'm skeptical about -- the only real context I ever see it used to denote support votes is...GAN, where it in fact makes perfect sense. Is hyper-anti-skeuomorphism and a redesign ten people asked for really a better solution than "rename " or just straight up "we have a million support vote symbols, some will overlap"? It's also honestly bizarre to me that the previous proposal was closed as a mandate when it had no participation from the people highly involved in the relevant process, many of who have since come out in strong opposition. Vaticidalprophet 06:17, 3 April 2021 (UTC)[reply]
      (Addendum: readers interested both in the 'million support vote symbols' comment and in why trying to redesign Wikipedia's house styles for icons is both a huge job and a thankless/anti-thanked one are pointed here.) Vaticidalprophet 06:25, 3 April 2021 (UTC)[reply]

    Licensing

    • Ideally, any new icons would be licensed as CC0 or PD so that the icons be used unlinked, without the need for the link for attribution. -- WOSlinker (talk) 09:01, 3 April 2021 (UTC)[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Idea for speedy deletion U6: user pages of users blocked or banned for bad-faith edits

    We have many pages that list problem users and categories for Wikipedia sockpuppets and long-term abusers and sometimes one-off spammers who create user pages. I think users that vandalize or spam or anything of the like should have their user pages deleted as not to glorify them. See also Special:PrefixIndex/Wikipedia:Long-term abuse/ and Category:Wikipedia sockpuppets. We should not be glorifying these users acting in bad-faith. We should have secret administrative pages (probably on an admin mailing list or on Discord) to allow for admins and trusted users to identify socks. Aasim (talk) 05:48, 4 April 2021 (UTC)[reply]

    Like usual, feel free to move this to the idea lab if too early for VPPR. Aasim (talk) 05:49, 4 April 2021 (UTC)[reply]
    CSD proposals should be at WT:CSD but I don't think we need a real large-scale discussion here. This is a bad idea for multiple reasons. Stuff that is relevant to Wikipedia should stay on Wikipedia (barring privacy concerns). There is nothing "glorifying" about telling the whole world that this person violated the rules to the point that they were banned from editing and it helps users to identify problem editors, especially when they return as socks. Regards SoWhy 11:11, 4 April 2021 (UTC)[reply]
    In addition to SoWhy's points, if their user page is spam it can already be speedily deleted (WP:CSD#G11), if it was created by a user in violation of a block or ban it can be speedily deleted under criterion G5, if they're misusing Wikipedia as a webhost then criterion U5 applies. However, most often user pages of sockpuppets and sockmasters are replaced by a notice that notes this status and (in the case of sockpuppets) who their master is; this does not require deletion so your proposal would fail WP:NEWCSD point 2. Thryduulf (talk) 11:35, 4 April 2021 (UTC)[reply]
    Creating a new CSD to hide things is... not really a good idea. "Secret administrative pages" *shudders* Elli (talk | contribs) 11:59, 4 April 2021 (UTC)[reply]
    Apart from pages that already qualify for deletion under U5 or G11, I don't see a need to delete userpages of banned or blocked users. User:力 (power~enwiki, π, ν) 22:20, 4 April 2021 (UTC)[reply]

    Email edit notice update

    Given some of the, ...let's say discussions, at various places lately, I wondered if this idea was worth floating. (if this should be at a different VP section like technical, or something else, I have no objections to it being moved)

    As it stands now there is the last line in the 'email this user' edit notice:

    • Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

    and I wondered if perhaps we should bold that to stand out a bit more...

    • Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

    thoughts? — Ched (talk) 21:55, 4 April 2021 (UTC)[reply]

    Without trying to commenting on any particular situations... Sure, Wikipedia can't guarantee that an editor won't send a message to another editor. But this is true of any site, anywhere. Facebook can't guarantee that the receiver of a "private message (PM)" won't show the message to someone else, Signal (software) can't guarantee a message sent in its E2E encrypted "private chats" won't be republished by a participant, and for all Snapchat gives an alert when people screenshot an expiring snap/image, it can't actually stop anyone screenshotting it. All this is to say, I don't really see the point of this disclaimer. It doesn't really relate to what good etiquette is (and IMO, it's bad etiquette to repost messages sent via that system), and a move towards possibly implying that this is anything but bad etiquette is a bad idea imo. Not even sure I like the existing text that's there, maybe it should be worded in a more nuanced way (but I suspect I'm the minority on this opinion). ProcrastinatingReader (talk) 00:24, 5 April 2021 (UTC)[reply]
    While I'm commenting here, what might be interesting is to see if there's now consensus for some sort of email guideline. Wikipedia:Harassment#Private correspondence indicates previous discussions were no consensus. Some other incidents makes me feel this can lead to bad situations (for example this situation). ProcrastinatingReader (talk) 00:36, 5 April 2021 (UTC)[reply]
    information Administrator note the entire message is stored in MediaWiki:emailpagetext. — xaosflux Talk 00:51, 5 April 2021 (UTC)[reply]
    The line in question was added by AGK with this edit in 2014. I assume this change didn't come out of nowhere but I haven't immediately found any discussion about it. Two days later they added a similar message at User:Arbitration Committee. Thryduulf (talk) 02:20, 5 April 2021 (UTC)[reply]
    Was that around the time that there were all those arbcom leaks posted on an external site perhaps? — Ched (talk) 02:26, 5 April 2021 (UTC)[reply]
    A quick search suggests that the major leak was in mid 2011 Signpost story, with a smaller one in late 2012 Signpost story. That tallies with my memory of leaks not being mentioned significantly in the 2014 elections where I was a candidate. Thryduulf (talk) 02:47, 5 April 2021 (UTC)[reply]
    • It's 2021, and people know what email is and how the internet works. It's not our job to educate them on those things in the editnotice Xaosflux linked. Worse, when the editnotice becomes 20 pages long with every other line bolded,[hyperbole] the main actually-important point—that your email address will be disclosed—gets lost because no one reads the notice. This suffers from the same issue that has made so much of instruction on Wikipedia terrible: the way to improve it is to make it shorter so that people actually read it, not to make it longer and longer until it becomes a manual covering every possible eventuality. There are several lines from the current notice that should be removed, including the reiteration; that's where I would start. {{u|Sdkb}} talk 16:11, 5 April 2021 (UTC)[reply]
    • If I want to e-mail a user, I go to their user page and use the Email this user option in the sidebar menu. The entire text that I am given in the form is then:
      You can use the form below to send an email message to this user. The email address you entered in your user preferences will appear as the "From" address of the email, so the recipient will be able to reply directly to you..
      Nothing more. For me, this seems to be enough. When would I see the text being discussed above? — GhostInTheMachine talk to me 19:27, 5 April 2021 (UTC)[reply]
    @GhostInTheMachine: You probably have your interface language set to British English. I see the same thing at [6]. I'm guessing maybe MediaWiki:Emailpagetext/en-GB should be moved to MediaWiki:Emailpagetext/en-gb. Suffusion of Yellow (talk) 21:27, 5 April 2021 (UTC)[reply]
    Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1016336943"