Wikipedia talk:Manual of Style/Infoboxes/Archive 14

ArbCom wants there to be an RfC and the drafting of infobox inclusion criteria
Twice (at WP:ARBINFOBOX and WP:ARBINFOBOX2 the WP:Arbitration Committee has stated that the community needs to hold an RfC on what to about infoboxes, because "use of infoboxes is neither required nor prohibited" isn't helping and just seems to cause circular, endless page-by-page and sometimes category-by-category fighting. I'm not sure what this RfC should say, but we've been directed to try to draft some kind of "when an infobox should/shouldn't be included" guideline.  The community is actually pretty good at that sort of thing; we have all kinds rules about proper categorization, navbox templating, lead content, etc.  Whatever is drafted should be proposed at the Village Pump, since it's a site-wide matter.

However, this need for a draft infobox inclusion guideline points out another long-standing problem: Infoboxes are mostly not a style matter, but a content one. We need to split this page into WP:Infoboxes (WP:INFOBOX) and WP:Manual of Style/Infoboxes (or perhaps just WP:Manual of Style/Layout; MOS:INFOBOX either way), and separate the content material from the style material, the same as we have with other things. Needs to happen eventually, and I suspect the forthcoming inclusion criteria would be the central matter of a WP:INFOBOX content guideline, around which the other content-not-style material in the current page can be framed. PS: A literal page split might not be needed; WP:Stand-alone lists is a content, style, and naming conventions guideline, with different sections tagged with the right banner templates, and this seems to work fine, and is less bureaucratic than splitting the page. (It also matters for WP:AC/DS reasons; disruptive editing in style and naming discussions is subject to DS, while it is not with regard to content guidelines.) — SMcCandlish ☏ ¢ 😼  04:30, 8 July 2018 (UTC); revised: 23:35, 8 July 2018 (UTC)
 * I welcome clarification on infobox use. Recent debate over having two infoboxes in a very short article showed to me the ongoing issues with their use: see Talk:Green Party of England and Wales leadership election, 2018 and Green Party of England and Wales leadership election, 2016. Happy to input. Bondegezou (talk) 15:25, 8 July 2018 (UTC)
 * I'm puzzled by this: currently WP:ARCA does not contain the word "infobox", WP:ARBINFOBOX dates to 2013, and WP:ARBINFOBOX2 ran between January and March this year. I see no sign that "use of infoboxes is neither required nor prohibited" can or should be replaced. Actually I thought things have calmed down considerably, not least because some of the most vociferous "infoboxes everywhere" people are now more on Wikidata. I suggest you find something else to do over the summer. Johnbod (talk) 16:23, 8 July 2018 (UTC)
 * Relax ; you needn't be puzzled at all (IMHO). The fact is: this discussion would have been served better if "don't template the regulars" had been the order of the day. You've certainly enough wiki-tenure to have seen the sign that it can, many times. Whether it should or not is a matter that we can decide, and if so, how to improve it as well. Your insight is sorely missed in answering the core questions raised by the OP. I hope you'll consider rededicating that part of yourself since you obviously have a great deal to potentially give.--John Cline (talk) 17:52, 8 July 2018 (UTC)
 * No one said the wording should be (though that might end up happening depending on what the eventual RfC/proposal results are); rather, that it causes circular dispute when there are no criteria for deciding whether a particular article should/shouldn't have an infobox).  ARCA isn't archived in the straightforward way a lot of other process pages are (which is a major butt-pain when you're trying to find this stuff!), but rather under a case to which the request pertains.  The recent ARCA in question has to be dug out of the page history, and can be found here, or where it has been archived under ARBINFOBOX (not ARBINFOBOX2, for some reason), here. I've added a link to it to my original post, above.  — SMcCandlish ☏ ¢ 😼  20:55, 8 July 2018 (UTC)
 * The problem is that there really isn't an easy way to resolve anything with an RfC. While we could feasibly get a result saying all articles of X category should have an infobox, and all articles of Y category are exempt from this requirement, that really just puts us in the same position as now. The only area that I've seen controversy is generally with various biographical artist articles, so even if we could get agreement for all other types of articles having mandatory infoboxes, it isn't going to change the problematic ones. There is no chance of an RfC coming down with the decision that "articles of Z category should not have infoboxes", so really the only outcomes will be what we have now, or infoboxes being mandatory. Given this, it is natural for infobox opponents to consider any proposal for an RfC to be an attempt to force infoboxes down their throats. I am personally of the mind that having a very simple infobox doesn't cause any issues, helps to unify a cohesive look of Wikipedia, and also would result in less disruption if they were made mandatory for all articles (there would still be discussion about which parameters to include in infoboxes, but this is less disruptive than the repeated RfCs seen on some articles). While we might get a consensus for something like this, I doubt that it is going to happen. —  Insertcleverphrasehere (or here)  21:14, 8 July 2018 (UTC)
 * You are right that only certain types of article raise disputes (though there are more than you mention). There are other types that almost always have them and others that almost always don't, both without friction. I don't see any reason why a result might not say all articles of X category should have an infobox, and all articles of Y category should not. But it would be tough getting there. Johnbod (talk) 21:51, 8 July 2018 (UTC)
 * On this sort of thing, I quite agree with your opening statement. This needs to be a about how we even get to criteria before there's any RfC on exact proposed criteria. I think the range of criteria would can consider, however, could obviate some of your concerns (which aren't just "your concerns", of course, but rather easily observable historical problems with the debate about infoboxes).  In particular, approaching it from "my topic versus your topic" perspective has been the primary source of conflict, and has been the main thing that ArbCom has come down against (along with hammering on the civility problems that emerge from that kind of debate), while generally skirting the larger question because the community is sitting on its thumbs.  I've long remained neutral on infoboxes (early on, I began being opposed, switched to being in favor, and for about a decade now have been listening to both sides, though I've !voted in favor of or against particular i-boxes at particular articles based on utility-to-reader analyses).  In a sub-thread below, I'll suggest some initial criteria talking points when I'm done drafting them in a few minutes. Someone has to get the "meat" of the discussion cooking.  — SMcCandlish ☏ ¢ 😼  21:58, 8 July 2018 (UTC)
 * , ARCAs that become motions end up as a link at the bottom of the main page of the corresponding case. See this section of the case and the link labeled motion. StarryGrandma (talk) 21:49, 8 July 2018 (UTC)
 * Yes, I know; I already linked this (just in a different format and also to the original diff at ARCA itself) in previous post.  — SMcCandlish ☏ ¢ 😼  21:58, 8 July 2018 (UTC)
 * Ok, now we've found it, can you quote the bit from it where "the WP:Arbitration Committee has stated that the community needs to hold an RfC on what to about infoboxes" as you say at the start of the section? I can't see one. WP:ARBINFOBOX2 has "The Arbitration Committee recommends that well-publicized community discussions 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 and how those factors should be weighted" from this March. Johnbod (talk) 22:42, 8 July 2018 (UTC)
 * Please hold; the ARCA link is wrong. Let me dig up the right bit.  — SMcCandlish ☏ ¢ 😼  23:28, 8 July 2018 (UTC)
 * Never mind; it's just WP:ARBINFOBOX and WP:ARBINFOBOX2; the ARCA bit isn't relevant. I was thinking of another case (where WP:ARBAP and WP:ARBAP2 pre-date 2018, and new ARCA material this year had come up about the central issues still being ongoing). The more recent action about infoboxes at ArbCom  ARBINFOBOX2.  Sorry about that. I'll revise the OP above to compensate. The material you quote from ARBINFOBOX2 is the meat of the matter, along with previous (less directive, more "hand-wringing") material in ARBINFOBOX: "Because there is no project-wide policy governing when infoboxes should be used, disagreements concerning their inclusion arise with some regularity ... too often the consensus-building process has broken down, in a fashion that has been extremely demoralizing to many editors. ... It is not clear how infobox disputes are to be resolved ... there is no default rule and no policy guidance for determining how the consensus is to be determined, so the dispute continues indefinitely".  — SMcCandlish ☏ ¢ 😼  23:35, 8 July 2018 (UTC)


 * Multiple Infoboxes in an article – when is that appropriate and how many should be the maximum? Mojoworker (talk) 18:35, 13 July 2018 (UTC)
 * That whole question is complicated by infobox nesting. We're moving more toward that model (see, e.g., Andrew Lloyd Webber as of this writing). It can even have clear benefits (at that article, I was able to shunt all details that did not pertain to his central notability into the embedded officeholder box, and thus group them at the bottom, away from what readers are most likely to care about). The days of literally having one infobox right after another one are numbered.  — SMcCandlish ☏ ¢ 😼  00:50, 14 July 2018 (UTC)
 * Currently, If a notable song is covered by another band, itself being notable, the cover version does not qualify for its own article (a practice with which I disagree). Nevertheless, the notable cover is, therefore, included as a section of the original recording and it most often includes an infobox (as songs generally do). For example: You Really Got Me by the Kinks includes their own live version as well as the Van Halen cover, both in their own sections, and both having an infobox. I suppose this process would repeat as many times as the song was notably covered unless we changed our current practice and allowed songs like You Really Got Me (Van Halen cover) to have their own page.--John Cline (talk) 07:41, 16 July 2018 (UTC)

Toward drafting criteria
We'll need to air out what of criteria the community might want to contemplate before drafting any actual proposal. An initial list of ideas (and this is hardly exhaustive):


 * 1) Level of article development: Is there enough detail to create an infobox that wouldn't substantively just duplicate the article prose?  This answer may be "no" for the average stub. This approach may not take into account the views of some editors that infoboxes are not appropriate at all for certain topics or certain kinds of topics.
 * 2) Article length: Related to but distinct from the above, especially for mobile users: Can an article be long enough that an infobox's bullet-point presentation is helpful, regardless of the number of templatable "factoids" that can be extracted from that content?
 * 3) Type of article and need for an abstract of details: In an article on a cell phone model, a city, a species, or an actor, readers are more likely to be looking for "vital statistics" than they are for someone notable only for one event, or a concept like rhoticity in English.
 * 4) Pan-category consistency: It may be jarring for readers to find infoboxes at most articles on biologists, but not for the one they're most interested in.  A problem with this broad-consistency idea is that few articles are in just a single category (and fewer actually  be). This also relates to the ArbCom-rejected idea that wikiprojects get to decide whether infoboxes are used on a cross-topic basis (deemed to be against WP:CONLEVEL and WP:OWN policies); few articles are within the scope of a single wikiproject, either.
 * 5) Pan-category : In some cases – usually when the infobox provides a special feature like the taxonomy chart in  – all articles in a category (even a very large one like organisms) have an infobox, and this appears to be uncontroversial. Attempts to apply this model to other categories have often been highly controversial (e.g., the suggestion that articles on classical music composers all should/shouldn't have infoboxes).  These sorts of disputes are the main ones (they're behind both of the ArbCom cases) and are most frequently about biographies.  If we recognize that infobox inclusion/exclusion is standardized in certain cases in actual practice, how do we square this with ArbCom ruling against wikiprojects dictating inclusion/exclusion?
 * 6) Pan-topic consistency: A variant of the above approaches would be to consistently use/avoid infoboxes across an entire topical group of articles covered by a navigation box.  This raises similar problems (many articles have more than one), plus the articles in a navbox may be of radically different kinds (bios, published works, concepts, locations, etc.).
 * 7) Hierarchical consistency: Another variant of this is the observation that hierarchical relationships tend more often to produce infoboxes (a politican under a government, a bishop under a church, a sportsperson under a team, a CEO under a company,  a professor under a university) than in article about "independents" (film directors, artists, writers, etc.). This seems most commonly to affect bios.  Is this a good idea? Is it just accident?
 * 8) The value added on a case-by-case basis: Are there cases where an infobox, even at a well-developed article of a sort that usually has one, isn't actually reader-helpful?  Are there cases were even a tiny stub benefits from one (e.g. due to specific features of the box in question)?  Previous debates suggest the answer to both questions is "yes".  But how can this be encapsulated in inclusion criteria?
 * 9) Presence or absence of an infobox in the first post-stub revision: MOS:STYLEVAR defaults to this on any intractable style dispute, but only as a last resort.  Is it very applicable here, given that the central concern is utility, and infoboxes are unlike, say, an argument about whether to use "next to" or "alongside" in a sentence? (The concept is sometimes misconceptualized as the preference of the first major contributor, which is a WP:OWN / WP:SUPERVOTE problem.) Other difficulties with this approach are that later changes to the article's scope and content could make an infobox much less or more attractive than it was early on; and infoboxes are primarily a content not style matter, and we do not apply such reasoning to content.
 * 10) The kind of information included (or, perhaps, what  be included) in an infobox: This is not very consistent. Some infoboxes generically summarize the article, while others have documentation limiting them to very specific data (e.g. only the first edition of a book, in ).  Should they be inconsistent in approach, or normalized, and what implications does this have for their inclusion at particular articles?  The novel example is a case of limitation of scope of the template, while  is the addition of a feature not suited to prose (full phylogenetic tree), and these seem qualitatively different.
 * 11) Questionably valid reasons to include/exclude. Some arguments may be fallacious, such as "it's disrespectful to condense this person's life into an infobox", or "I want people to read the entire article so that they fully understand the topic."; on the other side of the coin, "this type of article always includes an infobox", and "infoboxes are always useful". Should we list a few common non-policy/guideline-based arguments?
 * 12) Collapsing, either whole boxes or sections of them; whether doing this serves the reader or the purpose of having an infobox, or is merely as a "compromise" between exclusion or inclusion of an infobox. However, it impacts accessibility.
 * 13) Number of items: Many editors feel that an infobox that consists simply of the article name and a few factoids adds little to the article. On the other hand, many editors feel that an infobox with 100+ items is a monstrosity that detracts from the readability of the article. Should we establish guidelines on how many fields an infobox should have?
 * 14) Location of infobox Should the infobox always be in the lead? What about situations where multiple infobox templates apply to an article? (eg: NFL player and US congressmen Jack Kemp)
 * 15) Inclusion of image(s) and/or map When should an image be included in an infobox? Should there be a limit on how many images are included? Should maps be counted as part of such a limit? Should the aspect ratio of the images be considered? (As an example of an infobox with multiple images, Infobox school frequently includes the school's logo, an image of the school campus, and a map)
 * 16) Add probably several more ideas here..

Meta questions:  Should there be a general default? ArbCom has suggested that there should be (or at least that having one would reduce disputation). It's not clear if the community agrees with this, nor what that default would be if we did. Should we just make them a standard feature, absent a sold WP:IAR reason to exclude one? The majority of well-developed articles do in fact appear to have infoboxes. However, the above questions at least hint that they are not desirable in every single case and thus such a blanket rule might be WP:BUREAUCRACY. Should we just get rid of them? Not every experiment is a success, and various things that Wikipedia once deployed widely were eventually deemed to be bad ideas and removed (two obvious examples to old-timers are the use of spoiler alerts and wrappers in plot summaries, and the imposition of automated date formatting and linking).  

The central question before us is this (assuming the community agrees with ArbCom that the current "use of infoboxes is neither required nor prohibited" is not working):

How do we take the criteria we collectively decide matter for particular kinds of cases and compress them into a paragraph or bullet list of guideline wording, that will actually be better than the status quo of no criteria?

After some initial discussion, draft approaches to doing this for a future WP:VPPRO proposal should probably each be in its own section, if the discussion proceeds here to a drafting stage. Hopefully we can merge any conflicting approaches into a single cohesive proposal (perhaps with multiple options to choose from).

Posted originally by  — SMcCandlish ☏ ¢ 😼  22:11, 8 July 2018 (UTC) – with the explicit intent that people add to the lists as they see fit if this helps further the discussion. It could also be converted to a pro/con table, or whatever.


 * First of all, can we make a list of the current status quo in terms of where infoboxes are controversial, commonly used, or commonly not used (topics and types of articles/number of valid criteria etc)? From there we can build a picture of what we have currently, draft it as a guideline, and then decide if anything on that list needs changing. —  Insertcleverphrasehere (or here)  22:24, 8 July 2018 (UTC)


 * I will add another consideration that I had thought of when the last batch of infobox wars came up, and that's how well the person falls into a "hierarchy" organization that an infobox readily serves. For example, a politican (as part of a government), a bishop (as part of a church), a professional athlete (as part of a team), a CEO (as part of a company), or a professor (as part of a university). Whereas where infoboxes tend not to be added are for those that do not readily fall into such hierarchies (film directors, artists, writers, etc.). The only bright line from this is that the infobox should be included when the person falls into a hierarchy; this should not mean that a person that doesn't fall into this case should not have an infobox, but it should not be demanded either. That doesn't solve all the problems, but this seems like the brightest line where we do include infoboxes without question. --M asem  (t) 22:26, 8 July 2018 (UTC)
 * Wikipedia only has biographies? Johnbod (talk) 22:29, 8 July 2018 (UTC)
 * Perhaps what Masem may be getting at is that bios seem to be the ones where infoboxes are potentially controversial? I, too, would echo Insertcleverphrasehere's request for making a list of where infobox inclusion is controversial / used / not used. It would probably help in creating a guideline. Killiondude (talk) 22:41, 8 July 2018 (UTC)
 * Perhaps, but if he thinks that he is wrong. Musical and artistic works and movements produce at least as many disputes in my experience. Johnbod (talk) 22:45, 8 July 2018 (UTC)
 * The only infobox wars that I've seen get out of hand (to the point Arbcom intervention has come up before) have been on BLPs; I was not aware that non-BLPs had this though I don't doubt if any had happened there. --M asem (t) 23:51, 8 July 2018 (UTC)
 * People have spilt blood over infoboxes in classical music articles—WikiProject Classical music used to ban them entirely in their guidelines. Curly "JFC" Turkey 🍁 ¡gobble! 00:58, 9 July 2018 (UTC)
 * Anecdotally, infoboxes are seemingly not useful in some cases: I wrote Columbia-Southern Chemical Corporation then another editor added an infobox; I have never removed it (not worth a potential disagreement) but have always thought that it is not particularly appropriate or helpful. — Godsy (TALK CONT ) 00:54, 9 July 2018 (UTC)
 * In that particular case I would agree and say that as it currently stands it is pretty useless. To me though it seems to be an example of an underutilised Infobox, which would be better suited by filling in more of the relevant fields rather than removing the IB. The main issue is with other types of articles where there really isn't much of import to say in an infobox (where I believe that there is a valid argument for no-infobox). I think that there is generally always enough information that could be filled into company infoboxes, even if it isn't always there right now (analogousto why we don't delete all short stub articles). —  Insertcleverphrasehere (or here)  05:45, 9 July 2018 (UTC)


 * I don't know where this would fit in, but we should also discuss the kind of information to include in infoboxes. I stopped using them entirely for articles on novels when WikiProject novels insisted the information in novel infoboxes must be about the first edition (including first edition ISBN, cover image, and page count), rather than a general summary of the subject (which is the approach of virtually every other infobox on Wikipedia). Curly "JFC" Turkey 🍁 ¡gobble! 01:03, 9 July 2018 (UTC)
 * Both that and your point above about classical music non-bios, plus the nature of the (mostly music-related) bio disputes that went to ArbCom, would seem to indicate that wikiprojects trying to make up "rules" (their page layout advice pages are essays, not guidelines) is a proximal cause of at least some types of this dispute. A point made below is that we might try to nail down what is already being done across what topics where something consistent is happening, then try to establish some specifics in WP:INFOBOX (an actual guideline) that covers these cases, in addition to some general principles. However, this seems like a lot of work, and it could also end up enshrining one particular view in a long-running dispute (e.g., composers again).  Hopefully just figuring out general criteria will avoid that, perhaps if we also take note of "special use" infoboxes that do more than summarize the article (e.g., which was actually the original infobox). Some infoboxes are also straying into navbox territory (e.g.,  has features for navigating between releases, including often with little album-cover pictures); this complicates things.  And them doing nav things is not necessarily a good idea in the first place.  — SMcCandlish ☏ ¢ 😼  02:13, 9 July 2018 (UTC)
 * I find infoboxes useful. When I'm looking something up, I can quickly find some information I want: e.g. who directed this film, when was this person elected. And yet I hate infoboxes, or rather I hate the endless editing disputes they seem to produce. In my experience, those are more often not around whether to have an infobox or not, but about what should go in the infobox. I wonder whether it's not that we need more guidance on when to use infoboxes, but we need more guidance on what to do with infoboxes. My experience is of three sorts of generic problems:
 * Infobox bloat: despite existing guidance saying infoboxes should be short summaries of an article, we get increasingly large infoboxes. Examples would be Doctor Who, Salbutamol, Margaret Thatcher and French legislative election, 2017. Those are all quite well designed infoboxes full of information, but they're not short summaries. And not all the information seems that important. Compare the brief infobox for Led Zeppelin. These big infoboxes are not how infoboxes were initially conceived. Do we want large infoboxes or should that material be integrated back into the article? Is Wikipedia trying to write a set of articles, or a set of infoboxes? It sometimes feels like the latter.
 * Infobox importance: there is a certain fetishisation of infoboxes, as if they are the most important part of an article. People insist there must be an infobox as if that indicates a certain cachet, e.g. Talk:Green_Party_of_England_and_Wales_leadership_election,_2018, which was about having a second infobox in a short article. There are endless disputes over what political parties to list in election infoboxes, e.g. Talk:United_Kingdom_general_election,_2017/Archive_5.
 * Infoboxes are bad at fuzzy situations: the nature of the infobox requires simple answers. Reality isn't always simple. Sometimes we're not certain about someone's date of birth. Or there's more than one way to define how many seats a party won. In article prose, the text can explain all that, but infoboxes generally display one thing. I often find myself to tell people to focus on explaining the uncertainty/fuzziness in the text, or to use a footnote in the infobox. But editors get very blinded by local rules for what must be shown how. For example, The Matrix lists the director of the film as The Wachowski Brothers, even though Wikipedia policy is to respect their self-identification as female: thus The Wachowski Brothers re-directs to The Wachowskis. But the local consensus is that the infobox must say the same as what the film credits say (even though this rule is not applied in other situations): see Talk:The_Matrix. This is all much easier to handle in prose. Bondegezou (talk) 11:04, 9 July 2018 (UTC)
 * A rule of thumb I've often used is that the infobox should contain information that is essential for a concise summary of the subject—that is, the absence of these characteristics and facts would leave a significant gap in understanding or in traditional historical context (e.g. birth date / year of establishment / etc.). It's a subjective criterion, but one I have found useful in trying to frame the importance of including something in an infobox. isaacl (talk) 15:59, 9 July 2018 (UTC)

Alternate idea - do nothing
No one is perhaps a bigger proponent of infoboxes than me, but even I recognize that any attempt to lay out specific criteria for when an infobox must be included is foolhardy and limits the creative potential of the editors. We should be more open to new ideas and less hung-up on rigidly regulating aspects of presentation. A long time ago, we had no infoboxes, then someone tried one and it worked, so it was used in other articles, and usage grew... and now we've been asked by ArbCom to codify their usage. But who among us can say with certainty that infoboxes are the best way to present information in our articles? We should allow editors to continue to experiment with the format. Coming up with a rigid set of criteria under which we must require their use will stifle inventiveness. I say we, politely, decline this request from the ArbCom. -- Netoholic @ 02:40, 9 July 2018 (UTC) — SMcCandlish ☏ ¢ 😼  07:59, 14 July 2018 (UTC)
 * Enthusiastic support. The less rigid our rules on presentation are, the more we have a chance to come up with creative improvements. Infoboxes are good ways to display information in some articles, but not in others (one classic case biographies of people notable in more than one field, or where parts of the infobox would need to contain disputed material with extensive annotations). Instead of forcing infoboxes on certain classes of articles (which then will require workarounds for the inherent weaknesses of infoboxes), we could just use what works in each case. —Kusma (t·c) 02:57, 9 July 2018 (UTC)
 * We're doing nothing, and this has led to repeated ArbCom cases, otherwise productive editors being sanctioned (we may have lost a WP:FAC regular over this permanently) and ArbCom repeatedly asking the community to settle this.  The fact that "forcing infoboxes on certain classes of articles" is problematic is part of the discussion, not a reason to not have the discussion.  — SMcCandlish ☏ ¢ 😼  03:06, 9 July 2018 (UTC)
 * Those are behavioral concerns. We are allowed to say that the ArbCom may be wrong in asking for us to codify infoboxes, because we'll be sacrificing flexibility to maybe help with the bad behavior (but more likely, at best shift, the bad behavior or, at worst, even increase it). Infoboxes are already pervasive and we haven't needed to enforce their use to get them to be so. I for one want to see if any new ideas can come from freedom. -- Netoholic @ 03:23, 9 July 2018 (UTC)
 * How would you codify such freedom? Doing nothing will not increase editorial freedom to do anything.--John Cline (talk) 04:33, 9 July 2018 (UTC)
 * Right. The freedom Netoholic seeks already the status quo, and is the cause of the perpetual conflict; it's a "Wild West" situation. The lack of criteria (or a default, or both) is the proximal cause of the round-and-round-and-round fighting over the matter. Maybe we need no default, and just criteria, I don't know.  But we need something other than the unqualified, vague "maybe" of "is neither required nor prohibited".  — SMcCandlish ☏ ¢ 😼  05:07, 9 July 2018 (UTC)
 * No harm in a civil discussion and analysis. There is no proposal here yet, nothing to support or oppose, and you can't stop us from having a civil discussion and floating ideas. If you don't want to participate in the discussion, feel free to edit a different page. —  Insertcleverphrasehere (or here)  05:48, 9 July 2018 (UTC)
 * Regardless, I integrated and 's "just do nothing"/"ArbCom is wrong" idea into the "The central question before us ..." line up top.  — SMcCandlish ☏ ¢ 😼  07:28, 9 July 2018 (UTC)
 * Support. We don't need more rules. Let it be decided by article. If the infobox is considered to add value to the article, let it stand. Natureium (talk) 14:31, 9 July 2018 (UTC)
 * Strongest possible support The status quo is fine. Headbomb {t · c · p · b} 00:31, 10 July 2018 (UTC)
 * Strongest possible support case-by-case is how this needs to be decided. This is not something that needs global decisions.  —Dirk Beetstra T  C 06:20, 10 July 2018 (UTC)
 * Support – User:RexxS made a very convincing case below that a proscriptive change to the current situation will only end in tears. It's only Realpolitik to concede that there are different positions. Further, as others here have mentioned, I too noticed that over the last 18 months or so tempers have mellowed on both sides, so I really can't see why this needs discussing now. -- Michael Bednarek (talk) 06:49, 10 July 2018 (UTC)
 * Support. Nothing is deficient in the current policy, as far as I can tell. ~ Rob 13 Talk 17:31, 10 July 2018 (UTC)
 * Support while this exercise may be useful in documenting current practice - which I think is valuable in and of itself as a point of reference - it has no more chance than any of the other many attempts to codify infobox use across the project. Infoboxes are inherently a matter of editorial judgement. Any attempt to force a one-size-fits-all solution, even by category, will accomplish preceicely nothing. Why is this? Because the most that will result is a guideline - which, while establishing a default position, is still subject to editorial discretion on a case by case basis. The same arguements will arise; the only difference will be the constant beat of the IAR drum in the background. The solution, just like any other DS area where individual editors are continuously problematic, is the liberal application of increasing term topic bans. Either problematic editors will modify their behavior re infoboxes or, if they can or will not, they simply loose their ability to have any say on the use of infoboxes.  Jbh  Talk  21:37, 11 July 2018 (UTC)
 * Strong Support. L293D (☎ • ✎) 00:29, 12 July 2018 (UTC)
 * Support: the easiest and most straightforward approach. --K.e.coffman (talk) 05:14, 12 July 2018 (UTC)
 * Support: I don't see what we'd have to gain out of this. Jbh summarizes what I'd be saying quite nicely. --AntiCompositeNumber (talk) 12:45, 13 July 2018 (UTC)
 * "Voting" here serves no purpose, since there is no opposite count of people in favor of doing "something"; no specific somethings have been proposed yet. WP has on average 30,000 active editors per month, so a few voting to avoid all proposals before any proposals have been offered or examined, is meaningless obstructionism.  — SMcCandlish ☏ ¢ 😼  01:03, 14 July 2018 (UTC)
 * Actually, one specific suggestion HAS been suggested: to intentionally “do nothing”. Blueboar (talk) 02:22, 14 July 2018 (UTC)
 * Obviously. Repeat: voting to "do nothing" is meaningless in the absence of any other alternatives being laid out yet.  — SMcCandlish ☏ ¢ 😼  02:29, 14 July 2018 (UTC)
 * Ok, then let me turn this into a proposal for positive action, rather than a call for negative non-action: Go back to arbcom and tell them that the decision as to whether an article should have an infobox (and if so, what should be in it) is a CONTENT issue, and NOT a style issue.  Disputes are intentionally devolved to the ARTICLE level, as that is where content disputes are best settled. While we agree that we don’t want editors “fighting” about the infoboxes, we actually ENCOURAGE healthy and polite discussion of them... and feel that such discussions need to be held on an article by article basis. Blueboar (talk) 03:21, 14 July 2018 (UTC)
 * Would also entail re-doing WP:INFOBOX as mostly a content guideline with an MOS section (which should happen anyway). Sounds like a reasonable proposal, but it's not what people are !voting on here. Some seem to agree with part of what you said, others are just declaring futility, others just hate "rules", etc.  The rationales aren't particularly related.  — SMcCandlish ☏ ¢ 😼  05:04, 14 July 2018 (UTC)
 * Making it a content guideline? That's twisting what he said and the exact opposite of what people opposed to action are saying. There is no particular problem with WP:INFOBOX as a technical/style guide. If an infobox is appropriate content for an article, then we can agree on some general look-and-feel items. But the choice to include one is a content issue which does not need any additional guidelines - the same rules about verifiability, NPOV, etc. always extend to infoboxes just as they do to lead paragraphs, to body text, and to categories. We simply don't need central planning as to when to include a infobox or not. Just like we don't have a central plan about which categories must be used in particular types of articles, what specific section headings must be present, and so on. This is content discussion which belongs on article talk pages or perhaps WikiProjects, nowhere else.  -- Netoholic @  06:28, 14 July 2018 (UTC)
 * But "people opposed to action" aren't actually saying anything consistent. Substantively: "We simply don't need central planning as to when to include a infobox or not" might be the core point of a WP:INFOBOX then. Lots of things in the current guideline are not style matters but content ones, and a key factor in i-box disputes has been not just that their inclusion/omission is a content matter but that they contain is, too – not a style matter. It's been a problem for a long time that everything i-boxy has been crammed into a style guideline page and interpreted by many as style and by others as content.  It's also the source of damned near half of the total "anti-MoS" mindset.  No page with an MoS banner on it has led to more unresolved disputation and harder feelings than this one, not even MOS:CAPS. Anyway, maybe I am trying to fry too many eggs at once here.  My main point in replying above was "this is an interesting proposal, so maybe make it a proposal, since it's not really what the people above have actually been talking about."  I didn't come here to impose an end result.  I opened the meta-thread on the premise and promise of an open WP dialogue, to satisfy ArbCom's repeated demands that there be one (and perhaps more importantly their refusal to do much about i-box related disruption in the absence of one). If the end result of that ends up being a) a list of some topics where i-boxes are pretty much "standard" and some where they're usually controversial (valuable in and of itself) and b) an RfC that concludes firmly that i-boxes really must be decided page-by-page, then ArbCom have a "corrective" answer from the community.  I'm not certain that's the only outcome we could come up with (I think we could probably come up with some general criteria; people have suggested some, like not having one just to have one even when there's too little content to provide any real infobox substance), but it would be an outcome.
 * Isn't "b)" where we are now, and where the supporters in this section are content to leave it? Voting to to do nothing is not meaningless in the presence of the alternatives laid out here. -- Michael Bednarek (talk) 12:05, 14 July 2018 (UTC)
 * Support and change the guideline to clarify that this is a content issue which is decided at the article level. –dlthewave ☎ 12:39, 14 July 2018 (UTC)
 * (Expanding comment) We currently have strong support for "the current status quo of deciding by article," however this is not actually the status quo in all cases. There have been attempts to impose rigid requirements across wide swaths of articles (without community consensus) and it seems that ArbCom has difficulty understanding whether this practice goes against the current guideline. Instead of continuing on a No Action path, the solution would be to document our preference by adding "inclusion is a content decision that is decided at the article level" to the guideline. –dlthewave ☎ 16:59, 14 July 2018 (UTC)
 * This is already part of the guideline. –dlthewave ☎ 00:34, 15 July 2018 (UTC)
 * Can you flesh out which "attempts to impose rigid requirements across wide swaths of articles" you mean? Johnbod (talk) 23:14, 14 July 2018 (UTC)
 * I would exercise extreme caution, per WP:ASPERSIONS. Any specific finger-pointing will require diffs, and this is not a drama board.  — SMcCandlish ☏ ¢ 😼  01:56, 15 July 2018 (UTC)
 * WikiProject Composers would be a fairly watered-down example: (most members of this project) think it is normally best, therefore, to avoid infoboxes altogether for classical musicians, and prefer to add an infobox to an article only following consensus for that inclusion on the article's talk page. Editors are not, in fact, required to obtain consensus prior to adding content. The project has also added hidden text to articles: –dlthewave ☎ 18:18, 15 July 2018 (UTC)
 * That is actually the most often-cited case - are there any less "watered-down"? It can be interpreted as sensible advice to reduce the chance of the editor's time being wasted on a box that gets removed.  On the other side RexxxS points out there is WikiProject_Bridges_and_Tunnels, point 4 - a flat instruction to add a box. Johnbod (talk) 18:26, 15 July 2018 (UTC)


 * Support, see other comments in the thread. --Gerda Arendt (talk) 12:54, 14 July 2018 (UTC)
 * oppose this conversation needs to happen. — BillHPike (talk, contribs) 22:41, 14 July 2018 (UTC)
 * Can you explain WHY “the conversation needs to happen”? Blueboar (talk) 23:31, 14 July 2018 (UTC)
 * I feel that a conversation about general guidelines would help avoid rehashing the same arguments on infobox discussions on individual articles. As I noted elsewhere on this page, I would oppose hard criteria on infobox inclusion/exclusion, but I support establishing a consensus on what factors should be accorded what weight in infobox discussions. — BillHPike (talk, contribs) 01:39, 15 July 2018 (UTC)
 * Fair enough... my counter to that would be this: having to "rehash" the arguments for and against having an infobox at individual articles is actually a good thing... even a necessary thing. I say this because we always need to apply those arguments to the specific situation, the specific article.  The factors that influence the decision as to whether to include an infobox or not (and, if so, what fields to include) are article specific and can be very nuanced. The weight we should give to these factors will not be the same from article to article... indeed the factors themselves are not always the same from article to article.  Blueboar (talk) 13:03, 15 July 2018 (UTC)
 * That's the theory, and it is possible to have that sort of discussion. But in the past they tended not to be like that at all. And they came in runs, so the same people on either side just applied the same arguments several times over. Johnbod (talk) 13:38, 15 July 2018 (UTC)
 * While I appreciate the desire to revisit the specific tradeoffs for each specific article, the problem is that English Wikipedia really makes decisions by straw poll, forcing adherents of different viewpoints to continually monitor and participate in discussions across a huge number of articles. This chews up an enormous amount of time and energy, which is a sorely lacking resource with a volunteer community. What's needed is a decision-making process that actually tries to find a real consensus view, weighing benefits against problems, that will satisfy the most people (or dissatisfy the fewest), including the silent reader base who isn't involved in the discussion. Unfortunately, there are no signs of this happening (in any type of discussion on English Wikipedia). isaacl (talk) 20:02, 15 July 2018 (UTC)
 * Support. Most pages should have infoboxes, since most have definable metadata that need to be presented in a machine-readable format.  However, some pages simply don't fit; what kind of metadata would exist in Screened porch, for example?  And tons of really broad topics wouldn't work, e.g. History and Existence.  Any firm rule would either lead to bizarre and unhelpful situations like putting infoboxes on these three articles, or it would need to have lots of exceptions, and we'd probably have to end up with page-by-page discussions to decide whether a specific page warranted an exception.  A broad rule can be helpful at preventing lots of unneeded discussions, but it risks rule creep, and when it doesn't prevent those discussions, the result is worse than not having the rule in the first place.  Nyttend (talk) 23:11, 15 July 2018 (UTC)
 * I don't see anyone in this discussion suggesting that articles like Screened porch, History, or Existence should have infoboxes, and the main "Toward drafting criteria" subtopic already has this covered.  — SMcCandlish ☏ ¢ 😼  02:28, 16 July 2018 (UTC)
 * Support I would've thought that the standard for when to use an infobox were whether any of the parameters beyond the title were fillable or not. If none of the infobox parameters could be filled out, then no need for an infobox. It really is that simple.  spintendo   01:42, 16 July 2018 (UTC)
 * Where has anyone suggested inserting empty infoboxes? More and more I get the sense that many respondents here are not actually reading any of this discussion, just inserting a reflexive reaction to a vague idea without following what we've actually been talking about. That's very discouraging.  — SMcCandlish ☏ ¢ 😼  02:28, 16 July 2018 (UTC)
 * "We've been directed to try to draft some kind of 'when an infobox should/shouldn't be included' guideline." You yourself spent 10 years on the fence regarding the topic, so it's apparent that the issue is less "reflexive" than either of us thought. I look forward to following along and learning more about it.  spintendo   05:48, 19 July 2018 (UTC)
 * Which relates in no way to whether people are actually looking at what's proposed or just !voting in terror about what they imagine in might have proposed.  — SMcCandlish ☏ ¢ 😼  09:55, 20 July 2018 (UTC)
 * Strong possible support - Case-by-case works fine, If one wants an infobox or wants one removed they can and should go to the talkpage, No need for more bureaucratic nonsense. – Davey 2010 Talk 18:39, 18 July 2018 (UTC)
 * Support. The infobox wars are due to lack of objectivity, civility, and WP:DR, and due to blatant and continued POV-pushing and partisanship rather than civil WP:DR. All of those are personal behavioral issues, not side-wide PAG issues. As with any contentious area (such as GMO editing), when we get rid of the bad actors or bad behavior (on both sides of the issue), and enforce proper WP:DR and civility, the problem calms down considerably or disappears. Softlavender (talk) 06:12, 23 July 2018 (UTC)
 * Well, at least it is impossible to tell from this which side are the mad dogs who ought to be shot - or is it both of them? I don't quite see how strong views for or against boxes equates to "POV-pushing and partisanship" in the normal WP sense - it's all too in-universe, isn't it?  A massive failure of WP:AGF lurking here. Johnbod (talk) 14:39, 23 July 2018 (UTC)

Incomplete list of topics by controversy level
Below is start on a list of topic areas listed by category as 'uncontroversial', 'possibly controversial', and 'controversial'. Feel free to add more topics and examples. If you want to move a topic down to a more controversial category, please add links to articles where there have been disputes. Please help by filling in the list with more topics and examples. —  Insertcleverphrasehere (or here)  06:13, 9 July 2018 (UTC)

Uncontroversial topics that primarily use infoboxes

 * Academic journals, Magazines, Newspapers, Websites, Publishers
 * Albums, singles, and bands: Albums, singles, and bands border on being navigation tools to help readers go from album to album, or song to singer, and might be considered generally essential.


 * Buildings including bridges - boy, do bridges have infoxes. Occasional disputes, as at Buckingham Palace.
 * Chemicals: Generally essential for high profile chemicals, and the chembox is generally used as a table of relevant attributes for the chemical in question.
 * Films, TV shows: Films and TV shows have nearly the same utility and needful purpose as the albums, singles and bands
 * Human anatomical terms short boxes with standard codes and a picture: Interventricular septum
 * Taxonomy: Used for more than just info, could almost be considered "essential" as some of the information in Taxoboxes is generally not contained elsewhere in the article.
 * Countries, cities, provinces, et al.: generally full of stats.
 * Olympians and professional athletes:
 * Legislation, legislatures, and office holders (for all, individual examples; general articles have no box, eg Upper house, Statute of limitation)


 * Medical conditions and pharmaceutical drugs: Considerable discussion as to what should be included, beyond the standard medical codes
 * Politicians, some rows about including full details of offices held etc
 * Schools and colleges
 * Ships, planes, cars, motorbikes - anything manufactured multiply as a "model"
 * Software and video games
 * Sports teams
 * Musical compositions, especially Opera with the few exceptions where an article author is not in favour (French opera, operas by Handel), Choirs, Orchestras, individual performers in classical music (singers, players, conductors). Musical intruments.
 * Military battles use of infobox is generally uncontroversial. Sometimes intense discussion about how results of battle should be described.

Uncontroversial topics that primarily omit infoboxes

 * Abstract concepts for example Thought, art, Epistemology, Tort
 * Artistic forms (or as Wikipedians insist on calling them, "genres"): for example Sonata, Symphony, Blues, Diptych, Epic poetry, Epic film
 * Animal anatomical terms and parts of plants: for example Cloaca, Gynoecium
 * Clothing for example Cowboy hat, Tuxedo, and Coat
 * Everyday objects for example cooker, Car, Traffic light, Teacup
 * Basic foods for example Steak, Cheese, and Bread (but individual types of bread and cheese, and "dishes" with recipes generally do: Irish stew, Stilton cheese, Soda bread)
 * List articles irrespective of topic, predominately omit infoboxes, but some lists of compositions have one, see Max Reger works and List of compositions by Jean Sibelius
 * Scientific and medical concepts, techniques, and fields of study for example Measurement in quantum mechanics, Radiocarbon dating, Medical diagnosis and Biology
 * Small rivers for example Bee Run (Missouri), Norbury Brook
 * Topics of all sorts for example Economic history of the United States, Sexism in the technology industry, Religion in ancient Rome

Possibly controversial

 * Organizations: Infoboxes for companies, nonprofits, governments, and other organizations can generally be a convenient location for information that generally would not be naturally included in the prose, or might be awkward in the prose (i.e. parent company, website, logo, value, # of employees, etc), Example Apple Inc.. Some infoboxes that are nearly blank might be considered superfluous, and editors may disagree on whether the correct action in this case is filling in more information or removing the infobox.
 * Books: Some books have been controversial (examples?: ____, ____); historical works like On Virtue usually don't have infoboxes
 * Churches: is it a building or a parish? Many do, many don't. The larger Hindu temples have remarkably uninformative boxes, mostly taken up with the address over several lines.
 * Occupations some have boxes, like electrician, but these say nothing useful, and most don't (barber surgeon, groundworker). An example of infobox over-reach? Not aware of any actual rows, but this is a quiet area.
 * Scientists - the difficulty is what to usefully say, and whether some fields often used are accurate or sufficiently important
 * Authors
 * Philosophers - Philosophers often work in multiple disciplines and traditions and are sometimes also known as authors, theologians, etc. It is difficult to create summaries of this without over-simplifying.

Controversial

 * Composers: Highly controversial whether composers should have infoboxes, the source of many spirited debates. (add examples here: ____, ____)
 * Film directors: Bios for some directors have become quite heated as well (i.e. Stanley Kubrick, ____, ____)
 * Works of visual art
 * Visual artists
 * Artistic movements
 * People whose careers do not follow a single and regular path: It is often difficult to distill the complexities of a human life into a short list of standardized facts and statistics. (examples: Mary Wollstonecraft, ____)
 * Non-military historic events: Events rarely fit cleanly into our cookie-cutter templates (like Infobox event, Infobox civil conflict, etc.) and they often have important implications and aspects that are lost in our attempts to summarize them. (examples: Nashville sit-ins, ____)

Allegedly controversial: composers
Perhaps let's have a look at examples:
 * Alma Mahler, pictured on the Main page today, infobox, same for husbands Walter Gropius and Franz Werfel
 * Gustav Mahler, no infobox
 * Ludwig van Beethoven, short infobox, suggested in 2013 and implemeted by community consensus
 * Percy Grainger, "identibox" (short infobox) by Brianboulton from 2013, stable until yesterday when it was TFA
 * Alexander Zemlinsky, infobox which I just gave him to be discussed

All examples have in common that there are no traces of war ;) - The last controversity I was in was Pierre Boulez where I added a short infobox in 2016. Long discussion on the article talk and project composers. Why, I will never understand. Just to prevent people seeing basic facts at a glance that a good printed encyclopedia also provides at the beginning? --Gerda Arendt (talk) 07:18, 9 July 2018 (UTC)
 * Alma Mahler - none of these are mainly notable as composers - poor example. Mahler himself of course has no box. Johnbod (talk) 14:12, 9 July 2018 (UTC)
 * The lead describes Alma Mahler as a composer. All composers are also persons, most also musicians of some sort. What I want to illustrate is that it's a myth to think that there's a lot of controversy for classical composers, and all the people mentioned are good examples for that. Better no infobox and peace among editors, than the waste of time we sometimes had. I remember Bach (ibox) and Wagner (no ibox), but most composers peacefully have one, or not. There's even infobox classical composer, with 181 transclusions today, not counting those who come as infobox person or infobox musical artist. The 2010 suggestion of project composers to better not have an infobox for composers of classical music, mentioned in some hidden notices where someone would add an ibox, is not binding (which these hidden messages of course don't mention). --Gerda Arendt (talk) 14:42, 9 July 2018 (UTC)
 * "composer, author, editor and socialite", discreetly omitting "femme fatale" and given in reverse order of importance. It's still not a good example of anything. Johnbod (talk) 15:01, 9 July 2018 (UTC)
 * Andrew Lloyd Webber, John Williams and Elton John, some of the most successful composers of the last century all have infoboxes (as do most of contemporary composers). What is it about the work that John Williams did that is so fundamentally different from what Benjamin Britten did that explains why most contemporary composers have infoboxes and classical composers do not? Answer: nothing; it's all a matter of who wrote the articles, and it's about time you acknowledged that. --RexxS (talk) 17:41, 11 July 2018 (UTC)
 * But how accurate, useful, or for that matter similar, are those boxes? Not very. Lord Lloyd Webber's treats him, rather comically, as a politician (and millionaire). The Williams one is a classic piece of infobox misinformation, encapsulating his musical career with: "Genres: Film score, contemporary classical music, post-romanticism, jazz [and]] Instruments: Piano, harpsichord" and not even making it clear that he is a composer, not a performer. Hopeless, and if you care at all about Williams, highly objectionable. And these are the best examples you and Gerda can find.  It's all a matter of who wrote the infoboxes, I suppose. Where infoboxes are useful they contain roughly similar information for similar types of people, not some personal OR summary. One of the problems with this issue is that infobox fans  get very worked up about there being an infobox, but rarely care much about the quality or cogency of the contents. Johnbod (talk) 20:03, 11 July 2018 (UTC)
 * WP:Arguments to avoid on discussion pages and WP:RUBBISH. If the infobox is inadequate, the solution is to make it adequate; it's not a valid "no infoboxes" rationale.  — SMcCandlish ☏ ¢ 😼  00:05, 12 July 2018 (UTC)
 * I take it you mean this bit "With that said, if content is so bad that it is harmful in its current state, then removing it now, and possibly adding it back later, is often a better option." Johnbod (talk) 00:09, 12 July 2018 (UTC)
 * Not really. If one is not in a position to repair it – to make an infobox with the more correct or more pertinent information – then one likely isn't in a position to be certain that the current i-box is wrong/inadequate. Judging from the Webber example, I think this comes up most often when someone has applied a specific occupational i-box to someone with more than one notable occupation. The solution is probably to replace it with  and provide more generic but broad information. Others might prefer to include multiple occupational i-boxes with occupationally specific drill-down details. The latter approach appears to be more controversial.  — SMcCandlish ☏ ¢ 😼  00:52, 12 July 2018 (UTC)
 * This one uses ! The best solution is to remove it, and let the well-written first para convey the key information properly. The last thing it needs is "more generic but broad information"! Johnbod (talk) 04:26, 12 July 2018 (UTC)
 * That doesn't follow. Such information is exactly what a bio infobox is for: routine vital stats and some deets on why the person is notable. If one over-dwells on some political particulars, for example, that's a problem of undue attention to that aspect of the subject instead of a broader view.  Looking at Andrew Lloyd Webber, which I think is the "Lord Lloyd Webber" you refer to, what I see is an infobox that doesn't label him "politician" at all, but a "composer, panellist, television personality, songwriter, theatre director, businessman"; the only hint of any involvement in politics is his having been an Conservative MP (which for most MPs isn't a profession but a digression, from what I gather).  He was in the HoL for over a decade, so this isn't trivia, but a major part of his life, even if not the central source notability. It's appropriately excluded, perhaps, from the list of occupations.  ("Panellist" should be removed, since it's redundant with "television personality").  The problems I do see: No indication of what he's really known for in any detail; "See discography" doesn't really cut it.  Some of his best work is mention in the lead and should be in the i-box.  Second, the "Awards" list should not be auto-collapsed.  That  central to his real notability, and forced collapse is both an accessibility and usability problem. Needs cleanup, though (two entries look identical until you see where they link, and the arrangement is redundant and confusing, e.g. Evita-related stuff in four places).  Next, the MP stuff actually appears twice; it s hould eaither use "Office:" line or the "Member of the [body]" mini-box at the bottom of the i-box, not both.  The rest seems normal, aside from the fact that "alma mater" is an Americanism (there's a discussion ongoing about removing this parameter completely in favor of just using education.  I don't see "Net worth:" as a problem; the fact that he's 3/4 of the way to billionaire}} is significant, and it's normal to include this information when we have it, especially for businessmen (even if they are also composers or whatever).  I'm not sure this article needs an infobox, but I find I'm hard pressed to object to this one when the issues with it are fixable.  PS: Would prefer a color photo; use B&W implies he's some dead-guy from our grandparents' era.  — SMcCandlish ☏ ¢ 😼  08:17, 12 July 2018 (UTC)

Just for you:. I overhauled all the above issues, except the photo. The others are rather poor, and a wide one is preferable here (I slightly widened the infobox to prevent line-wrapping of some awards). I went further, and got all the personal-life stuff that isn't of direct relevance to his theatro-musical career (family, net worth, politics) into a "Personal details" section of the bottom, thanks to the officeholder sub-box grouping them this way. The i-box could actually be squeezed to about the same height as the ToC, by removing School of Rock, three lines of awards notes, and some of the less important awards. I think this is pretty close to what an infobox should be doing at an article like this. Some might demand to add "parliamentarian" to "Occupation:"; I thought about it, but it would add a line, unless "television personality" were removed (which is not necessarily a bad idea; that's a side-effect of fame, not an occupation – except for someone like Zsa Zsa Gabor, "famous for being famous"). — SMcCandlish ☏ ¢ 😼  09:43, 12 July 2018 (UTC)
 * (as I was mentioned by name:) I never claimed I picked examples of the best infoboxes. I picked examples of accepted infoboxes for people who are (also) composers. Alma Mahler was seen by 9k+ viewers that day, Percy Grainger by 45k+ viewers this month, and there was no conflict. Can we use them, and the ever-popular Beethoven, as models? That is my question. - My example for a good composer's infobox (arrived at after a peculiar discussion) is Max Reger. Suggestions to make it better are always welcome. (Would love to see "Spouse", not "Spouse(s)", for example.) --Gerda Arendt (talk) 10:02, 12 July 2018 (UTC)
 * If you are going to use examples, Gerda (and RexxxS), it's always wise to pick good ones! Thanks and kudos, SMcCandlish. Generally, supporters of infoboxes would do their cause more good if they spent time actually improving the many appalling and net-negative infoboxes we have, rather than the usual response to complaints of "well, you fix it then". I might institute a barnstar when I have the time - it would be a small and select group of recipients, I fear.  Does anyone want to take on Electrician?  Gerda, we all know that "views without complaints" figures on WP are virtually meaningless. Johnbod (talk) 13:38, 12 July 2018 (UTC)
 * When I see an infobox with problems I fix it, without expecting a reward. When I write an article, I make one, thinking that telling a reader at a glance where and when this person lived and died is a minimum courtsy. I save time by usually not adding one to articles of others (unless I substantially worked on it, or looked up that no author was involved who would normally object). I think I have listed several good examples which could be used as models: Alma Mahler, Percy Grainger, Ludwig van Beethoven, Alexander Zemlinsky, Max Reger. - (I picked the examples for another reason, though. Repeating: I believe the alleged bitter disputes about composer articles date back to 2016 and before. Nothing recent I'd know of.) --Gerda Arendt (talk) 14:14, 12 July 2018 (UTC)

Alternative view: criteria are not practical
I've been a strong believer that adding an infobox to an article generally improves the article for multiple reasons. However, I have come to believe over many years of debate that numerous editors, whom I value, disagree with my view. They give less weight to certain advantages that infoboxes provide than I do, and more weight to other considerations. Consequently, I find there are are some realities that we must accept: I have come to the view that the factors which need to be considered when deciding to have an infobox or not are: (1) numerous; (2) nuanced; and (3) often incapable of objective realisation. The human factor just has too great an effect. I started an essay some time ago at User:RexxS/Infobox factors which gives some further background, but is still incomplete, and may actually be incompletable.
 * 1) The majority of articles on Wikipedia have infoboxes and there is a certain expectation on the part of readers and editors that an article should have one;
 * 2) It is possible for editors to disagree on the net value of an infobox without either side being objectively right or wrong;
 * 3) The disputes that have arisen, for example, in classical music composers or theatrical biographies are not because those topics are inherently less suitable to having an infobox, but because the editors most interested and hardest-working in those topics generally set a lower value on infoboxes;
 * 4) Many articles have editors who have invested a lot of time and care into them, and those editors attempt to steward those articles;
 * 5) Where those editors have chosen not to have an infobox, they consequently end up having to repeatedly justify that decision;

I propose that we recognise that because of the complexity of the decision, it is not possible to produce a formula or algorithm to decide on whether an article, or group of articles should or shouldn't have an infobox. Instead we should promote goodwill and mutual understanding of each others' positions. We have a chance to make a paradigm shift in the way we reach decisions on this thorny topic. In the grand scheme of things, the presence or absence of an infobox ought not to be a big deal. --RexxS (talk) 18:48, 9 July 2018 (UTC) — SMcCandlish ☏ ¢ 😼  00:18, 10 July 2018 (UTC)
 * I think this is wrong for various reasons - point 3 perhaps being the key. As the expanding section above demonstrates, there are types of articles where we normally have infoboxes, and types where we don't. There is absolutely no evidence that "there is a certain expectation on the part of readers" that all articles should have one, nor do I believe this is the case. The great majority of article types fall fairly neatly into one group or the other, but some types, for various reasons, get caught in the middle, and it is here that disputes are concentrated. The articles suited to infoboxes are about discrete things, whether people, places, taxa, events etc, where the important things to know about the subject are a) the same for other members of that class of thing, b) objective facts that are straightforward to verify, and c) clear and easy to state.  The types of articles not suited to infoboxes are those where any of these three factors is not the case, which includes most articles on broader topics and concepts, but also some on things (like people of certain types).  It is a particular feature of WP, considered as an encyclopaedia, that we are very strong on the former type, "thing" articles, of which we have vast numbers, but often very weak on articles on topics (many very obvious ones are completely missing) and concepts. Therefore most articles do indeed have infoboxes, but to conclude from this that all articles usefully can do so is an optical illusion.  Mind you, busy editors who don't like researching and writing actual content (who increasingly seem to be the majority here) have typically filled up many sorts of non-infobox articles with other types of templates of the navbox or timeline sort. There are many good points made in your essay though.  Johnbod (talk) 20:28, 9 July 2018 (UTC)
 * I agree with Johnbod that this alternative isn't workable, but for different reasons. It amounts to "Can't we all just get along?" with no substantive change to our approach. We already know for a fact that we can't just get along (or, rather, that certain otherwise productive editors can't).  The usual response of "just topic-ban them from infoboxes" won't work, because there will always be more editors insistent that infoboxes should be on every article and others that infoboxes are trash, these extreme views are the source of most of the conflict, and they do not represent the views of the average editor (or reader).  — SMcCandlish ☏ ¢ 😼  20:54, 9 July 2018 (UTC)
 * I think the general view that all "infoboxes are trash" is vanishingly rare, and most supposedly "anti-infobox" editors have explicitly said in the past that they don't hold that at all - taxon boxes for example are surely entirely uncontroversial. I'm not even sure there are many editors (who have given the matter any thought) who really believe that all articles should have boxes. Disputes do in fact centre on a narrow range of types of article and if you want to actually achieve anything with this, it is best to concentrate on those and see if anything can be done bearing this in mind. Johnbod (talk) 23:47, 9 July 2018 (UTC)
 * In areas where there are typically no infoboxes, there are also typically no disputes—nobody has ever tried to add one to Comics or Ukiyo-e, for instance. And then we have film directors—the infobox-less Stanley Kubrick is the subject of the most fearsome and endless disputes, while there is no mention of the very word "infobox" at the infoboxed Steven Spielberg.  We have to recognize that the most acrimonious debates centre on personalities to a far greater degree than "categories". Curly "JFC" Turkey 🍁 ¡gobble! 00:53, 10 July 2018 (UTC)
 * "As the expanding section above demonstrates, there are types of articles where we normally have infoboxes, and types where we don't." indeed - and that's not because the topics are somehow more or less suited to an infobox, but because the regular editors in those fields either like or dislike infoboxes, to put it bluntly.
 * Of course most bridges have infoboxes. One look at WikiProject Bridges and Tunnels, bullet point 4 ("Add Infobox bridge or Infobox tunnel to articles") will show you why.
 * Of course most classical composers don't have infoboxes. One look at WikiProject Classical music/Guidelines ("current consensus among project participants holds that biographical infoboxes are often counterproductive on biographies of classical musicians ... and that they should not be used without first obtaining consensus on the article's talk page.") will show you why.
 * Can't you see what is obvious? It's the editors, not the topic that determines whether there is an infobox or not.
 * There is loads of evidence that casual editors (and by implication readers) expect an infobox; it's just that you don't want to admit it. Many's the time that I've looked at the latest outbreak of edit-warring on a composer's biography or that of an actor only to find that it was ignited by a new editor or a passing IP who expressed astonishment that the article had no infobox. If you tell me you haven't seen that, I just won't believe you.
 * Please understand that I'm not arguing here for an infobox where the regular editors don't want one. I certainly could produce the arguments, but I'm trying here to convince folks that they will never solve the problem by producing an ever-increasing list of instruction-creepy areas where we will have infoboxes and where we won't. You fundamentally misunderstand the nature of the problem and hence its solution.
 * YES, I am simply recommending "why can't we all get along", if you insist on putting it that way. I've seen good and productive editors like Andy, Gerda, and Cassianto sanctioned needlessly, and many other top-notch editors effectively retiring because of infobox disputes. Yet all it needs is some give-and-take on both sides to stop that from ever happening again.
 * Give up on trying to make categories of discrete things vs "most articles on broader topics and concepts". You've been banging that drum for years without being able to offer any help to those editing in the problematic areas. It's time to try something else, and you need to be looking at editor behaviour, not subject content. --RexxS (talk) 22:26, 9 July 2018 (UTC)
 * And why do these groups of editors have such different views? Can it possibly be because they know from experience that articles of a certain type do or do not benefit from boxes? What strange perversity in WikiProject Classical music leads to articles on works and instruments almost always having boxes, but those by the same group of editors on composers and musical forms almost never having them (without any "guidelines" on either group). Most of the "usually without" set of types have no project instructions, and in fact rarely cause trouble.  As an experiment take your favourite infobox "infobox:Foo" then see if the actual article "foo" has a box - typically it won't. Why on earth is that?  Look at what's right in front of you!  Johnbod (talk) 23:40, 9 July 2018 (UTC)
 * I agree with your general theme, but in fact quite a bit of special pleading does actually come out of WP:WPCLASSICAL, including strange, niggling insertions into style, naming, and other guidelines, and attempts to insert it into WP:AT policy itself. The general veracity of your observations doesn't preclude the possibility of unconstructive things coming from particular wikiprojects (more accurately: clusters of particular, like-minded editors at some wikiprojects – projects are not hive minds and sometimes have 100+ active participants). The centrality of classical composers and works in the worst of our "infobox wars" strongly suggests there is (or at least historically has been) such a problem. It's very similar to other issues that have arisen with wikiprojects that date back to the early days of Wikipedia and the wikiproject concept.  Several of them have gotten locked into a kind of "we are a unique fiefdom, we own our articles, and we make up our own rules" mindset, which needs to be swept away like cobwebs. Your "experiment" isn't valid. "Why on earth is that?" has an obvious answer: Infoboxes are for presentation of details about a particular notable instance, details not possessed by the general class. I.e., it would not be rational for  and  to be at Person and Cat breed, respectively, since neither page is about a particular person or cat breed.  A more interesting and illuminating experience is to see what percentage of non-stub articles qualify for a particular topical infobox yet do not have one. It's small and shrinking.  When you find a case that does't have one, you'll generally find the same usual suspects fighting against inclusion at that article or at the category/wikiproject level (despite ArbCom invalidating the latter approach). It's pretty rare to see an infobox discussion actually focus on whether the template adds sufficient value to that particular article, rather than how bad/great infoboxes are and related "we don't want them on  articles" stuff.  I have a strong suspicion that lack of infoboxes on well-developed articles is a lost cause in the long run, unless we do something here. More editors support their inclusion, as a general matter, than oppose them. One of the reasons I opened this big meta-thread is that there can be legit arguments against infoboxes at particular articles and types of articles (defined multiple ways), but they generally get drowned out by "all i-boxes are great/terrible" battelgrounding. If some kind of criteria aren't reached, the likely result is the battlegrounding continuing until we can't take it any more, then a simplistic vote-type RfC on whether to make infoboxes a default feature, and the outcome would be "yes" without much room for nuanced arguments. At some point the disruption will force the community's hand, unless the disruption is short-circuited by something like some inclusion criteria (whether detailed and topical, or just general-principles stuff).
 * My experiment was perfectly valid; the point was not that Cat breed doesn't have, but that doesn't have any infobox at all - in theory (and probably in RexxS's mind) it could have or something (although in fact it's just a list), but it doesn't, because it is unlikely the box would say anything useful (Breed doesn't have one either). In the same way School might have a  infobox, but it doesn't, nor do either infoboxes seem to exist.  As you leave the level of discrete things, and ascend to a more conceptual level, the utility of infoboxes falls away. But I am glad you recognise that the type of article is a key factor. As I said above, my clear perception (doing a lot of editing in some of the more contentious areas) is that the general level of rowing is greatly reduced, which is why I am dubious we should respond to Arbcom's call. But if we do, I think recognising that one size won't fit all is the way forward. Johnbod (talk) 00:43, 10 July 2018 (UTC)
 * My point, is that if all of the regular editors of Cat breed want to have  in the article, then let them have it. If they don't want it, then somebody (not me) may ask why not, but in the end it will be best if consensus agrees with the wishes of the regulars. That does the least damage as far as I'm concerned. As a matter of principle, I don't think list articles are well served by infoboxes. But that's because they are a different type of article, not a different class of topic. Cheers --RexxS (talk) 17:19, 10 July 2018 (UTC)
 * Well I certainly believe in giving the views of regular editors considerable weight, though as we know the standard position of the infobox-keen is very much not to do so. But I don't think it helps not to recognise that the position of editors of some groups of articles is unlikely to come from some mysterious and inexplicable aversion. It was SMcCandlish who brought the list into the discussion. Johnbod (talk) 18:57, 10 July 2018 (UTC)
 * Which list? I seem to have lost some of the thread here. The reason people don't accept the "I should have more say because I've edited the article more than you have" arguments is that we have an explicit policy against it, and another one, and another one. WP isn't a place for someone to think of themselves as the author of a work of literature. We're all cogs in a collaborative machine here.  What it will boil down to in most cases is whether more editors who show up to the discussion at a particular article want one or not. This is why I think that without at least baseline criteria, infoboxes will be everywhere in the end, because fans of them outnumber their detractors, and that gap is widening, not shrinking. It would be better to have some defensible, codified reasons why to omit/include an infobox than to continue with boundless, subjective mêlée about it until patience finally wears out.  — SMcCandlish ☏ ¢ 😼  03:40, 11 July 2018 (UTC)
 * Cat breed, actually List of cat breeds. As I and others have said, the level of disputes seems generally down these days, and restricted to a narrow range of articles. But I'd welcome "some defensible, codified reasons" if you think you can get them through - I'm a stronger believer that they exist than you. WP:OWN doesn't at all settle the matter, especially when applied to a whole group of editors, many of whom have never edited the article. WP:CONLEVEL and WP:NOTBLOG (is that really what you meant to link to?) aren't at all relevant. I do think Wikidata has helped reducing tensions, by taking off many of the crowd who would turn up anywhere to clamour for infoboxes. But also people actually realize the inherent limitations of infoboxes, or at least realize they wouldn't know what to put in one for Epistemology, and the great majority of suitable articles now have them, and the great majority of unsuitable articles don't, so the issue has died down naturally except for a few hotspots. I think you and RxxxS are to a large extent "fighting the last war" though I accept some bitter disputes still occur. Johnbod (talk) 16:07, 11 July 2018 (UTC)
 * I don't disagree with you about limitations of infoboxes. The problem here is "have never edited the article". There's a persistent myth that this "is a thing" at all, and it's not, per all those policies. Otherwise a) WP:GNOME work would be forbidden; b) bots would be forbidden; c) article- and category-level RfCs would have to stop, as invalid interference by outsiders in the natural rights of the author(s) of the page or of the wikiproject claiming the "best" scope; and d) site-wide management processes like WP:RM, WP:AFD, etc., would also have to stop for the same reason. Yet the exact opposite is the case.Yes, WP:NOTBLOG (and WP:NOTFORUM) are relevant: WP isn't a publisher of original thought nor is it any anyone's personal writing-on-the-Web platform. This speaks directly to some of the motivation behind "ownish" behavior at articles. None of them are "my" or "your" articles, but the community's, and that includes everything about them, from wording to layout to title to information architecture. This fact makes WP an unsuitable project for certain mindsets; some who have them are very good writers, but they end up conflicting sharply with our collaboration and shared-control model. And this is the core of CONLEVEL policy, it's why we have that policy at all: to restrain individual and factional attempts to exert control against a larger consensus formed from a broader editorial pool.  Various wikiproject- and topically-focused editors hate it, but that's just too bad. They're "at the wrong project" in a sense (more accurately, they've misapprehended the nature of this one, and need to adjust).  — SMcCandlish ☏ ¢ 😼  01:11, 15 July 2018 (UTC)
 * My view: A hard criteria for infobox inclusion is neither practical nor wise. However, I think the community would benefit from a list of what factors should be used in a decision to use (or not use) an infobox and to what degree each factor should be weighted. If we were to make such a list, it could serve as a framework for more thoughtful debate about the utility of infoboxes in particular articles, similar to how legal tests are used to apply jurisprudence to the particular set of facts and circumstances presented by a legal case. Note that, like I propose, many legal tests do not require a particular outcome for a given set of facts, but only provide a method to determine what factors should be weighed. — BillHPike (talk, contribs) 21:05, 11 July 2018 (UTC)
 * I think this is right. Johnbod (talk) 21:14, 11 July 2018 (UTC)
 * Here's a list of factors that should be used in a decision to use (or not use) an infobox:
 * Stewardship
 * Third-party re-use
 * Microformats
 * Structured data
 * Translation
 * Inappropriate fields
 * Alternate values
 * Missing nuances
 * Irrelevance
 * Thin end of wedge
 * Aesthetics
 * Balance of the article
 * Images
 * Lead image
 * Other editors' sensibilities
 * Core editors
 * Effect of GA/FA
 * Effect of Wikiprojects
 * Different audiences
 * The homework assignment
 * Reading impairments
 * Foreign visitors
 * There's further detail at User:RexxS/Infobox factors. Feel free to let me know when you've decided to what degree each factor should be weighted, and I'll explain why my preferred weighting is different on each given article. We can then move on to examine how the community can reach agreement on such an obviously subjective matter. --RexxS (talk) 23:21, 14 July 2018 (UTC)


 * Empty infobox arguments might become a thing if we mandated them anyway. Even if we hard-mandated that, for example, all articles on people should include an infobox (I'm not saying that we should, just a hypothetical), editors could still simply argue to remove all criteria from said infobox for aesthetic reasons, e.g. Stanley Kubrick would simply be a photo with a caption and his name above the photo. The argument would then transfer from infobox v. no-infobox to infobox v. blank-infobox. —  Insertcleverphrasehere (or here)  04:27, 12 July 2018 (UTC)

Styling criteria the MOS could stipulate
Add MOS styling considerations that you want to discuss under its own level 4 header below to see if it's the stuff of good MOS guidance. Add comments from a bullet on the left margin of a new line under any of the stipulations where you wish to comment. Indent any comments you wish to make to any of the points made by another editor.

Unused parameters
Whether unused parameters should remain in an article's infobox or not could be delineated.


 * I believe unused parameters should not be left in an article's infobox. When desired for use, it's easy enough to manually import the parameter from the documentation subpage. The presence of blank parameters lends an impression that the information is needed as soon as possible.--John Cline (talk) 21:28, 9 July 2018 (UTC)


 * That's a practicality matter. Parameters that might be filled in at any time, because they could be applicable, should be left in, probably, while those that are not applicable, will not be applicable for the foreseeable future (e.g. death for a BLP), and any that are contentious (religion in the bio i-boxes that still support it, where it's reserved for religious leaders) should likely be removed. I just reverted someone the other day at a cat breed article removing parameters for links to breed standards at organizations that don't yet recognize the breed, because the recognition is very likely to come in the next few years, and the average editor will not know what parameters for which organizations are available at all if the blank ones are removed; they would have to go look up the codes in the template and are not likely to do so. By contrast, if we know someone doesn't/didn't have children or that their parents are unrecorded by history, no empty parameters should remain in the article for i-box factoids we can't fill in. I guess that could be compressed into a couple of bullet points as advice, but do people squabble about it enough that we should bother?  — SMcCandlish ☏ ¢ 😼  21:45, 9 July 2018 (UTC)
 * I disagree a bit. A living person will die, and to have the coding of death date and age ready (and prepared by the birth date in it) might help at a time of stress. --Gerda Arendt (talk) 21:50, 9 July 2018 (UTC)
 * Anyone so stressed they are not capable of inserting death_date isn't in a competent state to be editing until the state passes.  — SMcCandlish ☏ ¢ 😼  00:57, 15 July 2018 (UTC)
 * <P>I think we could fashion the guideline so as to treat a parameter like:  |death date=   as not being empty by virtue of the HTML comment. This would give enough flexibility to allow an editor to retain certain unused parameters for good cause. And I agree that it should.--John Cline (talk) 22:38, 9 July 2018 (UTC)
 * But it's just unnecessary clutter. We don't need to keep a "dead code" parameter around for 37 years. Or even 1 year for that matter.  — SMcCandlish ☏ ¢ 😼  00:55, 15 July 2018 (UTC)
 * I don't really understand the last point. If someone has a terminal illness and it's said they're likely to die within the year (I'm assuming this is already sourced within the article), why is it so harmful to leave the parameters there whereas you think they should be left if a breed recognition is coming with a few years? The code for death date might be slightly easier to remember but realistically many aren't going to and will have to waste time looking it up. This may be a bit easier than finding the parameters for the other organisations but it's still needless work. I don't see why this "clutter" for 1 year or less is so much worse than the other clutter for even longer which you defend to the extent of reverting. Nil Einne (talk) 16:54, 19 July 2018 (UTC)
 * People pull through all the time. Two members of my own family have, both given approx. 6 months to live. One aggressively went for experimental treatments and make it another 20+ years, the other keeps saying he expects to not make it more than another few months, and that was in 2011. More importantly, we have no need to keep a one-line template string around; it can just be added when it's needed. It's clutter and infoboxes such lines really annoyingly waste vertical space, making editors scroll again and again and again through unnecessary code noise to get to the actual lead.  — SMcCandlish ☏ ¢ 😼  09:58, 20 July 2018 (UTC)
 * I often am very selective about blank parameters, removing the more esoteric ones but leaving in those I think could improve the article and which could reasonably be found and filled out sometime later. There's a balance between confusing new editors vs. convenience for future work, and so I would oppose a blanket statement to remove blank ones. -- Netoholic @ 00:31, 11 July 2018 (UTC)

Proportionality standards
Styling considerations can contain "infobox sprawl" and prevent it from undue domination of the article.


 * In my opinion, the infobox should not fall into the first section. I'd like to see a technical solution that automatically set overflow to vertical scrolling at the bottom of the TOC (if used).--John Cline (talk) 21:28, 9 July 2018 (UTC)


 * Whether it happens depends a lot on a reader's screen. --Gerda Arendt (talk) 21:35, 9 July 2018 (UTC)


 * Sounds like a matter for WP:User CSS, not hard-coding.  — SMcCandlish ☏ ¢ 😼  21:45, 9 July 2018 (UTC)

Singular plural nouns
The MOS is a great place to depreciate the nonsense of rendering a man's wife as his, or his nicknames as his. It's way too easy to code the template so that one wife renders as his while two wives would render as his.


 * If we do nothing more than fix this one bit of malarkey, we will have done quite a bit. Many times over such molested grammar is featured on our pages; even on our featured pages.--John Cline (talk) 21:28, 9 July 2018 (UTC)


 * Support to drop the "(s)", keep simple. When there are two, a reader will understand ;) --Gerda Arendt (talk) 21:35, 9 July 2018 (UTC)


 * That's not an MoS matter, it's a template coding matter, probably only handleable by a conversion to WP:Lua (for ability to analyze the input for whether the data provided is a single value. Even this might not be practical because input may be comma-delimited, or wrapped in a template like unbulleted list. Another approach might be adding singular parameter, e.g. spouse, spouses.  — SMcCandlish ☏ ¢ 😼  21:45, 9 July 2018 (UTC)
 * Actually, even better would be to define spouse=spouse1, spouse2, ..., spouseN and have the template generate the header as Spouse or Spouses, and format the list. I really hate all the use of Plainlist/unbulleted list - such a kludge. -- Netoholic @ 00:37, 11 July 2018 (UTC)
 * Even better, the Lua code should be able to detect whether something's in asterisked-list form and pluralize accordingly for parameters that have a "pluralizable" option enabled, rather than creating lots of |XXX1=, |XXX2= parameters. I've wondered why nobody's bothered to do that years ago. Curly "JFC" Turkey 🍁 ¡gobble! 01:21, 11 July 2018 (UTC)

Over-inclusion of details
a fairly common theme in infobox disputes is alleged triviality of included details, sometimes running to lengthy lists which are sometimes then pre-collapsed, which is an accessibility problem. We should address these matters directly, though in general terms about encyclopedic and contextual relevance – WP:NOT, etc.


 * Dealing with this would go a long way to resolving some (hardly all) of the complaints about infoboxes. A clear example of a problematic one is that at Sony Ten (and similar articles), crammed with local-station trivia, including both collapsed and uncollapsed lists. Collapse lists in particular should basically be banned per MOS:DONTHIDE.  We permit it with navboxes because that feature itself is of low utility to mobile users and to users who need screenreaders or low-mobility pointing devices. That exception doesn't apply to infoboxes, which are heavily used by all categories of readers, right at the top of the page.  — SMcCandlish ☏ ¢ 😼  22:28, 9 July 2018 (UTC)


 * This would constitute a sound guideline in my opinion. Perhaps it could be accomplished by using "notes" in the infobox, where excess would otherwise render, leaving two or three examples inside the infobox and expanding the rest through the note, in a "Footnotes" section.--John Cline (talk) 02:36, 10 July 2018 (UTC)


 * I consider this a sound guideline as well. A lot of the parameters are cruft in my view, including "cause of death" and "resting place". They also increase the chances of adding misleadingly over-simplified assertions in a highly visible area. Having witnessed the various infobox kerfuffles over the years and especially the 2013 ArbCom case, I found that these overly detailed megaboxes led to bitter, highly personalised disputes and decreased the chances of meaningful compromise. Huge, overly detailed boxes which basically tried to cram a a whole article into a vertical box are proposed on talk pages or added to articles. Barney results. Anti-infobox editors refuse to consider a simple pared-down box like the type used in the Encyclopædia Britannica, e.g. and the Australian Dictionary of Biography, e.g. . Instead, they see it as "the thin end of the wedge" and demand no infobox at all. What led to the ArbCom case were attempts to add these sorts of boxes to multiple articles in a short space of time, exhausting and driving away reasonable editors who might have participated. The mere suggestion of an infobox was viewed as a "breaching exercise". Given that at the time the primary box targets were FAs, there was some truth in the accusation, but the response was equally counter-productive. Voceditenore (talk) 08:38, 16 July 2018 (UTC)


 * We get things like New Zealand general election, 2017, which is huge, with 7 pictures. Some of that I think is unnecessary detail ("leader since", "leader's seat"), but much of it doesn't look like cruft. The question is whether it should all be an infobox in that form. There's an alternate infobox format, which you can see at Israeli legislative election, 2015. I've pushed for that (without the pictures), but there's been a lot of resistance. Bondegezou (talk) 09:10, 16 July 2018 (UTC)
 * Nine pictures for New Zealand general election, 2014. Bondegezou (talk) 09:12, 16 July 2018 (UTC)


 * Esther McVey is perhaps an interesting example. A politician with a very long infobox because she's had so many different roles, each of which gets listed. What should be the advice here? List everything, or drop some things when an individual has several notable roles? Bondegezou (talk) 12:31, 19 July 2018 (UTC)


 * I'd drop all "preceeded / succeeded", if that's not enough also the prime ministers at the time, - not tricky to find if someone really wants to find out, but not too relevant for her bio. --Gerda Arendt (talk) 12:47, 19 July 2018 (UTC)
 * I would agree with that. Is there a general statement about infoboxes that could be made that would support such a decision at the individual infobox template discussion level? Bondegezou (talk) 15:48, 23 July 2018 (UTC)

Prohibit usage in underdeveloped articles
It could serve as an incentive to improve an article if infobox usage was reserved for start class or better articles or conversely prohibited in stubs.


 * I see nothing contrary with requiring a minimum level of basic article development before an infobox becomes eligible for inclusion.--John Cline (talk) 02:36, 10 July 2018 (UTC)
 * Except that many users in many use cases access Wikipedia articles solely or primarily for the information in infoboxes (I often access cities and countries for the population or GINI stats, for example). Wikipedia is a reference work and its articles are often accessed for specific, narrow reasons—"disinfoboxers" habitually ignore this fact. Curly "JFC" Turkey 🍁 ¡gobble! 03:05, 10 July 2018 (UTC)
 * WP:EDITING policy is contrary to it, basically. I think the best we could do is suggest that an i-box is often not appropriate at stubs. This isn't true for some entire classes of articles, like those on species. Anyway, I can't think of anywhere else that MoS or another guideline policy is suggesting that a feature is [generally, usually, sometimes, conditionally, whatever] useful or an improvement but shouldn't be applied just because an article is underdeveloped (a stub). Adding features to articles is part of their development. See next item for a different way to get at this.  — SMcCandlish ☏ ¢ 😼  03:06, 10 July 2018 (UTC)
 * I don't see how this related to the ArbCom cases which inspired this discussion. Those involve infobox disagreements on articles which are extensive, not stubs. And as you said, we don't usually user infoboxes in these cases anyway. This feels like a rule just to say we made a rule about something - it's without substance, function, and relevance. --Netoholic @ 03:46, 12 July 2018 (UTC)
 * Oppose as counterproductive. Example: BR-Klassik (a one-sentence + infobox stub) would definitely be worse without the infobox. The box at least has an external link (the only one in the article) – without it the stub would be completely unreferenced. Not that this is anything near to what one would expect from an article, only it would be worse without the infobox. Such box gives a first indication for those who want to develop its content beyond stub state, and it contains around half of the useful content of the stub. Stubs are never intended as a permanent state of an article: whether one wants to start fleshing the article out by first adding prospective sources (eg in external link format), and/or some media from commons, and/or an infobox, and/or WP:SKYISBLUE prose, and/or WP:GNG-affirming content, etc., intermediate states en route to an acceptable article will probably never be perfect. --Francis Schonken (talk) 13:48, 19 July 2018 (UTC)
 * Gästgivars would be another example of a stub that would lose by removing its infobox. The entire page currently consists of:
 * Two sentences of prose (including one reference)
 * An infobox
 * A gallery with four images (each with a short caption)
 * A navbox
 * Removing any of these elements would be a step backwards – even elaborate prose would not so much be a replacement of the boxes or the gallery, as a much needed addition to balance out the prose-to-other-elements ratio. --Francis Schonken (talk) 14:57, 19 July 2018 (UTC)


 * Oppose The majority of gene articles are stubs and would be very lacking were if not for the infobox supplying basic information. Example: Cofilin 1 Natureium (talk) 15:02, 19 July 2018 (UTC)
 * Oppose: too prohibitive :). Also, "instruction creep". K.e.coffman (talk) 20:20, 13 October 2018 (UTC)

Avoiding infoboxes when there is little important information to summarize that is well-suited to tabular format

 * This gets at both the typical stub and the typical concept article, both cases where we usually don't have infoboxes. Approaching it this way avoids making categorical claims ("no stubs", etc.) that aren't valid (there are some stubs, like towns and species, where a certain kind of infobox is de rigeur and useful, even if the content of the article is otherwise a single sentence).  — SMcCandlish ☏ ¢ 😼  03:06, 10 July 2018 (UTC)
 * Certainly support this one. It's tempting to say that the article should be added to sufficiently to destub before an infobox is added (except for some types like those you mention), but perhaps better not. I've set out a-c points above on what characteristics of the subject make an infobox useful. Johnbod (talk) 17:05, 10 July 2018 (UTC)


 * I don't see how this related to the ArbCom cases which inspired this discussion. Those involve infobox disagreements on articles where the potential information for the infobox is extensive. And as you said, we don't usually user infoboxes in these cases anyway. This feels like a rule just to say we made a rule about something - it's without substance, function, and relevance. --Netoholic @ 03:49, 12 July 2018 (UTC)
 * This is really about quality not quantity. The important issue here is "well-suited" which is often at the heart of the most bitter disputes. What some infobox adders will attempt to put into boxes can make any box "extensive". But is the information accurate when summarized in one or two words, and so on? I don't think the phrasing here is perfect though. This would apply to vast numbers of articles on abstract concepts, many very long - try Epistemology, or for that matter Biology. Johnbod (talk) 04:21, 12 July 2018 (UTC)
 * We may also be thinking of different i-box disputes. I've seen quite a few that, without naming names, involved accusations of "drive-by" infoboxing with just a few factoids with the alleged motivation of getting an i-box into an article at the stub stage to later claim it had been there forever and ever when the article is a B-class or better development and an "anti-infoboxer" comes along; countered by claim that the info in the box was correct and that i-boxes are basically a "standard feature" at this stage. I don't think I agree with either side, but I've seen a lot of rancor about it.  — SMcCandlish ☏ ¢ 😼  00:54, 15 July 2018 (UTC)
 * That sort of thing has happened, certainly, but I think less often these days, and never at Epistemology etc - it's usually biographies. Johnbod (talk) 13:33, 15 July 2018 (UTC)

Underlying disagreement?
The debates over whether to include info-boxes (and if so, how) are reminding me of the debates over whether to include links to Wikidata (and if so how)... and I am wondering if there isn’t a root disagreement underlying both disputes: a fundamental (almost philosophical) disagreement between those who think of the presentation of information in terms of TEXT vs those who think of the presentation of information in terms of DATA. Or to put in in simpler terms: Is it the case that TEXT oriented editors dislike infoboxes, while DATA oriented editors want them? Thoughts? Blueboar (talk) 13:23, 13 July 2018 (UTC) — SMcCandlish ☏ ¢ 😼  00:50, 15 July 2018 (UTC)
 * I think it's a bit more complicated than that. The objections to including WikiData (especially in infoboxes) stem more often than not from WikiData's lack of reliable sourcing and the complication of expecting Wikipedia editors to edit incorrect WikiData entries which is not at all straightforward. On the other hand, I am very much a writer of text on Wikipedia, but I do include infoboxes on the articles I write (mainly operas and opera-related biographies) because I consider them helpful to the reader. I couldn't care less about the data-mining that results from an infobox. In fact, Google data-mines regardless and produces its own infoboxes in its search results even if the WP article doesn't have one. Observe the results of a Google search on Stanley Kubrick. Voceditenore (talk) 13:40, 13 July 2018 (UTC)
 * Oh, there is no question that there was more to the Wikidata debates than just TEXT vs DATA... however, I think TEXT vs DATA was part of that debate... so... I am wondering if that philosophical divide in how we think information is best presented isn't 'also playing a role in this debate about infoboxes? Some people are simply wired to think of information in the form of charts, graphs, and broken down bits of data, while others think in terms of words, sentences, nuances, and detailed explanation. It may even be a right vs brain left brain thing. Blueboar (talk) 15:37, 13 July 2018 (UTC)
 * And other editors can happily switch from a programmatic/data way of thinking to a creative/textual one. I think you'll find there is a wide spectrum of editors' abilities and that it's a mistake to try to label people into mutually exclusive sets. --RexxS (talk) 15:51, 13 July 2018 (UTC)
 * I agree, RexxS. That's why I present the articles I write in a way which serves both types of readers. I'm really not fussed about which way they prefer to get the information. Both ways are there. Nor do I mind if they only come to the article, read the basic facts in the infobox, and skip all my carefully researched and utterly delightful prose. I do that myself if I just need a quick check on something related to an article I'm writing, like when a composer died or where an opera premiered. However, I know that some editors who strongly oppose infoboxes have explicitly stated that they are only writing for people who will read the whole article and/or that the presence of an infobox discourages people from doing so. Voceditenore (talk) 15:59, 13 July 2018 (UTC)
 * I think is at least partly right. The question is where does this get us? Infoboxes are here to stay. The question is which articles should have them and what should they be they like. Is there some third way that satisfies everyone? Or is this just about a necessary compromise over which articles have infoboxes and keeping them small? Bondegezou (talk) 16:05, 13 July 2018 (UTC)
 * The answer to which articles should have infoboxes is purely subjective. If an editor weighs up the factors that are important to them, and then decides that an infobox would improve the article, then in that editor's opinion, the article should have an infobox, otherwise it shouldn't. When you generalise that to other content, it's pretty much how Wikipedia works anyway. The problems arise when an editor disagrees with another editor's assessment. That's why trying to find patterns, such as "scientific articles should, but humanities articles shouldn't" is a complete waste of time. We're far better off trying to politely explain why in our opinion a particular article should/shouldn't have an infobox. If we can't persuade other editors with opposing views to change their minds, and they can't persuade us to change ours, why not just leave it to whoever does the most work on the article? It's not a big deal. --RexxS (talk) 20:43, 13 July 2018 (UTC)
 * But RexxxS, you have already decided, as said above, that all articles would be better with infoboxes, pretty clearly a minority view as there are many types of articles which very rarely have infoboxes, as set out above. It is in fact possible to generalize about which type of articles are suited to infoboxes, although of course the distinction is nowhere near as crude as your caricature "scientific articles should, but humanities articles shouldn't", which is not a quote from anyone but you, in case anyone thinks it is. You basically advocate an indian reservation policy of limited tolerance to some small groups of nutters who don't like infoboxes on their articles. Johnbod (talk) 21:45, 14 July 2018 (UTC)
 * Simply untrue, John. I have never said "that all articles would be better with infoboxes". That's a complete strawman. Now I'm going to challenge you to give the diff that you pretend I wrote, or eat your words. There's nothing "set out above" but a load of your usual hand-waving about types of articles. It's pure delusion to think you can define any meaningful category of articles in the way you want to, without as many exceptions as inclusions. There is no distinction that you can express without more misses than hits. --RexxS (talk) 21:58, 14 July 2018 (UTC)
 * Just from here "I've been a strong believer that adding an infobox to an article generally improves the article for multiple reasons" above. I'm not trawling back through older discussions.  It would be a great help then if you could give some examples of articles you don't think should have infoboxes. That would be a first I think. You are simply wrong about the rest of it. Any formulation might well have many exceptions, and I would never suggest they are used rigidly, but as a way of giving a starting point for discussion it could be useful. Johnbod (talk) 23:21, 14 July 2018 (UTC)
 * Then your idea of quoting is to turn "generally" into "all articles? It's a good job we don't have to rely on you to draw accurate conclusions from discussions then. Make a start here: Talk:Buckingham Palace . Then you can really eat your words. I'm simply right about the rest of it, and considering how discredited your assumptions have already been shown to be, I don't think I need waste any more time refuting your evidence-free assertions. --RexxS (talk) 14:48, 15 July 2018 (UTC)
 * Ok "This is one of the few articles where I believe on balance that an infobox would not be a net improvement," you said. Apparently, "discredited" means "I don't agree with you, no matter who else does". Yes, best we stop. Johnbod (talk) 17:23, 15 July 2018 (UTC)
 * Except it is a big deal, and WP doesn't work that way. We have WP:OWN, WP:EDITING, and WP:LOCALCONSENSUS policies for a reason.  It simply is not the case that "whoever does the most work on the article" gets more say, about anything, as a matter of policy. (In particular cases some ownish behavior has temporarily had that result, simply by screaming louder and longer, but it can't be sustained. Loads of wikiprojects and FA "authors" have had to learn this the hard way.  "This is mine", a.k.a. "I did all the work", a.k.a. "you're not even an editor at this article", a.k.a. "WikiProject Foo has agreed that ...", may dissuade one random editor but it won't work against all of them.)  — SMcCandlish ☏ ¢ 😼  01:00, 14 July 2018 (UTC)
 * Only, WP works that way, in reality, not an ideal world. (Example: an article has an infobox for 10 years, but those - usually several - improving the article delete it because they think a plain photo is better.) Want to change that? --Gerda Arendt (talk) 06:48, 14 July 2018 (UTC)
 * The snag with your view, is it doesn't agree with Wikipedia reality. The presence or absence of an infobox is not something that is worth getting worked up about. We do have WP:OWN, WP:EDITING, and WP:LOCALCONSENSUS policies, but they are not worth going to ArbCom to enforce because productive editors simply end up being sanctioned. See Arbitration/Requests/Case/Infoboxes where I note you weren't arguing for those policies to be enforced. What do you make of Arbitration/Requests/Case/Infoboxes/Proposed decision, in the light of OWN? What do you make of Arbitration/Requests/Case/Infoboxes, in the light of CONLOCAL? The presence or absence of an infobox is a binary decision – there's no "middle ground" to find a consensus on. When polite and reasoned debate doesn't reach a consensus, how do you propose reaching a decision? If you insist on an RfC, and spend a lot of time arguing the case for an infobox, and the RfC eventually comes down in favour of an infobox on an article where the principal contributors don't want one, you end up with bitterness, editor retirements, and a lack of stewards for the article. It's simply not worth it. I'm a big fan of infoboxes, but the infobox is not a big enough deal to make those sort of sacrifices. Of course, that's just my opinion, and what would I know? I've only been fighting in the infobox wars for six years or so (although I'm glad for the current lull in hostilities, and I'd prefer to see it last). --RexxS (talk) 19:35, 14 July 2018 (UTC)
 * I think we're talking a past each other. I agree people shouldn't get worked up about an infobox, but they do, principally for territorial reasons. Lack of a default or any criteria means that article-level RfCs on infoboxes always devolve to pro/anti argument about infoboxes in general, not about the article in question. This problem is central to both of the ArbCom cases about infoboxes, and this meta-thread was opened to look into that problem. That very pattern is why people get fed up, yet the commenters in the "do nothing" camp above are begging for more of the same.  Is this a "the devil you know" situation? Looks like it to me. The community and process question raised by the idea of "whoever did the most work gets the biggest supervote" – a notion that comes up very frequently in many forms and rightly gets condemned, except when it happens in "closed rooms" of people who believe in this idea (e.g. at WP:FAC) – is not trivial at all and cuts right to the core of what this project is about.  I didn't participate in the original WP:ARBINFOBOX, but would have made the same policy argument in it, since it's the same one I consistently make any time this comes up.  The #Levels_of_consensus section at that case doesn't contradict me or vice versa.  "Taken into account" doesn't mean "automatically winning", it means "has a voice at the table".  As a practical matter, local consensus of regulars at an article is how most optional stuff gets decided. But it doesn't trump a larger consensus of more and broader editors (e.g. when an RfC brings in more than the locals and they're against what the locals want). If this were not true, we would not have an RfC system at all, since an RfC at an article's talk page would be completely meaningless, always being overridable by the one- or three-editor (or whatever) faction who feel "vested" or "tenured" by having made more edits at the page. WP obviously doesn't work that way at all.  When polite discussion fails, it seems that a decision isn't really reached, only a heightened stress level. But that also happens even if there's an RfC and a decision is reached. It's like arguing about religion, and people seem to get in a mood to burn heretics.  I'm not aware of any articles that have lost "stewardship" over an infobox. Anyone who starts out caring about the project enough to help carefully manage the qualify of article prose but then quits in a huff because they lost an infobox battleground (probably at least 50% of their own making) has drifted into being here for the wrong reasons; it's often best for them to take a break. I'm aware of a grand total of three editors who claimed to quit over infoboxes; two almost immediately returned (I don't know about the third).  Breaks are often effective when it comes to such matters (so are topic bans, if it comes to it, though when it gets the the ArbCom or dramaboard level, it's often already too late.).
 * Only, WP works that way, in reality, not an ideal world. (Example: an article has an infobox for 10 years, but those - usually several - improving the article delete it because they think a plain photo is better.) Want to change that? --Gerda Arendt (talk) 06:48, 14 July 2018 (UTC)
 * The snag with your view, is it doesn't agree with Wikipedia reality. The presence or absence of an infobox is not something that is worth getting worked up about. We do have WP:OWN, WP:EDITING, and WP:LOCALCONSENSUS policies, but they are not worth going to ArbCom to enforce because productive editors simply end up being sanctioned. See Arbitration/Requests/Case/Infoboxes where I note you weren't arguing for those policies to be enforced. What do you make of Arbitration/Requests/Case/Infoboxes/Proposed decision, in the light of OWN? What do you make of Arbitration/Requests/Case/Infoboxes, in the light of CONLOCAL? The presence or absence of an infobox is a binary decision – there's no "middle ground" to find a consensus on. When polite and reasoned debate doesn't reach a consensus, how do you propose reaching a decision? If you insist on an RfC, and spend a lot of time arguing the case for an infobox, and the RfC eventually comes down in favour of an infobox on an article where the principal contributors don't want one, you end up with bitterness, editor retirements, and a lack of stewards for the article. It's simply not worth it. I'm a big fan of infoboxes, but the infobox is not a big enough deal to make those sort of sacrifices. Of course, that's just my opinion, and what would I know? I've only been fighting in the infobox wars for six years or so (although I'm glad for the current lull in hostilities, and I'd prefer to see it last). --RexxS (talk) 19:35, 14 July 2018 (UTC)
 * I think we're talking a past each other. I agree people shouldn't get worked up about an infobox, but they do, principally for territorial reasons. Lack of a default or any criteria means that article-level RfCs on infoboxes always devolve to pro/anti argument about infoboxes in general, not about the article in question. This problem is central to both of the ArbCom cases about infoboxes, and this meta-thread was opened to look into that problem. That very pattern is why people get fed up, yet the commenters in the "do nothing" camp above are begging for more of the same.  Is this a "the devil you know" situation? Looks like it to me. The community and process question raised by the idea of "whoever did the most work gets the biggest supervote" – a notion that comes up very frequently in many forms and rightly gets condemned, except when it happens in "closed rooms" of people who believe in this idea (e.g. at WP:FAC) – is not trivial at all and cuts right to the core of what this project is about.  I didn't participate in the original WP:ARBINFOBOX, but would have made the same policy argument in it, since it's the same one I consistently make any time this comes up.  The #Levels_of_consensus section at that case doesn't contradict me or vice versa.  "Taken into account" doesn't mean "automatically winning", it means "has a voice at the table".  As a practical matter, local consensus of regulars at an article is how most optional stuff gets decided. But it doesn't trump a larger consensus of more and broader editors (e.g. when an RfC brings in more than the locals and they're against what the locals want). If this were not true, we would not have an RfC system at all, since an RfC at an article's talk page would be completely meaningless, always being overridable by the one- or three-editor (or whatever) faction who feel "vested" or "tenured" by having made more edits at the page. WP obviously doesn't work that way at all.  When polite discussion fails, it seems that a decision isn't really reached, only a heightened stress level. But that also happens even if there's an RfC and a decision is reached. It's like arguing about religion, and people seem to get in a mood to burn heretics.  I'm not aware of any articles that have lost "stewardship" over an infobox. Anyone who starts out caring about the project enough to help carefully manage the qualify of article prose but then quits in a huff because they lost an infobox battleground (probably at least 50% of their own making) has drifted into being here for the wrong reasons; it's often best for them to take a break. I'm aware of a grand total of three editors who claimed to quit over infoboxes; two almost immediately returned (I don't know about the third).  Breaks are often effective when it comes to such matters (so are topic bans, if it comes to it, though when it gets the the ArbCom or dramaboard level, it's often already too late.).
 * I'm quite certain it is a factor, and you'll see it come up in other areas, e.g.: the "I hate citation templates" crowd, people who under-link articles; those who object to language markup, semantic HTML, and other code; formatting of material that clearly should be in a table as a simple list instead; and so on. Anything that gets in the way of plain text, even at the source level, is an irritation to certain people. This can even rise to the level of a WP:CIR matter, since WP is a very "codey" place.  — SMcCandlish ☏ ¢ 😼  00:54, 14 July 2018 (UTC)


 * Drahmah enthusiasts might want to check out the fresh infobox dispute at Talk:Ezra Pound for evidence of why "let's do nothin is obviously the way to handle things. Curly "JFC" Turkey 🍁 ¡gobble! 13:40, 15 July 2018 (UTC)
 * Can’t tell if you are being sarcastic or not... In that specific case, it appears that there were multiple discussions as to why an infobox does not work. Drama could have been avoided by checking the archives. Blueboar (talk) 15:27, 15 July 2018 (UTC)
 * From my read drama could best have been avoided by a specific editor not being snippy, insulting and failing in good faith. I would suggest that editors who behave in that manner, for what ever reason and on whatever side, should be removed from infobox conversations until they remember how to be minimally civil and not to personally attack other editors. Contentious areas do not benefit from those who are unable to engage in discussion without attacking others regardless of what else they may bring to the table — and infobox disputes do not even have real life consequences like American politics, Israel/Palestine, etc. do to provide some mitigation/excuse for such poor behavior so we should be proportionately less forgiving of such behavior rooted in the 'Infobox wars'. From what I have seen the infobox question is not so much the issue as poor editor behavior seems to be. We will get nowhere solving the former until the later is addressed.  Jbh  Talk  16:04, 15 July 2018 (UTC)
 * (Edit conflict): Looking through the archives, the previous discussions are full of personal attacks and objections that (in my opinion) could easily be addressed. The editor who reopened the discussion (which they had a right to do) was immediately met with hostility, and every attempt to discuss the infobox itself turned into a meta-debate about how the discussion shouldn't have been reopened. This certainly appears to be a conduct/stonewalling issue that should be dealt with accordingly. In this particular case an RfC would be a good path forward. –dlthewave ☎ 16:10, 15 July 2018 (UTC)
 * Without commenting on the specifics of this "case", I have to note that ARBINFOX2 (finally!) authorized discretionary sanctions for infobox disputes; see Arbitration/Requests/Case/Civility_in_infobox_discussions. That can only be used with regard to events post-dating 28 March 2018, of course, but it's something. Nothing will change, probably, if WP:AE is not used to actually enforce the DS on people (on both sides) making infobox-related discussions into a hellhole in various places.  — SMcCandlish ☏ ¢ 😼  03:09, 16 July 2018 (UTC)
 * PS: Anyone who seems like their behavior needs to be addressed at AE will have to have first received {{subst:Ds/alert|cid}} at their user talk page; only disruption after receipt of it will qualify.  — SMcCandlish ☏ ¢ 😼  03:14, 16 July 2018 (UTC)

Single criterion
Above, someone said something like criteria would necessarily be complex. Don't buy it. For me there has always been just a single criterion, as simple (or complex) as the verifiability criterion: there are some ifs and buts depending on context, and the interpretations needed to apply it can be tricky, but the underlying principle is in fact simple, once one gets the knack of it. The principle is of the type "remove if not satisfying" (in that respect comparable to WP:V) rather than "include if satisfying" (which would rather be the WP:AfD MO), meaning anyhow that a WP:CONSENSUS can take account of other principles (like perfectly verifiable information can be thrown out of an article for WP:COATRACK reasons or whatever other applicable principle that is not strictly WP:V-related). When I participate in an infobox implementation discussion for a particular article, the principle at the back of my head is more or less this: Technical topics, such as species, would generally fall more easily on the "yes" side of this question than entries about philosophical subjects, such as positivism, nihilism etc, which would be at the "no" side extreme.

Elaborating an example: above it is said somewhere that musical compositions are usually unproblematic for infoboxes – on the other hand, articles on compositions with an unclear or complex history of origin seldom or never have an infobox (could list half a dozen without much effort). For instance, it is not very sensibly possible to summarize, in "keywords, numbers and codes", a decade-long discussion among specialized scholars on the attribution of a composition (even if, in the end, the attribution issue seems to have been settled satisfactorily) – even if a summary of that aspect would technically be possible, it might be too dominant in an infobox, as if the value of the music as such is subordinate to the question of its author. Thus, for example, Oboe Concerto (Marcello) has no infobox: complex history of origin, key unclear, etc. Once all of that is summarized in "keywords, numbers and codes" the sum of it will hardly give a balanced representation of the article topic. --Francis Schonken (talk) 16:08, 19 July 2018 (UTC)


 * I mostly agree with the criterion, but feel misunderstood: "musical compositions are usually unproblematic" means that I recall few debates, after the noise about infobox opera died down. Look at Mass in C major (Beethoven), for example: some friendly discussion. I never read the concerto article, and confess that the prose is also not too clear to me, so I can't help thinking that some hint at Baroque and possible composers, together with related pieces, might be easier to grasp for some readers. But I won't be the one to propose there ;) --Gerda Arendt (talk) 16:59, 19 July 2018 (UTC)
 * I don't know who wrote, above: "Uncontroversial topics that primarily use infoboxes [...] Musical compositions [...]", but I certainly did not misunderstand or misinterpret it. Here's a way to clarify my elaborated example:
 * Step 1: click →→→here←←← (that's a navbox you know very well)
 * Step 2: click on any asterisk-less number in that box: you will almost certainly see an article with an infobox (I think the odds are about 90%)
 * Step 3: return to the navbox, and click on any number with one or two asterisks: you will almost certainly see an article without an infobox, again around 90% chance (the asterisks denote "doubtful" and "spurious" compositions, thus the ones that per my elaborated example, show, in practice, to be more often problematic for infoboxes).
 * --Francis Schonken (talk) 17:48, 19 July 2018 (UTC)
 * You are right, but that relates more to the (lack of) attention those "spurious" works get, + the lazyness of an editor (like me) to do something complicated. --Gerda Arendt (talk) 08:18, 20 July 2018 (UTC)
 * No problem. I tried to update the infobox of the single "asterisked" one I could find which already had one. Don't know whether the three-line subtitle in the infobox really works (I'm not too convinced myself). Same for other aspects which possibly make the box too elaborate... In sum, for this article I'd do without an infobox as well. --Francis Schonken (talk) 09:46, 20 July 2018 (UTC)
 * ... and *poof* --Francis Schonken (talk) 11:48, 20 July 2018 (UTC)
 * My own formulation above ( The articles suited to infoboxes are about discrete things, whether people, places, taxa, events etc, where the important things to know about the subject are a) the same for other members of that class of thing, b) objective facts that are straightforward to verify, and c) clear and easy to state. The types of articles not suited to infoboxes are those where any of these three factors is not the case, which includes most articles on broader topics and concepts, but also some on things (like people of certain types). ) is similar, but introduces a couple of other elements. I think "objective" is important - most box disputes I see have issues about subjective/doubtful/dubious information in fields like :"main works, style, movement, infuenced by" etc. While in theory a one-off type of infobox is fine, in practice they work best when there are lots of a class of article, whether beetles or football players, and the fields can be refined. I agree re compositions - the situation is the same with works of art, where many, especially early ones, have too little certainly known information for a box to be useful. Johnbod (talk) 18:08, 19 July 2018 (UTC)
 * Well,
 * the "single criterion" is simpler than the three-tier criterion;
 * the single criterion also fits better: it is not because something is "clear and easy to state" that it gives an overview-in-a-glance of the core of the article topic. Case in point, some bigger-than-life artist can have a "clear and easy to state" curriculum ... that doesn't even begin to summarize what the artist was all about, where his true significance for mankind lies. Think Stanley Kubrick, at the root of this renewed interest in getting criteria written down.
 * --Francis Schonken (talk) 18:31, 19 July 2018 (UTC)
 * That's turning it on its head. It is indeed "not because something is "clear and easy to state" that it gives an overview-in-a-glance" - of course not. But to work in a box it must be "clear and easy to state", and if the facts meeting that criterion do not add up to an adequate overview, then the box fails to be useful. I've no real idea what a "bigger-than-life artist" might be, but I dare say it doesn't matter. I haven't looked at Stanley Kubrick, as I try to limit my exposure to infobox disputes, but Ezra Pound might work as a case where very important things are not "clear and easy to state" - I suppose he might be "bigger-than-life". Johnbod (talk) 01:51, 20 July 2018 (UTC)

I don't think what we're saying is all that different. Grouping the responses above, there seem to be three main approaches: ... then we're both in the second line of thought. For clarity, the way I tentatively formulated the "single criterion" has two halves too (the technical possibility of a key concept summary; whether or not that results in an apt summary of the article topic); your formulation splits more or less the same in three sub-criteria. Let's keep in mind that both formulations are not far from one another. I'd put some effort in ironing out the minor differences, keeping in mind that the thrust is near-identical. I do think that if such criterion would be adopted, a set of examples should clarify the proposed principle (so there'd be, in a way, some of the #3 approach too, but under the umbrella of a general principle).
 * 1) Do nothing, a.k.a. no criteria, or: defy the ArbCom recommendation
 * 2) Single criterion
 * 3) Convoluted set of multiple ad hoc criteria

Generally, I'd keep the formulation of the basic principle as compact as possible (think e.g. how the basic formulation of WP:GNG is no more than a single sentence) – in that sense I think that my proposal works better than yours. As for ironing out minor differences, here's another example, addressing your first sub-criterion (sorry that most of my examples belong to the same topic area, that's the one I know best): Bach's first biographer wrote about Bach's Chromatic Fantasia and Fugue: "I have given much effort to find another piece of this type by Bach. But it was in vain. This fantasy is unique and has never been second to none." – would something that falls in a "class of it own" fail "the important things to know about the subject are [...] the same for other members of that class of thing"? Surely, that could be debated endlessly & fruitlessly; in practice there is, however, apparently no impediment for an infobox: the Wikipedia article on that composition has one. I do think there's room for improvement of that infobox, but I'd rather discuss that on the basis of the two-tier formulation of the single criterion than on the basis of its three-tier formulation. --Francis Schonken (talk) 07:30, 20 July 2018 (UTC)
 * I agree our two formulations are fairly similar. I'm not seeing the relevance of the Bach example - it uses "Infobox Bach composition", certainly a large class, which seems to work ok. No doubt there is an "infobox keyboard composition" too. I suppose it is just an eccentricity of our classical music style that neither box nor text seem to give any indication of the typical time in performance, which I would think of as a key piece of information. Johnbod (talk) 15:11, 20 July 2018 (UTC)


 * This is basically restatement of the principle already listed above at . I like "keywords, numbers and codes" bit, being more precise.  — SMcCandlish ☏ ¢ 😼  10:04, 20 July 2018 (UTC)
 * Yes and no. is rather part of a "multiple criteria" approach – the proposal in the current subsection is explicit in choosing a "single criterion" approach, with the exclusion of competing criteria, meaning that such other criteria are either rejected (e.g. what I would do with ), reformulated as particular implementations of the general principle (e.g.  could be reformulated thus imho), or kept out of the infobox-specific guidance (could give examples for that too, but let's not digress for the time being).
 * Other than that, there are some minor formulation differences (like with Johnbod's three-tier formulation): the thrust is somewhat the same, but, for example, I'd avoid qualifiers like "important" while too prone to discussion (what's important for one editor might be quite irrelevant for another): whether the end result is an infobox that delivers a short-form "spitting image" of the article topic seems a more important adequate approach (and easier to assess) to me – in other words, the kind of details in the formulation I'd like to iron out. --Francis Schonken (talk) 10:41, 20 July 2018 (UTC) (updated in order to avoid confusion about what I tried to say 12:09, 20 July 2018 (UTC))
 * "what's important for one editor might be quite irrelevant for another" - and there's the nub of the problem with this approach. I treat the ability of some infoboxes to emit microformats as important. A third-party re-user scraping data from Wikipedia would find having the information in key-value pairs as particularly important. Google found it important that our infoboxes duplicate in tabular format many pieces of information that exist in prose in the body of the article, so they were able to use them to train their natural reading programs. I know of one editor who tries to make the balance of images and prose as aesthetically pleasing as possible in the articles they write, and finds infoboxes ugly, so attaches a low importance to them. Other editors believe that infoboxes distract from the lead of the articles that they write work on, and therefore hold them in very low importance. There is not a binary divide between "articles suitable for infoboxes" and "articles not suitable for infoboxes" - there is a spectrum of value for suitability, and that depends on a wide number of factors, each of which will receive a different weighting from each individual editor. Just because you can identify articles at the extremes of that spectrum, doesn't mean that the majority of articles don't fall somewhere in-between. --RexxS (talk) 11:52, 20 July 2018 (UTC)
 * As said, the approach explained in this subsection avoids (deliberately) the "important" qualifier in the criterion description, rather looking at the over-all end result of the box than at the would-be "importance" of individual descriptors – maybe post your suggestion in the appropriate place (which would be afaics)? Tx. --Francis Schonken (talk) 12:04, 20 July 2018 (UTC)
 * And as I demonstrated, "importance" is a valid consideration to make, as are many other factors, so that's why this subsection, trying to find a single criterion, is a waste of everybody's time. There's nothing here that could possibly be useful in helping decide "the drafting of infobox inclusion criteria". I don't accept that you have any right to completely disregard so many equally valid inclusion criteria, simply because you don't agree with, or understand, them. And that's why I posted my objection in the section where it's relevant. Perhaps you should concentrate on working on the actual issues, rather than patronisingly making suggestions about where I may post. --RexxS (talk) 12:14, 20 July 2018 (UTC)
 * Sure, when deciding whether or not to include a particular parameter in an infobox, then that parameter's relative importance plays a decisive role – but a sound discussion on whether or not a clearly defined particular parameter is included in the box should preferably have little to do with whether or not there's going to be an infobox in that article. Currently (I mean, under the current lack of guidance), an interminable discussion about which parameters to include may oust the infobox altogether, irrespective of whether an infobox would be beneficial for the article. I'd try to slowly move away from such conundrums (at least diminish their frequency) by clarifying an underlying principle that could help guide such discussions, that is: everyone speaking more or less the same language (as a manner of speech). I mean, much like WP:GNG, and a set of particular notability guidelines, streamline WP:AfD discussions, or WP:CRITERIA (and a set of particular naming conventions) have taken the "interminable" out of most WP:RM discussions. --Francis Schonken (talk) 12:50, 20 July 2018 (UTC)
 * We don't disagree about discussions around whether to include a particular parameter. Nevertheless – as I've already demonstrated in the examples above –  the numerous factors I collected at User:RexxS/Infobox factors currently all play a part in the decision on whether to include an infobox or not, for some editors. I find it problematic that this part of the discussion is effectively discounting many factors that are of prime importance to different editors, thus disenfranchising their view from the debate in any given article. Is it not true that adopting the single criterion you suggest would mean that nobody could then argue for the value of an infobox in emitting microformats, or for the aesthetic value conferred by not having an infobox? --RexxS (talk) 13:31, 20 July 2018 (UTC)
 * What I propose is in line with the Wikipedia way that worked for WP:AfD, WP:RM, etc: not individual editors weighing their own criteria according to their own assessment, but offering tools for weighing opinions in a common system, that, for instance, would help someone closing an RfC on an infobox implementation. That may involve discounting some argumentations (comparable to how Arguments to avoid in deletion discussions is helpful for determining the outcome of an AfD discussion), and enhancing other argumentations which are more in line with a suitable umbrella principle (compare WP:GNG, WP:CRITERIA, etc). You're free to oppose such ideas, of course, but the advantages and viability seem obvious to me. --Francis Schonken (talk) 15:44, 20 July 2018 (UTC)
 * So, your answer is "yes". You want to prevent editors from arguing for or against an infobox unless they focus on the particular considerations that you deem the "right" ones. I see that you anticipate guiding the closers of infobox discussions to ignore any argument that is based on the value of the structured data in the infobox, or on the aesthetics of the infobox, or on whether the infobox has previously received community approval/disapproval at FAC, or that a prior consensus exists, etc. You haven't understood that those sort of considerations are in no way analogous to the essay WP:Arguments to avoid in deletion discussions because those "... have been identified as generally unsound and unconvincing". Nobody has ever shown that the factors I'm referring to are "unsound" or "unconvincing". Well, I can tell you now I'll be opposing that sort of prescription, and I won't be the only one. --RexxS (talk) 22:05, 20 July 2018 (UTC)
 * So, your answer is "yes". You want to prevent editors from arguing for or against an infobox unless they focus on the particular considerations that you deem the "right" ones. I see that you anticipate guiding the closers of infobox discussions to ignore any argument that is based on the value of the structured data in the infobox, or on the aesthetics of the infobox, or on whether the infobox has previously received community approval/disapproval at FAC, or that a prior consensus exists, etc. You haven't understood that those sort of considerations are in no way analogous to the essay WP:Arguments to avoid in deletion discussions because those "... have been identified as generally unsound and unconvincing". Nobody has ever shown that the factors I'm referring to are "unsound" or "unconvincing". Well, I can tell you now I'll be opposing that sort of prescription, and I won't be the only one. --RexxS (talk) 22:05, 20 July 2018 (UTC)

What is the goal - and can we achieve it?
The premise for this RFC was that Arbcom wants us to come up with something to prevent "circular, endless page-by-page and sometimes category-by-category fighting." Unfortunately, I don't think that any of the suggestions that we have proposed (at least so far) achieve that goal... our fellow editors will still hold circular, endless page-by-page and category-by-category arguments - all we are achieving is a minor shifting in HOW they will argue, and what they will argue ABOUT. So... lets refocus on the goal... and that means addressomg a more fundamental question: is the goal even achievable? Blueboar (talk) 14:14, 20 July 2018 (UTC)
 * Initially I was very doubtful that anything would come of this initiative (see way above), but have now come to feel it can be useful (see above). I think we can produce a general non-prescriptive, non-bureaucratic statement on the factors that make a particular article more or less suitable for an infobox. We should also stress that accuracy is very important, and that if an infobox does not represent the subject well enough it is ok to remove it (rather than the adder saying "ok, you fix it"). I believe this would substantially reduce the number of rows, which many above agree are already in decline, but no doubt some will still remain. Johnbod (talk) 15:02, 20 July 2018 (UTC)

If arb come had been willing to decide the actual issue ,which it was not, I would have advocated on behavioral-related grounds for  the inclusion of infoboxes in all articles where the topic is distinct enough and has sufficient distinct factual content to have one. (which would include--for examples and not as a limitation-- all biographies. all creative works, & all organizations). My reason would be that  opinions on this issue are so irreconcilable, that the only way to avoid infinite argumentation is to have a general rule. I would reject the general rule that we have no infoboxes at all, not because I like them, which I do not--as far as my personal use of WP is concerned I find them distracting; as far as editing is concerned I find them a nuisance--, but because they add to the potential uses for the encyclopedia and, properly programmed, can assist universal access--both of which are over-riding considerations. I would also have accepted a overall yes / no vote. sufficiently advertised and over a sufficient time, because even the view I reject would be better than further individual discussions.

If this were not accepted, I'd propose that it be a fixed decision for areas as defined by wikiprojects, wwith yes/no votes, (obviously everyone could vote, regardless of whether they were embers of the project.

l ask those inalterably opposed to infoboxes, in these discussions, had you come to WP when there was a general consensus to have infoboxes, as strong as the general consensus that articles must be referenced,  wouldn't you have been able to work here on your favorite topics nonetheless. And, reciprocally, for those who inalterably absolutely support them. In fact, I think the need to avoid these arguements so strong that I would even support a universally binding random decision.

If you look at my comments on the proposed decision, you will se the traces of what I thought it practical to say without being unconstructive.  DGG ( talk ) 04:19, 21 August 2018 (UTC)