Wikipedia talk:Manual of Style/Infoboxes

Removal of senseless blather

I've removed the following as worse-than-useless noise:

Overall approach

The recommended process for creating an infobox template is simply to begin, and to gather as many requirements as possible. Test the base format for a new template as a static table first, then once consensus is reached, migrate it into template format. The template should be reviewed before being used extensively in articles in case the template or defined parameters need modification to minimize re-work. If new fields and parameters are added, articles must be updated to reflect the new requirements. If parameters are renamed or removed, many articles will likely be unaffected, since extraneous parameters are ignored.

To walk through it:

• "Overall approach" does not actually describe this content.
• "The recommended process for creating an infobox template is ..." isn't true, since this does not describe an actual process, and no consensus concluded to recommend what is in here. Nor does a section that actually did provide a recommended process for creating such a template belong in an MoS page in the first place; that would be a matter for "Help:Infobox".
• "simply to begin": What a silly thing to say.
• "gather as many requirements as possible" is meaningless gibberish. What would be a "requirement" and how would we "gather" it? Even if that had a clear meaning, when would it not be "possible"?
• "Test the base format for a new template" has no clear meaning and sounds like pseudo-jargon out of Tron.
• "as a static table first": No one develops templates this way, and trying do it would largely be counter-productive, especially given how the underlying meta-template code for infoboxes works today.
• "then once consensus is reached, migrate it into template format": More of the same. No one has to establish a consensus before using template code to code a template.
• "The template should be reviewed before being used extensively in articles in case the template or defined parameters need modification to minimize re-work": This really doesn't parse well due to missing punctuation and some other syntax issues. But really this is just "use preview and sandbox" advice that pertains to all template development, and has nothing to do with MoS, including MOS:INFOBOX. It's just poorly reiterated basics from Help:Template.
• "If new fields and parameters are added, articles must be updated to reflect the new requirements." That's patently false. The infobox as deployed in a article would continue to work perfectly well; it simply wouldn't have additional parameters (and "fields and parameters" is redundant). Articles only "must" be updated if an existing parameter has been invalidated in a way that makes the template break, and this is something we don't do. The old parameter name is retained as a parameter alias, or a "retired" parameter (like |ethnicity= in {{Infobox person}}) is simply made to no longer produce any output at all.
• "If parameters are renamed or removed, many articles will likely be unaffected, since extraneous parameters are ignored." This, too, is factually wrong. If a parameter was literally renamed (i.e. changed from one string to another, without the old one being retained as an operational alias), then while the original would become an "extraneous parameter" that was ignored, that would of course affect the article, by removing previously displayed information from the infobox. Again, we don't do this; we create aliases for old parameter names to the new ones so this does not happen. If a parameter is completely removed, the same thing will happen (by intent), but will still be affecting the article.

Literally not one single piece of that mess has any business being in this guideline.  — SMcCandlish ☏ ¢ 😼  15:54, 7 January 2024 (UTC)

Thank you, the guideline is better without it. Presumably that was useful guidance long ago (it was in the guideline 15 years ago, I stopped looking after that), but it has far outlived its usefulness. Ajpolino (talk) 23:10, 7 January 2024 (UTC)

Agreed. I support the deletion, as the language was not helpful and, as SMcCandish pointed out, confusing nonsense. -- Ssilvers (talk) 04:14, 8 January 2024 (UTC)

MOS:COLLAPSE

There's a discussion in place at the main MOS talk page about whether or not MOS:COLLAPSE supports the use of collapsed infoboxes of the type seen at Montacute House and Little Moreton Hall. Feel free to comment if this is of interest to you. A.D.Hope (talk) 11:42, 16 February 2024 (UTC)

City related articles infoboxes

Hi, I have found inconsistencies between the cities across the globe on Wikipedia relating to the images format on the infobox. Refer to the articles New York City, London, Liverpool and Chicago vs Newcastle upon Tyne, Prayagraj and Hyderabad. Which is the accepted image format? Is there a particular norm or rule dictating the format of the images to be placed in? My recent edit on Hyderabad got [1] reverted saying that it is not accepted format. What is the accepted format? Since I find lot of cities in the united states and many cities in India itself like New Delhi and Mumbai have a different format. Also refer to the talk page:[2] 456legendtalk 00:58, 2 March 2024 (UTC)

Please participate in this discussion to come to a common interpretation about the infobox image format for the city related articles. It would be of a great help. 456legendtalk 01:06, 2 March 2024 (UTC)

Alternative 1	Alternative 2
Hyderabad Metropolis Clockwise from top: Charminar during Ramzan night bazaar, Qutb Shahi tombs, Buddha Statue at Hussain Sagar, Falaknuma Palace, skyline at Gachibowli and Birla Mandir.	Hyderabad Metropolis Charminar during the Ramzan night bazaar Birla Mandir Qutb Shahi tombs Skyline at Gachibowli Buddha Statue at Hussain Sagar Falaknuma Palace

Please kindly put in your views and opinions 456legendtalk 15:48, 6 March 2024 (UTC)

This issue was previously considered at this (incredibly annoying to link to because someone had the bright idea to put brackets in a section heading) discussion: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_203#Putting_captions_in_{{multiple_image}}_galleries_in_infobox. There wasn't any formal consensus, but the status quo had previously been to have one caption at the bottom, and that discussion didn't exactly find agreement to move away from that. The main issue is space, which is at a huge premium in city infoboxes given how crowded they already are. Your alternatives aren't the same size, but you can still see how much more room alternative 2 takes up. Sdkb ^talk 03:55, 8 March 2024 (UTC)

@Sdkb I'm sorry I didn't see your comment earlier. That said, shouldn't we actually reach a consensus for the purpose of maintaining consistency? 456legendtalk 04:36, 12 March 2024 (UTC)

Consistency is good where it helps us enforce best practices and reduce the maintenance burden in situations with functionally identical circumstances. In this case, there's possibly a best practice (in my view alternative 1), but not a big maintenance burden from inconsistency (the biggest part of it is the confusion/uncertainty it creates over which format to use), nor functionally identical circumstances (e.g. some cities have much more recognizable landmarks in their galleries and therefore need the captions to be nearby less). Sdkb ^talk 04:53, 12 March 2024 (UTC)

Thank you for highlighting these aspects. Also considering the points raised by the user Huggums537 in the archived discussion, it seems reasonable to conclude that flexibility should be allowed for editors, as hinted in your statement to necessarily help address the varying circumstances and potential confusion, ensuring a more practical and adaptable approach. (Since your example does makes sense and is practical in nature) 456legendtalk 05:35, 12 March 2024 (UTC)

I prefer Alternative 1 for several reasons. Firstly, it occupies less space, which is advantageous. Additionally, it presents a cleaner appearance overall. In terms of viewing information, it's essential that info boxes remain as compact as possible while still conveying all necessary details. Therefore, opting for Alternative 1 aligns with this principle. RWILD✉ 13:29, 1 May 2024 (UTC)

|

Hyderabad
Metropolis
Charminar during the Ramzan night bazaar

• WP:COLLAGE tels us: Collages and montages are single images that illustrate multiple closely related concepts, where overlapping or similar careful placement of component images is necessary to illustrate a point in an encyclopedic way [emphasis added]. I would say that these types of collages are more decorative and do not rise to the standard of being necessary. A good single representative image readily associated with the subject (see MOS:LEADIMAGE) is way better than multiple images particularly if they are small (placed abreast) and/or there is insufficient contrast between them. Too much eye-candy can be a distraction and not a benefit. Furthermore, WP:INFOBOXPURPOSE tells us that an economical infobox is more effective and large infoboxes can have accessibility issues. The article would state that the Charminar has become an icon of the city. On that basis, that image in the infobox would qualify as a good single representative image. Cinderella157 (talk) 00:30, 2 May 2024 (UTC)

  I feel like an entire city needs a few different pictures to be represented. ꧁Zanahary꧂ 06:39, 3 July 2024 (UTC)

• I admit to finding this discussion not entirely necessary. While I'm personally inclined to the concision and space economy of "alternative 1", "alternative 2" isn't misrepresenting or disinforming our readers. Coming up with something formal for the sake of consistency on a matter of comparatively minor variation falls pretty low in terms of my sense of what really needs a more formal, wiki-wide, enforced consensus/rule. I'm just not sure what we have to gain from consistency for its own sake. Hydrangeans (she/her | talk | edits) 00:41, 2 May 2024 (UTC)
• Alternative 1 does not in fact present in clockwise order on mobile resolutions (which is >60% of our viewership). Perhaps something to consider. :) Izno (talk) 02:48, 2 May 2024 (UTC)

MOS:FORCELINK

James Earl Jones
Jones in 2013
Born	(1931-01-17) January 17, 1931 Arkabutla, Mississippi, U.S.
Alma mater	University of Michigan (BA)
Occupation	Actor
Years active	1953–present
Works	Full list
Spouses	Julienne Marie ​ ​ (m. 1968; div. 1972)​ Cecilia Hart ​ ​ (m. 1982; died 2016)​
Children	1
Father	Robert Earl Jones
Awards	Full list

Does MOS:FORCELINK prohibit linking to notable works from an infobox[[3]]? I'd like to get this clarified. That seems to be a extremely liberal interpretation, but if true, there's a lot of biography articles that link lists of awards/works that would need to have those links removed. Thanks! Nemov (talk) 03:56, 3 March 2024 (UTC)

No; MOS:FORCELINK applies to links in text, not links included outside of text to aid readers in finding additional articles on the topic: Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links.

Per that interpretation of FORCELINK, we wouldn't be allowed to use templates like Template:Antonio_Vivaldi or have "See also" lists at the bottom of articles. BilledMammal (talk) 04:00, 3 March 2024 (UTC)

Correct: it shouldn't be used in IBs. Look at why we have FORCELINK. - SchroCat (talk) 15:46, 5 March 2024 (UTC)

Until you find a consensus for your interpretation of FORCELINK, you really shouldn't be changing articles with that justification.[4] Nemov (talk) 15:58, 5 March 2024 (UTC)

It's not my interpretation. It's following what the guideline says. Just because IB warriors are trying to expand it's use outside the reasons we have the guideline in the first place, you are the one that should curtail the breaches. - SchroCat (talk) 16:00, 5 March 2024 (UTC)

I would also ask you to remain civil. Cleary your interpretation differs from other editors and you're not the sole arbiter of "what a guideline says." That is why it's wise to find consensus before making changes. Linking to works has been used on biographies for some time, on this article it was the status quo before you introduced this reasoning for the change. That is why I asked the question here. Nemov (talk) 16:06, 5 March 2024 (UTC)

There is nothing uncivil in what I have said, so please don't try and play games. Read the guideline in full and you may understand both why we have the guideline and also note that it doesn't give any exemptions for things like IBs. Unwatching now. - SchroCat (talk) 16:13, 5 March 2024 (UTC)

• As an example, please see review this infobox for James Earl Jones as an example. It includes inks to works and to awards. Nemov (talk) 19:50, 5 March 2024 (UTC)

  For Jones, "Works" linking to James Earl Jones on screen and stage and "Awards" linking to List of awards and nominations received by James Earl Jones is violating the spirit of MOS:INFOBOXPURPOSE:

  Avoid links to sections within the article; the table of contents provides that function

  Whereas previously editors might have linked in-page to James Earl Jones § Filmography or James Earl Jones § Awards and honors, the links are now off the page. However, a link is not a summary of key facts nor are they curated highlights. More from INFOBOXPURPOSE:

  When considering any aspect of infobox design, keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article.

  —Bagumba (talk) 22:17, 5 March 2024 (UTC)

Infobox purpose should be a different discussion. For Jones, I'd suggest to say List of performances on screen and stage, while "List of awards" should already be clear enough. I believe that a complete list is more neutral about his achievements than a hand-picked selection would be. I therefore embrace the link to a list, a concept that was already part of {{infobox classical composer}}, drafted in 2008 and moved to mainspace in March 2010. --Gerda Arendt (talk) 08:07, 6 March 2024 (UTC)

Infobox purpose should be a different discussion: Disagree. Since we are talking about an infobox, INFOBOXPURPOSE is quite relevant, especially if some are interpretating that NOFORCELINK doesn't apply to infoboxes.—Bagumba (talk) 16:42, 6 March 2024 (UTC)

We should resolve FORCELINK first since that's the topic. We can discuss INFOBOXPURPOSE next if others wish to get clarification on the spirit of INFOBOXPURPOSE. Nemov (talk) 16:56, 6 March 2024 (UTC)

(ec) I don't get it, Bagumba, sorry. The question raised is: may a link from an infobox about a composer to the works by the same be reverted citing FORCELINK, and the answer that I read (BilledMammal, Lee Vilenski) is "no", because the guideline is meant for prose only. The question if the link may be reverted citing something else is a different question which should not be confused with it. --Gerda Arendt (talk) 16:58, 6 March 2024 (UTC)

I guess I'm thinking too WP:NOTBURO. The question to me is just simply: "Does the link belong?"—Bagumba (talk) 17:30, 6 March 2024 (UTC)

NOFORCELINK applies to prose, not tables, infoboxes and the like. Lee Vilenski ^{(talk • contribs)} 22:19, 5 March 2024 (UTC)

When I visit an author's or performer's article, I often look for a list of their works. Instead of skimming the article and look for a {{Main}} or {{further}} link, I'd much prefer having such links in the infobox. That does not mean these links should be omitted from the article's body. -- Michael Bednarek (talk) 23:50, 5 March 2024 (UTC)

At least two editors (see Vivaldi, and please comment there to leave the discussion in one place) still question that it doesn't apply to infoboxes. Can it perhaps be said more clearly in the guideline that it applies only to prose? --Gerda Arendt (talk) 08:07, 6 March 2024 (UTC)

How could it effect Infoboxes, it says Use a link when appropriate, but as far as possible do not force a reader to use that link to understand the sentence. The text needs to make sense to readers who cannot follow links. As there is no prose in infoboxes, we can't rewrite the information to be read without requiring. The point of no force link is to stop people from writing complex prose and including a link that explains all the info. Lee Vilenski ^{(talk • contribs)} 15:31, 6 March 2024 (UTC)

Of course it affects IBs. Don’t cherrypick FORCELINK, but read it in full. The guideline specifically refers to those who "may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links". You can't just ignore the inconvenient bit you don't want to deal with. These links fail the purpose of the IB purpose and FORCELINK - SchroCat (talk) 17:41, 6 March 2024 (UTC)

Sure, if there is a suitable way to state the information in an infobox then obviously that's the way to solve it. However, simply having a link to another article in a way that would be very difficult to do in prose (especially in an infobox) isn't a reason to not remove. We have audio and visual items in infoboxes that for various reasons might not also be viewable (with alttext and the like). In this case, the link says "list of works" or equivellent).

More pertinently, is whether or not the link is suitable. In the case of a list of items that would be too large for an infobox, that seems like a suitable solution. This should be, as said above, only to full articles, and not sections. Lee Vilenski ^{(talk • contribs)} 19:53, 6 March 2024 (UTC)

No, it breaches the purpose of an IB (as outlined by the IB guidelines) and FORCELINK. How many guidelines do you want to ignore? An IB appears at the top of the page, in an overly prominent position and - by virtue of its position - carries a lot of wp:weight, so needs to be used properly. Being in an IB highlights the fields used above other information in an article, and this field is one that breaks the guidelines. A field like “Works: Full list" tells you what, exactly? All the other fields in an IB provide a factoid. The date of birth field tells you the date the person was born; the place of birth field tells you where they were born. “Works: Full list" tells you zero information about the subject. You can’t ignore the part of the guideline you don’t want to deal with. You want to use this field? Go find a way that supports both machine readers and the printed versions—as clearly outlined in the guidelines—and then re-write the guideline. - SchroCat (talk) 20:06, 6 March 2024 (UTC)

• There's doesn't appear to be much support that FORCELINK prohibits linking to related articles from infoboxes, but I do want to clarify MOS:INFOBOXPURPOSE that was raised by Bagumba. I have opened a discussion below. Nemov (talk)

No one is claiming that you can’t put links into IBs. That’s a straw man. It's also a false claim that FORCELINK doesn't apply. No-one has come up with a way that "Works: Full list" makes any sense to machine readers or on the printed page. Again, if you want to use this field, then go find a way that supports offline readers, republishers and the printed versions—as clearly outlined in the guidelines—and then re-write the guideline; alternatively acknowledge we don't care enough about the offline readers, republishers or printed page readers and amend the guideline regardless of them, but as it stands, the practice of some is to ignore the guidelines and do what they want. - SchroCat (talk) 22:13, 7 March 2024 (UTC)

I've only skimread this discussion but if the issue is that "full link" is misleading for some users, then why not just replace it with "See list at [[other article]]" or "See list in [[#Section]] section"? Thryduulf (talk) 13:59, 8 March 2024 (UTC)

MOS:INFOBOXPURPOSE and links to related articles

Ludwig van Beethoven
Beethoven (1820)
Born	Bonn
Baptised	17 December 1770
Died	26 March 1827(1827-03-26) (aged 56) Vienna
Occupations	Composer pianist
Works	List of compositions
Parent(s)	Johann van Beethoven Maria Magdalena Keverich
Signature

In the discussion above regarding FORCELINK, MOS:INFOBOXPURPOSE was raised.

When considering any aspect of infobox design, keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article. (That is, an article should remain complete with its summary infobox ignored, with exceptions noted below.) The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. Of necessity, some infoboxes contain more than just a few fields; however, wherever possible, present information in short form, and exclude any unnecessary content. Avoid links to sections within the article; the table of contents provides that function.

Does MOS:INFOBOXPURPOSE prohibit biography article infoboxes from linking to list of awards/works? Below are examples of some articles that include infobox links to related articles.

• Rod Steiger
• Ludwig van Beethoven
• Barack Obama
• Wolfgang Amadeus Mozart
• Daniel Day-Lewis

Clarification on this issue will be helpful since it affects a lot of articles. Thanks! Nemov (talk) 21:14, 7 March 2024 (UTC)

Yes

• It breaches INFOBOXPURPOSE (and FORCELINK). The entry “Works: Full list" does not "allow readers to identify key facts at a glance". The key facts are only available by clicking onto a different page, which goes against the purpose and spirit of what an IB is supposed to be and do. - SchroCat (talk) 22:48, 7 March 2024 (UTC)
• Per above. It also doesn't make a lot of sense to argue that [[List of works|List of works]] is okay when [[#Works|List of works]] is not, per Bagumba. Nikkimaria (talk) 01:32, 8 March 2024 (UTC)
• Per above. Please keep infoboxes concise and include only key facts. -- Ssilvers (talk) 01:40, 8 March 2024 (UTC)
• For the Beethoven example, Ludwig van Beethoven § Music details his music career, and includes a link there to the comprehensive list. MOS:INFOBOXPURPOSE reads:

  Avoid links to sections within the article; the table of contents provides that function

  It seems to violate the spirit of that guidance to link directly outside the page, when we don't link to the related section that's on the page (and in the TOC). It's more elegant for the reader to stay on the page, reading higher-level content first and being offered more detailed off-page links from the body.—Bagumba (talk) 04:25, 8 March 2024 (UTC)
• Per Nikkimaria above. Ajpolino (talk) 17:01, 13 March 2024 (UTC)

No

• Linking to a related article that includes a full awards/works is not prohibited by MOS:INFOBOXPURPOSE. I don't object to how it's used at Barack Obama as well. However, these links should not be used for content that's included in the article. Avoid links to sections within the article; the table of contents provides that function. Setting aside the policy argument, the reason these links have existed in many different articles is because they're useful. Making information more difficult to find for end users is something we should avoid. Thanks! - Nemov (talk) 21:28, 7 March 2024 (UTC)
• No. We have the ability to set our own guidance here, so I'm a lot less persuaded by arguments about what the guideline says/doesn't say than arguments about what it ought to say. We discussed this issue not too long ago at this thread, which I don't think others have linked yet but which I'd recommend participants read. Quoting myself from there:

  I've always found links to lists in infoboxes slightly odd, but they're highly relevant to the subject, and reader data shows that having them is important for helping readers discover the list. The only alternative seems to be leaving them out, which doesn't feel optimal.

  Sdkb ^talk 03:29, 8 March 2024 (UTC)
• As I wrote above, such links to articles listing works/awards save readers interested in those skimming the article looking for a {{Main}} or {{Further}} link. Bagumba's suggestion below to allow for sidebar functionality strikes me as sensible. -- Michael Bednarek (talk) 04:52, 8 March 2024 (UTC)

  To be clear, I haven't said it should be allowed. I only stated that sidebar functionality seems to effectively be what some are arguing for. —Bagumba (talk) 05:50, 8 March 2024 (UTC)

• It shouldn't. These links, whether to sections of the same article or to a sub-article, are very clearly beneficial to readers so they should be allowed, even encouraged in some cases. If this is contrary to the current guideline then the guideline needs to be changed. Thryduulf (talk) 11:08, 8 March 2024 (UTC)
• No - similar to what Nemov said, the policy prohibits links to sections within the article, because there is a table of contents for that. There is no ToC for links to other articles, and though one could argue that the 'See also' section serves that purpose, but should a section at the very bottom of an article contain necessary links for a reader to have access to? I think not. Fully support having links to other articles in infoboxes. MyCatIsAChonk (talk) (not me) (also not me) (still no) 11:52, 8 March 2024 (UTC)
• No. I believe that a list of a composer's compositions is the most neutral and complete summary of their achievements, and a link to it early - in both infobox and lead - should be wanted, saving the reader to scroll to a Music section or the footer navbox. I don't see the wording of the guidelines contrary to presenting such a link in the infobox, - FORCELINK speaks of sentences, so not about infobox data; the reader of a printed version is not forced to follow a link, but can read what the printed version says about the music. Why not offer the link as a convenience to the (estimated) 99% of readers who will be able to click? There is interest see here. --Gerda Arendt (talk) 21:04, 8 March 2024 (UTC)
• No. The key facts of some kinds of subject will invariably include things that may become too large to include directly. It makes no sense to omit them arbitrarily based on their size: Beethoven having more compositions than can fit directly in an infobox does not diminish their importance to a reader. The alternative to a link would be some sort of collapsible or truncation, both of which clearly hinder usability to follow an arbitrary standard. ― novov (t c) 08:54, 9 March 2024 (UTC)
• No, but the links should be made as informative as possible, see this earlier discussion on the topic. "Works: List of compositions", as in the infobox at the top of this discussion, gives more information than something trivial like "Works: Full list", and should hence be preferred. Gawaon (talk) 10:37, 9 March 2024 (UTC)

  The line that was removed (four times) was "List of compositions". If wanted it could be made more precise, such as for Vivaldi: Lists of operas, concertos and other compositions. --Gerda Arendt (talk) 11:19, 9 March 2024 (UTC)

  Well, if it can be made more informative, that's arguably even better. In the earlier discussion, the line arrived at for Rossini was "Works: Thirty-nine operas · Other compositions" (with two different links). I'm a bit sad that there is no infobox in the actual article on Rossini. Gawaon (talk) 11:41, 9 March 2024 (UTC)

• No, and it shouldn't. A composer's list of works is a "key fact," or something many readers will of course be looking for. It helps the reader to either offer a list of the works (if short enough), or a link to a list. We shouldn't try to force the reader to first read "high quality content" before getting to where the reader wants to go. Help the reader by giving them quick links to where they want to go, don't try to control the reader by forcing them on a linear content path, it's paternalistic. Levivich (talk) 08:01, 10 March 2024 (UTC)

  Also there is no TOC on mobile. Taking the Beethoven example, to get to the list of compositions (without using the infobox link), the mobile reader must scroll down several screens (past the infobox, past the entire lead), open up the "music" level 2 heading, and then click on the hatnote link. A link in the infobox would make that much easier. Also the link should go to a subsection of the article if there is not a separate sub article. Put "list of works" link in the same place on every article about a person with a list of works. That's good web design: predictable, easy, standard. Levivich (talk) 20:57, 10 March 2024 (UTC)

• No per Mir Novov. As I wrote last October, It gives a list of [the composer's] works, something the article does not fully cover, because the entire list of his works cannot be handled in the article. It is a different article. It does not attempt to cover the same subject as [the composer article]. The section "works" is best summed up as a link to the longer article of his works. This is, as I showed above, exactly what that line in the infobox is for. 🌺 Cremastra (talk) 14:32, 10 March 2024 (UTC)
• No. When someone has a list article about their creative works, it generally indicates two things: (1) that the creation of those works is a meaningful part of that person's notability, and (2) that they have been prolific enough that it would be impractical to list all of their work in an infobox. Linking directly to "list of works" articles is a compact, stable, and easy-to-find way to get this significant information in front of readers' eyes. By contrast: trying to list everything on (for example) Johnny Cash albums discography in an infobox is obviously unworkable, and mentioning only specific works by name has historically been a breeding ground for cruft and edit-warring. ModernDayTrilobite (talk • contribs) 15:06, 13 March 2024 (UTC)
• No MyCatIsAChonk and Gerda Arendt.  Spy-cicle💥  ^Talk? 20:35, 15 March 2024 (UTC)
• INFOBOXPURPOSE prohibits links to sections, from my reading of it it doesn't mention links to other articles. I would support the continued prohibition of section links. FORCELINK says not to use links if the reader has to use that link to understand the link (or that's my generalised reading of it). I don't see any reader being confused by "Works     List of compositions" (or similar), so I don't see it prohibiting such links to other articles. -- LCU ActivelyDisinterested «@» °∆t° 02:23, 16 March 2024 (UTC)

Neutral

• I'm content with either version. GoodDay (talk) 04:43, 8 March 2024 (UTC)

Comments

This question is so badly formed it’s not worth approaching or voting on. Any information in an article is “related” - that’s why the information is in the IB. This can be taken as being if the (linked) place of birth is allowed, because it’s related. Can I suggest you frame the question properly first? - SchroCat (talk) 22:19, 7 March 2024 (UTC)

I'll need two versions of the same bio infobox, to fully understand what's being asked. GoodDay (talk) 03:50, 8 March 2024 (UTC)

You can review the infobox of James Earl Jones in the above discussion that features a link to his "full works." Each example has a link that goes to a full list of awards/works/etc. The content in these related articles is too big for the main article. Also added example of the Ludwig van Beethoven infobox which features a link to list of his compositions. Nemov (talk) 03:56, 8 March 2024 (UTC)

Perhaps the contention is whether MOS:INFOBOX should be modified to allow WP:SIDEBAR functionality in an infobox. If so, the debate is not on what MOS:INFOBOXPURPOSE currently says, but on what it could be modifed to say.—Bagumba (talk) 04:31, 8 March 2024 (UTC)

What would something like that look like for a biography? Nemov (talk) 04:36, 8 March 2024 (UTC)

MOS:INFOBOXPURPOSE says an ibx should summarize (and not supplant) key facts that appear in the article. However, some want to allow navigation links, like a sidebar would, which does not directly summarize notable achievements to the ibx reader.—Bagumba (talk) 05:46, 8 March 2024 (UTC)

Given this use is against INFOBOXPURPOSE as it’s stands (even the sensible ‘no’ !votes are more about the links being “useful” than about whether they are compliant with the guidelines), then recasting the guideline to bring it in line with the proposed use would be the only way to avoid the breaches such use brings, and to avoid any future misuse of IBs (based on this ‘thin end of the wedge’ misuse like this). Changing the basis of INFOBOXPURPOSE would, I think, need a centrally advertised RfC based on wording that allows this use, but that avoids any other problems. It should not be too onerous to change the wording at PURPOSE to reflect the current use, but it does need to be done properly, rather than just ignored. - SchroCat (talk) 07:03, 8 March 2024 (UTC)

Popping in here because I had a similar discussion at Wikipedia talk:Manual of Style/Linking (see here). It seems that the main argument for the Yes side is that the wording of INFOBOXPURPOSE prevents these kinds of links. Where would an RfC to change the wording of that guideline be started? MyCatIsAChonk (talk) (not me) (also not me) (still no) 11:48, 8 March 2024 (UTC)

Let's see how is discussion plays out. Given how many articles this affects, we would need a pretty clear consensus to say these links violate INFOBOX purpose. Nemov (talk) 13:04, 8 March 2024 (UTC)

It seems that the main argument for the Yes side is that the wording of INFOBOXPURPOSE prevents these kinds of links: But that's exactly how the question was framed (Does MOS:INFOBOXPURPOSE prohibit...). It wasn't an open ended, "is it a good good idea to..." —Bagumba (talk) 13:12, 8 March 2024 (UTC)

Given most of the sensible 'no' !votes that haven't stuck their heads in the sand acknowledge that current practice isn't in line with the wording ("less persuaded by arguments about what the guideline says/doesn't say than arguments about what it ought to say", "If this is contrary to the current guideline then the guideline needs to be changed", etc), these are also more towards supporting a wording change (which needs an RfC), than the current standing is more towards changing the wording. This who are ignoring the problem are just not reading the guideline in full, or ignoring the bits they don't want to acknowledge. It may as well be done properly - it's not like this is a pressing problem that needs sorting immediately. I suspect an RfC supporting the wording change would be well supported, but given it changes what the purpose of the IB is, it's not something that can be done in a half-arsed way by sneaking through something others may want to have input on. - SchroCat (talk) 16:09, 8 March 2024 (UTC)

Preparing for changing MOS:INFOBOX

Considering that four more no votes have been added in the past two days, I believe it's appropriate to prepare for an RfC to changing the wording of some sections in MOS:INFOBOX. To summarize the arguments: links to "lists of works/albums/operas/songs/others" in infoboxes do not violate MOS:INFOBOXPURPOSE because they are not links to sections within the article and are key facts that readers may want access to early in an article. Additionally, these links do not violate MOS:FORCELINK because FORCELINK deals with sentences, and infoboxes are not part of the text.

Here are the proposals I'd put up at the RfC, and please make an alterations or additions or comments you fee' are necessary before the RfC is opened:

• Proposal A: Amend the first paragraph of MOS:INFOBOXPURPOSE with: "Links to other articles are allowed but should be informative: see the section below Links to other articles."
• Proposal B: Create a subsection under "Design principles" titled "Links to other articles" with the following text: "Links to other relevant articles, such as lists of works, may be used, but should be as informative as possible (e.g. "Thirty-nine operas ⋅ Other compositions" is preferable to just "Full list"). Like other infobox parameters, the link must also appear in the body of the article."

-MyCatIsAChonk (talk) (not me) (also not me) (still no) 13:25, 10 March 2024 (UTC)

I'm not sure RFC is even necessary. These links have existed for quite some time with no incident. I brought the issue here since it was a relatively new objection. If there's going to be a change made the onus would be on infobox minimalists to change INFOBOXPURPOSE to expressly prohibit these type of links. However, there appears to be very little support for making this change. - Nemov (talk) 13:41, 10 March 2024 (UTC)

@Nemov, I feel the need to initiate this because of strong pushback from some at Wikipedia:WikiProject Classical music. Just look at Rossini: numerous oppositions to having an infobox there, in spite of our own discussion here. Or look to Cosima Wagner: that discussion got rather unpleasant quickly. There have even been comparisons to Nazis! I feel that changing the policy is the only way to truly standardize IBs across articles, especially for composers. MyCatIsAChonk (talk) (not me) (also not me) (still no) 14:00, 10 March 2024 (UTC)

(ec) Given that the 4 opponents' argument is the current wording of MOS:INFOBOXPURPOSE, I agree that a wider discussion might be needed. -- Michael Bednarek (talk) 14:04, 10 March 2024 (UTC)

I agree such an RFC may be needed (as the one who IIRC came up with the "thirty-nine operas" piping, I'd support B), but please let's not make this about whether we should have infoboxes at all, or the opportunity for a small improvement will be lost in division over that larger issue and we'll have WP:ARBINFOBOX and WP:ARBINFOBOX2 looming over us as well. NebY (talk) 15:54, 10 March 2024 (UTC)

If a person did not already have a standalone list of works, but had an elaborate list embedded on their bio, it also seems inconsistent why we would allow a link to another page, but not a link to similar content on the same page. So to me, the question is whether a link to any list, either internal or external to the bio, is suitable.—Bagumba (talk) 14:51, 10 March 2024 (UTC)

I agree with Bagumba. If the list is too complicated and/or extensive to summarise in an infobox there should be a link to it from the infobox, regardless of whether it's a section on the same article or a separate article. It's equally valuable to readers in both places. Thryduulf (talk) 14:57, 10 March 2024 (UTC)

If the list is too complicated and/or extensive to summarise in an infobox...: That's where I'm not convinced yet that a link is needed. Invariably, a decent lead already has select works mentioned, by no means an exhaustive list. If an editorial decision can be made on what works to highlight in the lead's prose, why is it not similarly possible to determine what works to highlight in an infobox, providing readers the quick overview of key fact that is an infobox's purpose? —Bagumba (talk) 15:11, 10 March 2024 (UTC)

@Bagumba, the difficulty with putting famous works (like in Pablo Picasso's article) in the infobox is that it a) creates great clutter in the box (just see how long Picasso's is) and b) does not work for famous things with common titles. On the topic of point b, take for example Beethoven: some of his most famous works are the Symphony No. 5 and No. 9, the Piano Concerto No. 5, many of his late string quartets, his opera Fidelio, many many piano sonatas (including the very famous Moonlight), Fur Elise, etc etc. My point is that listing works does not always work, and it especially doesn't work for composers. This is why many discussion related to this result from composer articles: listing works does not work for such monumental and complex figures. MyCatIsAChonk (talk) (not me) (also not me) (still no) 23:42, 10 March 2024 (UTC)

listing works does not work for such monumental and complex figures: But a decent article already makes such editorial decisions regarding which works are to be mention in the lead's prose.—Bagumba (talk) 06:38, 12 March 2024 (UTC)

@Bagumba, imagine the leads for the articles on Mahler and Beethoven. If we had a sentence for their best-known works, set up like in the first para of Sergei Prokofiev's lead, they'd look like this:

- Beethoven's works include such widely heard pieces as the Fifth Symphony, Ninth Symphony, and Fifth Piano Concerto.

- Mahler's works include such widely heard pieces as the Fifth Symphony, Ninth Symphony, and Second Symphony.

Of course, this is cherry-picking works without titles, but it makes a good point: both Mahler and Beethoven are best known for their symphonies, most of which are indistinguishable from each other without including a link. And, we know from the FORCELINK discussion above that you can't distuinguish something just by linking it.

That is why we need to use the "Works" parameter in the infobox: providing quick access to a list of works that's much more detailed than the lead provides clarification for the reader without confusing the names of works. But, even then, look at some composer FAs as they stand: Mahler's works aren't even mentioned until para 3 of the lead, and only three are stated; or see Richard Wagner, who's Ring Cycle is the only work mentioned in the lead besides Meistersinger; or even Gustav Holst, which only talks about The Planets and disregards his other work. All three of those composers are FAs, and yet their leads don't mention many of their works. We need infoboxes in these articles to provide better access to the list of compositions, so readers don't have to click around to find something that should be obvious from the start. MyCatIsAChonk (talk) (not me) (also not me) (still no) 10:48, 12 March 2024 (UTC)

As someone pointed out above, isn't that what a table of contents is for? If there is appetite for this, I would encourage a separate question (possibly a separate RfC, running at the same time) that provides new wording that specifically allows this. If a blind eye is turned on smaller points, it will become a bigger problem later, so it may as well be done properly now to get it right. - SchroCat (talk) 18:02, 10 March 2024 (UTC)

isn't that what a table of contents is for why should a reader need to hunt for the TOC and follow a link to what may or may not be an intuitively named section when they could just follow a link right where they are currently looking, especially when that is where the information (or a link to it) is located in other articles and there is no indication that they need to do so? Thryduulf (talk) 18:10, 10 March 2024 (UTC)

Take that line of argument up with Mycatisachonk, who used it to support their ‘no’ vote. Given this is specifically barred by the guidelines, I’m not sure why the reticence to open it up to the community for comment. - SchroCat (talk) 19:37, 10 March 2024 (UTC)

• Those questions seem appropriate for dealing with the PURPOSE point, although once it is opened up, there is a good chance the wider readership may disagree entirely with changing the purpose, so you may want to think about including an Option 3 of not changing the section (and therefore not allowing these links). I suspect it will get very few !votes, but it should be included - to avoid giving a fait accompli if nothing else.
  If you are opening an RfC on this, the cherrypicking of FORCELINK should be addressed to deal with the part of the guideline that specifically refers to not linking to parts that are useless for the time when "The text needs to make sense to readers who cannot follow links. Users may print articles or read offline, and Wikipedia content may be encountered in republished form, often without links": "Works: List of Works" is a breach of the guidelines as they currently stand. Having a second RfC running at the same time as the first would be the most efficient way of also dealing with this conflict - its certainly better than ignoring the problem or pretending there isn't an issue. - SchroCat (talk) 17:57, 10 March 2024 (UTC)

  "Works: List of Works" is a breach of the guidelines this can easily be solved by replacing "List of works" with an informative phrase such as "See List of works by Bach", see the #Compositions section", or similar. This shouldn't require an RFC. Thryduulf (talk) 18:12, 10 March 2024 (UTC)

  Again, I’m not sure why the opposition to opening it up to the community. ”Works: See List of works by Bach" is still a breach of the guidelines as they currently stand. It may as well get wider input and a solid consensus for a change. - SchroCat (talk) 19:37, 10 March 2024 (UTC)

  I'm not opposed to an RFC, I just don't think it's required. Thryduulf (talk) 19:49, 11 March 2024 (UTC)

  @Thryduulf, as I said to Nemov above, I feel the need to initiate this because of strong pushback from some at Wikipedia:WikiProject Classical music. Implementing "See List of works by Bach" is a great idea that I would love to just work, but there is strong opposition to that idea in the WPClassical community. That is mainly why an RfC is needed- to change the guidelines and formally allow this parameter to be used as it's intended. MyCatIsAChonk (talk) (not me) (also not me) (still no) 20:50, 11 March 2024 (UTC)

  I don't object. I would object to Option 3 as worded above. This discussion has settled the main question, INFOBOXPURPUSE doesn't specifically prohibit these links. This RFC would simply present a proposal that gives some guidelines on how to make these links clearer. Nemov (talk) 21:13, 11 March 2024 (UTC)

Next steps

This discussion was promoted at WP:VPP, WT:BIOG, and WT:BLP, so this question has been open for wider community feedback. There's clearly no consensus so far that these links prohibit INFOBOXPURPOSE. These links appear to have support from the community, but perhaps there could be some clarification about their specific use in a future RFC. MyCatIsAChonk, do you want to proceed with that? You could use the village pump to workshop the language if you feel it needs more work. Nemov (talk) 14:19, 15 March 2024 (UTC)

Thank you for spreading the word and ensuring people are aware of the discussion- I've posted a message at the village pump for feedback on the wording of the proposals, since the discussion here has mostly been about the merits of an RfC. MyCatIsAChonk (talk) (not me) (also not me) (still no) 18:15, 15 March 2024 (UTC)

RfC: Change INFOBOXUSE to recommend the use of infoboxes

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

---

Should INFOBOXUSE be changed to recommend infoboxes for particular kinds of articles? — Wug·a·po·des 20:37, 15 March 2024 (UTC)

Proposal

Old text: The use of infoboxes is neither required nor prohibited for any article. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

New text

The use of infoboxes is recommended for articles on specific biological classifications, chemical elements and compounds, events, people, settlements, and similar topics with a narrow and well-defined scope. Broad topics and overview articles like philosophy, time, or Mathematics are usually better served by navigational sidebars like {{philosophy sidebar}}, {{time sidebar}}, or {{math topics sidebar}}. Stubs are usually too short to warrant an infobox, and infoboxes on them often attract edits expanding the infobox rather than expanding the article.

Where infoboxes are used, they should neither be too short nor too long. They should contain basic facts which readers would reasonably be looking for at a glance like date of birth for people or number of protons in an element. Infoboxes should not be used as repositories for any odd bit of information related to the subject because the visual clutter can make it harder for readers to find the most important information quickly. If information is important but too complex to distill into an infobox, consider using a link to a section or dedicated article on the topic. For example, instead of trying to decide which of Mozart's works should be listed in the infobox, the "works" field is a link to List of compositions by Wolfgang Amadeus Mozart.

Previous discussions

RfCs on Infoboxes in the last three years

Article	Date closed	Result	Closer
Fred Sullivan	January 12, 2024	No consensus	S Marshall
Georges Feydeau	November 2, 2023	No consensus	S Marshall
Antonio Vivaldi	January 5, 2024	Consensus	Dantus21
Felix Mendelssohn	August 11, 2023	Consensus	starship.paint
Cole Porter	August 7, 2023	No consensus	Dantus21
Richard Wagner	August 5, 2023	Consensus	Charcoal feather
Colleen Ballinger	May 17, 2023	Consensus	ScottishFinnishRadish
Rod Steiger	March 31, 2023	Consensus	Nemov
Mozart	March 30, 2023	Consensus	Maddy from Celeste
Jenny Lind	February 23, 2023	Consensus	ScottishFinnishRadish
James Joyce	January 25, 2023	Consensus	Ingenuity
Claude Debussy	January 18, 2023	No consensus	Red-tailed hawk
Maddie Ziegler	December 31, 2022	No consensus	Isabelle Belato
Tchaikovsky	January 3, 2023	Consensus	Gusfriend
Laurence Olivier	November 27, 2022	Consensus	Red-tailed hawk
Stanley Kubrick	November 15, 2021	Consensus	Tol
Ian Fleming	March 4, 2021	Consensus	Wugapodes

Previous / Related Centralized RFCs

Squashing this in at the top as reference for closing and/or future discussions, as I had (and probably other uninvolved peeps will have) no clue until, like, reading several comments in. :P Feel free to update. --slakr^\ talk / 20:54, 3 June 2024 (UTC)

• Wikipedia:Village_pump_(policy)/Archive_143#Infobox_RFC (May 2018)
• Wikipedia:Village_pump_(proposals)/Archive_202#RfC_on_establishing_a_biography_infobox_guideline (June 2023)

Discussion

• Support My sense after surveying discussions on infoboxes over the last few years is that our guideline has not kept pace with the actual consensus in practice. For example, you notice that the (hoepfully exhaustive) list of discussions these last few years involves biographies, while articles on chemicals, settlements, and species appear to have an obvious consensus to include them where possible. To drive the point home, 3.1 million articles (nearly 50%) have infoboxes. We should document that consensus. The area of contention seems to be biographies, and particular kinds of biographies at that: subjects who are engaged in theatrical, literary, musical, or visual arts with widespread critical acclaim which makes their subjective achievements difficult to distill into a line in a box. Despite this, editors have routinely found consensus that these articles are better with an infobox than without. We should document that consensus, and hopefully reduce the time the community spends mediating a relatively niche area of controversy.
  The goal of the proposal isn't to require every article have an infobox, in fact, it gives specific recommendations for when an infobox shouldn't be used. The goal is to synthesize the various considerations editors raised across the discussions surveyed to provide accurate guidance for editors and help improve decision-making on true edge-cases. It is not helpful when we have guidance that is years out of date and doesn't provide actual guidance, and keeping it around just to handle a small subset of biography articles is a net negative. Let's incorporate the insights from those debates into the guidance, but as caveats to the consensus from practice that infoboxes are part of our house style. — Wug·a·po·des 20:37, 15 March 2024 (UTC)

  The area of contention seems to be biographies, and particular kinds of biographies at that: subjects who are engaged in theatrical, literary, musical, or visual arts with widespread critical acclaim which makes their subjective achievements difficult to distill into a line in a box

  I think this is a misidentification. The logical area of contention is with any subject that is not easily summed up with key bullet points, of which certain classes of biographies are merely the most prominent.

  To me, it seems like the existence of universal consensus you describe is implicit at best, and that you are overstating its breadth. It feels a bit ambitious to assign this universal intent not only to Wikipedia, but to media at-large.

  Despite this, editors have routinely found consensus that these articles are better with an infobox than without.

  They often do not, or instead the consensus is that an infobox is a fait accompli.

  It is not helpful when we have guidance that is years out of date and doesn't provide actual guidance, and keeping it around just to handle a small subset of biography articles is a net negative.

  It does provide actual guidance, the guidance is that "you should use your head", like many other areas of advice on Wikipedia. If infoboxes are already so widespread as you've pointed out, why on earth do we need to (at the guideline level) mandate their use? No one needs help knowing that articles often have them, it's the first part of many articles that many new users are attracted to editing.

  This seems to me like an argument that "infoboxes are usually-to-always good for articles" cloaked as an argument that "'infoboxes are usually-to-always good' is a universal consensus". We operate based on verification and consensus here, but we also have to make arguments ourselves. There is a significant topic space where there are reasonable arguments that the use of infoboxes therein is not good or necessary. Let's be intellectually honest about that. Remsense诉 21:09, 15 March 2024 (UTC)

  Over 50% of articles have them and I provided two years worth of RfCs to support my position. — Wug·a·po·des 21:12, 15 March 2024 (UTC)

  • Over 50% of articles have any number of aspects and defects. Whether you think that equates explicit normative consensus is what you are adding on top.
  • Your RFCs are about individual articles, and it borders on dishonest to present them as supporting a universalizing position like this.

  Remsense诉 23:12, 15 March 2024 (UTC)

  Half our articles have this feature, and over the last year nearly every RfC we've had has resulted in a consensus to include them, but I'm being dishonest because I think that shows general support for this? Please be serious. — Wug·a·po·des 23:41, 15 March 2024 (UTC)

  The RFCs were about individual articles, they were not answering the question "should every article have an infobox". That is a different question, it is the one we are discussing here. The least you could do is frame this RFC as establishing a categorical consensus, and not merely reflecting an existing one. Remsense诉 23:44, 15 March 2024 (UTC)

  It's not about whether every article should have an infobox. The text literally includes recommendations for when to not use them. Before calling me dishonest or telling me how to frame the proposal, please read the actual proposal and characterize it accurately. — Wug·a·po·des 23:52, 15 March 2024 (UTC)

  Apologies, "most articles, according to certain broad criteria". I suppose I also really have an issue with your criterion of "narrow; well-defined scope". Infoboxes aren't really good for an article based on their scope, right? It's about if there are well-defined properties of the topic itself. A well-defined scope doesn't mean the scope is well-suited to an infobox presentation. Remsense诉 02:04, 16 March 2024 (UTC)

  @Wugapodes. Remsense did not call you dishonest, that is misciting them. They merely asked you to reframe your question. And it's certainly no more uncivil than telling editors to "be serious". ——Serial Number 54129 14:06, 16 March 2024 (UTC)

  I did say their framing "bordered on dishonest", which I accept being met with that characterization. Saying that wasn't necessary to make my point, so I do think I could've said it more amenably. Remsense诉 14:10, 16 March 2024 (UTC)

  • Why have you cherrypicked these specific examples for the table? Why is WP:RFCBEFORE being ignored? And why are we ignoring WP:RFCOPEN with non-neutral opinion in the statement? - SchroCat (talk) 04:23, 16 March 2024 (UTC)
  • I've updated the table to include information from SandyGeorgia's more up-to-date version, although there are probably still gaps. With the missing ones now included (oddly, all ones with no consensus for a box) it paints a slightly different picture than the presumed universal support for boxes in all bios. I removed the entry that wasn't about whether to include a box or not, and took out the notes, which were highly NPOV and misleading in places. Let's try and keep it neutral at the top. - SchroCat (talk) 10:59, 16 March 2024 (UTC)
• Support. The proposed text does a great job of capturing the practice around infobox use and when and why they're useful. Having read some of the discussions about whether to provide infoboxes for people with less easily summarized accomplishments—and having written a couple of articles like that, about a diarist, an actor, and an economist—I do generally find having an infobox is better than not. Infoboxes are readable, they're accessible, and they're in use. This is a good proposed text for the manual of style to create more clarity about the way we use infoboxes, especially for newer editors learning from the manual of style. P-Makoto (she/her) (talk) 20:47, 15 March 2024 (UTC)

• I don't think Broad topics and overview articles like philosophy, time, or Mathematics are usually better served by navigational sidebars like {{philosophy sidebar}}, {{time sidebar}}, or {{math topics sidebar}}. Stubs are usually too short to warrant an infobox, and infoboxes on them often attract edits expanding the infobox rather than expanding the article. is called for at this time. It's offtopic to the section and adds what I think is unnecessary guidance to boot. I'd even say "stubs don't need infoboxes" is categorically wrong based on my gnoming across many thousands of articles for citations, above and beyond offering something unnecessary. I'd also not like to add additional support for sidebars, which while I agree can be used in these places, as they often take up space (as at least one other location in the MOS suggests) that could be used fruitfully for other items floating right. (And I've been coming to the conclusion that sidebars should just be deleted as a category, at least in the main space.)

  Otherwise, I generally applaud this attempt to add support in the MOS for infoboxes. On that point, I even think there are some factors in User:RexxS/Infobox factors (and the talk page) that could be listed in addition to the ones you selected above. Izno (talk) 20:58, 15 March 2024 (UTC)

  I'm open to removing the note on sidebars. The intent wasn't to recommend the use of sidebars but rather contrast the kinds of articles where an infobox wouldn't be useful (because something else does a better job). Perhaps leaving the navigational sidebar bit off would be best? Say Broad topics and overview articles like philosophy, time, or Mathematics are generally not well served by infoboxes? I share the intuition that lots of stubs do have infoboxes, but from the discussions I've read I'm not sure if their use on stubs is something we should necessarily recommend? A big concern that comes up in the discussions linked is that infoboxes attract edits and can dwarf page content in ways that aren't helpful which is magnified on stubs or short pages. So while there are lots of stubs that do have infoboxes, I wonder whether a project-wide discussion would view that practice as something to encourage or not? I'm open to the answer being "no, it's fine, remove that line", but I thought it worth testing the consensus on. I even think there are some factors in User:RexxS/Infobox factors (and the talk page) that could be listed in addition to the ones you selected above Indeed, I think long term there's a lot of guidance in user essays that can be incorporated into project-wide documentation. I wanted to try and synthesize the most recent discussions as a starting point and then from there branch out to more specific guidance that editors in the topic area have developed from experience. — Wug·a·po·des 21:28, 15 March 2024 (UTC)

  I think the general suggestion that these don't usually have an infobox is a fine spot to back off to.

  I'm not sure if their use on stubs is something we should necessarily recommend Yes, but you go further than "we probably shouldn't recommend" into "we recommend against", especially when you include some marginally negligible rationale as to why one might want to avoid infoboxes on such articles. Especially such a specious rationale as "we don't want people editing the short pages with infoboxes!". *points in the general direction of all of Wikipedia, its ethos, and whatnot* :) We will functionally never remove what might be perceived as "nuisance" edits precisely because we assume good faith, and infoboxes are no different in this regard, on any size of page.

  It might be fair to describe the current use of infoboxes in short articles as "these are less likely to have infoboxes", but I don't see that as saying anything beyond "short articles are likely to have a lower quality" which is more or less the state of the wiki. Izno (talk) 23:59, 15 March 2024 (UTC)

• Support - aside from all the reasons given by Wugapodes that I completely agree with, infoboxes are just generally helpful. I will hold my own RfC idea until this is resolved. Also, Wugapodes, you may be interested in the table of musician bios with infoboxes that Gerda Arendt assembled last year: see Wikipedia talk:WikiProject Classical music/Archive 80#10 years. MyCatIsAChonk (talk) (not me) (also not me) (still no) 22:07, 15 March 2024 (UTC)
• Support --Gerda Arendt (talk) 22:14, 15 March 2024 (UTC)
• Are the topics listed above given as examples or more of a definitive list? I've also seen every language abd star have an infobox. Also should maintenance tags be created? {{Missing taxobox}} exists. 115.188.117.112 (talk) 22:20, 15 March 2024 (UTC)

  They're meant as examples, the general guidance being "topics with a narrow and well-defined scope" which I think covers languages and celestial objects as well as roads and other things I can't think of off the top of my head. {{Missing taxobox}} doesn't seem used on any articles, and I think maintenance templates would be more trouble than they're worth. If it's not worth going the extra step to add an infobox, then it's probably not important enough to warrant a maintenance tag. — Wug·a·po·des 22:24, 15 March 2024 (UTC)

  {{Missing taxobox}} does get used on articles; I add it myself on a somewhat regular basis. It's just that there is no backlog of existing articles that need a taxobox and which don't have one, and it's uncommon for a new taxon article to be created without a taxobox (and rare to make it through NPP without a taxobox being added). Articles that do get tagged with missing taxobox are usually resolved in a matter of hours, and at any given time there are usually no articles with a missing taxobox template. But it does get used. Plantdrew (talk) 20:17, 17 March 2024 (UTC)

• Support 🌺 Cremastra (talk) 22:22, 15 March 2024 (UTC)
• Support - This is a reasonable proposal that mirrors the community's position on infoboxes. Thanks for the work putting this together. Nemov (talk) 22:51, 15 March 2024 (UTC)
• Support The current wording is archaic (added in 2011; courtesy ping @WhatamIdoing) and no longer representative of the common practice. Infoboxes are generally beneficial and should be included if there is enough information. InfiniteNexus (talk) 22:52, 15 March 2024 (UTC)

  Thanks for the ping. Wikipedia:Consensus can change, and if it has (which this RFC will determine), then I've no objection whatsoever to that being changed, nor any special insight into what a new version should say. WhatamIdoing (talk) 22:56, 15 March 2024 (UTC)

• Oppose. This would blatantly violate the ArbCom compromise. It also appears that canvassing may be going on here. -- Ssilvers (talk) 23:03, 15 March 2024 (UTC)

  Where is your evidence that canvassing has taken place? InfiniteNexus (talk) 23:19, 15 March 2024 (UTC)

  For transparency, I posted on WP:CENT and WP:VPP, and there's a small discussion on my talk page which has some watchers. Beyond that I'm not aware of anywhere else this has been advertised. — Wug·a·po·des 23:44, 15 March 2024 (UTC)

  Also, Ssilvers could you be more specific about "the ArbCom compromise"? Remedy 6 of Infoboxes (2013) states that "The Arbitration Committee recommends that a well-publicized community discussion be held to address whether to adopt a policy or guideline addressing what factors should weigh in favor of or against including an infobox in a given article." which is largely what this is. There doesn't seem to be anything in that case which prevents the community from creating policy or guidelines regarding infoboxes, quite the opposite. Am I missing something or is there another case you're referencing? — Wug·a·po·des 23:49, 15 March 2024 (UTC)

• Support. I think the use of infoboxes should be regulated so that it is not too long. If the infobox is too long, it could cover almost the entire side of the article, and worse, shift the images that have been placed where they should be. ▪︎ Fazoffic _{( ʖ╎ᓵᔑ∷ᔑ)} 23:07, 15 March 2024 (UTC)
• Oppose per my reply above, as well as the important, basic observation made by Ssilvers. During some extracurricular discussion with Gerda, I happened to mention the fact that I didn't express my actual opinions very clearly here in my initial !vote. My opposition to this RfC has pretty much nothing to do with ArbCom or canvassing, and I've observed literally no foul play from anyone else in this RfC, opinionated as it was. She suggested that I strike this part, and I agree it's a good idea such that my past confusion doesn't beget yours in the future. A slightly clearer outline of my feelings are at the permalink above. Remsense诉 09:32, 7 April 2024 (UTC) The present wording is also reflective of consensus and serves it just fine. It would be nice to have some guidelines for infoboxes regarding length, but that seems to be being smuggled in atop what is an extremely broad universal affecting a majority of articles on the site, a scope as huge as that of any RfC in site history. I reject what amounts to the pork-barreling here, and insist that points should be considered individually for a proposal this ramified. Remsense诉 23:17, 15 March 2024 (UTC)

  I get what you’re saying, but infoboxes are an extremely broad universal by their very nature. And I don’t think the present wording reflects consensus since for some odd reason most articles on the enumerated topics have infoboxes. Must be that wacky infobox cabal adding them I guess, not the ~90% of users who just treat them as standard. Dronebogus (talk) 15:53, 17 March 2024 (UTC)

• Support per Wugaopodes. Infoboxes should be encouraged but not required. Having participated in a few of the mentioned RfCs, I am pleased that other editors feel the same. The proposed MoS wording will reflect both the widespread usage of infoboxes and the dozen individual RfCs leaning on the inclusion. I recall that most of these infobox disputes have arisen from disputes about the content of some parameters (in which cases a compromise could be made to omit those details entirely). SWinxy (talk) 01:25, 16 March 2024 (UTC)
• Oppose Infoboxes are good and should be used. However although 50% of articles may use them, far to many contain nothing but repetition of information in the first sentence of the article. This is a compete waste of space, and adds no value to the article. The date of birth point used in this text is a exact example of this. I would be open to slightly modified text that strengthens the point of not using overly short infoboxes. -- LCU ActivelyDisinterested «@» °∆t° 01:52, 16 March 2024 (UTC)

  This is a good point especially for the many articles which simply can't include verifiable birth, death, and other parameter dates. Not everyone lived in Europe after the 19th century with reliable vital records. People like Gaius Verres or Quintus Tullius Cicero cannot have parameters filled in on an infobox with entering into the realm of fiction. Ifly6 (talk) 23:20, 17 March 2024 (UTC)

• Oppose. Remsense notes some of the issues with the first paragraph, but it also conflates a well-defined article topic with a topic that can be well described by structured data. One size does not fit all in this regard, as was noted in at least two previous RfCs along these lines (1, 2), and many of the concerns raised in those discussions persist with this proposal.
  Paragraph 2 is just a dumpster fire, to be frank. I agree with Remsense's point about considering this separately, and note that this appears to have prompted at least one support (Fazoffic) that doesn't address the broader change of para 1. But on top of that, this proposal contradicts multiple other existing pieces of guidance that it's not proposed to replace, it discards the actually useful guidance from the previous version on resolving disputes, contradicts itself, and privileges inclusion based solely on whether someone believes something is "basic", to the detriment of any other consideration - promoting oversimplification and negatively impacting neutrality. Nikkimaria (talk) 02:12, 16 March 2024 (UTC)
• Support The use of infoboxes is de facto standardised in these categories except a few articles grandfathered in to not use them. Our primary purpose should be to serve readers, and due to these types of articles almost always containing infoboxes, it serves the principle of least astonishment that when a user looks for information in the top right of the article, they will find said information in a (reasonably) consistent manner. I also don't see how them repeating basic facts is measurably harmful; they don't really take up that much space, especially given a picture would most likely be there anyway. ― novov (t c) 02:20, 16 March 2024 (UTC)
• Support, however for stubs which already have infoboxes, it should not be removed without good reasoning (e.g. unreferenced statements, etc.). I consider to keep this to help new editors: If you are in doubt on which infobox to include and which parts of the infobox to use, it is determined through discussion and consensus among the editors at each individual article. RaFaDa20631 (talk) 04:21, 16 March 2024 (UTC)
• Oppose. Not every article within those criteria has sufficient information to form a viable IB. I wonder why the cherrypicked examples in the table (missing articles where there was no consensus, obviously, and Sellers listed despite it already having an IB). - SchroCat (talk) 04:37, 16 March 2024 (UTC)

  @SchroCat, can you provide links to any missing RFCs? It looks like the goal was to list all of the RFCs about infoboxes in the last two years, and I don't believe anyone would object to having an overlooked RFC added to the list. WhatamIdoing (talk) 16:40, 16 March 2024 (UTC)

  I’ve already boldly added three that I know of (all no consensus, which changed the look of the table a lot). I don’t track or follow them (let alone comment in all of them), but there may well be others. - SchroCat (talk) 16:45, 16 March 2024 (UTC)

• Oppose a recommendation of infoboxes for people, not sure about some of the other categories. For many pre-1800 and other non-recent bios, there is not enough definite info to write a useful infobox. Infoboxes also take space and make image placement harder. If infoboxes are included as standard, we should drop the anti-sandwiching rules to allow articles to be illustrated properly. —Kusma (talk) 05:54, 16 March 2024 (UTC)
  • I agree with all you say (although would say pre-1900 bios), but would include recent bios as being problematic too. We don’t have dates or town-/city-level locations of birth for many BLPs, which leaves an IB with a name, nationality and occupation/notability field. This would mean we would just duplicating the first sentence, which isn’t ideal. Also agreeing particularly with Nikkimaria above about the fact the two previous RFCs (one of which was was only nine months ago) rejected the idea because of deep-seated concerns: this proposed measure has those same concerns. - SchroCat (talk) 06:51, 16 March 2024 (UTC)
• Oppose paragraph 2, paragraph 1 needs work The second paragraph falls firmly into WP:CREEP territory and additionally isn't that well formulated, while the first paragraph, although closer to current practice than the current antiquated guideline, needs editing to resolve overly-broad categories (e.g. Kusma's note on pre-1800 biographies). ~~ AirshipJungleman29 (talk) 06:44, 16 March 2024 (UTC)
• Oppose. Present text is more succinct, clear, consistent, and incontestable than the proposed text. DrKay (talk) 07:50, 16 March 2024 (UTC)
• Oppose. Of the millions of articles with infoboxes, almost none have been contested; the reason to change the wording here would be to provide better guidance on articles where there might otherwise be disagreement about the use of infoboxes. It's precisely those cases where there should be discussion, rather than reference to a rule. I write a lot of articles on magazines and an infobox is usually beneficial on those articles, but occasionally it provides no value because almost none of the relevant fields have simple answers. I would not want to see a rule that forces an infobox into articles where all the editors active on the article see it as harmful. And as mentioned above, what about the ARBCOM ruling? Can this RfC overturn that ruling? Regarding the second paragraph of the proposed wording, I think it's well-intentioned but would not be helpful in practice - it provides a list of things that should be considered without a way to settle the question: "they should not be used as repositories for any odd bit of information" -- debating whether a particular bit of information is important or not is the sort of thing that comes up in these debates, and this wording gives no guidance for resolving those questions (nor do I see how it could). Most of the rest of the paragraph has the same problem. Mike Christie (talk - contribs - library) 12:08, 16 March 2024 (UTC)
• I take no position on whether articles should have infoboxes, but I do want to thank Wugapodes for starting this discussion. RfC closers really do need some guidance from the community about how to decide these things, and any progress towards such guidance will be of great help.—S Marshall T/C 12:20, 16 March 2024 (UTC)
  • I would particularly welcome community guidance on two specific matters. Firstly, clearer instructions about what a contested infobox should contain and what it should omit; and secondly what to do when the infobox expects a simple, one- or two-word listing but in this article, there's nuance to resolve. At the moment I would say that where there's no consensus, the right outcome is either to leave the disputed parameter blank, or else to write "see [heading]"? Not sure how to choose which.—S Marshall T/C 12:30, 16 March 2024 (UTC)

    What an infobox should contain or omit is extremely subject specific… what works in one article won’t work in another. There are just too many variables. I don’t think “instruction” is possible. Blueboar (talk) 15:44, 16 March 2024 (UTC)

    The first is impossible to generalize about, except that it should respect WP:INFOBOX and only contain key facts - very many IBs don't do this. The second is easier: if a short wording is potentially misleading, just leave it out. If it's something really key, like date of birth or death, "uncertain" with a link may be needed. Johnbod (talk) 13:40, 23 March 2024 (UTC)

• Oppose. This seems to be a solution looking for a problem. The proposed new text looks like a gift for Wikilawyers. And why the the presumption that "discussion and consensus" will not lead to the best, or at least a reasonable, solution in individual cases? Gog the Mild (talk) 13:55, 16 March 2024 (UTC)
• Oppose per most of the cogent argument above, particularly Nikkimaria—one size not fitting all—and unnecessarily constraining local consensus, which arbcom mandated should be established on a case-by-case basis. Instruction creep is a permanent concern. ——Serial Number 54129 14:13, 16 March 2024 (UTC)
• Oppose this overshoots the mark. Statements like "Stubs are usually too short to warrant an infobox" do not make sense to me; I would argue that all stubs of, e.g., species articles should have infoboxes for consistency (and almost all have them). --Jens Lallensack (talk) 14:31, 16 March 2024 (UTC)

  @Jens Lallensack, a couple of other editors have questioned the sentence about stubs. Would you still oppose it if that sentence were removed? WhatamIdoing (talk) 16:41, 16 March 2024 (UTC)

• Oppose. The proposed text overreaches; I don't think there's really a consensus for many of the details proposed. The current version is correct even if it understates the prevalence of infoboxes, and frankly, I don't see the problem with a handful of well-discussed articles not including infoboxes for no other reason than editors feeling an infobox would not be appropriate in that particular article. —Compassionate727 ^(T·C) 14:51, 16 March 2024 (UTC)
• Oppose - instruction creep. Sometimes it is better to NOT have a rule, and to allow flexibility. Yes, flexibility in “the rules” sometimes results in disagreement (and even heated debate). Thing is, I see that as a GOOD thing. It’s an important part of improving the project.
  Should most articles have an infobox? Probably. Should Article X have one? It depends. Maybe, maybe not. We need to explore the arguments for and against - and that can only be done on a case-by-case basis. Blueboar (talk) 14:55, 16 March 2024 (UTC)

  @Blueboar, are you concerned that the word "recommended" will be misinterpreted as "required in all cases"? WhatamIdoing (talk) 16:44, 16 March 2024 (UTC)

  It's essentially a first-person weasel word, yes. Remsense诉 17:12, 16 March 2024 (UTC)

  A bit… but it’s more that I don’t think we need to say it either way… neither “recommended” nor “discouraged”. Leave it up to editorial judgment. Not everything needs to be spelled out in “the rules”. Blueboar (talk) 19:05, 16 March 2024 (UTC)

  To be specific, I think the use of "recommended" is wrong here. It should say they should be used or an equivalent—this is already a guideline, we generally understand the level of strictness in what that means. If should be used sounds too strong, that's because the guideline is too strong. "Recommended" functions as a hedge, and another qualifier for people to fret about interpreting. Remsense诉 19:11, 16 March 2024 (UTC)

  I use should in the meaning of RFC 2119 when I'm writing policies, but there are editors who believe that should is a more polite way to say must. WhatamIdoing (talk) 20:29, 17 March 2024 (UTC)

• Support. Infobox discussions are a timesink with the same editors rehearsing the same general arguments over and over again. Opposers say that each article should be considered individually, but when you look at the discussions you can see that article-specific arguments are rarely offered and that the regulars always give the same !vote. The fact that there hasn't been a recent consensus against an infobox is telling. Charcoal feather (talk) 15:51, 16 March 2024 (UTC)

  This is survivorship bias, it doesn't consider cases where an article doesn't have an infobox and no one does an RfC to add one. Remsense诉 15:52, 16 March 2024 (UTC)

• Hesitant oppose, in large part per Mike Christie and Nikkimaria. I agree with Wug above that there is a consensus established via editing that some broad classes should have infoboxes by default; biological taxa come to mind, geographical units are another example. I'm not opposed to documenting that consensus, but that's not where the crux of the infobox problem lies. The dispute has historically been about prominent biographies, where this text won't solve anything; and the crux of the matter isn't breadth so much as the applicability of structured data, and, ultimately, aesthetic sensibility. I think we can usefully document some guidance in that respect too, by documenting which kinds of data are well-suited for an infobox and which are not, while remaining agnostic on the general question of whether infoboxes are preferred. I agree with many folks above that the infobox wars are endlessly frustrating, and reading infobox RfCs makes me feel like I'm in Groundhog Day. While I applaud the effort, I don't see how this fixes the issue. Vanamonde93 (talk) 20:36, 16 March 2024 (UTC)
• Oppose - I am hesitant to take the decision to add infoboxes or not out of the hands of experienced editors. Many of these discussions I have seen comprised outside editors who have nearly no history on the pages they are attempting to add an infobox to arguing with editors who have numerous edits. I fail to see a compelling reason to overrule longstanding precedent. Barbarbarty (talk) 17:51, 16 March 2024 (UTC)

  RFCs exist in part to avoid local consensus. The whole point of RFCs is to ask "outside editors" for comments. There's no policy on this topic so this isn't a experienced editor issue. Nemov (talk) 00:25, 17 March 2024 (UTC)

• Oppose - there is a reason why the current position is in place - to stop the conflict and edit warring between people who demand that articles must have infoboxes and those who demand that they shouldn't - these disputes were very damaging and resulting in a painful Arbcom case. We don't want to reopen these wounds again.Nigel Ish (talk) 23:54, 16 March 2024 (UTC)
• Support We need to bring old policies in line with current consensus; I'd rather build a good encyclopedia that effectively stays with the times than one that stays static to protect editors' feelings. JuxtaposedJacob (talk) 00:41, 17 March 2024 (UTC)

  What? Editors' feelings is what consensus is. Remsense诉 02:05, 17 March 2024 (UTC)

  No, “editors feelings” here is exactly that, their irrational emotions. Consensus is an alignment of informed opinions. And yes you could say that the current “consensus” on certain articles meets that definition, but the way I see it the “opinions” here were never really that “informed” to begin with. Dronebogus (talk) 15:43, 17 March 2024 (UTC)

  There's a fundamental flaw in one's model of consensus if it involves sometimes discarding some or most of it in favor of what you individually found to be correct anyway. Remsense诉 20:10, 17 March 2024 (UTC)

• Oppose as drafted I'm sympathetic to some progress on this issue, but the draft has many problems. Wugapodes rightly identifies that biographies are the typical battleground. I'm perfectly happy that some types of people should normally have boxes, for example professional sportspeople, politicians and perhaps career military, but I won't support any policy change that all people should have them. In fact there should be a specific note of caution against adding them to people from the arts, and also people not easily classified, unless there is clear support from editors who have worked on this or related articles. That is a change that would vastly reduce conflicts. Johnbod (talk) 03:37, 17 March 2024 (UTC)

  I should add that "Broad topics and overview articles like philosophy, time, or Mathematics are usually better served by navigational sidebars like {{philosophy sidebar}}, {{time sidebar}}, or {{math topics sidebar}}." would have to go. There are already far too many sidebars (by which I hope you mean bottom bars), and the very last thing we want to do is to encourage even more datafication of articles. Research shows they are rarely used by readers. Johnbod (talk) 15:13, 21 March 2024 (UTC)

  Why? Pablo Picasso has an infobox, and yet he undoubtedly is a person from the arts, and a very important one at that. Personally I'm often confused when people don't have them where they would no doubt be useful and where useable examples have already been drafted (Gioachino Rossini is one such case). If one outcome of this RfC is that all people will or can got infoboxes, avoiding the tiresome and needlessly time-consuming process of having to discuss this again and again in each individual page, that would already be a huge plus. And it would allow editors to focus on the thing that matters most (content creation and improvement), instead of spending their time in repetitive discussions. Gawaon (talk) 07:22, 17 March 2024 (UTC)

  So? Do I say nobody from the arts should have ibs? Yes, I can see you are confused. Johnbod (talk) 15:13, 21 March 2024 (UTC)

  While no-one has to attend an RfC, they can be time consuming when an article under people’s stewardship is targeted by a cadre of the same people with zero interest in the subject. That’s what causes a tiresome timesink. Not all biographies are suited to the one-size-fits-all approach, and they never will be. That’s why the consensus (reaffirmed at RfC only nine months ago) is that the current wording is an adequate reflection of reality. - SchroCat (talk) 08:13, 17 March 2024 (UTC)

  When a discussion is deadlocked that is not a consensus. The discussion nine months ago failed to reach a consensus either way. Nemov (talk) 12:12, 17 March 2024 (UTC)

  It failed - and it's a mischaracterisation to call it deadlocked. The closer of that particular RfC summarised as "'Infoboxes are neither included or omitted by default' is the rough consensus choice", which is both a consensus, and as close to "The use of infoboxes is neither required nor prohibited for any article" as you can get without directly copying. - SchroCat (talk) 12:34, 17 March 2024 (UTC)

  I appreciate you came back a day later to reword this and I rather enjoyed this colorful interpretation of consensus. Nemov (talk) 21:59, 18 March 2024 (UTC)

  If you think the neutral closer made a mistake with the interpretation of the consensus, feel free to challenge it, but no-one raised any questions at the time, and rightly so. My original point (that the consensus was “reaffirmed at RfC only nine months ago”) stands, despite your attempt to misconstrue and deny. - SchroCat (talk) 22:07, 18 March 2024 (UTC)

• Oppose as drafted I agree with the headline that infoboxes are recommended, but the proposed text misses out on biographies, and has too much other waffle about the content of the box. Graeme Bartlett (talk) 09:43, 17 March 2024 (UTC)
• Strongest possible support the only reason some articles that normally should have infoboxes don’t is because the article or topic is controlled (dare I say WP:OWNed?) by a handful of powerful contrarians who are still fighting the infobox wars that otherwise ended in a decisive, uncontroversial victory for the pro-infobox faction. This balkanized, arbitrary system is not how a very standardized encyclopedia should be run. Dronebogus (talk) 15:19, 17 March 2024 (UTC)

  As the number one fan of infoboxes, you should know it's not allowed to write "decisive victory". Also, since when are we a "very standardized encyclopedia"? We are very explicitly, fundamentally not that. Remsense诉 15:22, 17 March 2024 (UTC)

  I’m sick of “ignore all rules”. We have a lot of rules, they’re very good rules, and they’re pretty much always followed. IAR is basically “it’s no biggie if you accidentally break them because they are not laws”, basically advice for inexperienced editors. When experienced editors cite IAR it’s basically to say “my opinion is better than a well-established best practice formed by multiple editors over a long time and accepted by the community”. Dronebogus (talk) 15:30, 17 March 2024 (UTC)

  It's you versus a fundamental pillar, then. Remsense诉 15:32, 17 March 2024 (UTC)

  I know it’s a fundamental pillar, but I think it’s so vague it can be interpreted any way you please (which I guess is the point?). I don’t really understand what the point/message of IAR is, when obviously Wikipedia does have rules that more or less have to be followed, otherwise we wouldn’t be able to sanction people for breaking them. Dronebogus (talk) 15:35, 17 March 2024 (UTC)

  In my view, it’s so vague it can be interpreted any way you please is not an adequate characterization. It's an inherently social, not individual pillar: the point is that the intent and spirit behind rules are what matter, and if interpretation of a rule in a given situation, even ones that don't seem overly pedantic, are agreed among those concerned to go against the spirit of the rule, the text of the rule can be ignored. This may be adapted into the future text of a rule, but doesn't always need to be. Remsense诉 15:42, 17 March 2024 (UTC)

  That’s a beautiful summary. Maybe it should say that instead of a one sentence non-explanation that can easily just be interpreted as “lol go rando” Dronebogus (talk) 15:44, 17 March 2024 (UTC)

  And I mean the IAR page, not the pillar page. Dronebogus (talk) 15:46, 17 March 2024 (UTC)

  It's kind of there already. The policy says "If a rule prevents you from improving or maintaining Wikipedia, ignore it." Making random changes does not improve or maintain Wikipedia; implementing the spirit of the policies does.

  I think we need more IAR rather than less. There are too many editors, particularly those who started editing in the last couple of years, who seem to believe that everything which is not allowed is forbidden. As an example, one diligent, faithful editor is asking today whether Wikipedia:Citing sources will accept one of the most common citation styles in use. (That guideline literally contains the words nearly any consistent style may be used – WP:PAREN, all-numeric date formats that conflict in British vs American English, and WP:Bare URLs being the only exceptions.) WhatamIdoing (talk) 05:25, 18 March 2024 (UTC)

  Also, while I'm on the subject: the point of the policies and guidelines is to make the project work. It's not to be able to sanction people. The "sanction" for "violating" WP:CITE is specified in its lead: Others will improve the formatting if needed. WhatamIdoing (talk) 05:27, 18 March 2024 (UTC)

  It was less than a year ago that you received a contentious topics message about incivility around IBs. Given the continued disruption you attempt to create on the subject, we’re close to an AE report. - SchroCat (talk) 15:27, 17 March 2024 (UTC)

  I could say the same of you. Dronebogus (talk) 15:31, 17 March 2024 (UTC)

• Oppose. One of the more deeply-embedded and damaging structural flaws of Wikipedia is its tendency towards formulaic construction of articles, where rather than reflecting how the sources write about something, Wikipedia instead uses the sources to establish 'notability', and then builds an article around its own series of labels, classifications, and conventions. This begins with a title (selected for brevity rather than descriptiveness, and frequently non-neutral, even if only accidentally), gets further embedded through a lede that restricts once more the potential scope, and then breaks content up into sections based not on how the sources discuss the topic, but instead on existing Wikipedia practice for whatever topic-hole Wikipedia has decided to shoehorn it into. Infoboxes are very much a part of this process, and not infrequently end up skewing articles even further into the this-is-how-Wikipedia-defines-things-never-mind-the-sources distortions that formulaic construction imposes. Some topics (a great many, actually) aren't about well-defined 'events', 'people', 'settlements', or similar seemingly narrowly-scoped subject classes that can be summarised infobox-style but instead, per the coverage in the sources we are supposed to build articles around, complex interactions of competing ideas within an ongoing narrative, where whether something is a 'settlement' say is deeply contested. In such circumstances, infoboxes don't just impose a restrictive structure on article content, they pick sides. Imposing (or even 'recommending') infoboxes in such circumstances amounts to an instruction to violate WP:NPOV. AndyTheGrump (talk) 16:42, 17 March 2024 (UTC)

  I’m not sure I follow. You don’t like this proposal because you don’t like… putting things in categories because it’s NPOV to call George Washington a “person”, World War I an “event”, or Truth or Consequences, NM a “settlement”? I recall you got into this weird postmodern meta-arguing at the village pump when I proposed banning “popular culture” sections. The thing is, I don’t think there’s “complex interactions of competing ideas within an ongoing narrative” going on in an infobox that tells me where John Stamos was born or some other objective information. Dronebogus (talk) 16:50, 17 March 2024 (UTC)

  I’m not sure I follow. I'm quite sure you don't. Accordingly, I suggest you take your vacuous straw man arguments somewhere else, and leave commenting on my response to people actually capable of understanding it. AndyTheGrump (talk) 16:58, 17 March 2024 (UTC)

  Calling me stupid is not a great counter argument. You could actually explain where I’m wrong. Dronebogus (talk) 17:00, 17 March 2024 (UTC)

  You are wrong to engage in vacuous straw man arguments. If the reason you do so is because you can't follow my argument that's your problem, not mine. AndyTheGrump (talk) 17:04, 17 March 2024 (UTC)

  That’s exactly the kind of non-explanation I was worried you were going to give. “You’re wrong because you’re wrong”? How am I supposed to learn anything from that? Dronebogus (talk) 17:07, 17 March 2024 (UTC)

  This is an RfC on Infoboxes. It isn't an 'explain to Dronebogus why straw-man arguments are invalid' thread, and I am under no obligation to teach you anything. Or to respond to you at all for that matter. I have expressed my opinion, which is all that participation in an RfC requires. AndyTheGrump (talk) 17:16, 17 March 2024 (UTC)

  This is the same argument strategy you use here. In no particular order: make vague accusations/complaints, turn everything into a discussion about Wikipedia’s systematic flaws, and either refuse to answer objections/questions or insult the user posing them. This may not be an “explain to Dronebogus why straw-man arguments are invalid” thread, but it’s not “Andy’s jaded semi-retired ex-Wikipedian vent thread” either. Dronebogus (talk) 18:05, 17 March 2024 (UTC)

  Replies to replies to replies are rarely useful in RFCs and this is thread is veering off target. -- LCU ActivelyDisinterested «@» °∆t° 20:06, 17 March 2024 (UTC)

• Oppose. Per the reasoning of user:Johnbod. Somambulant1 (talk) 22:31, 17 March 2024 (UTC)

• Oppose. For many short articles on ancient figures, infoboxes are simply lede repetitions. Having them adds nothing and opens the box (pun intended) for drive-by subtle vandalism. A recent example of this is the hundreds of articles which were basically vandalised by this infobox-only edits that were inconsistent with sources with body text. On this kind of edit warring, over articles such as Gaius Verres – a person whose infobox parameters number like actually three – there is also the related edit warring of which kind of infobox to use; unless we want to... basically delegate infobox type to projects... something which I believe policies are against, then we are sure to get into dumb "debates" over additions of anachronistic misleading fantasy images to the infobox, whether {{infobox officeholder}} should be used rather than {{infobox person}}, and (also repeatedly) the filling in of factually incorrect parameters such as |party=. (Most laypeople don't know this but there were no political parties in the Roman republic; that does not stop know-nothings from edit warring over |party=Optimates or |party=Populares.) Ifly6 (talk) 22:39, 17 March 2024 (UTC)
• Oppose Lots of comments noting the debate around infobox use in particular articles, but even when used they are a particular lightning rod for disputes (there is currently a long RfC at The use of 'infobox country' for fictitious states for example). That infoboxes can be contentious is not a reason they can't be used, but does suggest it may not be a good idea to write into MoS the idea that they should be. The listing of specific article groupings with particular infobox use is better handled through smaller more specific MoS tailored to those articles, rather than at this high level. Mentioning sidebars as a potential alternative is a good idea, although I would similarly hesitate to prescribe them. As for stubs, infoboxes are not uncommon on stubs, and the "often attract edits expanding the infobox rather than expanding the article" frankly could apply all infoboxes in any length of article. On the second paragraph, restricting infobox length feels in general useful (less is more), but I am also unsure it should be prescribed at such a high level. CMD (talk) 05:10, 18 March 2024 (UTC)
• Oppose. Unnecessary bureaucracy. — Sandbh (talk) 11:38, 18 March 2024 (UTC)
• Support in some form. I agree with the general underlying sentiment that existing guidance on infoboxes has not kept pace with actual practice in the topic. I disagree with a few points of Wugapodes' initial proposal – specifically, I think "people" should be removed from the first sentence since biographical articles are a historically contentious topic area for infoboxes, and I agree with Izno's suggestion of removing the passage on sidebars. However, I think the proposal is otherwise a sensible encapsulation of what we actually do in practice, and I think adopting it (or a revised version of it) would be helpful for communicating the in-practice expectations of Wikipedia readers and editors. ModernDayTrilobite (talk • contribs) 14:24, 18 March 2024 (UTC)
• Support in principle, but the wording needs some change. Infoboxes are already the standard for a variety of articles – contemporary officeholders, modern countries, chemical elements, etc. The current wording "The use of infoboxes is neither required nor prohibited for any article" is thus clearly outdated and does not reflect reality. For many other articles, leaving the use or not of infoboxes entirely to the editors that happen to work on any specific article leads to ownership issues and a lot of repetitive, unnecessary, and unproductive discussions. More guidance on whether or not any given article should have an infobox is urgently needed and so this RfC is clearly a step in the right direction.

Nevertheless, some specific wordings could use more work or might be better cut altogether. I think the sentence "Broad topics and overview article ..." could be safely cut, since the text is to be about infoboxes rather than sidebars, plus it's already implied in the mention of "topics with a narrow and well-defined scope" in the preceding sentence. And I think that the advice against the use of infoboxes in stubs should be removed – adding an infobox to a stub seems a reasonable way to help it grow, and the claim "infoboxes on them often attract edits expanding the infobox rather than expanding the article" seems entirely speculative without evidence to back it up. Might it not be the other way around, with edits to the infobox leading to other edits outside of it, whether by the same editors or by watchers? "they should neither be too short nor too long" is a triviality and not helpful, so that clause should be cut too. "consider using a link to a section" violates the rule that infobox entries should not link to sections within the same article (which I consider reasonable – that's what the TOC is for!), so it should be removed too (and the rest of that sentence reworded accordingly). But those are details – the core idea of the RfC is sound, it would help both readers (by leading to more consistency in article appearance for related articles) and editors (by reducing the need for repetitive discussions, and providing guidance in cases where discussions still happen). Gawaon (talk) 18:57, 18 March 2024 (UTC)

• Neutral, while the consensuses (consensies?) support this addition, this does seem CREEPy and not fixing an actual problem. Queen of Hearts ^she/_they^talk/_stalk 20:35, 18 March 2024 (UTC)
• Oppose as drafted As drafted, it may create a conflict with WP:INFOBOXPURPOSE and the type of information placed in the infobox - ... the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article and the article should remain complete without the infobox - ie what is placed in the infobox should be supported by the body of the article with few exception, as already indicated. Cinderella157 (talk) 02:05, 19 March 2024 (UTC)

  Why and where does the draft contradict this? I don't think it does. Gawaon (talk) 07:27, 19 March 2024 (UTC)

  I did not say that there was a contradiction but a potential conflict, where the draft states: They should contain basic facts which readers would reasonably be looking for at a glance ... This is much more subjective than that which I quoted above. It has the potential to be used as an end-around the more rigorous and sounder guidance at WP:INFOBOXPURPOSE. With few exceptions, such as chemical data that would normally be tabulated in any case, information in an infobox should be key facts supported by the article. Cinderella157 (talk) 12:16, 19 March 2024 (UTC)

• Oppose as not needed. If anything, the MOS guidance should be more aligned with WP:WHENINROME, and the language in Manual of Style/Infoboxes should be changed to: it is normal practice to defer to the style/layout used by the first major contributor to the page, and editors should not attempt to change an article's established style/layout, merely on the grounds of personal preference or to make it match other articles. Isaidnoway (talk) 10:42, 19 March 2024 (UTC)

  That only applies to citation styles, though. Gawaon (talk) 11:07, 19 March 2024 (UTC)

  Although WHENINROME is part of citation styles, it's not the only guide we have that has the same idea. Language choice (BrEng v AmEng v others at MOS:RETAIN), date format (at MOS:DATERET), use of serial commas, style (at MOS:STYLEVAR), etc etc, are all done on the 'first come' basis. Although there are some limitation and allowances on some points where it may be possible to change, the general concept is well-rooted in WP's processes; I seem to remember it was brought in to avoid continual disruption on the same points across multiple articles. - SchroCat (talk) 11:11, 19 March 2024 (UTC)

  Nevertheless, what all these have in common is that they are about merely stylistic choices, which have very little influence on the reading experience. Plus they don't rule absolutely, e.g. MOS:TIES can override MOS:RETAIN. Use or non-use of an infobox, on the other hand, is a major decision about how the article should look like, and so very different from such merely stylistic issues. We don't say "Whether an article may include images is to be decided by the first major contributor and cannot be revised later", and for good reasons. For infoboxes it should be the same. I'm not saying that every article should have an infobox (certainly not!), but merely that its usage is too big a decision to leave to individual taste. Gawaon (talk) 12:40, 19 March 2024 (UTC)

  A few things. Firstly I am not 100 per cent on board with the concept (I think it gives too much power to one person) and would remove the ability to remove an IB that was unsuitable; I would, however, prefer this slightly different approach to one that didn't involve people with zero interest in the subject descending to demand a box "just because", with no real thought or rationale behind it - ignorance of the subject matter is the worst thing basis on which to decide to have a box or not - and unfortunately that's the system we have at the moment. I also acknowledged that there were limitations on the choices, and yes, TIES is one of those, but that's a bit of a straw man as far as IBs go.

  During my time considering the various arguments put forward in IB discussions, I've seen IBs described as a stylistic choice, not a stylistic choice, text, not text, content and not content, so I'm unswayed by any attempts to categorise or pigeonhole them (they are clearly each and all of those things, as well as more). While an IB 'is too big a decision to leave to individual taste', it's also one unsuited to being forced by "the rulez!", and one unsuited to decision by drive-by committee with no grasp or feel of the subject. - SchroCat (talk) 13:24, 19 March 2024 (UTC)

  The difference between infoboxes and those other issues is that infoboxes are an expansion, which can be considered part of the development of an article, not a replacement. There is no loss or gain in changing an article from British English to American English, there is for adding or removing an infobox. For example, I have yet to add a lead infobox to Across 7 Street, but that is not a disendorsement of someone adding one later on Mach61 01:34, 22 March 2024 (UTC)

  ”Expansion” isn’t really the right term. “Repetition” is more appropriate. IBs provide a dumbed-down repetition of out-of-context factoids that often mislead and that that normally focus on trivia. As I said above, my point was that the concept of ‘first choice’ is not uncommon on WP, but not necessarily one suited to the question of IBs. - SchroCat (talk) 06:49, 22 March 2024 (UTC)

• Oppose, as I would if the proposal were to recommend not using an infobox in any particular area. The current guidance is elegant and balanced, and allows for flexibility. When moving away from flexibility, in order to make imposing one viewpoint easier, we tend to run into conflict with those holding a different viewpoint. If the conditions are appropriate for an infobox then the current wording allows for the use of an infobox, so there is no problem. However, under the new proposal, if the conditions are not appropriate for an infobox, but the article is on a person (for example), then the new wording could be used to impose an infobox, and that imposition is likely to be challenged, leading to potential conflict and dissent. This proposal doesn't make the adding of appropriate infoboxes any easier, but it does legitimise the adding of controversial and inappropriate ones so opening the door for disruption. SilkTork (talk) 14:08, 19 March 2024 (UTC)
• Oppose per instruction creep. Some1 (talk) 02:36, 20 March 2024 (UTC)
• Support I personally find the infoboxes helpful in certain articles and it helps me get a general sense of important facts. ‍ Relativity 02:56, 21 March 2024 (UTC)

  Ah, so you personally like it then? ——Serial Number 54129 11:48, 21 March 2024 (UTC)

  "I like it" is an entirely reasonable argument in this context? Mach61 01:13, 22 March 2024 (UTC)

  No of course it's not, I know that. That's because, as a purely subjective assessment, it is incapable of being distilled into a de facto style standard capable of being written down in PAGs. Cheers, ——Serial Number 54129 16:28, 22 March 2024 (UTC)

• Oppose per AndyTheGrump. Ajpolino (talk) 13:48, 21 March 2024 (UTC)
• Support, the trend line on this issue is pretty clear, especially considering the fact that there haven't been many successful proposals to remove infoboxes from biographical articles that already had them. It is bad to have de facto style standards that are not written down in PAGs, and the widespread acceptance of infoboxes is one of them. Mach61 01:25, 22 March 2024 (UTC)
• Oppose, instruction creep. Stifle (talk) 11:43, 22 March 2024 (UTC)
• Oppose, doubly. First, I do not agree infoboxes make sense for all biographies. As already noted, figures in antiquity are the biggest example - people who are just lines on a page somewhere, where even if detailed biographical detail is provided it may be wildly untrustworthy and written by someone centuries later (think the Persians Herodotus wrote about). Forcing infoboxes is just asking for well-meaning editors to invent some stuff, or to reify guesses by placing them in the infobox. Secondly, even if you disagree, it doesn't matter. If some editor wants to write a well-written and well-maintained article without an infobox... let them. The lack of a common feature is very different from something like inaccurate content - it's not a "problem" to be fixed. It's just that article being a little different, which is harmless and accepted on Wikipedia, which explicitly accepts multiple styles of English, multiple styles of citation, multiple styles of section organization, and so on. SnowFire (talk) 15:34, 22 March 2024 (UTC)

  ↑↑↑↑ This. - SchroCat (talk) 15:56, 22 March 2024 (UTC)

• Support. Not only infoboxes are generally a good idea, but also there is de facto consensus that they should be used. The current neutral MOS wording is misleading. Furthermore, the proposal only recommends infoboxes, it does not require them. Editors will be able to discern where following the recommendation is not appropriate. Tercer (talk) 08:37, 23 March 2024 (UTC)

  It's a false claim that there is a de fact consensus - that's wrong. The current wording is not misleading (to be honest, how could it be?) And I think we all know the levels of wikilawyering that go into a loaded term like "recommends", where many will translate "recommend" as "insists upon". I don't think anyone disagrees that they are beneficial in some articles on some subjects, but there are articles on which they are unsuited. - SchroCat (talk) 09:33, 23 March 2024 (UTC)

  Of course it's misleading. It says: "The use of infoboxes is neither required nor prohibited for any article" (emphasis added). But as I've pointed out, there are some groups of articles – say contemporary officeholders, modern countries, chemical elements etc. – which simply always have an infobox, and no discussions about it are needed. Also, the proposal doesn't suggest that infoboxes are suitable for all articles, so why the straw man in your last sentence? Gawaon (talk) 10:57, 23 March 2024 (UTC)

  So there are IBs on articles where there is a consensus, you mean? I'm struggling to see how that is misleading. There's no straw man in my previous comment, even allowing for stubs; some fully-formed biographies also don't warrant sufficient information to generate an IB. - SchroCat (talk) 13:28, 23 March 2024 (UTC)

  It is helpful to write down broad consensuses in PAGs; that is, in fact, the purpose of PAGs. Mach61 06:49, 24 March 2024 (UTC)

  And the broad consensus is recorded. - SchroCat (talk) 07:18, 24 March 2024 (UTC)

  Where? Gawaon (talk) 07:28, 24 March 2024 (UTC)

  I think you may be being deliberately obtuse here. The current guideline well reflects the fact that only 45 per cent of articles have an IB, no matter how pointless or misleading some of those boxes are. - SchroCat (talk) 07:44, 24 March 2024 (UTC)

  Yes but there are some article types where having an infobox is generally considered best practice. For example almost every movie has an infobox and ones that don’t usually are of lower quality. Dronebogus (talk) 07:52, 24 March 2024 (UTC)

  I agree they work well in film articles, but that’s not one of the areas listed in the proposed wording. And that’s just one reason why the proposed wording is so deeply flawed. It has one topic where use is considered contentious (you removed an IB today that would have been enforced by the proposed guidelines, just as a reminder), but it didn’t include areas where their use (and their usefulness) is commonplace. Having a list of areas where they are uncontentious is both unnecessary and INSTRUCTIONCREEP, and the current guideline is both accurate and manageable. - SchroCat (talk) 08:10, 24 March 2024 (UTC)

  "Yes but there are some article types where having an infobox is generally considered best practice." Right and there is nothing whatsoever in the current guidelines that makes this clear. Which is why they should be changed. The rest is details – coming up with a better wording might not be trivial and I agree (and pointed out in my vote) that the proposal suggested above needs more work, but it's something we should be able to figure out. Gawaon (talk) 08:46, 24 March 2024 (UTC)

• Support in principle. I don't think the factual assertion about stubs is true, and I think it should be removed. I also think that we would need to build up some "case law" (maybe a FAQ or a footnote would be sufficient? Or changing the wording to "recommended but not required"?) to explain to editors that the word "recommended" does not mean "required" (particularly for pro-infobox people). The table of recent RFCs is instructive: not a single RFC about infoboxes during the last two years has ended with a consensus against including an infobox. I don't recall seeing an RFC proposing to remove an existing/long-standing one for years (I'm not entirely sure established infoboxes ever get RFCs proposing their removal them, actually). I think therefore that the change from "scrupulously even-handed because we don't want to get screamed at by anyone, thanks" to "all else being equal, we kind of lean towards including an infobox" is inevitable, and we should document that reality. We should not continue telling newcomers that the playing field is equal, because – for better or for worse – it's not. WhatamIdoing (talk) 22:19, 23 March 2024 (UTC)
• Support. Infoboxes provide readers with quick access to the most pertinent information about a subject, like date/place of birth and death, positions held, major awards, etc. Looking through the opposes I don't see a compelling reason not to recommend them. Jessintime (talk) 14:45, 25 March 2024 (UTC)

  I do not think that birth/death is equally pertinent for all articles. The part about awards too would also be largely inconsequential, especially for more historical figures where societal awards were not commonplace. 128.227.1.32 (talk) 15:51, 25 March 2024 (UTC)

  @Jessintime: Serious question, then: would you recommend an infobox for "biographies" like Sanballat II? What would be in it, if so? (This is an extreme example - this is a hypothetical person who probably did not even exist, but the word "Sanballat" was written on one surviving piece of papyrus, and a scholar proceeded to generate wild-ass guesses that maybe it's the son of this other guy but who had the same name, or maybe the grandson. But is "one guy's guesses" infobox-worthy, when the Infobox is normally accepted, factual background elsewhere? Especially when those guesses don't really have a scholarly consensus behind them?) SnowFire (talk) 20:19, 25 March 2024 (UTC)

  I don't understand your argument. Infoboxes would be recommended, not required. Some articles don't have enough information to justify the purpose of an infobox. The conflict over infoboxes on biographies isn't for short articles. As others have noted, there hasn't been a single RFC that's been required to remove an infobox like the example you've presented. This idea that infoboxes will be jammed into small articles seems ridiculous. Even the most ardent infobox supporter wouldn't agree with that. Finally, if you really do think this is a problem the status quo is really no different. There's no guidance so an editor could put an infobox on any small article if they wanted. Nemov (talk) 21:08, 25 March 2024 (UTC)

  Having verbiage like this for editors to point to makes the worse info boxes much stickier, and textually encourages their addition when no such encouragement is required. There is a difference. Remsense诉 22:13, 25 March 2024 (UTC)

  Ths doesn't address my point. There's nothing stopping this imaginary problem from happening now. Nemov (talk) 23:21, 25 March 2024 (UTC)

  Again, it is a matter of degree. People adding clunky stuff where it doesn't belong will always happen, but this verbiage will make it happen more often. Remsense诉 05:58, 26 March 2024 (UTC)

  Nemov: I really hope that is true, but I have little confidence it will be true. In this very discussion several editors seem to advocate that every single article of [type] should have an infobox, no matter what, no matter how nonsensical. Anyway, your last argument cuts bother ways - if we're trusting editor discretion, then why not say nothing per WP:CREEP? SnowFire (talk) 05:41, 26 March 2024 (UTC)

  ”This idea that infoboxes will be jammed into small articles seems ridiculous” Does it? There are too many editors who read “recommend” as “must have”. There are many, many small articles that unthinkingly have an IB placed into them (this was one, until recently). As soon as you start twisting the wording towards “recommending”, then you’ll see a plethora of empty crap, bloated crap and/or trivial crap being placed where it really shouldn’t be, just because people don’t engage their brains and question why they are blindly adding something, or the drawbacks and flaws of their edit. There’s already too much lack of thought when it comes to IBs, but you seem t want to encourage that for some reason. - SchroCat (talk) 05:57, 26 March 2024 (UTC)

  You don't seem to have must trust in Wikipedia's editors. Gawaon (talk) 07:21, 26 March 2024 (UTC)

  Not all of them, not all the time. That's what policy is for. Remsense诉 07:24, 26 March 2024 (UTC)

  Here the argument seems to be, however, that a more detailed and realistic (= in line with actual practice) policy/guideline would be abused by editors, and so it's better not to have it. That's a bit odd. Gawaon (talk) 07:42, 26 March 2024 (UTC)

  This seems to be part of the disconnect: the detail serves no useful function. The present guideline is perfectly adequate as policy, which is meant to be didactic before it is descriptive, in my view. Remsense诉 07:50, 26 March 2024 (UTC)

  When you’ve been here a while you’ll appreciate the point of view. While 99 per cent act in very good faith most (but not all) of the time, not everyone has the ability to produce or judge quality content. Not all think before acting and many take the MOS as some form of fetish to adhere to, even taking “recommend” for “insist upon”. - SchroCat (talk) 08:10, 26 March 2024 (UTC)

  I didn’t know the Manual of Style was a kink for some people (yes I know what fetish means in this context it’s a joke) Dronebogus (talk) 19:15, 29 March 2024 (UTC)

• Oppose, instruction creep and per SnowFire. Infoboxes are particularly problematic for arts biographies. Jip Orlando (talk) 13:59, 27 March 2024 (UTC)
• Conditional support the proposed text is better than the current, archaic text, but the wording is imperfect. "events" and "people" are too broad a classification to recommend infoboxes for. The second sentence should not advocate sidebars (and mathematics should be in lowercase). "they should neither be too short nor too long" is about the most useless advice one could give. The rest of the second paragraph could be condensed slightly. Otherwise this is a good proposal. The current policy is often surprising to new users, who see infoboxes as an integral part of what Wikipedia is, and needs revision. Toadspike (talk) 11:17, 30 March 2024 (UTC)
• Oppose For many of our subjects, little is known about many of the infobox's fields and there's considerable uncertainty, sometimes fierce dispute, about others. Happily, many are also irrelevant (for example, the number and names of the brothers of a poet will usually have nothing to do with that writer's significance). But these parameters remain in the infobox designs; filled, they're at best distractions and often misleading to the reader, unsourced, not summaries of the article, or simply wrong, and left blank they are traps and temptations to helpful editors, often novices, eager to contribute to the encyclopedia by making it more complete and very often focused on infoboxes as the best or easiest contribution they can make. If experienced editors with extensive watchlists and familiar with the subject revert them, however gently they do it, we still leave new editors with a discouraging early experience of editing; if no active editor has the article watchlisted and overcomes their weariness of defending the encyclopedia, the errors remain and the degradation of the encyclopedia accumulates. Encouraging the proliferation of infoboxes with proposals such as this can actively harm the project of building Wikipedia.

This should not be dismissed as just a matter of biographies from antiquity - classical Greece and Rome and suchlike. Information is scant on many notable historic and even living people. Many historic measurements cannot be converted because of our incomplete knowledge of the units of measurement; even the content and dates of any laws governing them are often fragmentary or lacking. For wars, battles and military campaigns, there are often no clear records or historical consensus on the sizes of the forces involved, the military or civilian casualties, or even if anyone can be said to have won, yet helpful or biased editors will fill in those fields with ancient exaggerations or invent their own. Of a plant on which a city's economy depended, we know little but the name and that it's extinct. Population sizes and demographics are only vaguely known and much contested throughout time; even present-day numbers of adherents of different religions and none, in particular countries and worldwide, are the subject of much infobox warring on little or no evidence. These are only a few examples from my experience; other editors would be able to add many more fields of study. Overall, it is not at all only "liberal arts" for which infoboxes are sometimes inappropriate; in many ways, it's the occasions when infoboxes are appropriate that are far more limited than this proposal acknowledges. NebY (talk) 15:34, 31 March 2024 (UTC)

• Oppose there are many event articles on which infoboxes are inappropriate—for example when many of the fields are "disputed" or "unknown". That's not just an issue with ancient history, summarizing the causes of wars/genocides in infoboxes is more misleading than clarifying. (t · c) buidhe 06:04, 1 April 2024 (UTC)
• Mild support. As someone who has no strong opinion either way on infoboxes, the proposal seems to me to reflect current practice and may help limit edit wars about infoboxes. Sandstein 07:36, 5 April 2024 (UTC)

• Oppose - per the very good arguments above. Infoboxes work well on complicated topics, such as astronomy, science, sports, and military. Pretty much everywhere else, they are repetitive, misleading, uninformative and open to abuse and bloat. I've seen the figure of 50% cited above, when it comes to infoboxes already in existence, but I would wager that most of these carry pointless, repetitive information and exist, purely, as a result of a toxic discussion somewhere. Cassianto^Talk 08:08, 8 April 2024 (UTC)
• Oppose. Infoboxes are sometimes good and sometimes bad. The nature of Wikipedia (an encyclopedia!) is such that it is impossible to specify by rule whether a given article would benefit from one (except for very limited classes of articles, e.g. the elements). Most cases are obvious (hence established practice), but many are borderline. Best to leave it to discussion on a case by case basis. Srnec (talk) 13:59, 10 April 2024 (UTC)
• Oppose for people per Kusma and SC. voorts (talk/contributions) 20:28, 2 May 2024 (UTC)

  Bit late to the party no? Dronebogus (talk) 05:48, 3 May 2024 (UTC)

  I would say no, since the RFC is still open, which would imply to me that...the RFC is still open! Remsense诉 06:49, 3 May 2024 (UTC)

  The RFC’s open because no uninvolved admin has bothered to close it. Most activity completely ended a month ago. Dronebogus (talk) 12:45, 3 May 2024 (UTC)

• Support. The proposal aligns with the community's practice on infoboxes. The current wording is outdated. TarnishedPath^talk 03:31, 22 May 2024 (UTC)

Comments

• There have been a few comments citing ARBCOM as an impediment to this proposal. Regardless of the outcome of this discussion, ARBCOM doesn't prohibit the community from creating guidance on the use of infoboxes for biographies or any other subject. We should listen to experienced closers like S Marshall who have pointed out that guidance would be helpful. In fact, during the 18 months or so that I have been observing this topic admins/closers have said on multiple occasions that guidance on infoboxes is the logical next step to prevent future RFCs on the topic. - Nemov (talk) 14:24, 16 March 2024 (UTC)

  Nemov… what is wrong with RFCs? Blueboar (talk) 14:55, 16 March 2024 (UTC)

  Blueboar… there's a lot wrong with RFCs about infoboxes.

  Firstly, infoboxes are very Wikipedia-specific things. You can't cite a source to say whether to have an infobox.

  Secondly, there are no policies or guidelines about whether to have an infobox. All we have is an Arbcom case, and Arbcom doesn't have jurisdiction over content decisions.

  Thirdly, I have never seen an infobox-related argument I can give greater weight to because of reason or logic. They reduce to: "I like infoboxes" (ILIKEIT); "I don't like infoboxes" (IDONTLIKEIT); "Lots of other similar articles have infoboxes", or the converse (OCE); "We generally put infoboxes in articles like this", or the converse (OUTCOMESBASED); and "Infoboxes help our readers easily find facts" or the converse "Infoboxes steal attention from the prose" (both of which have their own essays and neither of which I find particularly compelling).

  Therefore as I've observed before, any RfC about an infobox is just a straight-up poll. You count the numbers on each side, subtract the obvious socks, and reach a total. That's it.

  We need some community decisions to work with. Specific, clear ones please. "It depends" is perfectly useless in practice.—S Marshall T/C 21:58, 16 March 2024 (UTC)

  We're a bit stuck, frankly, because like you've said, it's a wiki-specific construction, but it's a construction that requires us to be able to make our own editorial judgements on what is important, in a way that WP:NPOV normally prevents us from doing. We can't reflect the bigger world if there is no bigger world. I'm fine living with that per the status quo, but I appreciate it will continue to cause problems. Remsense诉 22:03, 16 March 2024 (UTC)

  I understand that having a “rule” that was more definitive than “it depends… decide at the article level” would make life easier for admins and closers… but I don’t think it would be best for the articles themselves (and that should always be the goal of policy, even when it makes life difficult for the wonks behind the scenes). Blueboar (talk) 12:53, 17 March 2024 (UTC)

  I think the “benefit” to articles here is negligible if not nonexistent since in most cases it just results in an infobox being considered an improvement. So having a rule would likely end up helping both articles and “behind the scenes wonks”. Dronebogus (talk) 21:11, 17 March 2024 (UTC)

  @S Marshall, I wonder what you think the ideal reason for supporting or opposing an infobox would sound like. Are you hoping editors will say something like "doi:10.1177/1464884914545739 says infoboxes "enable readability and quick reference" for news events, and all true Wikipedians support readability and the use of Wikipedia as a quick reference, so of course I think this news-event-related article should have an infobox"? Is that more compelling than "Based on my experience, I think an infobox would be typical and appropriate for this article" or "Yes, let's have an infobox for the people who just want to look up a basic fact, especially if they're not native English speakers"? WhatamIdoing (talk) 05:40, 18 March 2024 (UTC)

  I'm envisaging a happy world where I have a guideline that says something like Wugapodes' proposal so I can evaluate !votes saying "Support: meets WP:INFOBOXCRITERION#3." :) I want the community to tell me whether to give greater weight to those who've actively edited the article and lesser weight to those who haven't; or else to weight all Wikipedians equally. I don't mind which. In an even more perfect future the guideline might tell me what to do when only one parameter of the infobox is in dispute (which is at issue in a lot of RFCs). Because I don't weight any of those example three views higher.—S Marshall T/C 07:41, 18 March 2024 (UTC)

  It sounds like you're looking for pre-approved reasons (similar to "we delete copyvios" or "we only include images that have educational value for the article"), and we're giving you only editors who are using their best judgement and common sense.

  I'm not sure if we have a generic rule about giving greater weight to those who've actively edited the article and lesser weight to those who haven't. WP:OWN suggests that all editors should be treated equally, and once a dispute reaches the RFC stage, it's possible that we would prioritize the views of uninvolved editors. WhatamIdoing (talk) 22:41, 23 March 2024 (UTC)

  I think that people exist who have strong views about infoboxes, and who come to RFCs about articles they've never edited in order to !vote or against including an infobox. Some of them only ever !vote one way. Perhaps this is perfectly unproblematic behaviour and I should indeed give those people greater weight than those who've laboured on the article; but, also, perhaps not?—S Marshall T/C 17:20, 24 March 2024 (UTC)

  It's tricky. We don't want to discourage the primary authors of an article, but we also don't want to let them override the rest of the community's views. But we could equally say "Some of those primary authors never add an infobox to any article they write. Perhaps this is perfectly unproblematic behaviour..."

  Have we been approaching this from the POV that infoboxes really ought to be a 50–50 thing within each general subject area? It is really true that Template:Infobox person is equally likely to be desirable or undesirable for a randomly selected group of articles about people? I pulled up 10 pages in Special:RandomInCategory/WikiProject Biography articles. Eight of them had infoboxes. The two that didn't were Constance Burrell and Ben Fee – both dead, and neither with photos of the subject.

  I am concerned that we have talked ourselves into a state of hand-wringing helplessness. "It's just hopeless – we'll never be able to decide whether an infobox belongs in an article. We should give up now, because no advice or rationale could possibly be valid or any better than flipping a coin". The fact is that the playing field isn't level; it appears to be tilted heavily towards including infoboxes for most articles (e.g., most of the two million articles about people, nearly all articles about species, but not in lists or in articles for which no suitable infobox exists [such as Mathematics or Philosophy – those tend to get sidebar navboxes instead]). The last time an RFC (or any advertised discussion) ended with a consensus against an infobox is so long ago that nobody remembers it. We have a decision in practice. Editors are voting with their feet, and they're voting to put infoboxes in nearly all articles. WhatamIdoing (talk) 18:18, 25 March 2024 (UTC)

  I think that current custom and practice looks like this:

  If our article is about something basically unchanging with heaps of quantifiable data, such as a chemical element or compound, a railway station, or a drug, then an infobox is incredibly useful, quite uncontroversial, and also, often absolutely huge. Nobody argues about those infoboxes and I need no guidance about them.

  If our article is about something with some quantifiable data but also some things that might vary between sources because they change over time, such as a disease, a railway station, or a nation state, then infobox is likely useful and mostly uncontroversial but needs regular updating. In such cases one or more of the infobox parameters might be a matter of opinion, but the opinions are from subject matter experts and handed down in reliable sources. These infoboxes are useful and mostly uncontroversial. I need no guidance about them.

  If our article is within the scope of WikiProject Mathematics, then it doesn't have an infobox, no useful infobox could be devised, nobody's arguing and I need no guidance about it.

  If our article concerns something without quantifiable data at all, but pure matters of opinion, and you don't need scholarship to have an opinion -- here I'm thinking about for example the genre parameter of {{Infobox song}} and {{Infobox album}} -- then you get conflict because different editors want to draw on different sources to say different things. On those, I would personally benefit from some parameters from the community to work with, and having such parameters would help reduce friction and manage inter-editor arguments before we get to RfC stage.

  If it's something that's controversial and nationalistic, then of course it's a huge problem. It's amazing how many RfCs reduce to "who won this battle?" and "what are the accurate casualty figures?" with conflicting sources from each side. It's been my experience that {{Infobox military conflict}} is incredibly fraught, much more so than {{Infobox military person}} and {{Infobox military unit}}. (We have editors who genuinely think that the side that holds the disputed territory at the end of a battle is the winner, irrespective of casualties, and irrespective of the other side's commander's orders.) And, yes, I'm shining the bat-signal up in the sky to the community to say, "Help!" If that's hand-wringing helplessness then okay, I'll be over here wringing my hands.

  I know, I'm partly talking about whether to decide or remove disputed infobox parameters rather than the question of whether we should have an infobox at all. I hope we're working towards rules about that too.

  To an extent, whether to have an infobox is partly stylistic preference. We do allow the article starter's preference to decide stylistic things, in matters like ENGVAR or DD-MM-YY dates or whatever.—S Marshall T/C 00:54, 26 March 2024 (UTC)

  Can you give an example of a subject that "concerns something without quantifiable data at all, but pure matters of opinion", and for which we have a relevant infobox? It's not going to be something like {{infobox album}}, as those articles include quite a lot of quantifiable data (e.g., whether it's live or studio album, release dates, recording location, length, names of various people and businesses involved – in fact, the only thing that could be disputed is musical genre, and those can only be disputed within a narrow range. People might argue over whether an album is glam rock or art rock [two closely related genres], but nobody's going to claim that it's best described as folk music, or classical Indian music, or smooth jazz). WhatamIdoing (talk) 02:05, 26 March 2024 (UTC)

  Classical Indian music? In my rock? It’s more likely than you think! Dronebogus (talk) 05:50, 26 March 2024 (UTC)

  The examples where all the quantifiable data are matters of opinion would be historical, and often historical individuals or battles. For example, Hereward the Wake, whose life is attested by sources from well after the fact which differ on every particular. Dissecting that infobox, it consists of his "name", which literally means "Army Guard the Watchful" and is almost certainly a cognomen; an image, which is taken from a source from eight and a half centuries later and depicts men fighting with weapons, shields and armour that are completely wrong for the time and place; his very approximate year of birth, which is no more than a best guess; his alleged county of birth, which is uncited, dubious, and as SchroCat notes hadn't actually been founded when he was born; his very approximate year of death, which is no more than a best guess; his claimed "other names" which would also be cognomens; and his "movement", whose historicity is hard to establish.

  But that infobox hasn't been a locus of dispute, and in fact the ones I was hoping for help with are typically where only some of the parameters are disputed. I know that's not quite what Wugapodes raised, but we've got a lot of policy-minded people gathered together thinking about infoboxes. Where there's genuine conflict between sources, when is it better to populate the disputed parameter with something like "see text", and when is it better to leave it blank? NB: That question does have various answers in obscure places but I'm not sure to what extent the answers represent the consensus of editors who think about infoboxes. For example in Template:Infobox military conflict/doc#Usage it says Information in the infobox should not be "controversial". Refer the reader to an appropriate section in the article or leave the parameter blank rather than make an unsubstantiated or doubtful claim. But for example in the whole massive barney about who won the Battle of Chawinda hardly anyone thought we should leave the parameter blank.—S Marshall T/C 09:18, 26 March 2024 (UTC)

• I don't believe adding a new proposal at this point is a good idea, and especially a new proposal so different from the first. -- LCU ActivelyDisinterested «@» °∆t° 09:28, 17 March 2024 (UTC)

New proposal

Proposed language: "The decision on whether or not to include an infobox in an article should rest with the editors who regularly edit and maintain the article." -- Ssilvers (talk) 01:55, 17 March 2024 (UTC)

I moved this to the comments section from above the "discussion" section since it's not what people were discussing and it's confusing to present it as if that's what's being discussed. — Wug·a·po·des 23:35, 21 March 2024 (UTC)

WP:SNOW closure?

I think it’s fairly obvious that this is never going to gain a broad enough consensus to pass. More importantly I don’t think it’s solving anything— most articles with infoboxes are fundamentally not controversial (so no need for a guideline there) and IMO the ones that are controversial are not related to the merits of infoboxes themselves but rather to the preference of the most prominent editors. I think this is a problem, but this heavy-handed approach clearly isn’t the solution. Dronebogus (talk) 00:39, 21 March 2024 (UTC)

No. Maybe there won't be a consensus, maybe there will be some kind of partial consensus for a more modest revision, but it's too early to tell until the discussion has run its course. Also, "I don’t think it’s solving anything" essentially means "I don't like it", which is certainly NOT an argument for an early closure (though it might be or become an argument against the proposal). Gawaon (talk) 06:21, 21 March 2024 (UTC)

If I were closing this, which obviously I won't be, then my closing statement would note that all the broad !votes so far support or oppose infoboxes in general, and all the narrow !votes are about infoboxes on biographies. I think we're learning a lot.—S Marshall T/C 10:43, 25 March 2024 (UTC)

S Marshall. I think that would be possibly be the wrong takeaway (I can say this because you're not closing!) Skimming through, there are very few people who oppose IBs in general, which is my experience from wider discussions too. The 'pinch points' are at specific areas where there are problems. Disagreements (from this discussion) seem to be around the size of the article, the lack of enough key points of information and certain types of biographies. People who hold 'ranks' (politicians, clergy, military, etc) are fairly uncontentious (because their career stages can be bulleted in the box); similarly athletes of all types are unproblematic (sporting statistics, club memberships and appearances at championships, cups, olympics, etc can also summarise the stages and achievements of the individual). The issue (as far as I have encountered it), is around the liberal arts, where the career is not defined by a statistical breakdown that can sit in a box. For liberal arts articles, the box gives too much WEIGHT to trivia. That would be my view of this discussion, and of some of the wider debates too. - SchroCat (talk) 11:01, 25 March 2024 (UTC)

I think there's more to it than "ranks" or "athletes" because it also seems to depend whether the person is historical, and if so, from which period. There are users arguing that point above, but it's also true in practice: from my brief glance at the history, I think that nobody has ever tried to add {{infobox noble}} to Lady Godiva. Interestingly, her maybe-son Hereward the Wake takes {{infobox person}} in which all the parameters are rather vague, which I think supports the premise that our practice is inconsistent depending on who edited the article.—S Marshall T/C 11:44, 25 March 2024 (UTC)

I’m not convinced that an inconsistent practice is a problem, particularly when Hereward is being listed in a modern county that didn’t exist. On the wider point, yes, I was thinking of the more recent biographies that I’ve seen, not those from antiquity, where even more problems abound. I don’t know why biographies were included in the original proposal: there are too many deep-seated problems in the topic for a one-size-fits-all rule. - SchroCat (talk) 12:05, 25 March 2024 (UTC)

I agree that inconsistent practice isn't a problem at the moment. Foreseeably, if the community does come up with a Treaty of Infoboxes 2024, there might be attempts to regularize it, which could lead to plenty of work for RfC closers.—S Marshall T/C 12:14, 25 March 2024 (UTC)

Other possible approaches

Multiple people have said that it would be good to have a rule that reduced or eliminated the conflicts over infoboxes in individual articles. I also have sympathy for S Marshall's request for guidelines for closing RfCs. This RfC tries to resolve those problems by establishing a rule; I don't think it's going to pass, but the problems remain, so I wanted to get a sense of what other approaches might gain support. Ideas (some mentioned above) include:

1. Find a different RfC wording that could gain consensus for a global standard, as this RfC tries to do. A couple of opposers said "oppose as drafted", implying another version might gain more support.
2. Give some extra weight in RfCs to the opinion of editors who have been actively editing the page before the RfC. This could vary from "Only active editors should be consulted" to "If there is no clear consensus, the active editors's views are only then given extra weight". The first of these would be equivalent to having an INFOBOXVAR. This rule would tend to work in favour of editors arguing against an infobox, since it's rare that there's an infobox on an article and someone comes along and tries to remove it.
3. For GAs and FAs, give extra weight to whatever the state of the article was at the time of promotion. The justification would be that multiple eyes have reviewed the article and agreed it is OK with/without the infobox. This would apply more strongly for FAs as there are more reviewers for an FA. This rule would also tend to work in favour of editors arguing against an infobox, for the same reason as above.
4. Allow consistency requirements at a project-level. There are some cases where (as far as I know) this would be uncontroversial -- elements, living things, roads, probably scores of others. This would always work in favour of infoboxes but I don't think it would help, because even if this doesn't run afoul of LOCALCONSENSUS, it's not the elements and roads that are the problem, and there is already a de facto consensus in those cases that doesn't need to be codified.
5. Limit the number of RfCs on infoboxes in some ways. I've seen suggestions that editor X should only be allowed to start so many per year, or only allowed to vote in so many per year, or that they should not be widely advertised. I think this would be a bureaucratic nightmare to police, though I can understand where the suggestion is coming from.

I have some scepticism about each of these, but the problem of infobox arguments isn't going away. Are any of these tweakable to be acceptable? Are there other ideas that could be tried? Mike Christie (talk - contribs - library) 18:33, 21 March 2024 (UTC)

I'd oppose 2, 3 since it seems like attempts to keep RFCs from breaking WP:LOCALCONSENSUS. Like you pointed out, 5 would be a nightmare to enforce and probably wouldn't do much anyway. The best argument against changing policy is that over time the vast majority of these disagreements are going to end because most of the RFCs are ending in inclusion. I haven't checked, but there can't be many of these large biographies that are missing infoboxes anymore. I'm sure there will be editors willing to argue about this forever, but the pool will eventually dry up. Nemov (talk) 19:02, 21 March 2024 (UTC)

I'd support 2 and 5. I'd oppose 3, especially for GAs -- Ssilvers (talk) 19:14, 21 March 2024 (UTC)

1. I'm neutral at the moment (it would, of course, depend on the wording), although it's likely to be as WP:CREEPy as the main proposal above. For those areas that are non-contentious, why is there a need to have a list of them? That's just pointless changing for the sake of change and won't affect anyone or anything. For areas that are contentious, they are contentious because people have good rationales why a one-size-fits-all list of trivial factoids isn't suitable for that particular article. That's the reason why there are not groups of people going round deleting boxes en masse, because each article needs to be judged on its merits, not by a drive-by, knee-jerk choice based on ignorance of the subject matter. I'd possibly support 2, depending on the wording (as I said above, most of the problems arise from ‘people with zero interest in the subject descending to demand a box "just because", with no real thought or rationale behind it’). Three I’d support if it didn’t include GAs: aside from the fact they are of variable quality, I’ve seen one reviewer of GAs near- bullying someone into having an IB during a GA review. Four I think would move disruption to the project level – and how do you police who is in any particular project? It still doesn’t get round the problem of those articles which are not suitable for IBs. Five I’d possibly support, but I agree it would be cumbersome to police. If, however, it stopped some of the repetition of the same figures appearing at articles they’ve never edited before and have no interest in, that would certainly be worth looking into. - SchroCat (talk) 20:31, 21 March 2024 (UTC)

I think 1 is the best option by far and part of why I find this discussion valuable regardless of the top-line outcome. Part of the issue I've seen is that most of the arguments regarding infoboxes generally were spread across RfCs spanning years and in non-standard locations. Even when I tried to get a comprehensive list, this project-wide discussion pointed out that there were still some I missed despite my best efforts. It's really hard to draft good guidance when opinions are that spread out, even harder when having a project-wide discussion is viewed as taking a side. Personally, I think there's a very different stroty being told in the rationales compared to the bolded !votes. The note about stubs has been met with suspicion, though a number of editors point out issues with short articles. Others take issue with infoboxes that are restatements of the lead, and that tends to mesh well with the point about short articles. On the other hand, there's some argument that for certain topics (biological taxa were brought up as one example) this concern is not as much of a problem. This seems tied into the sub-discussion about topics well-suited to "structured data". So while "stubs" (as in the proposal) probably won't find consensus because it oversimplifies these issues, there are coherent threads in the discussion that I think could lead to guidance, especially if the drafting process was more than one guy reading two years worth of RfCs and throwing out an idea. — Wug·a·po·des 00:00, 22 March 2024 (UTC)

I too think that, if the original proposal fails to reach consensus, option 1 is the best alternative to pursue. Gawaon (talk) 07:22, 22 March 2024 (UTC)

Option 1 isn't really a proposal though. The only way to find enough support is to convince the editors who don't think there's an issue or people who think this is CREEP. It's going to be difficult to accomplish since there's a sizable bloc that will fight it. The first oppose vote here was accusing the proposer of canvassing right out of the gate. It's a tough crowd. Nemov (talk) 12:55, 22 March 2024 (UTC)

And one of the supporters was uncivil enough to describe people as "a handful of powerful contrarians" simply for having a differing opinion. What's your point? Given we're talking about a small proportion of articles, and given most people are in broad agreement that most IBs work in most areas (broadly speaking), why is there a need for the wording to change? - SchroCat (talk) 13:15, 22 March 2024 (UTC)

Because, as S Marshall in particular has pointed out, actually closing discussions on controversial cases is more difficult when our policies and guidelines pretend like there's no guidance to actually give. If we look at the discussions from the past 2 years and also the opinions in this discussion, there are considerations that have broad agreement, but since we don't document it closers either need to be familiar with years of precedent (to have a sense of the lines of argument that repeatedly crop up in these debates) or count heads (giving everyone equal weight since policy says it's a free-for-all). The first means decisions are arbitrary depending on what kind of closer you get for that particular RfC, and the second means we reward editors who use filibuster or stonewalling tactics until they get the right turnout for their preferred outcome. While the topic area may be small, having RfCs every few months to see which faction shows up most or which closer we get this time takes up a disproportionate amount of time from other volunteers. — Wug·a·po·des 20:35, 22 March 2024 (UTC)

Then put a moratorium on opening RfCs on IBs. Stop the same group of editors who are uninterested in the subject matter but turn up and are disruptive and abusive regardless of which article it is. That’s where the disruption starts and continues: the ongoing crusade by a small group to keep pushing and pushing and pushing. - SchroCat (talk) 20:47, 22 March 2024 (UTC)

There is also an ongoing crusade by a small group to maintain the status quo, of which you are easily the most vocal member. Don’t call the kettle black. Dronebogus (talk) 02:36, 24 March 2024 (UTC)

Oh dear. A crusade is action for change, not retaining quality. - SchroCat (talk) 06:35, 24 March 2024 (UTC)

I know about the pedantic definition of “crusade”, I was trying to make a rhetorical parallel. What’s the inverse equivalent of a crusade? Dronebogus (talk) 06:54, 24 March 2024 (UTC)

It’s not pedantic, it’s just having standards. If people were on a “crusade” it would involve the mass removal of IBs, which doesn’t happen, even in the most laughable cases because someone normally reverts, despite how ridiculous the box actually is. (If you want to find a word or the proper meaning of on, a dictionary or thesaurus are ideal companions: I recommend them to you.) - SchroCat (talk) 07:15, 24 March 2024 (UTC)

I deleted that; I think an infobox with zero parameters in use and no available data besides “occupation” is objectively useless and in this case created a wall of cruft in the code. So yes, even I think infoboxes that cannot provide any info whatsoever are of no benefit. Dronebogus (talk) 07:34, 24 March 2024 (UTC)

1 seems obvious and more importantly sane. 2 is basically “WP:OWNership is good”, 3 doesn’t make any sense (why GAs, which are simply articles of above-average quality, vs FAs, the highest standard an article can be? And even then what’s so great about an arbitrary status quo besides “somebody must’ve knew best at review”?), 4 is just entrenching the balkanization problems I mentioned in the main discussion and 5 is stated in the proposal to be a “bureaucratic nightmare” which is why the current proposal is floundering in the first place. Dronebogus (talk) 12:26, 22 March 2024 (UTC)

I oppose #4, as inconsistent with the Wikipedia:Advice pages guideline – a guideline that exists because everyone got sick of WikiProject Composers claiming that they were exclusively in charge of deciding whether infoboxes could be added to "their" articles. Wikipedia talk:WikiProject Composers/Infoboxes RfC resulted in an agreement that they did not own articles and could not insist that other editors abide by their group's preferences, though their members were, and still are, free to make compelling arguments against disinfoboxes (closing summary for the RFC is at the end of the page; see, e.g., "WikiProjects are free to publish guidelines and recommendations but do not have the authority to override a local consensus on the talk page of an article").

Even before this, the Wikipedia:Consensus policy said things like "Consensus decisions in specific cases do not automatically override consensus on a wider scale - for instance, a local debate on a WikiProject does not override the larger consensus behind a policy or guideline. The WikiProject cannot decide that for the articles within its scope, some policy does not apply, unless they can convince the broader community that doing so is right."

We should not go backwards on this point. Self-selected, self-appointed groups of editors do not get to make rules affecting anyone else. WhatamIdoing (talk) 23:03, 23 March 2024 (UTC)

It still seems like most of WikiProject:composers (or at least a vocal plurality) still thinks that way, despite having their ability to exercise such authority curtailed. WProject Gilbert and Sullivan is even worse about this. At least Wproject Opera seems to have come into the modern era. Dronebogus (talk) 02:43, 24 March 2024 (UTC)

Oh, I thought "Self-selected, self-appointed groups of editors do not get to make rules affecting anyone else" referred to you and your pals on Discord. Johnbod (talk) 02:54, 24 March 2024 (UTC)

I haven’t even touched discord ever in my life. Dronebogus (talk) 02:57, 24 March 2024 (UTC)

WhatamIdoing, you say "Self-selected, self-appointed groups of editors do not get to make rules affecting anyone else" and that's clearly right, and I agree it means option 4 above is impossible. I think, though, that the various VAR and RETAIN guidelines could be considered an exception to what you say -- which is probably why some editors dislike them. Those guidelines make it clear that they don't provide "unchallengeable primacy" to the early versions of the article, but in practice, for an actively maintained article, VAR and RETAIN are treated as rules to follow. That means that when an RfC happens on the style of an article, most outside opinions will !vote for the continuation of the original style if they feel RETAIN applies. Any rule that prevents arguments over infoboxes would probably have to look like an INFOBOXVAR (i.e. 2 or 3 above) or a global rule to always include infoboxes on certain classes of article. That's not necessarily an argument for creating either rule. Instead I'd say we have to decide what we want: if we don't choose either a 2/3 rule, or a consensus to always include infoboxes, we should not be surprised if the arguments continue to chew up editor time. I don't think option 1 above has much chance of being precise enough to resolve the arguments, and that's the only reason I can think of for adding more rules in this area. Mike Christie (talk - contribs - library) 13:09, 25 March 2024 (UTC)

I think we could have a suggestion/recommendation to "follow the pattern used in articles with similar subjects". We just can't have one that says "WikiProject Getting My Way gets to decide whether this whole subject area gets infoboxes".

We will eventually end up with infoboxes as a standard, normal, expected, and default (but not mandatory) element. The only question is how long we will resist this. I just checked the 20 most recent articles in Special:NewPages. 85% of them already contain infoboxes. The oldest of them is just over one hour old. The three that don't contain infoboxes (yet) are two BLP athletes and one televisions show. I realistically expect Template:Infobox sportsperson and Template:Infobox television to be added as soon as any interested editor notices the omission.

If we want to prevent editors from wasting time arguing over it, then I think the thing to do is to accept that infoboxes already exist in more than half the articles, and will be added to even more as time goes by. The discussions might be a waste of time, but the evidence above indicates that they never end up with a true consensus to exclude the infobox. Maybe the way to solve this problem is to stop resisting infoboxes. It is a losing war. WhatamIdoing (talk) 17:48, 25 March 2024 (UTC)

85% of them contained infoboxes within the first hour, and two of the remaining three picked up infoboxes shortly thereafter. WhatamIdoing (talk) 23:52, 25 March 2024 (UTC)

I don’t think it is a case of “resisting” infoboxes in general, it’s more a case objecting to infoboxes in specific articles. It is true that infoboxes are helpful and appropriate in most articles. BUT… we will never get rid of all argument, because it is also true that there are a few articles where having an infobox causes problems (problems that are resolved by simply omitting an infobox). As long as the guidance allows us to omit when there is consensus to omit, I don’t think many would object to a statement that says they are deemed appropriate in most articles. One size does fit most… just not all. Blueboar (talk) 00:14, 26 March 2024 (UTC)

I wouldn't want to see an infobox in every single article, either. However, I think we do have a minority of editors who strongly object to what they see as Wikipedia:Disinfoboxes, and whom I would expect to object to any change that might make it harder for them to exclude infoboxes from the articles they care about. Even something like "Infoboxes are deemed appropriate in most articles", or a purely factual and undeniably true statement like "As of 2024, infoboxes are present in a majority of articles" could make it harder for them to "resist" the "invasion" of infoboxes in the remaining minority. WhatamIdoing (talk) 02:11, 26 March 2024 (UTC)

But “As of 2024, infoboxes are present in a majority of articles” would be a lie. You can’t claim something in the MOS that’s not true, let alone not “undeniably true”. According to the figures at the top of this thread, it’s 45 per cent, which isn’t a majority, your statistically insignificant sample of ten articles notwithstanding. (Of most recent 20 pages I checked, seven did not have IBs, including FOUR biographies.) - SchroCat (talk) 04:12, 26 March 2024 (UTC)

Did you write them, or were they stubs, or both? Dronebogus (talk) 19:38, 29 March 2024 (UTC)

New draft ideas

Option 1 states that a new proposal should be developed to improve on the current RfC. But currently there’s not even a rough outline of what that might look like. Any ideas? My personal suggestions would be to qualify that biographies should generally have infoboxes if they have a birth date and death date (since infoboxes are an established and efficent format for providing “current age/age at death” due to auto-calculating templates), or at least three non-controversial parameters in total (which is a good metric for “is this useful?”, similar to the “three sources” minimum for notability). Dronebogus (talk) 07:50, 24 March 2024 (UTC)

Or leave out biographies altogether as being a contentious area and have wording that reflects that in some areas (such as films) they are considered the norm. - SchroCat (talk) 08:16, 24 March 2024 (UTC)

Well, it's also useful to have the circa year(s), even eras they were born and died (for some even the century or centuries.) One reason for the layout of infobox's is to quickly highlight, 'who what when where how why', and circa numbers do that too.

Also, since what the infobox does, if it does nothing else, is box an image (for articles that have images -- and 'almost all' editors seem fine in general with a picture in some kind of box upper right - a picture is worth a thousand words, they say) together with the bolded title, boxing the image that way is also fine, since it is boxed one way or another anyway, and it also serves, who or what information purposes. (Although, either way, we should mandate for such pictures to the extent possible, tell the reader when it is.) Alanscottwalker (talk) 08:36, 24 March 2024 (UTC)

This is going to be a bold suggestion: sometimes it does not matter as much when a person may have been born, or equivalently it is not adequately reflected in sources. It's common for people to add "Xth century" as a birth date to articles for figures from antiquity, simply WP:BLUEing it—despite the figure having no attested birth date or even more specific estimate in the sources. I don't think this is lying or a real net negative, but it's frankly not a net positive: if it has to be derived, it probably shouldn't be in an infobox. It reflects the reflex that infoboxes must exist and be populated to a certain degree, which is not the case unless you buy the argument from least astonishment above, which I do not. Remsense诉 14:13, 24 March 2024 (UTC)

I don’t think they should be used if they can’t be populated. But if you can populate them with reliably sourced facts and refuse to based on tired non-arguments like “redundancy” or “status quo” or “liberal arts something whatever”, that’s where I have a problem. Dronebogus (talk) 15:07, 24 March 2024 (UTC)

"non-arguments" = WP:IDONTLIKEIT. Just because you don't like other people's opinions, you don't get to ignore their input. They are entirely valid, despite your inability to accept them as such. - SchroCat (talk) 15:23, 24 March 2024 (UTC)

Okay, I’ll replace “non-arguments” with “bad arguments”. Dronebogus (talk) 05:49, 25 March 2024 (UTC)

My previous comment still applies. - SchroCat (talk) 06:01, 25 March 2024 (UTC)

I think redundancy as an argument really matters—it's ultimately based in WP:NPOV, in my view. What information you display about a figure first reflects POV, as does how many times you state information. I don't really have much else to say though, since you simply do not see it as enough of an issue qualitatively, which I've no further argument against and will have to chalk up to "reasonable minds may differ". C'est la vie. Remsense诉 16:31, 24 March 2024 (UTC)

You did not make a "bold suggestion", you stated a non sequitur. No one is advocating adding information that's "not reflected in sources." As for a sourced date being NPOV, that is rather the purpose of writing what sources say. -- Alanscottwalker (talk) 05:09, 25 March 2024 (UTC)

I'm saying that is what often happens when infoboxes are thought of as fundamental to an article. Remsense诉 07:06, 25 March 2024 (UTC)

No, you don't need an infobox, at all, to add anything to an article, let alone whether the box is "fundamental" or not, which means your so-called fundamentality cannot matter. -- Alanscottwalker (talk) 12:16, 25 March 2024 (UTC)

I agree with that, but am confused what you are disagreeing with me about. Remsense诉 12:59, 25 March 2024 (UTC)

I am too. Dronebogus (talk) 13:00, 25 March 2024 (UTC)

I am disagreeing that anything needs to be seen as "fundamental" for your parade of horribles to happen. -- Alanscottwalker (talk) 13:28, 25 March 2024 (UTC)

Sure, it's a matter of degrees. Remsense诉 13:35, 25 March 2024 (UTC)

"Is this useful" is highly subjective, as opposed to "is this a key fact", which is written into WP:INFOBOXPURPOSE. Some templates have a ton of parameters. Some would argue that because there is a parameter, it must be useful. This then leads to bloat because some editors try to write the article in the infobox rather than considering the maxim at INFOBOXPURPOSE that less is usually better. Cinderella157 (talk) 03:18, 25 March 2024 (UTC)

Yes, I agree. Dronebogus (talk) 04:32, 25 March 2024 (UTC)

Quibble your certitude about "key" as opposed to "useful", surely key facts may be considered useful, but one supposes it really matters how you are using those terms. But all infoboxes can be edited down to say, a picture field and a caption field, or any other way, which is why infobox purpose can even suggest, less is more. Alanscottwalker (talk) 12:40, 25 March 2024 (UTC)

What you’re describing is patently not an infobox, it’s an image. Reductio ad absurdum or not, that’s a very bad argument. Dronebogus (talk) 12:46, 25 March 2024 (UTC)

No it's not. It's a box with information in it (images are information), so rather quod erat demonstrandum. Alanscottwalker (talk) 12:55, 25 March 2024 (UTC)

An infobox means something specific on Wikipedia and you know it. Dronebogus (talk) 12:58, 25 March 2024 (UTC)

Infoboxes on Wikipedia are a flexible coding for rendering boxes with information. Alanscottwalker (talk) 13:02, 25 March 2024 (UTC)

We aren’t talking about picture captions in this discussion, I’m pretty sure. Dronebogus (talk) 13:07, 25 March 2024 (UTC)

Captions are regularly information fields in infoboxes, so quite obviously we are. -- Alanscottwalker (talk) 13:09, 25 March 2024 (UTC)

They are thought of as a reified part of the interface by most users. Remsense诉 13:09, 25 March 2024 (UTC)

If by reified you mean boxed information, than that's a distinction without a difference. But if by reified you mean summarizing information, than that's rather a general purpose for an encyclopedia. -- Alanscottwalker (talk) 13:20, 25 March 2024 (UTC)

Closing?

It’s been two days since the last vote, and three days since the last meaningful non-vote edit. The discussion has clearly stalled without anything resembling progress towards a consensus or new draft and votes seem to lean oppose. Even if there were suddenly a dozen “support” votes the community clearly is too divided to agree on any change to the current guidelines. The discussion has been open for two weeks so I think that’s plenty of time for people to submit their opinions. I think this should be closed as no consensus for change as currently drafted; no prejudice to different or revised drafts. Dronebogus (talk) 19:55, 29 March 2024 (UTC)

Aye, seems no consensus. Remsense诉 21:05, 29 March 2024 (UTC)

It's only been two weeks? It feels much longer. There is clearly no consensus, but that will serve as a useful confirmation that it is NOT the case that infoboxes are expected/encouraged/mandated for all articles, and in particular all biographies, an argument that is often voiced in discussions. Johnbod (talk) 05:21, 30 March 2024 (UTC)

• Although there isn't consensus, I think we've learned a lot. We know there are a lot of objections about biographies and historical topics. We suspect there's almost no opposition at all to infoboxes about chemical elements and compounds, drugs, modern settlements, modern nation states, species, rail stations, stars, and other things with heaps of reliably-sourced quantifiable data. I think that's progress.—S Marshall T/C 10:56, 30 March 2024 (UTC)

  Agree—to explicate my own position, seeing as I've definitely presented an infobox-skeptical stance—when we make some element 119 and 120, those should almost certainly have infoboxes. The fact that they already do is cute and unobjectionable, but definitely when they do exist, infobox updated pronto. Remsense诉 13:17, 30 March 2024 (UTC)

• Votes are still coming in, so it makes sense to let this run a while longer before an experienced closer determines what we have learned. While there may not be sufficient consensus for the new wording as suggested here, there also seems to be very little consensus to just let the current text stand as it is. Gawaon (talk) 11:29, 30 March 2024 (UTC)

  I think the biggest problem I have with current guidelines is that there’s no good advice provided when an article should have an infobox. That’s why I’m frustrated with the status quo as well, at least in regards to biographies— there are actually good reasons for certain biographies not to have them, chief among them lack of verifiable information. But the current situation is based mostly on arbitrary user preference mixed with equally arbitrary unofficial guidelines. The situation is basically identical between Ludwig van Beethoven and Claude Debussy, yet one had enough votes to get a box and the other didn’t. That’s not a workable precedent. I think the guidelines should say “if a category of article typically includes an infobox, there must be explicit, article-specific reasons to exclude it”. Dronebogus (talk) 13:32, 30 March 2024 (UTC)

  I agree. There is really no good reason why Debussy doesn't have an infobox – certainly we do know enough to create one for him! With some people from antiquity or others about whom very little is known, on the other hand, that's indeed not the case and they might best stay without an infobox. Gawaon (talk) 14:43, 30 March 2024 (UTC)

  There are good reasons and they’ve been explained on that talk page. I think what you mean is that you don’t like the reasons, which is rather different. - SchroCat (talk) 16:36, 30 March 2024 (UTC)

  The issue is that there's nothing in policy or guidance one way or another, which leads to the acrimonious discussion seen in the area. Rather than pushing one side or the other it could be useful if guidance was given on why or why not an infobox should be used. This wouldn't settle the arguments, but would at least ground them in something more solid that like/dislike. -- LCU ActivelyDisinterested «@» °∆t° 17:12, 30 March 2024 (UTC)

  The way I see it, the current situation is “two people give two answers to the same situation; the correct one is whoever got there first”. The ideal situation would be “two people give the same answers to the same situation, because there’s a guideline”. And the guideline would look like the one I formulated above, and be part of the MOS, not some unofficial dogma that obviously isn’t true like “infoboxes are particularly unsuitable for liberal arts biographies” (if that’s the case why do tons of said biographies have them?) Dronebogus (talk) 17:31, 30 March 2024 (UTC)

• Probably time to wheel out once again my comment from 2018: "there are types of articles where we normally have infoboxes, and types where we don't. There is absolutely no evidence that "there is a certain expectation on the part of readers" that all articles should have one, nor do I believe this is the case. The great majority of article types fall fairly neatly into one group or the other, but some types, for various reasons, get caught in the middle, and it is here that disputes are concentrated. The articles suited to infoboxes are about discrete things, whether people, places, taxa, events etc, where the important things to know about the subject are a) the same for other members of that class of thing, b) objective facts that are straightforward to verify, and c) clear and easy to state. The types of articles not suited to infoboxes are those where any of these three factors is not the case, which includes most articles on broader topics and concepts, but also some on things (like people of certain types)." Johnbod (talk) 03:40, 31 March 2024 (UTC)
• Agree As I have stated before, I believe that sports and politician bios can benefit from infoboxes, but on the other hand, as a Signpost report noted: "Infoboxes may be particularly unsuited to liberal arts fields when they repeat information already available in the lead section of the article, are misleading or oversimplify the topic for the reader". Infoboxes in such articles misleadingly emphasize less important factoids, stripped of context and lacking nuance, whereas the WP:LEAD section can emphasize and contextualize the key facts about the subject. -- Ssilvers (talk) 03:54, 31 March 2024 (UTC)

  A signpost report(!) from 10 years ago, that you like citing as gospel. I don’t debate that the lead contextualizes facts, but literally nobody has ever suggested replacing the lead with an infobox. This isn’t a zero-sum game. Articles can, and do, have leads and infoboxes. Dronebogus (talk) 13:30, 31 March 2024 (UTC)

March 2024 (UTC)

• I admire the determination, but these are still "I don't like it" vs. "I like it" arguments. Those assessments can be saved for the next RFC which inevitably feature many of these editors. If the will of the community is to settle these discussions one by one so be it. There can't be many of these articles left at this rate. Nemov (talk) 10:12, 31 March 2024 (UTC)

Again, infoboxes are a rather Wikipedia-specific construction. We don't really have external validation or corroboration to work with, so unfortunately we have to use our brains on this one, though we usually live and die by V and NPOV. Remsense诉 10:15, 31 March 2024 (UTC)

Agree. There’s also no research on readers’ appetite or desire for boxes. Lots of claims from people on both sides of discussions, but zero actual evidence evidence or research on this. - SchroCat (talk) 12:33, 31 March 2024 (UTC)

With that said, I will concede that if readers are of the same species as editors, I think that it's extremely likely that many readers love the hell out of infoboxes—inconclusive and anecdotal evidence, but a lot of it. Of course, whether they learn better from them is an interrelated but distinct question. Remsense诉 12:50, 31 March 2024 (UTC)

Radical suggestion here maybe, but what if we actually rigged up some kind of poll that asks “do you like infoboxes” and “are they useful to you”? Dronebogus (talk) 13:31, 31 March 2024 (UTC)

Hey sure, why not. Seems like it would be really interesting and useful if we got 10k reader responses to a 5-minute feedback poll. Remsense诉 13:50, 31 March 2024 (UTC)

Seems like a lot of hoops to jump through to get to the obvious conclusion. Most people like the ability to find a quick summary of information in an infobox. The general cycle of these discussions on individual articles goes like this... a random editor sees a large article without and infobox. They boldy add one.[5] It's reverted with a note "find consensus in talk."[6] If they take the next step and create a discussion, they'll be greeted by the the usual chorus of "we don't like it" from many of the editors here and then the same "we like it" from the other group. The discussion will end there or someone will create a RFC. The casual editor, who thought it was an improvement will likely just move on. It's not worth the bureaucratic red tape. Is this good for the project? Does it make information easier to find for readers? The answer seems obvious, but sometimes what is obvious isn't obvious to everyone. Nemov (talk) 14:28, 31 March 2024 (UTC)

In before “but you can’t PROVE it!” Dronebogus (talk) 14:32, 31 March 2024 (UTC)

Seems like a lot of hoops to jump through to get to the obvious conclusion.

Nah, we like verifiability on Wikipedia if we can get it. Obvious to you, maybe, but maybe we can get additional useful insights from something like this. 's worth a village pump discussion. Remsense诉 14:45, 31 March 2024 (UTC)

Readers and editors are different beasts entirely. Look here for the question by a reader about a picture of a naked child in an article. Knee-jerk reaction for the first respondent about CENSORSED before admitting they hadn’t bothered looking at the article. Another editor being bloody rude to them. Editor response is on a completely different path to reader reaction, so I’m not convinced the IB radicalisation of some parts of the community will equate to what readers actually want. - SchroCat (talk) 14:01, 31 March 2024 (UTC)

I think it's more precise to say that editors are a beautiful, rather specific cultivar within the reader family. Remsense诉 14:07, 31 March 2024 (UTC)

I agree they are a sub-group, but that’s the point: they don’t represent all readers, just a very specific offshoot, and the two are very different! - SchroCat (talk) 14:35, 31 March 2024 (UTC)

SchroCat, drop the freaking WP:STICK on that WP:OTHERCRAP Dronebogus (talk) 14:09, 31 March 2024 (UTC)

I have zero idea what you’re talking about and have even less interest. - SchroCat (talk) 14:35, 31 March 2024 (UTC)

The incident you just brought up? Dronebogus (talk) 14:38, 31 March 2024 (UTC)

I brought up the discussion and the two examples of editors dealing badly with readers for the reasons in my comment, about the difference between the two. Note that I didn’t name either editor, because naming and shaming was not the point - only the gulf in outlook and expectations between a reader and an editor. You pushing the point about you being the very rude editor is a great example of the Streisand effect. - SchroCat (talk) 15:10, 31 March 2024 (UTC)

Well it’s not exactly hidden if you linked it Dronebogus (talk) 15:39, 31 March 2024 (UTC)

https://meta.m.wikimedia.org/wiki/Research:Which_parts_of_an_article_do_readers_read Moxy🍁 03:00, 21 May 2024 (UTC)

As has been explained to you before, this does not show what you want it to show. It doesn’t prove that IBs are useful, but that they are a distraction. This backs up numerous other eye tracking studies that show the human eye is always drawn to non-textual elements on a page. It doesn’t answer the question of whether they are wanted, beneficial or useful. - SchroCat (talk) 03:35, 21 May 2024 (UTC)

I would say it doesn't prove either cleanly. Remsense诉 03:38, 21 May 2024 (UTC)

Extended content

The argument that this data proves "that they are a distraction" is rather humorous. Very much in the spirit of Fox Mulder and "I want to believe." Nemov (talk) 12:57, 21 May 2024 (UTC) It makes more sense than the spurious claim that it somehow demonstrates readers want IBs. That's less humorous and more derisible. It doesn't matter how many times that particular lie is squashed, but desperate claims keep beep being rolled out. - SchroCat (talk) 13:03, 21 May 2024 (UTC) The truth is out there. Nemov (talk) 13:09, 21 May 2024 (UTC) But intelligence and maturity seems to be lacking here. - SchroCat (talk) 13:12, 21 May 2024 (UTC) For someone who pretends to act like this discussion is "tiresome" and "childish"[7] you certainly like to respond. If you really want others to believe that this discussion is beneath you a simple way to accomplish that would be to move along. Nemov (talk) 13:22, 21 May 2024 (UTC)

• The main area of disagreement appears to be biographies, maybe extra advice could be added for other areas and for how to handle details in infoboxes that are controversial/disputed. -- LCU ActivelyDisinterested «@» °∆t° 12:01, 31 March 2024 (UTC)
• It’s a shame that some quite blatant canvassing has taken place. I don’t think it will affect the end result, but I think we can, and should, ignore the votes of those pinged. - SchroCat (talk) 16:40, 5 April 2024 (UTC)
• Comment from potential closer: I'm willing to close this, although as I participated in a single RfC on adding an infobox to a specific article I want to ask if any editor sees me as involved before I do so; please see this discussion at Closure Requests for more details.

If there are no reasonable objections in the next couple of days, either here or at the closure request, I will proceed to close the discussion, unless someone else gets to it first. BilledMammal (talk) 02:39, 21 May 2024 (UTC)

As your close would be a non-admin closure, does the outcome seem clearly unambiguous and unlikely to be controversial (i. e. unambiguous consensus for a certain outcome)? Hydrangeans (she/her | talk | edits) 04:02, 21 May 2024 (UTC)

It is unambiguous that there is no consensus here to change the MOS, as various people who voted on both sides have acknowledged above. -- Ssilvers (talk) 04:06, 21 May 2024 (UTC)

This has been listed on WP:CR for a while now, and no admin appears to be interested. I see no reason why a non-admin could not close this, regardless of what that essay says. Charcoal feather (talk) 12:15, 21 May 2024 (UTC)

WP:BADNAC is part of WP:Non-admin closure, which is an information page, not an essay. While essays offer advice that is generally from a point of view, information pages supplement or clarify technical or factual information about Wikipedia impartially. Hydrangeans (she/her | talk | edits) 06:24, 22 May 2024 (UTC)

The status of the page doesn't really matter (but see Wikipedia:The difference between policies, guidelines and essays if that subject interests you). What matters is that sensible humans don't want to be the target of wrath, and however you close it – for, against, or neither – somebody's likely to be angry. Any NAC who writes a summary statement is a NAC who can expect to be lectured about BADNAC as well as giving The Wrong Answer™. WhatamIdoing (talk) 07:31, 22 May 2024 (UTC)

Somebody changed that from essay to info page a month ago; I just reverted it. Levivich (talk) 21:50, 22 May 2024 (UTC)

One of the problems with infoboxes

Raid on Tendra Spit
Part of the Russian invasion of Ukraine
Date 28–29 February 2024 Location Tendra Spit, Black Sea, Russian occupied Kherson Result Russian victory
Belligerents
Ukraine	Russia
Commanders and leaders
Col. Serhii Lupanchuk	Vice Admiral Vladimir Vorobyov Vice Admiral Sergei Pinchuk
Units involved
Special Operations Forces 73rd Naval Center of Maritime Special Operations	Baltic Fleet Black Sea Fleet
Casualties and losses
20–25 killed 1 captured 3 landing boats sunk 1–4 landing boats captured	2 wounded

I am not inherently against infoboxes when their construction is well executed. But all too often, we see boxes that are way too bloated because editors try to write the article in the infobox and/or they are populated with dubious "facts" (as in the example). The example is from a small boat operation conducted by Ukrainian special forces in five RHIB assault boats. They were opposed by no less than two Russian fleets commanded by two admirals. Of the five boats deployed, seven were captured or sunk and one managed to escape! The Ukrainians were apparently commanded by Col. Serhii Lupanchuk, who isn't in the source cited and probably wasn't in any of the five (or is that eight) boats. Perhaps he is the ghost of one of the casualties.

But not only do we get crap like this, we get editors reinstating it! Cinderella157 (talk) 00:52, 3 April 2024 (UTC)

I think this is a case of “then remove the unsourced material”. And if editors are reinstating bad content that’s known as “disruption”. But I don’t get how “some infoboxes are poorly cited crap” translates to “this is The Problem inherent to infoboxes”. Like, literally any form of content could have these issues. Dronebogus (talk) 05:00, 3 April 2024 (UTC)

I very frequently see conflicting information between infoboxes and the articles in which they appear, over time infoboxes tend to accumulate factoids that are not found or referenced in the article, and these factoids are almost always unreferenced in the infoboxes. -- Ssilvers (talk) 02:28, 3 April 2024 (UTC)

I don’t deny that’s true, but the infoboxes you most vocally oppose are not that. They’re biographical infoboxes with 4 or so objective, sourced, extremely basic factoids. Nobody seems to be working on widespread systemic errors in battle/war infoboxes but everybody acts like a composer getting one carefully designed to provide specific, useful information is sacrilegious. Dronebogus (talk) 05:10, 3 April 2024 (UTC)

what then should we do about the many poor infoboxes? You say, “Nobody seems to be working on widespread systemic errors in battle/war infoboxes”, so how do we encourage that to happen? Because presently there are lots of editors who focus on infoboxes over article content and vigorously defend bloated and unsourced infoboxes. Bondegezou (talk) 06:14, 3 April 2024 (UTC)

Are you trying to create some kind of myth? Who are these "lots", be specific. Alanscottwalker (talk) 11:12, 3 April 2024 (UTC)

I see a lot more editors fighting over the first sentence than focusing on infoboxes. WhatamIdoing (talk) 07:40, 22 May 2024 (UTC)

You don't hang out or watch arts biographies much, I think. Johnbod (talk) 14:49, 22 May 2024 (UTC)

@Bondegezou reminder that infoboxes have a CTOP designation and any editor engaging in disruptive behaviour to restore unsourced information into them can be taken to WP:AE provided that they've been given advice on their talk page prevoiusly of the CTOP designation. That some editors display behavioural issues concerning infoboxes is not an argument against their usage. TarnishedPath^talk 06:31, 28 May 2024 (UTC)

If you have a rule that is frequently broken, it is sensible to review that rule. Bondegezou (talk) 09:12, 28 May 2024 (UTC)

Uh, I guess that's what this RfC was all about? Making our rules/guidelines re infobox use better fit the actual practice. Gawaon (talk) 10:44, 28 May 2024 (UTC)

But on the whole it does reflect general practice, given less than half our articles have an IB in place. - SchroCat (talk) 11:16, 28 May 2024 (UTC)

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

Hokkien infobox

There's currently a discussion to establish consensus on aspects including layout and sourcing on the Hokkien article. Input from folks would be appreciated. Remsense诉 21:49, 10 May 2024 (UTC)

Inline maintenance tag

I realized this would likely be of considerable utility, so I've gone and quickly created {{Infobox clutter}}. I hope others find it useful! Remsense诉 04:23, 11 May 2024 (UTC)

Rule of thumb suggestion?

The less information it contains, the more effectively it serves that purpose, allowing readers to identify key facts at a glance. Of necessity, some infoboxes contain more than just a few fields; however, wherever possible, present information in short form, and exclude any unnecessary content.

While this is certainly rhetorically helpful, I've found that this explication doesn't help a lot of the time, as strictly speaking only moves the issue down a rung: clearly, many people have broader notions of what "necessary" or "key" facts are, or how brief a "glance" is. Keeping in mind I do not want to reduce the effective flexibility of editors, it seems a concrete addition may help. There are problems I can already ascertain with this addition, but it's a starting point, perhaps:

As rules of thumb: information that is not easily recalled by the reader after perusing the infobox for under a minute may be worth removing, and lists longer than five or six items may have room for trimming.

Remsense诉 22:55, 29 May 2024 (UTC)

This would still be an arguing point, with personal views of who retains what based on personal experience of editors familiar with the subject (and have therefore retained) rather than a blind test. On the other hand, if it is not supported by the body of the article (and the article does not remain complete without the infobox) it is clearly not a key fact. I would say, that just because a field exists in an infobox does not mean that it should be used in a particular article. That might be more useful. Apart from that, I don't think that we are going fix bloat by trying to be more prescriptive. It takes a concerted effort such as happened at (Napoleon or Syrian civil war) to say this is just beyond a joke. Perhaps we need a list of infoboxes in articles by size so that the community can actively scrutinise the worst excess? Cinderella157 (talk) 00:15, 30 May 2024 (UTC)

I think including a list of reference articles in the guideline might be a possibility. Remsense诉 00:17, 30 May 2024 (UTC)

I strongly disagree with your argument above. The shorter the infobox, the more effectively it might help readers to identify key facts at a glance. It is essential to exclude content that is not "key". I find this instruction to be extremely helpful. Any discussion of what is key, necessary and able to be understood "at a glance", and what is "possible", may require discussion at the article's Talk page, but that should be, at least, the aspiration. "Under a minute"? A geographical or political infobox could take many minutes to digest, while many biography infoboxes should take 10 seconds. And any time you put an upper limit on something, people will argue that they should be allowed to put in all the stuff you can put in up to that limit. It must be a case-by-case discussion based on common sense and experience. -- Ssilvers (talk) 01:33, 30 May 2024 (UTC)

These are all extremely good and welcome points. I plucked one minute completely out of thin air: I want to reemphasize my suggestion was a scaffold interrogating what kinds of suggestions could work, and nothing more. Remsense诉 01:52, 30 May 2024 (UTC)

Birthplace as proxy for citizenship and nationality

I'm assuming WP:INFONAT should be interpreted to include countries without jus soli birthright citizenship when it says that the "citizenship" and "nationality" fields are not necessary when "birthplace" is filled out and the country for all three is the same? If that's not right, please let me know; I intend to clean up any articles that don't follow that. -- Beland (talk) 19:36, 30 May 2024 (UTC)

I agree. Don't need more than one if they are the same. -- Ssilvers (talk) 20:44, 30 May 2024 (UTC)

Cool, I'll note that in the guideline for clarity. -- Beland (talk) 20:54, 30 May 2024 (UTC)

One caveat… take into account that a place may be part of different countries at different periods of history. For example, someone born in San Antonio, Texas in 1800 was born a Mexican, not an American. Blueboar (talk) 21:04, 30 May 2024 (UTC)

Sure; I would expect the country name to be given in the birthplace explicitly for cases like that. -- Beland (talk) 21:24, 30 May 2024 (UTC)

No. I strongly oppose the inclusion of countries without « jus soli ». For instance fr:François-Louis de Pesmes de Saint-Saphorin was born, and died, in the same Swiss town. But he was not Swiss, as there was no jus soli then (there still isn’t): he was a citizen of the Republic of Geneva, in which he never even lived. --Sapphorain (talk) 22:58, 4 June 2024 (UTC)

INFONAT does not preclude use of |nationality= when it does not match a person's birth country. —Bagumba (talk) 23:11, 4 June 2024 (UTC)

Sorry for the long message here, but I've been fixing a lot of articles to conform to WP:INFONAT, and have learned a lot about how these fields are used in practice. It would be nice to get a firm answer on whether or not the rule is going to change, because hundreds of thousands of edits are needed to bring articles into conformance regardless of what the rule is going to be.

Even for countries that do have jus soli, there are exceptions. For example, the children of foreign diplomats born in the United States, Native Americans before 1924, and people who have dual citizenship because they are the descendants of foreign nationals.

The alternatives I can think of:

1. Document citizenship for every single person, so when the field is missing, it can only mean that editors have not yet found sourcing and documented it (or it's a complicated case explained in the prose, if we don't change that rule).
2. Document citizenship for every person born in a country without jus soil or whose citizenship changed, does not match their birth country, or has dual citizenship. When the field is missing, it means either the country of birth has jus soil (but they may or may not be an exception) or that editors have not yet found sourcing and documented a citizenship mismatch or dual citizenship (or it's a complicated case explained in the prose, if we don't change that rule). Readers would be on their own to figure out which countries have jus soil.
3. Document citizenship only for people where it does not match their birth country or has changed. When the field is missing, it means either it matches the birth country and has not changed, or that editors have not yet discovered or documented a citizenship mismatch or change or dual citizenship, or it's a complicated case explained in the prose. (This is the current rule, before Sapphorain's revert and after the un-revert.)

I'd be interested to read if anyone would like to propose any other alternatives.

I assume the reasons we don't do (1) now are that this repeats the country name for 140,000+ biographies (I did a database dump scan) and perhaps over-emphasizes citizenship compared to other information in a "show me your papers" sort of way?

Documenting citizenship for everyone or more than half the world would require a lot of sourcing work. In many cases, I suspect whoever filled the citizenship field just assumed citizenship was the same as the birth country without confirming that or checking for dual citizenship or emigration or exception status. Maybe half the time the nationality field is filled out incorrectly, either simply duplicating the citizenship field or supplying their ethnicity instead of their legal nationality. I would want to require inline citations whenever these fields are used to protect against bad information, especially in BLP articles. Nearly all instances of the citizenship and nationality fields are currently without citations.

One way we could reduce incorrect use of these fields is to drop the nationality field entirely, and use the citizenship field for both citizenship and legal nationality. Needing to use nationality to indicate something other than citizenship is relatively rare, but for countries that make the distinction we should probably be careful to distinguish. So for example instead of just saying "citizenship=United Kingdom" we'd want to say "citizenship=British citizen" which has a differnt set of rights compared to "citizenship=British subject". If we care about which legal rights a person has, we'd also need to specify which colony they are attached to if they are not full citizens, for example "citizenship=United States national (American Samoa)" or "citizenship="British Overseas Territories citizen (Bermuda)". I've been operating under (3) and just making sure the colony name is mentioned in the birthplace, and that the article on the colony explains the citizenship/nationality status of people born there or links to an article that does.

A lot of people with Wikipedia biographies don't have books written about them, and unless their citizenship is notable in some way it's simply not mentioned in articles about them. Mentioning the countries they have lived in is a lot more common than specifying legal status if they have moved around. So even if we try to do (1) or (2), I'd expect to have a lot of blank citizenship fields, even more if we don't consider birth in a jus soli country to be proof someone isn't a diplomatic or dual-citizen or emigrant exception, and regardless for a lot of people in non-jus soli countries.

One of the nice things about (3) is that it greatly simplifies the infobox in certain complicated situations, and avoids a lot of disputes and factual errors that require us to become amateur immigration lawyers to figure out, which skirts the boundary of original research. For example, I came across someone born in the New Hampshire Grants in colonial British America. Technically, I think they were indisputably a British subject before 1776, then after the Declaration of Independence either a citizen of New York or New Hampshire, both of which claimed the territory. Then in 1777, the Vermont Republic declared independence, but it wasn't recognized, so there was a third citizenship claim. Even worse, the British continued to assert Americans were British subjects after 1776, and even after the 1783 Treaty of Paris ended the war, adding a fourth claim. Vermont became a state under the U.S. Constitution in 1791, and which I think made everyone there U.S. citizens, though that may depend on whether or not the U.S. Congress had yet passed a uniform nationality law. Recapitulating all this history by listing all the citizenships a person has had seems a bit much for a biography infobox. With (3), I can just say they were born in the New Hampshire Grants and if you care about their citizenship you can go and read about the sovereignty changes for that territory. Presumably any notable changes in citizenship that did not follow the changing sovereignty of the territory would be noted in the prose, which is where the current rules says complex cases should be explained.

Likewise, some colonies (e.g. Puerto Rico, Bermuda) have had different levels of citizenship and nationality extended to them at various times, sometimes retroactively, so to accurately describe a person's citizenship, we'd need to take their birth date and plug it into a timeline of nationality law changes for their birthplace, which might also require us to figure out where they were living when and the nationality of their parents. I came across another biography where someone was born in Puerto Rico just before the Spanish-American war. Based on Puerto Rican citizenship and nationality, it seems they were a Spanish subject for a while, then probably a stateless U.S. national, then probably a U.S. national and citizen of Puerto Rico, and then for people living into the later era of retroactive and birthright citizenship for PR, U.S. citizens to whom the constitution only partly applies, weirdly unless they move to a U.S. state. It was kind of nice to effectively just have the infobox say, they were born in Puerto Rico when it was part of the Spanish Empire and died in Puerto Rico when it was part of the United States; you can figure out the rest if you care and it's explained in the prose if it's important.

-- Beland (talk) 02:29, 5 June 2024 (UTC)

FTR, for an English-language article where removal of citizenship was disputed by Sapphorain, we have Charles Bonnet. -- Beland (talk) 02:32, 5 June 2024 (UTC)

Was disputed, and still is. And a real consensus should be reached in order to include the countries having jus soli in this rule.--Sapphorain (talk) 06:59, 5 June 2024 (UTC)

I count six involved editors so far including myself; only you have spoken in favor of excluding those countries. Ssilvers has said they are in favor of inclusion. Would you be satisfied if the others explicitly express an opinion in favor of inclusion? Do you want an RFC? -- Beland (talk) 07:10, 5 June 2024 (UTC)

What? I don't know what you think I am in favor of. I am in favor of EXCLUDING nationality and citizenship parameters if they are the same country as the person's birthplace. We don't need more than one parameter if they are the same, and we should keep infoboxes concise. -- Ssilvers (talk) 19:51, 5 June 2024 (UTC)

Sorry for the confusing phrasing; I was saying you were apparently in favor of including non-jus-soli countries in the rule that excludes these parameters. -- Beland (talk) 20:02, 5 June 2024 (UTC)

OK, thanks. -- Ssilvers (talk) 20:16, 5 June 2024 (UTC)

For the record, as an editor not yet involved in the discussion I think that adding the phrase "including countries without jus soli birthright citizenship" is fine. It's sufficient to include the nationality if it can't be guessed from the country. Peoples born in Spain are probably Spanish, those born in Germany are probably German etc. Add the explicit info in cases where these "rules of thumb" are violated, but don't make it more complicated than that. Gawaon (talk) 07:36, 5 June 2024 (UTC)

Broadly agree with this. Also worth keeping in mind that the concept of citizenship has varied over time, I would be wary of anachronisms from too strict a guideline. CMD (talk) 07:48, 5 June 2024 (UTC)

Well, then there should be a number of exceptions for particular cases. For instance, in a former country in Europe where about 95% of the population didn’t hold any citizenship at all, does having no precision on citizenship mean the person’s citizenship « can be inferred from birth place », or does it simply mean this person was not a citizen anywhere?!--Sapphorain (talk) 08:00, 5 June 2024 (UTC)

What would you propose to do for that country, add "citizenship=None" for 95% of the biographies? -- Beland (talk) 08:09, 5 June 2024 (UTC)

No, I would simply keep or add the indication of citizenship for 5% of the biographies.--Sapphorain (talk) 08:13, 5 June 2024 (UTC)

… Besides, the people without citizenship rights in some country are very far from representing 95% of the people of that country that deserve a wikipedia page. --Sapphorain (talk) 08:19, 5 June 2024 (UTC)

If we don't consider it important enough to note that someone is a citizen of the country they were born in when that's true for 95% of people born there, why would it be important to say that when it's only true for 5% of people born there? Was citizenship equivalent to nobility status in modern European countries? (What country are we talking about here, anyway?) -- Beland (talk) 08:26, 5 June 2024 (UTC)

Oh, if you're talking about Canton of Geneva#Republic of Geneva (1534/1541–1798, 1813–1815), it looks like "citizen" there and then meant a child of a bourgeois, the latter being the only people with voting rights. That does not sound much like the modern concept of citizenship, and I think it would be confusing to use the citizenship field to indicate that status. I would file that under "complicated cases that should be explained in the prose" with a link to the above or other explanatory article. -- Beland (talk) 08:31, 5 June 2024 (UTC)

FTR, Sapphorain also reverted removal of the nationality field from Jean Senebier, which just said "Genevan". From the article linked above, it appears the Republic had four levels of membership, each with different rights: habitant, natif, bourgeois, and citoyens. "Genevan nationality" could mean any of these, and it could easily be inferred that someone has Genevan nationality because they were born in the city-state of Geneva. If this person's level of membership is unknown, it seems like this field should be dropped from his infobox.

I do agree that this social structure is interesting and deserves mention in these biographies, but it's sufficiently different than modern structures that it needs explaining.

Jean-Jacques Rousseau is a more high-profile biography, and I see that the infobox doesn't mention citizenship or nationality, but the prose explains (with citation) that Rousseau was a citizen of Geneva, and a bit about what that meant. Would anyone object to giving the same treatment to Charles Bonnet (if a citation can be found to support the claim of citizenship) and Jean Senebier (if his specific level of membership can be determined)? -- Beland (talk) 17:14, 5 June 2024 (UTC)

Including such situations as plain and unadorned "nationality" or "citizenship" in the infobox feels it might mislead modern readers. People don't even know about the weird odd cases such as various British passport types and the American Samoan situation where distinctions still exist today. CMD (talk) 01:28, 6 June 2024 (UTC)

If more detail/clarification is needed, it should be given in the article itself, rather than the IB. -- Ssilvers (talk) 02:20, 6 June 2024 (UTC)

Abolishing or disfavoring the "nationality" field

As mentioned above, after going through thousands of biography infoboxes, I've noticed that the "nationality" field is used for ethnicity maybe half the time. Sometimes it's ambiguous (e.g. "Cuban") but often it's disambiguated either by a link (e.g. targeting Cuban people or Cuban nationality law) or it's something like "African-American". This violates WP:INFONAT, and before making tens of thousands of fixes, I'd like to get consensus for a solution to prevent this from re-occurring, which will presumably the guideline.

I can think of two good alternatives - abolishing the "nationality" field, or keeping it but preferring the "citizenship" field - but I'm open to other suggestions.

If we keep the "nationality" field, to avoid confusion with ethnicity, I would recommend:

• Changing the field display name from "Nationality" to "National of", and possibly also changing the name of the template parameter to "national_of"
• Requiring that the value be a country name (e.g. "Cuba") or legal category (e.g. "British subject"), not a demonym (e.g. "Cuban")
• Specifying the territory they are connected to by their non-citizen status (e.g. United States (American Samoa), not "American"; same for citizenship e.g. "British Overseas Territories citizen (Bermuda)")

The vast majority of people are citizens of the country they are nationals of. Citizenship is generally more specific, so noting citizenship conveys more information and is less ambiguous. Saying that someone is a national of a given country doesn't necessarily imply that they are a non-citizen national. If we care about accurately noting the distinction for readers, we probably need to make non-citizen status more explicit. But if we're doing that in the display value anyway, it seems like there's no reason to keep two distinct fields, especially when one of them has a name that makes it prone to abuse. Formatting options I could think of:

• Give the legal status like "citizenship=United States national" or "citizenship=British subject", and assume the phrasing (and the linked article) makes it clear enough this person is not a U.S. or British citizen, in the legal sense. (wikt:citizen notes that citizenship also has non-legal meanings.)
• Explicitly note as non-citizen with something like "citizenship=None (United States national, American Samoa)" or "citizenship=United States national (American Samoa, non-citizen)".

Thoughts? -- Beland (talk) 21:30, 9 June 2024 (UTC)

For the vast majority of people, citizenship is a clear and simple attribute. Nationality has many, very diverse meanings. One of its biggest problems is that some people are certain they know what it means everywhere in the world. It's a dangerous descriptor to include in an Infobox, where a more detailed explanation isn't possible. Yes, I know we have footnotes and other tools to do that, but there is a never a guarantee that readers will follow such links. — Preceding unsigned comment added by HiLo48 (talk • contribs) 00:42, 10 June 2024 (UTC)

I think that "nationality" is a vague and unhelpful parameter. -- Ssilvers (talk) 00:11, 10 June 2024 (UTC)

Not sure what "citizenship" means, to be honest. Many countries are divided into "nations" e.g. the UK: I was born in Wales so I'm Welsh; I have Scottish parents so I'm Scottish; I lived most of my childhood in England making me English; or maybe I'm simply British. On the other hand, "nationality" refers to the country where you are a legal citizen. I'm torn here as the term is perfectly valid. How about "Citizen of" which sounds better than all the other suggestion so far, imo — Iadmc♫^talk  04:14, 10 June 2024 (UTC)

What concerns me there is your certainty that you know what nationality means, and that you believe that there is a single, universally agree meaning. There isn't. HiLo48 (talk) 06:49, 10 June 2024 (UTC)

Very few countries are divided like that, and as that consideration is not a legal one it is probably not something that should go in the infobox. It sounds like you are both a British national and a British citizen, which does not affect your personal or communal identity as someone from Wales, Scotland, England, or other. This is the case for most British nationals/citizens, although the UK is one of the places with a notable distinction between the two, eg. holders of BNO passports. The arisen confusion here between the legal concept of nationality and use as a term of self-identification is possibly another argument along with existing misuse towards the need for a change here. CMD (talk) 04:46, 10 June 2024 (UTC)

However, categories are often made like category:Welsh people which suggests that this is important to the subject more then category:British people. Should that person's nationality in the infobox be Welsh or British? — Iadmc♫^talk  04:56, 10 June 2024 (UTC)

BNO is a good point though — Iadmc♫^talk  04:58, 10 June 2024 (UTC)

Per MOS:INFONAT, the |=nationality field should not be used for most British people as they will have been born in the UK. When needed, the field would presumably say British, plus other citizenships. However, that is just for this specific infobox field; categories, lead/article prose, and even other infobox fields such as birthplace are areas of perenial discussion as to whether to include the UK nations (documented at WP:UKNATIONALS). CMD (talk) 05:11, 10 June 2024 (UTC)

I think what would fix the misuse of the |nationality= parameter is an actual |race-or-ethnicity= parameter. People are trying to put that information in the infobox, and they can't find the "right" thing, so they use whatever's closest.

If you want, we could program the infobox templates so that if the parameter gets used, it throws an ugly red error message about it being inappropriate content for the infobox.

If you don't want to go that far, we could probably code the template to reject or ignore specific common mistakes in the | nationality= parameter (e.g., "African American" or "Jewish").

More generally, there are really significant cultural differences around race and ethnicity. Some people think it's perfectly normal for everything you do to have some sort of racial or ethnic note attached to it. Some people think that it's valuable information for visibility and measuring our goals. And other people think that this information should be suppressed, so that no government has a handy way to figure out which people to round up during the next ethnic cleansing exercise. WhatamIdoing (talk) 06:50, 10 June 2024 (UTC)

I wonder how many other countries are like mine, Australia, where no questions are asked on the national census about either race, or ethnicity, or nationality? That means nobody has an official racial or ethnic label. (There is a question about ancestry. Around a third of respondents declare their ancestry to be Australian. Most of those people aren't Aboriginal.) In mentioning this, I'm not saying Australia's position is better or worse than others. I'm just highlighting the problem with defining these terms, and in assuming that there is any sort of international consistency in how these words are used. HiLo48 (talk) 06:59, 10 June 2024 (UTC)

According to the closing message, there was an overwhelmingly negative response to the idea of adding an ethnicity field in the 2016 RFC: Wikipedia:Village pump (policy)/Archive 127#RfC: Ethnicity in infoboxes. -- Beland (talk) 07:18, 10 June 2024 (UTC)

Yes. "Ethnicity" and "Race" feel racist to me. Just saying — Iadmc♫^talk  07:35, 10 June 2024 (UTC)

Note that I don't want an ethnicity field that actually works the way the other parameters work. I'm just saying that when people want to include that information and are looking for a place to stick it, the realistic options are:

• we give them a place that doesn't screw up the articles (e.g., by throwing a big red error message that says "Don't use this, because we voted in 2016 to never put race and ethnicity information in the infobox" or that refuses to let the page get saved, or something like that), or
• they continue to screw up the articles by shoehorning that information into an existing but incorrect field.

WhatamIdoing (talk) 02:53, 29 June 2024 (UTC)

If there simply aren't any fields that seem appropriate for ethnicity, I think that would solve the problem. It's not like people are going to shoehorn ethnicity into birth_date or something. -- Beland (talk) 07:31, 29 June 2024 (UTC)

I like the idea of keeping the "nationality" field as a honeypot and displaying a big red error message if anyone tries to use it, at least for a transitional period. In order to avoid widespread disruption of biographies, we'll want to remove the field (and add citizenship where needed) to tens or hundreds of thousands of articles. I'm currently working on biographies where both fields should have been omitted under the old guideline (where they were the same as the birth country). I'm doing countries with jus soli citizenship, but given the consensus in the previous thread was to include all countries in that rule, I'll do the non-jus soli countries next. Then I'll have to circle around and do the more complicated cases. If anyone would like to help, I can provide lists of articles; it's easy to zap them in a few seconds for most articles if using JWB or AWB. -- Beland (talk) 17:56, 12 June 2024 (UTC)

But note that, according to Nationality#Nationality versus citizenship: "Historically, the most significant difference between a national and a citizen is that the citizen has the right to vote for elected officials, and the right to be elected. This distinction between full citizenship and other, lesser relationships goes back to antiquity." – So maybe it would be better to allow continued used of the "nationality" field in cases where "citizenship" is not applicable? If we just straight out forbid the former, it seems very likely that the latter will very often be abused for it in cases where there actually was no citizenship. Using both in the same infobox can still be deprecated, since it seems there is no reason to do so. Gawaon (talk) 19:46, 12 June 2024 (UTC)

I'm writing this because of Beland's bold change to MOS:INFONAT today that "a |nationality= field should not be used." I must say I did not see that coming based on how the discussion went so far (there was a suggestion of changing it to "national_of", not dropping it altogether) and I do think that more deliberation is needed before such a change should possibly be made. Gawaon (talk) 19:53, 12 June 2024 (UTC)

Well, we certainly have plenty of time before I finish cleaning up articles under the old policy before I get to the new one.

There's not a clear-cut voting distinction across all countries between nationals and citizens. In the United States, for example, U.S. citizens who are residents of Puerto Rico cannot vote in federal elections, and non-citizen residents of some cities can vote for some local elections.

There are actually very few people whose nationality would be listed in an infobox...it would have to be someone with dual or naturalized citizenship or nationality, who is a non-citizen in at least one country. For example, someone who was born in American Samoa and also has Independent State of Samoa citizenship from parentage would be both a U.S. national (non-citizen) and Samoan citizen. What would you want to see in the infobox in such a case? -- Beland (talk) 20:48, 12 June 2024 (UTC)

Indeed. Beland's The vast majority of people are citizens of the country they are nationals of might be true-ish nowadays in the age of the nation-state, but it's not true of, say, much of medieval Europe. People were subjects of the monarch, not citizens. This even remained the legal situation in the British Empire until the 1940s, starting with the Canadian Citizenship Act, 1946 and the British Nationality Act 1948. Many people born outside Britain became British citzens with the right to settle in the UK and did so, transforming the country in many ways, until the law was changed again. NebY (talk) 20:51, 12 June 2024 (UTC)

All this is to say that we can never have a perfect solution to this. Citizenship is a much clearer word than nationality, which suggests ethnicity. As I indicated above, we should not have repetition, and if "citizenship" is given, it is because the person has moved out of the country of their birth, and it should be OK whether the person is/was a voting or nonvoting citizen, as long as they have qualified under the new country's citizenship laws, rather than just being a resident there. Further details and specifics, if needed, should be either described in the article or a footnote. -- Ssilvers (talk) 22:19, 12 June 2024 (UTC)

@NebY: Sure, but 1.) medieval and ancient biographies are a shrinking minority, because most records from that time have been lost, there were far fewer people alive, and new people keep being born, and 2.) for the vast majority of people who were non-citizen subjects of empires, we will omit both fields because status is inferred from the country of birth and either never changed because they never took an allegiance outside the empire or it changed along with almost everyone else in the country (e.g. due to independence). If how often we'd be using the field matters to whether or not we want to keep it, I can gather some statistics. I already have code that's looking at the birth century in these infoboxes to make cleanup faster. FWIW, I do know there are hundreds or thousands of people who should have been described as "British subject" by the nationality field who are instead marked with an ethnicity or colonial nationality like "Jamaican". We could help that by changing to national_of, though "National of British subject" looks more weird to me than "Citizenship British subject". -- Beland (talk) 23:19, 12 June 2024 (UTC)

FTR, looking only at British bios (including the Empire) where the nationality or citizenship field is redundant to the birth country, I see 73 (.5%) for people born in the year 2000 and later, 9191 (58%) for the 1900s, 3920 (25%) for the 1800s, and 2532 (16%) for all previous time periods. -- Beland (talk) 19:37, 13 June 2024 (UTC)

Turns out there were a lot of "unknown date" in that "all other time periods" stat. I fixed my code to report more carefully, and can report there were 924 (5.9%) from the 1700s, 515 (3.3%) from all previous time periods, and 1093 (7.0%) unknown year (mostly no birth_date specified). -- Beland (talk) 03:06, 15 June 2024 (UTC)

2¢ Per WP:INFOBOXPURPOSE, the infobox is for "key facts", a supplement to the lead and the article should remain complete without the infobox. Also, the infobox cannot capture nuance and anything in the infobox must be sourced one way or another (not OR). It is unfortunate that most infoboxes were not designed in a way that recognises these principles but more on the principle of how much can we cram into it. Consequently, they are then populated on the same principle with the view that, if there is a parameter, we should use it - like Napoleon before it was recently hacked back in size. I just looked at Guglielmo Marconi (not quite a random choice). The infobox tells us that he was born and died in Italy and an Italian Senator but also lists his nationality as Italian. The opening sentence states he was an Italian^[1][2][3][4] inventor [though the number of references suggest doubt]. Isn't nationality in the infobox redundant here? We also see from the discussions here there is quite a lot of nuance to nationality and citizenship and these are somewhat modern concepts (but not exclusively - after all, what have the Romans ever done for us apart from the aqueducts and ...). These terms are round holes that don't correspond neatly to reality in many cases. What is sometimes important is what they identified as (ie a demonym rather than more strictly defined terms). This may not be a constant over their life, which is nuance in itself. Some principles to consider for bios: If it isn't in the lead's prose, it probably isn't a key fact. If it is fairly self evident, it is redundant. If it isn't fairly self evident, it is probably too nuanced for the infobox. If their notability isn't intimately tied to their nationality (or any other such distinction we might make) it isn't a key fact. In short, we can probably live without all such terms in infoboxes and it would be for the better. Cinderella157 (talk) 01:08, 13 June 2024 (UTC)

So what’s the solution? What about cases where people are born in one country but move to another one at an early age and the article clearly states they’re a national of the second one? Kay girl 97 (talk) 04:32, 26 June 2024 (UTC)

In the majority of cases, it would be better to use the citizenship field. CMD (talk) 04:50, 26 June 2024 (UTC)

What if we combine both of them into a parameter called |country=, displayed as Country or Nation? WhatamIdoing (talk) 02:57, 29 June 2024 (UTC)

What would that...mean? A person can be associated with one or more countries through birth, parentage, ethnicity, residence, citizenship, sports team... -- Beland (talk) 07:30, 29 June 2024 (UTC)

I don't think the infobox is the place to explore complex issues. Place of birth is simple enough. Citizenship can be useful, particularly if the person's whole notable career was in a single country that was not their country of birth. If the person has a more complex history of emigration, being "based" in other countries or otherwise "belonging" to other countries, then the body of the article can and should explain, and the infobox should refrain from introducing misleading, incomplete factoids. -- Ssilvers (talk) 17:50, 29 June 2024 (UTC)

@Beland, if we switch to a "country" model, a person who is associated with one or more countries could have both listed. A "country" approach is no more likely to have disputes about whether someone is "really" from that country than what we've already got with nationality and citizenship, and it is much less likely to have someone try to claim that "African-American" or "Jewish" is a "country". WhatamIdoing (talk) 22:09, 29 June 2024 (UTC)

Agree with WhatamIdoing… except I would have the parameter in the plural (“Countries”)… to make it clear from the outset that we can put more than one. Blueboar (talk) 22:28, 29 June 2024 (UTC)

I can see why that would be desirable for the purpose of coralling editors into following the guidelines, but my point is that for readers it would be rather vague. It doesn't specify any particular sort of relationship between the person and the countries listed, so it leaves readers to guess what is meant or read the article body. -- Beland (talk) 22:36, 29 June 2024 (UTC)

A "country" field is a very poor idea; ignore perhaps the immediate bunfight we would have in UK articles, it can get very vague going back in time. It raises exactly the sort of complex question we should be avoiding (pretty similar ones to the existing nationality field). Do we have regular issues about the citizenship field? CMD (talk) 01:17, 30 June 2024 (UTC)

Other than cases where it should be omitted because it's the same as the birth country (tens of thousands of instances), the problems I've seen with current practice are anachronistic errors where people are assigned citizenship of a colony instead of e.g. British subject (though this is also true for birth places), lack of explanation as to why it's not the same as country of birth or residence (nearly all the time), lack of citation (nearly all the time), and no indication that citizenship changed when the country itself changed status (e.g. independence from a colonial power). -- Beland (talk) 04:57, 30 June 2024 (UTC)

For cases where it's unclear which administrative level is appropriate to list for birth country, I always list both if there's no dispute that X is part of Y. Generally this is "Colony Name, Empire Name", but the same solution could be applied to the UK home nations in lists of countries, e.g. "Wales, UK; France". Looking at birthplaces as they currently appear in infoboxes, "UK" is omitted for about 85% of bios (on my todo list) where Wales is listed in the birth_place field. For those that list "UK" in birth_place, the home nation is omitted about 30% of the time.

Actually, I wonder if it should be a rule that both levels are always included in birth places for UK bios. This would help readers who don't know that e.g. Wales is part of the UK, and also those who don't know which home nation e.g. Birkenhead is in.

We generally seem to consider any entity listed in ISO 3166-1 as the top-level birth country. So for example, we don't write "Puerto Rico, United States" which would be disputed by editors pointing to the "belongs to but is not a part of" legal situation. -- Beland (talk) 19:31, 30 June 2024 (UTC)

In complex cases (where more than one country applies) I would think we would want the reader to go beyond the info-box and read the article. Blueboar (talk) 01:38, 30 June 2024 (UTC)

Sure, but if they need to read the article to understand what's going on, is it useful to have the field in the infobox? If the relationship is unspecified, will editors degree on which aspects of association with a country should be counted in populating this field? -- Beland (talk) 04:52, 30 June 2024 (UTC)

I think it would be very useful… populating the field with multiple countries alerts the reader to the fact that the subject has ties to multiple countries… (perhaps they moved… perhaps borders changed… perhaps they live in one place, but champion a cause in another… etc etc). Populating the field with multiple countries tells the reader that, in this case, things are complicated and that they need read further to understand why. Blueboar (talk) 12:31, 30 June 2024 (UTC)

So in the New Hampshire Grants case mentioned above, you would want the infobox to say something like "Countries  Province of New York or Province of New Hampshire in British Empire (disputed), Vermont Republic, United States"? Or would this list be omitted under the rule that it's the same as the birth country, and only changed because the birth country status changed and not because the person moved?

Many Native Americans are currently listed in their infoboxes as having citizenship both to a native nation and the United States. If we add residence to the criteria for inclusion on the "Countries" list, under McGirt v. Oklahoma, parts of the Tulsa, Oklahoma metro area are considered to be Cherokee and Muscogee territory. Some people who live there are Cherokee citizens who also have US and Oklahoma citizenship, and some are descendants of white settlers who only have US and Oklahoma citizenship. Would we want to add "Cherokee" to the biographies of some white people based on where in the Tulsa metro area they live or were born (pretty hard to determine) or not have "Cherokee" on the list of countries because it's not fully sovereign and thus drop the most important affiliation from the infobox, or have some other rule? -- Beland (talk) 18:51, 30 June 2024 (UTC)

I don't think that last one will prove to be as complicated as it sounds. We can't add anything that can't be found in a source. Therefore, in the absence of a source affirming that the person was born in Cherokee or Muscogee territory (whichever is relevant), then we should not include it. That requirement alone solves nearly all of them. WhatamIdoing (talk) 23:53, 30 June 2024 (UTC)

If we do find such a source, however, what should be put in the infobox for that person? -- Beland (talk) 00:18, 1 July 2024 (UTC)

Why not list both, then? We could say something like "Tulsa, Oklahoma, US and Cherokee Nation reservation". WhatamIdoing (talk) 00:57, 1 July 2024 (UTC)

Adding "and Cherokoee Nation reservation" for an Oklahoman who isn't Cherokee seems a bit misleading, and Ssilvers would object that it's not related to that person's notability. If it's just a random quirk of geography that's not particularly relevant to the person's life, it is arguably not worth highlighting in such a prominent location. -- Beland (talk) 03:23, 1 July 2024 (UTC)

You should only include what's relevant, and I would expect in this case for reliable sources to normally only mention this particular situation when it is relevant. WhatamIdoing (talk) 02:01, 2 July 2024 (UTC)

Imo nationality of pre-modern states is a pointless concept to reduce to an infobox parameter, and I'm certain this has been discussed both here and in Template Talk:Infobox person before. Legal citizenship becomes similarly problematic when you go too far back. The common cutoff I see people casually use for the modern (European) state is the 1814 Congress of Vienna, but even that's too early for a lot of places that simply did not exist until much later (such as Germany and several other modern polities in Central and Eastern Europe, and that's just Europe).

I agree that citizenship is the most direct parameter to contain within an infobox, while anything else would just be too volatile. If there has to be a rule of thumb on historical citizenship, maybe it should be the rules of citizenship for the modern country -- like, how does modern Serbia interpret someone re-entering the country with former Yugoslav citizenship, for example. SamuelRiv (talk) 06:13, 13 September 2024 (UTC)

Not exactly sure what you mean about re-entering a country with a citizenship that no longer exists. Whether or not Serbia recognizes Yugoslav citizenship in any special way is somewhat irrelevant to the question of whether or not Wikipedia says that someone was in the past a citizen of Yugoslavia.

Serbia's rules do matter in defining who got citizenship at the creation of the country. For example, for someone who was born in Belgrade, Yugoslavia and currently has only Serbian citizenship, we would just omit the field. For someone born in Zagreb, Yugoslavia who got Serbian citizenship later, I would expect "citizenship=Yugoslavia, Croatia, Serbia" or "citizenship="Yugoslavia, Serbia", depending on their actual personal timeline. -- Beland (talk) 18:29, 13 September 2024 (UTC)

What does "ties" mean? Rishi Sunak was born in the UK, has grandparents from India and Pakistan, has a father from Kenya and a mother from Tanzania, studied, worked, and gained residency in the United States, and married an Indian citizen. Which of these, or others, make it into the infobox? Birthplace and Citizenship are fields that much more rarely raise such value judgements. CMD (talk) 01:34, 1 July 2024 (UTC)

I think in that case you would only mention the UK. Your parents' ties/places of origin are not really your own. WhatamIdoing (talk) 02:03, 2 July 2024 (UTC)

This both sidesteps the overall question and is far more reductive than how things often work. The 2024 Summer Olympics are coming up, where Joseph Fahnbulleh will be competing for the second time. After being born and spending his life in the United States, he went to the 2020 Summer Olympics to represent Liberia, for which he was no less than a flag bearer. CMD (talk) 02:20, 2 July 2024 (UTC)

[left]. Infoboxes are for key facts, not for lists of things that don't affect your notability and that should be explained clearly in the text below. -- Ssilvers (talk) 02:28, 1 July 2024 (UTC)

(Begin sarcasm) Wait… you mean infoboxes aren’t for claiming famous people as “one of us” (or, on occasion, as “one of them”)?

But, but… surely that would qualify as a key fact! (End sarcasm) Blueboar (talk) 18:58, 13 September 2024 (UTC)

No, dude. The purpose of infoboxes is to make sure that everyone knows the always key fact of where famous people died, as in: "Who was Christopher Columbus?" "He was a man who died in Valladolid, Castille." It is obviously not enough to state this in the body of the article. -- Ssilvers (talk) 21:07, 13 September 2024 (UTC)

For sportspeople

Just came across an instance that raises a question for the "drop the nationality field" project. {{Infobox basketball biography}} only has a "nationality" field, not a "citizenship" field. After some discussion at Talk:Julius Hodge with Rikster2, it appears we can and do infer nationality from the basketball rules. That is, if someone played for a national team, league rules require them to be a legal national of that country or a resident of a dependent area. However, I can't find any sources that say Julius Hodge (who was born in the United States but played on the Antigua and Barbuda national team) is a citizen of Antigua and Barbuda, as opposed to some other sort of national. Though after reading Antiguan and Barbudan nationality law, I'm not sure there's actually a difference between an A&B national vs. citizen, or if for that country those are effectively synonyms.

What should we do in these situations? It seems to me like "nationality" will often be read or written to mean "ethnicity", so I'd still like to avoid that. Many sportsperson templates seem to have a "national_team" parameter, so we could potentially add that here? That would avoid teetering on the edge of original research by inferring citizenship or nationality from team membership. We could also drop this from the infobox and leave complicated cases to the article body. -- Beland (talk) 03:29, 3 September 2024 (UTC)

... "nationality" will often be read or written to mean "ethnicity": (Notified here. I'm only commenting on this subsection) I don't think we need to bastardize the infobox for readers that have an incorrect understanding of English's nationality. To date, the basketball infobox only mentions national teams w.r.t. medals earned, in which case the country for which they competed will be adjacently shown (e.g. Derrick White). We shouldn't adopt a one-size-fits-all in assuming national team competition is equally notable among all sports segments.—Bagumba (talk) 03:53, 3 September 2024 (UTC)

As a basketball player who has played for a national team, he had to meet requirements thusly: page 5 From the FIBA manual (this is for 3x3 basketball but the rules are the same): “In order to play for the national team of a country, a player must hold the legal nationality of that country and have fulfilled also the conditions of eligibility and national status according to the internal regulations.” That absolutely qualifies inclusion in the nationality field. Frankly that’s all an infobox should need, national team representation is clear and verifiable. Rikster2 (talk) 14:07, 3 September 2024 (UTC)

It's not an error to read "nationality" as "ethnicity"; here in the States, that's how it's commonly used in casual conversation, referring to the national origin of one's family. Wikipedia templates are trying to use it in a technical sense most people aren't familiar with. I'm cleaning up the field site-wide, and I'd estimate that half of editors are not using it in the intended legal sense, and putting things like "African American". Which readers actually correctly interpret as a race or ethnicity, but those things are banned from infoboxes. -- Beland (talk) 00:17, 4 September 2024 (UTC)

I think it we want people to stop doing that, we either need to provide them with a 'correct' way to achieve their good-faith goal of recording someone's race/ethnicity, or prevent the |nationality= field from accepting anything that isn't on the pre-defined list. Template:Inflation, for example, only accepts certain country codes. We could pre-program a list of acceptable country codes, and have the infobox refuse to display anything else. WhatamIdoing (talk) 00:46, 4 September 2024 (UTC)

Rikster2 said on Template talk:Infobox basketball biography that their preferred solution was to eliminate this field entirely. Would there be any objection to doing so? I am currently going through and dropping all instances where it is simply the same as the birth country. After that's done, I could do another pass over the complicated cases and either tag them for a while to give authors time to transition that info, move the info to some other designated place, or simply drop it if the article already covers it adequately (which we could leave to inferences like "was born in" and "played on the national team for"). -- Beland (talk) 00:49, 4 September 2024 (UTC)

Rikster2 said on Template talk:Infobox basketball biography that their preferred solution was to eliminate this field entirely. Would there be any objection to doing so?: It instinctively feels like overkill. The field just needs to be used "properly", but I understand that might not happen either, esp. since infoboxes draw more drive-by edits than the same information that's in prose in the lead. It seems like an infobox MOS page might not draw the widest input. Perhaps ideas might come at WP:VPPOL on how to meld it better with the lead's MOS:NATIONALITY? Just a suggestion to cover all alternatives (I'm not passionate enough on this topic to contest it, nor do I have a better solution currently). —Bagumba (talk) 05:31, 4 September 2024 (UTC)

It's not an error to read "nationality" as "ethnicity"; here in the States ...: That's nothing more than generations of distortion by certain people to push a narrative that some citizens "really" aren't American.—Bagumba (talk) 01:41, 4 September 2024 (UTC)

It is better not to put it in the infobox and to explain the information in a more nuanced way in the article itself, unless the person is most famous for representing their country in international competition. -- Ssilvers (talk) 01:57, 4 September 2024 (UTC)

MOS:NATIONALITY is generally prominent in the lead sentence. If an infobox is just summarizing the article, it seems to follow that nationality should be present also, particularly when it cannot be inferred vis MOS:INFONAT. It seems this should be a centralized discussion/RfC, to have the lead and infobox be consistent, rather than making infobox decisions in isolation. —Bagumba (talk) 02:11, 4 September 2024 (UTC)

Partial strike. In prose its a bit amorphous what is being referred to, but it can be reflected more in the body, while a "Nationality" field is rigid, and editors will start enumerating verifiable, but less prominent ones.—Bagumba (talk) 02:25, 4 September 2024 (UTC)

Well, I've dropped this field from that infobox for now, and I'll see if any more unusual cases come up. -- Beland (talk) 06:11, 6 September 2024 (UTC)

• If actions are to be taken on this then an actual consensus decision needs to be reached to remove it from the infobox in question. Manually striking it from one specific article is not a solution. Does this discussion serve as consensus to remove the nationality field or not (I have my doubts)? If so, someone needs to remove it as an option in Template:Infobox basketball biography. It is not appropriate to take this discussion as a grounds to just remove it from one article (Julius Hodge) while it remains on hundreds of others. Rikster2 (talk) 12:09, 7 September 2024 (UTC)

  Why not? Sometimes trying it out at a small number of articles is a good way to test the change and see if it's helpful. WhatamIdoing (talk) 16:07, 7 September 2024 (UTC)

  • Sounds like a fun way to get around trying to make the case for consensus. Rikster2 (talk) 16:35, 7 September 2024 (UTC)

    It sounds to me like an effective way to collect some data. WhatamIdoing (talk) 17:40, 7 September 2024 (UTC)

    I do not want to "get around" consensus, because making edits that have to get undone later would be a potentially huge waste of my time and the time of other volunteers.

    That is why I have started discussions at all three levels - article, template, and manual of style. Between here and Template talk:Infobox basketball biography#Nationality and Talk:Julius Hodge, I see some editors supporting removal, some abstaining, and no firm objection. Unless someone objects or points out something I've missed, I am comfortable gently proceeding with removal. We could stop and call an RFC and ask for more opinions from people who aren't interested in basketball, if you like, but I think folks who edit basketball biographies probably care more about this than the general editor population. If they follow articles but not templates or policy pages, they probably aren't aware of this proposal. Given that there are a huge number of pages where nationality should be removed under the existing policy of dropping it when it's the same as the birth country, I can get their attention by dropping those instances and noting in the edit summary that the field is being removed entirely. Then if a crowd appears and objects to the removal, we won't have anything that needs undoing. That will also boil the question down to a relatively small number of unusual cases, which would be informative to analyze if anyone's on the fence.

    There are several levels of removal from the template:

    1. Marking the parameter as deprecated in the documentation
    2. Stopping the parameter from displaying
    3. Removing the parameter completely, causing an error message if used

    It's certainly fair to want to avoid editors adding this parameter to new articles during the removal process. I just took the first step and marked it as deprecated in the documentation, linking to this discussion. That's easily undone if anyone objects, and will help raise awareness that this is happening before most of the work gets done.

    Having a parameter that people are used to using but which suddenly doesn't show up on articles anymore may cause confusion or cause editors to think there is a bug, but I won't object to doing the level 2 change if other editors want to. I was intending on removing the parameter from all affected articles first (keeping the actual use-cases for last), and then just doing the level 3 change unless the increased attention sways the prevailing opinion. Doing the level 3 change as soon as there's consensus at the template or policy level would cause a mess in a lot of articles, which I'd rather avoid. I can put whatever change people want to see into the template sandbox for testing. -- Beland (talk) 17:56, 7 September 2024 (UTC)

If sportspeople infoboxes want to show what national team the person is playing for, and this was has indicated by the |nationality= field, then those infoboxes should probably create a separate field name to indicate national team/eligibility (because that is not an obvious overload of that parameter) and start running through AWB now to replace it. Otherwise the nationality/ethnicity/citizenship confusion that we're talking about will just persist. And of the basketball players' infoboxes already out there, how sure are you that the nationality parameter does indeed represent their FIBA eligibility, especially for those players not on their respective national teams? SamuelRiv (talk) 06:02, 13 September 2024 (UTC)

Well, my opinion was about dropping the field completely from the infobox. My opinion about this specific article is that, if the field exists in the infobox, that it should be kept because it is a clear case of split/dual nationality. Thanks for giving me the opportunity to be 100% clear

Also, just to be clear, no other editor has agreed to your proposed changes to nationality at Talk:Julius Hodge as I write this. Rikster2 (talk) 19:19, 7 September 2024 (UTC)

Well, of the participants on Talk:Julius Hodge, you've said you want the field removed from the template entirely, I support that, and it's unclear to me what DaHuzyBru thinks about complete removal. I invite them to give their opinion here if they have one.

Given that you would like to have the field removed from the template entirely, in what order would you like the changes implemented? (The needed changes being: remove from articles instances with same country as birthplace, remove from articles remaining instances like dual nationality, stop the field from displaying, and cause the template to emit an error if used.) -- Beland (talk) 20:01, 7 September 2024 (UTC)

It already gets removed in cases where the nationality matches the birth country. As long as it is a field in the infobox that is the only situation where it should be removed. Cases of split nationality like Julius Hodge are the reason the field was kept at all I assume. Rikster2 (talk) 15:19, 11 September 2024 (UTC)

I wrote a script to check. Out of 21688 transclusions, 3835 have a single nationality that is the same as the birth country, and another 3098 that list a US state with American nationality. I will start by removing those with a deprecation edit summary, as proposed.

There are under 200 cases of dual nationality. Hundreds of bios are for people who have moved from one country to another but have only one nationality listed, and people who were born in a country that no longer exists (like Yugoslavia or the USSR). -- Beland (talk) 01:55, 12 September 2024 (UTC)

Removing "American" when they were born in the U.S. is purely MOS:INFONAT, it's not related to any potential deprecation. —Bagumba (talk) 13:49, 14 September 2024 (UTC)

Sure, I'm just advertising the deprecation in edit summaries, since I'm touching the same field in articles that use the template. -- Beland (talk) 15:41, 14 September 2024 (UTC)

Sign language translations in infoboxes

Has there been discussion before of how (or whether) to include sign languages in infoboxes? There has been a request at Talk:New Zealand#New Zealand Sign language video request, but once adequate media has been found or generated, I’m concerned that simply pasting a graphic or video into the infobox title section isn’t going to flow the best. There are only a handful of countries with official sign languages, but the potential here is quite a bit broader. — HTGS (talk) 06:14, 25 June 2024 (UTC)

I'd suggest an icon/link to accompany the pronunciation (which is either in the lead or in a footnote) instead. Nikkimaria (talk) 03:51, 26 June 2024 (UTC)

INFONAT, ethnicity and fictional characters

Seeing as everyone’s having so much fun discussing MOS:INFONAT: Does INFONAT apply to fictional characters? I lean slightly towards a no myself, so I figure I should check in. I ask following the addition of “Italian-American” to the Nationality field of Adriana La Cerva’s infobox (diff). Although I don’t think “Nationality” is the right field, I wonder if the fact of her ethnicity is at least worth considering as an important part of the characterization; that is, should it be down to editorial judgement, rather than being verboten by MOS? Or does this just open every (non-generically-white) character up to including their race in their infobox? — HTGS (talk) 23:09, 10 July 2024 (UTC)

Yes, I would apply the same standards to fictional people for those fields. Italian-American is an ethnicity, and so should not be in an infobox, and neither should religion. I'll drop those now. -- Beland (talk) 03:09, 3 September 2024 (UTC)

Italian-American is an ethnicity, and so should not be in an infobox doesn't come from anything though? The reason we don't list it in biographies is because the idea of real, human ethnicity is too complex to pin down in such a field. The ethnicity or religion of a fictional character can be complex, but is often simple and deliberate, as written by the creator. For Daredevil (Marvel Comics character), the answer of religion is straightforward, explicit and central to the character, it could certainly be argued that for Tony Soprano et al, their ethnicity is just as central. I'm happy to go along if there's good reason, but I can't see a rationale to follow if it's just "No Ethnicities in Infoboxes". — HTGS (talk) 07:27, 5 September 2024 (UTC)

For some real people, their ethnicity is just as simple and straightforward as for a fictional character, and there is no exception for them. For example, the ethnicity of Al Capone is straightforward and central to his life and occupation, but is not listed in his infobox. Reading the 2016 RFC on the "ethnicity" field, I see comments that say something like: the arguments and inaccuracy that would result from having this field available for complex cases is not outweighed by the benefit this field would provide in simple cases. -- Beland (talk) 16:37, 5 September 2024 (UTC)

There was also a 2016 RFC on the religion field. It has been removed from real-person biography infoboxes except for Template:Infobox religious biography, which only seems to be used for people with a religious occupation or who are part of the content of a religion. It seems consensus is not to include this field for people who simply have a strong faith-based motivation for some other occupation, which I assume is the Daredevil's situation. -- Beland (talk) 16:45, 5 September 2024 (UTC)

Ok, that's fine. I guess I just fall slightly further over on the spectrum between “This is useful for some cases” and “This will be a major temptation for most cases”. And as much as I agree with most of our userbase’s liberal atheist attitude, I suspect it goes too far at some points. (On that note, Daredevil’s article doesn’t mention his Catholic faith at all, despite it having a massive amount of coverage in sources, so maybe I’ll go bother that article, and leave this alone for the time being.) — HTGS (talk) 22:29, 5 September 2024 (UTC)

Following up on implementation of cleanup at Template talk:Infobox character. -- Beland (talk) 05:58, 6 September 2024 (UTC)

Tree lists

It seems different editors have different tastes regarding how {{Tree list}} should be used versus other list types. My impulse was they shouldn't be used at all in infoboxes, since they are visually noisy. The more I think about it, the more they seem fine, if a bit noisier than combining plain, definition, and lists like I am usually in the habit of doing. If there's more than one level of depth, it's probably not fit for an infobox to begin with, and so excludes the situation where tree lists could clearly be a superior choice. Remsense ‥ 诉 00:29, 17 August 2024 (UTC)

• I would agree with the observation that these are noisy. There are cases of multiple levels (ie more than two) where tree lists might be appropriate. However, in an infobox, this would suggest a level of detail at odds with WP:INFOBOXPURPOSE. Cinderella157 (talk) 02:09, 17 August 2024 (UTC)

Duplication of images in infobox and body

Should an image that appears in the infobox also appear in the body of the article? (I would have thought that we do not duplicate images in this way, but if so, I would have thought that infobox images would be mentioned as one of the exceptions, where something may be placed in the infobox, but not in the body.) Nurg (talk) 23:40, 3 September 2024 (UTC)

Generally we should not, but infobox images are so small, there may be cases (articles on paintings for example) where a repetition is justified. Johnbod (talk) 00:01, 4 September 2024 (UTC)

Indeed. Some infoboxes have very many small images and are unstable too (e.g. Rome). Shuffling images out of reasonable placements and sizes in the body of the article because someone's put a tiny version in the infobox, then shuffling them back again with the next infobox change, could become quite disruptive. NebY (talk) 09:48, 4 September 2024 (UTC)

Lists in the |title= parameter

I just wanted to point to a recent dispute about how the |title= parameter for {{Infobox royalty}} at Talk:Xerxes I should be used. Remsense ‥ 论 23:21, 7 October 2024 (UTC)

Consistency among office holders

If a numbering is removed from an office holder's infobox. Should it be removed from that individuals' predecessors & successors' infoboxes? GoodDay (talk) 15:07, 12 October 2024 (UTC)

Or to put it another way, should you have added numbering to one office in one article[8], slow-editwarred to keep your insertion on the grounds of consistency[9][10], requested page protection to keep your addition[11] and then come here to seek a general ruling that reverting your addition requires comprehensive removal in other articles?

And are you proposing that in the name of Consistency among office holders we should number other offices in that article, and in articles about those holding other offices in that country, and in articles about vice-presidents in other countries? NebY (talk) 16:01, 12 October 2024 (UTC)

Numbering should only be added if "there is a well-established use of such numbering in reliable sources." Otherwise, don't add it. DrKay (talk) 17:16, 12 October 2024 (UTC)

@NebY: don't bite my head off, please. If the other editor isn't going to make the effort to delete the numbering from the related bios? Then neither will I. GoodDay (talk) 00:40, 13 October 2024 (UTC)

"end of the lead section of an article (in the mobile version)"

Is there a reason behind the current first sentence stating infoboxes appear at the "end of the lead section of an article (in the mobile version)"? Whenever I've looked at a mobile version infoboxes appear after the first paragraph, which could be in the middle or even towards the start of a lead section. CMD (talk) 17:31, 16 October 2024 (UTC)

I have tweaked to reflect the mobile positioning. CMD (talk) 13:24, 22 October 2024 (UTC)

Why does the 'coordinates' paramater yield duplicate coordinates?

At articles like Assassination of John F. Kennedy, the coordinates parameter causes coordinates to be presented at the top right of the page and also in the infobox. Why do we need it to appear twice? Also, are coordinates even useful? What percent of readers even know how to interpret them? If there is already a map feature, are coordinates even needed at all, let alone twice? ~ HAL333 (VOTE!) 16:19, 23 October 2024 (UTC)

It's not the coordinates parameter itself causing that, it's the actual {{coord}} template - if you changed |display=inline,title to have only one value it would display coordinates in only one place. As to whether it should be displayed at all, that's probably a question for a Village Pump rather than here. Nikkimaria (talk) 04:59, 24 October 2024 (UTC)

Noted with thanks. ~ HAL333 (VOTE!) 16:16, 24 October 2024 (UTC)

Image/s max-width within the infobox

What is the optimal method for determining the maximum width of an image or group of images (such as a national flag and coat of arms together) within the infobox that sets the overall width of the infobox? SilverBullet X (talk) 16:34, 25 October 2024 (UTC)

Can MOS:INFOBOXPURPOSE be updated to reflect discussion here?

On Donald Trump, there has been a discussion on applying MOS:INFOBOXPURPOSE in the discussion Parents, children, and spouses links in the infobox. After reading that the infobox's purpose is "allowing readers to identify key facts at a glance" we moved to exclude Relatives: Trump family and potentially Awards: Full list. After reading the talk page here however, it doesn't seem like this natural reading has consensus, and editors have repeatedly argued above that links to these pages constitute "key facts". I couldn't quite gauge the consensus as the page didn't appear to change in light of the discussion and the INFOBOXPURPOSE still naturally reads as having the opposite meaning. Can this language be clarified to better reflect what editors perhaps believe? Rollinginhisgrave (talk) 08:28, 12 November 2024 (UTC)

Infobox file spam

New York
City
Midtown Manhattan with the Empire State Building (center) and Lower Manhattan with One WTC (background) UN headquarters Statue of Liberty Times Square Unisphere Central Park Brooklyn Bridge Verrazzano-Narrows Bridge Bronx Zoo
Flag Seal Wordmark
Interactive map outlining New York City
New York City Location within the state of New York New York City Location within the United States
Coordinates: 40°43′N 74°00′W
Country	United States
State	New York
Named for	James, Duke of York

We should get together and get some sort of consensus about file spam in infoboxes like at cities New York city (17 files) is an accessibility nightmare and I'm not sure how anyone would think this amount of files for three paragraphs is reasonable. Moxy🍁 02:42, 26 November 2024 (UTC)

I don't see why we need any cites in the IB if the info is cited in the article. -- Ssilvers (talk) 02:45, 26 November 2024 (UTC)

Perhaps I should be more clear..... files as in images. Scrolling nightmare of little mini images is deterrent for readers. I've seen many debates where those who love lots of teeny images in conflict with those who want an academic look and care about accessibility of content.Moxy🍁 03:12, 26 November 2024 (UTC)

Oh, I see. Thanks. -- Ssilvers (talk) 03:41, 26 November 2024 (UTC)

• I would see that they violate WP:COLLAGE: where overlapping or similar careful placement of component images is necessary to illustrate a point in an encyclopedic way [emphasis added]. Collages are otherwise discouraged. WP:LEADIMAGE uses the singular. MOS:INFOBOXPURPOSE tells un not to try to write the article in the infobox. Such collages are a photo essay and just another way of trying to write the article in the infobox. WP is not a picture encyclopedia. Moreover, squeezed two (and sometimes more) abreast, they are too small to be easily seen and poorly contrasting images just become a blur. We are told not to force the infobox size (eg make it larger) for accessibility reasons. Cations then bloat the infobox further. In short, they are a terrible idea and unfortunately, they are not peculiar to cities. I see them in a battle article. Any discussion to address this should be as broad as possible in scope. Cinderella157 (talk) 08:11, 26 November 2024 (UTC)
• City infobox image bloat has been longstanding issue, and picture selections and arrangements are a common cause of dispute. However, it's reasonably entrenched, so any change would likely require very wide reaching RFC. CMD (talk) 09:01, 26 November 2024 (UTC)

  Agree been around for some time...at the begining it was 2 or three only in major cities. Still mainly only in big cities (rare in small towns etc) but the bloat is up to 8 or 9 even 10 images let alone 3 or 4maps 2 or 3 symbols and a few flag icons is somthing in my view we need to get a hold of. Moxy🍁 16:49, 26 November 2024 (UTC)

  I think we have many protocols and essays about this but they are simply ignored. Think we need to be more blunt here.

  [emphasis added]

  • MOS:IMAGERELEVANCE ="However, not every article needs images, and too many can be distracting.
  • WP:GALLERY = "In articles that have several images, they are typically placed individually near the relevant text....A gallery is not a tool to shoehorn images into an article,
  • WP:NOTGALLERY ="If you are interested in presenting a picture, please provide an encyclopedic. context,
  • MOS:IMAGELEAD = :they should not only illustrate the topic specifically, but also be the type of image used for similar purposes in high-quality reference works, and therefore what our readers will expect to see ".
  • WP:UNDUE = "Undue weight can be given in several ways, including but not limited to the depth of detail, the quantity of text, prominence of placement, the juxtaposition of statements, and the use of imagery".....
  • ,MOS:IBP = The purpose of an infobox is to summarize, but not supplant, the key facts that appear in an article..The less information that an infobox contains, the more effectively it serves its purpose,"
  • ,MOS:LAYIM = "Try to harmonize the sizes of images on a given page in order to maintain visual coherence."
  • Template:Infobox settlement = "Primary image

  Moxy🍁 17:04, 26 November 2024 (UTC)