Wikipedia:Village pump (proposals)/Archive 179

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

RFC: Citation Style 1 parameter naming convention

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.

---

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

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)

  @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)

  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)

  @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)

• 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)
• Option C. This is pointless make work; see extended comment in discussion section. Espresso Addict (talk) 07:08, 11 February 2021 (UTC)
• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)
• 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)
• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

• 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)

  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)

  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)

  Nope. See my response to same claim by Phil Bridger, above.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)

  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)

  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)

• Option C per Phil Bridger. Ealdgyth (talk) 21:28, 11 February 2021 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)

  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)

• Option C per Phil Bridger. SarahSV ^(talk) 02:51, 12 February 2021 (UTC)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
  • 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)

    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)

• 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)
• 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)
  • @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)
    • @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)
• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)
• 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)
• 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)

• To whom is standardization for template parameters important & useful? Phil Bridger (talk) 20:39, 16 February 2021 (UTC)
• 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)

• 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)

  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)

  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)

• 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)
• Option C If it works don't fix it. Andrew🐉(talk) 13:01, 17 February 2021 (UTC)
• 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)
• 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)

  Notwhen it'sjust twowords :-P Levivich ^harass/_hound 08:10, 20 February 2021 (UTC)

  ...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)

• 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)
• 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)
• 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)
• 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. Reywas92^Talk 06:21, 24 February 2021 (UTC)
• Option C. Benefits for bot or template builders don't outweigh the inconvenience for other editors. Fram (talk) 08:13, 24 February 2021 (UTC)
• 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)
• 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)

  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)

• 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)
• 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)
• Option Cper Phil BridgerSea Ane (talk) 21:53, 26 February 2021 (UTC)
• Option C, stop the craziness hitting watchlists (although most of that damage is already done). SandyGeorgia (Talk) 00:58, 2 March 2021 (UTC)
• 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)
• 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)
• Option C per Aquillion. Monkbot should never have been approved --In actu (Guerillero) ^{Parlez Moi} 20:22, 2 March 2021 (UTC)
• 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)
• 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)

  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)

• 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)

  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)

• 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)
• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  "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)

  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)

  "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)

  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)

• 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)

  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)

  "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)

  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)

• 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)

  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)

• Option A / B per above.  Spy-cicle💥  ^Talk? 18:50, 10 March 2021 (UTC)
• 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)

  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)

  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)

  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)

  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)

  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)

• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)

  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)

• Option C (preferred) or Option B (seoncd choice) -Beyond My Ken (talk) 03:06, 23 March 2021 (UTC)
• 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)
• 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)
  • 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)
    • 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)
      • 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)
        • 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)
• 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)
• 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)
• 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)
• 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)

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)

• 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)
  • 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)
    • 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)
      • 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)
        • 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)
          • I would be more sympathetic to such an argument of "significant reputational damage" if there weren't over 100,000 pages with active errors on them (and that's ignoring the hidden Category:CS1 errors: missing periodical) and another 250k in its sister (also hidden). --Izno (talk) 20:22, 15 February 2021 (UTC)
    • 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)
      • 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)
        • 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)
          • 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)
            • 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)
              • 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)
                • 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)
          • 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)
          • 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)
            • 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)

              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)

              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)

              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)

              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)

              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)

              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)

              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)

• 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)
  • 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)
    • 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)

      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)

      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)

      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)

      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)

    • 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)

      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)

• 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)
• 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)

  Thanks for the ping, I was indeed unaware of this discussion. Modest Genius ^talk 12:16, 12 February 2021 (UTC)

• 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)

  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)

  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)

  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)

• 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)

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)

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)

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)

@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)

@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) ... Y, also {{Bach's compositions (sources)}}, which indeed had |author2link =. David Brooks (talk) 21:42, 22 February 2021 (UTC)

• 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)

  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)

  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)

  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)

  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)

  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)

  • 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)

  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)

  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)

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)

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)

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)

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)

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)

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)

Exactly this. — JohnFromPinckney (talk) 02:05, 23 February 2021 (UTC)

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)

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)

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)

(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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

• 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)

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)

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)

• 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)

  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)

  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)

  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)

  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)

  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)

  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)

  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)

  You would be correct good sir! - Floydian ^τ _¢ 15:36, 11 March 2021 (UTC)

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:

• at Special:Preferences#mw-prefsection-watchlist:
  • check Advanced options → Expand watchlist to show all changes, not just the most recent
  • check Changes shown → Hide bot edits from the watchlist
• at Special:Preferences#mw-prefsection-rc:
  • check Advanced options → Group changes by page in recent changes and watchlist

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)

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)

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)

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)

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)

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)

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)

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)

• 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)
• 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)

  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)

• 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)

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.

MJL's close

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.

---

MIXED

Previous discussions

• Help talk:Citation Style 1/Archive 5 § RFC: Citation Style 1 parameter naming convention (2014)
• Wikipedia:Bots/Requests for approval/Monkbot 18 (November 2020)
• Wikipedia talk:AutoWikiBrowser/Archive 32 § Citation parameter renaming (November 2020)
• Help talk:Citation Style 1/Archive 74 § deprecation and removal of nonhyphenated multiword parameter names (November 2020)
• Wikipedia:Village pump (proposals)/Archive 174 § Cosmetic Bot Day (CBD) (December 2020)
• Wikipedia:Bots/Noticeboard/Archive 15 § Monkbot 18 (December 2020)

Summary

This is basically Option B with extra caveats.

---

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 uniform template parameters 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 or semi-automatically 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)

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.

Closure review

NOTE: the closure of this RfC is now under discussion at WP:AN#Closure review request for "Citation Style 1 parameter naming convention" RfC. Fram (talk) 09:44, 8 April 2021 (UTC)

• I undid MJL's close based on the discussion above. It is preserved for the record in the section above. – Joe (talk) 11:02, 14 April 2021 (UTC)
  • While MJL's RFC closure was fearless and difficult, it was unclear in its prose and left a number of implementation-related questions unanswered. I was involved with the RFC and with the implementation of its first closure, so I asked a number of those questions. I am willing to assist a potential closer with drafting a closure, not to put my spin on it, but to ensure that it answers questions that might arise from it and contains grammatical prose. Feel free to ping me. – Jonesey95 (talk) 20:34, 14 April 2021 (UTC)
    • It is a very bad idea to get someone who was seriously involved in the RfC to "assist a potential close", and I hope no one pings you over this. The closure has not been overturned because of unclear or ungrammatical prose, suggesting this already disqualifies you from having any involvement with a new close. If the closers have questions, they can post them here, for everyone, without pings to one party or another. Please don't try to unduly influence the outcome, and please stop replacing these parameters while the RfC is still open. Fram (talk) 07:32, 15 April 2021 (UTC)

    Fram is correct that nobody involved with the RfC, whatever their preference is regarding it, should be "assisting" the closer - we should not be part of the closure process at all. Additionally, I would say that those closely involved with implementing one of the options, regardless of which option, should also not be part of the closure for the same reasons, namely it is extremely important that the close reflects only the opinions expressed in the RFC without bias. Finally, nobody should be taking any action based on this RfC or which would prejudice the outcome of this RfC until it is closed in a manner consistent with the consensus of it. That means nobody should be changing any parameters, nor making any changes that suggest one style or other is or is not preferred, deprecated, will be removed in future, etc. Thryduulf (talk) 10:36, 15 April 2021 (UTC)

As I said, I have no intention of influencing the outcome of the closure. I maintain my offer to provide grammatical and technical feedback on a draft closure in a public forum. Don't we want the best, most reliable closure possible, instead of the somewhat muddied one that resulted from a single person with limited subject-matter experience trying to answer this complex issue? Wasn't the primary complaint about the closure, and the reason for it to be overturned that it didn't [reflect] only the opinions expressed in the RFC without bias? I try to limit my involvement in WP drama like this because it seems to be so suboptimally run, but without at least a little input from people who understand the technicalities and how to construct a grammatical sentence, RFC closures can end up making things worse instead of better (cf. developer discouraged, a adjectival phrase from the initial closure that was both wholly invented and missing a hyphen). It seems like this RFC, if it is to be reclosed as described immediately above, should be evaluated by a group of editors who can give each other feedback, ask questions of editors with relevant subject-matter knowledge, and check each other's work so that we don't end up in this situation again. – Jonesey95 (talk) 14:57, 15 April 2021 (UTC)

Yes, having a group of editors (admins?) evaluate a complicated RFC and work together to create a clear closure is a good idea. HOWEVER, an involved editor should not be part of that group. I am sure your intentions are for the best, but “appearances” matter just as much as intentions. Blueboar (talk) 16:28, 15 April 2021 (UTC)

Discussion at Wikipedia:Categories for discussion/Log/2021 April 16 § Category:CS1 maint: discouraged parameter

 You are invited to join the discussion at Wikipedia:Categories for discussion/Log/2021 April 16 § Category:CS1 maint: discouraged parameter. * Pppery * _{it has begun...} 19:40, 16 April 2021 (UTC)

Possibility to edit for blocked users

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.

---

In my opinion, to avoid the cases of sock-puppets, users blocked should have the possibility to edit a page if the change is approved by a prending changes reviewer. Dr Salvus 21:41, 15 April 2021 (UTC)

This is by far the most ridiculous proposal I have seen in my Wiki-career. Blocked means blocked. Want to edit? Don't get blocked. We can deal with sock puppets as they arise. TAXIDICAE💰 21:51, 15 April 2021 (UTC)

This is not currently possible. If this was possible and implemented for all blocked editors it would put a massive extra workload on pending changes reviewers for very little benefit as nearly all blocked users are blocked for a good reason and few of them use sock puppets. Phab:27400 (lowest priority) and Phab:T240311 (unprioritised) propose allowing whitelisting of individual pages for individual editors, but that would allow normal editing of the given pages. I cannot find a phab task related to configuring pending changes per user. Thryduulf (talk) 22:01, 15 April 2021 (UTC)

• We don't allow blocked users to propose edits on their user talk pages; they shouldn't be allowed to propose them to PC reviewers. If a blocked user wants to edit, they should request unblock. 331dot (talk) 22:06, 15 April 2021 (UTC)
• Blocked users have already proven their utility, or lack thereof, to the project. That being near 0.0. This proposal makes no sense: the time-sink to create this ability versus the negligible gains are not worth it.  ::I want the two minutes it took to comment on this back.:: GenQuest ^"scribble" 16:07, 17 April 2021 (UTC)
• As far as I can see, this won't actually stop anyone making sock puppets though. If their account was found, then it was found, and they will move on onto the next one(s). —  HELLKNOWZ   ▎TALK 16:34, 17 April 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Deletion of own user-pages

In my opinion non-sysops should have the right to delete their own user page. Dr Salvus 12:47, 11 April 2021 (UTC)

You can request the deletion of a page in your own userspace by CSD by WP:U1 Best Wishes, Lee Vilenski ^{(talk • contribs)} 12:51, 11 April 2021 (UTC)

Dr Salvus This is a perennial proposal, with good reasons as to why it hasn't been done. See this section. The main reason not to do it is that users could move articles to their user page and then delete it. 331dot (talk) 12:54, 11 April 2021 (UTC)

Providing we have some sensible precautions such as excluding pages that have been moved from outside your userspace, this is a sensible suggestion that has got consensus at least once before. The problem is with getting IT resource to make it happen. ϢereSpielChequers 08:08, 15 April 2021 (UTC)

• Another option: users definitely ARE allowed to BLANK their user pages. By blanking, the page still exists, and removed content is still available through the page’s history (should there ever be a reason to retrieve it)... however it no longer clutters up what is on seen on the page. Blueboar (talk) 12:21, 15 April 2021 (UTC)
• @Dr Salvus: see the note above, for the most part any user may blank their userpage, and in most cases may tag it for speedy deletion. Anything else would require both software changes and community adoption and policies. With this information available, do you still want to go forward with a proposal discussion? — xaosflux ^Talk 16:08, 21 April 2021 (UTC)

This is a silly idea. Someone could move an article to their userspace and then delete it. There is also no need. TAXIDICAE💰 16:09, 21 April 2021 (UTC)

People can't create a new article on English Wikipedia

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.

---

Hi Wikipedia!

People can't create a new article on English Wikipedia. It doesn't appear the page that contains the link "Start the article wizard" but appears: The page x doesn't exist. You can create as a draft..."

We want to return the option for article wizard page or if not, the drafts created to have an option "Submit the draft for a review" in order to review the draft and move or not on the main articles, which this option doesn't exist on created drafts.

Thanks! — Preceding unsigned comment added by NSHPUZA (talk • contribs) 11:30, 27 April 2021 (UTC)

Once your account has been autoconfirmed (four days old and 10 mainspace edits) you can create pages in the main space. This minor throttling feature is in place to head off unregistered (IP address) and newly registered accounts from abusing the ability to create articles, which can be a cleanup nightmare. Once your account has been autoconfirmed, you can create all the articles you want; the article wizard is an optional process, as is the "Draft and review" process. Newer users (and even autoconfirmed ones) are steered through the draft-and-review process as a means to discourage the creation of a new article that is likely to be quickly deleted, often without explanation. However, once you are autoconfirmed, there is no technical barrier to creating new articles. I would recommend you don't until you learn a little bit about what makes a worthwhile Wikipedia article (see WP:42 and WP:YFA for a short, and long, version of that), but once you reach that 10 edits/4 days threshold, you'll be fine. --Jayron32 14:45, 27 April 2021 (UTC)

@NSHPUZA: Access to the article wizard should be available on any red linked page you are trying to create. For example, click here: Red link demo for NSHPUZA, and at the top of the page (Source Editor) or in the popup notice window (Visual Editor and 2017 Wikitext Editor/New wikitext mode), you should see this message in bold that sends you to the Article Wizard:

• Before creating an article, please read Wikipedia:Your first article. We recommend that new editors use the Article wizard.

Just click the Article wizard link, and it will run you through what it looks like you are seeking. -2pou (talk) 17:14, 27 April 2021 (UTC)

I just checked NSHPUZA's contributions, and this post was tagged "(Tags: Mobile edit, Mobile web edit)". I tested a red link on my phone (in Mobile View), and it does not provide the same access to the article wizard. Perhaps that is the request? I have no idea how easy it would be to try and create an article from the wizard in mobile view, but that may be the root of the question. -2pou (talk) 17:19, 27 April 2021 (UTC)

@2pou: did you scroll down? I just used a mobile browser to go a nonexistent title and under the search results I got the link to use AW. — xaosflux ^Talk 17:54, 27 April 2021 (UTC)

@Xaosflux: Thanks. It looks like the problem was that I was logged in while trying it out. While logged in, it displays the notice window for a split second before going to a text field to edit and no way to exit/view the window. While logged out, as an IP (or presumably non auto-confirmed editor), you're right, the option is presented because in that case, I'm not allowed to directly create in main space. So, NSHPUZA, if not auto-confirmed, the message actually reads this to get to the wizard:

• You cannot create this article. You may need to log in or create an account and be autoconfirmed to start this page. Alternatively, you can use the Article Wizard, or add a request for it.

-2pou (talk) 18:12, 27 April 2021 (UTC)

@2pou: note also that Red link example is a bad example here, as it is creation-protected. — xaosflux ^Talk 18:20, 27 April 2021 (UTC)

Thx. Updated to be more specific and unlikely to be used anywhere else. -2pou (talk) 18:26, 27 April 2021 (UTC)

Mobile-phone editors also get new IPs on each new session, so if you edit from the mobile, your ability to autoconfirm gets harder. Create an account to overcome that issue. GenQuest ^"scribble" 18:49, 27 April 2021 (UTC)

GenQuest, uhhh...none of that is correct (well, except "create an account"). Mobile IPs are fairly dynamic, but they aren't new-one-each-session, and IPs cannot get autoconfirmed, period. ^{SubjectiveNotability} _{a GN franchise} (talk to the boss) 19:02, 27 April 2021 (UTC)

• @NSHPUZA: please see everything above. Article Wizard should be available for new article creation still; if you are not seeing this please post over at WP:VPT for technical support, including the exact steps you are following. Thank you, — xaosflux ^Talk 13:03, 29 April 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Nowrap for scoring within sporting articles

Hi! I've never actually suggested anything here, so excuse me if this isn't quite right, or if this needs to go through a second channel to get some thoughts before the actual proposal can begin. At a recent FAC, it was questioned if sporting scores (or at least the ones on this article), should be enclosed with NOWRAP. I'm not sure if there is a minor part of the MOS that I'm missing, but I didn't see it. I've done a little bit of digging, but didn't find any prior conversations about this. Here's the question:

Should we enclose numerical scores (such as 300—267) in {{nowrap}}? If this has been covered before, or obvious reasons not worth commenting on, let me know. Best Wishes, Lee Vilenski ^{(talk • contribs)} 12:28, 30 April 2021 (UTC)

300—267 has em dash. It should be 300–267 with en dash, but it appears to make no difference for wrapping. Wrapping is browser dependent. Change window width to see where text wraps when there is no nowrap.

With hyphen:

300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267 300-267

With en dash:

300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267 300–267

With em dash:

300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267 300—267

On Windows 10 with current browser versions: Firefox never wraps above. Internet Explorer, Google Chrome, Microsoft Edge and Opera always wrap. PrimeHunter (talk) 13:29, 30 April 2021 (UTC)

Sorry, I mistyped! I am specifically talking about scores such as 10–5, which is what the MOS currently fits, it's not so much as if it currently nowraps, more should we require scores to be wrapped, so they display on the same line for all browsers? Best Wishes, Lee Vilenski ^{(talk • contribs)} 13:36, 30 April 2021 (UTC)

Categorizing Wikipedia Books

This is largely a follow up to Wikipedia:Village pump (proposals)/Archive 177#Deprecate linking to Wikipedia books in templates and articles where it was decided to remove links to the book namespace from articles and templates. This was because books don't serve our readers anymore with the book creator no longer working. There is still one user facing place where there is a significant amount of links to the book space and that is content categories. My proposal is to remove all content categories with articles from Wikipedia books while retaining categories like Category:Wikipedia books on Christianity. Links to other related discussions: Deletion of Template:Wikipedia book (2021) and Supress rendering of Template:Wikipedia books and remove link in sidebar (2019). --Trialpears (talk) 12:44, 23 April 2021 (UTC)

Seems like no one particularly cares about this matter (understandable). I will start removal tomorrow. --Trialpears (talk) 01:49, 1 May 2021 (UTC)

RfC on limiting minor edits

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 debate may be found at the bottom of the discussion.

---

No Consensus - Option B is Opposed; Option A had slightly more support than Option 0, but not enough to say that this has consensus for implementation. Several people wished for a better interface for this, such as better filters or a pop-up description - no prejudice against starting a follow-up rfc for broader discussion of that. - jc37 16:16, 3 August 2021 (UTC)

---

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)

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)

  The aforementioned RfC demonstrates fairly clear opposition to removing minor edits entirely. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:30, 1 April 2021 (UTC)

  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)

  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)

  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)

  Given that the title was to "Disable minor edits" I doubt this. Tol | Talk | Contribs (formerly Twassman) 01:03, 1 April 2021 (UTC)

• 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)
  • 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)
    • 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)
      • 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)
• Support B, then A Johnbod (talk) 00:39, 1 April 2021 (UTC)
• 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)
• 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)
• 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)

  Also, should this have a watchlist notification? Vaticidalprophet 01:15, 1 April 2021 (UTC)

  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)

  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)

• 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)
• Question: What if I don't want to limit minor edits at all? — JohnFromPinckney (talk) 01:50, 1 April 2021 (UTC)
  • Then you would say "Option 0" and set up your own proposal on such a topic, I would think. Aza24 (talk)
    • Option 0, then, as I don't see a compelling reason to limit usage at all, and Option 0 is the closest option to that. — JohnFromPinckney (talk) 23:27, 28 April 2021 (UTC)
• Oppose B No real preference on A or 0. — UwU wug's this? 02:21, 1 April 2021 (UTC)
• 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)

  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)

  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)

  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)

• Support B, then A per Suffusion of Yellow. ProcrastinatingReader (talk) 13:33, 1 April 2021 (UTC)
• Option 0. What problem is this even trying to solve? Thanks. Mike Peel (talk) 14:50, 1 April 2021 (UTC)
• 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 ^(TALK_CONT) 15:08, 1 April 2021 (UTC)
• 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)

  @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)

  Thanks, I noted it above and struck this !vote. — xaosflux ^Talk 23:09, 1 April 2021 (UTC)

• 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)
• 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)
• 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)
• 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)
• 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)
• Support 0 As a sock and vandal detector, the minor edits checkbox is a fantastic honeypot. AdmiralEek (talk) 17:03, 1 April 2021 (UTC)
• 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)

  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)

• 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)
• 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)
• 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)
• 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)
• 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)

  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)

• 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)
• 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)
• 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)

  @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)

• 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)
• Support A Would ensure that editors understand its use. ~ HAL333 17:44, 2 April 2021 (UTC)
• Option 0 I don't get the point of this RfC; status quo is fine. TonyBallioni (talk) 20:32, 2 April 2021 (UTC)
• 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) 01:56, 3 April 2021 (UTC)

• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
• 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)
  • 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)
• 0 It's confusing if the interface changes and we should avoid confusing new users. Andrew🐉(talk) 08:52, 4 April 2021 (UTC)
• 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)
• 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)
• 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)

  +1 for better filtering, searching, and colour-coding in History. Is there some underlying technical reason this can be done in Recent Changes but not page history? Pelagic ( messages ) – (17:18 Sun 25, AEDT) 06:18, 25 April 2021 (UTC)

• 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)
• 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)

  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)

• B 1st choice, A 2nd choice - This makes things simpler for new users (who will not have to worry about the minor flag), and simpler for experienced users (who will know the minor flag is only being used by experienced users). Levivich ^harass/_hound 03:20, 7 April 2021 (UTC)
• Option 0 Pointless. Why limit it to more experienced users if new users will probably not use it anyway? What is there to gain? There's no policy against making a minor edit not minor. ThePlatypusofDoom (talk) 13:49, 7 April 2021 (UTC)

  To me the answer to "why" is: so that I can filter out minor edits from my watchlist, and be confident that anyone using the minor flag is an experienced editor, and I'm not missing vandalism that is marked as minor by new vandalism-only accounts. Levivich ^harass/_hound 17:07, 7 April 2021 (UTC)

• Option 0, strong oppose B Minor edits, in my opinion, are an essential part of organizing edits. Also, there's no policy against making a minor edit not minor. EpicPupper 18:03, 7 April 2021 (UTC)
• Option 0. Recent change patrollers always look at every edit, minor or not, so it doesn't really help to hide anything. -- King of ♥ ♦ ♣ ♠ 03:15, 8 April 2021 (UTC)
• Option AB+ If this proposal actually passed, then I would filter out minor edits from my watchlist. The reason I don't already is because it feels like a lot of the time those edits are really some form of disruption or vandalism. –MJL ‐Talk‐^☖ 04:50, 8 April 2021 (UTC)
• Option 0. Solution looking for a problem. Stifle (talk) 10:06, 8 April 2021 (UTC)
• Support B, then A per numerous others. There needs to be a way to mark things that are truly inconsequential, such as fixing broken syntax in a call to a template or removing an extra period, etc. But there is no reason to allow it to be abused. Desertborn (talk) 17:42, 8 April 2021 (UTC)
• Support B first, then A. Should we be allowing brand new users a way to make an edit not appear on watchlists with one click? No... the "solution looking for a problem" group needs to get over themselves; obviously there is an apparent problem to some people, or B and A would have received no support at all. Aza24 (talk) 23:10, 11 April 2021 (UTC)
• 0 - I'm not clear what the problem is supposed to be. FOARP (talk) 20:22, 12 April 2021 (UTC)
• Strong oppose limiting the "minor edit" function to a select group of Wikipedians. I did not even know that the status quo is to limit marking edits as minor to registered users, and would oppose even this, because I think any one who edits Wikipedia should have the right to mark an edit as minor. Marking edits as minor is useful, because when one looks at the history of an article, it makes sense to see what edits have only been corrections of spelling mistakes in a single word or removal of superfluous punctuation marks. Rollo August (talk) 16:55, 18 April 2021 (UTC)
• Option 0 per AdmiralEek and Blueboar. I love it when vandals click "minor edit" on a 2,000kb entry. This feature helps me identify vandals, rather than hiding them. I see no worries with the status quo. Huggums537 (talk) 13:50, 22 April 2021 (UTC)
• Option 0 I generally find the minor edits tag an entirely useless feature (though, in good faith, I try to use it appropriately). This entire debate is a tempest-in-a-teacup, and I see no reason to deviate from the status quo. --Jayron32 13:59, 22 April 2021 (UTC)
• Support B, then A. However noble the intention of minor edits, we should accept that in practice, there's issues, especially with new users. I feel some of the "status quo" votes are akin to https://xkcd.com/1172/ ... I'm sure it's true that some non-smart vandals use "minor" as a clever technique to try to disguise vandalism that may make the vandalism even more obvious to some watchers, but that's very off the beaten path. The intended use is still not working great. I think that being able to mark edits minor at all is still a useful feature, but it's privilege, not a right - there's no real disadvantage to editors who can't use minor edits. So there's essentially no harm in further restrictions, and minor gain in clarity. "Minor" should really mean "said to be minor by a mildly trusted source", there's no use in "said to be minor from an untrusted source." SnowFire (talk) 04:28, 24 April 2021 (UTC)
• Support A, then 0. User:Vaticidalprophet's arguments (and others in the same vein) have convinced me that B is too high a bar. Keeping a feature that some people misunderstand and others intentionally but naïvely abuse just as a honeypot for the latter has moral issues. On the other hand, AC is a very low bar, is there enough volume of non-AC "minor" edits to make it worth the change? Pelagic ( messages ) – (19:07 Sun 25, AEDT) 08:07, 25 April 2021 (UTC) (oops, forgot to sign)

  Quick and dirty answer to my own question: recent changes, human not bot, page edits, main namespace, newcomers, latest 250 (which is approximately an hour and a half). Counted 65 bold m's, about a quarter of total newcomer edits. (I’m not in a position to work through all of them and score true-minor versus false-minor.) Pelagic ( messages ) – (19:19 Sun 25, AEDT) 08:19, 25 April 2021 (UTC)

• Support A, then 0. The thing about minor edits is that people can always ignore the tag if they want to, especially if it comes from an IP, so there's no need to make this so restrictive. Kokopelli7309 (talk) 14:27, 25 April 2021 (UTC)
• Support 0. The minor edit function seems like a simple and non-contentious part of Wikipedia, so restricting it would just cause unneeded restrictions and potentially create larger issues than any problem it's solving. User:Heyoostorm^_talk! 14:59, 25 April 2021 (UTC)
• Support B or A as being helpful for admin but it isn't a huge deal. Most real new users aren't going to know what a "minor" edit is until they are autoconfirmed at the earliest, so I don't see how they could miss it, nor how it would affect them negatively. Dennis Brown - 2¢ 17:57, 25 April 2021 (UTC)
• Option 0 per Mike Peel and DGG. Nemo 18:50, 26 April 2021 (UTC)
• Option 0 haven't seen any compelling evidence the present status of minor edits has caused any problems. – Teratix ₵ 02:22, 27 April 2021 (UTC)
• Anecdotal evidence I just saw this edit on my watchlist, in the edit summary of which an IP user bemoans the lack of "minor edits like on Fandom". — JohnFromPinckney (talk) 23:27, 28 April 2021 (UTC)
• Support 0, weak support A per Vaticidalprophet and Pelagic. JJP_Master 12:28, 29 April 2021 (UTC)
• Strong support B, support A, oppose 0: worrying about confusing new users is a red herring; by their nature, they won't know what has changed. Or care, for that matter. ——Serial 12:36, 29 April 2021 (UTC)
• Strong support B, support A, oppose 0: The occasional benefits of the minor edit checkbox are not worth the costs, which are that (1) they are a non-intuitive contribution to the cliff-like learning curve for new editors, and (2) they impose a small but persistent cognitive burden on all registered editors. I'm surprised that others aren't mentioning (2). I've had to think about whether to check the box over 17,000 times. It's not always a tough decision, but that still adds up to a tonne of time and mental effort that could have been directed elsewhere. The proposed changes at least fix (1). Adrian J. Hunter^{(talk•contribs)} 10:36, 30 April 2021 (UTC)
• At last! Someone who brings up this tremendously annoying and unregulated borderline anarchist feature! To answer the question: YES YES YES, VERY MUCH SO! Minor edits in its current relaxed implementation is absolutely awful. I come across very very few cases were it's used properly. In the vast majority of cases it's either used improperly, mostly by decently experienced users and not unusually to hide potentially controversial edits, or as outright vandalism. I mostly lurk in sports articles, and most editors in that subject mark updates (change of information) as minor even though that clearly is NOT what minor is meant for. Look in a bunch of sports season/event articles and you will find plenty of that. It's tremendously annoying and a huge waste of time to mentally scan and filter them in good or bad edits.

I support B with a twist, calling it Option B2, where it additionally includes Pending changes reviewers, Rollbackers and/or Patrollers (even though I've been here for 4 years and contributed more than most but still not qualifies for any of those groups) as well as bots. Autoconfirmed is too easy to get around. It could also be limited to byte size, preferably it would be clever enough to figure out when someone reverts data-rich vandalism.

I saw User:The Earwig suggesting in the earlier RfC that the minor edit feature could be blocked from a user if it's misused. I think that's a splendid idea.

User:Vaticidalprophet made an important note that the minor edit feature could be used by the poster to themselves distinguish them in their own statistics. So a compromise would be that minor edits can be marked by (auto)confirmed users but doesn't show to anyone else. Not until that user is extended confirmed will marks show, and then only marks made after the user has become extended confirmed.

User:Chess suggested that it could be replaced with another system instead, where one categorises the edit based on type, like grammar/spelling correction, style/layout issues, revert vandalism, wikilinking things, and so on. That is a terrific idea!

If nothing of this, then I lean towards a complete removal or at least limiting to administrators and bots rather than the microstep to limit it to (auto)confirmed or – heaven forbid – status quo. Even now as I checked, I discovered that two persons I spotted misusing it and pointed out for, were in fact extended confirmed users! So this feature is absolute garbage right now, worse than not having it at all. But if it stays and gets regulated, I also think minor edits should become an official guideline.

It's disheartening to see so many in favour of status quo specifically for the abuse. It's completely backwards thinking and a testimony to how broken the feature is. Even more so from the ignorant and selfish people saying there's no problem at all, implying for anyone. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)

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)

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)

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)

Option C

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

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) This seems unnecessary, it's already possible to filter for these on recent changes. See [1] User:力 (power~enwiki, π, ν) 19:17, 3 April 2021 (UTC) 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)

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)

• Support as proposer. {{u|Sdkb}} ^talk 16:00, 5 April 2021 (UTC)
• Sensible. Also works well with the options that don't make minor edit a possibility until you have been here a while. There is much to learn when you start to edit and a lot of sense in postponing some of that to make things simpler for new editors on their very first edits. ϢereSpielChequers 07:18, 8 April 2021 (UTC)
• Support. To be quite honest, it took me quite a while for me to figure out what constituted a minor edit back when I started, and I believe this would be useful. Sdrqaz (talk) 20:56, 9 April 2021 (UTC)
• Support. I'm a new editor. I've already misused "minor edit" because I thought adding an extra external link wasn't a major change to a page. A lot of new editors are going to make this mistake; it seems almost vain and self-glorifying to suggest that such a small change constitutes a major improvement in a page. There are a lot of rules and policies in Wikipedia; mistakes will be made in good faith not only by newbies but also by longer-term, occasional editors. Little pop-ups triggered at strategic moments would help to educate us. Elemimele (talk) 10:48, 29 April 2021 (UTC)
• Support — I think this is a better solution than removing the functionality from new users altogether. This would allow good-faith editors to use the button correctly from the start (instead of assuming they'll find out what it is over time), while vandals will probably disregard the message (so people's RC patrol worries should be alleviated). Tol | Talk | Contribs 17:56, 1 May 2021 (UTC)
• I strongly support this. IT took me a while to understand what i really meant. It's a lot to take in in the beginning if one wants to go a little deeper than just pure text alteration. All the things to read and check before posting something... And not being a native English speaker doesn't help either. When I think of it I have come across a lot of level 1-2 English speakers that made loads of erroneous minor edit marks in good faith. --Mango från yttre rymden (talk) 23:57, 2 May 2021 (UTC)
• It seems unclear at this point whether option A or B will pass, but from the above, I wonder if this might be something we'd want to do regardless. {{u|Sdkb}} ^talk 22:20, 5 May 2021 (UTC)
• As long as this is truly a once per account/IP thing this would be fine... If it is tied to cookies then I don't think it would be great. --Trialpears (talk) 22:26, 5 May 2021 (UTC)

  IPs aren't allowed to mark edits as minor, I believe, so that's not an issue. Tying it to the account would be the obvious way to go. {{u|Sdkb}} ^talk 07:15, 7 May 2021 (UTC)

• Oppose running any sort of local javascript for this, if this is something that is needed it should be handled software side along with other types of "first time you do something" things (like picking the visual editor). — xaosflux ^Talk 13:40, 7 May 2021 (UTC)
• Support, this looks like a viable middle-ground. EpicPupper (talk) 04:35, 9 May 2021 (UTC)

An extended comment/rebuttal to option 0

I, the proposer of this RFC, have seen rather many confusing option 0 responses; I will counter those here.

• Mike Peel, Thryduulf, TonyBallioni, OhKayeSierra, John M Wolfson, ThePlatypusofDoom, and Stifle say there is no obvious problem to be solved. The problem is that many edits marked as minor by new users are not actually minor. Therefore, the option to hide minor edits on watchlists is ineffective, as it may hide edits which are not actually minor. (I probably should have included this in the RFC itself.)
• Nosebagbear, CaptainEek, Blueboar, Chicdat, and GenQuest argue that a questionable edit marked as minor is an indicator to recent changes patrollers that the edit may be vandalism (a honeypot). That may be, but the whole point is that these edits are not actually minor. Recent changes patrollers will still check the edit, and this provides tangible benefits to people who use the watchlist and want to filter out minor edits. ProcrastinatingReader also noted this.
• Finnusertop and Bilorv believe that most new users use the feature correctly, so it would be unhelpful to remove it from all new users. A quick look at minor edits from new users shows otherwise, as I saw (see my #Data on usage of minor edits). This only removes the feature from new users, who are unlikely to use it correctly.
• Andrew Davidson says it would be confusing if the interface changes. I believe, if anything, it would be less confusing, as (for new users) there would no longer be a checkbox with a potentially unclear meaning.
• Swordman97 and SunDawn seem to think that this would ban new users from making edits which are minor. (Note the wording.) This does not propose that, rather, it proposes that new users cannot mark edits as minor. They can still make edits which fulfill the minor edit criteria, but they cannot tick the box which marks it as minor.
• EpicPupper says two things. First, he or she says that minor edits are an essential part of organizing edits. Sure, but they work poorly because they are frequently misused by new users. He or she also says that there's no policy against making a minor edit not minor. I assume this means making a minor edit, but not ticking the box. As far as I know, people do this all the time, and there is not much of an argument for making everyone tick the box when the edit is minor — all that will happen if one leaves it unticked is that it may show up on more watchlists.
• King of Hearts says that recent change patrollers always look at every edit, minor or not. That's not the point, the point is that people who use the watchlist may want to only look at edits which are not minor. This doesn't hurt recent changes patrollers, but it significantly helps those who wish to filter out minor edits from watchlists.

Tol | Talk | Contribs (formerly Twassman) 22:26, 11 April 2021 (UTC)

The problem is that many edits marked as minor by new users are not actually minor. I do not consider that a problem. TonyBallioni (talk) 22:28, 11 April 2021 (UTC)

@TonyBallioni: As I said, the watchlist function allows users to hide minor edits. With these edits, which are not minor but are marked as such, someone who hides minor edits on his or her watchlist will not see these edits even though he or she wants to. As most of these edits are by new users, I believe restricting the feature to more experienced users (who are more likely to use it correctly) is a good idea. Tol | Talk | Contribs (formerly Twassman) 22:33, 11 April 2021 (UTC)

And I disagree that what you are describing is actually problematic. Maybe it's because I've never hidden minor edits on my watchlist, but if someone makes the choice to hide them, that's on them. There's no reason to restrict it because of that. TonyBallioni (talk) 22:36, 11 April 2021 (UTC)

I agree completely with Tony. I don't know why people choose to hide minor edits on their watchlist (the only edits I hide are my own), but that's not the primary function of the flag. As has been said multiple times by multiple people, the solution to what you are seeing as a problem is to teach people how to correctly use the minor edit flag not to remove their ability to use it. Thryduulf (talk) 22:45, 11 April 2021 (UTC)

@Thryduulf: The reason to hide minor edits would be because one wants to see the substantive edits to the article but skip the minor ones. For teaching people: we do have {{Uw-minor}} for this purpose, and while I've tried to use it as much as possible, there isn't a "new users' minor edits patrol" akin to RCP to teach people about minor edits. I do agree that education on minor edits is definitely preferable to removing it from new users, but I'm not sure how to do that effectively. Now I have an idea for a bot, hmm... Tol | Talk | Contribs (formerly Twassman) 23:00, 11 April 2021 (UTC)

I agree with Tony and Thryduulf. Also, yes, you should have said this at the start of the RfC. Thanks. Mike Peel (talk) 07:22, 12 April 2021 (UTC)

• While it (to put it coarsely) sucks that many users abuse the "minor edit" functionality, and I wouldn't be opposed to removing it entirely (though nor would I entirely support it), I think it's hardly a reason to impose such an onerous restriction.  – John M Wolfson (talk • contribs) 22:30, 11 April 2021 (UTC)
• I didn't say that most new users use the feature correctly (name any step to editing and most new users do it wrong) and my argument doesn't rest on that fact. Your data remains lacking a control sample (what you replied to my comment with is not a control sample or the data that I said was missing). — Bilorv (talk) 22:37, 11 April 2021 (UTC)

  @Bilorv: Thanks for following up. The control sample would be made of a mixture of all three categories, and I didn't see much of a point in repeating the tedium of sorting edits a fourth time. From the data I already sampled:

  • Non-AC: 100 edits from 22:03 to 23:59 (1 hr 56 min), so ~0.864 minor edits per minute, weight 9%
  • AC non-XC: 100 edits from 23:26 to 00:27 (1 hr 1 min), so ~1.64 minor edits per minute, weight 17%
  • XC: 100 edits from 00:45 to 00:59 (14 min), so ~7.14 minor edits per minute, weight 74%

  From this, it is evident that extended-confirmed users make many more minor edits than other groups (around three quarters of minor edits). Weighting the samples with minor edits per minute, the reconstituted "control"-ish sample gets ~73% of total edits are actually minor. Tol | Talk | Contribs (formerly Twassman) 22:54, 11 April 2021 (UTC)

  Read what I wrote again. The control sample for the factor that is relevant to the argument I make is the proportion of non-minor edits which are reverted per group (which can be compared to the 20%/1%/0% data you give). This still assumes that "reverted" is synonymous to "unconstructive", but I presume you aren't willing to read through 600 edits and assess whether they're constructive or not manually. — Bilorv (talk) 23:02, 11 April 2021 (UTC)

  Ahh, thanks for the clarification. Based on new RC data, 11% non-AC, 3% AC non-XC, 0% XC (percent of non-minor edits reverted). This indicates that for non-AC, the minor edit may be a flag or honeypot, but for autoconfirmed users minor edits are more likely to be constructive. Tol | Talk | Contribs (formerly Twassman) 23:09, 11 April 2021 (UTC)

  Your rebuttal to both my and TB's group don't really seem to be convincing to me. Recent Changes Patrollers don't check every edit (if they did, we'd never find vandalism more than 10 minutes old!), prioritisation is key. Nosebagbear (talk) 23:19, 11 April 2021 (UTC)

  @Nosebagbear: Thanks for the reply. I do not think the removal of minor edits from new users will have much impact on recent changes patrol. I certainly take into account a minor edit flag in RCP, but only when it's combined with something else (such as a large byte change size or a questionable or missing edit summary). I believe that the amount of vandalism that would not be reviewed without a minor flag is inconsequential. Tol | Talk | Contribs (formerly Twassman) 23:27, 11 April 2021 (UTC)

  Well, here's the thing: A user can choose whether or not to hide minor edits on his or her watchlist. I myself never hid minor edits, not to detect vandalism, but because I wanted to see all the edits made to that article on my watchlist. 🐔 Chicdat  ^{Bawk to me!} 10:12, 12 April 2021 (UTC)

• The thing is, a lot of users just aren't getting the point. If we pop up a notice saying, "Are you sure you want to mark this edit as minor? A minor edit is..." then the maliciously intending editors will just skip the notice and mark their edit as minor. If we limit it to autoconfirmed or extended confirmed, then the maliciously intending editors will just make the necessary amount of edits and time, and then go on a disruptive "minor" spree. If we limit the character change of minor edits, then the maliciously intending editors will just change all the 4 letter words on the page to "****" and/or change the 5 letter words on the page to "penis". If, on the other hand, we block the maliciously intending editors before they can go on a disruptive "minor" spree, and keep the status quo, then the maliciously intending editors will never get to edit. Period. 🐔 Chicdat  ^{Bawk to me!} 10:12, 12 April 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comment on mobile editing

Note that the mobile web source editor does not have a minor-edit checkbox/toggle. Mobile VE and iOS app editor do.

1. On mobile, I have sometimes resorted to hand-typing "[minor]" in the edit summary, though you can't filter that from your watchlist.
2. It suggests that, at the time mobile / Minerva was designed, minor-edit (along with several other features) was deemed unnecessary or too confusing for "typical" mobile users, or too cluttered for smaller screens. But the devs' thinking on that seems to have changed.

—Pelagic ( messages ) – (17:58 Sun 25, AEDT) 06:58, 25 April 2021 (UTC)

An observation

I do not believe that any restriction based on numbers of edits is worthwhile. For what it's worth, my approach is that I don't omit minor edits from my watchlist, but usually don't bother to check minor edits by editors who I trust to mark edits appropriately. These are not necessarily the same as editors who I usually agree with, and certainly do not correlate with numbers of edits made. I would expect most people to take a similar approach. For myself I don't believe that I ever mark non-minor edits as minor, but often forget to mark minor edits as such. Whatever system we have apart from removing minor edit functionality completely will always be vulnerable either to editors who don't know what should be tagged or to malicious editors who want to fly under tha radar, and I'm sure there are quite a few extended confirmed editors who fall into those categories, as anything based on numbers of edits is very easy to game. Phil Bridger (talk) 16:26, 25 April 2021 (UTC)

What I would support is a policy that states that minor edits have to be used sensibly. (and repeated offenses made blockable) That's vague, but on Commons I once ran into an admin who had "Mark all edits as minor" enabled in their preferences. (this option doesn't appear to exist on enwiki though) That's obviously disruptive. If use cases can be presented, maybe a proposal could be made to make minor edits a user right that can be revoked. — Alexis Jazz (talk or ping me) 16:50, 25 April 2021 (UTC)

Can we come to a consensus on when it is appropriate to "rescue" live links in an article with IABot?

If you visit the history page of any article, at the top you'll see "Fix dead links". This takes you to a page on https://iabot.toolforge.org where you can use IABot's database to add archive links to the page. There is a box for "Add archives to all non-dead references (Optional)" and it's that little box that I'd like to talk about here.

As I understand it, clicking that box does not archive the page. That has already been done by the bot and stored in an off-wiki database. All it does is copy the archive links that already exist into the article en masse. Many people have taken to just going around to various articles that do not have dead links and "rescuing" all of the live sources.

The reasons why this is good: I think the main reason people think is good is because it archives all the links (i.e. misunderstanding how it works), but there's something to be said for having everything already in the article, just in case IABot goes down, stops being maintained, etc.

The reasons why this is not good: It adds significantly to the size of the page without adding any meaningful functionality. See for example, this diff which was just the most recent on my watchlist and not the largest I've seen. It adds 12k to the page with no dead links rescued. This means the page is larger, of course, but also means anyone using the source editor has to scroll through even larger citation templates. It also throws off the various tools we have to understand authorship of a page. Controversial subject, I know, but sometimes it's useful to take a look at the xtools page statistics in order to see who's been working on an article, which isn't always apparent just by looking at the most recent history. In this case, someone who simply rescued links that didn't need to be rescued is now listed as the primary author of this page. (Apologies to YoungForever, who was just trying to help here. I don't mean to single you out -- there are a lot of people who use the tool this way.) We also know that some Wikipedians are motivated by making large numbers of contributions, and I'd suggest the ability to quickly make these large, semi-automated edits at any article could also be a motivating factor for some (I've seen people, in a long string of edits, go to dozens of articles just to rescue live links).

TL;DR - If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing. If it's not desirable, this option either shouldn't be available to users or we should be clearer in the displayed text for that option and allow reverting if used improperly. If it is sometimes desirable to rescue links that aren't dead, what are those cases? — Rhododendrites ^talk \\ 14:27, 23 April 2021 (UTC)

I agree it shouldn't be done arbitrarily. It should be a step for a practice like in the final preparation for a GA/FA and subsequent maintenance once that's been achieved. (eg once 90% of the refs have archive-url's, bot-archiving the rest is not a problem). I can also see it being done for a topic where the bulk of the sourcing does exist only from web pages, such as many current event articles, but that should be some time well after the article is created where the possibility of link-rot may arise - at least if not more than a year out from creation, not in that first year for certain. --Masem (t) 14:43, 23 April 2021 (UTC)

@Masem: Just to clarify, when you say I can also see it being done where the bulk of the sourcing does exist only from web pages, are you saying that archiving those links is what should be done so that if one dies an archive can be added semi-automatically? Or that all of those links should be added directly to the article preemptively in addition to being archived by IABot off-wiki? IABot is archiving/storing them whether we use that interface or not. The question is when to move the archive links into the article text. — Rhododendrites ^talk \\ 14:51, 23 April 2021 (UTC)

Does the archive bot actually make the archives as it runs, even when you do not check that box? I was under the impression that it did not AManWithNoPlan (talk) 15:02, 23 April 2021 (UTC)

I'm talking about when they are added to the wikipage. We do want the backgrounding of Archive links to happen regardless, I feel, but adding those to Wikipages is where the problem lies and should only be done for polishing purposes (GA/FA) or if the article is heavily reliant on online sourcing. --Masem (t) 15:04, 23 April 2021 (UTC)

If it is desirable to have all archive links in the article, a bot should do it, rather than leave it to arbitrary drive-by rescuing of things that don't need rescuing. Rhododendrites, I agree with that. And there is another reason to add archive links: WP:EVADEGDPR. By the way, when it comes to the concern of longer wikitext (never really bothered me), this could be reduced significantly by adjusting templates. The citation template on Dutch Wiktionary for example requires no archive date and allows omitting the live URL. — Alexis Jazz (talk or ping me) 15:05, 23 April 2021 (UTC)

Years ago my proposal to automate the archive-date (based on parsing the archive-url of common archive sites) was rejected. Can't find it in the archives at the moment. I generally support reducing redundancy among fields. However, I don't support removing the url if there is an archive-url, because it makes it more confusing to scan for specific refs or update the ("where the hell is the URL itself? Oh right, it's encoded as part of another URL in a different field."). DMacks (talk) 15:57, 23 April 2021 (UTC)

DMacks, on Dutch Wiktionary it isn't common to omit live URL either and if specified the entered URL will be used. The template just doesn't make a fuss about omitting the URL. I'm not really sure if structurally omitting the live URL would be a good idea, but I wanted to mention that technically it's possible. — Alexis Jazz (talk or ping me) 17:36, 23 April 2021 (UTC)

Thanks for explaining the origin of these edits. The term "rescuing" on my watchlist kept confusing me when links were all live (it's not clear that there is any bad situation that is being remedied). DMacks (talk) 15:29, 23 April 2021 (UTC)

100% agree with OP. I used to make this mistake when I first got here: I went about to articles, checked the optional box and added all the archive links. I thought this was archiving the links. Someone at some point set me straight, and now I realize this adds a lot of unnecessary bloat to articles. It also messes up authorship stats. I am listed as a main author of Alexandria Ocasio-Cortez and Yellow vests movement but it's only because I added like 40k of archive links with one click. That optional checkbox should at least have a warning if not removed or moved somewhere else. Levivich ^harass/_hound 16:57, 23 April 2021 (UTC)

I don't really use the IABot that much. I only used it when I come across a canceled TV series that ended already, a miniseries (only 1 season) ended already, dead person, or film that has been out for a while as the urls of the articles may not work or updated with information that may not be relevant to the articles anymore. I didn't think it is a big issue to add archive urls to live links as I seen a lot of veteran editors using the IABot to do that as well. — YoungForever^(talk) 19:43, 23 April 2021 (UTC)

Assuming the information at WP:EVADEGDPR is true, I support editors (or bots) adding archive links to anything already archived on the Internet Archive (WayBack Machine) website, so long as bots are not doing so without either an editor requesting it for a particular article, or because the bot is rescuing other dead links on the articles. I don't really have an opinion one way or the other about a bot doing so for all pages without being asked to, but I wouldn't necessarily oppose it. -bɜ:ʳkənhɪmez (User/say hi!) 01:58, 24 April 2021 (UTC)

• So perhaps this is due for an RfC. I think it ultimately comes down to:
  • Option 1 - Turn off the option to "rescue" links that aren't dead in the IABot interface because all links should be accompanied by an archive link, and we should have a bot add these automatically.
  • Option 2 - Turn off the option to "rescue" links that aren't dead in the IABot interface because IABot already archives all links and we don't need them in the article until the link actually goes dead.
  • Option 3 - Allow users to "rescue" links that aren't dead but set up rules for when it's allowed. (e.g. certain types of topics, or when actually rescuing a dead link) and add a warning to the interface.
  • Option 4 - Allow users to "rescue" links that aren't dead on a whim at their own discretion (status quo).
• More or less? To be clear, I'm not asking for people to pick one of these here -- I'm making sure these are more or less the correct options to present, acknowledging that #3 would of course require follow up. — Rhododendrites ^talk \\ 02:19, 24 April 2021 (UTC)
  • I think add an option for "add a warning/advisory to the checkbox" (as opposed to #3's "rules"), and explicitly identify #4 as the status quo (w/more neutral wording). Otherwise looks good and thanks. Levivich ^harass/_hound 02:51, 24 April 2021 (UTC)
    • Regarding "rules" isn't that what we really need, though? Conditions when it's acceptable? Otherwise what would the advisory say? And yeah, I didn't actually intend "on a whim" to make it into an RfC. :) — Rhododendrites ^talk \\ 13:31, 24 April 2021 (UTC)
  • Also pinging Cyberpower678 do make sure this sounds workable on his end, too? — Rhododendrites ^talk \\ 03:04, 24 April 2021 (UTC)

    Is option 2 true? It doesn't seem to prompt IA to archive links; I'm always searching for them manually. Hawkeye7 (discuss) 03:07, 24 April 2021 (UTC)

    Rhododendrites, I would like to remove option 2. This tool is also used outside of enwiki and they have different practices. Amending number 1, disabling that option would be moot if we have IABot add archive automatically. Ultimately, this is a tool that anyone is free to use, but isn't being forced to. If it comes to what is allowed to be used and not, it should be policy centered, not implementing customized restrictions on an external tool. —CYBERPOWER (Around) 14:01, 24 April 2021 (UTC)

    @Cyberpower678: Facepalm thanks for the reminder that the english wikipedia is not the only project that uses these tools (and that I am susceptible to enwikicentrism). The issue with policy centered is our policies don't readily address this. So it seems like this will need to be rethought not in terms of removing the option but perhaps just (a) determining whether we want the bot to add all archives; if not then (b) developing our own rules for it and, if applicable, (c) adding an advisory when the option is selected saying (using general wording about it not being allowed on all projects or pointing to some documentation somewhere). How does that sound? — Rhododendrites ^talk \\ 14:28, 24 April 2021 (UTC)

    Rhododendrites, Sure. Adding an advisory to the box is not a problem. —CYBERPOWER (Around) 15:47, 24 April 2021 (UTC)

• As far as cons of archiving live links, does it slow down loading for readers? And are the longer references something readers will find annoying, or will it be potentially helpful if a link dies but is not yet identified as such? Those seem like more important, reader-centric questions to me than authorship percentages (which fundamentally is a fault of the tool's oversimplicity; tools should serve editing, never vice versa) or clogging up the source code (which fundamentally is a UI problem the WMF needs to solve). If we decide they're more annoying than helpful, one option would be to store archive links in the wikitext but not display them to readers so long as |url-status=live. {{u|Sdkb}} ^talk 04:12, 24 April 2021 (UTC)
  • I imagine an extra 5, 10, 15, or in some cases 40-50k of data per page would have some affect. The WP:Article size guideline addresses page size at WP:CHOKING, where it explains that 32k takes about 5 seconds to load on a dial-up connection and long pages present problems with some mobile devices. I think as with so many things it's worth talking about how much useful it is compared to any costs. And I wouldn't fully discount costs to editors. Some things may "just" be a design issue that WMF or someone should fix, but that doesn't mean it'll actually happen. That's quite a tangent, though, and yes, readers are fundamentally the priority. I do think that storing the archive information in wikitext but not displaying it is the worst of all worlds, though. I've not heard of anyone annoyed by the appearance of archive links. I mean, long-term this is something that should be exported to Wikidata/WikiCite, but we're not there yet. — Rhododendrites ^talk \\ 13:18, 24 April 2021 (UTC)

Some comments:

• Don't worry about performance.
• Link rot is categorically bad. The earlier we stop it, the better.
• Don't base decisions on whether people get editcountitis. We're not here to tell them how to contribute so long as the contribution is positive.
• Templates being a certain size in wikitext has a solution. It's just certain editors don't like that solution. ;)
• We have had at least one discussion about 'early' archival before. Please review the archives here or elsewhere.

Between the set, adding archive links is categorically to the better. --Izno (talk) 00:15, 25 April 2021 (UTC)

We are not supposed to worry about *server-side* performance. We can still worry about adding to download and parsing times on the client side ("parsing" refers to any time added by extra parameters to the setting up of data structures that make the mouseover action happen). Fighting link rot by mindlessly adding massive numbers of archive-links doesn't enhance verifiability, when it's helpful to check for better original links (esp. when lost merely due to website reorganization), for availability of more up-to-date sources, and whether sources and text match. I would reserve IABot to, say, one-article-at-a-time usage, for those editors who don't care to learn the extra reference markup (e.g. archive-url, archive-date, url-status). Dhtwiki (talk) 14:53, 25 April 2021 (UTC)

Is everybody here saying that it's bad to include archive links when you insert a (live) reference? —Naddruf (talk ~ contribs) 17:12, 25 April 2021 (UTC)

No. We're trying to figure out whether there's consensus to add archive links to live references en masse. I don't think that would affect an individual decision to include an archive link for a particular citation. — Rhododendrites ^talk \\ 18:21, 25 April 2021 (UTC)

One might consider augmenting the "Add archives to all non-dead references (Optional)" capability with another option that allows the user to try and selectively add archives to specific references. I'm not sure how frequently this happens, but I have seen some "live" links that have actually died and been replaced by spam. The link is technically "live", so IABot passes over it and says something like, "no changes made" because there are no dead links. Well, I know I actually need to add an archive link to have the correct content, so I can go search the multiple archive sites for my URL, or I can take a shot at adding all archive links, and hope I get the right one. Sure everything else will get an archive link as well, but that's OK, right? Go ahead and do it. Sometimes I will search Wayback and Archive.today, but I'll tend to stop there. It depends on how lazy I'm feeling.
Anyway, this doesn't necessarily solve the proposal, but it might slightly reduce the frequency of using add all archives. -2pou (talk) 17:05, 26 April 2021 (UTC)

• Comment. Yo, I can't believe checking that box doesn't archive the links. I could've sworn that's what it did.
  @Cyberpower678: you may want to weigh in here. –MJL ‐Talk‐^☖ 04:10, 28 April 2021 (UTC)

  Oh woops.. He was already pinged. Sorry about that. I should just go to bed.. –MJL ‐Talk‐^☖ 04:11, 28 April 2021 (UTC)

  MJL, Of course it does. If the objective is to add archive URLs to ALL references, and some of them don't yet exist in the Wayback Machine, then IABot will have the Wayback Machine save them and the URL of the snapshot will then be added to Wikipedia. —CYBERPOWER (Chat) 15:34, 28 April 2021 (UTC)

  @Cyberpower678: But it's not necessary to activate IABot in order to archive links because IA already automatically crawls Wikipedia and archives all its links, is that correct? For example, yesterday I created an article sourced to recent press stories. I don't need to "check the box" and add archive links to the Wikipedia article via IABot because those links in the article have already been archived, simply by virtue of being on an indexed Wikipedia page. Is that right? Also, if one of those links should go dead, there's a bot that will automatically replace the dead link with an archive link at that time, is that right? Just trying to see if I understand how it all works. Thanks for taking the time to explain this to us noobs. Levivich ^harass/_hound 16:15, 28 April 2021 (UTC)

  In my experience, new links are usually but not always archived within a couple of days of being added. About a week ago I checked the links in Fagradalsfjall and manually archived several that had not been done automatically. Thryduulf (talk) 10:42, 29 April 2021 (UTC)

  Levivich, yes. That is how the system is supposed to work. But sometimes, things can go wrong and some links are missed or failed to archive. It's not a common occurrence, but it can happen. Internet Archive after all has a massive infrastructure to maintain. —CYBERPOWER (Around) 16:30, 29 April 2021 (UTC)

• When is it appropriate to rescue live links? Always and yesterday. That 12kB of anti-link rot is some of the most valuable drive-by content an editor can add. I think there are two more salient subpoints to address within the OP. (1) Sometimes an article is too big to support archive URLs on all citations, so what's the best way to communicate this social practice? Easiest solution would be some kind of null template that tells IABot to archive its links but not write to the article, respecting the social consensus of that page's editors. (2) Authorship issues within XTools should be addressed in the authorship algorithm, not in blanket restrictions on IABot usage. The fact that citation bytes factor into "authorship" means that non-IABot citation edits will continue to inaccurately reflect prose authorship. (not watching, please {{ping}}) czar 07:12, 4 May 2021 (UTC)

Archive RfPP reports

I am creating a permanent archive of reports at Wikipedia:Requests for page protection. I have already done some, which can be seen at User talk:Chicdat/RfPP archives. I would like to see what the wider community of Wikipedia thinks of this. 🐔 Chicdat  ^{Bawk to me!} 10:54, 21 April 2021 (UTC)

What's the point of this? I mean, the archiving bots could be setup to create permanent, dated archives if that were deemed useful (verses the current rolling archives). But there's simply so many reports made I just don't see how it could be useful. ProcrastinatingReader (talk) 11:17, 21 April 2021 (UTC)

While protecting a page, an administrator could review other protection requests of the page to determine whether to protect or not. 🐔 Chicdat  ^{Bawk to me!} 12:23, 21 April 2021 (UTC)

I guess it'd be up to RfPP admins if they'd find that helpful, but if they think yes then it'd probably be better to WP:BOTREQ a bot to reply to RfPPs with links to permalinks of previous protection requests. Even if you did manage to compile all RfPP archives on your page (a very laborious task to do by hand), it'd take so long for that page to load and then to ctrl-f the page title that it just wouldn't be particularly effective. ProcrastinatingReader (talk) 12:51, 21 April 2021 (UTC)

I do not plan to do sixteen years of RfPP on that one page. When it reaches 500KB, I will split it. Chicdat (talk) 12:42, 26 April 2021 (UTC)

• Probably unnecessary but also probably harmless. Admins (anyone, actually) can already review the protection log of a page to see how recently and how often the page has been protected. Reviewing a log of times that a protection request was declined is (IMO) not really useful in deciding on protection. Ivanvector's squirrel (^trees/_nuts) 12:54, 21 April 2021 (UTC)
• As an admin who used to patrol RFPP a lot (and still drops by from time to time), I would find this functionality useless; I mean if you want to do it because someone else might find it useful, go ahead, I'm just saying it would have no impact on my RFPP work; I base my protection decisions almost entirely on the article history page and protection log, where prior protections are easily visible and can be tracked just fine. So basically, I don't object to it if someone else finds it useful, I just wouldn't. --Jayron32 12:55, 21 April 2021 (UTC)
• There was consensus to do this at Wikipedia talk:Requests for page protection/Archive 9#Archiving RfPP requests, but it never got implemented because the current archiving system is handled by a bot whose operator is not responsive to requests to update the bot. * Pppery * _{it has begun...} 13:20, 21 April 2021 (UTC)
• If this is needed, a bot should do it. — xaosflux ^Talk 15:36, 21 April 2021 (UTC)

  I wrote the code for such a bot a while back, see Wikipedia talk:Requests for page protection#Historical archives. I still have the code, and would be willing to run it if there is consensus to do so, but the bigger problem (as I said in my previous comment) is getting the bot currently archiving RFPP requests to a rolling archive to be compatible with the new system. * Pppery * _{it has begun...} 16:03, 21 April 2021 (UTC)

  Or we could just shut that bot down. We certainly don't need a rolling archive and a permanent archive. Ivanvector's squirrel (^trees/_nuts) 13:22, 22 April 2021 (UTC)

  Agreed, but the same bot is responsible for lots of other non-seperable clerking of bot reports so "just shut it down" isn't as easy as it sounds. I'll give the bot operator a ping, but I don't expect action given that he was first requested to do this in 2019 and never did. * Pppery * _{it has begun...} 21:25, 22 April 2021 (UTC)

  Pppery, I really need to get back on that request. I'll try to dedicate time to getting that updated this weekend. —CYBERPOWER (Chat) 15:26, 23 April 2021 (UTC)

  @Cyberpower678: Any update on this? * Pppery * _{it has begun...} 14:51, 27 April 2021 (UTC)

  Agreed, it's not as easy as pushing the big red button. But, if there's a request for the bot to change or stop doing something that it's currently doing, and the operator is unresponsive, I won't hesitate to block it. Ivanvector's squirrel (^trees/_nuts) 15:03, 27 April 2021 (UTC)

  Pppery, I got some work done on it, but it's not ready. I will work some more on throughout the week. —CYBERPOWER (Chat) 15:32, 28 April 2021 (UTC)

• There is a lot of needed work here at Wikipedia. This is not that. GenQuest ^"scribble" 17:43, 21 April 2021 (UTC)
• Can you explain why this is needed, Chicdat? What problem it will solve? --Malcolmxl5 (talk) 13:26, 22 April 2021 (UTC)
  • Please see Wikipedia talk:Requests for page protection#Archive?? for more information. 🐔 Chicdat  ^{Bawk to me!} 13:30, 22 April 2021 (UTC)
• The page protection log already achieves this, in a handy, easy to use format. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:10, 22 April 2021 (UTC)
• I also just don't get how this helps. To me this is like archiving WP:UAA or WP:AIV. These are boards that receive new reports all, day, every day. Archiving all these requests would create mountains of new pages that would almost certainly be largely unmaintained and basically ignored as old business. I don't see the benefit. Beeblebrox (talk) 20:19, 22 April 2021 (UTC)
• While the utility is a little questionable, again it does no harm. And in the absence of that harm, if the editor feels it is either beneficial or enhances transparency then I support them doing so. Nosebagbear (talk) 20:29, 22 April 2021 (UTC)
• Agree with Jayron32. Seems like a solution in search of a problem. -FASTILY 23:41, 22 April 2021 (UTC)
• I'll add on that I support this (although my comments above imply it to some extent), primarily on the argument of consistency: nearly every other noticeboard is fully archived (including ANI, which gets approximately the same number of edits per day as RFPP), so it seems odd to me not to do it in one case. * Pppery * _{it has begun...} 21:53, 25 April 2021 (UTC)
  • I agree. ANI actually has about 500,000 more revisions than RfPP. Chicdat (talk) 12:40, 26 April 2021 (UTC)
    • Not really though. ANI is a place for discussion of complex issues. AIV, UAA, and RFPP are for quick action in more obvious cases. That's why they aren't archived and also why archiving them would not be useful. Beeblebrox (talk) 01:22, 1 May 2021 (UTC)
      • There are several different types of noticeboards. There are the ones that have good reasons not to be archived (i.e. AIV and UAA). There are the ones that are archived (AN, ANI, AN3, BN, IAN, EFN, RSN, COIN, BLPN). There are the ones that are archived, but in a strange manner (PERM, XfD, SPI). And then, there's RFPP. Some users want it to go with AIV and UAA. Others want it to go along with the Ns. 🐔 Chicdat  ^{Bawk to me!} 11:02, 2 May 2021 (UTC)
• Cyberbot I should soon be updated to reflect this proposal. Chicdat (talk) 12:40, 26 April 2021 (UTC)
• It's been a while. Happy to see this currently being worked on. Thank you very much, Chicdat and Pppery for re-voicing the issue, and Cyberpower678 for implementing the proposal. In response to PEIsquirrel, well, while I'm not sure how else to describe the situation of the stalled RfC at WT:RFPP, it's neither urgent nor beneficial to take such action, or I would long have requested it, for years. The current only alternative to a running bot with outdated settings is an unclerked noticeboard and an upset bot operator. ~ ToBeFree (talk) 21:15, 3 May 2021 (UTC)
  • Thank you. That's one of the nicest messages I've gotten in a long time. 🐔 Chicdat  ^{Bawk to me!} 10:06, 4 May 2021 (UTC)