Misplaced Pages

:Village pump (proposals): Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 10:54, 26 February 2021 view sourcePrimeHunter (talk | contribs)Administrators79,268 edits →Adding more information in templates: remove excessive blank lines, unsigned← Previous edit Revision as of 21:43, 26 February 2021 view source Sea Ane (talk | contribs)Extended confirmed users559 edits →RFC: Should certain succession box content, be deletedNext edit →
Line 313: Line 313:
*'''Yes''' certain ones should be deleted. At a minimum, the spirit of ] #4 seems applicable: {{tq|There should be a Misplaced Pages article on the subject of the|q=yes}} succession box.—] (]) 10:11, 22 February 2021 (UTC) *'''Yes''' certain ones should be deleted. At a minimum, the spirit of ] #4 seems applicable: {{tq|There should be a Misplaced Pages article on the subject of the|q=yes}} succession box.—] (]) 10:11, 22 February 2021 (UTC)
*'''Depends''' - '''Yes''' for "Oldest-living British prime minister" "successions" as trivia, but without a discussion on others is will depend on the case, this should not be used as consensus to delete non-cited examples. ] (]) 10:15, 23 February 2021 (UTC) *'''Depends''' - '''Yes''' for "Oldest-living British prime minister" "successions" as trivia, but without a discussion on others is will depend on the case, this should not be used as consensus to delete non-cited examples. ] (]) 10:15, 23 February 2021 (UTC)
*'''Yes''' Succession boxes are not needed, in most cases it's a duplicate.] (]) 21:43, 26 February 2021 (UTC)


===Discussion (succession boxes)=== ===Discussion (succession boxes)===

Revision as of 21:43, 26 February 2021

Discussion page for new proposals
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Centralized discussion
Village pumps
policy
tech
proposals
idea lab
WMF
misc
For a listing of ongoing discussions, see the dashboard.

RfC: What to do with category links to Commons?

What should we do with the links to Commons in categories? Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Hi all. We currently link from categories here to Wikimedia Commons categories using {{Commons category}}. Over the last few years, we have been working on synchronizing the links to Commons categories between enwp and Wikidata, and for the Category namespace these are now fully synchronized. These links use sitelinks on Wikidata, which are robust against vandalism (a Commons category has to exist to sitelink to it), and these also match the sidebar link to Commons. They are also used to display links back to enwp from the Commons categories (both in the sidebar and the infoboxes there).

In 2018 I posted an RfC to switch to using Wikidata for interwiki links to Wikimedia Commons, which led to conditional approval to implement the changes here, and the creation of a new set of tracking categories at Category:Commons category Wikidata tracking categories. A subsequent RfC in 2019 on removing locally-defined links to Commons categories if they match the Wikidata sitelinks resulted in no consensus to remove locally defined links to Commons.

I would like to revisit this as it applies to categories only (i.e., this proposal does not apply to articles). At some future point this may also be applied to articles, but for those we need to fix the issue that causes Commons sitelinks to not appear in the sidebar (on the Community Wishlist Survey 2021), and there are ~15k articles that aren't synchronised to Wikidata yet (cases with e.g., multiple, mismatched, or misplaced links) out of 560k articles. These are not issues for links in the Category namespace, which are now fully synchronized with Wikidata.

Changes to current links

I suggest the following options for the use of {{Commons category}}, which would only apply in the Category namespace:

A1. Remove {{Commons category}} and just have the sidebar link. This is the easiest option to maintain here as MediaWiki will automatically display it where available. This would affect around 310k categories (the tracking categories listed in A2 and A3). An example of how the Commons link would look like after this change is Category:1817 in Vermont.
A2. Remove the locally defined links from categories, i.e., {{Commons category|Example}} -> {{Commons category}}. This is the second easiest to maintain, as e.g., renames of categories will be automatically updated. Manually defined links would only be removed where they match the Commons sitelink on Wikidata, so this would also allow local overrides. This would affect around 290k categories at Category:Commons category link is on Wikidata. An example of how the Commons link would look like after this change is Category:Data modeling.
A3. Always locally define the link, i.e., {{Commons category}} -> {{Commons category|Example}}. This is the most difficult to maintain, as it requires bot or manual edits when the link changes. This would affect around 20k categories at Category:Commons category link from Wikidata. An example of how the Commons link would look like after this change is Category:Bodies of water of Lebanon.
Adding new links

I also propose:

B. Bot-adding {{Commons category}} where a Commons category sitelink is available on Wikidata

Many links have been added between Wikidata and Commons over the last few years (now totaling over 3 million links). If we go for (A2) or (A3) above, then bot-adding them would significantly increase the number of links to Commons. These links are already available in the sidebar, so if we go for (A1) above then this isn't needed. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

Discussion (Commons category links)

I suggest !voting for A1, A2 or A3 and saying yes/no to B. If we reach consensus for any of these options, I will code a bot to implement it and propose it at Misplaced Pages:Bot requests for final discussion before implementation. Thanks. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

It's not clear from the RFC as written which options would still allow us to customise the displayed text and whether we could link to multiple categories, both of which are something that arises fairly often (Commons has a slight tendency to split categories so we want to provide links to more than one, and has a very strong tendency to give categories really peculiar names which don't tally with the English common name). I'd be strongly inclined to reject any option that wouldn't allow us at minimum to add explanatory text to the link (e.g. for an biography of an architect, have one link for portraits of the subject and one link for images of their buildings, clearly labelled which is which). ‑ Iridescent 20:15, 11 December 2020 (UTC)
@Iridescent: Those are rare occurrences in categories (but somewhat more common in articles, which is out of scope for this RfC). I can implement something for A2 that will continue to allow customised display text if really necessary, but that can easily be used to mislead the reader. Linking to multiple categories never makes sense anyway, since you can either link directly to the appropriate category from "Category:Buildings by X", or just link to 'Category:X" for the architect, and readers can then look at the subcategories on Commons for the rest - or you can improve the categories in Commons. Thanks. Mike Peel (talk) 21:02, 11 December 2020 (UTC)
P.S., are those intentionally missing links noted/explained somewhere, please? If not, perhaps they could be noted somehow? Thanks. Mike Peel (talk) 21:34, 11 December 2020 (UTC)

@Mike Peel: what is your brief and neutral statement? At over 4,500 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Misplaced Pages:Requests for comment/Wikipedia technical issues and templates. --Redrose64 🌹 (talk) 23:37, 11 December 2020 (UTC)

@Redrose64: The title was kinda the summary, I've paraphrased it just below the RfC tag for the bot. Thanks. Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Just to note, I've posted a neutral note about this RfC at commons:Commons:Village_pump#Commons_links_from_enwp_categories (diff), since this directly relates to Commons. Thanks. Mike Peel (talk) 20:11, 12 December 2020 (UTC)

Survey (Commons category links)

  • Oppose A1 without even blinking. I'm certain 99.9% of readers aren't aware the sidebar is even there, and on a topic with a lot of interlanguage links readers are never going to see it. Weakly oppose A2 as I can't see any particular advantage to removing the ability to override the displayed label. If these are the only three alternatives then support A3, although I could accept A2 provided there were a means to override or disable it in circumstances where what's on Wikidata isn't considered appropriate. Definitely oppose B, as there are occasions when we intentionally don't link to Commons for a given subject. ‑ Iridescent 20:18, 11 December 2020 (UTC)
    @Iridescent: As stated in the A2 description, "this would also allow local overrides". Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)
  • Oppose A1 and Support A3 To always have local control over the destination of the link, makes it easier for users. Keith D (talk) 20:30, 11 December 2020 (UTC)
    @Keith D: Can you elaborate on how that 'makes it easier for users' please? Thanks. Mike Peel (talk) 21:03, 11 December 2020 (UTC)
  • Concern (not opposition)... We here at WP.en have become very leery of linking to Wikidata (in any form). There are times when the two projects just don’t seem to speak the same language, and that has caused headaches for both projects. I have no idea if this is an exception or not... but please go with caution. Blueboar (talk) 01:28, 12 December 2020 (UTC)
  • Support A1 is the easiest to maintain with the tools at our disposal and with common sense protections against vandalism. A1 is a question of getting used to it and knowing where to look. The template can have a deprecation period where it says "See sidebar left for link to Commons" to help educate during the transition period. Failing A1, would also support A2 w/ Bot add (sigh.. see how much better A1 is?). Oppose A3. -- GreenC 02:38, 12 December 2020 (UTC)
    Genuine question and not being snotty, but how do you think "getting used to it" would work? In the skin in which more than 50% of readers see Misplaced Pages, A1 wouldn't just change the location of the link but would remove it altogether; from the perspective of readers this wouldn't be a matter of looking somewhere else to navigate to Commons, but of Commons suddenly apparently ceasing to exist. (Existing readers would probably know to ask where it had gone, but new readers would have no reason to suspect the links ever existed.) Plus, Misplaced Pages doesn't just have a single cohort of readers; new people discover us all the time. Most people viewing a category have either got there via a search or via the links on a Misplaced Pages article and aren't insiders who understand the quirks of MediaWiki, and "the links from Misplaced Pages pages to related content appear on that page" is a very well-established convention reinforced by 20 years of categories and navbox templates. A typical reader couldn't possibly be expected to know that if they're looking for the media associated with a category, they need to switch to desktop view if they're not already there, and then once there click a cryptic "In other projects: Wikimedia Commons" link hidden in the sidebar. ‑ Iridescent 06:40, 12 December 2020 (UTC)
    Ouch, that's a pretty major bug. I hadn't noticed that since I never use the mobile interface. I had a look on Phabricator to see if there was an existing bug report, but I couldn't find one, so I've started phab:T269992. Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)
    Repeating my plug for the gadget discussed here which adds a one-click button to preview how pages will look to readers (who mostly use the mobile view) rather than editors (who rarely if ever do). You'll be astonished how many things you take for granted are either missing completely or behave completely differently (see what a mess User:Mike Peel looks in mobile view, for an obvious example). If I had my way we'd deprecate mobile view and start again from scratch—I think the current skin is irredeemably bad both for readers and for editors—but I can't imagine the WMF ever admitting that a pet project they've spent a decade promoting is a complete lemon. ‑ Iridescent 13:22, 12 December 2020 (UTC)
  • Support A1. The Commons link is just one example of the "other projects" links, and displaying them automatically as part of the user interface makes more sense than adding one or more templates to every category. If the mobile interface isn't displaying these links, then it should be fixed. Perhaps removal of the existing templates should be delayed until it's fixed. ghouston (talk) 02:18, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 To always have local control over the destination of the link, makes it easier for users. As Keith_D put it. Or, as I put it during the last RFC: Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Misplaced Pages, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC) A tiny number of Wikidata enthusiasts have been persistently trying to bulk-delete content screwing over other editors in a holy crusade to make Wikidata lord&ruler of all they survey. Among other problems, the typical editor is going hit CTRL-F trying to find the content they want to change, and it wouldn't be there. They maybe eventually find the would-be-completely-useless template in the wikitext, but there would be no value there. The editor is left stranded with an impossible edit, absolutely no indication anywhere WTF is going on, and no path forward. Alsee (talk) 16:31, 13 December 2020 (UTC)
  • Support A2 and B. The typical editor does not need to edit technical interproject links. Ruslik_Zero 20:38, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 noting that we would need to explicitly discourage well-meaning editors removing labels "because it's on Wikidata", as has already happened with the A3 example. Sometimes the difference between the Commons category name and the local name is going to be jarring, all the more so if this is used as a precedent for changing how Commons category links are presented in articles: Commons has a more worldwide focus on titling categories than any individual Misplaced Pages has on titling pages, and has evolved different conventions as a result, and although this doesn't arise much on categories ("in" vs. "of" Lebanon in the A3 example is barely noticeable), it will be jarring in the cases where it does matter. I've frequently created categories on Commons with different names from the Misplaced Pages articles, for example using a disambiguator instead of "The". On the broad issue, concur with Alsee; having what the reader sees on a page determined at Wikidata rather than on the individual project is unacceptably risky with regards to vandalism or simple error (I corrected a Wikidata description in Dutch the other day that assigned something to the wrong US state) and makes editing unacceptably difficult; "anyone can edit" is one of our foundational principles, we want readers to be drawn to correct or update something and have the satisfaction of seeing their change live, and we want those who add or expand something to fix things linked to it (WP:SOFIXIT). Wikidata is intentionally behind a steep accessibility wall because it's a thing for information professionals and because errors there potentially affect all the projects. So I must oppose A2 and especially A1 (Iridescent's point being also hugely important regarding A1, and I am astonished the WMF was unaware of it). That said, I can see no harm in the bot run so long as we retain the ability to pipe the links when our category moves to a new title and no longer matches that at Wikidata: support B providing A3 is implemented. Yngvadottir (talk) 21:01, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 Local control provides needed flexibility. Another aspect is language - my impression Commons tends yo make more use of local language names where as enWikipedia often uses names translated into English - more likely to cause category names to need local control. Changes other than A3 assume a 1-to-1 correspondence between Misplaced Pages articles and Commons Categories; there have been Misplaced Pages changed where I've wanted to add more than one Commons Category link. PsamatheM (talk) 23:21, 13 December 2020 (UTC)
  • As nominator, in case it wasn't obvious, my long term preference is A1 (but that bug with the mobile site needs to be fixed first), right now I would prefer A2 since it minimises data duplication - which is the fundamental problem here. If you have multiple copies of the same data, then you have to fix each of them separately. By storing that link on Wikidata, in the same way as we store interwikis there, is the simplest option: it is then the same dataset here, on Wikidata, and on Commons (where that link is used to display the multilingual infobox). Then there are more eyes on the links, and more chance that someone will spot bad links and fix them. I'm saying this as someone that has gone through and corrected thousands of incorrect commons links from enwp over the last year.
I could live with A3 if needed, but it means continuing to bot/manually sync changes between Commons/Wikidata/here, which is just duplicate effort. Vandalism-wise, using the sitelinks/interwiki links is the safest way, since the category has to exist to be linked to (you can't change it to any random bit of text). There are currently no categories that link to multiple Commons categories, and there should rarely be a need to do that - but A2 would still let that be possible if needed. Similar with local text if really needed (but Commons category names are English by default). A tiny number of Wikidata-haters tend to trot out the same rhetoric whenever Wikidata is mentioned, which isn't really helpful (it's like arguing that all websites should go back to static rendering rather than using databases: it doesn't scale). With B, I'm happy either way - if we don't do that, I don't have to code up the bot, but we also don't get a lot more links to Commons (and bear in mind these have historically been bot-added to categories anyway). Thanks. Mike Peel (talk) 18:05, 14 December 2020 (UTC)
  • Support A2. This is the best of both worlds option. It eliminates a need to maintain two different systems to link a WP category to its equivalent Commons category, but also allows flexibility and control in handling special cases. – Finnusertop (talk ⋅ contribs) 16:42, 15 December 2020 (UTC)
  • Oppose A1 unless and until the mobile view is fixed (as per the nominator). Support A2 provided it isn't seen as a step to not allowing local over-riding, which will remain necessary for all the reasons others have explained above. Peter coxhead (talk) 17:50, 15 December 2020 (UTC)
  • Oppose A1, week oppose on A2 and support A3 for the reasons outlined by Iridescent. -- Euryalus (talk) 23:12, 15 December 2020 (UTC)
  • Oppose A1, A2, B, - Support A3 for reasons above already given. Only in death does duty end (talk) 15:36, 16 December 2020 (UTC)
  • Oppose A1 and A2 (very strongly), B, - Support A3 per Iri & others above. The problem with A2 is that (as I understand it) the current category links will all be removed, and the "local overides" would have to manually re-added. "Matching Wikidata" is a totally untrustworthy test. This would be a nightmare. Johnbod (talk) 15:44, 16 December 2020 (UTC)
    @Johnbod: The check is that the links between enwp + Wikidata + Commons are all in sync, not just 'matching Wikidata'. If you disagree with the link, then in A2 you would have to fix the link (e.g., by adding the local override, which we'd then check and correct on Wikidata/Commons - or better by fixing it on Wikidata so it's then fixed everywhere), or in A3 then you would have to fix the link (e.g., by changing the local override, which we'd then check and correct on Wikidata/Commons). Either way, the work you would have to do is very similar, it's hardly a nightmare. Reminder that enwp/wikidata is currently 100% synced for the categories we're talking about. Thanks. Mike Peel (talk) 20:44, 16 December 2020 (UTC)
  • Weekly Oppose A1, Strongly support A2 and Strongly Oppose A3 as explained hereafter
  • I generally support A1, but I think that's a question better left for a more general RFC on the boxes we put at the ends of articles. I also support A2 as a minimum result since it removes duplication of what is just another interwiki link at the end of the day, which we already accepted managing interwiki links at Wikidata. Hard oppose A3. I also oppose B as I do not want to see a continuing spread of these boxes; secondarily, enforcing the inclusion by bot of these seems to override the apparent editors' will in editing particular pages. --Izno (talk) 18:17, 20 December 2020 (UTC)
  • Support A2 for better visibility of the connection, but A1 is okay for me too. We should leverage Wikidata as much as possible in uncontroversial scenarios like this one. --MarioGom (talk) 14:16, 4 January 2021 (UTC)
  • Oppose A1, Support A2, Neutral A3, Support B. This gives the best combination of visibility and avoiding unnecessary duplication of effort. Thryduulf (talk) 16:05, 9 January 2021 (UTC)
  • I don't care too much about A1-A3 (though I think that local definition is better, goals of en.wikipedia and wikidata do not always align and definitions are sometimes different). I however strongly oppose any automated or blind additions of the 'commons category' (and I guess that is then also an agreement with selective A1). There are many cases where commons category has nothing that is adding to our articles (all images are already used, and, albeit in rare cases, commons has less than what en.wikipedia has), and sending people off to commons to find less (or the same) than what is here is silly and just clogging our articles (especially when you get the whole series of sisterlinks). Note that commons sometimes has different croppings of 1 image, so even if the number of images on commons is higher, it still does not add. --Dirk Beetstra 14:11, 10 January 2021 (UTC)
  • A3 (and A2 when the names are the same). Commons categories too often do not have names that match ours.  — SMcCandlish ☏ ¢ 😼  08:33, 15 January 2021 (UTC)
  • Oppose A1 and A2. And support A3. And support B but only if it says "Bot-added link". And Mike Peel, please stop removing commons category links that don't exactly match up with the English article name or English article categories. See this diff. You don't have that authority as far as I know. It is an example of why a bot shouldn't be removing commons categories. Humans like you shouldn't be doing it either. I noticed from your contributions that you are on a bot-like spree in doing so. Just because you are an admin doesn't mean you have the right to do so. Show me the guideline. I have tens of thousands of edits on both the commons and Misplaced Pages. I know many of these attempts at synchronization will not work due to the many idiosyncrasies of Commons work and Misplaced Pages work. I prefer an additive approach. Let the bot add commons links, but not let a bot remove commons links. --Timeshifter (talk) 04:18, 9 February 2021 (UTC)
  • Oppose A1/A3, strong support B, since a large part of the readers probably don't even know what "Wikimedia Commons" is, and "media related to ..." is just much easier to understand. --TheImaCow (talk) 06:26, 23 February 2021 (UTC)

Convert all English variant notices to editnotices

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

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

Survey (English varieties)

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

Discussion

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

Pending-changes protection of Today's featured article

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

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

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

I'll note that one of the primary reasons for rejections of auto semi on TFA in the past is giving the impression that Misplaced Pages isn't so free to edit by having our most visible page be uneditable to the majority of the audience of TFA. Pending changes protection avoids this by still allowing users to make the edit, even if there is a slight delay in publishing it live, so it would be a decent compromise between unfettered access and maximum accessibility for our most visible page, and avoiding wasting of the community's time and potential risk of bad content being put up for all to see. Regards, User:TheDragonFire300. (Contact me | Contributions). 11:01, 2 February 2021 (UTC)
As a further thought - the protection template text should be tailormade for TFA, and welcoming. Narky Blert (talk) 13:35, 2 February 2021 (UTC)
And another - WP:ANI#Pacific swift - Today's TFA receive high level of IP Vandalism (4 February 2021). Narky Blert (talk) 08:59, 5 February 2021 (UTC)
Another one, for which protection was declined - WP:ANI#Cheadle Hulme - Today's TFA receive high level of IP Vandalism (5 February 2021). Narky Blert (talk) 11:42, 7 February 2021 (UTC)
This is every edit made to Cheadle Hulme during its day at TFA. I see a grand total of two IP vandals, one of whom made two edits and one of whom made one, while every other IP edit is constructive. If any admin had protected it under those circumstances, then unless there's something I've missed they'd have been instantly hauled off to Arbcom for admin abuse. ‑ Iridescent 12:37, 7 February 2021 (UTC)
I am not an admin, and have no comment on whether any particular page should or should not have been protected. Nevertheless, I have felt it right to post here every relevant ANI post since I opened this discussion, no matter whether they help or harm my proposal. All evidence is important towards reaching a consensus. (I have not monitored WP:AIV or WP:RFPP, which would be much more difficult.) Narky Blert (talk) 20:10, 19 February 2021 (UTC)
Another one - WP:ANI#Apollo 14 - Today's TFA receive high level of IP vandalism and unsourced content (8 February 2021). Narky Blert (talk) 12:53, 9 February 2021 (UTC)
And another - WP:ANI#Bernard A. Maguire - Today's TFA suffered persistent vandalism (11 February 2021). Narky Blert (talk) 00:23, 12 February 2021 (UTC)
WP:ANI#Vandalism on TFA Grant Memorial coinage (12 February 2021). Narky Blert (talk) 05:42, 13 February 2021 (UTC)
Another - WP:ANI#Vandalism on Saturn (magazine) (14 February 2021). Narky Blert (talk) 07:30, 14 February 2021 (UTC)
Today's installment - WP:ANI#Vandalism on Silesian Wars (15 February 2021). When this one got reported to ANI, it had only a couple of hours left on the main page. Cluebot and something like six registered editors had already dealt with edits to it; add in the protecting admin, and that's a lot of work.
I spotted something I hadn't noticed before - User:TFA Protector Bot had stuck {{pp-move}} on the article on 26 January, with automatic expiry at midnight 15 February. Narky Blert (talk) 17:34, 16 February 2021 (UTC)
@Narky Blert: For several years now, it has been normal for all upcoming TFAs (which don't already have move protection) to be given a short-term move prot, set to expire the moment the article stops being TFA. Until November 2013 it was a manual process; since then it has been tasked to TFA Protector Bot, see the BRFA. This prot is usually applied some time in advance (I believe soon after the calendar slot has been approved), see the bot's log; and the use of {{pp-move}} is supplementary to that. --Redrose64 🌹 (talk) 22:33, 16 February 2021 (UTC)
I didn't know of that procedure (which was why I mentioned it), but it strikes me as an excellent one. Even a good-faith move of a reviewed and queued article would be disruptive, in the greater scheme of things. We don't want redirects on the main page.
Also - WP:ANI#Vandalism on Meteorological history of Hurricane Dorian (19 February 2021). Narky Blert (talk) 20:00, 19 February 2021 (UTC)
And another two - WP:ANI#Vandalism on SS Mauna Loa (19 February 2021) and WP:ANI#Multiple IPs adding porn or offensive image in supposedly TFA article (20 February 2021). On the second one, I count (among other reversions) seven WP:REVDELs while the article was on the main page. Narky Blert (talk) 00:53, 21 February 2021 (UTC)
Another - WP:ANI#Vandalism on Margaret (singer) (23 February 2021; also mentioned by Levivich, below), which illustrates a problem. An admin WP:SILVERLOCKed the page for 3 days (which IMO is too much in both duration and level); a non-admin closer thought that the problem should have been posted at WP:RFPP not ANI. Narky Blert (talk) 21:49, 24 February 2021 (UTC)
PC is widely agreed not to work/be practical on highly edited pages. That's why no one suggests it, probably. --Izno (talk) 15:44, 2 February 2021 (UTC)
This is something that was proven during the PC backdoor attempt, by the Barack Obama and George W. Bush articles. The volume of edits was so high that the queue on those articles were perennially backlogged, and so it was and still is agreed that PC is not suitable for pages that would see high volumes of edits, something which would happen with TFA as a matter of course. —A little blue Bori v^_^v 16:43, 2 February 2021 (UTC)
At least the TFAs as considered in this discussion. I have seen some fairly quiet TFAs of late. --Izno (talk) 17:17, 2 February 2021 (UTC)
Unfortunately I suspect the set of TFAs that would be suitably quiet for PC to work is almost identical to the set of TFAs where PC is not needed. Thryduulf (talk) 01:30, 3 February 2021 (UTC)
As a supporter of the proposal, and an active PCR, I don't think this would be insurmountable for most TFAs. I note that the two given examples are highly political topics, one of whom was at the time President of the United States and the other of whom had been less than a full term ago. Vaticidalprophet (talk) 06:04, 3 February 2021 (UTC)
I'm against preemptive protection of any kind, especially pending changes which makes more work for volunteers and is rarely useful. — Wug·a·po·des​ 01:53, 3 February 2021 (UTC)
  • Support some sort of protection it's unacceptable to have editors (very predictably!) vandalizing articles like The Holocaust in Slovakia while they're on the main page. This diminishes our reputation much more than any protection would do. (t · c) buidhe 04:16, 3 February 2021 (UTC)
  • I should note that "highly active" is a fairly low boundary - PCR starts having real issues well before, say, editors would be frequently edit-conflicting. I'm also not sure how accurate a prediction of a TFA's likely edit rate we can do. Obviously we can predict the "very active" and "not likely to be edited much" buckets, but there'd be a large middle category that is tough to order. As such, I continue to believe PCR remains distinctly problematic for any TFA use that would actually warrant PCR. Nosebagbear (talk) 07:35, 3 February 2021 (UTC)
  • To be honest, I'm not totally against this. The utility of pending changes is different from semi-protection: the goal is not to reduce the workload for administrators and recent change patrollers (as others have correctly pointed out above, pending changes effectively does the opposite), but rather, to prevent the vandalism from being seen by readers and thus possibly bringing the project into disrepute. As a matter of fact, if my memory serves me right, for a brief period a few years ago, we actually did start preemptively putting PC protection on the TFA after an WP:AN discussion because of a particularly nasty LTA that would replace images on TFAs with extremely shocking ones. The traditional problems with PC on highly edited pages don't seem to be a big concern here because the protection would only last for one day, and most TFAs don't seem to be edited so frequently that large backlogs might become a problem. At the very least, I would probably support a trial period for this idea. Mz7 (talk) 07:53, 3 February 2021 (UTC)
    Thinking about this a little further, I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA. Pending changes works best on articles where vandalism has a hard time getting reverted quickly, and now that I think about it, because the TFA already has a lot of eyes on it in general, it may be the case that most vandalism is already reverted within seconds, rendering the need for pending changes moot. Mz7 (talk) 08:02, 3 February 2021 (UTC)
So far as I can tell, TFA vandalism is rarely if ever reverted within seconds. I've heard averages around 10-15 minutes, which is enough to be problematic for those articles, especially with heavy or grotesque vandalism. Vaticidalprophet (talk) 11:39, 3 February 2021 (UTC)
Looking at the edit histories of the articles I mentioned in the opening paragraph (a very small statistical sample): if ClueBot spots it, within seconds; if a human, 1-40 minutes (median 8). Narky Blert (talk) 14:24, 3 February 2021 (UTC)
I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA This is the crucial question for me. If our goal is to prevent disruption to the reader, we need to know how much vandalism is currently disrupting readers. I don't think a trial would change our ability to look at that, we just need someone to crunch the numbers from the page history. It could also be crossed with the day's page hits to estimate the number of readers who actually saw the vandalism, e.g., this vandalism was up for 5 minutes, so with a total of 60 thousand page views that day---5 thousand people probably saw this instead of the article. In my experience it's as you describe with the added eyes bringing faster reversions, but knowing the average and other statistics would be useful and quite possibly change my mind. If PC protection really is a substantial benefit, I'd be willing to support its use on TFA. It at least allows users without accounts to edit, and if we craft a nice message as Narky suggests, it could minimize the potential newbie biting. So my main concern in this case is usefulness because I've rarely seen PC solve more problems than it caused. — Wug·a·po·des​ 20:13, 3 February 2021 (UTC)
(I guess the maths in your example isn't meant to be taken literally but 5 mins of 60,000 pageviews is about 209 views—5000 would be 60,000 per hour. A limitation of this approach is that vandalism lasts longer the less-viewed the page is, and the pageviews vary based on time zones in areas where most of our readers are from. But I think some API somewhere can give you hourly pageviews.) — Bilorv (talk) 20:43, 4 February 2021 (UTC)
  • Support pending changes protection as a trial: TFA is different from other highly-viewed pages in that there is very likely a highly active editor who is passionate about the article (the one who just promoted it to FA), and activity is limited to 24 hours (maybe the next few days as well, while it's still linked on the main page). I can't really speak for all such editors (I've only been that person once) but perhaps some would be able to look through all the changes at the very least after the dust has settled, and collect any of the changes which are productive. A counterargument is that TFAs are, well, featured articles, and so much less likely to have issues that new and unregistered users will be able to solve. But there are likely still small prose improvements that one might expect to be made in the TFA period. An alternative is maybe pre-emptively semi-protecting only some TFAs based on topic. — Bilorv (talk) 20:43, 4 February 2021 (UTC)
  • Support Few useful changes are made, vandalism is a serious problem not for the number of vandals but for the black eye we get for allowing it on the front page. Volume of changes we are talking about is not great. So this is an excellent use of PC. Hawkeye7 (discuss) 04:33, 5 February 2021 (UTC)
  • Support, in my view, this is the ideal balance between preserving both the integrity of our "anyone can edit" mantra, and quality of our featured articles. I tend to agree with Hawkeye that "few useful changes are made"—to the point where the amount of vandalism or unhelpful edits vastly outnumbers the occasional random spelling fix (and any major edits/errors would better be discussed on the talk page anyways). But either way, this protection could address both the vandalism and occasionally helpful edits. Aza24 (talk) 09:07, 5 February 2021 (UTC)
  • (nom) I agree that any change should be on a trial basis.
My idea for the template text is along the lines of: "Welcome to Today's featured article. It is an unfortunate fact that these articles attract vandals. Therefore, changes by new editors are reviewed by experienced editors before they show up for everyone to see. This usually takes only a few minutes. If you are here to be part of the community whose goal is to improve Misplaced Pages - Thank you, and happy editing! You might find Help:Editing a useful beginners' guide. If you are here only to disrupt - Be off with you!" Narky Blert (talk) 18:04, 5 February 2021 (UTC)
  • Support Would prevent instant publication of toxic or copyrighted material on such highly visited articles. ~ HAL333 02:58, 6 February 2021 (UTC)
  • Upon notice I haven't explicitly said it here yet, support as one of the parties in the original conversation. Vaticidalprophet (talk) 13:53, 6 February 2021 (UTC)
  • Oppose. PC protection generates significant amount of work for minimal benefit, and doesn't work on pages with a high volume of editing; those pages which attract enough vandalism to make protection worthwhile, are also going to be those pages on which PC won't work. PC also comes with significant additional drawbacks in addition to the maintenance backlog it generates; there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary; for BLP issues PC has little impact since it doesn't affect what Google scrapes (they pick up the most recent revision even if it's been unapproved); to approve/disapprove changes to an article at FA level often requires specialist knowledge of the topic, which the handful of people who work the Special:PendingChanges queue are unlikely to have; the whole proposal appears to be predicated on the idea that every, or at least most, FAs are going to be on peoples' watchlists, which just isn't the case. ‑ Iridescent 08:00, 7 February 2021 (UTC)
(Interesting to see you here -- I was literally just wondering what you would think of the proposition.) For what it's worth, "there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary" is incorrect -- the edit summary box is...huh, PC queue is empty as we speak, so my plan to take a screenshot for "right here" will have to wait, but it's prominently placed complete with giant "ADD AN EDIT SUMMARY IF WHAT YOU'RE REVERTING ISN'T BLATANT VANDALISM" bold text. Vaticidalprophet (talk) 06:37, 8 February 2021 (UTC)
In lieu of screenshotting the edit summary box itself, here's a screenshot from my recent PCR contributions showing them. Vaticidalprophet (talk) 06:42, 8 February 2021 (UTC)
It's alarming as a standalone thing to learn that Google is scraping the most recent revision on PCP pages—albeit I understood it to have a bit of a delay for general vandalism reasons (possibly it's just that it takes a few minutes for Google to scrape the article again). However, this is Google's problem, not ours. I don't want them having a single say in any of our decisions in any way. They need to change to suit us, not the other way around. Other search engines are available. — Bilorv (talk) 00:56, 13 February 2021 (UTC)
In around 2014, I was told that Google scraped a well-known social website every 20 minutes. Our goal as volunteer moderators was to take down heavy commercial spam within that time. IDK if that's a typical number, but our leader tried and failed to get them to increase it to 30. Narky Blert (talk) 06:05, 13 February 2021 (UTC)
  • Support The only backlog this would generate in terms of PC is one page which would need to be checked regularly for the duration (and, well, PC isn't that large of a backlog, compared to some other places). And, well, while it might not stop everything, at least any vandalistic edit (which would need to be reverted anyway, PC or not) won't be prominently displayed to every person who gets there... RandomCanadian (talk / contribs) 01:21, 12 February 2021 (UTC)
  • Support as a pending-changes reviewer, I think the added workload would be minimal compared to the benefits. With the number of eyes on the page, good changes will be accepted quickly, while bad ones won't be prominently linked from the main page. Elliot321 (talk | contribs) 05:57, 14 February 2021 (UTC)
  • Support - This strikes me as a reasonable compromise that both allows IPs to edit TFAs and combats vandalism. Put another way, it's the least restrictive means of effectively protecting our most prominent articles. (Protecting one article a day certainly won't overwhelm PC, and the article will be widely watchlisted anyway.) Let's at least give this scheme a try: I think it would be effective. Extraordinary Writ (talk) 07:18, 14 February 2021 (UTC)
  • (nom) To repeat a point I made earlier, in case it might get lost. This idea has both carrot and stick. It would provide a means to speedily welcome new editors and to point them in the right directions. Experienced editors know where to look or to ask for help; newbies, by definition, don't. Narky Blert (talk) 07:50, 14 February 2021 (UTC)
  • Support. This is about balancing Misplaced Pages's positive reputation as the encyclopedia 'anyone can edit', agains the potential negative reputation for vandalism and inaccuracies being introduced and not being caught. I think pending-changes protection is an excellent compromise, allowing people to edit, but preventing stupid nonsense from showing up on our most prominent article of the day. ƒirefly ( t · c ) 14:02, 14 February 2021 (UTC)
  • Support as trial. I agree with RandomCanadian, a short period of time having pending changes protection isn't going to create much of a backlog and with so many eyes on TFA already.
    I've been wondering though (which is also why I'm voting here, for the first time at Village Pump), where would one go to suggest an entirely-new protection type? Because what if, instead of putting pending changes on TFA, there was instead a "delayed changes" protection? It would basically be pending changes, but with automatic approval after some set amount of time. Set the time to something a bit longer than the average length it's taken for vandalism to be reverted, and I'd bet it would drastically reduce the workload on heavy-vandalism days without contributing to a pending changes backlog. This would be protection for just TFA (a case of a page with high visibility/traffic for a short period of time). But since this would need to be created and isn't a matter of assigning an existing protection, it's more of a future-implementation kind of suggestion. --Pinchme123 (talk) 01:27, 18 February 2021 (UTC)
    @Pinchme123: Feature requests should be submitted at Phabricator. --Redrose64 🌹 (talk) 14:26, 18 February 2021 (UTC)
@Redrose64: Thank you for pointing me to Phabricator, as I did not know about it beforehand. But my question isn't about "submitting" for a feature request, but suggesting one, to be discussed before requesting it. I see little point in requesting a brand-spankin' new feature without having a discussion about its merits, especially when feature requests appear to be made outside of WP (since Phabulator is merely an affiliated Wikimedia entity, and I had to create a new account just to see the feature request creation page). So where might I go to suggest the feature, for discussion? --Pinchme123 (talk) 16:16, 18 February 2021 (UTC)
  • Oppose, per Iridescent, and also because of the general principle of using TFA to highlight the "anyone can edit" principle. Editing with a delay is not the same thing as editing with an immediate impact, and using PC on such a prominent page would harm recruitment. --Yair rand (talk) 06:25, 18 February 2021 (UTC)
  • Comment. I'm in the knee-jerk oppose camp per Iridescent & Yair rand, but I can see the problem of adapting our processes as we evolve from "the encyclopedia that anyone can edit" to "the encyclopedia that anyone can edit". If we want to use the TFA for recruitment then the edit must be visible (almost) immediately; more than 30s would, I think, take away that little burst of joy that addicted me to editing here. I believe one of the major problems that Misplaced Pages faces as it matures is erosion of the editor base as it becomes harder and harder to get a foot in the door as a new editor. Is there any evidence that newbies take up editing via the TFA? I've seen multiple new editors converted via ITN, but rarely other sections of the main page. My DYKs have occasionally had substantive or typo-fixing edits by redlinks or IPs who are clearly interested in the topic, and I've even very occasionally had comments of thanks or opprobrium from IPs. Personally I hate pending changes and hardly ever accept significant revisions because it puts the onus on me to put my weight behind them, and I know others have the same problem. Is there some bot-mediated mechanism that could immediately auto-accept anything that looked good faith and not obviously problematic? Could Cluebot be set to run on every TFA edit immediately? Espresso Addict (talk) 12:19, 18 February 2021 (UTC)
  • Strongly support trying something after seeing today's TFA, Margaret (singer), be ceaselessly vandalized, spawning yet another ANI thread. I think the work combatting vandalism at TFAs is greater than the work involved in protecting the article, and the detriment from vandalism at TFAs is greater than the detriment of not allowing everyone to instantly edit it. I'm not sure if it's PC or semi or something else, but Something Must Be Done™. I'd support a trial of this or any type of protection. Or even a trial of both PC and semi, like an A/B test. What I strongly oppose is resigning ourselves to "well that's just how it is" and trying nothing. Strongly oppose trying nothing. Levivich /hound 22:44, 23 February 2021 (UTC)
  • Support As it's a featured article, the cost-benefit calculation here is very different than most. Newcomers vandalize many articles but also make good edits to make up for that. For featured articles, the likelihood of a newcomer making a good, constructive edit is greatly reduced (based on low potential for improvement of the article as a featured one), while the fact that it is on the front page means that the amount of vandalism increases substantially. Personally, I support pending changes protection on all featured articles because of the diminished benefit a newcomer editing them can bring. Plenty of featured articles have significantly declined in quality over time as for a pretty much completed article it is much more likely for any edit by newcomers to be unhelpful. I think people are overestimating that satisfaction people get to see their change immediately; as long as they are aware of the pending changes situation, what matters most is the fact that your work is published at all, not the exact time. Zoozaz1 talk 22:00, 24 February 2021 (UTC)

RFC: Should certain succession box content, be deleted

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following lists: When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

Survey (succession boxes)

  • Yes. We ought not to have any of that trivia in succession boxes. There are often many boxes, dozens even, and additional clutter is unhelpful. One would be very hard-pressed to find reliable sources discussing how James Callaghan "succeeded" Alex Douglas-Home as the oldest British prime minister, and I dare say that no biography of either of them mentions it. Surtsicna (talk) 22:15, 4 February 2021 (UTC)
  • Yes. Only posts with transitions (or successions) would need succession boxes. -- Kautilya3 (talk) 22:56, 4 February 2021 (UTC)
  • Not here. Trivia should be deleted, non-trivia should not be. Whether any specific succession is or is not trivia needs discussing individually at an appropriate forum - that forum is very much not here. Thryduulf (talk) 02:21, 5 February 2021 (UTC)
  • No As Thryduulf says trivial ones should be, non-trivial ones should not be. That needs to be done on a case by case basis. -DJSasso (talk) 18:03, 5 February 2021 (UTC)
  • Yes I find succession boxes unnecessary in general since they usually duplicate the infobox, a navbox, and/or the text. When it's not duplicative like this example, it's often trivial that doesn't need a box to itself. Reywas92 19:36, 5 February 2021 (UTC)
    • You dislike them, whereas I find the clear, consistent presentation extremely useful. Succession boxes, infoboxes, navboxes and prose all serve different functions and so the same link appearing in more than one place is a Good Thing. Some succession boxes should be removed, but most should not be. Which is the case for any given succession box can only be determined by a consensus discussion about the succession box in question. Thryduulf (talk) 01:04, 6 February 2021 (UTC)
  • Yes and would support getting rid of them all. Redundant and pointless clutter. Why not have separate boxes for marriages, spouses, and works dispersed througout the article while we're at it? ~ HAL333 02:50, 6 February 2021 (UTC)
    • What are they redundant to? Links in prose and links in succession boxes have different purposes so they are not redundant to each other. Boxes (for anything) scattered throughout the prose would be completely disruptive to the prose, which is why succession boxes are not placed in the middle of the prose? Thryduulf (talk) 11:58, 6 February 2021 (UTC)
  • Yes - Not sure we even need them for positions, but definitely not for superlatives. Levivich /hound 17:22, 6 February 2021 (UTC)
  • Comment: I feel the validity or triviality of succession boxes should be discussed on a case by case basis on their respective talk page. Not sure what a global decision one way or another on "trivial" succession boxes could achieve, when it does nothing to establish what is trivial and what is not. PraiseVivec (talk) 14:01, 7 February 2021 (UTC)
  • Yes for purely trivia succession box such as "oldest living X" - unless said role is notable in its own right (not sure if this actually applies anywhere). Elliot321 (talk | contribs) 05:54, 14 February 2021 (UTC)
  • Yes certain ones should be deleted. At a minimum, the spirit of WP:NAVBOX #4 seems applicable: There should be a Misplaced Pages article on the subject of the succession box.—Bagumba (talk) 10:11, 22 February 2021 (UTC)
  • Depends - Yes for "Oldest-living British prime minister" "successions" as trivia, but without a discussion on others is will depend on the case, this should not be used as consensus to delete non-cited examples. KylieTastic (talk) 10:15, 23 February 2021 (UTC)
  • Yes Succession boxes are not needed, in most cases it's a duplicate.Sea Ane (talk) 21:43, 26 February 2021 (UTC)

Discussion (succession boxes)

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

RfC: Should we allow custom DISPLAYTITLE?

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following list: When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Should we use custom DISPLAYTITLE? We have dozens of titles where custom DISPLAYTITLE would be useful, such as thatPower and C Sharp (programming language). Using custom DISPLAYTITLE would allow us to bypass these restrictions and allow us to use any DISPLAYTITLE and deprecate the template {{correct title}} Aasim (talk) 20:22, 9 February 2021 (UTC)

There would need to be some system to only allow "valid" alternate names—currently only modifications that result in the same text (ignoring formatting/normalization) are allowed. For C#, you'd need to allow adding "#" (maybe reasonable to code in as an unsupported character), but also removing "Sharp" (harder to code in, because it already bans hiding arbitrary parts of the page title). One possibility is a separate software feature so the title could only be edited by users with a certain permission, but I don't think this will get much support and it would be a lot of work for fairly minor gain. And there's still the problem that the displayed title won't work if you copy it into the search box or try to link to it. — The Earwig ⟨talk⟩ 22:40, 9 February 2021 (UTC)
@The Earwig: Removing chars from the title is already supported via the font-size=0 trick, though I think it's generally seen as bad practice. – SD0001 (talk) 14:03, 10 February 2021 (UTC)
From Misplaced Pages:Page name#Changing the displayed title, it was formerly possible to hide text with display: none; but this is no longer allowed. It makes sense there are other workarounds, but I'm certain this is a bad idea. For one, I'm not sure how screen readers will handle that. — The Earwig ⟨talk⟩ 14:39, 10 February 2021 (UTC)
In theory there could be a list of valid substitutions defined by regex somewhere or something, so the complete word "sharp" can be substituted for "#" or the like. --Aquillion (talk) 21:56, 15 February 2021 (UTC)
IMHO I think abuse is a bit unlikely given that most people dropping by Misplaced Pages to edit it are here in good faith and probably know nothing about how "DISPLAYTITLE" works. Also it appears DISPLAYTITLE is hidden deep in VisualEditor anyway, so I do not think abuse is likely to happen.
And messing with the "DISPLAYTITLE" of a page could just be treated as disruptive editing, just as we treat page move wars, tendentious comments, etc. Aasim (talk) 00:55, 10 February 2021 (UTC)
  • Oppose It's too annoying and error-prone if the displayed name cannot be copy-pasted to a wikilink or the search box. It can also be confusing if you click a link in search results or somewhere else and come to a page with a different title. PrimeHunter (talk) 15:38, 10 February 2021 (UTC)
  • Oppose. When I worked for a music tech startup, one of our pains in the butt was artists like Ke$ha and NIИ. We were constantly special-casing things like this so people could find them in searches. Yes, it is annoying that typing "C#" into a wiki-search box gets you to C, so you have to hatnote you way over to C-sharp where you finally get to click on C# (programming language) which takes you to C Sharp (programming language) (actually, I think that last step might be a violation of MOS:DABPIPE). But, I think the alternative would be worse. -- RoySmith (talk) 15:50, 10 February 2021 (UTC)
  • oppose The characters that are allowed in the title are limited for good reasons as far as I can tell. Specifically, # already has a meaning in URLs and so would be a real problem for wiki links. — GhostInTheMachine 18:08, 10 February 2021 (UTC)
    This is not about allowing # in wikilinks, but allowing custom DISPLAYTITLE. Aasim (talk) 21:51, 10 February 2021 (UTC)
    I get that, but imagine the fun people will have trying to type a wiki link to a page that has a # character in the displayed title. Is a wiki link of A#B to a page called A#B or to a link called B in page A? Is the link to a page called A-something-else, but displayed as A#B? If the page title is displayed as A#B, what should the link be? — GhostInTheMachine 22:53, 10 February 2021 (UTC)
  • The issue with this is that we don't want title-spoofing abuse. Perhaps, in certain cases, we could have a system for displaying the "technical title" in a less prominent alongside the "display title"? --Yair rand (talk) 06:19, 18 February 2021 (UTC)
    We could take an approach like Wiktionary, and have an "Unsupported titles" page where we can have all the unsupported titles listed. Then the technical hatnote would be unnecessary and the links would become clearer. Aasim (talk) 02:49, 21 February 2021 (UTC)
    Please provide a link to that Wiktionary page. --Redrose64 🌹 (talk) 08:28, 21 February 2021 (UTC)
    What I mean is "unsupported titles" prefixpage and have subpages of it be unsupported titles. See wiktionary:Unsupported_titles/Number_sign for an example. For the page C#, we could have it be located at Unsupported titles/C-sharp and then have JavaScript change the title displayed to C#. Aasim (talk) 08:40, 21 February 2021 (UTC)
    There appears to be some JavaScript going on: on visiting the page, the title showed as "Unsupported titles/Number sign" briefly, which was then replaced by a single "#" character. --Redrose64 🌹 (talk) 09:00, 21 February 2021 (UTC)
  • Support as there are many titles that should have square brackets but can't. # is also a problem. But perhaps this could be done with a mechanism to DISPLAYTITLE that enabled checking for abuse. An edit filter could check for mistakes if a standard is set for mapping to the name. Note that there other unicode characters that are similar in appearance to the forbidden ones. Graeme Bartlett (talk) 22:47, 24 February 2021 (UTC)

RFC: Citation Style 1 parameter naming convention

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following lists: When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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)
  • B going to 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 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)
  • 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 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. Misplaced Pages 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)
  • Option C per Phil Bridger. SarahSV 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 /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 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 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 \\ 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 \\ 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 \\ 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 - /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)
  • 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 /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 \\ 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 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 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 /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)

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

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) ... checkY, 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 Misplaced Pages 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)
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 Misplaced Pages: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)

New speedy delete criterion (Not for Misplaced Pages)

This AfD could have been resolved earlier if there was this criterion. It was clearly not for Misplaced Pages, and it was a WP:SNOW anyway. The text should read as follows:

Ax. Not for Misplaced Pages.

Pages which qualify under Not for Misplaced Pages as not for Misplaced Pages. (templates)

-or something to that effect. This should be numbered A12. Please consider this, as it will help avoid future unnecessary AfDs like that. AnotherEditor144 21:56, 14 February 2021 (UTC)

Just let the process work out. It will be gone within a week. --Malcolmxl5 (talk) 22:18, 14 February 2021 (UTC)
Clearly not for Misplaced Pages is far too broad and subjective for a speedy deletion criteria. I'm a little more sympathetic to AFD snow as a speedy deletion criteria, except for the issue that sometimes it can be a while before someone comes along and does the legwork to find spources and save an article. ϢereSpielChequers 22:45, 14 February 2021 (UTC)

RfC: Disable minor edits on English Misplaced Pages

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following list: When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Proposed: Effectively disable the "minor edits" functionality on the English Misplaced Pages. Its usage will be limited by policy for anti-vandalism reverts only. Technically, the permission to mark as minor will be limited to rollbackers, admins and bots. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)


Survey (minor edits)

  • Support The point is apparently for some editors to ignore "m" edits on watchlists. No experienced editor would do so because "m" edits can be as wrong, disruptive, or destructive as a "major" edit. Vandals can use them for vandalism, newbie editors in good faith with problematic changes, and experienced editors may make something they believe is minor but other editors disagree. Really, all edits are subject to dispute. The point of a watchlist is to monitor articles. What's more, we apparently block editors for minor edits related issues. The functionality is not only useless, it's a net negative. Minor edits can be communicated via the edit summary and the diff count. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)
  • Oppose. I mark edits as minor all the time when they are, in fact, minor. Fixing typos and the like need not bother editors who don't want to see those edits. If there is a problem with non-minor edits being marked as minor, figure out how to figure those out. We already flag, for example, possible changes in birth and death dates. BD2412 T 20:03, 15 February 2021 (UTC)
  • Oppose a policy that minor should only be for vandalism reversion; I agree with BD2412 that actions such as small typo fixes, small whitespace adjustments, etc should still qualify as "minor" for patrolling and review purposes. Nuetral on an overlapping component of this, the removal of the minoredit permission from "All Users" - if it is being misused frequently by newer users might be helpful - but if so I think it should go to +extendedconfirmed and/or other groups (i.e. rollbacker/patroller) that otherwise help recognize that an editor has a modicum of experience here. — xaosflux 20:23, 15 February 2021 (UTC)
    • A perfectly cromulent use case is by a bot that has to make a non-content clean up to user talk pages, by declaring the edit minor and leveraging their nominornewtalk permission - the operator can avoid bothering users with a new messages notification. While "bots" were in the original proposal, this use case fails the "anti-vandalism reverts only" criteria. — xaosflux 20:41, 15 February 2021 (UTC)
      For clarity, I meant anti-vandalism only for human editors (bots being able to use it as they do). ProcrastinatingReader (talk) 20:44, 15 February 2021 (UTC)
      @ProcrastinatingReader: OK thanks, any bot use should already be governed by a specific WP:BRFA for whatever it is they are doing (and this is almost always used in addition to the 'b'ot flag). — xaosflux 20:52, 15 February 2021 (UTC)
      Re typos, a typo fix can still be disputed. Perhaps the editor got it wrong and the 'typo' was intentional. More importantly, Suffusion of Yellow's comment, especially about the evil bit, is a good way to phrase the issue imo. So long as some disputed edits can flow through it, the entire feature is worthless. The anti-vandalism allowance is because that's already governed by existing policy, WP:ROLLBACKUSE and WP:VAND etc, and allows pure 'junk' to be filtered out. Though I'm also okay with removing this exemption. ProcrastinatingReader (talk) 20:55, 15 February 2021 (UTC)
  • Support. So long as this feature is available to spammers, vandals, and the clueless, it's as useless as the evil bit. It's also a source of needless drama, when users innocently overuse it. But if people think this proposal goes too far, limiting it to extendedconfirmed would be a good start. Suffusion of Yellow (talk) 20:33, 15 February 2021 (UTC)
  • Oppose Why? Mike Peel (talk) 20:35, 15 February 2021 (UTC)
  • Support, tentatively, disabling the option when making a manual edit. It's simply not that useful; even experienced users don't agree on what it means, and don't use it consistently. The byte count is a much more effective way to identify "minor" changes at a glance, since it's less prone to manipulation. Because the minor flag can be set inappropriately, it's almost never reasonable to completely filter out minor edits, so it simply acts as a weak signal of intent on page histories, redundant to edit summary and byte count. Not convinced about making it antivandalism-only, though. — The Earwig ⟨talk⟩ 20:37, 15 February 2021 (UTC)
    After reading the comments in opposition and consideration of alternate solutions for the problem, I don't think this proposal as written is the way to go. — The Earwig ⟨talk⟩ 19:13, 16 February 2021 (UTC)
  • Oppose as written. It might make sense to further limit who can mark edits as minor, but eliminating them nearly wholesale as this proposal does goes too far. This is using a bunker buster to wipeout a few hornets. -- Calidum 21:11, 15 February 2021 (UTC)
  • Support the idea of disabling the option to mark edits as minor when editing manually. I don’t really see the point of making the ‘minor’ flag CV only, or granting it to admins or rollbackers. If we think it’s useless, then let’s deprecate it fully, rather than trying to debate who is experienced enough to use it. The only truly clear use for minor edits is bots editing user talk pages as Xaosflux sagely said above, so bots should obviously keep the right for that reason. Bot edits can already be filtered from watchlists, so other than on user talk pages it doesn’t matter whether bot edits are minor or not. ƒirefly ( t · c ) 21:35, 15 February 2021 (UTC)
    Other uses of minor edits include (but are not limited to):
    • Spelling fixes
    • Capitalisation fixes
    • Typo fixes
    • Grammar fixes
    • bold/italic fixes
    • List order fixes
    • Markup fixes (templates, tables, etc)
    • Small corrections to comments (e.g. missing words)
    • Signing unsigned comments
    • Whitespace fixes
    • Addition of templates that have no or minimal impact on content (e.g. {{As of}}, {{Update after}}, {{convert}})
    • Adjusting links
    • Adding/adjusting hatnotes
    • Protecting/unprotecting pages (automatically marked minor). Thryduulf (talk) 21:53, 15 February 2021 (UTC)
  • Very strong oppose. There is (probably) an issue that needs resolving behind this proposal, but there is no evidence presented for any of (a) the problem being widespread (i.e. that the solution lies with something other than educating and/or blocking individual users), (b) restricting minor edits will solve the underlying issue, (c) that restricting minor edits as much as is proposed is either necessary or proportionate, or (d) that the inevitable collateral damage will cause fewer and less significant problems than the original one. It is therefore way, way too premature to be bringing this to this board, let alone an RfC - it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth. Thryduulf (talk) 21:37, 15 February 2021 (UTC)
    it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth I've discussed this with other editors in multiple AN/ANIs last and this year, and this directly came from a VPT from this week. So that's not true. ProcrastinatingReader (talk) 22:26, 15 February 2021 (UTC)
    This is vague and lacking in so many ways I'm truly gobsmacked that multiple editors thought this was viable proposal. Thryduulf (talk) 23:02, 15 February 2021 (UTC)
  • Oppose. Most experienced editors use minor a lot when performing wholly uncontroversial typo fixes, minor formatting changes, wikifying and the like. This feels like a baby–bathwater situation. Espresso Addict (talk) 00:36, 16 February 2021 (UTC)
    The thing is in order for some people to gain some benefit from ignoring edits flagged as minor, others must continue to monitor all edits. At present it's like some people just play with the baby without taking a turn dealing with the bathwater. Which is OK when there's enough people who don't filter out minor edits, but it means that minor edit filtering inherently fails to scale up, and that makes me uneasy about touting its benefits for all. isaacl (talk) 00:59, 16 February 2021 (UTC)
    I think we're talking about slightly different things here. I see it as a signal from experienced editor to experienced editor that says nothing to see here, which seems unambiguously useful. You, I think, are complaining that editors who filter out minor edits in watchlists (or, like me, don't bother with a watchlist at all) are placing a burden on others to check them. That seems more a problem in the way watchlists are configured, rather than with the principle of edits being marked as minor/not. Perhaps an edit filter could be devised to flag edits that are clearly not minor, and remove the designation? Espresso Addict (talk) 02:02, 16 February 2021 (UTC)
    The signal is unfortunately not a reliable one. It's an AI problem to automatically detect minor edits. If it works well enough, then there wouldn't be any need for manual flagging. That might be a good idea, but I'm not sure if it should be given priority over other developer tasks, particularly given the likely high effort-to-benefit ratio. (I appreciate the advantage of the signal, when accurate, and have written about it in the discussion section.) isaacl (talk) 03:13, 16 February 2021 (UTC)
    I wouldn't object strongly to restricting the ability to mark edits as minor to, say, extended confirmed editors; or more usefully, letting inexperienced editors continue to mark them (so that they learn to do it to community norms), but ignoring the mark (from inexperienced editors) in watchlist presentations. I don't think AI is going to differentiate them accurately enough any time soon. Espresso Addict (talk) 03:48, 16 February 2021 (UTC)
    It already has the ability to filter based on experience and minor edits (as well as a contribution quality prediction), but I don't think it can be set for all edits from inexperienced editors plus non-minor edits from experienced editors. The reliability issue remains, even with experienced editors, so someone ought to be checking all minor edits. isaacl (talk) 04:06, 16 February 2021 (UTC)
  • Oppose, but open to reform. The minor edit designation is a piece of information, just like the edit summary, that has to be taken in context. When I see an "m" next to a reputable username, that saves me the effort of reviewing the edit. When it's next to a giant edit from an IP a redlinked user with a suspicious summary, that's different. For that reason, I don't filter them from my watchlist, but if someone else wants to do so, they can. That said, I agree misuse of the minor edit box is a problem. Here's a more modest proposal: limit it to autoconfirmed editors, and the first time someone checks it, have the software generate a popup that quickly explains what we mean by "minor". With that, we could take a harder stance on misuse of the box, since no one could claim they just didn't know. That might get us closer to a point where more editors feel comfortable filtering minor edits from their watchlist. {{u|Sdkb}}  07:19, 16 February 2021 (UTC)
    @Sdkb: unless I'm missing something, IP's can't tag edits as minor today (please point to any diff if you can see one). Unconfirmed users can - so the next "small step" up would be to remove that access from "All users" and give it to "autoconfirmed" users. — xaosflux 14:30, 16 February 2021 (UTC)
    You're correct; I've fixed my hypothetical. {{u|Sdkb}}  18:34, 16 February 2021 (UTC)
    @Sdkb: those are both steps that I can support, along with perhaps a byte limit for the size of a change to still be marked minor. BD2412 T 17:57, 16 February 2021 (UTC)
    A byte limit might be tricky; reverting a vandal blanking a page is a very valid minor edit, as it's clearly uncontroversial. As an alternative, maybe disallow if ORES flags it as possibly unconstructive? {{u|Sdkb}}  18:38, 16 February 2021 (UTC)
    Something like that would definitely be useful, yes. BD2412 T 00:20, 17 February 2021 (UTC)
  • Support The checkbox adds complexity to the process of making each edit, with very little benefit to other editors, and just a little anxiety at perhaps getting it wrong. On average, I guess I spend half a second to a second on this decision each time. Doing the math, that adds up to 2 to 4 working weeks of my life over the past decade. -- John of Reading (talk) 08:28, 16 February 2021 (UTC)
    @John of Reading: if it bothers you personally you can add this one line to your Special:MyPage/common.css and you won't have to see that box anymore:
    #mw-editpage-minoredit {display: none;}
    — xaosflux 19:57, 16 February 2021 (UTC)
    @Xaosflux: The checkbox I use most is the one in AWB, not the one in the edit window. But if I hide the checkbox, or always leave it unchecked, and some other editors think the distinction is important, then I'll be failing to signal correctly to them that most of my edits are minor. -- John of Reading (talk) 20:09, 16 February 2021 (UTC)
  • Strong oppose as unnecessary and counter-helpful. A large percentage of my own edits are minor, and I like the ability to keep the groups separated (if only for myself). No reason other people should have to pore through my edits when all I did was correct spelling or fix date formats or eliminate the spaces before <ref>, etc. — JohnFromPinckney (talk) 18:11, 16 February 2021 (UTC)
  • Support limiting the "minor edit" checkmark to experienced users. It is very unreliable when used by newbies. - Vis M (talk) 21:04, 16 February 2021 (UTC)
  • Oppose A supposed vandalism revert isn't necessarily minor. And the fact that the flag might not be accurate is just like everything else on Wikpiedia. Every single page, edit, summary or whatever might not be accurate. Per the disclaimer "WIKIPEDIA MAKES NO GUARANTEE OF VALIDITY". Andrew🐉(talk) 23:12, 16 February 2021 (UTC)
  • Oppose per BD2412 and xaosflux. While I'm open to stopping non-autoconfirmed editors from marking edits as 'minor', I am in disagreement with the bulk of the proposal. Sdrqaz (talk) 20:42, 18 February 2021 (UTC)
  • Limit to autoconfirmed Any potential damage from misusing the minor edit flag is minimal---on par with moving a page. It takes time to figure out what's minor and what's not, and we already restrict IPs. While we can certainly improve our guidance on using the minor edit flag, the threat level doesn't warrant restricting autoconfirmed editors who we already trust with much more powerful tools in their hands. — Wug·a·po·des​ 22:31, 18 February 2021 (UTC)
  • Limit to autoconfirmed. We already prevent IPs from using the box, and new users can be assumed to be similarly inexperienced. However it is definitely useful for exconf+, and seeing as it's, well, a minor feature, autoconf should have access to it as well. Would be open to Sdkb's idea of having a popup the first time someone ticks the box, though I'm not sure as to the feasability of this on the software end. —pythoncoder (talk | contribs) 19:54, 19 February 2021 (UTC)
  • Nein - minor edits are edits that well, are minor. If we mark them as major edits, then it will only waste more editors time in the RC patrol backlog. — Preceding unsigned comment added by Awesome Aasim (talk • contribs) 03:15, 21 February 2021 (UTC)
  • Limit to autoconfirmed. For experienced users, especially when working with other editors, this is an important flag. Anyone who does not trust the minor edit flag can still look at all edits, so why could there possibly be a need to remove this functionality?ThoughtIdRetired (talk) 15:07, 21 February 2021 (UTC)
  • I very strongly oppose the idea as proposed, but agree with Pythoncoder (this is the second RfC today I've agreed with him on) that limiting it to autoconfirmed is a good idea. JJP...MASTER! JJP... master? 01:55, 22 February 2021 (UTC)
  • Support with comments: (1) Admins should be permitted to mark any of their edits, vandalism-related or not, as ‘minor’ if they they deem doing so beneficial to the community. For the rest of us (non-bot editors), rollback seems as good a threshold as any. (2) ‘Minor’ may cease to be the optimal name for the tag. ‘Procedural’ might be more apt? No idea if there’s anyway to change that for the sake of new editors. —jameslucas 03:14, 23 February 2021 (UTC)
  • Oppose Minor edits are important - the little changes to markup, spellings, white space, capitalisation, changes/updates to numbers, correcting typos: they are the little things that make the bigger machine work. By removing "minor edits" as a tag, you run the risk of flooding timelines with clutter, and potentially dissuade editors from making necessary minor changes in the first place. doktorb words 07:25, 23 February 2021 (UTC)
  • Oppose per Mike Peel. --Jayron32 19:31, 24 February 2021 (UTC)
  • Oppose. If someone is inappropriately flagging non-minor edits as minor, that's a user conduct issue, not a reason to deprecate minor edits. Speaking as someone who's apparently made 318,850 minor edits, it's of no benefit and causes obvious disruption if readers who don't need to be made aware every time I quietly search-and-replace the misspelling "targetted" are unable to filter it from their watchlist. It would also make reviewing editors' contribution histories (whether it be for processes like RFA, or just "I'm looking for the diff of that edit you made last week") orders of magnitude more complicated, for no obvious benefit. ‑ Iridescent 19:45, 24 February 2021 (UTC)
  • Oppose - Personally I don't ever use it even if I'm indeed making minor edits... It really is too much effort clicking on one box everytime I want to save changes... that being said not using it isn't a reason to support and no reason has been given as to why this should be disabled in the first place. –Davey2010 23:12, 24 February 2021 (UTC)
  • Oppose. I am somewhat sympathetic to the proposal but the problem and its scope need to be much better defined, and the proposed solution appears to be too radical. I mark copyedits as minor all the time; same for manual delsort edits. If the feature is used properly, I find it quite useful; if an edit is marked as minor in my watchlist or in a page history, I am much more likely to ignore that edit. I agree probably is some issue with the misuse of this feature, but at the moment I am unsure about the extent of the problem. Perhaps less radical solutions, such as limiting the class of users with the userrights to mark edits as minor, and trying to provide a more precise definition of what constitutes a minor edit would be useful and should be attempted first. Nsk92 (talk) 23:50, 24 February 2021 (UTC)

Discussion (minor edits)

Although the minor edits flag isn't a reliable one to use for filtering all edits, it can be used (visually) to filter edits from editors you know. This advantage is, of course, only available to you if some of your known editors actually use the flag. isaacl (talk) 21:13, 15 February 2021 (UTC)

@ProcrastinatingReader, would your actual problem be solved by changing the default prefs settings to show minor edits? Whatamidoing (WMF) (talk) 21:55, 15 February 2021 (UTC)
The issue I have is that the functionality doesn't make sense. I don't think it ever makes sense to actually hide minor edits in a watchlist. The indicator itself may be helpful nevertheless, but is still redundant to the summary + byte count. I think Suffusion of Yellow and The Earwig's comments put my concerns succinctly. My second issue is individual admins thinking blocking even a single editor for their use of the minor indicator (eg or blocking individual users) is appropriate. I think the issue is frequent enough, per it having a section in a policy page (Misplaced Pages:Vandalism#Gaming_the_system). ProcrastinatingReader (talk) 22:22, 15 February 2021 (UTC)
If you could configure specific editors for which minor edits would be filtered out, it might be more useful. But given the low amount of usage, and the amount of overhead processing required for that level of filtering, I don't think it's worth the development and ongoing sustaining cost. isaacl (talk) 22:40, 15 February 2021 (UTC)
How do you know which editors to filter out? I think it'd be difficult to create an exhaustive list of editors who are incapable of using the feature. If it's a local list, it'd be very difficult for editors to maintain it (besides, if you have minor edits hidden, how do you know which editors are misusing the minor feature to add to the list since, well, you won't see their edits?) If it's a global list, I sense more pointless ANI drama. Plus, it may just be one-off edits that require more scrutiny rather than continuous inability to determine what is minor or isn't. ProcrastinatingReader (talk) 22:44, 15 February 2021 (UTC)
It would be up to individual users to decide whom they trusted to properly flag minor edits, and then configure their watchlist accordingly. But like I said, I don't think the work to implement this warrants the benefit. I didn't realize the current filtering capability allowed for level of experience to be configured; I'm not sure if that is useful or not for one's watchlist. isaacl (talk) 00:03, 16 February 2021 (UTC)
@ProcrastinatingReader, if the function doesn't make sense to you, then why do you propose that certain editors should continue to use it?
I think that whether it makes sense depends upon which version of the watchlist you're looking at. If you have each edit displayed separately, then it could let you skip a lot of edits that you don't want to see (e.g., ClueBot reverting simple vandalism, which is marked 'minor' but not as a 'bot' edit).
The minor edit flag is displayed in Special:RecentChanges as well. This allows interested editors to filter (for example) for minor edits by less-experienced editors that are the most current version of the page. I imagine that this would be an interesting list for both anti-vandalism patrollers and people seeking out promising editors. Whatamidoing (WMF) (talk) 23:05, 15 February 2021 (UTC)
The answer to the first paragraph is your second paragraph: so that ClueBot, and Hugglers, reverting simple vandalism can continue to be filtered out of watchlists. It's less restricting it to certain editors, and rather restricting it for a certain purpose. Even rollbackers and admins wouldn't be allowed to mark as minor "grammar changes", for example, under this proposal. ProcrastinatingReader (talk) 23:21, 15 February 2021 (UTC)
That's the problem with this proposal - vandalism fixing is only one of many valid reasons to mark an editor minor, including grammar changes (a I wrote a non-exhaustive list above). You seem to be assuming that everybody uses Misplaced Pages in the exact same way you do, which is flat out wrong. Thryduulf (talk) 12:28, 16 February 2021 (UTC)
As an example, this edit is very clearly a minor edit yet it has nothing to do with vandalism. Thryduulf (talk) 12:39, 16 February 2021 (UTC)
  • Since this proposal is unlikely to get consensus as written, here's a completely different suggestion, more narrowly targeted at what I see is the most egregious problem: the fact that we occasionally block otherwise productive editors for misuse of the minor edit feature. Allow admins to disable the minor edit flag for an editor as part of the blocking interface, in the same vein as partial blocks or disabling email, but without restricting the ability to edit. — The Earwig ⟨talk⟩ 15:21, 16 February 2021 (UTC)
    • Two thoughts. The first, is it actually technically possible? If not, I think it’s unlikely to get through phab and even if it did we run the issue of having people reporting each other even more than now to ANI for “minor edit marking violations” for a “minor edit block”. The second, the feature would still be useless imo, but that’s just my idealism talking I suppose; if editors aren’t being site blocked for it then I don’t care as much. ProcrastinatingReader (talk) 16:40, 16 February 2021 (UTC)
      Not currently possible, would require developer time. That alone makes it a bit hopeless, I suppose. But I'm still interested in how we can solve this problem in a more targeted way. — The Earwig ⟨talk⟩ 16:52, 16 February 2021 (UTC)
      Indeed it isn't currently technically possible, but a lot of work has recently been done on partial blocks and marking edits as minor is something that is given to only a subset of users so it strikes me that it is something that going to be possible with a reasonable amount of work (I'm not a developer though). Thinking of ways to solve the actual problem in a focused way that doesn't cause massive collateral damage is absolutely the right thing to be doing though - indeed this is the sort of thing that should have been done before coming here with a proposal, let alone an RFC. Thryduulf (talk) 17:25, 16 February 2021 (UTC)
      @The Earwig and ProcrastinatingReader: I've created a phab task for this, see phab:T274911. Thryduulf (talk) 17:29, 16 February 2021 (UTC)
      Since minoredit is a separate user right, if it were to be assigned by bot instead of being a permission set for all users, then it could be removed from anyone who used it inappropriately. isaacl (talk) 19:36, 16 February 2021 (UTC)
      @Isaacl: I think you might be mixing up some terms here? It could be possible to make a group that includes the minoredit permission; and it would be possible to make it auto-assign-once on a threshold (like extendedconfirmed) such that it could be revoked - but that is a lot of overhead for such a small permission (and I don't think we'd get "bots" involved with this process at all). — xaosflux 19:50, 16 February 2021 (UTC)
      It's not something I know a lot about, so almost certainly. I elided talking about groups for simplicity, and I didn't know (or forgot) about auto-assign-once; my apologies. Yes, it would be overhead, but less than enhancing the partial block capability to support blocking a user from flagging minor edits. isaacl (talk) 19:55, 16 February 2021 (UTC)
      It would also be possible, without any overhead in the common case or coding effort, to create a group that removes the ability to make a minor edit using $wgRevokePermissions. This way of doing it also avoids the issue of blocks being seen as a stain on people's record that was pointed out by Suffusion of Yellow below. That said, I am far from convinced that any of this is actually a good idea. * Pppery * it has begun... 23:38, 16 February 2021 (UTC)
      @Pppery: from a quick check we have exactly one project using that setting in all of WMF, and it looks like they haven't used it in over 10 years so I'm shocked it is still around (looks like may get merged in t pblocks - see phab:T227618). It does leave a "stain" on the user's rights log of course (e.g. w:ta:Special:Redirect/logid/58001. — xaosflux 00:11, 17 February 2021 (UTC)
      As I recall when I was working with another Wiki implementation that had similar functionality, it can be useful in a corporate setting when defining user groups and managing their permissions. isaacl (talk) 00:20, 17 February 2021 (UTC)
    • This would be a fantastic source of drama. A block (even a partial block) isn't just the technical inability to do something, it's (for better or worse) going to be viewed by the user as a "stain" on their record. For something as trivial as this, that doesn't seem worth it. Suffusion of Yellow (talk) 20:00, 16 February 2021 (UTC)
  • When you see a ±10k edit marked as minor, you know that the editor is almost certainly up to no good. Narky Blert (talk) 17:55, 16 February 2021 (UTC)
  • Apparently more than seven thousand users have been warned for marking non-minor edits as minor. Has the opposite ever happened? I.E. "you're making typo fixes but not marking them as minor, please start using the flag or I'll drag you to AN/I". Suffusion of Yellow (talk) 19:52, 16 February 2021 (UTC)
    When training I always say that if you are in any doubt about whether and edit is minor assume it isn't as the worst that will happen is someone will give you friendly advice, but marking a major edit as minor could lead to people getting angry at you. Thryduulf (talk) 21:06, 16 February 2021 (UTC)
  • I'm surprised that productive editors are being blocked for their use of minor edit marking. Are there more cases than the one mentioned by The Earwig above? That particular case seems highly unusual as the editor is apparently using an iOS app that does not receive notifications, and hence is not responding to feedback. Someone being blocked for vandalism marked as minor is clearly being blocked for vandalism. Espresso Addict (talk) 00:44, 17 February 2021 (UTC)
    Good question, Espresso Addict. I dug up some examples of editors being blocked for marking edits as minor. In most cases, there are other reasons for the blocks, of course: . — The Earwig ⟨talk⟩ 07:37, 17 February 2021 (UTC)
  • Comment. I voted oppose above and indicated I would be open to limiting who can mark edits as minor. I've noticed several people have since suggested only allowing autoconfirmed users to mark edits as minor, but I was under the impression it was already limited to autoconfirmed users. If not, I see no reason why that shouldn't be the case. -- Calidum 21:11, 24 February 2021 (UTC)
    @Calidum: The present situation is that you dn't need to be autoconforemed to mark edits as minor, just be logged-in. --Redrose64 🌹 (talk) 17:12, 25 February 2021 (UTC)
  • Some of the topics I keep my eye on are prone to POV vandalism. Often the vandals attempt to hide their vandalism behind a “minor edit” tag. This is (counterintuitively) quite helpful when it comes to spotting and cleaning up such vandalism ... I have learned to pay extra close attention to edits that are marked as being “minor”. Thus, I would oppose doing away with the tag. Blueboar (talk) 23:03, 24 February 2021 (UTC)

Class date stamps

Several articles have on the talk page a label of quality in the form of Class levels. However, it is quite difficult to find out when the assessment was made and often the assessment may be several years old and not corresponding to the current level of the article. Would it be possible to add a time stamp on these assessments (in the same way as for the templates indicating need of editing in the article itself)? Ideally, this would be done retroactively with robots going through and adding time stamps to all those assessments already made. --Olle Terenius (UU) (talk) 11:17, 16 February 2021 (UTC)

Hmm, interesting thought! The benefit would have to be weighed against the potential for watchlist clutter. I think the first reform that needs to happen with quality assessments is getting them unified to one per article, rather than having one per project per article. {{u|Sdkb}}  03:14, 17 February 2021 (UTC)
Not that I have any clue or involvement in article-assessing projects whatsoever, but wouldn't such a unification be potentially difficult, esp. when there are more than just a couple projects involved? I mean, consider the (currently fictional) article Military music of Poland as a hypothetical case. The Polish project is happy with it and assesses it highly, but the Music project folks see that it's missing a bunch of the necessary music, um, stuff they require. The Military crew might have a third opinion of the quality of the article. And again, I have no idea how realistic this scenario is. — JohnFromPinckney (talk) 03:30, 17 February 2021 (UTC)
While I can see some people don't like cluttering talk pages with multiple assessments, it's common for different projects to have different standards and for one project's material to be well covered while another one's is lacking. How would we decide whose opinion prevails? Also, if the assessments were unified, what would happen to the importance assessments, which clearly differ between projects? Espresso Addict (talk) 03:38, 17 February 2021 (UTC)
I mostly agree with this, but some projects (like the military wikiproject) do their own assessment (eg A class ratings). That would have to be allowed to continue. But most projects are not really that active or well organised as MILHIST, and most ratings are not even done by WP members but just page patrollers etc. So something should improve about the system, probably. ProcrastinatingReader (talk) 05:26, 18 February 2021 (UTC)
Per-wikiproject assessment is dead, and should simply be deprecated. It is already formally overwritten for GAs and FAs, and I'm not sure it ever happens outside of MILHIST A-class. If MILHIST rates an article as A-class, that rating should apply to the quality of the article as a whole, and could receive a single timestamp much as GA and FA currently do. CMD (talk) 07:21, 23 February 2021 (UTC)

Notification of an RFC

Users may be interested in the RFC at Misplaced Pages talk:Page mover/delete-redirect § RFC on granting delete-redirect to page movers. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Science Photo Competition 2021 Russia targeting CentralNotice banner

On Marth 1, the «Science Photo Competition 2021» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 11:43, 21 February 2021 (UTC)

CentralNotice proposal for International Women's Day

A proposal has been made to run a CentralNotice banner for both anonymous and logged-in users from March 1-10 for International Women's Day, highlighting gender gap issues. The proposal is at m:CentralNotice/Request/Int. Womens day 2021. --Yair rand (talk) 11:36, 22 February 2021 (UTC)

I'm only a man, but can somebody tell me when International Women's Day is? You know, a date? Neither of those two links tell me when this damned thing is supposed to be. I guess all the women already know it, but if we're all supposed to celebrate it, or it's supposed to mean something, why is it kept such a big secret? — JohnFromPinckney (talk) 02:09, 23 February 2021 (UTC)
International Women's Day is 8 March. --Malcolmxl5 (talk) 02:25, 23 February 2021 (UTC)
Maybe the reason all the women already know when it is, is because they tried clicking the links, or reading the first sentence of International Women's Day. ¯\_(ツ)_/¯ Levivich /hound 02:29, 23 February 2021 (UTC)
If you don't fancy Google, then there is this nifty online encyclopaedia that has articles about things like this and much more. It's called Misplaced Pages, you might even have heard of it? Anyway, you can find their article at International Women's Day, and in the very first sentence it says International Women's Day (IWD) is celebrated on 8 March every year around the world. it's got a citation and everything! Thryduulf (talk) 02:32, 23 February 2021 (UTC)
Yes, friends, thanks for providing the actual date along with the snide remarks. I was 98.3% sure somebody was going say, "but it's right there in big <color> letters!", and I had just completely overlooked it. And yes, I could have googled, or looked directly for a WP article on International Women's Day, but I foolishly followed the provided link to International Women's Day, thinking (sort of on autopilot) that that must be it.
And while it's good and right that International Women's Day (the unlinked one) included the date, I still think two other pages which make a big deal out of "International Women's Day" would at least mention when it is. You know, for us ignorant people who might learn something. I know when Christmas Day and the Fourth of July and New Years Day are, but I haven't learned IWD yet. Or maybe I'll know it now. — JohnFromPinckney (talk) 04:20, 23 February 2021 (UTC)
Second link in the OP, top of the page: One global banner for International Womens day 2021, available for all gender gap activities around the 8th of March. Levivich /hound 04:27, 23 February 2021 (UTC)
Ah, now I see it. Still took me a whole minute, even with your directions. Thanks. — JohnFromPinckney (talk) 04:36, 23 February 2021 (UTC)
You're welcome. As a man, I'm proud you even asked for directions. Levivich /hound 05:52, 23 February 2021 (UTC)
International Men's Day is 19th of November. Emir of Misplaced Pages (talk) 21:51, 23 February 2021 (UTC)
Well, shoot, everybody knows that. Minor, finicky detail: I didn't know there even was a International Men's Day. — JohnFromPinckney (talk) 22:47, 23 February 2021 (UTC)
This is not advocating for a cause, this is a notice bringing to our attention several events aimed at filling in gaps in the encyclopedia. --Malcolmxl5 (talk) 15:35, 25 February 2021 (UTC)
Reiterating support for this central notice. You may disagree with advocacy, but worth noting English Misplaced Pages in general has done advocacy e.g. Misplaced Pages:SOPA initiative, and while not community sanctioned, the Wikimedia Foundation sued NSA. This event itself is not advocacy and most concretely is a call to improve content on Misplaced Pages. Shushugah (talk) 15:49, 25 February 2021 (UTC)
I try to avoid where possible much celebration of such days, because they often serve as excuses to ignore relevant issues for the rest of the year, but if this encourages people to take part in events that aim to improve Misplaced Pages then I see no reason to oppose it. It is not advocacy, as in telling people what they should think, which I do oppose. Phil Bridger (talk) 16:32, 25 February 2021 (UTC)
  • I believe that the actual proposal for the banner has been made on meta. The original post by Yair rand above contains a link. Probably editors wanting to express support/oppose opinions should do so there, not here. Nsk92 (talk) 18:11, 25 February 2021 (UTC)

User pages

In my opinion it would be better to allow the edits of the user page and its sub-pages only to the "page owner" For example, if user X creates his page, only he will be able to edit it --Dr Salvus (talk) 15:15, 25 February 2021 (UTC)

There are many reasons why non-"owners" would want to edit such pages. Userfying articles. Moving AfC drafts. Tagging for deletion. Tagging socks. Fixing syntax errors. Disabling mainspace categories. Removing fair use images. Removing offensive content. Removing copyright violations. The user may be an alternate account. It may be a bot account. It may host a public page/list for editing/maintenance. And then there's user talk page archives. Etc. etc. —  HELLKNOWZ   ▎TALK 15:21, 25 February 2021 (UTC)
Note that non-autoconfirmed users are already prohibited from editing userpages via an edit filter. I don't believe there's any reason why user pages should be restricted in such a manner, there are plenty of reasons (as articulated above) to edit pages in someone else's userspace. — csc 20:49, 25 February 2021 (UTC)
Would be totally against existing community consensus at Misplaced Pages:Ownership of content and Misplaced Pages:User pages#Ownership and editing of user pages. As mentioned, there's already an edit filter to prevent vandalism by unconfirmed editors to user pages that are not their own. ✨ Ed talk! ✨ 21:06, 25 February 2021 (UTC)

Adding more information in templates

Dear editors and others of Misplaced Pages. Forgive me for I am new to this site. I have enjoyed using Misplaced Pages for as long as I can remember. However, after visiting the site so many times, I feel that somethings are missing. For those who don't have time to read every single piece of information on some historical or current leader. politician, etc, etc. They don't know how to get this information. I propose a couple of ideas for the templates.

Ideas

What I am proposing is this.

Tenet: Progressive, Neutral or Conservative

With this, users and those visiting the site can learn what their favorite historical or current leaders' tenet is.

For example. These are just a couple of historical individuals to give you an idea.

Progressive: Oda Nobunaga, Qin Shi Huang, Date Masamune and Cao Cao.

Those who wish to move forward towards a better future and life.

Neutral: Sun Quan, Sanada Yukimura, Zhang Liao, Minamoto no Yoshitsune and Tokugawa Ieyasu.

Those who wish to join neither side whether it be a conflict, war, religious matter, etc, etc.

Conservative: Adolf Hitler, Takeda Shingen, Liu Bei and Zhuge Liang.

Those who wish to stay in the past and protect old traditions.

Ideals: Ambition, Fame, Talent, Family, Determination, Mastery, Greed, or Justice.

Fame: Those who wish to obtain as much glory and status as possible.

Ambition: Those who have big ideas for the future and the world.

Talent: Those who wish to show their talent and make themselves known.

Greed: Those who wish to achieve everything they want by any means.

Determination: Those who wish to achieve their goals with any opportunity that comes or is available.

Family: Those who goals are solely to ensure that their family, clan, business, etc, etc, stays strong and endures.

Justice: Those who wish to make sure evil does not prevail and to protect those whom they love.

Mastery: Those who wish to continue to prefect their craft whether they are a swordsman, priest, blacksmith, merchant, etc, etc.

With this, users and those visiting the site can learn what their favorite historical or current leaders ideals are.

Fame: Shimazu Yoshihiro and Minamoto no Yoshitsune

Talent: Toyotomi Hideyoshi and Kuroda Yoshitaka.

Greed: Dong Zhuo, Tokugawa Ieyasu, Matsunaga Hisahide and Lu Bu.

Justice: Sanada Yukimura, Hosokawa Tadaoki, Liu Bei, Zhuge Liang and Zhao Yun.

This give you an idea.

Tier: C, B, A or S.

With this, users and those visiting the site can learn what their favorite historical or current leaders tier.

S: Cao Cao, Oda Nobunaga, Zhang Liao, Imagawa Yoshimoto, Zhuge Liang, Qin Shi Huang, Minamoto no Yoshitsune and Toyotomi Hideyoshi.

A: Kuroda Yoshitaka, Miyoshi Nagayoshi, Hosokawa Tadaoki, Akechi Mitsuhide and Shimazu Iehisa.

This gives you an idea.

Rebellious: 1 ~ 15

14: Date Masamune and Ōtomo Sōrin.

13: Miyoshi Nagayoshi.

12: Oda Nobunaga, Toyotomi Hideyoshi and Kuroda Yoshitaka.

11: Imagawa Yoshimoto.

This gives you an idea.

If these ideas are added to templates, it should help users and newcomers learn must faster and more efficiently on what or who they wish to learn about. It doesn't have to just apply on people, but policies, groups, organizations or whatever it can be applied to.

This is what I propose to help Misplaced Pages help those who want to known this type of information is essential to any avid leader or newcomer. Like with everything, Misplaced Pages must move forward. If not, those who do not are doomed to fail. That is all I have to propose at the moment. — Preceding unsigned comment added by Azuchi1579 (talk • contribs)

Categories: