The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Should we add pronouns to the signatures of new users? Should we add pronouns to the signatures of old users? What format should these pronouns be in, if they are added?

Options for new users:

A: Add new pronouns to signature automatically when they sign up, choosing their pronouns in the sign-up screen.

B: Give new users the option to add their pronouns to their signature when they sign up

C: Do nothing, do not give users the option to easily add their pronouns to their signature.

Options for already existing users:

A: A drive to encourage Wikipedians to add their pronouns to their signature in the way they choose

B: Automatically affixing the pronouns on file to the end of the signature

C: Not encouraging users to add pronouns to their signature

Options for format (using they/them as an example):

A: (They/Them)

B: (they/them)

C: [they/them]

theleekycauldron (talk • contribs) (they/them) 23:35, 1 March 2021 (UTC)

Meh... You are overthinking it... those who care about their pronouns usually let others know their preference. Some put it on their user page (so it is a good practice to check), most simply correct you (politely) if you use something “incorrect”. As long as we respect another editors wishes when informed of their desires, we all get along. Blueboar (talk) 00:49, 2 March 2021 (UTC)

I agree with Blueboar. But a real problem (for me) is that I am now forced by the software to choose between they, she and he, which is really irritating. I don’t care how people refer to me, but that I am forced to choose between a gender and “they” is off. No choice, or prefer not to say, should be an option in the preference settings. SandyGeorgia (Talk) 00:54, 2 March 2021 (UTC)

• Just for ease of use, I think we should have an option in preferences that helps editors add pronouns to their signature, but I'm suspicious of going further than that. There are risks to identifying as a non-cisgendered man (i.e., woman, non-binary, or trans man) on the internet, and without advising new editors of that reality, we should avoid encouraging editors to reveal personal info they may one day wish to take back. Of course, we should allow them to make that decision, and even make it easy once they have come to a decision, but we should not force anyone to reveal information about themselves that could put them at risk of harassment. For that reason, I think adding pronouns to the signatures of new users automatically is a bad idea, and even having an option at sign-up is something to avoid. For existing users, we should not add pronouns automatically. Personally, I have gender neutral references set in my options, but I'm fine with editors using any pronouns to refer to me. Adding pronouns automatically to my signature would make it seem as if I want editors to use "they" exclusively when that is in fact not necessarily the case. I also like my signature as it is and don't want others futzing with it unless it's breaking something. As for how to format pronouns in signatures, I would avoid using square brackets or curly brackets since those are used to denote links and templates and could cause problems with the software or bots. I don't care about the capitalization. — Wug·a·po·des​ 01:14, 2 March 2021 (UTC)
• Pretty much what Wugapodes said. I would support making it easier for those who wish to add them to do so, but do not support making it mandatory. I'm not even sure what I would choose, as my pronouns vary situationally. --Khajidha (talk) 01:29, 2 March 2021 (UTC)
• I don't think this is a good idea for a two main reasons:
  1. Not every user wants to reveal this information - especially those are typically targets of online harassment for their gender - and including this in a sign-up form makes the implication that gender revealing is required, no matter clearly worded otherwise; and
  2. Pronoun selection is not a simple enumeration; pronoun policies are far more complex than a trinary of he/she/they. The correct way to handle this is as a free-form field, but in English alone a pronoun has multiple forms, so we'd have to provide multiple fields, which makes for a UX nightmare

  The reasoning behind this is good faith, but I just don't think it's achievable in the way the OP is wanting.--Jorm (talk) 01:45, 2 March 2021 (UTC)

• I find myself agreeing with Jorm in large part here. The implementation of this, if done correctly, would simply be another free-form field for users to put things in... and those who know how to find and use it would likely be those who can handle adding them to their signature manually if they really want them there. I also do not want to get into this idea that people should "have" to or even be encouraged to display a set of pronouns - there are many people who wish to be referred to as different pronouns depending on the situation, and people shouldn't feel like they need to reveal information that for some people is hard to reveal. I am especially worried that non-cis-gender editors (or those who use other pronouns) will be caught between a rock and a hard place - using their preferred pronouns and the potential harm that could come from that, or using non-preferred pronouns and having to see them often. TLDR: People who want their pronouns in their signature can do so already, and I do not see any policy based reason they can't go manually add it now. I am undecided on an alternative to have an option in settings - if this were implemented, I think it needs to be optional, and the viewing of pronouns in signatures should be opt-in - i.e. they should not automatically appear. Again, this is because if it was mandatory or built in, people would be harmed by that. Not to mention that we can simply talk to each other - hell, people don't even know whether I'm a male, female, non-cisgender/non-binary (I can't include all options here, obviously), etc. I have had multiple editors refer to me as a she based on my username, and I've had others refer to me as a he based on my username, and I've had a few people refer to me as "they" as an attempt to be respectful of not knowing my preference. If I had a strong feeling, I would simply just send a simple reply to the person stating my preferred pronouns and requesting they attempt to comply. And that's how it should continue. -bɜ:ʳkənhɪmez (User/say hi!) 01:54, 2 March 2021 (UTC)
• No change per above. As stated, we need to avoid making it seem like revealing one's gender is an expectation or imperative, and then some people either have to misgender themselves or reveal something about themselves they may not be comfortable revealing. And really, adding these to one's signature is already very easy if one is so inclined. One's "preferences" at the top of the page, when clicked, has a field where it's easy to type them in as part of the signature. Editors can also reveal their gender on their userpage, as many do. Crossroads ^-talk- 06:17, 2 March 2021 (UTC)

  I also oppose any text in guidelines that mention this practice. For Wikipedia to seem to engage in WP:ADVOCACY for this practice is extremely inappropriate. And given the real-world advocacy for it, any statement on it is inherently suggesting it be done and thus joining-in the exerting of social pressure. Again, typing them in that box in preferences is very easy and needs no specific instruction, and people can already easily write something on their userpage if they wish. Crossroads ^-talk- 06:00, 3 March 2021 (UTC)

• No change (C and C) per Wug and others above. Editors very much ought to learn to stop using the male default, editors who use the male default should be gently reminded not to do so, and editors who choose to specify pronouns in their signature should certainly be welcome to do so. However, I don't think that calling attention to editors' genders by making pronouns default would help us build a better encyclopedia, and indeed I could see it possibly worsening harassment against non-male editors by making them stand out. I think the status quo of using singular they by default works fine. ((u|Sdkb)) ^talk 07:14, 2 March 2021 (UTC)
• No change This seems like a solution looking for a problem. The above comments offer a buffet of good reasons why this is a bad idea, so I won't rehash them. Dennis Brown - 2¢ 11:56, 2 March 2021 (UTC)
• No change At Preferences → User profile I have deliberately left "How do you prefer to be described?" set to "They edit wiki pages" (IIRC the gender-neutral option was "I prefer not to say" until about 2014/15). In discussions, some people use a gender-specific pronoun when referring to me and a proportion of those people get it wrong: I never correct them. Curiously, people who have actually met me rarely use a gender-specific pronoun for me. Even so, I find it amusing when people flip a coin and it falls wrong-side up. --Redrose64 🌹 (talk) 14:12, 2 March 2021 (UTC)
• No change I'm opposed to encouraging adding extra wikitext to every signature for this, if someone wants to do it for themselves then whatever, but we shouldn't encourage it. I'd be strongly opposed to any sort of requirement that all old wikitext signatures needs to be edited to add/change for something like this - or if someone decides to change from "he" to "they" and back in the future. As far as the preferences section about what terms someone prefers in the interface, SandyGeorgia while it does say "they", "he", or "she" - you shouldn't be running in to much (any?) occurrence of actually seeing 'they' by the software are you? I tend to use singular they when referring to other editors when I type something about them (if they do not specify a preference) just because it is how I use natural language otherwise. @Theleekycauldron: are you aware that an editor's opt-in to request certain descriptors is already public and can be seen on tools like popups when you hover a user's linked name? — xaosflux ^Talk 16:04, 2 March 2021 (UTC)

  @Xaosflux: I don’t know; I don’t know where these preferences are used, or how they may be affecting what others see about me. It bothers me as much to be a “they” as it would bother me to be expected to reveal gender. I suppose my concern is how this preference setting might eventually be used, if it is not now. All I know is I am not allowed to not say in preferences. SandyGeorgia (Talk) 17:03, 2 March 2021 (UTC)

  @SandyGeorgia: I'll follow up on your talk. — xaosflux ^Talk 17:06, 2 March 2021 (UTC)

• No change (C/C) We absolutely shouldn't be requiring the addition of pronouns to every signature for multiple reasons - the technical/pragmatic (i.e. the extra wikitext will only serve to clutter up talk pages, and any kind of automated solution would require developer time that is sorely needed elsewhere), and the 'political' (i.e. we shouldn't require anyone to disclose anything they're not comfortable with). ƒirefly ( t · c ) 16:16, 2 March 2021 (UTC)
• Nothing mandatory - English Wikipedia has users in many countries and places where revealing one's non-binary gender opens them to persecution or real physical danger. We cannot force users to do this. As for encouraging users who wish to do so, writing up a guide would be a good first step, before we talk about how to promote it. This would include: how to set your gender pronouns in the software, how to add code to your signature to display your pronouns, and how to find/use the templates (like ((he or she)) and ((they))) which fill pronouns from a user's software gender setting. And how about a category of users willing to prepare code for less technically proficient users? I'd be willing to help write such a guide. Ivanvector's squirrel (^trees/_nuts) 16:20, 2 March 2021 (UTC)

  To Jorm's point about free-form pronouns: I think you're overthinking it. In general you can get away with three fields: the third-person subject (he/she/xe/they), the third-person object (him/her/xem/them), and (really optionally) the third-person possessive (his/hers/xyr/their), at least as far as doing things automatically; other forms can be derived manually. The site pronoun.is demonstrates this pretty simply (see for example the site's entry for singular they). I don't know how big of a project this would be and the devs probably have more important things to do already, but I think this is the simplest approach if software changes are on the table. Ivanvector's squirrel (^trees/_nuts) 16:37, 2 March 2021 (UTC)

  I really like the idea of guidance on how to do this, and I could imagine putting some text in WP:SIG to the effect of

  Some editors choose to include their personal pronouns in their signatures using a structure like [[User:Example]] ( [[User talk:Example|talk]] · they/them ) 20:42, 2 March 2021 (UTC).

  Even if this discussion results in no action on the software side (as seems likely), I would like the closer to summarize community sentiment around this practice so that we can draft some accurate text for guideline pages. For that reason I hope this doesn't get SNOW closed. — Wug·a·po·des​ 20:42, 2 March 2021 (UTC)

• No change can't see why this is needed or helpful when neutral pronouns exist that are quick and easy to use. It also makes the signatures longer and more confusing. I prefer that editors are judged by there edits and attitude and avoid any bias/accusations based on non-contributing attributes. KylieTastic (talk) 16:27, 2 March 2021 (UTC)
• No change I encourage and support (personally) any user who feels comfortable doing so to create a custom signature to add their pronouns to it. I think that is perfectly allowable, and every user who wishes should feel comfortable doing so. I see no benefit in forcing or encouraging people who do NOT feel comfortable doing so to basically make it required and/or mandated and/or heavily encouraged that they do so. I have not seen anyone be chastised for voluntarily putting their pronouns in their signatures, and if they were I would be there to defend them every time; however I don't think we need to mandate these things. --Jayron32 17:12, 2 March 2021 (UTC)
• I have no desire to find out about the contents of other Wikipedians' underwear, nor whether they're happy with the manufacturer fitted equipment, nor whether they've modified it, nor what they do (or don't do) with it. I'd rather keep my equipment out of the conversation too. Cabayi (talk) 17:31, 2 March 2021 (UTC)
• No change Users can edit their signature to be (almost) anything — adding (they/them) etc. is already possible — GhostInTheMachine ^{talk to me} 17:35, 2 March 2021 (UTC)
• No change (after a discussion on my talk with Xaosflux, who helped me understand how the current preference settings are used[1]). SandyGeorgia (Talk) 17:54, 2 March 2021 (UTC)
  • For anyone that wants to follow up on that part, see MediaWiki talk:Yourgender. — xaosflux ^Talk 18:15, 2 March 2021 (UTC)
• No change A distraction. The less known about the intimate identity of users, the better. An author who cares that much about such things should probably be writing elsewhere. Rollo (talk) 22:18, 2 March 2021 (UTC)
• No change defaulting to add pronouns to signatures placed in Wikitext will not improve Wikipedia. I believe editors can enable a tooltip (like popups) to view the information now. power~enwiki (π, ν) 22:23, 2 March 2021 (UTC)
• Nothing mandatory. We should make it trivially easy for people to add their pronouns, if they want to, and make sure that people know how to do this, if they want to, but we should not not push anybody into either doing it or not doing it. Personally, I would, but then my pronouns are he/him, which are the one set that are least likely to attract any unwanted attention. I have the specifically cis male privilege to be able to do this without risk. I can easily understand why other people, with other pronouns, might be far more wary. --DanielRigal (talk) 22:44, 2 March 2021 (UTC)

• Oppose, We have the right to self-disclose, and likewise we have the right not to. There's plenty of existing infrastructure in MW for discerning how to refer to a user - some of us do choose to disclose, but having it forced upon me would seem incredibly condescending. -- a ^{they/them | argue | contribs} 07:24, 3 March 2021 (UTC)

As a non-binary person, i completely agree– but i do think it should be much more accessible to add pronouns to a signature. theleekycauldron (talk • contribs) (they/them) 09:19, 3 March 2021 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

I'm proposing that we formally deprecate linking Wikipedia:Books in templates and articles. Wikipedia books have not worked for many years now but are still included in various templates (e.g. ((Star Wars universe)), ((Mercury (planet))), ((Abraham Lincoln))) and maybe some articles—I recall seeing some in various "see also" sections. It seems unhelpful and unproductive to lead readers to a page that says the service in question is unavailable and points the reader towards external (third-party) sources; I speculate that most readers will see this as a dead end and not pursue it further. Around two years ago ((Wikipedia books)) and the relevant sidebar were suppressed, so I don't see why we should contradict that practice by still providing useless links in templates (and supposably articles). Aza24 (talk) 06:48, 13 March 2021 (UTC)

More info available at Wikipedia:Wikipedia book creator status.

Past discussion on the template itself - Wikipedia:Templates_for_discussion/Log/2021_January_16#Template:Wikipedia_books

• Support. I'm not fully read up on the history of Wikipedia Books, but it seems like an experiment we tried and that failed. We should clean up after ourselves, which means not continuing to link to it after it's dead. ((u|Sdkb)) ^talk 05:04, 14 March 2021 (UTC)
• Support: as Sdkb says, let's clean-up after ourselves. GenQuest ^"scribble" 08:48, 14 March 2021 (UTC)
• Support As a loose end to failed project, as Aza points out, this is just a dead end that does no service to our readers. Beeblebrox (talk) 20:45, 14 March 2021 (UTC)
• Support Not a contentious suggestion and understandable. I like the principle of "cleaning up after ourselves." doktorb _words^deeds 21:37, 14 March 2021 (UTC)
• Support Wow, I had never even heard of these (which says a lot). ~ HAL333 00:18, 15 March 2021 (UTC)
• Support Failed experiment, should be deprecated.--Vulphere 04:52, 16 March 2021 (UTC)
• Support I have a ton of opinions about books and think it is a really difficult problem how to handle them. I think they have a non-negligible value if they ever get working properly again and even now there are a handful of people finding value in them. At the same time the namespace is filled with a lot of crap, the category system is in most cases a better tool for reading about a subject and linking to pages with large warning banners doesn't look good at all. I have previously proposed a technical way to hide these links without removing them so we could put them back if the issues are fixed at Wikipedia:Village pump (technical)/Archive 183#Mainspace book links but to be honest I am absolutley fine with just removing them as well. My solution, while workable, would definitely cause some confusion for non-technical editors and possibly weird formatting in places if someone touched whitespace around them. Straight up removal would also have the benefit of pruning the links if they ever need be re-added and should in theory only link to decent quality books. --Trialpears (talk) 16:19, 16 March 2021 (UTC)

  @Trialpears: The problem with the Category system is that its lists are essentially unstructured and can be very large; Books allow intelligent design. Also, book links are currently suppressed, much as you suggested. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)

• Strong object. The OP's "service in question", as described at Wikipedia:Books, is the Collection extension (aka Book Creator). It is very much here and working. And w have a Books: namespace with lots of books in it. We deservedly ditched our useless in-house renderer, but the idea that it is nowadays "the service in question" is nonsense. As stated on Wikipedia:Books and elsewhere, "As a result of anticipated future solutions, template transclusions should not be removed from articles." We would first need to establish a consensus to abandon any thought of such future services, such as adopting the long-anticipated Collector, and also of supporting external services such as MediaWiki2LaTex at WMFlabs. Then we'd have to agree to abandoning the Book: namespace. Let's discuss those first and not go round breaking them. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)
• Support per WP:NOTPAPER. If readers want to use an external service to print collections of articles, they may do so, but we have no need to maintain support indefinitely for services unrelated to our goal of building a wiki. As sdkb says, we tried books and it failed. Book:Star Wars and Book:Abraham Lincoln average 3 views a day each. Star Wars got more page views yesterday than the book gets in an entire year. Mark the namespace as historical, remove reader-facing links to it, and let it collect dust (I oppose deleting the namespace or pages per m:Keep history). We don't need to waste time maintaining support for a feature no one uses. — Wug·a·po·des​ 19:27, 16 March 2021 (UTC)
• Support I sometimes have seen the links at the bottom of articles and wondered what additional info they offer. Seems in some cases they are more of a fork to out of date content. Jtbobwaysf (talk) 05:59, 19 March 2021 (UTC)
• Support Essentially these are an external link. Reading the guidelines here Wikipedia:External links#What to link indicates that Wikibooks no longer meets most (if not all) of them. MarnetteD|Talk 06:46, 19 March 2021 (UTC)
• Support no more linking to dead namespaces. 🐔 Chicdat  ^{Bawk to me!} 11:10, 20 March 2021 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Proposed: Effectively disable the "minor edits" functionality on the English Wikipedia. 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)
  • Note: I support the below proposals to limit minor edits to either autoconfirmed or extended confirmed editors (preferably the latter). BD2412 T 04:56, 3 March 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 ^Talk 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 ^Talk 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 ^Talk 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)

  Support limiting to autoconfirmed as a first step. Oppose limiting to extended confirmed. I understand the arguments in favor, but I generally oppose expanding the role of EC by taking privileges away from autoconfirmed users (giving EC users privileges otherwise only available to more restricted users is another thing). Even with this we could not prevent every mistagging of edits as minor, nor should we strive to. The majority of minor edits tagged by someone with, say, 2 months of experience and 100 edits will be fine, and if they aren't, they're not likely to figure it out by the 500th edit. — The Earwig (talk) 06:46, 3 March 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)) ^talk 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 ^Talk 14:30, 16 February 2021 (UTC)

  You're correct; I've fixed my hypothetical. ((u|Sdkb)) ^talk 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)) ^talk 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 ^Talk 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!_{[talk to] 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^deeds 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^Talk 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)
• Oppose minor edits are useful to distinguish, well, which edits are minor. If minor edits are disabled, we have no way to distinguish here, so we lose information. Potentially faulty information - as improperly marked minor edits are - is worse than no information. Maybe limit to autoconfirmed, and in the worst possible case limit to extended confirmed, but removing entirely is not a good idea. Elliot321 (talk | contribs) 01:53, 28 February 2021 (UTC)
• Oppose as proposed per Xaosflux. I am open to limiting minor edits to autoconfirmed or extendedconfirmed, but not as proposed. Twassman | Talk | Contribs 06:48, 28 February 2021 (UTC)
• Support this makes "request minor edits feature" a main value of the rollback permission. Once somebody knows enough to want it, we should give it to them. power~enwiki (π, ν) 03:03, 2 March 2021 (UTC)
• Oppose A solution which would be far worse than the problem it seeks to address. Minor edits are useful. Limiting it to autoconfirmed users might solve most abuse (since most vandals are non-AC); if there is such abuse in the first place. RandomCanadian (talk / contribs) 03:44, 2 March 2021 (UTC)
• Oppose. While marking edits as minor isn't super useful, it does have some benefits when going through the edit history of an article. Of course the "minor edit" flag is just as reliable as the edit summary there (i.e. not very) and you shouldn't do anything automated based on the presence or absence of the flag. —Kusma (t·c) 11:55, 2 March 2021 (UTC)
• Support. Should be a privilege. At present it's worse than useless for vandalism and just superfluous cognitive overload for good-faith editors. Rollo (talk) 22:06, 2 March 2021 (UTC)
• Limit to extended-confirmed (autoconfirmed is too easy to get around) because only experienced editors should be able to mark edits minor. Then if I ignore minor-flagged edits, I won't have to worry about missing any non-EC edits. Levivich ^harass/_hound 04:42, 3 March 2021 (UTC)
• Oppose I don't think there is an Issue that needs solving. I think minor edits are a useful tool for actual minor edits. jort⁹³|talk 19:56, 4 March 2021 (UTC)
• Oppose This is a solution in search of a problem. Many users, myself included, do not abuse minor edits. This is like not allowing anyone to eat food because some people eat too much. Thank you, 🐔 Chicdat  ^{Bawk to me!} 11:58, 6 March 2021 (UTC)
• Oppose Just sanction those who abuse it. Minor edits are beneficial to this project overall. ~ HAL333 22:16, 7 March 2021 (UTC)
• Oppose as written. Support limiting it to autoconfirmed or extended confirmed. --Ahecht (TALK
  PAGE) 20:23, 9 March 2021 (UTC)
• Oppose Minor edits are clearly defined in WP:MINOR, and they have a good purpose. Besides, many people who revert vandalism are not rollbackers (like me) — Preceding unsigned comment added by Bop34 (talk • contribs) 20:46, 9 March 2021 (UTC)
• Oppose Just becuase some people may abuse minor edits it does not mean we should essentially remove their use to editors almost entirely.  Spy-cicle💥  ^Talk? 18:49, 10 March 2021 (UTC)
• Oppose, but open to reform, if we just got rid of minor edits, then it would either discourage people from making edits that are simply just spelling or grammar fixes or it would make it harder for those who moderate editing to figure out what is and isn't spam. A way we could reform this would be my making it so all edits under a certain size (say 100 bytes, this is simply an example) will be marked as minor and cannot be unmarked as minor. When I edited on Fandom (similar to Wikipedia except more for games) I would mark edits that are just me making small edits to articles (like fixing spelling or grammar) as minor because, well, they are. If we just removed the option to mark edits as minor then it might make people feel like they have to radically change the article. I'm probably repeating myself so I'm going to give another way to reform it. Just have all edits marked as minor by default. Yes, there is an option for this but I think people don't know that. Another way to reform, is, like I said above, have all edits under a certain size marked as minor and if someone attempts to unmark it as minor and its still under that size, a warning message pops up, letting the user know what the point of it being marked as minor is. When it gets over a certain size, it cannot be unmarked as minor unless the user has special permissions to do so (I.e they're a trusted Wikipedia editor). This is just my opinion but after reading all the stuff above I felt like I should contribute. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 01:08, 16 March 2021 (UTC)
  • Diff size is not a reliable way to determine what is and isn't a minor edit. A rewrite of an entire paragraph is not a minor edit but if it used the same number of characters it would have a diff size of 0 bytes. At the other end of the scale, adding an archive link to sources can add 50-100 bytes of text per URI but as it makes no change to the prose it would be valid to mark that as a minor edit. Thryduulf (talk) 01:23, 16 March 2021 (UTC)
• Oppose as proposed, Support for limiting minor edit to autoconfirmed/extendedconfirmed editors.--Vulphere 04:56, 16 March 2021 (UTC)
• Strongest Oppose There are other solutions to the dishonest use of the "minor" button. This, as proposed, should not be implemented. GenQuest ^"scribble" 16:38, 16 March 2021 (UTC)
• Support Bots, reverts have an obvious place for minor edits. While experienced users don't all agree on definition of a minor edit, they'll at least use it consistently, which can be useful for reviewing edits of a particular user. They are less useful however, when monitoring recent changes of a watchlist. In order to make them more useful, I'd recommend limiting the ability to enable minor edits to WP:ECP users who'd at least have a consistent rationale for what's minor/major. Shushugah (talk) 16:52, 16 March 2021 (UTC)
• Oppose Minor edits are useful. Not only for me to use when correcting typos, or to help me bypass minor edits by editors I recognize, but also because the "minor edit" checked plus a canned edit summary like "Fixed typo" is a clear red flag to check for vandalism or other disruptive editing. – Muboshgu (talk) 16:54, 16 March 2021 (UTC)
• Oppose - when looking at an article's history, it can be useful to see that an edit has been marked

as minor, for example, changing a single letter to correct a typing error. This is useful because it helps to distinguish minor edits from more major changes in an article. Rollo August (talk) 20:15, 20 March 2021 (UTC)

• Oppose - may discourage future edits ParallaxVision222 (talk) 16:28, 22 March 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 (Wikipedia: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 Wikipedia 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 ^Talk 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 ^Talk 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: [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]. — 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)

  We should rename it to Honeytrap 😅 Shushugah (talk) 11:08, 22 March 2021 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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

Authority control background

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

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

Authority control proposal

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

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

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

• There's probably something I'm missing, but the lead reference "Integrated Authority File" leads to a German language website for the Deutsche Nationalbibliothek which I would have expected under "National Libraries"? Other than that issue it does seem a good and sensible proposal. Martin of Sheffield (talk) 10:25, 18 March 2021 (UTC)

  Yes, I wasn't certain where to put this one. It is, to my best knowledge, an international standard, but maintained by the German National Library, and the text on the page is in German. These details (well, it's an important one) will need to be decided upon if the general principle of the proposal gets accepted. Fram (talk) 10:43, 18 March 2021 (UTC)

• Comment: Is the term "Authority control" even reader-friendly? Few readers other than librarians will have any idea what it means, and it sounds ... authoritarian? Should we talk about "Unique identifiers" for clarity? PamD 11:29, 18 March 2021 (UTC)

  No not really. Its a data/library term not a reader term. Only in death does duty end (talk) 11:41, 18 March 2021 (UTC)

  That would be better but is a separate discussion, I think. Fram (talk) 11:54, 18 March 2021 (UTC)

  I don't fully mind the term, as it is wikilinked, but it's not a major deal either way. Most casual readers likely don't even make it that far on the page. ɱ (talk) 13:58, 20 March 2021 (UTC)

• Oppose removing WP links - I'm pretty sure this has been discussed before, but that hasn't stopped Fram before, either. The links to, for example, LCCN inform the user of the AC-granting institution, and the ID link(s) n81033861 provide the information. Both are needed.   ~ Tom.Reding (talk ⋅dgaf)  11:39, 18 March 2021 (UTC)
  • Why should you require a reader to click on obscure acronyms to get the information about who issued the ID string, if you can include it much more clearly in the template directly like above? Most readers of the Oë article will have no clue at all what "NLG: 71274" is. In the new template, they see directly that it is a link to the National Library of Greece. Do they need an actual link to National Library of Greece from the Oe article? I doubt it, it is not relevant information for that article. Do they still have the link to the NLG ID page? Yes, that is still included. But now at least they will have a better idea of what they are presented with, without needing to click either link. Your two reasons are "informing the reader of the granting institution", which is in the proposed version done directly instead of requiring a click: and the ID links to provide the information, which is in the proposed version also still there, as it still is a link which still leads to the same information. Oh, and feel free to link to previous discussions, perhaps without the personal comments though. Fram (talk) 11:53, 18 March 2021 (UTC)
    • You brought it up, here, at this Village pump (proposal) in June 2018. Search "Option 2Names", which spawned "Option 2Wikidata", "Option 2pencil", and "Option 2edit". I too, at first, and others, liked these options, before realizing my statement above. Nothing personal, just facts about your person. Unfortunately, they seem like WP:I didn't hear that and/or slow-motion WP:FORUMSHOPPING.   ~ Tom.Reding (talk ⋅dgaf)  15:43, 18 March 2021 (UTC)
      • Oh, that trainwreck discussion ending in no consensus, but with a lot of support for the type of changes I propose here? Yes, that kind of discussion doesn't stop me from bringing a new RfC two years later. I do like the "Nothing personal, just facts about your person." though. Fram (talk) 16:22, 18 March 2021 (UTC)
  • LCCN, etc., links serve the additional purpose of notifying the editor which parameter they may use (|LCCN=) to either override the WD ID, or to suppress the ID altogether. With the proposed scheme, this is much more difficult to determine. Such a lack of foresight could have been avoided if there had been any discussion on the talk page, instead resulting in this very poor RfC.   ~ Tom.Reding (talk ⋅dgaf)  00:42, 19 March 2021 (UTC)
    • Despit the template being used on 1.7 million articles, the possibility to suppress links was used on 43 pages before I created the ACArt template recently. Such a barely used possibility (which will remain available anyway, but may if the RfC is successful need better documentation) hardly justifies making the template much harder to understand (and thus less likely to be used) for our readers. This is not a "lack of foresight", this is getting your priorities right. Fram (talk) 08:23, 19 March 2021 (UTC)
      • You're ignoring the ~2400 pages using Category:Pages using authority control with parameters (1). Par for the course though.   ~ Tom.Reding (talk ⋅dgaf)  10:18, 19 March 2021 (UTC)
        • For a start, hundreds of those seem to be redirects, which shouldn't have an authority control templatein the first place. But let's look at some actual articles instead. First one I checked at random, Anthony St. John Baker, has the same ID in the parameter as in Wikidata. Siddharth Basrur, added by same editor on Wikidata and a minute later on enwiki, so not necessary either. And in any case, the possibility isn't removed, in the few cases where it is needed they will just have to check a bit harder to get it right. Fram (talk) 10:43, 19 March 2021 (UTC)
          • At least we agree that this proposal will hamper functionality.
            Also, 353 redirects, on which AC is encouraged per Wikipedia:Authority control "If necessary, create a new redirect to carry the template." For an RfC, you are stunningly misinformed.   ~ Tom.Reding (talk ⋅dgaf)  11:37, 19 March 2021 (UTC)

            Maybe it's time to stop attacking Fram ("IDHT", "FORUMSHOPPING", "stunningly misinformed", "just facts about your person", and others)? Read the room: consensus doesn't agree with you. ProcrastinatingReader (talk) 12:02, 19 March 2021 (UTC)

            All facts relevant to the discussion.
            "Read the room"? This isn't a vote; this is based on merit, of which there's none, other than "it looks pretty". Introduce a version where WP links are kept, then we can move on to discussing how much taller the template will get, but that's a better starting point than this.   ~ Tom.Reding (talk ⋅dgaf)  12:39, 19 March 2021 (UTC)

            If all you see in the proposal is "it looks pretty", then I think we are done discussing things. Uses of this template on redirects, which no one will ever see and which serve no practical purpose on enwiki, are hardly a reason to keep a template as uninformative and opaque as possible. Fram (talk) 13:13, 19 March 2021 (UTC)

• Support improvements - Fram is right. The weird acronyms that no reader can be reasonably expected to know are utterly useless. You can hover over them to see what they mean, since they link to the respective article, but readers shouldn't have to do that to make sense of it. The presentation of the template currently is useless, and Fram's mock-up above is a leap of an improvement. Still, I think more can be done with this template. The "National libraries" presentation is good, the rest is still iffy imo. ProcrastinatingReader (talk) 15:19, 18 March 2021 (UTC)
  • When I hover of them, I get "Bibsys (identifier)", "BNF (identifier)", "CiNii (identifier)" and so on. Not very helpful. Fram (talk) 15:10, 19 March 2021 (UTC)

    When I hover over them, I get "BIBSYS is an administrative agency set up and organized by the Ministry of Education and Research in Norway. They provide the exchange, storage and retrieval of data pertaining to research, teaching and learning – historically metadata related to library resources." and other similar previews of the articles. I think it depends on whether you've got page previews (Preferences -> Appearance -> Enable page previews) or navigation popups (Preferences -> Gadgets -> Navigation) enabled. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)

• As stated at the VPI discussion, I support the general change. I have some nits about the suggested appearance, but as requested, that's not the focus. --Izno (talk) 15:35, 18 March 2021 (UTC)
• Support, broadly speaking, making it more readable. It's currently just acronyms no one knows with numbers that mean nothing. I exaggerate, but if a general reader would want more encyclopedic "structured" information, these should be easy to identify for them. I get that the acronyms link to the articles about the authorities, but this seems a secondary goal to achieve. —  HELLKNOWZ   ▎TALK 17:00, 18 March 2021 (UTC)
• Support, to make the display more human-friendly. There is room for more improvement but the suggested display is vastly superior to the current example above. Schazjmd (talk) 17:02, 18 March 2021 (UTC)
• Support the general idea of making the template more accessible to readers. Breaking it into categories is a good step. I'm less sure about removing the identifiers and linked acronyms: the former is useful if a reader wants to copy and paste it, the latter for understanding what they actually are. But those are details that can be worked out incrementally. I also agree with the sentiment below that, now Wikidata is a mature project, this template (which is a few years older) is now largely redundant. It might be an idea to go further and suppress links to authorities that don't provide any useful extra information, essentially turning the template into an automated component of the external links section. – Joe (talk) 17:12, 18 March 2021 (UTC)
• Support of course, a no-brainer. Maybe add a TfD tag so more people see this discussion? Elli (talk | contribs) 17:15, 18 March 2021 (UTC)
  • TfD isn't a forum for RFCs. I'm listing it at WP:CENT. 力 (power~enwiki, π, ν) 17:18, 18 March 2021 (UTC)
    • I'm not suggesting to list it at TfD per se, but since the template is under discussion indicating that in the template would be helpful, and TfD has been used for this before (for example, for whether we should collapse ((WikiProject banner shell)). Elli (talk | contribs) 18:06, 18 March 2021 (UTC)
      • I don't think advertising this RFC on 1 million articles is needed. I don't think the ‹See TfM› showing up with every ((tl)) is needed either ... 力 (power~enwiki, π, ν) 18:09, 18 March 2021 (UTC)
• Support in a very general sense, as I believe there's room for improvement of the template. I'm hesitant about some of the specific changes proposed, though. Converting to just external links without wikilinks or numbers looks great for an item like the example above with tons of identifiers, but might not for items with fewer identifiers. Adding sections makes the template longer and more likely to be confused with a navbox. ((u|Sdkb)) ^talk 17:37, 18 March 2021 (UTC)
• Oppose While the the template could definitely be made better looking, I don't trust Fram to do it. This RfC was started without any previous discussion that I've seen at Template talk:Authority control, which would have been the logical venue. Fram has nominated the template for deletion, campaigned for removal of properties from it (e.g., Musicbrainz), and most recently created ((ACArt)) to systematically remove content from it (it is currently up for deletion). They are generally hostile to Wikidata, and seek to reduce the use of Wikidata here. It feels like this RfC is a trojan horse to continue doing that. Thanks. Mike Peel (talk) 17:40, 18 March 2021 (UTC)

  That isn't a valid oppose reason. The proposal doesn't say who will implement it, and presumably the implementation itself will be subject to further discussions and/or scrutiny (+ AGF etc). The idea behind the proposal is sound (as you've said), which is the matter of discussion here. Fram left a link to this RfC at that template talk when the RfC was written (a local consensus cannot override community sentiment on this template, which is present on 1.75 million articles). ProcrastinatingReader (talk) 17:53, 18 March 2021 (UTC)

  If Fram's not going to implement it, then they should have found someone that would before starting the discussion here (like discussing it on the template talk page, not just posting a link to this discussion). I said that it can be made better looking, which is generally true of most templates, but not necessarily like this (some extra whitespace would make reading it easier). Thanks. Mike Peel (talk) 17:59, 18 March 2021 (UTC)

  It doesn't look like a particularly difficult LUA change. 力 (power~enwiki, π, ν) 18:06, 18 March 2021 (UTC)

  This opposition is unfounded. I too disagreed with Fram's decision to create and add AC art without seeking a community consensus (and as such, supported deletion at TFD) but this proposal a clear backtracking of Fram to go through the system properly; seeking community consensus for what is (demonstrably—by the amount of support) a reasonable suggestion. Its also worth noting reminding everyone that this proposal does not change the amount of links being shown, which was the cause for dispute at the AC art TFD in the first place. I would urge Mike to AGF. Aza24 (talk) 08:31, 19 March 2021 (UTC)

  @Aza24: I have interacted with Fram on numerous times about Wikidata-related issues. Assuming good faith with them has long been worn out, I stand by my opposition here. They are not the right person to do this. Thanks. Mike Peel (talk) 09:31, 19 March 2021 (UTC)

  Dude I hope you never propose an RFC. Levivich ^harass/_hound 17:22, 20 March 2021 (UTC)

  @Levivich: I propose them regularly, but I do the background work first (including discussion with at least some people) so that it can be implemented if passed. Thanks. Mike Peel (talk) 20:17, 20 March 2021 (UTC)

• Support, broadly, improving the template, though I'm not sure exactly what this would look like, I trust our technically minded editors. I somehow doubt that Fram is trying to secretly attack wikidata or something by proposing this at a highly visible page, certainly much more visible than the authority control talk itself. Eddie891 ^Talk _Work 17:58, 18 March 2021 (UTC)
• (edit conflict) Strong support These are inscrutable to readers -- you know, the people Wikipedia is supposed to serve -- in their current state. Honestly, I don't expect them to turn into the most earth-shatteringly popular part of the project after this either, but they'd be a lot better than "actively useless". Vaticidalprophet 18:00, 18 March 2021 (UTC)
• Support There may be users who need the ID numbers, but this is a definite improvement. SportingFlyer T·C 18:51, 18 March 2021 (UTC)
• Support Don't need wikilinks to the IDs for every instance of the template. That is what the general help link is for. Likewise the new version is more descriptive as to what the IDs are, and doesn't look like a binary dump of abstracted codes. -- GreenC 20:49, 18 March 2021 (UTC)
• Support anything that makes this business easier for readers to understand, or else why are we even doing it? Beeblebrox (talk) 23:54, 18 March 2021 (UTC)
• Support Common sense proposal, it's far easier to understand than the existing method. ThePlatypusofDoom (talk) 01:20, 19 March 2021 (UTC)
• Support Removing the link to the identifiers Wikipedia article is a tradeoff that I'm more than willing to make in order to get a more understandable template where you don't need to know obscure acronyms and look at meaningless IDs when using. Clear improvement for readers. --Trialpears (talk) 10:14, 19 March 2021 (UTC)

• Unsure - I think I support the basic question at the top -- that it could be more user friendly -- but regarding the actual example I'm not so sure... and that makes me unsure whether there is a straightforward way to make it more user friendly without significantly increasing the amount of space it takes up.
  For example, while the section for libraries seems helpful, why is a direct link to "SUDOC (France)" more helpful to a reader than wikilinking what that even is before linking to the identifier? I agree that displaying the identifiers themselves probably doesn't add all that much value, but it does seem valuable to have both a wikilink and an external link (in which case, why not link the identifier rather than something arbitrary like "external" or "link"). — Rhododendrites ^talk \\ 14:54, 19 March 2021 (UTC)
  • The SUDOC identifier is used on 235000 pages, but Sudoc only gets 12 pageviews a day (unclear how many of those through the current authority control template, and how many in another way). The proposed version (which can be improved upon, and the "other" section may be one opportunity for this) immediately indicates to our readers where the info comes from: perhaps it would be better to indicate in which language the linked page is instead, but the basics are the same: if you are interested in Norwegian authority control for Ôe, by all means click on Bibsys: but you don't need to visit our Bibsys page first to be aware of this. Fram (talk) 15:08, 19 March 2021 (UTC)
    • But this doesn't explain why a direct link which just adds "France" (or even "French") is more user friendly than wikilinking to what that resource is in addition to the direct link. It seems like removing the wikilinks is a major part of this proposal. What I'm worried about is that the wikilinks seem quite useful, and that retaining them and breaking the template into sections and/or spelling out what they are may increase the amount of space it takes up to a degree some find unacceptable. Here's another idea (one which I'm not entirely convinced of myself, but while we're spitballing a bit...): have a section for the non-English sources and collapse it by default? We obviously cover topics from outside the English-speaking world, so retaining them would be important, but it's true that the vast majority of users of the English Wikipedia would not be looking for non-English resources. — Rhododendrites ^talk \\ 15:22, 19 March 2021 (UTC)
• Support per proposal. ~ ToBeFree (talk) 13:53, 20 March 2021 (UTC)
• Support change so long as implementation is thoroughly discussed. ɱ (talk) 14:04, 20 March 2021 (UTC)
• Mixed - my first choice would be to shift the entire Authority Control process over to Wikidata (so all we would have here on WP would be a small unobtrusive box pointing editors to WD.)... however, if we are going to have Authority control links here on WP articles, I agree with Fram that we need to make them clearer for the average reader to understand. Unexplained abbreviations and ID strings are not helpful. So a more expansive template gets my hesitant support. Blueboar (talk) 16:34, 20 March 2021 (UTC)
• Alternative proposal, like User:Blueboar, I'd prefer if Wikidata handled this directly, with Authority Control being a default template, instead of something people manually add. That said, with the current template, I'd keep/use the wiki links, but improve the readability by adding sections (National libraries etc..) and more descriptive names. It would become a fatter template, and that's worth testing. We can measure its effectiveness, by tracking the view count of the Wikilinks before/after. It doesn't need to be useful to everyone, but for the few people it's useful for, experimenting is worth a try! Shushugah (talk) 19:26, 20 March 2021 (UTC)
• Support; removing numbers with no human-readable meaning improves the signal-to-noise ratio. I would also support going further and displaying the links only on Wikidata; pace librarians and archivists, these links are only of interest to such specialists. The links by and large do not help readers, do not meet the standards of usefulness, excessive length, etc. that we would require of external links in any other context, and do not merit blanket inclusion across over a million articles. Adumbrativus (talk) 22:29, 20 March 2021 (UTC)
• Alternative / support-ish: I agree with the general gist of this, including better layout and using more plain English. However, I agree with Blueboar that interfacing more directly with Wikidata would make sense, and with Tom.Reding that the wikilinks are important (they allow the reader to find out what these databases and other sources are and what RS say about them, i.e. why they should care about / trust what they're about to click an external link to.  — SMcCandlish ☏ ¢ 😼  21:11, 21 March 2021 (UTC)
• Support the proposal as written, but ... I am more supportive of scrapping the template altogether per several others below. I am always wary of anything that removes control of what appears in an enwiki article from enwiki editors (acknowledging the less preferred option to manually override the template’s parameters), a simple link to Wikidata would be more appropriate. Cavalryman (talk) 22:17, 21 March 2021 (UTC).
• Support the general principle. A bunch of random numbers and letters won't mean much to most readers, so I think adding context will help. I'm fine with using WikiData as well, as long as we still have the template for readers to easily click to. — Wug·a·po·des​ 22:20, 21 March 2021 (UTC)
• Support a change like this. I think that, from a reader's perspective, the current blob of data looks like something only relevant for computers, something Wikipedia-internal that's not relevant for me. With this change, I think readers would be more likely to click through to the libraries etc. for more information. For the links to our own articles on these systems (all the (identifier) links), I think they should be added to Help:Authority control. That'll only be one click more for interested readers, and they won't clutter up every single article. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)
• Support I was today years old when I actually figured out... vaguely...what authority control is. If it took me years to figure it out, then it's practically meaningless to newbies or readers. Our pages shouldn't have cryptic gobbledegook, it should all be plainly useful to the reader. CaptainEek ^{Edits Ho Cap'n!}⚓ 22:01, 22 March 2021 (UTC)
• Support the concept or making this clearer. If it were collapsed by default, it would take less space and be more removed from the majority of readers who could care less while having the entire title bar to explain what it is to those that could make use of it: MB 03:45, 23 March 2021 (UTC)
• Strong support all proposed changes: the encyclopedia serves readers, not editors or bots. The template is very non-user friendly. If it makes the information twice as accessible then it's worth halving the amount of it. Someone looking for the identifiers can find it from hovering over the URL, visiting the URL or visiting Wikidata. Fram makes a good argument about low pageviews meaning no-one is clicking on these wikilinks for identifiers that are supposedly useful to the reader (from what I can tell this is true as a rule, not just the one example given), so it's not a loss to remove them. Even if all else fails, I hope reorganization into sections by provenance of identifier, rather than the current alphabet soup, will be implemented as I don't think the opposers are opposed to specifically that part of the proposal. — Bilorv (talk) 00:47, 24 March 2021 (UTC)
• Support I sympathize with those that want links the Wikipedia articles on the various databases, but that feature is not worth the inherit confusion that stems from giving readers a large set of unfamiliar acronyms, this is much clearer. Aza24 (talk) 02:06, 24 March 2021 (UTC)
• Support making the template more human-readable. The specifics can be worked out later, but even if the exact proposed template was adopted, I think that would be an improvement. Ajpolino (talk) 21:21, 25 March 2021 (UTC)
• Support anything to make the template more user-friendly, but prefer the suggestions of User:Blueboar and others of a more drastic overhaul and or replacement. TheEmeraldBeyond (talk) 23:04, 26 March 2021 (UTC)
• Support making the template readableto the average reader Asartea ^{Talk | Contribs} 09:01, 28 March 2021 (UTC)

Alternate formatting

Discussion re: Authority control itself

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

It's linked in the template... Help:Authority control. Izno (talk) 15:03, 18 March 2021 (UTC)

A lot of the information on that page is wrong though or severely outdated (compare the concise 5-link authority control template shown for Alexander Graham Bell with the current 27-link bloat). Basically, everything that is described there is done through Wikidata (and if there are outside applications that rely on the template on enwiki directly, they should be rewritten by someone more competent), not through Enwiki, except linking readers to some of the databases listed. Every researcher and application that needs unique IDs should do this through Wikidata, which is the source, and not through enwiki, which is a partial mirror for this information only. Bus this discussion, while necessary, is separate from the RfC. Fram (talk) 15:17, 18 March 2021 (UTC)

I feel like this template only exists so folks can mass-add it to articles. Pretty sure it offers 0 benefit to readers, at least in its current structure which is just an obscure bunch of numbers and abbreviations. ProcrastinatingReader (talk) 15:22, 18 March 2021 (UTC)

For what it's worth, I have found it useful in several cases, especially with regard to reconciling data about BLPs (not as a reliable source, of course). Occasionally I've had dates of births that didn't match across cross-wiki articles and I was able to use the various authority control to figure out what was most likely correct. I've basically treated it as an alternative to WikiData when needing structured information about somebody. The pitfall, of course, is that authority control isn't a reliable source in the same way that WikiData isn't. I would be interested to know what possible use cases it has for actual readers who aren't looking to edit the page it's on. Perryprog (talk) 13:05, 19 March 2021 (UTC)

Agree with those above saying that the template is pretty useless almost anywhere in Wikipedia. Wikidata should do the matching of unique identifiers. Mirroring that in Wikipedia is odd at best (that is, for those understanding what it means); and completely incomprehensible for the majority. I can't support Fram's OP proposal of this RfC (neatly organized redundancy... is still redundancy... it just occupies even more space while I would reduce that space to zero), but I'd gladly support any proposal that would discourage the widespread usage of the template in English Wikipedia. --Francis Schonken (talk) 16:00, 18 March 2021 (UTC)

It’s already been mass-added to every other article. With 1.75 million transclusions, I think the ship has sailed to discourage even more use. If we can’t get it blanked/removed (which I’d support), reforming it to not be useless is the next best thing imo. ProcrastinatingReader (talk) 16:09, 18 March 2021 (UTC)

This isn't really mirroring it, it's displaying it. You could make a similar argument for removal of infoboxes. Elli (talk | contribs) 16:47, 18 March 2021 (UTC)

Most infoboxes don't mirror Wikidata info though, but get their input locally: and more importantly, most infoboxes are self-explanatory, they add on their own understandable info with direct use for many readers (though there as well a significant group doesn't like them). Fram (talk) 17:01, 18 March 2021 (UTC)

The infoboxes getting their input locally is arguable more of a "mirroring" than authority control pulling from Wikidata is. I do generally like your idea for reforming the template. Elli (talk | contribs) 17:03, 18 March 2021 (UTC)

It's useful in the same way that references are. You can find more info in the links, or confirm content in the article. Thanks. Mike Peel (talk) 17:43, 18 March 2021 (UTC)

References verify information written in the article. External links, which do not, are bound by the WP:EL guideline, which states: it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic. No page should be linked from a Wikipedia article unless its inclusion is justifiable according to this guideline and common sense. The burden of providing this justification is on the person who wants to include an external link. Authority control is the exemption to the rule, not the rule. ProcrastinatingReader (talk) 18:24, 18 March 2021 (UTC)

"External links... are bound by the WP:EL guideline" Nope. It's a guideline. Nothing is "bound" by it. Besides, Wikipedia guidelines are supposed to describe, not proscribe, current practice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 19 March 2021 (UTC)

As usual, WP:JUSTAGUIDELINE is the weakest of all possible rationales. How about WP:NOT#LINK? ProcrastinatingReader (talk) 15:52, 19 March 2021 (UTC)

• Thank you for the pointer. Wouldn’t a simple (small) box with a link to Wikidata (perhaps saying: “Wikidata has a page on this subject: see here”) serve the same purpose? Blueboar (talk) 18:05, 18 March 2021 (UTC)

Much like the link to Commons or Wikiquote? Thats sounds like a good idea too. Lugnuts ^{Fire Walk with Me} 08:04, 19 March 2021 (UTC)

Wikidata is not exactly meant to be browsed, and it shows in its design, so directing readers that way is not ideal. It's meant for retrieval, which is what the AC template accomplishes. – Finnusertop (talk ⋅ contribs) 10:35, 19 March 2021 (UTC)

• Beyond doing what's in the name, authority control puts a Wikipedia article about a subject in connection with other resources about the same subject. It basically does what our external links section does. But whereas lots of links in an EL section quickly bloat and take up too much page space, this template packs a ton of resources into a [relatively] small box tucked away at the bottom of a page. While most users probably don't notice it (ditto categories and other elements on the fringes of an article), I've talked to an awful lot of librarians, researchers, archivists, etc. who really value it. (This is a response to this sub-section, not an opinion about the RfC itself). — Rhododendrites ^talk \\ 14:41, 19 March 2021 (UTC)
• Isn't itpart of the idea behind Wikidata that this sort of information woould be moved there? DGG ( talk ) 06:02, 21 March 2021 (UTC)

  @DGG: the data lives on Wikidata, this just makes it visible on Wikipedia. Elli (talk | contribs) 05:36, 22 March 2021 (UTC)

  • There is no question that the data is useful for librarians, etc. The question is: Do we actually need/want that data visible here on WP... or do we want the data to be visible at Wikidata. Blueboar (talk) 13:02, 22 March 2021 (UTC)

there are times when such identifiers are needed to make it clear what the article is actually about, and they can be the best entry point into further information. But they are sometimes inconsistent, sometime erroneous, notably OCLC, and often reflect mere format variations, notably ISBN,. The practice of libraries confronted with this chaos is to record all available identifiers without trying to harmonize them--that's more in the realm of bibliographers. (Though I have sometimes resorted to analyzing them on WP, to elucidate the publication history of a periodical, usually on a talk p, because it is in a sense OR,). I have never tried to work with this on wikidata, as in the past the quality has been so erratic as to be discouraging, but I know the editors there are trying to clean it up as they can). The question then , as was said just above, is what part of this belongs in WP. For journal articles, I think the doi does--it's quite reliable. For books, I usually enter one ISBN, if possible for the print edition which tends to be more stable (unless OCLC record only th electronic version of what is actually a print book also). For identifying individuals, nothing that I know of is reliable. The one source for authors I know and can prove to be totally unreliable is LC after around 1960-70, and OCLC records or international cataloging records derived from LC, for if the information about the identity of the author is not immediately obvious from the title page of the book, they simply copy it from Wikipedia--and they seem to be doing so increasingly. . DGG ( talk ) 20:45, 22 March 2021 (UTC)

Remember WP:SAYWHEREYOUREADIT If you've read it in a book, then use the ISBN printed in the book. Martin of Sheffield (talk) 22:23, 22 March 2021 (UTC)

Authority control in mobile view

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

This is under discussion at the authority control talk page. That said, this is true of all navboxes today, which is a hard problem to solve. Izno (talk) 18:01, 18 March 2021 (UTC)

((Authority control)) is a navbox, and all navboxes are disabled in the mobile view. It's been an outstanding bug for several years; see T124168. – Joe (talk) 18:08, 18 March 2021 (UTC)

Sad that it has been tagged as low priority. That explains why it has been pending for years. I hope they will provide more support for mobile users. AVSmalnad77 ^talk 02:55, 19 March 2021 (UTC)

It is trivial to enable again, but if we did it would look like in this video https://www.youtube.com/watch?v=eaos1s3UfLs. I think that is worse than the status quo and the template would need a significant redesign to solve it. If we had an agreed direction to go in to improve it I guess it would be doable. --Trialpears (talk) 10:10, 19 March 2021 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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

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

Background

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

Guiding principles

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

Proposal

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

Survey (Agatheira)

• Weak support as nominator. I have serious reservations about this due to WP:BROKEN and WP:COSMETIC, but on balance I feel it would be an improvement. ((u|Sdkb)) ^talk 01:00, 1 April 2021 (UTC)
• Support: It should follow MOS; using en dashes for ranges is generally considered correct. Tol | Talk | Contribs (formerly Twassman) 01:06, 1 April 2021 (UTC)
• Question: En-dash? Is that an emoji? Suffusion of Yellow (talk) 01:07, 1 April 2021 (UTC)
• Oppose It's a scientific fact that endash are satanic and cause young children to have diabetus. There also have been multiple unconfirmed reports of spontaneous combustion in mice exposed to endashes, proving clearly that endashes cause cancer. Headbomb {t · c · p · b} 01:28, 1 April 2021 (UTC)

  [21] EEng 02:35, 1 April 2021 (UTC)

• Strong weak oppose malformed context ambiguity. Proposal doesn't discuss ancient Greek contributions to the hyphen. - Floydian ^τ _¢ 01:36, 1 April 2021 (UTC)
• Just be bold and change it, there hasn't been any conflict and this survey serves no purpose. SportingFlyer T·C 01:39, 1 April 2021 (UTC)

• WP:WHACK! Aza24 (talk) 01:41, 1 April 2021 (UTC)

• Support in the strongest possible terms, but only if "BC" is changed to "BCE" in this and all related articles (where the definition of "related" is determined by a new RFC to be started immediately after the closure of this one). This is a hill I will die on, so come at me! – Jonesey95 (talk) 02:05, 1 April 2021 (UTC)
• Opport or Suppose as long as a thin space is included somewhere on the page, or perhaps a hair space, but no minus signs, indifferent on whether the page has hyphen minus, and does anyone actually care about the em dash vs spaced en dash thingie. So confusing. 2A03:F80:32:194:71:227:81:1 (talk) 02:07, 1 April 2021 (UTC)
• Prefer a 3/4 em-dash. –Fredddie™ 02:25, 1 April 2021 (UTC)
• Please follow contemporary reliable sources. What did the historians at the time of Eumenes II prefer? Is there archeological evidence regarding the preferred chisel blade widths? What did the Library of Alexandria style manual specify? isaacl (talk) 02:28, 1 April 2021 (UTC)

• "The length of the striking edge of the chisel so purposed for inscribing endashes shall be the width of a thumb, or 3 grains of sound and well-dried barley laid end to end" - Floydian ^τ _¢ 02:36, 1 April 2021 (UTC)

• Oppose Per the reverse St Leonards-on-Sea principle. Do see my WP:Essay on this. Dear Dash is always in our hearts: 'Profit from his example'. -- Alanscottwalker (talk) 02:44, 1 April 2021 (UTC)
• Oppose - Propose changing MOS:DASH to use hyphen-minus instead. ~ Aseleste (t, e | c, l) 02:56, 1 April 2021 (UTC)

Question: is this a serious RfC or has the ((humor)) template been forgotten? JavaHurricane 04:06, 1 April 2021 (UTC)

@JavaHurricane: the proposal is tagged with ((April Fools)), though the fact that some people are aren't sure is a good sign this is at least somewhat clever. 2A03:F80:32:194:71:227:81:1 (talk) 05:26, 1 April 2021 (UTC)

Either these are not true spies I wear in my head, or I don't see the relevant template anywhere. JavaHurricane 05:49, 1 April 2021 (UTC)

@JavaHurricane: Probably the former as it's right after the signature (ctrl+f may be helpful). 2A03:F80:32:194:71:227:81:1 (talk) 13:55, 1 April 2021 (UTC)

I see it now. It is already a small template; and on mobile it is hard to catch. JavaHurricane 14:20, 1 April 2021 (UTC)

• Counter-proposal: the en-dash is slightly longer than the hyphen and it would therefore seem logical to link its usage to the period of time being described. My proposal is that, for spans of years of fifty and above, the en-dash be used - with the hyphen then reserved for shorter periods. This would give the alert reader a visual clue as to the length of time being described, even if they aren’t so good at mental arithmetic. The only potential flaw I can see with this proposal is that some editors may not cope with there actually being some logic behind WP's policy on dashes. MapReader (talk) 06:17, 1 April 2021 (UTC)

Excellent idea. Could we use a central dot (•) for periods of less than a year. An em dash (—) ought to be used for millennia except for US-related issues when it could be used for centuries due to their shorter history. Martin of Sheffield (talk) 08:40, 1 April 2021 (UTC)

• Comment. Having seen a WP:RFD where an experienced editor said that redirects from variant dashes should be tagged ((R from other spelling)) (to which ((R from other capitalisation)) should by that argument be redirected), I'm not going to comment. Narky Blert (talk) 07:20, 1 April 2021 (UTC)
• This place isn't a TURKISH city at all, it's clearly a GREEK city and the Turks did not even show up there until thousands of years later. Please take care not to inflict symbolic violence on indigenous people. (t · c) buidhe 15:40, 1 April 2021 (UTC)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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^Talk 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 ^harass/_hound 17:22, 6 February 2021 (UTC)
  • All superlatives? What about tallest buildings and longest bridges? Those seem extremely useful succession boxes to me. Thryduulf (talk) 18:24, 6 February 2021 (UTC)
• 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 Wikipedia 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)
• Oppose deciding this specific one here, support a general rethink of succession/navboxes and what they are good for (if anything). Most of the succession boxes at John Major are less trivial, but there are so many of them that they are not a useful way to navigate anything, and are hidden away by default (just like the ungodly amount of navboxes). Once an article has more than three succession boxes, they tend to stop being useful. —Kusma (t·c) 21:50, 1 March 2021 (UTC)
• Yes - A lot of succession boxes seem to be pure trivia. If there isn't an article for the topic it shouldn't exist as a succession box. Nosferattus (talk) 04:05, 9 March 2021 (UTC)
• ? Oppose Confused, how can this RFC decide anything? The RFC is vague and the answers equally ambiguous; everyone saying "Yes" is supporting something different. Who decides which ones are trivial? Aza24 (talk) 23:34, 15 March 2021 (UTC)
• Yes, some succession box material should be eliminated, In the example given, Oldest-living Prime Minister is treated like being an athletic record holder, a recognized and lauded accomplishment as opposed to the simple inconsequential happenstance that it is. You might as well have 'Tallest living Prime Minister'. 'Poorest living Prime Minister', or 'Living Prime Minister with the smallest left testicle'. Agricolae (talk) 19:09, 2 April 2021 (UTC)

Discussion (succession boxes)

• Why? Ivanvector's squirrel (^trees/_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 Wikipedia 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 Wikipedia:Overlink crisis. They are so overwhelming that editors hide them in collapsible templates Abraham Lincoln#External links. In many other cases the amount of them is simply overwhelming...mass link spam John A. Macdonald#External links.--Moxy 🍁 17:59, 6 February 2021 (UTC)

You've explained why you think having too many boxes is an issue, and reiterated your opinion that some boxes are low value (which basically nobody is disagreeing with). However you have not explained why having any boxes is problematic or why their position in the article indicates this. Thryduulf (talk) 20:24, 7 March 2021 (UTC)

As I said in my oppose above, who ever closes this is going to find themselves in an impossible situation. There is no uniformity in any of the "Yes" comments. Additionally what does "certain succession box content" even mean?—who decides which ones are being discussed? Aza24 (talk) 23:08, 24 March 2021 (UTC)