This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Manual of Style This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations. Templates This page is within the scope of WikiProject Templates, a group dedicated to improving the maintenance of Wikipedia's templates. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TemplatesWikipedia:WikiProject TemplatesTemplate:WikiProject TemplatesTemplates Infoboxes This page is within the scope of WikiProject Infoboxes, a collaborative effort to improve the coverage of Infoboxes on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InfoboxesWikipedia:WikiProject InfoboxesTemplate:WikiProject InfoboxesInfoboxes

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 Archive 7 Archive 8 Archive 9 Archive 10 Archive 11 Archive 12 Archive 13 Archive 14 Archive 15 Archive 16 Archive 17 Archive 18 Archive 19

This page has archives. Sections older than 365 days may be automatically archived by Lowercase sigmabot III when more than 5 sections are present.

Since this has been discussed on this page before, I thought this had long been settled, but apparently Edwardx disagrees. Citizens of Canadian First Nations and US federally recognized tribes are dual citizens, typically of Canada and the United States respectively (but not always). The US entered into treaties with tribes as foreign governments. In Worchester v. Georgia (1832) established Native American tribes as so-called "domestic dependent nations", which acknowledges their sovereignty that predates the establishment of the United States. Tribes have negotiated government-to-government relationships with the United States in the era of self-determination.[1]. Many people, including Wikipedia editors, mistakenly believe US federally recognized tribes are ethnic groups;[2] however, they are political entities. For example, the single tribe, Confederated Tribes of Siletz Indians, includes 27 different ethnic groups, while conversely the Pomo people are a single ethnic group, split across 21 different federally recognized tribes. As a citizen of a tribe and of the United States, I have treaty rights not accessible by non-tribal citizens and I have to abide by the laws of my tribal government and can seek redress in my tribal court system. Citizenship to both nation-state and a Native American tribe cannot quickly be inferred from place of birth. Yuchitown (talk) 01:31, 13 March 2023 (UTC)Yuchitown[reply]

Can you give an example as we have parameters for this..... we have nationality parameters citizenship parameters place of birth parameters. Is there an ongoing conflict or just something of note ? Moxy- 01:58, 13 March 2023 (UTC)[reply]

I just tried to clarify that these are typically listed under "nationality," but that was reverted, so I'm taking it to the talk page. I did have a typo, though. Yuchitown (talk) 02:09, 13 March 2023 (UTC)Yuchitown[reply]

How things are normally dealt with can be seen in our featured articles of related content ....like Jim Thorpe or Simonie Michael. We should be specific...linking generic terms like Native American or First Nations in the lead doesn't help anyone understand anything except for their indigenous. "name" is a Canadian of Naskapi descent who was the first too.... blah blah blah.... that being said is there indigenous status why they are famous? Moxy- 02:26, 13 March 2023 (UTC)[reply]

I absolutely agree that "Native American" and "First Nation" shouldn't be in the infobox under nationality, and when I see those, I change them to the specific nation the individual is a citizen of. The way I and other members of WP:WP IPNA list nationalities can be found at Rebecca Belmore, Charles Curtis, etc. It's short and simple but quickly conveys maximum information. The citations are found in the prose, but if necessary I can begin adding citations to the "nationality" listing in the infobox as well. Yuchitown (talk) 17:40, 13 March 2023 (UTC)Yuchitown[reply]

Unless relevant to notability, Native American should not be in the first sentence of a BLP per MOS:CONTEXTBIO. I'm opposed to having "Muscogee (Creek) Nation" as a nationality[3]/citizenship in the infobox. From what I'm reading, this citizenship thing is only recognised domestically (Canada too? Same thing to me). So chaps can't come to jolly ol' England on a Muscogee passport, they'll be using their universally recognised US passport. For me, this would be like having "Cornish, British" in the infobox. – ².O.^Boxing 10:23, 13 March 2023 (UTC)[reply]

Being an enrolled citizen of a tribal nation is not an ethnicity; it's a unique political status. I tried to explain that above with Siletz and Pomo, but another example to try to illustrate: A Maya person born in Guatemala living in Texas and a tribal citizen of Thlopthlocco Tribal Town living in Texas are both American Indian and closely related, ethnically and genetically, but they have completely different political statuses. Yes, members of tribes are usually dual (or threefold) citizens, but I know Muscogee (Creek) Nation citizens living in the United Kingdom. They still have rights through their enrollment and have to follow the laws of the tribal nation. Their Native national identity doesn't fall off the second they travel internationally. It does get confusing quickly, but Indigenous nations have international rights under the United Nations Declaration on the Rights of Indigenous Peoples. Citizens of First Nations have rights to freely cross the US–Canadian border and work in either country under the Jay Treaty. I'm writing about US federally recognized tribes because that is what I'm most familiar with, but Indigenous peoples of Panama also have strong political autonomy and their own lands, comarcas.

As far a relevance, being a citizen of a tribal nation is central to one's identity. It is not the same as being "Cornish, British." The Muscogee (Creek) Nation has a government-to-government relationship with the United States. It has its own constitution and its own court system. Under McGirt v. Oklahoma the rights of specifically the Muscogee (Creek) Nation and their reservation boundaries were reaffirmed. Yuchitown (talk) 17:56, 13 March 2023 (UTC)Yuchitown[reply]

The article on Indigenous peoples of the Americas says Native American is an ethnicity. To have a BLP say X is a Native American tiddlywinks world champion, the ethnicity would have to be relevant to their notability, not identity.

The way you and others at WP:IPNA are editing is simply wrong. Rebecca Belmore should be listed as Canadian; Lac Seul First Nation is not a nationality and it shouldn't be in the citizenship parameter per Template:Infobox person, Country of legal citizenship, if different from nationality (she should also be described as Canadian in the lead per MOS:CONTEXTBIO). Same with Charles Curtis; Kaw Nation is not a nationality. I don't think the tribal citizenships should be mentioned in the lead at all unless it's somehow relevant to the person's notability (as can be argued for Charles Curtis), but that would be a different discussion. – ².O.^Boxing 21:28, 13 March 2023 (UTC)[reply]

I was talking about Native American identity and First Nations identity, which are not the same as Indigenous peoples of the Americas, a much broader, vaguer term (that article doesn't state anywhere that "Native American is an ethnicity." I provided examples and links that those two are specific political identities. Yes, absolutely Lac Seul First Nation and Kaw Nation are nationalities. WP:IDONTLIKEIT is an insufficient argument. Yuchitown (talk) 02:43, 14 March 2023 (UTC)Yuchitown[reply]

X is a Native American bobsleigh King would be in reference to ethnicity, not nationality. If you want to say it's not ethnicity, but "identity", then fine. But it's still not a nationality and should not be in the first sentence per CONTEXTBIO. From the first sentence of Nationality, Nationality is a legal identification of a person in international law, establishing the person as a subject, a national, of a sovereign state. These tribal citizenships do not have recognition in international law and the tribes (regardless of the fact they have the word "nation" in their name), are not nations or sovereign states, by any stretch of the imagination. This has nothing to do with not liking something, but everything to do with following well-established guidelines instead of a WP:LOCALCONSENSUS. – ².O.^Boxing 11:09, 14 March 2023 (UTC)[reply]

You are being very loose with terminology and proposed policy. This is an infobox talk page. I'm proposing spelling our the WP:IPNA practice of listing one's specific tribal nation and one's nation-state in the "nationality" section of a person's infobox, not a discussion of opening lede senteces. So not "Native American" (which is not an ethnicity; it's a political status as I've cited above that includes innumerable diverse ethnicities and mixed ethnicities, including freedmen for some tribes and, in rare, instances, such as Gov. Kevin Stitt, people of 100 percent European-American ancestry). Instead, for example, it would be listing Kaw Nation and "American" for Charles Curtis. Yes, as I've established with links above, US federally recognized tribes and Canadian First Nations absolutely do have sovereignty and are recognized by international law. I am part of establishing the WP:LOCALCONSENSUS and am basing my proposal on cited facts about US federally recognized tribes and Canadian First Nations. Yuchitown (talk) 14:55, 14 March 2023 (UTC)Yuchitown[reply]

The lead issue was raised, I was just commenting as it was part of the edit I reverted. My terminology probably is off in regards to ethnicity, and it's piqued my interest so think I'll read up on it.

When reading Declaration on the Rights of Indigenous Peoples, the "Purpose" section says, This declaration is a resolution, meaning it is not a law-bearing document. Indigenous peoples are not considered political nation-states and do not have access to international law protection through the international court of justice. So that would mean the nation state is still US under international law, and by extension, their nationality/citizenship is American. To me, including tribal citizenship implies it has the same recognition in an internationally-recognised legal sense, that being, a subject, a national, of a sovereign state (country). I think the current wording of INFONAT accurately reflects the general understanding of nationality/citizenship, the country to which the subject belongs. – ².O.^Boxing 18:46, 14 March 2023 (UTC)[reply]

Again, "Native Americans" and "Indigenous peoples" are different legal concepts, but the current wording on MOS:INFONAT already covers what I was trying to purpose, "When needed (e.g. due to change of nationality after birth, dual 'citizenship', or other unusual scenarios), use |nationality= unless |citizenship= is more appropriate for uncommon legal reasons." A person can change their citizenship from Canadian or American to another country but retain their citizenship to their tribal nation. I do know one family that is split between Jordanian and American citizens but they are enrolled in the Osage Nation. Yuchitown (talk) 20:42, 14 March 2023 (UTC)Yuchitown[reply]

Following up, Merriam-Webster defines "nation" as:

a(1): NATIONALITY sense 5a

(2): a politically organized nationality

(3) in the Bible : a non-Jewish nationality

b: a community of people composed of one or more nationalities and possessing a more or less defined territory and government

c: a territorial division containing a body of people of one or more nationalities and usually characterized by relatively large size and independent status

2 archaic : GROUP, AGGREGATION

3: a tribe or federation of tribes (as of American Indians).

So, it would be nice to spell out protocols for dual citizens of Native American tribes, but existing terminology already covers the appropriate protocol (list both in "nationality" parameter). Yuchitown (talk) 21:16, 14 March 2023 (UTC)Yuchitown[reply]

It isn't covered by the current wording. What you quoted from INFONAT is on the understanding that nationality/citizenship relates to countries, not tribal lands in the US and their domestically-recognised dual-citizenship rights. You said, Their Native national identity doesn't fall off the second they travel internationally. It does get confusing quickly, but Indigenous nations have international rights under the United Nations Declaration on the Rights of Indigenous Peoples. According to that article, when travelling internationally their tribal citizenship--legally recognised in the US and Canada--is not recognised under international law. You mentioned somebody in England with Muscogee Nation citizenship; they're not recognised as a Muscogee and British citizen outside of the US and Canada, they're recognised as American and British (assuming they have US citizenship, if not, just British). Same as the Jordanian and American family. The tribal citizenship does not have the same meaning or legal standing, and shouldn't be placed along with or instead of US nationality/citizenship. – ².O.^Boxing 22:44, 14 March 2023 (UTC)[reply]

Much of the discussion above is trying to work from first principles. Instead, we can look at what reliable sources do. When reliable sources talk about people's nationality, what do they say? Pick someone who is a member of, say, the Muscogee (Creek) Nation: do WP:RS routinely describe that person's nationality as American/US or as Muscogee or as both? We should follow what RS do. Bondegezou (talk) 10:53, 15 March 2023 (UTC)[reply]

I don't think how RS describe somebody matters here. The infobox parameters are for the country to which the subject belongs/Country of legal citizenship, which I think I'm safe to assume reflects the general understanding (if not the literal definition) of nationality and citizenship. – ².O.^Boxing 12:10, 15 March 2023 (UTC)[reply]

How RS describe something always matters. It's by looking at RS that we determine what the general understanding is. Do RS understand these terms — the country to which the subject belongs/Country of legal citizenship — to cover recognised tribes or not? Bondegezou (talk) 12:19, 15 March 2023 (UTC)[reply]

I provided relevant external links and wikilnks above, but they don't matter if an editor refuses to read them. MOS:INFONAT says, "When needed (e.g. due to change of nationality after birth, dual 'citizenship', or other unusual scenarios), use |nationality= unless |citizenship= is more appropriate for uncommon legal reasons." The MOS doesn't say anything about "countries" or anything about "passports." I'm a tribal member; I've successfully used my tribal ID to return to the US from another country when I didn't have a passport on me. OP is now repeating themself. Thank you for joining this conversation. Hopefully, others can join and share their perspective. But current language covers dual citizens, and I've found one person who was a threefold citizen. Yuchitown (talk) 15:02, 15 March 2023 (UTC)Yuchitown[reply]

Thank you for sharing your own experience, which is interesting. You haven't, as far as I can see, provided examples of reliable sources referring to individual's nationality in the manner you propose Wikipedia do. I think that's what would be persuasive. Arguments from first principles are not. Bondegezou (talk) 17:14, 15 March 2023 (UTC)[reply]

Have you looked through all the links I already provided? I provided one more below for the "unique Nation-to-Nation relationship" the US government has with tribal nations. The current MOS:INFONAT "nation" and "citizenship" which absolutely apply to US federally tribes, as cited. It doesn't list caveats of being a country or issuing passports, etc. Yuchitown (talk) 17:30, 15 March 2023 (UTC)Yuchitown[reply]

INFONAT doesn't list any caveats because immediately before the part you quote, it literally says it relates to countries, use of either should be avoided when the country to which the subject belongs can be inferred from the country of birth (bolding mine). – ².O.^Boxing 19:46, 15 March 2023 (UTC)[reply]

General understanding was a daft phrase to use. I should have just stuck with 'as defined by international law'. We don't need to gather RS to determine what nationality means (we already know), they're only needed to determine what somebody's nationality is. If RS are explicitly referring to a person's nationality as Muscogee Nation (X is a Muscogee Nation surfer wouldn't suffice), then they're wrong by the internationally accepted definition. Here comes another Cornish comparison; RS routinely describing somebody as Cornish (as they so often do, even in non-British sources) doesn't mean we put Cornish as their nationality or citizenship, because it's not. It's still British or English. – ².O.^Boxing 14:04, 15 March 2023 (UTC)[reply]

We should not be trying to interpret international law: that's WP:OR. We should go with what reliable sources do. Yes, you are right, this means we need RS (routinely and frequently) describing someone's nationality as Cornish or Muscogee, not just describing someone as Cornish or Muscogee. I don't see that at present, but that's the standard of proof I expect to be applied. Bondegezou (talk) 17:11, 15 March 2023 (UTC)[reply]

As you can find in all the links and examples I posted at the beginning of this section, Cornish identity and being an enrolled citizen of the Muscogee (Creek) Nation are not the same. I know more about the US than Canada, but in the US, federally recognized tribes are a completely unique political status as domestic dependent nations, who have signed treaties with the United Stats as nations and have nation-to-nation relationships with the US federal government. Yuchitown (talk) 17:26, 15 March 2023 (UTC)Yuchitown[reply]

Nationality tells us the definition under international law. If we were to get into semantics about what a "state" is, then that is also defined under international law,[4] which clearly doesn't apply to federally recognised tribal lands. – ².O.^Boxing 19:41, 15 March 2023 (UTC)[reply]

If Ireland and other's accept Native American passports [5], if Native Nation treaty with other governments, how do they not have nation status? Indigenous girl (talk) 07:02, 18 March 2023 (UTC)[reply]

I don't find that very convincing at all. If it wasn't a sports team being invited by officials for a specific reason, then you know as well as I do they would be denied entry. I found the article Iroquois passport, which says the passport is not recognised in Europe. The European Council actually calls them "fantasy passports". – ².O.^Boxing 12:45, 18 March 2023 (UTC)[reply]

Canada does not have the same sovereignty recognition as the United States does for indigenous people."Sovereignty". The Canadian Encyclopedia. 2014-06-26. Retrieved 2023-03-18. In the United States, Native American (or "Indian") tribes are seen as "domestic, dependent, sovereign nations." They have the inherent right to govern within their reservations. They can make laws, establish courts and enjoy immunity from external lawsuits. This doctrine of domestic sovereignty has never been applied to Indigenous peoples in Canada. That said tribal nationality is not internationally recognized anywhere.... that's why no passports. Moxy- 14:00, 18 March 2023 (UTC)[reply]

Just because Canada doesn't have the same designation of "domestic dependent nations" (original term) as the United States doesn't mean that First Nations aren't nations. "This is recognized by the Canadian government as well, meaning that both Canada and Indigenous Peoples maintain their own sovereign states. Sovereign states indicate that they are two separate governing states residing on the same land" (Karim). Canada negotiated treaties with First Nations. A treaty by definition is "a formally signed and ratified agreement between two or more nations or sovereigns" (Cornel Law School).

I was hoping more editors would contribute to this conversation, but it's mostly been Squared.Circle.Boxing who doesn't contribute to Indigenous articles. As stated before, the current MOS:INFONAT wording allows for US federally recognized tribes and Canadian First Nations to be listed in the "nationality" parameter under: " "When needed (e.g. due to change of nationality after birth, dual 'citizenship', or other unusual scenarios), use |nationality= unless |citizenship= is more appropriate for uncommon legal reasons." MOS:INFONAT mentions "country," only to say "use of either should be avoided when the country to which the subject belongs can be inferred from the country of birth." It is indeed difficult to infer tribal citizenship simply by county of birth.

Tribal nations fit the dictionary definition of "nation." It doesn't matter whether or not tribal nations fit the unwritten definition of "nation" by a particular user. I'm moving on. Current text is fine. Yuchitown (talk) 21:46, 18 March 2023 (UTC)Yuchitown[reply]

If the parameters should be avoided when the country to which the subject belongs can be inferred from the country of birth, then the implication is that the parameters should be used when the country to which the subject belongs cannot be inferred from the country of birth. Instructions for the citizenship parameter at Template:Infobox person specifically say Country of legal citizenship, if different from nationality. The current text is fine, and it doesn't support your position. And it's not my definition of the word nation, it's the Declarative theory of statehood's definition. – ².O.^Boxing 04:17, 19 March 2023 (UTC)[reply]

I know I need to give up beating this dead horse, but you are quoting "citizenship" perimeter. The infobox person "nationality" perimeter (the one I've been discussing this entire time) states: "May be used instead of |citizenship= (below) or vice versa in cases where any confusion could result. Should only be used with |citizenship= when they differ per WP:INFONAT. Do not put religion or ethnicity in this field. (See |birth_place=, above, for instructions on how to use this parameter, including: no flag templates, inappropriate linking, anachronisms, "country" definitions, etc.)." And as stated in my first entry on this discussion, US federally recognized tribes and Canadian First Natons are not ethnicities. The term is "nationality," which I've provided amble references (as opposed to just linking Wikipedia pages) addresses tribal nations; however, the wikilink you provided, states: "1) a defined territory; 2) a permanent population; 3) a government and 4) a capacity to enter into relations with other states." Those all apply to US federally recognized tribes and Canadian First Nations. Okay, moving on for real this time. Yuchitown (talk) 15:29, 19 March 2023 (UTC)Yuchitown[reply]

I'm also quoting INFONAT, which the instructions for the nationality parameter also quote. Your understanding of the definition of soverign state/nation/country is tainted by your personal views on the subject. Any infoboxes with tribal nations listed as a citizenship or nationality are against guidelines and should be removed. – ².O.^Boxing 16:55, 19 March 2023 (UTC)[reply]

Just wanted to say Yuchitown is probably right here and tribal governments in the United States meet the declarative theory of statehood. Also, as far as US law is concerned, tribal citizens are dual citizens. TulsaPoliticsFan (talk) 06:23, 8 June 2023 (UTC)[reply]

Perhaps we should remind ourselves of MOS:INFOBOXPURPOSE: "The less information it contains, the more effectively it serves that purpose". Edwardx (talk) 17:12, 19 March 2023 (UTC)[reply]

An RFC about the infobox of the two general elections in Italy, is being held.--Scia Della Cometa (talk) 08:46, 8 April 2023 (UTC)[reply]

Please contribute. Cinderella157 (talk) 23:50, 12 April 2023 (UTC)[reply]

I see there's at least one previous section and an RfC on this issue above, but I don't see where it's been discussed previously in relation to heraldic tinctures.

Giltsbeach made their first edit on March 23 and has been editing in the field of heraldry. On April 1, they took two editors to AN/I for disagreeing with them: Wikipedia:Administrators' noticeboard/IncidentArchive1124#User talk:JalenFolf and User:Mako001. The section was archived after JalenFolf expressed satisfaction that Giltsbeach had not removed information, but when I examined Giltsbeach's edits at Sable (heraldry) their opening statement at AN/I turned out to be accurate: they had removed a section from the article on grounds of the information being in the infobox. Giltsbeach asserts consensus to have this information—on "poetic designations", in other words flowers and gemstones (and in some versions of the articles, metals) that became associated with the tinctures in alchemy and early modern heraldry, see the table at the top of Tincture (heraldry)#List—only in the infobox of the tincture articles on grounds of triviality, which I believe to be the reverse of the guidance. I joined the section that JalenFolf had started at Talk:Sable (heraldry)#Poetic meanings section and edited the article twice: the first time endorsing the rollback by Mako001 while making other changes, the second time again restoring the article section and also reverting a strange layout change that Giltsbeach has since self-reverted. This received a revert by Giltsbeach alleging vandalism as well as editing against consensus. The section on the article talk page failed to change Giltsbeach's mind or to attract participation by anyone else, so on April 5 I started a section at WikiProject Heraldry and vexillology to determine whether there was indeed a local consensus to override project-wide guidance on this matter.

This attempt at discussion also failed to attract a response from any other heraldry editors. Giltsbeach's last engagement with the issue on talk is the identical uncivil personalization at the WikiProject and the article talk. So I then did my own research and I believe I found the origins of the WikiProject deviating from the guidelines back in 2018, in the aftermath of Ssolbergj creating Template:Infobox heraldic tincture and adding it to Gules: this edit by Dbachmann. I put a lengthy report, including pinging the two editors who apparently originally discussed and developed both the sections and the table at the Tincture (heraldry), into the WikiProject discussionon April 8. It's now April 19 UTC and there has been no response; other than Citationbot, no one has further edited the Sable article except Giltsbeach. I appreciate Giltsbeach's willingness to work in a recondite field, and I assume they bring useful knowledge, but I can see no reason for this to be an exception to the guideline that information that can be comfortably accommodated in the article should be there as well as in the infobox. Not all readers read the infobox in preference to or even as well as the article prose, and this is not highly technical, statistical, or graphical material. The "consensus" appears to have come about by oversight, which was why one article, the sable article, still had the information in the article prose. So I can't see even that reason for an exception. Is there one that I'm missing? Yngvadottir (talk) 01:49, 19 April 2023 (UTC)[reply]

Please make more explicit the issue of guidance being contradicted that you are addressing here. Cinderella157 (talk) 02:18, 19 April 2023 (UTC)[reply]

The guidance page begins with this overview: keep in mind the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article (an article should remain complete with its summary infobox ignored, with exceptions noted below). The only information about exceptions that I can find is in the next paragraph: there will be exceptions where a piece of key specialised information is difficult to integrate into the body text, but where that information may be placed in the infobox. and belownoting less than perfect compliance and further technical/tabular examples: Be aware that although all information in an infobox ideally should also be found in the main body of an article, there isn't perfect compliance with this guideline. For example, the full taxonomic hierarchy in {{Taxobox}}, and the OMIM and other medical database codes of {{Infobox disease}} are often not found in the main article content. Giltsbeach's first edit to the Sable article, on April 1, violates this guideline by removing a section from the article, leaving only the listing of that information in the infobox. So did Dbachmann's 2018 edit at Gules, which I linked above. Giltsbeach then edit warred over removal of the article section, culminating in their opening the AN/I against the two editors who had reverted them: their rationale at AN/I is explicitly contrary to the guideline in that they assert the prose section is undue because the information is in the infobox: I made an edit to the Sable (heraldry) article to remove a subsection with redundant information that was given undo weight. The information was already found in the infobox to the right of the page, and remained there with my edits. On the article talk page, they also asserted triviality as well as local consensus: The poetic interpretation isn't a key fact, it's trivial. A fad. ... The rest of the tincture articles follow this style. The community has already come to a consensus on this. Its not being a key fact is a reason to exclude it from the infobox rather than from the article, its being trivia is a reason to exclude it from the entire article (neither of which I am advocating; it's referenced information), and it is not difficult to integrate into the body text. Yngvadottir (talk) 03:02, 19 April 2023 (UTC)[reply]

Yngvadottir, in general terms, I would agree. In more specific terms, this is a content dispute that I really don't want to be drawn into. The way to gather greater participation would be through an RfC. As a word of advice, an RfC would need to be succinctly stated. Your comments tend to be very long and have the appearance of being a wall of text. Many people just aren't going to persevere. Cinderella157 (talk) 04:15, 19 April 2023 (UTC)[reply]

I do understand about the wall of text; but you asked me to spell it out :-) I don't see it primarily as a content dispute; the information is still there, just only in the infobox. Or yet primarily as a conduct issue. It's a matter of whether the guideline remains valid, and the same point of contention has come up here before. So I bring it to the MOS wonks :-) I'm prepared to be schooled on why this constitutes a valid exception to the guideline (you suggest you broadly agree with me that it isn't, but there may be a relevant discussion somewhere that I've failed to find, or some other precedent for "trivial" material being confined to the infobox even if referenced). Alternatively, maybe the guideline no longer reflects actual practice and requires some rewriting; that would make an RfC here desirable. Since local consensus shouldn't trump project-wide consensus, I don't think an RfC at the WikiProject would be advisable. But I'm not at that point; I'm seeking knowledgeable input, since I didn't receive explanations from anyone except Giltsbeach. As I say, maybe I'm wrong. I am very much not an MOS wonk :-) Thanks for looking! Yngvadottir (talk) 08:37, 19 April 2023 (UTC)[reply]

As per Cinderella157, this is partly a content dispute, but on the general point, information in the infobox needs to be somewhere in the article as well. Bondegezou (talk) 15:25, 19 April 2023 (UTC)[reply]

Thanks for confirming my impression that there is no reason for these articles to be an exception to the rule. I'm sorry again for the length. One reason for it was that I wanted to be clear that I'd tried to discuss the matter on both the talk page of the article where I ran into it and at the WikiProject. Since there have been no further responses in either, and no defence here from Giltsbeach (note that I also did my best to summarise their rationales), I intend to reinsert the sections into all the heraldic tincture articles. If Giltsbeach reverts again, I'll consider it a conduct issue; no one has agreed with their position on the issue. Yngvadottir (talk) 21:06, 27 April 2023 (UTC)[reply]

This issue has already been hashed out on the admin noticeboard, on the article talk page, and on the Heraldry WikiProject page. My position is already well established. You are clearly fighting a war of attrition. Anyways, you are very well aware that the only other editor to chime in on the subject came around to my side [6]. You are lying when you say no one has agreed with my position. You are the one that has failed to gain a single supporter. You are the one that could not build a consensus. If you continue to lie and edit without consensus then I will escalate your behavior to the appropriate noticeboard. Giltsbeach (talk) 22:14, 27 April 2023 (UTC)[reply]

A follow-up note. I attempted to summarize Giltsbeach's statements and the outcome of their AN/I report, but it is always possible I failed in some respect. Since here, too, they were the only one arguing for an exception from the guideline, I went ahead and reinstated the section to Sable (heraldry) and Gules, then to the other tincture articles. In doing so, I found that Giltsbeach's assertion that all the articles except Sable had the information only in the infobox had been mistaken. Several articles still had either a section or a paragraph without a section heading. There was no consistency. There is now, following the guideline, and I also looked for and added references for the material where there was none. Yngvadottir (talk) 00:50, 3 May 2023 (UTC)[reply]

The manual of style requires consensus for such edits. Giltsbeach (talk) 09:37, 3 May 2023 (UTC)[reply]

Yngvadottir, I agree with you that if the infobox has material like this in it, it ought to be mentioned in the body of the text. I support the idea of adding a short section to any of these articles that have equivalent information in the infobox. Girth Summit _(blether) 17:08, 3 May 2023 (UTC)[reply]

Thank you, Girth Summit. I brought this here as a last resort, laying out my previous attempts to discuss the matter, and only then found that not only was no prior discussion in the WikiProject to be found, but there was not even the consistency among articles that Giltsbeach had claimed. (So as I stated here, some of my edits restored the section, others tightened an existing section and/or set it off with a heading.) I have just seen the AN/I section, haven't yet looked at the articles, but IMO this is the correct noticeboard to establish that an exception should be made, and that case has not been made. Yngvadottir (talk) 21:18, 3 May 2023 (UTC)[reply]

The information that Yngvadottir wants to add is dubious and/or unsourced. They are referencing elements , planets, constellations, etc. Heraldry has nothing to do with this mystic alchemy stuff. If you look at the main tincture article you will see that the poetic representations section has many issues with it and it and this information probably shouldn't be included at all in the articles. [7] Giltsbeach (talk) 01:48, 4 May 2023 (UTC)[reply]

There is currently a discussion at Wikipedia:Village pump (proposals)#RfC on establishing a biography infobox guideline regarding changes to infobox guidelines found on this page. Nythar (💬-🍀) 18:56, 2 May 2023 (UTC)[reply]

Editors' comments are sought at Talk:H._A._Willis regarding whether the infobox should note that one child has died. Mitch Ames (talk) 06:40, 14 May 2023 (UTC)[reply]

Template talk:Infobox legislative election#Survey has a discussion that some here might find interesting.

Personally, I think there’s an unfortunate trend for ever larger election infoboxes, but others may disagree! Bondegezou (talk) 12:35, 17 May 2023 (UTC)[reply]

Please see Template talk:Infobox person#Template:Age for a proposal regarding {{age}} whereby, when a date is unknown, it would change from showing a single number to a range of ages. Johnuniq (talk) 03:53, 9 June 2023 (UTC)[reply]

Relisted for further input. Cinderella157 (talk) 11:37, 22 June 2023 (UTC)[reply]

In this page Second Siege of Anandpur, an editor has repeatedly added a figure in the infobox from Koer Singh - an 18th century writer, who wrote detailed exegeses on the Sikh religion and explications on Sikh history, particularly about Guru Gobind and the events that transpired throughout his life. Koer Singh's work Gurbilas Patshahi 10 was composed from 1751-1762-. The source being used on the Wikipedia page is a reliable Oxford University published source, however much of the book is written in a tertiary tone, merely presenting an accumulation of summaries of primary sources, with little to no original commentary, intepretation or analysis from the author.

The book [8] reads Koer Singh says that after the institution of the Khalsa......Consequently sent an army of 10,00,000 [this is how 1 million is enumerated in India] against Guru Gobind Singh. The entire section preceding and after this is just recounting what the sources at that time said, the author does not seem to endorse or dismiss any particular narrative.

So should this 1 million figure be included in the infobox or not? On a side note, 1 million is an obvious figure of speech, sending 1 million men to besiege a few thousand belligerents would have been an incredible anomaly, iirc the entire Mughal army at it's zenith was 1 million, however that is being wilfully neglected, in my opinion, to push a narrative. Southasianhistorian8 (talk) 22:34, 2 August 2023 (UTC)[reply]

The redirect Wikipedia:DIT has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 September 29 § Wikipedia:DIT until a consensus is reached. Isla 🏳️‍⚧ 10:39, 29 September 2023 (UTC)[reply]

In a recent constructive discussion between MyCatIsAChonk, Nikkimaria, Sdkb, NebY, Folly Mox and Gawaon, an idea emerged that elegantly realizes MOS:INFOBOXPURPOSE's principle "key facts at a glance": Instead of just naming a link “List of operas”, name it "Thirty-nine operas". I think that idea merits inclusion in this MOS. ◅ Sebastian Helm 🗨 11:51, 23 October 2023 (UTC)[reply]

What specifically would you propose to add to this MOS to reflect that idea? Nikkimaria (talk) 21:33, 23 October 2023 (UTC)[reply]

How about something like “Use a pipe link with a number like [[List of operas by Gioachino Rossini|39 operas]].” (Writing the number as a figure per MOS:NUMERAL, differently from what MyCatIsAChonk had). ◅ Sebastian Helm 🗨 08:29, 9 November 2023 (UTC)[reply]

Please make the number optional. For living composers, it will change, for prolific composers, it may be hard to find, and will raise questions such as if unfinished works also count. I just added to the Rossini discussion, believing that even without a number, a link to a composer's works is a highly useful link from a composer's article. --Gerda Arendt (talk) 09:09, 9 November 2023 (UTC)[reply]

Agreed. — SebastianHelm 13:22, 9 November — continues after insertion below

I wonder ,though, if the problem for living composers could be solved with a template or Lua function returning the count of a category, as in {{countcat|Operas by Gioachino Rossini}}. However, that would currently yield 43, rather than 39. One too many from The Barber of Seville discography, which should be fixed by correctly putting that article in category:The Barber of Seville‎, but I don't know where the other 3 are coming from. ◅ Sebastian Helm 🗨 13:22, 9 November 2023 (UTC)[reply]

List of operas by Gioachino Rossini is also in the category. List of operas by Gioachino Rossini lists Ivanhoé and Robert Bruce in the Pasticci table but they are included in the category — GhostInTheMachine ^{talk to me} 18:44, 9 November 2023 (UTC)[reply]

Thanks, Ghost! That explains it. So, the function would need to omit entries piped to space, as the main article. Maybe that could then be used to check for consistency by a bot. ◅ Sebastian Helm 🗨 20:36, 9 November 2023 (UTC)[reply]

There is then the issue of discography articles and other list-like articles. They should probably be sorted with an asterisk and the test is then to exclude articles with any non-alphanumeric sort key. — GhostInTheMachine ^{talk to me} 21:04, 9 November 2023 (UTC)[reply]

Good idea. ◅ Sebastian Helm 🗨 21:44, 9 November 2023 (UTC)[reply]

Is there any policy on wikilinks? The project page doesn't appear to mention them. Some infoboxes include wikilinks to articles to which there are also wikilinks from the text. Are links from an article's text preferable to links from its box? Are there exceptions? Are there cases when links from both are desirable? Mcljlm (talk) 22:40, 7 November 2023 (UTC)[reply]

The infobox is generally treated as if separate from the article for this purpose. Anything that would be contextually sensible to link at least once in the article is also sensible to link in the infobox, and vice-versa. Our guideline on re-liking things also changed pretty recently; we now link stuff one per section instead of once per article, because we know that most of our readers are jumping around all over the place, not reading articles from top to bottom.  — SMcCandlish ☏ ¢ 😼  01:06, 8 November 2023 (UTC)[reply]

SMcCandlish Thanks. Some sections are brief. Linking a word once per section could mean linking the same thing several times within a few lines. A few hours ago I came across an article where someone mentioned in the lede was linked in 2 sentences one after the other. Then I noticed he was also linked in the lede's last sentence. That was in addition to an infobox link. The same lede also had someone else linked twice.

Someone else mentioned in the lede (only by his surname) isn't linked until he's mentioned in a later section. Presumably now he should be linked there as well as later. Mcljlm (talk) 04:41, 8 November 2023 (UTC)[reply]

Actually, MOS:REPEATLINK says to linke once per article and, "if helpful", again at the first occurrence in a section (and tables, captions, infobox, etc. "if helpful"). So, it's not that different a standard than it used to be. -- Ssilvers (talk) 04:52, 8 November 2023 (UTC)[reply]

Well, yes, I did not mean to imply that linking once per section is mandatory, rather just permissible. As with all things, excercise common sense. If there are a bunch of a very short sections, linking the same thing in back to back instances of such micro-sections isn't going to be useful. One should also consider whether the article structure needs work, since we generally shouldn't have microsections unless we expect them to be expanded in pretty short order. Anyway, the point for the OP is that if a link would be useful in the main body, it will pretty much by definition be useful in the infobox, since many readers read nothing but the infobox or a fraction thereof.  — SMcCandlish ☏ ¢ 😼  12:59, 8 November 2023 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 [9] 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:[10] 456legendtalk 00:58, 2 March 2024 (UTC)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

Does MOS:FORCELINK prohibit linking to notable works from an infobox[[11]]? 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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

  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)[reply]

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)[reply]

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)[reply]

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)[reply]

(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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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.

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

• 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)[reply]
• 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)[reply]
• Per above. Please keep infoboxes concise and include only key facts. -- Ssilvers (talk) 01:40, 8 March 2024 (UTC)[reply]
• 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)[reply]
• Per Nikkimaria above. Ajpolino (talk) 17:01, 13 March 2024 (UTC)[reply]

• 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)[reply]
• 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)[reply]
• 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)[reply]

  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)[reply]

• 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)[reply]
• 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)[reply]
• 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)[reply]
• 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)[reply]
• 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)[reply]

  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)[reply]

  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)[reply]

• 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)[reply]

  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)[reply]

• 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)[reply]
• 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)[reply]
• No MyCatIsAChonk and Gerda Arendt.  Spy-cicle💥  ^Talk? 20:35, 15 March 2024 (UTC)[reply]
• 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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

(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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

  "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)[reply]

  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)[reply]

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

  @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)[reply]

  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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

• 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)[reply]

  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)[reply]

  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)[reply]

  • 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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

  @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)[reply]

  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)[reply]

  • 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)[reply]
  • 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)[reply]
• 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)[reply]

• 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)[reply]

  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)[reply]

  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)[reply]

• 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)[reply]
• Support --Gerda Arendt (talk) 22:14, 15 March 2024 (UTC)[reply]
• 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)[reply]

  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)[reply]

• Support 🌺 Cremastra (talk) 22:22, 15 March 2024 (UTC)[reply]
• 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)[reply]
• 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)[reply]

  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)[reply]

• 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)[reply]

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

  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)[reply]

  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)[reply]

• 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)[reply]
• Oppose per my reply above, as well as the important, basic observation made by Ssilvers. 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)[reply]
• 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)[reply]
• 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)[reply]

• 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)[reply]
• 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)[reply]
• 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)[reply]
• 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)[reply]

  @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)[reply]

  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)[reply]

• 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)[reply]
  • 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)[reply]
• 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)[reply]
• Oppose. Present text is more succinct, clear, consistent, and incontestable than the proposed text. DrKay (talk) 07:50, 16 March 2024 (UTC)[reply]
• 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)[reply]
• 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)[reply]
  • 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)[reply]

    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)[reply]

• 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)[reply]
• 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)[reply]
• 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)[reply]

  @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)[reply]

• 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)[reply]
• 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)[reply]

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

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

  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)[reply]

  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)[reply]

• 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)[reply]

  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)[reply]

• 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)[reply]
• 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)[reply]

  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)[reply]

• 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)[reply]
• 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)[reply]

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

• 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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

  It failed, which is as good as a consensus, given status quo. - SchroCat (talk) 12:34, 17 March 2024 (UTC)[reply]

• 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)[reply]
• 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)[reply]

• 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)[reply]

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

  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)[reply]

  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)[reply]

  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)[reply]

• 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)[reply]