Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

RfC: Removing "Clear the watchlist" from main watchlist screen[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
During the discussion it arose that this button exists at Special:Watchlist not only in vector2022, but also in minerva and vector if JavaScript is disabled. We have a consensus that the option should be removed from Special:Watchlist. Currently this functionality is also available at Special:EditWatchlist and Special:Preferences, where most participants do not object to it. -- Maddy from Celeste (WAVEDASH) 20:47, 29 May 2023 (UTC)Reply[reply]

As we know the new default skin Vector-2022 has a "Clear the watchlist" option on the main watchlist screen beside "Edit raw watchlist" option. Personally, I get scared by its existence here, I have a habit of misclicks and I have 3000+ pages in the watchlist. I can't afford to lose it all. This option may also cause some confusion to non-native English users: "Clear the watchlist" might also mean that the current watchlist screen is cleaned, and not all the pages of watchlist. And ofcourse this is not as widely used an option to merit inclusion right on front of the watchlist screen. People don't put pages on their watchlist only to perform a mass removal 2 days later. This option can safely be moved away from the main page and only inside the edit watchlist pages. This RfC is to determine whether there is consensus among the community to seek such a technical change to the new watchlist. CX Zoom[he/him] (let's talk • {CX}) 07:42, 15 April 2023 (UTC)Reply[reply]

NOTE that I was inactive during the post-deployment discussions, so if this issue was already raised that time and was voted up or shot down, feel free to early close this one. CX Zoom[he/him] (let's talk • {CX}) 07:42, 15 April 2023 (UTC)Reply[reply]

UPDATE: I have been made aware below that the "Clear the watchlist" option has always existed. Most (including me) didn't see it on our watchlists because the "JS watchlist" was enabled by default which hid the "Clear the watchlist" option in the previous default skin, Vector legacy. This, however, raises the question, that when the need for removal of this option was felt due to obvious reasons, why was it removed using a JS workaround that is incompatible with the current default skin (Vector-2022), rather than from the software side itself. CX Zoom[he/him] (let's talk • {CX}) 16:25, 1 May 2023 (UTC)Reply[reply]

Survey (Clear watchlist)[edit]

  • Support as proposer. CX Zoom[he/him] (let's talk • {CX}) 07:42, 15 April 2023 (UTC)Reply[reply]
  • I hadn't even spotted that it was there. You've got me frightened now, as I too often misclick. I'm sure I didn't so often when I was younger, so it must be an age thing. I daren't click the option to check this for myself, so is there a "do you really mean to do this?" failsafe message when you do? Without at least this I would certainly support the proposal, and would probably do so anyway. Phil Bridger (talk) 09:25, 15 April 2023 (UTC)Reply[reply]
    There is a confirmation message.
    Clear watchlist
    All of the titles will be removed from your watchlist
    Clear the watchlist (This is permanent!)
    However, my concerns about non-native English users like me confusing this up remain. What exactly is meant by "all titles"? And again, this does not need to be on the front under any logic. It should be shown only to those who attempt to edit their watchlists. CX Zoom[he/him] (let's talk • {CX}) 10:03, 15 April 2023 (UTC)Reply[reply]
  • Support I see no reason why it should be where it is. It hardly seems to be the kind of thing you do so often that you need quick access to it. Moving it to the edit menu makes sense. -- Random person no 362478479 (talk) 11:01, 15 April 2023 (UTC)Reply[reply]
  • Support removal of this button. It is too dangerous on the watchlist. Graeme Bartlett (talk) 12:03, 15 April 2023 (UTC)Reply[reply]
  • The "Clear the watchlist" link exists in all skins and has existed long before Vector 2022. The opening statement of the RfC seems misinformed. And it can be hidden by the CSS #ca-special-specialAssociatedNavigationLinks-link-3 { display: none; }. Nardog (talk) 13:58, 15 April 2023 (UTC)Reply[reply]
    On Vector legacy, "Clear the watchlist" exists at Special:EditWatchlist & Special:EditWatchlist/raw, but not on Special:Watchlist. On Vector-2022, "Clear the watchlist" exists on all the pages, which is not ideal. This option does not have to be on Special:Watchlist. CX Zoom[he/him] (let's talk • {CX}) 15:46, 15 April 2023 (UTC)Reply[reply]
    Not true. Vector legacy definitely has the link, for me it's the last item in the line "For Redrose64 (View relevant changes | View and edit watchlist | Edit raw watchlist | Clear the watchlist)" just below the title and above the line beginning "You have nnn pages". If you're not seeing it there, you have some customisation that hides the link. --Redrose64 🌹 (talk) 17:35, 15 April 2023 (UTC)Reply[reply]
    I do not see either of these lines, the only things above "You have nnn pages" and below the title for me are the watchlist notices. Aaron Liu (talk) 19:46, 15 April 2023 (UTC)Reply[reply]
    I don't seem to recall checking any option to do that in my preferences. And my js scripts aren't doing it because it remains the same in safemode. And the three possible css pages that could do this have nothing related to it. (User:CX Zoom/common.css, User:CX Zoom/vector.css, m:User:CX Zoom/global.css). Infact, I couldn't replicate what you say, even on my alternate accounts User:CX Zoom Alt, User:CX Zoom Safemode, the latter of which intentionally calls no js/css. CX Zoom[he/him] (let's talk • {CX}) 19:49, 15 April 2023 (UTC)Reply[reply]
    I see the same as Aaron Liu in the old vector, i.e. nothing. Phil Bridger (talk) 20:08, 15 April 2023 (UTC)Reply[reply]
    In Vector 2010, I think these options only appear if you have "Use non-JavaScript interface" enabled in Preferences. Sojourner in the earth (talk) 20:18, 15 April 2023 (UTC)Reply[reply]
    Vector legacy (2010) skin
    Here is a screenshot from Vector legacy (2010) skin, including the link titled "Clear the watchlist" (it comes from MediaWiki:watchlisttools-clear). I also offer equivalent screenshots for the six other skins currently installed: Cologne Blue skin; MinervaNeue skin; Modern skin; MonoBook skin; Timeless skin; and Vector (2022) skin. All of them have the same link, albeit not all the same styling. --Redrose64 🌹 (talk) 09:31, 16 April 2023 (UTC)Reply[reply]
    Strange. I don't have those links on 'Vector Legacy'. I don't see anything in the preferences. It does appear on Vector 2022 though. SWinxy (talk) 17:32, 16 April 2023 (UTC)Reply[reply]
    What Sojourner in the earth said. So the apparent addition of the link isn't a deliberate decision by the V22 devs but simply a by-product of moving the tool links above the page body. Nardog (talk) 17:42, 16 April 2023 (UTC)Reply[reply]
    ohhhhhhhh SWinxy (talk) 23:34, 16 April 2023 (UTC)Reply[reply]
    I can confirm that these options only appear with non-JS interface. Aaron Liu (talk) 18:34, 16 April 2023 (UTC)Reply[reply]
    Thanks, this explanation clears it up for me. However, I have two doubts:    1) I don't see them even with ?safemode=yes. Why does the Watchlist JS still get called?    2) Whosoever created the JS Watchlist must've recognised the uselessness of "Clear the watchlist" option on watchlist, that is why they must've hidden it. So, why not hide it from software side rather than a JS workaround? CX Zoom[he/him] (let's talk • {CX}) 09:16, 17 April 2023 (UTC)Reply[reply]
    For 1), safemode doesn't disable all JavaScript, just your userscripts in common.js/vector.js/etc Aaron Liu (talk) 11:30, 17 April 2023 (UTC)Reply[reply]
  • It’s worth nothing that this proposal placed 147th in the Community Wishlist Survey 2023. Snowmanonahoe (talk) 14:11, 15 April 2023 (UTC)Reply[reply]
  • The links at the top of the watchlist (View and edit watchlist; Edit raw watchlist; Clear the watchlist) are not specific to Vector 2022 - they are also in the watchlist for all other skins, and what is more, have been there for as long as I can remember (almost 14 years). If you really want to hide the link, it can be done in CSS - but the actual CSS selector differs according to your skin. For Vector 2022 (but not legacy Vector) it is
    li#ca-special-specialAssociatedNavigationLinks-link-3 { display: none; }
    and this goes in Special:MyPage/vector-2022.css. If anybody wants the equivalent CSS rule for another skin, just ask. --Redrose64 🌹 (talk) 15:35, 15 April 2023 (UTC)Reply[reply]
    One of the things I mentioned on the recent Vector-2022 zoom call was the need for greater stability of the skin APIs. There really is no reason why every skin that exposes a "Clear the watchlist" functionality couldn't include that inside a HTML element with class="clear-watchlist-control" (maybe id instead of class?). Then people who wanted to make it go away could do so in a skin-independent way. I've got
    #pt-logout { display: none; }
    in my common.css for exactly the same reason. One time too many, an accidental click (especially on my phone) would log me out. And due to the way logout works, it would log me out from all my devices. And since I use 2FA, if I didn't happen to have my authenticator with me, I'd have just committed a one-click accidental DOS attack on myself. -- RoySmith (talk) 15:50, 15 April 2023 (UTC)Reply[reply]
  • Neutral This button has always been present in the same location in Vector 2010's non-Javascript watchlist, and also in Timeless and Minerva. When you click it, you get a big red warning sign asking for confirmation, so I think the danger is minimal. That said, the button doesn't really need to be where it is (or to exist at all, now that the "check all" option is available on the "Edit watchlist" screen). I'd say if it's technically easy to remove it, remove it; if it's technically difficult, let it be. Sojourner in the earth (talk) 20:34, 15 April 2023 (UTC)Reply[reply]
    If you have more than about 20,000 (±10%) pages in your watchlist, the "View and edit watchlist" screen may not be feasible: it can time out if it takes too long to (a) load; (b) action the "check all" option; (c) action the "Remove titles" button. --Redrose64 🌹 (talk) 23:04, 15 April 2023 (UTC)Reply[reply]
    Is there anyone who has more than about 20,000 pages in the watchlist and wants to delete them all? I doubt it. If we have a problem with large watchlists then that should be addressed, rather than a useless workaround be offered to users. Phil Bridger (talk) 18:46, 16 April 2023 (UTC)Reply[reply]
    Can't they just edit raw? Aaron Liu (talk) 18:52, 16 April 2023 (UTC)Reply[reply]
    @Redrose64: My watchlist has 12,375 items and it struggles a bit to load the raw list (I copy it over to the watchlist for User:Aoidh (Away) periodically), but if they need to clear the watchlist entirely then that option already exists in the Watchlist section of Special:Preferences. - Aoidh (talk) 03:27, 24 April 2023 (UTC)Reply[reply]
  • Support - (Summoned by bot) I don't use Vector 2022 by default and I'm assuming my tweaking my CSS has removed this elsewhere so I never noticed this until I checked for it after reading this discussion, but I do think that this is too prominently placed for something that most editors will absolutely not want to do. If you had asked me how to clear the entire watchlist I would have said that it would be in "Preferences > Watchlist" and I just checked and "Clear your watchlist" is there as a button with red text making it clear that this is an extreme option. If this link is removed from the watchlist page it's still accessible for those wanting to remove their entire watchlist, and those with a tenuous grasp of English or otherwise not understanding what "clearing all titles" mean are far less likely to accidentally click through a red button in the watchlist section of their preferences page than they are a comparatively innocuous-looking link at the top of their watchlist. - Aoidh (talk) 00:18, 24 April 2023 (UTC)Reply[reply]
  • Support removal and from all skins if necessary. Just flat out remove this functionality. Please see this relevant Far Side comic. Back when bulletin boards were a new thing, a common Madrona Park option was a "clear all text" button. But... why would you ever need this? No confirmation on that one, either, it just did it. If you really needed to clear the text window, CTRL-A + delete did the trick regardless. Anyway, there is absolutely no need to implement a "wings fall off" button on watchlists. If someone really, really wants to do this, they can go to Special:EditWatchlist/raw, select all, and delete it themselves. This will happen once in a blue moon, and it has the merit of working better for people who merely want to clear *most* of their watchlist, and it'd be what, 2 seconds slower than the dedicated process? For an action most editors will do never, or at most once? Delete it with fire. SnowFire (talk) 06:27, 1 May 2023 (UTC)Reply[reply]
    While I agree, the clear watchlist button has a confirmation. Aaron Liu (talk) 11:33, 1 May 2023 (UTC)Reply[reply]
    And the confirmation for rollback no longer works for me. I long ago enabled confirmation for rollback to avoid accidentally rolling back edits. That stopped working for me a while back, so that even though I select "cancel" on the confirmation notice, the rollback still proceeds. I can easily revert accidental rollbacks. It would only take one time for the cancel button to fail on clear watchlist to wipe out the over 5,000 items on my watchlist. Donald Albury 11:54, 1 May 2023 (UTC)Reply[reply]
    That'd be a bug and you should report it to phabricator. Aaron Liu (talk) 12:00, 1 May 2023 (UTC)Reply[reply]
    Eh? I've had rollback since 2010 and it's never had a confirmation step for me. I can't find any option for this in preferences, either. --Redrose64 🌹 (talk) 18:31, 1 May 2023 (UTC)Reply[reply]
    In Preferences, Gadgets, Browsing, there is an item, "Require confirmation before performing rollback on mobile devices", which I have checked (I don't think my Chromebook counts as a mobile device, however). I also have installed User:Mr. Stradivarius/gadgets/ConfirmRollback.js in my common jss. I used to get two confirmation notices, and could sucessfully cancel an accidental rollback. Now I normally only get one confirmation notice (I sometimes see the second one flash on the screen very briefly), and clicking on "cancel" does not stop the rollback. That has not yet been enough of a problem for me to pursue a solution. My main point, however, is that if the confirmation process for a rollback can break, then it is possible that the confirmation process for clearing a watchlist could break, and fail to stop a watchlist clear action. Donald Albury 19:47, 1 May 2023 (UTC)Reply[reply]
    You didn't mention mobile in your post of 12:00, 1 May 2023 (UTC). I have no mobile, and tend to ignore any prefs that are mobile-specific. That said, I find that the preference concerned is enabled for me (it was apparently added in June 2015 as an opt-out gadget, with a four-person consensus).
    If a script provided by Mr. Stradivarius (talk · contribs) isn't working as it should, you should inform Mr. Stradivarius on their user talk page: indeed, this is entirely the wrong venue to be reporting script problems. --Redrose64 🌹 (talk) 08:08, 2 May 2023 (UTC)Reply[reply]
    I've brought this up on Donald's talk page. — Mr. Stradivarius ♪ talk ♪ 03:40, 3 May 2023 (UTC)Reply[reply]
    If you have too many pages on your watchlist, the "raw edit, select all, and delete" method does not work due to timeouts or excessive page size. The "clear" option uses the job queue to do it for extremely large watchlists without overloading the DBs. Anomie 11:53, 1 May 2023 (UTC)Reply[reply]
    Sure, but dismantling bridges also requires special procedures, but it's rare enough that we don't install a "dismantle bridge" button at the entrance. This is an argument that perhaps the Special:EditWatchlist/clear option should be kept (although I'd say even this is suspicious, just do it manually in smaller batches), but it certainly shouldn't be highlighted. For the one person every two years who has compiled a watchlist of tens of thousands of articles AND wants to clear it efficiently, they can be pointed to the clear option at the Village Pump tech help. There's no need for a button to get you there faster, and potentially harm. SnowFire (talk) 17:05, 1 May 2023 (UTC)Reply[reply]
    I was replying to where you said Just flat out remove this functionality. I also note your batching idea wouldn't work if people can't even load the page because it's too big. Anomie 23:05, 1 May 2023 (UTC)Reply[reply]
    If people are unable to edit their watchlist because it's too big, then that is a problem that needs to be fixed by the developers not a reason to reject this proposal. Thryduulf (talk) 09:58, 2 May 2023 (UTC)Reply[reply]
    It seems to me they did fix it, by having a "clear watchlist" feature that uses the job queue. And I think that's excellent reason to oppose the "just flat out remove this functionality" sub-proposal. Anomie 11:42, 2 May 2023 (UTC)Reply[reply]
    I still struggle to see anyone with 5000+ items gathered over months and years to go clear it all instead of selectively weeding out the less important items from the more important ones in their list, to do which "clear watchlist" isn't really a good feature. Devs should try to explore other alternatives that fixes "raw edit" page, if one wants to clear it all: Ctrl+A > DEL is all they'd need to do. At the very least, the behaviour of the "Clear the watchlist" option should resemble the one already seen in "JS watchlist" on vector legacy, that hides this option in the main watchlist, but shows it in the edit pages. CX Zoom[he/him] (let's talk • {CX}) 15:06, 2 May 2023 (UTC)Reply[reply]
    I think you're about 1.7–2 orders of magnitude lower than where people have the problem being discussed here. SnowFire just below is at 2.4, and apparently doesn't believe anyone who accidentally got their watchlist that full would ever decide to start using it. Anomie 12:03, 3 May 2023 (UTC)Reply[reply]
    (de-indent) Re Anomie, to be clear, I still support removing the functionality entirely, just think that hiding it away is a good enough compromise. If we put on project manager hats for a moment - so what that it's technically tricky to mass delete watchlists? Maybe it'd be technically tricky to submit a bulk edit that transforms 1,000 articles into Pig Latin simultaneously, too. But that's a useless task. Again, it really needs to be restated that I find the use case of this functionality incredibly rare: an editor who's built up an exceptionally large watchlist AND wants to unilaterally delete everything (if they want to retire, they can just not login to their account anymore...). There's a certain cost with maintaining functionality and increased complexity, and it doesn't matter how clever or efficient the Pig Latin transformer is, it's for the best long term to just not bother with it and make the codebase a little simpler. Keep it if you want, but slap a big UNMAINTAINED warning on it and be done with it. (If there's REALLY an argument that this is useful, I'd want to see metrics on how often this is actually called by editors with 1,000+ articles on their watchlist, bearing in mind that the raw number of such editors isn't huge to begin with.) SnowFire (talk) 18:30, 2 May 2023 (UTC)Reply[reply]
    I think you probably overestimate the amount of maintenance the code requires. Even the link showing up in Vector 2022 has nothing to do with the feature itself, it's just that one of the random changes to Vector 2022 happened to break the CSS and JS someone had added to MediaWiki to hide these links on the fancy watchlist UI, just like how Vector 2022 broke gadgets and user scripts too. Anomie 12:03, 3 May 2023 (UTC)Reply[reply]
  • Leave is alone this is a useful function and sometimes necessary for people with certain broken watchlists (often if they are ridiculously large). There is already a confirmation prompt - no objections if someone wants to improve the localization of the message there (via MediaWiki:watchlistedit-clear-explain). — xaosflux Talk 13:33, 5 May 2023 (UTC)Reply[reply]
  • Support hiding away. There might be rare cases where it is useful, but I agree with above comments that the button is liable to be misunderstood, and I don't think any wording change would fix that. CMD (talk) 15:57, 17 May 2023 (UTC)Reply[reply]
  • Support: Anything that's basically irreversible probably should be hidden deep in user preferences with two confirmations, not right out in the open. Adam Cuerden (talk)Has about 8.4% of all FPs. 05:46, 24 May 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC on establishing a biography infobox guideline[edit]

Should MOS:INFOBOX be modified to advise that infoboxes are "recommended" for biographical articles where the infobox would contain textual information not provided by an article's first paragraph? Nythar (💬-🍀) 19:24, 2 May 2023 (UTC)Reply[reply]

Current guideline[edit]

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

Proposed guidelines[edit]

Option 1: Information past the first paragraph

The use of infoboxes is neither required nor prohibited for any article.
For biography articles, infoboxes are recommended if there is textual information—aside from external links—that could be put in an infobox beyond what is found in the article's first paragraph. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to augment it.
In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

Option 2: Non-stubs

The use of infoboxes is neither required nor prohibited for any article.
For biography articles, infoboxes are recommended if the article is longer than stub length. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to augment it.
In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

Option 3:All biographies

The use of infoboxes is neither required nor prohibited for any article, although for biography articles, infoboxes are recommended. The purpose of the infobox in is not to replace the lede or to re-summarize it, but to augment it.
Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.

Option 4: Oppose all changes/Other

Background (establishing a biography infobox guideline)[edit]

There is no current MOS guidance on the appropriateness of infoboxes. A 2013 ArbCom decision made clear that infobox inclusion should not be considered a maintenance task, but, rather, based on a determination of the use of a particular infobox on a particular page—in other words, it endorsed an article-by-article analysis. Unfortunately, in the past few years, there have been an unusual number of RFCs concerning infoboxes in biography articles, a subject which continues to be contentious.

Prior RFCs on biographies and results
Page Consensus? Date
Gustav Holst No consensus September 2016
Harry Lauder Exclude September 2017
Cary Grant No consensus January 2018
Include January 2021
Nicholas Hoult No consensus April 2018
Include June 2018
Penny Rowson Include October 2019
Jean Sibelius Exclude[1] August 2020
Mary Shelley Include October 2020
Dafne Keen Not closed October 2020
Nikki Amuka-Bird Exclude[2] March 2021
Stanley Kubrick Include November 2021
Cole Porter Not closed October 2022
Laurence Olivier Include November 2022
Maddie Ziegler No consensus December 2022
Pyotr Ilyich Tchaikovsky Include January 2023
Claude Debussy No consensus January 2023
James Joyce Include January 2023
Jenny Lind Include February 2023
Wolfgang Amadeus Mozart Include March 2023
Rod Steiger Include March 2023
[1] Infobox later added to the article after discussion.

[2] Infobox later added to the article without discussion.

  • There were two discussions on whether to collapse infoboxes, both resulting in a consensus in favor of uncollapsed infoboxes: Frank Sinatra and Peter Sellers

Moreover, editors examining or participating in these debates have noticed a few patterns:

  1. First, the debates are all contentious, feature many repeat players, and, despite the ArbCom's apparent endorsement of tailored considerations, are often dominated by general arguments—that is, arguments concerning whether infoboxes are, on the whole, good or bad.
  2. Second, there's not an obvious logic to the outcomes of these debates. Compare the Pyotr Ilyich Tchaikovsky infobox, which was, by consensus, included, and the nearly identical Claude Debussy infobox, on which there was no consensus. Or, compare the quite short Jenny Lind infobox, accepted by consensus to the considerably longer proposed Mackenzie Ziegler infobox, no consensus. Of course, complete consistency would be unrealistic, but the lack of guidance no doubt contributes to inconsistency.
  3. Third, there's a trend towards infobox inclusion. Eight of the last 10 RFCs that reached a consensus reached a consensus in favor of inclusion. And, as to the two RFCs that reached a consensus in favor of exclusion? Both pages now have an (apparently stable) infobox.

In light of these considerations, I propose the above non-mandatory language. The goal of this guidance is to reflect a preference for infoboxes where an infobox would contain textual information (not including links) beyond what is contained in the first paragraph of an article. Infoboxes serve to highlight information for quick reference; to the extent that they can contain information beyond what is already detailed by an article's opening paragraph, they allow users to find that information without having to scan. The guidance, which does "recommend" infoboxes in such situations, reflects the recent trend towards infobox acceptance in RFCs that have reached a consensus. Finally, a non-mandatory recommendation may serve to set a baseline for future discussions on infobox appropriateness. Nythar (💬-🍀) 18:49, 2 May 2023 (UTC)Reply[reply]

Survey (establishing a biography infobox guideline)[edit]

Please indicate whether you would support or oppose changing the guideline, and, if support, please indicate which option or options you would support.

Support (establishing a biography infobox guideline)[edit]

  • Support as one of the drafters and as the proposer. I believe this is long overdue and will help us achieve more consistency across biographical articles with generally acceptable criteria. Nythar (💬-🍀) 18:52, 2 May 2023 (UTC)Reply[reply]
  • Support my stance is that it’s a bit too vague (if someone wanted to stonewall a box they could just add suggested content to the lead or say it’s already there in a different format, etc.) and an article-length-based requirement would be better; but as a bare minimum it is preferable to the non-guideline we currently have. Dronebogus (talk) 19:02, 2 May 2023‎ ‎(UTC)Reply[reply]
    Update: support option 2. That was my preferred proposal from the start. Dronebogus (talk) 14:51, 4 May 2023 (UTC)Reply[reply]
  • Support as one of the drafters. Reviewing the RfCs on this topic the past six months the consensus appears to generally support the use of infoboxes on biographies. Updating the guideline for this community position should help reduce the number of RfC's and make this a less contentious topic in the future. In the past, there have been calls to create a policy to help reduce the conflict on this topic. Given the support for infoboxes, this attempt at creating a policy isn't perfect, but it's a step in the right direction. I prefer option 3 but I support the options presented. Nemov (talk) 19:13, 2 May 2023 (UTC)Reply[reply]
  • Narrow support, support all options, but, in order: Options 2, 1, 3 I helped Nythar craft this proposal at WP:VPI—I drafted the background information section, and I made the recommendation that external links and media be excluded. (I figured that this would have no shot at consensus support if it gave the impression that, say, a picture or link to a YouTube channel automatically warranted an infobox.) At the time, I raised concerns that no proposal would be perfect. I said that these RFCs have been dominated by individuals who always vote in favor or always vote against an infobox's inclusion, and that the editors who always vote against would certainly object to this change. Responding to a proposal that prioritized the number of parameters a template had, I mentioned that I'd seen debates in which users have stretched to add parameters to a template in order to make the infobox seem more useful, and that's a risk here—it's a gaming risk. But the tense that I just used is notable. I've seen that issue—meaning it's an issue under the current guidance. And, frankly, a discussion over whether information properly belongs in an infobox would, at least, be more article-specific than many of the comments I've seen in the various RFCs.
    Here's what's, for me, key: Almost worse than how brutal these RFCs are is how repetitive they are. The same general arguments are employed time and time again. Frankly, it doesn't make sense to have these discussions completely afresh on every individual page on which this issue comes up. This proposed guidance probably won't solve that problem. But at least it gives a suggested baseline. I think the non-stub option would encourage contributing to articles where users think an infobox is important, and I think article length is generally a decent proxy for infobox usefulness. I think the information/parameter focused option addresses a pretty common line for opposing an infobox ("it's in the first paragraph!"), and the more a user has to scan an article, the more an infobox makes sense. I also think infoboxes can generally be recommended for biographies--Jerome Frank Disciple (talk) 19:34, 2 May 2023 (UTC)Reply[reply]
  • I generally support this, as the one who spitballed the first draft. Sure, it's gameable, but so are all policies and guidelines; if someone does that, that's a user conduct issue, and we already have WP:CTOP in place if that occurs. Infobox RfCs have been a vexing issue because they're a rare case where there's long, draining RfCs, but without much personal attacks, POV-pushing, or other conduct that would merit admin action. Having actual guidance in place that establishes even a partial presumption one way or the other would be a step toward having to reinvent the wheel with each successive RfC. Like I said at VPI, basically everyone agrees with the idea that most non-stub biographies should have infoboxes, but some should not. This would formalize that. Individual talkpages would still be able to find local consensus to override the default recommendation, if some good reason exists. -- Tamzin[cetacean needed] (she|they|xe) 19:59, 2 May 2023 (UTC)Reply[reply]
  • Support I think this will generally reduce the amount of RfCs debating the same topic. There's no way to word this that isn't going to be gamed by people, but as a broad recommendation I think it works. Galobtter (talk) 21:19, 2 May 2023 (UTC)Reply[reply]
  • Support. I think this would reflect the current status quo, which is that, in general, more editors than not support infoboxes on biographical articles. That can vary depending on the article and the subject; I think in most disciplines/genres/whatever this isn't controversial at all. Note: I've preferred infoboxes for a long time; my views haven't changed since at least 2017 and probably longer ago than that. — Preceding unsigned comment added by Mackensen (talkcontribs) 21:43, 2 May 2023 (UTC)Reply[reply]
  • Support. I have long felt that there should be a presumption in favour of an infobox for non-stub articles about most concrete subjects (including biographies) because, in the majority of cases, they are (by consensus) significantly beneficial to and expected by readers. This proposal may not be perfect, but let's not let perfect get in the way of substantially better than the status quo. Thryduulf (talk) 22:42, 2 May 2023 (UTC)Reply[reply]
    • Update: I support Option 2 as my first preference, and Options 1 and 3 as about equal second preference. While I don't actively oppose option 4, it is a distant preference behind the above. Thryduulf (talk) 21:11, 4 May 2023 (UTC)Reply[reply]
  • Support as a healthy dose of common sense and a final end to these weird little cliques that oppose their usage in articles where a normal reader would expect to find them. Zaathras (talk) 23:41, 2 May 2023 (UTC)Reply[reply]
  • Support – I think including infoboxes in most/all cases for biographies is in line with the principle of least astonishment; since it is common for biographies to have infoboxes, not having them can be confusing. In other words, infoboxes make it clear visually that the article is a biography as opposed to some other type of article. RunningTiger123 (talk) 01:46, 3 May 2023 (UTC)Reply[reply]
    • Following the updates, option 3 is my preferred option and is most in line with my reasoning. Options 1 and 2 are okay as alternatives. RunningTiger123 (talk) 22:22, 4 May 2023 (UTC)Reply[reply]
  • Support – I would rather support a guideline that said "All biographies should have an infobox unless there is a clear consensus to the contrary", but this is a step in the right direction. Infoboxes, when used properly, provide a helpful overview of the article subject, are much more considerate to those who struggle to read a wall of text, and provide valuable assistance to search engines and tools that gather and compile structured data. – bradv 02:04, 3 May 2023 (UTC)Reply[reply]
    I find the structured data argument for infoboxes to be one of the weaker ones. We have Wikidata for that; on Wikipedia, we should write for humans rather than machines. {{u|Sdkb}}talk 02:17, 3 May 2023 (UTC)Reply[reply]
  • Support - I would, like Bradv, prefer a slightly stronger guideline, but I think this is vastly better than what we have, and I think this will hopefully bypass some of the highly repetitive comments that I've seen even in my brief time engaging with this discussion. It need not be perfect now, it just needs to be better, which it is. -Nerd1a4i (they/them) (talk) 04:05, 3 May 2023 (UTC)Reply[reply]
  • Support - I am sure that people will find a way to keep repeating the same arguments over and over anyway, but maybe this will decrease the frequency. -- Random person no 362478479 (talk) 04:17, 3 May 2023 (UTC)Reply[reply]
  • Support (Bradv's proposal 1st choice; original proposal 2nd) — Infoboxes are useful and readers expect them in biographical articles. Confusing readers because a small contingent of anti-infobox editors fight to keep them off specific pages does not benefit the encyclopedia. —pythoncoder (talk | contribs) 05:20, 3 May 2023 (UTC)Reply[reply]
  • Support. (1) Infobox RFCs are a common and repetitive occurrence on biographical articles; these RFCs tend to feature recurring participants, and recurring arguments – in some cases repeated verbatim from other articles' RFCs. Adding stronger guidance about infobox use cases should help to free up editor time that has previously been given over to these discussions. (2) The direction of the recommendation (in favor of infoboxes) accurately depicts the most common consensus that emerges; however, by being simply a recommendation, the proposal also creates an explicit allowance for infoboxes to be omitted on articles where a consensus forms against infoboxes. ModernDayTrilobite (talkcontribs) 15:14, 3 May 2023 (UTC)Reply[reply]
    Update for further clarity: I support all of the phrasing variations that have been proposed so far (at the time of my writing this, there are three). ModernDayTrilobite (talkcontribs) 15:02, 4 May 2023 (UTC)Reply[reply]
    So should we just combine them into one? Dronebogus (talk) 15:05, 4 May 2023 (UTC)Reply[reply]
    I don't think there'd be a way to combine all three without a lot of redundancy; I just intended to express that I'd support any of the three proposals individually. If I had to rank them, my order of preference would be 3 > 1 > 2, but in my opinion each of the three is an improvement over the status quo. ModernDayTrilobite (talkcontribs) 17:02, 5 May 2023 (UTC)Reply[reply]
  • Support - Tim O'Doherty (talk) 15:17, 3 May 2023 (UTC)Reply[reply]
  • I generally expect to see infoboxes on biographical articles and think they provide a convenient summary of important facts, so I support this proposal. Hatman31 (talk) 23:37, 3 May 2023 (UTC)Reply[reply]
  • Support as per nom Immanuelle ❤️💚💙 (talk to the cutest Wikipedian) 06:07, 4 May 2023 (UTC)Reply[reply]
  • Support alternative:
    The use of infoboxes is neither required nor prohibited for any article, although for biography articles, infoboxes are recommended.
    In other cases, there is no presumption for or against an infobox. Whether to include an infobox, which infobox to include, and which parts of the infobox to use, is determined through discussion and consensus among the editors at each individual article.
    For me, it's simply a matter of style, which is fitting as this is the manual of style we are talking about. I agree with WhatamIdoing's comment from the idea lab: Infoboxes are effectively part of our Trade dress. The content of the infobox should continue to be discussed on an article-by-article basis, although it seems obvious to me that at a minimum a biography should be expected to include dates and places of birth and death.
    I do not support the original proposed wording, which I think mixes style and content considerations, and is overly prescriptive and arbitrary about what should go in an infobox. Barnards.tar.gz (talk) 08:59, 4 May 2023 (UTC)Reply[reply]
    Oooh, I very much like this alternative. It's short and succinct, and reading it I have the feeling it describes my philosophy, although I have considered myself to be in the just-leave-it-to-individual-pages camp. I, too, dislike the original proposal, as it gets too finicky with conditions without clarifying them sufficiently. — JohnFromPinckney (talk / edits) 10:08, 4 May 2023 (UTC)Reply[reply]
    I support either the alternative or the initial proposal as both are better than the status quo. Thryduulf (talk) 10:59, 4 May 2023 (UTC)Reply[reply]
    @Nythar:: would you be willing to add this alternative as a second option? (If you'd like, I can work it into the above proposal and then ping the current voters to see if they have a preference or want to change their vote; I think this roughly matches Dronebogus's proposal.)--Jerome Frank Disciple (talk) 11:37, 4 May 2023 (UTC)Reply[reply]
    @Jerome Frank Disciple: Sure. I'm only concerned that it isn't specific enough to be useful at all and will simply result in more RfCs, but go ahead. Nythar (💬-🍀) 14:37, 4 May 2023 (UTC)Reply[reply]
  • Support I think the current guidelines are too vague, but I wouldn't want a strict guideline on how appropriate an infobox is. As long as the infobox is able to easily summarize facts that would be more difficult to pick out from the article itself, I support its inclusion. :3 F4U (they/it) 01:09, 6 May 2023 (UTC)Reply[reply]
  • Support recommending infoboxes, whatever that option was. Infoboxes are good things to have for and article, and is a common facet of Wikipedia. As I've said in the Mozart RfC, an infobox provides a different formatting of information that is wholly separate from prose. Infoboxes are useful in that they serve it in a structured format, and the commonplace and the recent RfCs ending in inclusion make it evident that infoboxes are desired generally. When an infobox has a field that would be wrong, excluding it altogether is what should be done (see Mozart's infobox) instead of denying a common standard. SWinxy (talk) 01:57, 8 May 2023 (UTC)Reply[reply]
  • Support Option 3Kerdooskis (talk) 20:10, 12 May 2023 (UTC)Reply[reply]
  • Support option 3, the alternative suggested by Barnards.tar.gz in this section, or any other options that otherwise gently encourages (but does not require) infoboxes in most biographies. I support this idea partly because this seems to be the direction that the community is slowly taking. Ten years ago, 30% of all articles contained infoboxes. Today, almost 50% of them do. This trend is, as User:Jerome Frank Disciple put it recently, "the elephant in the room". We're headed that direction, and we might as well admit it. We may someday reach a point of saying that biographies should have infoboxes except if there are extenuating circumstances, or even that citations should use Wikipedia:Citation templates. We're not there yet, but we can and IMO should take gentle little baby steps towards acknowledging that the community's preferences are drifting inexorably towards this approach. In case it matters, I have added infoboxes to very few of the articles I've created. However, I recognize that my personal approach is increasingly in the minority. WhatamIdoing (talk) 00:45, 13 May 2023 (UTC)Reply[reply]
  • I would support all three options. I recognize that this is a contentious topicnand that major changes are unlikely to receive consensus. Although I would prefer a broader policy in favor of IB, I can still support threes kinds of incremental improvements. — BillHPike (talk, contribs) 07:28, 15 May 2023 (UTC)Reply[reply]
  • Support option 3. Glad I noticed this discussion. Appreciate the consistency that infoboxes across biography articles provide. Guidelines should favor including one. Hameltion (talk | contribs) 15:51, 19 May 2023 (UTC)Reply[reply]
  • Support due to all the stupid reasons given by the opposers. A guideline is required to enable sensibleness, and to stop argument. Graeme Bartlett (talk) 05:08, 25 May 2023 (UTC)Reply[reply]
    • Really? The guideline isn't sensible and won't stop arguments - it will likely increase them and introduce gaming to the process, but is there really any need to be so dismissive of everyone else's opinions? - SchroCat (talk) 14:52, 27 May 2023 (UTC)Reply[reply]

Oppose (establishing a biography infobox guideline)[edit]

  • Oppose. I agree with User:Anarchyte above. I have often said that I agree with infoboxes in bios for politicians and sports figures, as the key information about these backgrounds makes sense in the box form. But the wording of the proposed guideline is nonsense: "...if there is textual information ...that could be put in an infobox beyond what is found in the article's first paragraph". All the key information about a subject, particularly a biography of an actor, writer or other creative person, should be included in concise form in the WP:LEAD, not in a box that often presents such trivia as "creator awards" (these are just plaques that YouTube gives you when you pass subscriber thresholds and adds absolutely no information of importance) and "associated acts" who have been deemed not important enough to mention in the Lead. Indeed, in many biographies of actors, performers and other creative people, I have seen users insist that the "YouTube" section be included, even where it is of scant importance to the subjects' careers. The box is mechanical and lacks context and nuance, requiring trivial information to be included. For example, why is a person's place of death important, in most cases? Plus, a lot of information in these IBs, like "years active" is often unclear and lacks adequate referencing to give a definite year. In these infobox debates, most of the people "voting" and commenting are people who have never edited the article, have no interest in the subject, and who will never contribute anything else to the article. As Anarchyte suggested, the editors who have created, expanded, and maintained the article, or at least who have a good-faith interest in contributing to the article, should be the ones who decide whether an infobox should be included or not -- not folks who are attracted merely because there is an infobox debate or RfC. See Signpost report: "Infoboxes may be particularly unsuited to liberal arts fields when they repeat information already available in the lead section of the article, are misleading or oversimplify the topic for the reader". -- Ssilvers (talk) 19:37, 2 May 2023 (UTC)Reply[reply]
    So you’re saying that (as is the current unwritten status quo) that you need X number of edits to get WP:OWNership privileges on an article? As if that’s really been working out great so far and isn’t a complete violation of the collaborative spirit of Wikipedia? Dronebogus (talk) 19:42, 2 May 2023 (UTC)Reply[reply]
    Not at all. You need a good faith interest in the article. It's a complete violation of the spirit of Wikipedia (and all the ArbCom decisions on the topic) to start an RfC knowing that the must-have-an-infobox crowd hangs around RfC for the purpose of forcing inforboxes into articles that are better without them. -- Ssilvers (talk) 19:46, 2 May 2023 (UTC)Reply[reply]
    (edit conflict) Dronebogus, Can you drop the uncivil language please? It's not ownership: it's WP:stewardship in developing an article. Insulting other editors for having an opposing viewpoint isn't going to help anyone. - SchroCat (talk) 19:48, 2 May 2023 (UTC)Reply[reply]
    Ssilvers, are getting into conspiracy theorist territory and casting aspersions. That is the complete opposite of good faith and the spirit of Wikipedia. Dronebogus (talk) 19:54, 2 May 2023 (UTC)Reply[reply]
    I'm not sure I agree there. To be clear: I've participated in one RFC concerning infoboxes. My vote was initially a slight oppose, which I changed to "neutral". But I don't think editors who are inclined to see infoboxes as beneficial are at all violating the spirit of Wikipedia or the ArbCom decision if, when a request for comment is made, they chip in their opinion that an infobox is useful on that particular page. And, due respect @Ssilvers, particularly because I know that you're a valuable and talented content creator/editor, but seeing as you've (by my count) participated in 6 of the last 10 RFCs—some on pages you were heavily involved with, some very much not so—using, as we've discussed, very similar statements on each ... surely your opinion isn't that "editors who always vote against infoboxes in RFCs can drive by in the spirit of Wikipedia, while editors who always vote for infoboxes can't".--Jerome Frank Disciple (talk) 19:56, 2 May 2023 (UTC)Reply[reply]
    Would you all *please* indent your comments in a way that makes it clear where each new comment begins? As for your Comment, Jerome Frank Disciple, what? I never said anything like that. What I mean to suggest is that, in my version of WP utopia, an editor should have an interest in a subject in order to give a useful opinion about whether or not it should have an IB. But I recognize that is not how WP works. -- Ssilvers (talk) 20:03, 2 May 2023 (UTC)Reply[reply]
  • Oppose. A poor solution looking for a problem that doesn't exist. We have a good current guideline and a good RfC system to discuss the cases where there is a question. Sometimes the consensus is to include; sometimes it is to omit. This WP:CREEP is unnecessary.
    Using an arbitrary metric to determine whether an IB should exist is the wrong way to consider whether an IB should be used, and this raises more questions than it answers. The question of the "first paragraph" fails to address the importance of the information in the box – and that should be the one of the key drivers. For example, we don't tend to have the town of birth or death anywhere in the lead because they are not really that important (as in, they don't tend to be the reason for the individual's notability or affect anyone's understanding of the individual, so there is an element of trivia about them), but those fairly useless bits of information will now be used to force in an IB despite their lightweight usefulness. In other words, this proposal treats all factoids as equal, regardless of whether they aid the reader (the number of children someone has, their height, political affiliation etc – they may be known, but should that be the sole factor in deciding whether an article has to have an IB). There's a long list of fields that are more or less important in providing relevant information about an individual, but some of them should not be used to determine the presence of an IB.
    The guideline is open to gaming (from both angles). A long(ish) first paragraph could be argued to negate the need for a box, while someone could split a paragraph into two very short ones to justify an inclusion. Why are we introducing something so open to gaming? – SchroCat (talk) 19:49, 2 May 2023 (UTC)Reply[reply]
Clarify: Oppose both proposals. The first as above, the second as it doesn't clarify anything or provide a concrete alternative to the existing wording. - SchroCat (talk) 15:04, 4 May 2023 (UTC)Reply[reply]
  • I actually do agree with the last bit about gaming, but anything less vague would immediately be torpedoed as partisan. Dronebogus (talk) 19:57, 2 May 2023 (UTC)Reply[reply]
    Well it is partisan already... As it stands, this could be used to force an IB in pretty much every article over a stub, which is not necessarily the best thing for every article. Don't forget, we're not talking every biography here - we're looking at some biographies in limited areas - those that don't have rank or positions to tabulate, or those that have sporting records and histories that fit neatly into a box. I don't think I've ever seen an article on a member of the military, or a politician, or a sports person, where there has been any question - and quite right too: they are the biographies where an IB works brilliantly. The problem comes with some in the liberal arts or an occasional historical person where the benefits of a box are not clear cut. Forcing boxes into articles (which is what this proposal will do) does harm to a small number of articles. - SchroCat (talk) 20:06, 2 May 2023 (UTC)Reply[reply]
    I don’t see that as “harm”. Just less essential. Dronebogus (talk) 16:09, 3 May 2023 (UTC)Reply[reply]
    As for the RFC system being good… what alternate universe are you living in? Dronebogus (talk) 20:02, 2 May 2023 (UTC)Reply[reply]
    One where things come up for discussion and come to a consensus. That is what has happened in the RFCs listed above - and the ones that have been missed out from the list too. - SchroCat (talk) 20:06, 2 May 2023 (UTC)Reply[reply]
    A very long, contentious discussion that frequently gets re-discussed. Dronebogus (talk) 21:29, 2 May 2023 (UTC)Reply[reply]
    Not always long, nor contentious. Yes, some people can’t let a matter drop and will keep re-litigating until they get an answer they want, but the system works. This bit of instruction creep won’t stop that - it’ll still be argued about, with the extra bonus that there will be accusations of people gaming the rules. - SchroCat (talk) 22:08, 2 May 2023 (UTC)Reply[reply]
    The change is, in my view, a step towards standardization. It’s not good, but it provides some structure and any radical changes won’t receive support at this point. Dronebogus (talk) 23:22, 2 May 2023 (UTC)Reply[reply]
  • Weak Oppose. This isn’t something we can write one-size-fits-all “rules” about. I have no problem with the idea that most bio articles should have an infobox included, but there will always be exceptions to that generalization. Whether a specific article should omit an infobox can and should be determined by local consensus - asking the simple question: Does it make sense to include/omit it in this case? I have no problem if the results of asking this question are inconsistent… in fact, I would expect inconsistency - because each situation is unique. Blueboar (talk) 19:53, 2 May 2023 (UTC)Reply[reply]
Addendum in response to the original RFC question being changed/updated - I’m still on Weak Oppose - I find the proposed guidance to be overly restrictive instruction creep. Under the current language, most bio articles will continue to have an infobox, but I see no reason why consensus at the local level should not determine that a specific article should omit. Reaching consensus is often messy and time consuming … but that is a feature, not a bug. Blueboar (talk) 15:24, 4 May 2023 (UTC)Reply[reply]
  • But is that inconsistency good? Because personal experience witb these RFCs tells me it isn’t. It’s confusing and the “no box” enclaves usually collapse anyway. I urge you to reconsider. Dronebogus (talk) 19:59, 2 May 2023 (UTC)Reply[reply]
    It is neither good nor bad… it is, however necessary because one size does NOT fit all. Blueboar (talk) 20:49, 2 May 2023 (UTC)Reply[reply]
    “One size fits most” is a thing. We can make exceptions in exceptional cases, it’s just that most cases I’ve seen are not. They’re arbitrary at best and weird enclaves policing weird local rules nobody else understands at worst. Dronebogus (talk) 23:27, 2 May 2023 (UTC)Reply[reply]
    @Blueboar: It is a recommendation. Infoboxes are not required for every article that passes the criteria, but they generally should be there. There may be exceptional circumstances that allow for the exclusion of infoboxes even if they do pass the criteria. Nythar (💬-🍀) 20:05, 2 May 2023 (UTC)Reply[reply]
  • Oppose Thanks for the effort but:
    • I see no need for this
    • It has a flaw - why should something that is in the first paragraph be excluded from the info box?
    • IMHO not an improvement. Sort of longer and confusing
    • IMO works in the wrong direction. Puts a finger on the scale towards inclusion of infoboxes. Why? IMO when in doubt leave it out.
Sincerely, North8000 (talk) 20:18, 2 May 2023 (UTC)Reply[reply]
Fair comment! Just to clarify, in response to your two questions: (1) the proposal isn't suggesting that items in the first paragraph should be left out of the infobox; rather, it's declining to recommend that an infobox be put in if it merely reflects first-paragraph information (e.g., name, birth, death, etc.). (2) The reason it does (I'd argue very slightly) put a finger towards inclusion is because, as stated in the background section, 8 of the last 10 RFCs that reached a consensus did so in favor of infobox inclusion, and all 10 pages now have an infobox on them. A "when in doubt leave it out" policy, I think, wouldn't reflect that there seems to be a growing trend of infobox desire/acceptance (though that's not to say that those who always oppose infoboxes in RFCs have significantly softened or warmed to them).--Jerome Frank Disciple (talk) 20:24, 2 May 2023 (UTC)Reply[reply]
Thanks. Regarding the "first paragraph" I agree that it structurally says as you describe. But IMO it implies that an infobox isn't for the the material in the first paragraph. Sincerely, North8000 (talk) 20:47, 2 May 2023 (UTC)Reply[reply]
7 of the last 10 6 out of ten. Mackenzie Ziegler’s discussion ran alongside the formal RfC of her sister. The same people !voted in both and both received a formal close from the same person. It was an RfC in all but name. - SchroCat (talk) 20:35, 2 May 2023 (UTC)Reply[reply]
No, sorry, 8 of the last 10. I think you missed my qualifier there—RFCs that reached a consensus. (I'm not sure how Mackenzie's spot in the table got taken out? I supposed because it wasn't an official RFC. Either way, neither Ziegler page reached a consensus.) --Jerome Frank Disciple (talk) 20:38, 2 May 2023 (UTC)Reply[reply]
7 of 10Six out of ten (Francis Bacon has been pointed out); the Mackenzie Ziegler was near as dammit an RfC, but if you want to stack the numbers one way, I guess that’s the one way to do it. The fact there was no consensus to add doesn’t mean no consensus. - SchroCat (talk) 20:48, 2 May 2023 (UTC)Reply[reply]
Schro, I'm baffled here. The closer at the Mackenzie Ziegler page said, exactly, "Closing this as no consensus, with a similar conclusion to the one seen at Maddie Ziegler's RfC." (that's what they bolded). And the closer at the Maddie Ziegler page said, "[T]here is no clear consensus on whether this article should have an infobox." (again, what they bolded).--Jerome Frank Disciple (talk) 20:52, 2 May 2023 (UTC)Reply[reply]
When you’ve been here more than a couple of months, you’ll grasp the language of a closer a little better. - SchroCat (talk) 21:03, 2 May 2023 (UTC)Reply[reply]
personal discussion
The following discussion has been closed. Please do not modify it.
Was an IP editor for a long time, thanks :) The closer is, plainly, directly contradicting what you're saying. But seeing as there's so rarely been a consensus in favor of exclusion, and seeing that you've opposed infoboxes in so many of the recent RFCs, I can understand if you're a bit desperate to claim wins where you can.--Jerome Frank Disciple (talk) 21:07, 2 May 2023 (UTC)Reply[reply]
I’m not desperate at all, by the way, so it appears your mind reading is as flawed as this proposal. Either way, this charming aside on my history of IB discussions is all rather utterly meaningless, so I’m going to leave you to it. - SchroCat (talk) 21:14, 2 May 2023 (UTC)Reply[reply]
Great dodge! Best of luck in your future RFCs.--Jerome Frank Disciple (talk) 21:17, 2 May 2023 (UTC)Reply[reply]
@North8000: The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. And to answer your second point, this proposal doesn't exclude from the infobox the information found in the first paragraph. It simply excludes an infobox if the only information that could be added to the infobox is found in the first paragraph. That is because readers shouldn't need to spend lots of time having to look through more paragraphs, or even the entire article, just to find some basic information on the subject, like location of birth or spouse. If the info can already be found in the first paragraph, an infobox isn't really important because there isn't much reading that needs to be done to locate the basic information that would otherwise be included in an infobox. Nythar (💬-🍀) 20:26, 2 May 2023 (UTC)Reply[reply]
When there is basic straightforward factual infobox type material available on the topic, I think the infobox is a great idea. When not, not. Regarding the "first paragraph" I agree that it structurally says as you describe. But IMO it implies that an infobox isn't for the the material in the first paragraph. Sincerely, North8000 (talk) 20:51, 2 May 2023 (UTC)Reply[reply]
  • Oppose as unnecessary WP:CREEP. For biographical articles where there is something good to put in the infobox then they are great, but for the minority of articles where most of the parameters are subjective or controversial then they are not. The current system would work now if RFCs didn't attract the "have an infobox whether it contains anything useful to the reader or not" crowd. Phil Bridger (talk) 20:40, 2 May 2023 (UTC)Reply[reply]
  • Oppose. This will make things so much worse. Even leaving aside the amount of gaming something like this would prompt on both "sides", it's completely illogical. It proposes to look at details that weren't considered important enough to include in the opening paragraph and use those to justify including an infobox - which is meant to summarize key facts? You could go to almost any article that already has an infobox and identify something that could be added to it, but could does not mean should. All this proposal does is encourage the former over the latter, and prompt arguments over that, rather than reducing conflicts. And all of the arguments put forward in support thus far add up to "We should do something. This is something. Therefore we should do this", rather than engaging with the details of the proposal. Nikkimaria (talk) 00:23, 3 May 2023 (UTC)Reply[reply]
    I thought the proposal was badly worded from the start. I just wanted it to be “infoboxes are recommended for biographies [because WP:SURPRISE and standardization]” and that’s it. I initially thought a weak guideline that “helps” nobody in particular was necessary but now I just wish I’d pushed for the simple version. Dronebogus (talk) 02:24, 3 May 2023 (UTC)Reply[reply]
    @Dronebogus: It's not too late; you can post it as an alternate proposal. Go ahead if you want to. Nythar (💬-🍀) 02:28, 3 May 2023 (UTC)Reply[reply]
    I don’t want to confuse people with two distinct, but extremely similar, proposals running concurrently. Dronebogus (talk) 02:32, 3 May 2023 (UTC)Reply[reply]
  • Oppose per my comments in the previous discussion. Most of the time, infoboxes are indisputable. The remainder of the times, the decision should be left to those with a vested interest in the article (not the same as ownership). Dubiously enforceable policies prone to gaming isn't the best way to go about this, as discussed by Nikkimaria. Anarchyte (talk) 02:07, 3 May 2023 (UTC). Update: I also oppose the new alternatives for the same reason: attempting to encourage editors to blindly consider infoboxes as being required, with little regard for local consensuses. Anarchyte (talk) 03:44, 5 May 2023 (UTC)Reply[reply]
    No functional distinction exists between having a vested interest in the article that somehow allows a small group of editors to control the content that gets added to an article and WP:OWNERSHIP. Wikipedia:Ownership of content#Multiple-editor ownership states The involvement of multiple editors, each defending the ownership of the other, can be highly complex. The simplest scenario usually consists of a dominant editor who is defended by other editors, reinforcing the former's ownership. This can be frustrating to both new and seasoned editors. And it's true; this is quite frustrating, as I'm not able to get the point across that the things that you are describing are by definition "ownership". Sure, the editors of an article might possess better understanding of its contents than most others, and they're more than welcome to present their points at RfCs. But nowhere on Wikipedia are editors allowed to control content against the community's desires. Nythar (💬-🍀) 02:23, 3 May 2023 (UTC)Reply[reply]
    Exactly. The whole reason infoboxes are contentious are because a very small group of editors have organized themselves against them on certain articles dogmatically, and get mad and blame “the pro-infobox condpiracy” when people point that out. This is just deletionism vs. inclusionism all over again— the inclusionists actively set up support networks to systematically stonewall deletion and blamed a similar, nonexistent conspiracy when people pointed out their gaming. Now that the network has been broken down in various ways, deletion is far less ugly. Dronebogus (talk) 02:30, 3 May 2023 (UTC)Reply[reply]
    It's the same way that the primary contributors get to decide the date format used in the article. I'm not saying the authors have the dictatorial say in whether an infobox is included, but whatever the decision is during the construction should be the status quo requiring local consensus to change. Per WP:STEWARDSHIP, in many cases, a core group of editors will have worked to build the article up to its present state and will revert edits that they find detrimental in order, they believe, to preserve the quality of the encyclopedia. Such reversion does not indicate an "ownership" problem[...]. Anarchyte (talk) 05:20, 3 May 2023 (UTC)Reply[reply]
    There is an actual distinction between stewardship and ownership. The behavior that you described above is ownership. Reverting edits that they find detrimental should not give them total control of articles and immunity from RfCs. We usually refer to such behavior as ownership. Nythar (💬-🍀) 12:12, 3 May 2023 (UTC)Reply[reply]
    I didn't mention immunity? I'm aware of how ownership and stewardship differ. As I said earlier, I'm not saying the authors have the dictatorial say in whether an infobox is included, but whatever the decision is during the construction should be the status quo requiring local consensus to change.WP:CCC. Anarchyte (talk) 13:00, 3 May 2023 (UTC)Reply[reply]
    So… illberal democratic say? Dronebogus (talk) 14:20, 3 May 2023 (UTC)Reply[reply]
    Not even close. Anarchyte (talk) 03:17, 4 May 2023 (UTC)Reply[reply]
    It’s rhetorical Dronebogus (talk) 15:56, 4 May 2023 (UTC)Reply[reply]
  • Oppose. This comes across as WP:CREEP, and I fail to see a good argument for why biographies should be a special case different from other categories of articles that also generally have infoboxes. As a practical matter, if most biographies have infoboxes, that trend will continue, but with this addition, I could see the recommended language being wielded to try to push infoboxes on some of the few biographies where they aren't so useful. I also have some qualms about the criterion of information that isn't in the lede. Often, such information may be trivia that gets stuffed in the infobox because a parameter exists for it but that doesn't rise to the level of due weight for rightful inclusion in the lead. In those cases, that's actually an argument against having an infobox in that particular article. {{u|Sdkb}}talk 02:37, 3 May 2023 (UTC)Reply[reply]
  • Oppose, I don't see a strong need. Personally, I usually don't notice whether articles have infoboxes (they go into my banner blindness spot, just like navigation sidebars). For many biographies (especially pre-1800) a huge amount of information is uncertain or non-standard, which is difficult to reflect in an infobox, and there should be nothing that forces editors to display such information in boxes. Where potential infobox information is located seems unrelated to whether we should have one (this seems to be an argument that could easily be used to force information into the infobox that isn't very important for the specific person). —Kusma (talk) 12:23, 3 May 2023 (UTC)Reply[reply]
    Continue to oppose, the new options are worse. Whether an infobox is helpful or not depends on completely different properties of the article than stub-ness. —Kusma (talk) 15:37, 4 May 2023 (UTC)Reply[reply]
  • Oppose as WP:CREEP, largely per Skdb and SchroCat. The current system is not perfect, no. But to create a set of rules to recommend the usage of userboxes specifically for biographic articles based on a few iffy parameters will likely worsen the debates. You cannot guarantee that even if these parameters were met, that an infobox would be ideal for that situation based on the content. And even then, just saying that it is "recommended" doesn't really give it any teeth; people who disagree with the practice will likely pay no heed to it. --WaltClipper -(talk) 12:44, 3 May 2023 (UTC)Reply[reply]
    Option 4, for all aforementioned reasons. Still not convinced that a change would be helpful. WaltClipper -(talk) 16:06, 4 May 2023 (UTC)Reply[reply]
  • Oppose This is something that needs to be worked out at the article level, not having a universal policy. If an article needs one, put it in. If it doesn't, don't. We don't need a rule to decide that. --Jayron32 12:45, 3 May 2023 (UTC)Reply[reply]
  • Oppose the main benefit of use a guideline would be "niceness" in terms of consistency—but Wikipedia often realizes that consistency is not the be-all, end-all (hence ENGVAR, etc.) and that more prescriptive guideline proliferations harms as often as helps. The RfC setup we've got has by all appearances worked fine. Der Wohltemperierte Fuchs talk 00:05, 4 May 2023 (UTC)Reply[reply]
  • Oppose all changes. We should not recommend infoboxes in any form. They are almost always worthless clutter, oversimplified and with significant omissions. See WP:DISINFOBOX. And having a lead that does not contain the same information is an especially bad reason for recommending them: either the information was appropriately omitted from the lead as non-leadworthy (in which case it should not be forced into the lead anyway by adding it to the infobox) or the lead text needs improvement. —David Eppstein (talk) 01:58, 4 May 2023 (UTC)Reply[reply]
    • And close this RFC as an out-of-process disaster and moving the goalposts now that it has been totally changed from the one so many people have already commented on. —David Eppstein (talk) 16:30, 4 May 2023 (UTC)Reply[reply]
      The change here is very minor and this RfC is far from a disaster. Nemov (talk) 16:32, 4 May 2023 (UTC)Reply[reply]
      Hello! In response to the requests for alternatives and asking the proposer, I updated the RFC, which was started two days ago, to include the various options suggested. I pinged every editor that had voted so far, which I imagine is what prompted you to reply here. I see you've been able to respond to that update in a perfect competent manner, and several other editors have done the same. Is there any reason you think others won't be able to?--Jerome Frank Disciple (talk) 16:33, 4 May 2023 (UTC)Reply[reply]
  • Oppose. 1. The initial justification for the guideline refers (twice) to the infobox would contain textual information but the proposed guideline says information ... that could be put in an infobox (note the change from "would" to "could"). The latter seems less justified – a criterion should not depend on lesser matters in the infobox. 2. Any guideline should also include criteria for when infobox removal is recommended on account of such things as changes made to the inbox template coding or the actual contents of the infobox and first paragraph. 3. My observation on the numerous debates is that people care about whether or not there is an infobox at all. It would be a shame if the arguments changed to being about the detailed contents of the first paragraph as a proxy for the real point of contention. Thincat (talk) 11:18, 4 May 2023 (UTC)Reply[reply]
  • Oppose per WP:CREEP. We don't need rules on everything, and prioritising consistency over editorial judgement is rarely the best option when dealing with complex topics. AndyTheGrump (talk) 12:17, 4 May 2023 (UTC)Reply[reply]
  • Oppose per many editors above. Arts biographies in particular are challenging for infoboxes. See Francis Bacon (artist) for an example. There have been many discussions not only about the infobox but how to put contentious things like his nationality into a format that is accessible in the ibox. It was decided that he be described as 'Irish-born British.' His oeuvre is also hard to shoe-horn in: "His output can be broadly described as sequences or variations on single motifs; including the 1930s Picasso-influenced bio-morphs... the 1950s 'screaming popes' ... and the cooler, more technical 1980s paintings.". Describing the subject as a 'Figurative painter' lacks nuance. Consider as well the shrinking of a picture of the article subject being shrunk to fit an ibox. Some of our free use pictures would become difficult to discern when shrunk to ibox params. Too much CREEP, to little nuance, bad idea. Jip Orlando (talk) 16:22, 4 May 2023 (UTC)Reply[reply]
    Okay, the pictures thing is a blatant non-issue. Cropping exists. Dronebogus (talk) 00:01, 5 May 2023 (UTC)Reply[reply]
  • Oppose per Kusma. I generally like infoboxes and am a bit bemused by the strong opinions some people have about them. However, articles, it is simply not possible to fill them out to a useful degree while still satisfying WP:V. The information is simply not available, or not undisputed. At that point, it just creates more busywork for the editor and nothing useful for the reader. Gnomingstuff (talk) 18:23, 5 May 2023 (UTC)Reply[reply]
  • Oppose per Nikkimaria and David Fuchs. Ajpolino (talk) 18:25, 5 May 2023 (UTC)Reply[reply]
  • Oppose Rules like this would just give make-work people things to argue about. Those interested in developing a particular topic should choose what is best for the articles concerned. Wikipedia relies on volunteers and follows the bazaar model where one-size-fits-all rules are inappropriate. Johnuniq (talk) 00:21, 6 May 2023 (UTC)Reply[reply]
  • Oppose This is an issue of local consensus. ~ HAL333 22:10, 6 May 2023 (UTC)Reply[reply]
    One more thought: with the removal of the centralized TOC in the new vector skin, infoboxes have become an aesthetic monstrosity, squeezing text and displacing images in the first section. If anything, we should be discussing removing or condensing many IBs, rather than this soft de-facto mandate. ~ HAL333 01:56, 10 May 2023 (UTC)Reply[reply]
  • Oppose - It would lead to a lot more arguing and edit-warring when inevitably User A tags a page for not having an infobox and User B disputes it. An infobox is not needed for many articles and for some, especially with crime and embarrassing incidents, it would come across as demeaning. It's also okay for various pages to look different.KatoKungLee (talk) 17:16, 7 May 2023 (UTC)Reply[reply]
    I don’t know how an infobox can be “demeaning”. It seems like people are just making up excuses to oppose at this point. If you think this is a “local consensus” thing or you think it’s an unhelpful proposal that would make things worse, just say that. Don’t grasp for weird secondary arguments. Dronebogus (talk) 19:07, 7 May 2023 (UTC)Reply[reply]
    @Dronebogus: I urge you to read WP:BADGER. Anarchyte (talk) 02:42, 8 May 2023 (UTC)Reply[reply]
  • Oppose As some others have written above, I don't find the proposed changes to be nuanced enough to incorporated as recommendations in the Manual of Style. Even for longer biographies, some considerations are best discussed in the context of a particular article, to the point that I prefer the status-quo guidance. DanCherek (talk) 19:54, 7 May 2023 (UTC)Reply[reply]
  • Oppose It's possible to discuss it for longer articles on their talk page but an infobox for a shorter article or not doesn't really matter and is going to lead to lots of useless arguing/discussions. Coldbolt (talk) 09:15, 9 May 2023 (UTC)Reply[reply]
  • Oppose - I personally quite like them, but they are contentious, and given that I don't think any guideline beyond what we have now ("deal with it case by case") is appropriate. Andrew Gray (talk) 18:46, 16 May 2023 (UTC)Reply[reply]
  • Oppose. Better not to create anything mandatory. Decide on a case-by-case basis. --Tryptofish (talk) 21:54, 18 May 2023 (UTC)Reply[reply]
    Just for the sake of clarification, there's nothing mandatory in this proposal. Nemov (talk) 22:06, 18 May 2023 (UTC)Reply[reply]
    Thanks, that was a bad word choice on my part. Maybe "formulaic" would have been a better word. --Tryptofish (talk) 16:34, 19 May 2023 (UTC)Reply[reply]
  • Oppose/other. Sort of like what Rhododendrites wrote below, I think a more appropriate resolution is to put more weight behind retaining existing styles, in the face of both styles being permitted and both styles having enduring community support. If we apply a stronger compromise in favor of retaining the established choice of an article, then repetitive individual RfCs proposing changes become less likely to succeed and are discouraged in that way. The guideline should clarify that, in disputes at individual articles, adding or removing infoboxes requires particularized reasons for that specific case, beyond merely arguments of a general nature or personal preferences, which are insufficient. Adumbrativus (talk) 07:30, 19 May 2023 (UTC)Reply[reply]
  • Oppose even though I personally like infoboxes, I hate the idea of making anything even resemble mandatory or needless CREEPy restrictions, and the proposal doesn't make much sense per the good logic of users like SchroCat, Skdb, Thincat, and Nikkimaria. Huggums537 (talk) 02:37, 21 May 2023 (UTC) Updated on 02:41, 21 May 2023 (UTC)Reply[reply]
  • Oppose. The less rigid the rules the better. It is fine for this to be determined by consensus only. If there is a change, only support option 3 Jack4576 (talk) 14:42, 22 May 2023 (UTC)Reply[reply]
  • Oppose Infoboxes can be useful but personally I believe Wikipedia is more negatively affected by too much infobox (ie. unimportant information, excessive length overall, filling parameters with misleading and unverifiable information because the parameters are there) than no infobox. (t · c) buidhe 04:43, 25 May 2023 (UTC)Reply[reply]
  • Strong Oppose per Ssilvers and others above. We all know that "recommended" = "absolutely compulsory". The great majority of bio infoboxes are not at all controversial, but when there is opposition, there is usually a very good reason for it. All these proposed changes will make sensible discussion impossible. Johnbod (talk) 02:30, 28 May 2023 (UTC)Reply[reply]

Discussion (establishing a biography infobox guideline)[edit]

Pings and rfc maintenance issues
  • @Nythar: See WP:RFCST: you have not provided a statement, nor a timestamp/signature. Because of these omissions, it's not shown properly at Wikipedia:Requests for comment/Wikipedia proposals. I could pull the {{rfc}} tag straightaway. --Redrose64 🌹 (talk) 19:15, 2 May 2023 (UTC)Reply[reply]
    @Redrose64: I've added a signature. Need anything else? Nythar (💬-🍀) 19:19, 2 May 2023 (UTC)Reply[reply]
    I added a statement on your behalf, Nythar (which I assume is okay since I helped craft the background section and stuck to your proposal). If you endorse it, just sign.--Jerome Frank Disciple (talk) 19:23, 2 May 2023 (UTC)Reply[reply]
    I've signed it. Thanks for all your help! Nythar (💬-🍀) 19:25, 2 May 2023 (UTC)Reply[reply]
    We'll see if it worked when Legobot next runs, just after 20:00 (UTC). --Redrose64 🌹 (talk) 19:36, 2 May 2023 (UTC)Reply[reply]
  • The idea of using an arbitrary metric such as "textual information—aside from external links—that could be put in an infobox beyond what is found in the article's first paragraph" is vague, too open to misinterpretation (either accidentally or deliberately) and so open to gaming by anyone, that it's a weak and poor proposal. It's been rushed through by a small group of editors (all acting in good faith, no doubt), but it's lead to a poor proposal. Even its supporters are admitting it's a poor proposal. Wouldn't workshopping alternatives be a better step than the adoption of something that is fundamentally flawed?

    One of the problems with biography IBs discussions (and it's a problem that isn't addressed in the proposal) is that there is no baseline agreement of what is considered "important" or "core" information that should be in any box. If such basic fields could be identified it would be a start of something far more useful. On the basis of that, a discussion could be had on how many of those basic fields need to be present to trigger a box. I'm thinking of actual "core" pointers - dates of birth and death are two obvious places to start, but it should be easy enough to come up with a list of 10 or 12 "core" fields, the presence of 5? 6? 7? 8? of which trigger a box unless there are extremely good reasons why there shouldn't be. It would be a damned sight better than the second rate proposal on offer at present. - SchroCat (talk) 09:54, 3 May 2023 (UTC)Reply[reply]

    Textual information—aside from external links is not arbitrary at all. We discussed this for a while until we landed on that. Usually the first paragraph is the most dense and has the most amount of description. If you can find all the information that could exist in an infobox in the first paragraph of an article, why have an infobox? But it is rather tiresome if you need to look through the entire lede (some ledes can be extremely long) or even the entire article just to find basic information about a subject. Like I said above, The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. The wording of the proposal is purposely left vague in order to allow for exceptional circumstances. Remember, nothing on Wikipedia is required, except maybe the civility and BLP policies. But anyway, this reply isn't intended for you; it's just to inform users who may be passing by. Nythar (💬-🍀) 12:25, 3 May 2023 (UTC)Reply[reply]
    A couple of things. Firstly, as you have done above, can you stop referring to stewardship as ownership? If you are trying to wind people up, then accusing them of ownership is a great way to go, but when people have spent a lot of time, effort (and normally) money in taking an article from something sub-standard to something the encyclopaedia can be proud of, then dismissing their efforts as "ownership" is a great way to get people's backs up. I'm sure that isn't your intention, but that's the effect it has. Maybe if you spent time trying to create some content, you might get an idea of what it's like to be accused of "owning" it when you remove something that is poor.
    Secondly, you and your fellow supporters don't have to respond to pretty much every comment that opposes the proposal. It's already crossed the line in WP:Bludgeoning and it hardly makes for a place where you will get the community to join in, unless you are actively trying to stop people opposing?
    "We discussed this [paragraph] for a while": you haven't actually spent that long discussing it - less than a week on WP isn't a terribly long time to discuss a contentious topic. Maybe a slightly wider call for people to chip at that stage would have come up with something better than the rather poor offering here.
    "Usually the first paragraph is the most dense and has the most amount of description". Did you do much research or analysis to get to that conclusion, because it's a long way off what I have seen. Just looking at a couple of the articles listed about, Debussy has three sentences (34 words after the date of death brackets); Olivier, 3 sentences with 58 words; Kubrick, two sentences of 51 words. Those are short, tight paragraphs about people - and yes, they contain the "basic information about a subject". That's a long way from "most dense". Still, it's good to know that the way to legitimately avoid activism on the point of IBs is to write longer leads to ensure that first paragraph negates the need. Is that really the intention of the guideline? I know you are desperate to have IBs in biographies for some reason, but this proposal is the wrong way to go about it. - SchroCat (talk) 12:52, 3 May 2023 (UTC)Reply[reply]
    For me, the decision as to whether a bio article should/should not have an infobox comes down to answering two simple questions: 1) is there an appropriate infobox template that relates to the subject? 2) Do we have enough verifiable data to populate the core fields in that template?
    If the answer to both of these questions is “yes”, then the article should have an infobox… if the answer to either of these questions is “no”… then the article shouldn’t have an infobox (it just does not make sense). Blueboar (talk) 12:44, 3 May 2023 (UTC)Reply[reply]
    How much is "enough" verifiable data? Nythar (💬-🍀) 12:56, 3 May 2023 (UTC)Reply[reply]
    A valid point, and it's one that shows the weakness of the current proposal. What I've (very roughly) sketched out above should deal with that - as it goes to something no-one has really looked at in a methodical way since IBs were first introduced: what is the "core" information. We have fields for any number of points but those shouldn't be used in general biographies (height is a good example of one - great for "world's tallest man" or basketball player articles, but meaningless for most articles). As I said above, birth and death dates are two obvious ones, but a box looks ridiculous and does zero benefit if they and the name are the only fields present. - SchroCat (talk) 12:57, 3 May 2023 (UTC)Reply[reply]
    Many of the oppose comments feature hypothetical arguments that are non-existant in these RfC discussion. If you review the articles mentioned in this proposal you'll see that the arguments (include/exclude) pretty much the same every time. The infoboxes are getting included anyway. This proposal is attempting to confirm the consensus which is infoboxes are increasingly common and accepted. This proposal doesn't make them mandatory, so someone could make your argument and if it's compelling then there will be no infobox. Valuable editor resources are wasted in these repetitive debates that are being played out in RfCs over and over. If these debates were deadlocked I could understand, but infoboxes eventually get added anyway. As someone who is a dedicated RfC commenter this is a colossal waste of time for an inevitable outcome. It seems like the community would attempt to find a solution to save editor's valuable time. Nemov (talk) 13:04, 3 May 2023 (UTC)Reply[reply]
    "Many of the oppose comments feature hypothetical arguments that are non-existant in these RfC discussion": I don't know what you're trying to say here.
    Yes, the arguments are the same in the various IB discussions - that's because there is no direct research or studies to show whether they are useful or wanted by readers; the 'think of the readers - they need an IB' claim is based on nothing but wishful thinking. That means it comes down to opinion and the newer intakes of editors are less flexible in their approach to IBs than many of the older hands who remember the site before IBs were a feature and can see the downsides to them too.
    Valuable editor resources? No editor is required to go to an RfC, no editor is required to open an RfC, but you've managed to spend a lot of time on them (more time on talk than editing articles, I see; perhaps you should try writing an article, rather than just commenting from the side-lines?) And an "inevitable outcome"? Three Four of the last ten discussions have rejected a box - and 70% 60% isn't "inevitable". Either way, that's no reason to have a flawed and easily-gameable guideline. - SchroCat (talk) 13:18, 3 May 2023 (UTC)Reply[reply]
    No consensus closings preserve the status quo ex ante (except in the cases of BLP issues, copyright vios, or external links—see WP:NOCONSENSUS). I wouldn't classify a no consensus vote that results in a status quo box or status quo no box as approving or rejecting a box. And Wikipedia editors put themselves in the shoes of readers all the time—that's not unusual. Wikipedia editors are, also, readers. And, in terms of non Wikipedia editors, as you've admitted, stray IP editors that comment tend to support infoboxes. Not the strongest datapoint, to be sure, but one nonetheless.
    And enough with the personal attacks—"try writing an article[] rather than just commenting from the side[]lines"? I understand you're frustrated that "newer intakes of editors ... can['t] see the downsides" of infoboxes, but perhaps, then, you've been around on Wikipedia long enough to be familiar with WP:CIVIL.--Jerome Frank Disciple (talk) 13:44, 3 May 2023 (UTC)Reply[reply]
    I think we need more examples. For example, I don't think an infobox should be recommended for B. Traven or other people whose identity is subject to debate. —Kusma (talk) 15:42, 4 May 2023 (UTC)Reply[reply]
    That is the sort of thing I might oppose, but that’s an exceptional case. Famous composers are not. Famous writers are not. Celebrities are not. We have concrete information on these people. Dronebogus (talk) 15:45, 4 May 2023 (UTC)Reply[reply]
    B. Traven is a famous writer, though :) —Kusma (talk) 15:50, 4 May 2023 (UTC)Reply[reply]
    This is why I wouldn't support a mandatory rule because there are exceptions. If that were discussed on I'd probably be inclinded to oppose an infobox for that article. Nemov (talk) 15:47, 4 May 2023 (UTC)Reply[reply]
    I'd be much happier if we had some agreement on what the exceptions could look like. If basic facts like year of birth and death are unknown or uncertain, there should not be an expectation that the article has an infobox. Generally, many pre-1900 lives do not fit into our infoboxes well. —Kusma (talk) 15:57, 4 May 2023 (UTC)Reply[reply]
    We we discussed this in the idea lab we'd have to craft some super complicated rule to manage exceptions. I just don't think that's going to be a problem. The issues in RfCs have been mostly slam dunk cases that are being relitigated over and over. A general recommendation is a far I'd go and there's significant wiggle room for the case you cited. The idea is that infoboxes help improve the article. In that it's not an improvement. Nemov (talk) 16:01, 4 May 2023 (UTC)Reply[reply]
    Without adequate protection for reasonable exceptions we should not have a recommendation one way or the other. —Kusma (talk) 16:26, 4 May 2023 (UTC)Reply[reply]
    @Kusma: The general trend is to include infoboxes in biography articles. Recommended exists in the wording of the proposal to indicate that there generally should be infoboxes; however, exceptional cases allow for actual consensus to be generated on talk pages, consensus that focuses on things other than "I generally support infoboxes in these cases so..." or "I generally oppose infoboxes in these cases so...". We don't need to clarify the exceptions; WP:CONSENSUS is one of the basic concepts all editors at Wikipedia should be aware of, and since the wording purposefully doesn't require anything, you should assume that real consensus can result in either the exclusion or inclusion of infoboxes regardless of the recommendation. And this is not WP:CREEP. In actuality, our current system is totally confusing for new editors who are inexperienced and aren't aware that editors who edit certain articles get to control the inclusion or exclusion of infoboxes. Nythar (💬-🍀) 16:36, 4 May 2023 (UTC)Reply[reply]
    Then why should we change the guidelines to recommend infoboxes instead of letting the actual main editors of an article decide on the appropriateness? Everything here is governed by consensus and confusing to newbies. The earlier they learn that Wikipedia is not consistent, the better. —Kusma (talk) 17:00, 4 May 2023 (UTC)Reply[reply]
    @Kusma: Because that's ownership? I see a few editors here are annoyed by my use of the term "ownership", so allow me to elaborate. The "actual main editors" of an article might have the stupidest reasons for including or excluding an infobox, or they might have the most well-thought-out reasons for doing so. Either way, they're the ones who decide on the appropriateness of infoboxes, rendering the opinions of most other editors ineffective. It's not like we have a system in place where the main editors must have good reason to include or exclude infoboxes. Apparently they can do so even on a whim. This proposal aims to eliminate this odd system, so that editors can have meaningful discussions that eventually result in neither actual main editors controlling infoboxes nor the regular "I like it" or "I don't like it" arguments, but instead real consensus that is article-specific. Nythar (💬-🍀) 17:11, 4 May 2023 (UTC)Reply[reply]
    Currently we need "real consensus" for a change in the status quo. The proposal says we should need "real consensus" only for exclusion of infoboxes, not for their addition, but does not actually give us any useful clues which articles should be exceptions. I agree that infobox discussions should be article-specific, hence I oppose suggestions that whole classes of articles should have infoboxes by default. —Kusma (talk) 17:21, 4 May 2023 (UTC)Reply[reply]
    @Kusma: To answer this, I'll repeat what I said above: The purpose of including infoboxes is that they are a tidy, easy-to-access summarization of the biographical contents of an article that pertain to the individual; partial descriptors, you may call them. They provide a basic overview of a person in conjunction with the lede, which provides the rest of the overview. That is why this proposal favors infoboxes. There isn't a need for exception-indicative "useful clues" because the proposed wording is simply a recommendation for including infoboxes for the reasons I highlighted; this recommendation does not override article-specific consensus, so long as that consensus is article-specific. That is implied by the fact that it is a recommendation. For example, infoboxes may be removed in exceptional cases granted that consensus to do so arises. This, however, is rare, and the proposal would solve most of our problems if passed. Nythar (💬-🍀) 17:34, 4 May 2023 (UTC)Reply[reply]
    "infoboxes may be removed in exceptional cases granted that consensus to do so arises": no. IBs may be removed at any time if they do not serve a valid purpose - no consensus is needed - that what WP:BOLD editing is. If someone objects, it can be reverted and a discussion should follow; if there's no agreement it goes to RfC (with the IB still there, as per status quo), but a consensus needed to remove the box. The proposal in either form will have no bearing on that. No-one needs a consensus to make that edit. As to the proposal being one that "would solve most of our problems", there is still no indication that there is a problem. We have had some RFCs recently, of which six have led to the inclusion of a box and four have not. Those RFCs ran OK. No one was censured or blocked. No one was taken to ANI or ArbCom for breaching the contentious topic guidelines. We have a good guideline on IBs already and a good mechanism for coming to (or overturning) a consensus. - SchroCat (talk) 17:47, 4 May 2023 (UTC)Reply[reply]
    The main problems with infoboxes are the inclusion of disputed or uncertain information, as infoboxes lack the necessary nuance, and the tendency of editors to fill out all fields, whether that is beneficial or not. Very often the place of birth is of limited importance for a person, so it isn't in the lead. There is no need for an infobox if all it does is give prominence to such non-important data. —Kusma (talk) 17:48, 4 May 2023 (UTC)Reply[reply]
    @Kusma: If you believe there is inaccurate information in an infobox or that one is composed solely of unimportant parameters (Template:Infobox person: religion, relatives, employer, baptized, death_cause, resting_place, resting_place_coordinates, burial_place, burial_coordinates, citizenship), you can totally start an RfC for the purpose of removing the infobox. If however the infobox contains mostly information that makes it appropriate for inclusion (date of birth, date of death, location of birth, location of death, name, nationality, spouses, and the like) then it is likely that you do not need to start an RfC. Seriously, all these hypotheticals are making this seem more complicated than it really is, but of course someone won't agree. Nythar (💬-🍀) 18:10, 4 May 2023 (UTC)Reply[reply]
    @Kusma:, As I am sure you are aware, you do not have to start an RFC before removing an IB. There is no such policy or guideline that says that and indeed, it goes against many of our policies and guidelines. The only time you need to go to RFC is if someone reverts the removal and no consensus can subsequently be reached - that's the point one should be opened. It is how the site has worked since inception and will continue to do so even if this proposal is passed. - SchroCat (talk) 18:17, 4 May 2023 (UTC)Reply[reply]
    And if you remove it, someone will very likely revert your removal, just as it is likely that adding an infobox will result in its removal. Don't get too focused on my explanations, I'm not wording them perfectly. Nythar (💬-🍀) 18:20, 4 May 2023 (UTC)Reply[reply]
    It depends on the subject and whether there is enough valid information. People add and remove IBs all the time without it ending in a brouhaha or without a reversion taking place - it depends entirely on the article's subject and whether there are enough pieces of key information to be of use to a reader. - SchroCat (talk) 18:24, 4 May 2023 (UTC)Reply[reply]
    If there is only irrelevant information in an infobox (and place of death is arguably mostly irrelevant for many people) it should be removed. Wikipedia works by being WP:BOLD, not by starting RfCs about trivialities. —Kusma (talk) 18:18, 4 May 2023 (UTC)Reply[reply]
    @Kusma: So you've chosen to focus on the fact that I haven't worded my explanations perfectly instead of responding to my actual points? You're correct, in the instance that you described, you'd remove the infobox. However, the entire point of this proposal is to find a solution for when someone does revert your removal. Then, you'd need to decide if an RfC is appropriate. The recommended indicates that infoboxes aren't a must; you should decide if an infobox made up wholly of useless parameters qualifies as an exceptional circumstance for removal. If you believe it does, start an RfC, and the infobox will very likely end up being removed. Nythar (💬-🍀) 18:25, 4 May 2023 (UTC)Reply[reply]
    No one needs to start an RFC every time they want to improve Wikipedia WP:BOLD is a bedrock policy, and if a person believes that removing an empty or useless infobox makes an article better, they don't need to start an RFC to do so. They can just remove it. --Jayron32 18:29, 4 May 2023 (UTC)Reply[reply]
    @Jayron32: Please read what you plan on replying to before you do so. I wrote: the entire point of this proposal is to find a solution for when someone does revert your removal. And a solution for when someone reverts your addition. Nythar (💬-🍀) 18:32, 4 May 2023 (UTC)Reply[reply]
    Well, then an RFC is still jumping the gun a bit then. A personal conversation where you and the other person listen thoughtfully to each other will often result in a quick solution to problems. The issue we have is that everyone jumps to "Lets have a 30 day vote on this!" the second any slight hint of disagreement might exist. 90% of the time RFCs are overkill. It's a small issue, and it needs small solutions. --Jayron32 11:39, 5 May 2023 (UTC)Reply[reply]
    Well, I'd have preferred a simpler solution, but that seems quite difficult to agree upon. Nythar (💬-🍀) 15:25, 5 May 2023 (UTC)Reply[reply]
    I hope I will never have to participate in RfCs about infoboxes on articles I care about. Mostly, I care little about infoboxes either way. Some of my articles have them, some of them don't. I rarely look at them (banner blindness I guess). When I nominate articles for GA, the fact that there is no recommendation for infoboxes means I do not have to have a long drawn out argument about including an infobox when I think it would not be beneficial. Why should it be my job to start an RfC, and not that of someone else who thinks they know better than the article's only author? —Kusma (talk) 18:38, 4 May 2023 (UTC)Reply[reply]
    Nobody at Wikipedia is forced to do anything. If you don't want to start an RfC, don't. Nythar (💬-🍀) 18:44, 4 May 2023 (UTC)Reply[reply]
    Pre-1900 is a little extreme. I was thinking like ancient lives, before the bith of Jesus even. Dronebogus (talk) 16:02, 4 May 2023 (UTC)Reply[reply]
    Off topic
    The following discussion has been closed. Please do not modify it.
    How you personally classify something is up to you, but I will stand by my wording, particularly that there is no "inevitable outcome".
    What I have said about IP editors commenting is that there is a slim majority who !vote in support - but there is hardly likely to be a majority coming to the talk page to say "huzzah - no IB!", is there? They will only make it to a talk page if they see something wrong, and when there is no IB, there are very, very few comments from anyone except editors. As I have said, there is no reserch or study that backs the claims for or against an IB from a reader's perspective, so it's a staw man to try and keep pressing on that point. All it amounts to is personal opinion, which isn't the best way to try and enforce a formatting choice.
    There are no personal attacks in what I have written. It has always been the case that newer intakes of editors have different views from older ones, and there is nothing wrong in that - that's just observation and I'm not sure how you think that an attack? It's a bit of a stretch to claim that, so perhaps you ought to drop that particular line.
    Either way, you can try and pick up on one or two bits of what I have written in response to others, or you can be constructive and look at my comment in this section to discuss what is an actionable point. - SchroCat (talk) 13:54, 3 May 2023 (UTC)Reply[reply]
    Well, I defer to the closers. But I guess if you choose to decide their bolded words don't mean what they say, that's up to you.
    And the snideness in "try writing an article" is absolutely incivility. "Well why are you paying attention to my incivility and not my substantive points" isn't a defense.---Jerome Frank Disciple (talk) 13:57, 3 May 2023 (UTC)Reply[reply]
    If you're trying to pick an argument, with comments that are not based on what I have said, or any reasonable interpretation of that, then you're barking up the wrong tree. - SchroCat (talk) 14:02, 3 May 2023 (UTC)Reply[reply]
    If you're taking that route, I'd suggest deleting "try writing an article" from your 13:18 comment before you deny saying it.--Jerome Frank Disciple (talk) 14:14, 3 May 2023 (UTC)Reply[reply]
    Undecided, but mainly want to highlight objections by some in the oppose camp along the lines of WP:CREEP or a suggestion that it be "evaluated on a case by case basis". The assumption in "case by case" is that people who care enough about the article or subject will talk it out, perhaps with the help of a DR mechanism. In reality, it's not people who care about the article; it's people who care about infoboxes. The RfCs are iterative and more or less identical, rather than specific to the case. "Case-by-case" just turns it into a question of numbers based on personal preference (based more on broad ideas of "what an infobox ought to do" or "what helps readers" rather than what makes a particular article special). In general, I'm inclined to support additional clarity about when to include an infobox to avoid RfCs that boil down to headcounts that have almost nothing to do with the article itself. I don't know if this provides enough such clarity though, per Nikkimaria, et al. It may just slightly reorient it.
    Here's the proposal I would support: "Treat the inclusion or exclusion of an infobox in the same way as WP:CITEVAR, applying this statement by the Arbitration Committee: Where Wikipedia does not mandate a specific style, editors should not attempt to convert Wikipedia to their own preferred style, nor should they edit articles for the sole purpose of converting them to their preferred style, or removing examples of, or references to, styles which they dislike.".
    At the end of the day, we have no clear criteria for including an infobox, meaning it's just a personal preference issue, like CITEVAR/ENGVAR. — Rhododendrites talk \\ 13:27, 3 May 2023 (UTC)Reply[reply]
    Now that I think about it, why doesn't that statement by arbcom already apply. Infoboxes are, after all, an example of "where Wikipedia does not mandate a specific style". Shouldn't WP:INFOBOX simply have a note along those lines like WP:CITEVAR does? — Rhododendrites talk \\ 13:29, 3 May 2023 (UTC)Reply[reply]
    This is an interesting idea. How would it be used in practice? Nemov (talk) 13:33, 3 May 2023 (UTC)Reply[reply]
    It would mean, much like when deciding the referencing style, the primary contributor(s) would determine whether an infobox should initially be included in the article. Then, if other editors disagree with this psuedo-consensus, a discussion on the talk page commences. It would add additional formalities to the way it works currently. Anarchyte (talk) 13:42, 3 May 2023 (UTC)Reply[reply]
    That scenario would essentially be the status quo. Nemov (talk) 13:49, 3 May 2023 (UTC)Reply[reply]
    You’ve diagnosed the problem correctly, but the solution is status quo. That isn’t working. At least, it isn’t working WELL. Dronebogus (talk) 14:17, 3 May 2023 (UTC)Reply[reply]
    [Responding to both comments about the status quo] - It is not the status quo. The status quo doesn't regard infoboxes as a matter of stylistic preference, even if the guidance on infoboxes is so vague that anyone could infer that's what it boils down to. If we start treating it as such, we can start respecting ArbCom's directive that editors should not attempt to convert Wikipedia to their own preferred style, nor should they edit articles for the sole purpose of converting them to their preferred style, or removing examples of, or references to, styles which they dislike. Currently, these discussions are filled with mere preference, as well as editors who are only there to implement their personal preference (infoboxes=helpful; infoboxes=not helpful). Perhaps this is less the stuff of an RfC and more an appeal to arbcom to clarify whether that language should apply to infoboxes... — Rhododendrites talk \\ 14:27, 3 May 2023 (UTC)Reply[reply]
    I don’t want ArbCom getting involved again. Their last solution was an imperfect fix at best, and we don’t need more unilateral decisions from tiny editor groups in this area. Dronebogus (talk) 14:31, 3 May 2023 (UTC)Reply[reply]

    faux-Arbitrary break[edit]

    Here is what I don’t get: most biographies have infoboxes. Numerous biographies have been RFC’d because they lack them. Most of these end up adding a box after a lot of ultimately pointless arguing. This will likely happen into the foreseeable future. So why are the anti-box users so utterly determined to oppose a pretty obvious emerging meta-consensus over something utterly trivial? Dronebogus (talk) 14:25, 3 May 2023 (UTC)Reply[reply]

    WP:NOTARBITRARYRhododendrites talk \\ 14:28, 3 May 2023 (UTC)Reply[reply]
    It’s arbitrary because it’s not part of an existing thread. Why do we even need a rule about this? THAT is WP:CREEP. Dronebogus (talk) 14:29, 3 May 2023 (UTC)Reply[reply]
    @Dronebogus You have said quite enough about this topic. I suggest taking a break. This RfC will be open for 30 days and there will be plenty of comments. Wall of text repeating the same arguments are not helpful for anyone. Nemov (talk) 14:35, 3 May 2023 (UTC)Reply[reply]
    I take some responsibility here—I engaged in a tiff by allowing myself to be baited by a petty remark that I couldn't understand closing summaries because I haven't been on Wikipedia long enough. I shouldn't have done that, and I hatted that discussion, but it may have set a tone. Dronebugs (update: sorry!) Dronebogus, it's ultimately up to you, but if you see comments that you really feel like you can substantively address—and, importantly, that you haven't already substantively addressed—, I would suggest adding to your rationale in the survey section. I understand it's easy to, in good faith, want to talk to every editor you might disagree with or have a response to, but the various walls of text that can result end up making you look like you're dominating the discussion.--Jerome Frank Disciple (talk) 14:48, 3 May 2023 (UTC)Reply[reply]
    That’s the second time I’ve been called “Dronebugs” in a week 😆 Dronebogus (talk) 14:49, 3 May 2023 (UTC)Reply[reply]
    Agreed... Probably time to give it a rest. Let the rest of the community have their say, and perhaps also don't bunch them into stereotype categories like "anti-box users". I have no disposition one way or another on the so-called infobox debates. WaltClipper -(talk) 16:34, 3 May 2023 (UTC)Reply[reply]
    I know the broad categories might seem unfair, but I really think there’s only three camps you can be in here— seeing biographical infobox inclusion as an objective maintenance issue that isn’t up for debate (“pro”), seeing it as something that the “article stewards” get to decide for any reason they agree upon (“anti”) and being neutral. Dronebogus (talk) 18:00, 3 May 2023 (UTC)Reply[reply]
    Or, you know, people who are still opposing i-boxes on principle, like that’s a plausible stance at this point. Dronebogus (talk) 15:52, 4 May 2023 (UTC)Reply[reply]
    Can you name one person who has stated they are opposed to IBs on principle? - SchroCat (talk) 16:19, 4 May 2023 (UTC)Reply[reply]
    David Eppstein didn’t literally say that but he made it clear he’s opposed to infoboxes period. Dronebogus (talk) 20:18, 4 May 2023 (UTC)Reply[reply]
    User:David Eppstein, is this true? My guess is no (and Dronebogus if you are going to make a dubious claim about another editor you should let them know). I support infoboxes for vast swathes of bios (sport, military, politicians, most academics and many others) but not for everybody, and on the relatively rare occasions there is a debate I usually oppose the infobox, because unless there are very good reasons not to have one (see eg Mozart most recently), there isn't a discussion. Johnbod (talk) 02:40, 28 May 2023 (UTC)Reply[reply]
    I am not opposed to infoboxes period. I have deliberately not objected as many of the articles I created have been expanded with infoboxes. I regularly expand existing infoboxes (recent and typical example). I may have even created an infobox or two here or there myself. However, the cost-benefit of infoboxes (where cost = pulling reader attention from the lead text and benefit = informing readers better than just reading the lead text would) is often not positive and I will often revert the addition of an infobox in cases where I think it is not a net benefit. I am definitely opposed to any WP:CREEP of our standards in the direction of requiring or even recommending infoboxes as a general thing. —David Eppstein (talk) 05:27, 28 May 2023 (UTC)Reply[reply]

    Break for pings following RFC update[edit]

    Pings on alternate proposal

    Pinging all prior voters: @Nythar:@Dronebogus:@Nemov:@Tamzin:@Galobtter:@Mackensen:@Thryduulf:@Zaathras:@RunningTiger123:@Bradv:@Nerd1a4i:@Random person no 362478479:@Pythoncoder:@ModernDayTrilobite:@Tim O'Doherty:@Hatman31:@Immanuelle:@Barnards.tar.gz:@Ssilvers:@SchroCat:@Blueboar:@North8000:@Phil Bridger:@Nikkimaria:@Anarchyte:@Sdkb:@Kusma:@WaltCip:@Jayron32:@David Fuchs:@David Eppstein:@Thincat:@AndyTheGrump:

    Hello! The RFC has been updated based on comments by User:Thryduulf and User:Barnards.tar.gz. If you can, please update your survey entry to indicate (1) whether you support or oppose changing the guidelines at all and, if support, (2) which option or options you support (or "other").--Jerome Frank Disciple (talk) 14:58, 4 May 2023 (UTC)Reply[reply]

    Oh, gosh, there are options now? In a CENT RFC that was already in progress? This is going to become a trainwreck. WaltClipper -(talk) 15:59, 4 May 2023 (UTC)Reply[reply]
    It’s only a few days old and opposers will always oppose without qualification because as I said they view this as a “local consensus” thing that should have zero external guidance. It won’t become any more trainwrecky than it already is. Dronebogus (talk) 16:04, 4 May 2023 (UTC)Reply[reply]
    • @WaltCip: I'm just curious at what point do you think this is a problem? 2 RfCs a month? 5? At what level does this become a problem? Over the last six months his is the most common type of RfC for biographies and they're not started by the same editor over and over. Thanks! - Nemov (talk) 16:11, 4 May 2023 (UTC)Reply[reply]
      I'm a bit perplexed by your question. I didn't say anything about the number of RfCs a month. I commented on adding options while the RfC is already underway with lots of responses already submitted. WaltClipper -(talk) 16:57, 4 May 2023 (UTC)Reply[reply]
      Sorry, reviewing above I pinged the wrong person. You can ignore my question. Nemov (talk) 17:04, 4 May 2023 (UTC)Reply[reply]

    I don't see anything identified as a new RFC. I'm sure that if I spend more time than typical respondent would I could figure it out. This is getting too gigantic and confused to have real/sufficient feedback. North8000 (talk) 13:12, 5 May 2023 (UTC)Reply[reply]

    The additional options (2 and 3) are new. I agree the RFC might be too large now, but enough discussion about preferring other options was made that I figured it was worth asking Nythar--Jerome Frank Disciple 14:15, 5 May 2023 (UTC)Reply[reply]
    My guess at the outcome of this is that it's going to die under it's own weight and complexity preventing any significant new input I think that for proponents of addition of a guideline that the best outcome that could expect here would be "no consensus to add". Might it be better to withdraw? Perhaps a proponent for adding a guideline could draw from all of the input received to craft a fresh new proposal that is also guided by the concerns expressed under "oppose" so that it could garner support from some of the "oppose" people. Sincerely, North8000 (talk) 16:07, 5 May 2023 (UTC)Reply[reply]
    The concerns expressed under oppose are basically "don't do anything at all." Can't craft a new proposal with no meaningful input. Nythar (💬-🍀) 16:31, 5 May 2023 (UTC)Reply[reply]
    I won't speculate on the outcome, but I haven't been surprised at the feedback so far. I don't see a reason to withdraw after 3 days and you're right, most of the oppose camp so far seems entrenched. Nemov (talk) 16:33, 5 May 2023 (UTC)Reply[reply]
    Yeah this is about what I expected, too. From my perspective, it would just be better to reduce these debates, given how dragged out and repetitive they are, even if that means some pages get infoboxes where that infobox isn't particularly helpful (although worth emphasizing again that none of the proposals are mandatory). From the perspective of the oppose voters, based on their votes in various RFCs, that's already happening. But I think, from their perspective, they want to maximize their chances at blocking an infobox, even at the cost of many repetitive losses.--Jerome Frank Disciple 16:42, 5 May 2023 (UTC)Reply[reply]
    Isn’t that kind of… disruptive? System-gamey…? Dronebogus (talk) 19:22, 5 May 2023 (UTC)Reply[reply]
    "most of the oppose camp so far seems entrenched": as do most of the support camp. The problem with the use of IBs and therefore IB discussions is that it's a binary question with very limited room for compromise: there either is one or there isn't. When compromise was tried previously - by having a collapsed box, for example - there has been enough of a campaign against them that I think there are only a couple still left; apparently compromise wasn't wanted. There have been suggestions from the oppose camp further up, but they have been ignored or rejected unfortunately. - SchroCat (talk) 17:06, 5 May 2023 (UTC)Reply[reply]
    I think that's a fair assessment! In fact, it's one of the reasons I thought guidance should be included—because the debates so often seem to be a referendum on infoboxes in general (though a few specific points might be made), it seems like the type of thing guidance should address, as it's quite repetitive! In light of the recent trend towards inclusion, I was hoping a non-mandatory policy might at least shorten some of these drag-out fights, but if the opponents of infoboxes aren't willing to slightly lower their chances of prevailing, then even explicitly non-mandatory guidance reflecting that trend is bound to be rejected. I'll also be really curious to see how the Colleen Ballinger discussion ends up once it's closed—a consensus exclude seems unlikely there, but I'm not sure if there'll ultimately be a consensus include or a no consensus.--Jerome Frank Disciple 17:47, 5 May 2023 (UTC)Reply[reply]
    It’s a non-mandatory policy but it’s also, quite intentionally, trying to throw extra weight on the pro-standardization side. This obviously sounds unfair but, as it is, the anti-standardization side actually has a built-in edge with the “infoboxes are unsuited to liberal arts” guideline that is brought up at every single discussion. Dronebogus (talk) 19:19, 5 May 2023 (UTC)Reply[reply]
    JFD, Unfortunately there are people who argue “all IBs are good, so include one here” (and, lesser seen, the opposite), although ArbCom says it should be focused in the specific article – and despite me focusing on the individual article, there are too many closers of the discussions who only focus on the general, rather than the specific.
    DB, there is no ‘“infoboxes are unsuited to liberal arts” guideline’ included in the guideline (either existing or proposed), which could be why this is being opposed. IBs for the liberal arts is not seen by some as beneficial, but the infobox wars/pressure/grief over years has lead to most not liking the situation, but feeling bullied off/exhausted by the ongoing push to have them. That doesn’t mean they should get included, but just shows that the pro-IB pushers have been trying to achieve the aim of exhausting any opposition for many years. - SchroCat (talk) 23:44, 5 May 2023 (UTC)Reply[reply]
    I think, for the closers, the real problem is that "focus on the general, not the specific" provides no guidance on what the threshold is. For example: If the infobox makes just one likely-searched-for datapoint more visible, is that enough? You can't answer that question with "well focus on the specific"—it is a specific! And perhaps you're right that there aren't as many "all IBs are bad" users, but, just as the same users show up time and time again in the pro voting sections; the same users show up time and time again in the anti sections ... and frequently you'll see repeat-pro voters say "of course if the article was just a silly stub then obviously an infobox wouldn't make sense!" ... and frequently you'll see repeat-anti voters say "obviously I support infoboxes on certain articles!" But, at least from what I've seen, these voters never seem to find an RFC that causes them to change their normal position.--Jerome Frank Disciple 23:53, 5 May 2023 (UTC)Reply[reply]
    Pro-ibox users don’t really have a choice here but exhaustion tactics when the opposition is stonewalling. Dronebogus (talk) 00:22, 6 May 2023 (UTC)Reply[reply]
    Exhaustion tactics are also a form of stonewalling. Anarchyte (talk) 06:13, 6 May 2023 (UTC)Reply[reply]
    D: It’s not stonewalling to hold a contrary opinion on a binary question. There is now an IB on Olivier: I still don’t think it a good idea for all the reasons I said in the discussion; it’s not stonewalling that I still don’t agree with it.
    JFD, Please note that in the Olivier discussion my comments there were specifically about that article, not IBs in general. As to “these voters never seem to find an RFC that causes them to change their normal position” that’s something a straw man. Biographies that should have an IB tend to already have them already and are not contentious. Again, the area of contention isn’t the whole field of biographies, but those in the liberal arts, where for some there is no flexibility of approach. - SchroCat (talk) 07:43, 6 May 2023 (UTC)Reply[reply]
    “If a bio needs one, it probably has one and adding one wouldn’t be controversial” is circular reasoning. Dronebogus (talk) 00:58, 7 May 2023 (UTC)Reply[reply]
    No it’s not. (And please don’t use quote marks for something I haven’t actually said). - SchroCat (talk) 03:23, 7 May 2023 (UTC)Reply[reply]
    I'd be comfortable withdrawing at this time. There's been enough comments at that stage to see this is deadlocked. There doesn't appear to be enough editors who believe this is a real problem. With that in mind, I'll continue to promote future RfCs on infoboxes here. Thanks for all the feedback and the editors who worked hard on attempting to solve a long term issue. Nemov (talk) 20:40, 7 May 2023 (UTC)Reply[reply]
    Concur as to withdrawing, but I think @Nytharshould make the call.--Jerome Frank Disciple 20:41, 7 May 2023 (UTC)Reply[reply]
    @Jerome Frank Disciple: Sorry I didn't respond sooner, my notifications might have gotten clogged up. Yes, unfortunately I agree this isn't going to succeed. Well, at least we know what the community thinks. Nythar (💬-🍀) 03:36, 10 May 2023 (UTC)Reply[reply]
    This issue will never be resolved. We should just accept that. Looking forward to more long, pointless RfCs about infoboxes for the rest of the foreseeable future. Dronebogus (talk) 21:11, 7 May 2023 (UTC)Reply[reply]
    WP:ALLROADSLEADTOINFOBOXES. —David Eppstein (talk) 21:08, 28 May 2023 (UTC)Reply[reply]

    Thanking administrators for blocks[edit]

    The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
    Strong consensus not to implement; blocks are seen as a necessary evil, not necessarily an action which should be clebrated. Mattdaviesfsic (talk) 09:19, 18 May 2023 (UTC)Reply[reply]

    Should it be possible to use the thanks tool to thank an administrator for a block on the English Wikipedia? Dreamy Jazz talk to me | my contributions 18:57, 6 May 2023 (UTC)Reply[reply]

    • Support (as proposer) Thanking an administrator for a block is currently not possible, but would be easily enabled. There has been some disagreement as to whether thanking for a block should be possible on Phabricator (T268701). I couldn't find previous discussion surrounding this on enwiki and the discussion surrounding this has been only with a few people. Enabling on the English Wikipedia could give a indication as to it's benefits and negatives, which could be used to expand it's use to other wikis and to be enabled by default.
      I see many benefits to enabling this especially surrounding admin retention as making non-controversial and beneficial blocks doesn't usually merit a thanks message. Having the occasional thanks for carrying out actions gives affirmation that they are appreciated. Dreamy Jazz talk to me | my contributions 19:00, 6 May 2023 (UTC)Reply[reply]
      For further thought: It is currently possible to thank an administrator for deleting a page and also protecting a page. If discussion here is concludes against enabling this, I wonder whether these two should be re-visited? Dreamy Jazz talk to me | my contributions 19:24, 6 May 2023 (UTC)Reply[reply]
      The result of this discussion either way will give better direction on the associated Phabricator task (which is to allow thanking blocks by default). If there is support here it could suggest support for enabling by default and if there is opposition it could be the basis for declining the task. Dreamy Jazz talk to me | my contributions 19:28, 6 May 2023 (UTC)Reply[reply]
      Deletions and protections aren't against a specific person, so there aren't the same issues as with blocking. Galobtter (talk) 02:23, 7 May 2023 (UTC)Reply[reply]
    • Very weak oppose. Per WP:FUCK, administrators should be doing things because they are the things that need to be done, not in pursuit of recognition. I don't think that fluffing admins' egos is a very good approach to retention - if prospective admins are led to believe that their experience with the mop is going to be all champagne and roses, they're going to have a rough time. I also think that thanking an administrator for a block is awfully close to WP:GRAVEDANCING. Ivanvector (Talk/Edits) 19:21, 6 May 2023 (UTC)Reply[reply]
      I think providing feedback can be more than bolstering ego—it can provide connection to the community so admins don't feel like they are operating in a vacuum. There are of course disadvantages. Feedback can be non-representative, and an asymmetric thanks mechanism is particularly prone to that. I wouldn't want to change community culture so that thank-you messages are always taboo, for instance, but I agree editors should be constructive and aware of the effect such messages have on others, including the blocked editor and those who advocated on their behalf. If there was already ample feedback during a discussion, for example, more feedback may not be necessary. isaacl (talk) 21:43, 6 May 2023 (UTC)Reply[reply]
      @Ivanvector: Per what?? The UPPERCASEs are getting cheeky these days! jp×g 16:13, 8 May 2023 (UTC)Reply[reply]
    • I'm not convinced there is a strong need for this. When people want to thank me for a block with the "thanks" button, they usually thank me for some edit accompanying the block like the talk page notice or a note on ANI that says "I have blocked the user". —Kusma (talk) 19:34, 6 May 2023 (UTC)Reply[reply]
    • Weak support. Sometimes a prompt block (usually of IP) makes everyone's lives easier, but I just thank the admin for a related action per Kusma. Certes (talk) 20:27, 6 May 2023 (UTC)Reply[reply]
    • Weak oppose per Ivanvector and Kusma. Thryduulf (talk) 20:48, 6 May 2023 (UTC)Reply[reply]
    • My experience is much like Kusma's. Cullen328 (talk) 20:54, 6 May 2023 (UTC)Reply[reply]
    • Weak support. There are times when thanking an admin for a related action isn't possible. For example, when dealing with an LTA where a block message wasn't left for WP:DENY reasons and where the responding admin is not taking action based on an ANI post. These don't happen very frequently so I understand if the community thinks the cons of the proposal outweigh the benefita of enabling such a feature for these limited scenarios. However, there have been times where I've wanted to send thanks but couldn't (in those cases I usually leave a message on the admin's talk page when I really think a thank you is in order, but this takes significantly longer). Thanks, Aoi (青い) (talk) 21:09, 6 May 2023 (UTC)Reply[reply]
    • Oppose per Ivanvector. AndyTheGrump (talk) 21:20, 6 May 2023 (UTC)Reply[reply]
    • The existing pros and cons for thanking administrators for administrative actions already apply today to the existing methods (talk page message, thanking for related edits). Personally I don't feel adding one more method will change the balance of advantages versus disadvantages. Although I don't feel strongly about it, I think the chance that I'm mistaken and the advantages are amplified is not worth the risk I'm mistaken and the disadvantages are amplified. Thus I don't favour adding the proposed functionality. isaacl (talk) 21:28, 6 May 2023 (UTC)Reply[reply]
    • Oppose per Ivanvector. Some1 (talk) 21:58, 6 May 2023 (UTC)Reply[reply]
    • Weak oppose. There's at least one disadvantage, even if limited: it opens up an additional avenue for trolling, gravedancing, and the likes surrounding blocks. That'd be one thing if the benefits outweigh those disadvantages, but considering the relative scarcity of blocks where the work-around mentioned by Kusma doesn't suffice, the benefits seem to me at best equally limited as the disadvantage. (Especially when considering that many of those blocks without related edits one could click "thank" on are blocks of LTAs and DENIED trolls, which are pretty much the very people who would abuse such avenues for further trolling.) AddWittyNameHere 23:06, 6 May 2023 (UTC)Reply[reply]
    • Oppose - However much it might be the opposite in practice, blocks aren't meant to be celebrated. They're intended to stop and prevent ongoing disruption. Adding 'thanks' to it will inevitably politicize the act as people "thank" controversial blocks against their enemies. This isn't a habit we should encourage. --WaltClipper -(talk) 23:22, 6 May 2023 (UTC)Reply[reply]
    • Weak support This could potentially reduce gravedancing, not increase it. A "thanks" is semi-private. No one but the thankee known what you sent the "thanks" for. Maybe it was something else they did around the time of the block, or maybe some edit from a week ago that you just noticed. But without the option to thank, the alternative is a public message, which could much more easily veer into GRAVEDANCING territory. My support is only "weak" because, as Kusma says, there's usually some related action, so it's not a big deal either way. Suffusion of Yellow (talk) 23:57, 6 May 2023 (UTC)Reply[reply]
    • Weak Oppose. I get thanks from time to time for various admin-ish things I do. It sometimes makes me feel uncomfortable because I'm not sure if it means "Thank you for your service" or "Thank you for supporting my position". I suspect being thanked for a block would be more likely to be the latter. -- RoySmith (talk) 00:11, 7 May 2023 (UTC)Reply[reply]
    • Oppose Per RoySmith, we should not encourage cheering about a block. Per Kusma, if people really want, they can thank for an associated comment although that should be infrequent. Johnuniq (talk) 00:30, 7 May 2023 (UTC)Reply[reply]
    • Oppose. Would create avoidable drama. Nardog (talk) 00:47, 7 May 2023 (UTC)Reply[reply]
      Serious question. How often do y'all go through Special:log/thanks and try to work out from the timestamps what people are being thanked for? I've never even seen anyone publicly admit that they do this; e.g. "as you can see, in the first day after [admin I like] deleted [page I don't like], they got 20 thanks, but on most days they get between 3 and 5 (see attached statistical analysis in figures 1 through 6), so obviously the AFD closure was correct". All this talk of "drama" and "gravedancing" and "mob mentality" implies this is commonplace. Suffusion of Yellow (talk) 20:18, 7 May 2023 (UTC)Reply[reply]
    • Strongly oppose. Blocks are necessary, but they're also a kind of failure. Nothing to celebrate. Isaac Rabinovitch (talk) 01:10, 7 May 2023 (UTC)Reply[reply]
      This exactly. A block might be a successful utilization of policy in that it prevents disruption, but in some ways, it is also a failure since it indicates an incompatibility between the blocked editor and Wikipedia that no one was able to reconcile. It's a bit like sending in the SWAT team to take out an unstable person after a breakdown in negotiations between police and suspect; it might get the job done, but it's also shameful and disagreeable. And cheering on the SWAT team after they finish the job bears the unpleasant undercurrents of mob mentality. WaltClipper -(talk) 15:09, 7 May 2023 (UTC)Reply[reply]
    • Comment Thanking an admin for making a block is not necessarily celebrating, gloating or grave-dancing, but could simply be expressing thanks for performing a necessary task that may subject that admin to attacks. - Donald Albury 12:48, 7 May 2023 (UTC)Reply[reply]
      Yes, it might not necessarily be one, but that's the problem with a "thanks". It does not distinguish between thanking for a necessary task to reduce ongoing disruption vs thanking for eliminating a controversial editor from Wikipedia. It's an unnecessary addition that adds no value, and it can't be retracted or removed once issued, as opposed to a Barnstar that an admin could simply remove from their Talk Page if they feel that it's inappropriate for the situation. WaltClipper -(talk) 15:03, 7 May 2023 (UTC)Reply[reply]
    • Support It's simply a way to communicate easily with the admin so they know you saw it which is sometimes useful after being engaged in dealing with a bad actor. It also adds an additional level of civility, which Wikipedia needs. For example, what if the thanker and thankee were engaged in a heated debate elsewhere on a diff topic, this signals to the thankee the thanker can see past their differences overall and no hard feelings, it defuses things. It's not just about ego, it's grease for the sometimes sticky parts of Wikipedia. -- GreenC 15:10, 7 May 2023 (UTC)Reply[reply]
    • Any case where thanking a block would be gravedancing or in bad faith or whatever will have an accompanying user talk edit for the block notice. The only blocks that this generally doesn't happen for are for new accounts so blatantly disruptive that someone else wanting to thank the blocker is likely, appropriate, and uncontroversial. Preventing thanking directly for the block doesn't stop bad thanks; it just makes good ones more inconvenient and occasionally impossible. —Cryptic 15:29, 7 May 2023 (UTC)Reply[reply]
    • Strong Oppose - Comes off as going against WP:AGF. It would provide absolutely nothing of value. KatoKungLee (talk) 17:11, 7 May 2023 (UTC)Reply[reply]
    • Depends on how good Wikipedia's common sense is. CactiStaccingCrane (talk) 17:39, 7 May 2023 (UTC)Reply[reply]
    • Support. I hear some concerns raised above, don't really buy them, but this would definitely suit the types of blocks that I usually do - LTAs, VOAs, abusive socks, and other very-undesirables. Most of the time I don't leave a talk page message. Very often I don't even make any related edits. The thanks that I've received when I do apply talk page notices, or protection, or reverts, says to me that some editors would appreciate having a quick way to show a little appreciation for a good job. And I appreciate being appreciated for doing a thankless task. Having a thank button will also help prevent talk page spam unnecessary messages on my talk page. You're welcome. -- zzuuzz (talk) 17:54, 7 May 2023 (UTC)Reply[reply]
      Serious question, and I'm not being rhetorical -- am I CLUEless to think that people using the "thank" button for blocks could or would be doing so in bad faith? If I am, I'd like to know so that I can self-correct. You make good points; it is a thankless task controlling vandalism, I agree, and perhaps I've been around WP:ANI too much to assume those extraordinarily explosive blocks like those against Athaenara are the norm. WaltClipper -(talk) 18:06, 7 May 2023 (UTC)Reply[reply]
      @WaltCip - If I reported you for something on here and got you blocked tomorrow, how would you feel? I doubt you would feel happy. How would you then further feel if I thanked the admin who did it publicly and told them what a great job they did and how I was right in getting you blocked? I don't think that would make you feel very good either. But, you are blocked. You can't complain or do anything about it. That's why it's a problem.KatoKungLee (talk) 19:43, 7 May 2023 (UTC)Reply[reply]
      Well as I mentioned I don't really buy it. Are admins going to suddenly think hey I should make even more controversial blocks? I don't think so. Is there any added value on the grave dancing scale? Hmm, no? Would it "create avoidable drama"? Huh? In these ANI situations, admins are going to get most of their feedback at ANI. On the plus side I suppose having a thanks button would help identify shy people with a vested interest. I already see that happen, and from an admin point of view I've never known it to be a bad thing. But Special:Log/block is where most of the real action happens, not ANI. The vast majority of blocks are just some school, or someone writing poop, trashing an article that may be very dear to some regular (or even casual but sincere) editor who has put a lot of work into it. These editors can be very appreciative when we put a stop to it, and that's okay. -- zzuuzz (talk) 19:12, 7 May 2023 (UTC)Reply[reply]
    • Oppose I indirectly thank admins for blocking by thanking them for adding block notices. This proposal is both unnecessary busywork and just kind of silly. Dronebogus (talk) 19:10, 7 May 2023 (UTC)Reply[reply]
    • Support Would probably reduce drama/gravedancing per Suffusion of Yellow; I also agree with what Zzuuzz wrote. DanCherek (talk) 19:48, 7 May 2023 (UTC)Reply[reply]
    • Weak support in concept but do not think the result of this should be see as greatly increasing the phab requests priority higher than than showing the community supports the idea. I think it's fairly low priority because I have thanked on he other related edits, as mentioned above, when an admin does a block I think is thank-worthy. Most of the downsides mentioned above, I think, are unlikely given the only "public" aspect of it is the fact that the thanks given and thanks received counts will both go up by one (as far as I know?). Some of the difference may just be editor's experience in when they see blocks: for me, it's primarily admins blocking vandalism only IP/accounts after I have already warned them and/or reported them to a notice board. In which case, me being able to give a direct thank to the blocking admin makes sense to me. An editor giving the block a thank after, say, a long-drawn out AN/I thread is potentially a bit more problematic but I'm not sure the negative outweighs the potential value. (Similar to what others have said above: Suffusion of Yellow, Zzuuzz, and GreenC.) Skynxnex (talk) 20:48, 7 May 2023 (UTC)Reply[reply]
      Of course if sufficient admins oppose this, as is starting below, I'll probably withdrawn my (weak) support since "forcing" this doesn't make sense either. But some of the issues feel like general issues with thanks. Skynxnex (talk) 13:55, 8 May 2023 (UTC)Reply[reply]
    • Oppose Tacky. Zaathras (talk) 20:52, 7 May 2023 (UTC)Reply[reply]
    • Oppose. I always assumed this function was disabled to prevent gravedancing and realistically, everyone just thanks you for placing the block notice anyway. I guess there's the case mentioned above where a LTA/troll is blocked without a notice, but is being unable to receive thanks for these actions really causing a crisis of morale among the admin team? Personally, I find the thanks spam after blocking a few accounts at AIV pretty annoying. There are people who will give you an individual "thanks" for a) placing a block notice on a sock's talk page; b) tagging the sock; c) closing the SPI case; d) reverting the sock; etc. Maybe users should be given a limited number of thanks per day to make them a bit more meaningful. Spicy (talk) 21:01, 7 May 2023 (UTC)Reply[reply]
      Strongly oppose limiting the “thank” function we don’t need MORE unnecessary rules about trivial things that have literally nothing to do with the encyclopedia. Dronebogus (talk) 21:13, 7 May 2023 (UTC)Reply[reply]
      It had originally not been included because of the following comment at the task that allowed thanking for log entries (T60485#4047567):
      Our current criteria for having a log in the list is that thanking for that doesn't come across as harmful/doesn't encourage negative behavior. This is why "block" related logs are not in the whitelist. Pretty much everything else is allowed. Dreamy Jazz talk to me | my contributions 14:10, 8 May 2023 (UTC)Reply[reply]
    • Oppose per Spicy; thanking for blocks wouldn't seem to add anything important besides gravedancing. -sche (talk) 21:16, 7 May 2023 (UTC)Reply[reply]
    • Oppose. I can't think of an administrator who would view this as positive feedback. Personally, I'd be wondering if I had to now look at the contributions of the person who thanked me to see if this was a sign of the edit-warrior mindset. Please don't thank me for any of that stuff. Don't thank me for doing an SPI. Don't thank me for any of that stuff. If so moved, feel free to thank me for edits, or for commentary - but not for logged actions. Risker (talk) 21:58, 7 May 2023 (UTC)Reply[reply]
      There are at least two supports from administrators right in this section; this is a good example of why "I can't think of..." arguments are so easily disregarded. Orange Suede Sofa (talk) 03:34, 8 May 2023 (UTC)Reply[reply]
      What they'd value is for some appreciation for the tough work that admins do, especially those who deal with the scummy stuff. You want to thank someone, use their talk page and write them a personalized message instead of performing a little click. It will mean so much more. Risker (talk) 04:41, 8 May 2023 (UTC)Reply[reply]
    • Weak Oppose Per above reasons, but also I feel being an admin is a thankless job. Beyond what any editor does to get thanked, giving thanks for blocking or banning someone is much like clapping when someone is kicked out of an arena for being a pest. It's distasteful to the person being blocked (even if the blockee doesn't know). Conyo14 (talk) 03:49, 8 May 2023 (UTC)Reply[reply]
    • Oppose, very un-classy. Where you do feel the need to thank a sysop, they have these things called talk pages.—S Marshall T/C 07:49, 8 May 2023 (UTC)Reply[reply]
    • Oppose Gravedancing. We don't celebrate people having to be blocked. --Jayron32 14:08, 8 May 2023 (UTC)Reply[reply]
    • Oppose as gravedancing. And cowardly gravedancing at that. If you wouldn't feel comfortable publicly thanking someone on their talk page for something, you shouldn't be given the option to hide behind the veil of the thanks button. --User:Khajidha (talk) (contributions) 14:44, 8 May 2023 (UTC)Reply[reply]
    • Oppose, unnecessary. Almost all the time a block leads to a block notice on the user talk page; thank the blocking admin for that. --jpgordon𝄢𝄆𝄐𝄇 15:12, 8 May 2023 (UTC)Reply[reply]
    • Oppose I don't think it is very helpful or too necessary for the encyclopedia. Many editors who have been blocked may have made valuable contributions in the past, and perhaps their recent destructive edits (or any other reasons) led to their blocking. Thanking the blocking of that user may not show appreciation for the editor's other good works. Even if their contributions were few in number, they still mattered. Additionally, blocking a user is not an achievement, but rather a failure, that we lose another editor. Prarambh20 (talk) 15:19, 8 May 2023 (UTC)Reply[reply]
    • Oppose; I do like the idea of being able to thank for a variety of log actions, but in this instance, it seems like thanking for blocks specifically would be an act whose vibe ranged somewhere between awkward and moustache-twirling. Not that I am in general support of writing software to prevent people from doing something that could potentially be rude, but mostly what I foresee is people (i.e. myself) doing this accidentally and adding a giant permanent entry to Special:Log/TimesThisPersonWasAGiganticAsshole/JPxG. Or, perhaps, Special:Log/HeyLTAsGoMessWithThisGuy/JPxG. jp×g 16:11, 8 May 2023 (UTC)Reply[reply]
    • Weak oppose In addition to what others have said, you can already thank an admin for the block via the edit they should be making to the user's talk page notifying them of the block. ~ ONUnicorn(Talk|Contribs)problem solving 16:32, 8 May 2023 (UTC)Reply[reply]
    • Oppose per Ivanvector. If an admin needs moral support from the commonfolk, there are other ways to provide it. ―Mandruss  22:08, 8 May 2023 (UTC)Reply[reply]
    • Oppose. Just send the admin an email if you want to express your appreciation. – wbm1058 (talk) 18:19, 9 May 2023 (UTC)Reply[reply]
    • Oppose By enforcing the block the admin has done their job if any thanks need to be conveyed it could be sent in a mail to that admin. The person has been blocked that should be the end of the case. Move on. It is time for the banned editor to review their own actions and reflect.Mnair69 (talk) 00:49, 10 May 2023 (UTC)Reply[reply]
    • Oppose Smacks of grave dancing.--Wehwalt (talk) 01:02, 10 May 2023 (UTC)Reply[reply]
    • Comment can we WP:SNOW close this? Oppose consensus is pretty overwhelming after just 3 days, I don’t know why anyone would bother keeping this open. Dronebogus (talk) 00:49, 11 May 2023 (UTC)Reply[reply]
      • No. I mean, nobody has to read it. Nobody has to comment. re "don’t know why anyone would bother keeping this open", I do. People can waste their time (in your opinion) on any harmless thing they want to. Even tho it's not going to win, maybe people still want to make unsaid points. I do, and will. — Preceding unsigned comment added by Herostratus (talkcontribs) 01:18, 11 May 2023 (UTC)Reply[reply]
    • Enh, I mean, OK, the great majority of blocks are justified... I suppose most by far are blocks of people who dropped in to vandalize or troll. There's no real need to thank for those, usually, they're so simple and common. Many, I'm sure, are hands-down justified, even tho it's of a longer-term editor. But some are debatable, some even wrong -- people are human. Thanking for those... it's kind of nyah nyah nyah. Go to the talk page if you really want to.
      And I mean, if you're blocking a long-term editor, something has gone badly wrong. If the block is justified and the person is unteachable, fine. But is it possible the the person blocking has missed a chance to educate the editor. Happens at least sometimes. It's not a crime -- people are human, people are busy. But the block is more an occasion for sad reflection rather than joy. My 2c. Herostratus (talk) 01:18, 11 May 2023 (UTC)Reply[reply]
    • Weak oppose per thank the block notice. That's what I did before I was an admin for vandal blocks and such, and that's what I've seen done now that I'm an admin. It gets the job done. ScottishFinnishRadish (talk) 16:40, 11 May 2023 (UTC)Reply[reply]
    • Weak oppose This isn't that big of a deal, but speaking as someone who has been blocked under circumstances that I considered ...well a lot of adjectives would work here, it would feel a lot like gloating, just one more thing to pile into Wikipedia's record. If a user really feels the need to thank an administrator publicly, then let them do so on a talk page, where there can be some chance of context and nuance. Darkfrog24 (talk) 01:08, 13 May 2023 (UTC)Reply[reply]
    • Oppose. Unnecessary and feels like WP:GRAVEDANCING. I know that's just an essay, but I agree that that kind of behavior feels like bad form. When a block isn't routine, i.e., when it happens to a long-term editor, or to someone a part of a long content dispute, or when there are strong feelings on both sides, the "thank"s would seem like a way to politicize and inflame the issue rather than lowering the temperature. If the goal of thanking is Wikilove, it feels like this is not the way to go.--MattMauler (talk) 03:25, 14 May 2023 (UTC)Reply[reply]
    • Oppose but only for the technical reason that such a change would require the devs to adjust the code, time that could be better spent fixing bugs elsewhere. As for the general principle, I'm neutral. It can already be done, after a fashion - a block is often accompanied by a post of a block notice to the user talk page of the blocked editor, and that may be thanked without any software change, nor indeed any consensus here. If there was no block notice, and you really want to thank the admin, then you are already permitted to use the admin's talk page to leave a message, as others have already pointed out. --Redrose64 🌹 (talk) 10:05, 14 May 2023 (UTC)Reply[reply]
      If there was support from this RfC, I would have been uploading the change and pushing it into production. However, as there doesn't seem to be consensus that is a moot point. Dreamy Jazz talk to me | my contributions 18:13, 14 May 2023 (UTC)Reply[reply]
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Hypothetical star[edit]

    Hypothetical star is a list and should be treated as such. From my point of view, on Wikidata [hypothetical star (Q5961276)] and [list of hypothetical stars (Q118591275)] should be merged.

    - Io Herodotus (talk) 07:19, 23 May 2023 (UTC)Reply[reply]

    @Io Herodotus: You are at the wrong venue for this, possibly even the wrong website. If you want two Wikipedia articles to be merged - presumably hypothetical star and list of hypothetical stars, or merely want to suggest a possible merger, you should follow the directions at WP:MERGE; but since one is a redlink, there's really nothing to do here. If you want two Wikidata pages to be merged - presumably d:Q5961276 and d:Q118591275 - see d:Help:Merge. --Redrose64 🌹 (talk) 14:42, 23 May 2023 (UTC)Reply[reply]
    His point is that the enwiki article "hypothetical star" should be renamed "list of hypothetical stars" cause the article is actually mainly a list. Simon Villeneuve (talk) 15:26, 23 May 2023 (UTC)Reply[reply]
    I made a proposal on Talk:Hypothetical star#List to rename this page.
    - Io Herodotus (talk) 16:11, 23 May 2023 (UTC)Reply[reply]
    That makes it a WP:RM matter, for which this is still the wrong venue. --Redrose64 🌹 (talk) 17:57, 23 May 2023 (UTC)Reply[reply]


    Ten years ago, galleries were updated. Whereas before, the only option for galleries was this:

    Now, you can choose from four other gallery modes, of which "packed" rapidly became the default.

    At the time, it was assumed that the default style - what would be used if no parameter was set - would likely be changed to packed after a while.

    We then... forgot about this.

    So, I propose that, perhaps after a bot is used to add a mode=traditional to all remaining unspecified galleries to minimise any potential disruption, that we go ahead and finally make packed the default. I'd also suggest making the default heights parameter for packed images be 200px, because, well that seems to be the default nowadays. Rare I see a gallery that's not mode=packed and a height around 180-250. I believe the default is still 120px, which is way too small for modern high-resolution monitors in pretty much every case (seen below)

    Adam Cuerden (talk)Has about 8.4% of all FPs. 05:32, 24 May 2023 (UTC)Reply[reply]

    Sounds like something that should be changed with a serverside configuration option, and not by making changes to thousands and thousands of pages. —TheDJ (talkcontribs) 12:29, 25 May 2023 (UTC)Reply[reply]
    • Support changing the default type to "packed" and default size to 200px, per nom. The traditional mode looks awful, with huge margins that decrease the size of the images themselves. I'd say that in 90% of cases, it's used only because it's the default. Regarding the details of implementation, to TheDJ's point, I'll leave that to technical folks familiar with the area. But disagreement about that shouldn't stop us from moving forward with the overall idea. {{u|Sdkb}}talk 19:20, 25 May 2023 (UTC)Reply[reply]
    • Support, though not sure how best to implement. This is overdue IMO. Garuda3 (talk) 20:07, 25 May 2023 (UTC)Reply[reply]
    • Extremely strong oppose I'm amazed at this proposal. I'd strongly deny that packed mode has become the default. It is common for articles on cities etc, but not for those on art, history etc. There was a lengthy discussion a couple of years ago (can anyone find it?) with various examples tested, which concluded that this was generally not a good option for art, especially because the images clash and "bleed" into each other. Can't you be bothered to find out what the default height now is? Please do so before proposing to change it. I agree it is too small, but so is the main default at 220 px. Much better to change that. Johnbod (talk) 03:49, 29 May 2023 (UTC)Reply[reply]
      Perhaps Talk:Paul Signac#Use of packed gallery? DanCherek (talk) 03:58, 29 May 2023 (UTC)Reply[reply]
      Thanks, that was it - the Rfc bit below. Note that this was a formal Rfc (which this should probably have been), that found no consensus to use "packed" at that article. The conclusion has often been extended to other art articles. Johnbod (talk) 04:06, 29 May 2023 (UTC)Reply[reply]
      I don't care what the default is; I care what it ought to be. The situation seems to be that pretty much everyone agrees that packed mode is best in many circumstances. For art articles, as at the linked RfC, it appears that (as of 2015) slightly more than half preferred packed and slightly less preferred the old mode with tiny images and gigantic margins. Nothing about that is persuasive to me.
      Note that this proposal would not change the gallery type on existing articles, e.g. it would not override the 2015 RfC. What it would do is change the default going forward. So if editors at a particular article want tiny images and gigantic margins in order to give images more "dignity", they will continue to be able to do so. But defaults are powerful, and editors should be steered toward the modern packed format by default. {{u|Sdkb}}talk 04:29, 29 May 2023 (UTC)Reply[reply]
      @Johnbod: This will, by no means, forbid articles from using a traditional style gallery, indeed, I even suggested that a bot could be used to add parameters to all galleries currently used that don't already have parameters to keep them in their current state.
      This is a discussion about what the default should be, a.k.a. what happens if a user just creates a gallery with no other parameters going forwards. It's not meant to override decisions on a particular article, it's meant to decide what should happen if no decision is made. Adam Cuerden (talk)Has about 8.4% of all FPs. 19:03, 29 May 2023 (UTC)Reply[reply]
      If we change the default state, that will affect all articles presently using a gallery with no options specified (and probably those with certain options specified). There's no "going forwards", it's retrospective. That is what default implies. --Redrose64 🌹 (talk) 20:42, 29 May 2023 (UTC)Reply[reply]
      @Redrose64, you're ignoring the suggestion of a bot, which Adam laid out clearly both in the proposal and directly above. {{u|Sdkb}}talk 20:53, 29 May 2023 (UTC)Reply[reply]
    • Support Tiny images that you can't see are no good. Excessive margins are no good. Leijurv (talk) 06:37, 29 May 2023 (UTC)Reply[reply]
    • Oppose per Johnbod. Visual art pages are a major user of galleries, and when Johnbod says that he's an 'Extremely strong oppose' then I consider that he's pretty much speaking for almost all of the editors who edit visual arts pages. Randy Kryn (talk) 23:47, 29 May 2023 (UTC)Reply[reply]
      @Randy Kryn and Johnbod: I don't think either of you are understanding the proposal: This isn't to disallow the current default style; it's to make it use <gallery mode=traditional>, instead of being the default when you just put in <gallery> A bot can readily be used to make sure that no pages change by adding that mode=traditional in to all galleries in use that don't have mode= set before we change the default over. Adam Cuerden (talk)Has about 8.4% of all FPs. 04:25, 30 May 2023 (UTC)Reply[reply]
    • Oppose, while I generally like packed mode, I don't think the convenience of not having to choose packed mode is worth the hassle and the breaking of the layout of old revisions. Templates could be used to achieve similar convenience without configuration changes. —Kusma (talk) 06:01, 30 May 2023 (UTC)Reply[reply]
      I'd argue it's not just about convenience, but rather has an effect on content. Editors, and particularly newer editors not versed in all the options, very often just go with the default. Retaining the old giant-margin format as the default means in practice that it will be used a lot more frequently. {{u|Sdkb}}talk 06:11, 30 May 2023 (UTC)Reply[reply]

    Putting captions in {{multiple image}} galleries in infobox[edit]

    There were some discussions in Wikipedia talk:WikiProject Cities about this, but I thought that a proposal here is more appropriate because a lot of articles outside of cities articles will be affected by this. Currently, here are two options for putting the captions in {{multiple image}} galleries in the infobox:

    It would be unwise to force all articles to follow either way to arrange captions in the infobox, but I think that there might be a consensus on what option is preferred in specific situations.

    Here are some advantages of both approaches:

    Option 1

    • Less confusing caption placement, no need for awkward "In clockwise" captions
    • Easier maintenance for editors

    Option 2

    • More compact, take up less valuable vertical space, especially for multi-line captions
    • Allow usage of custom galleries

    CactiStaccingCrane (talk) 08:02, 25 May 2023 (UTC)Reply[reply]

    Pinging people in the WikiProject Cities discussion: Dkriegls, Sdkb, WeaponizingArchitecture, Xeror CactiStaccingCrane (talk) 08:06, 25 May 2023 (UTC)Reply[reply]
    Whatever you do, avoid "clockwise from top left" as it becomes incorrect on narrow screens (at least in some skins). —Kusma (talk) 11:53, 25 May 2023 (UTC)Reply[reply]
    It's also not accessible. Always use actual order. —TheDJ (talkcontribs) 12:32, 25 May 2023 (UTC)Reply[reply]
    What do you mean by "actual order"? I get that it's not good if it can dynamically change (but then that's potentially an issue with any description, e.g. two lines of three becoming three lines of two) but if it can't (e.g. it's a single image file) what is wrong with "clockwise" if that is how they are arranged? Thryduulf (talk) 13:14, 25 May 2023 (UTC)Reply[reply]
    The order (in the document) of these images is left to right and top to bottom for each line. Like a (western) book. Clockwise is a visual description that goes left to right, top to bottom, right to left and then bottom to top. That does not match the document order and thus should not be used, as screen readers will only convey document order and it's also not resilient against reordering in different visualizations like for instance on mobile. —TheDJ (talkcontribs) 14:46, 25 May 2023 (UTC)Reply[reply]
    It's taken me a couple of times reading what you wrote, but I understand it now. Thank you. Thryduulf (talk) 20:57, 27 May 2023 (UTC)Reply[reply]
    • This seems a function of stuffing too many decorative images into the infobox, contrary to WP:GALLERY. A better option than either is not to create the problem in the first place. CMD (talk) 11:32, 25 May 2023 (UTC)Reply[reply]
    • New York City has ten! tiny infobox images. Four captions spill over two lines, and there's an extra empty line below each. The gallery alone takes more than one screen on my 7" smartphone (60% of readers come from mobile). One caption, three images max would be my recommendation in this case. Ponor (talk) 11:55, 25 May 2023 (UTC)Reply[reply]
      NYC should definitley be shortened WeaponizingArchitecture | scream at me 12:00, 25 May 2023 (UTC)Reply[reply]
      Personally I think that a picture of a skyline is enough. But people kept arguing that urban skylines are kinda samey, so let's add a notable place to the infobox. And another, and another, and another, ... CactiStaccingCrane (talk) 12:04, 25 May 2023 (UTC)Reply[reply]
      I perfer option 2 personally. I never found it too hard to grasp (this might be different for others), and i believe it makes the infobox look a lot cleaner (there's a noticeable gap between a caption and the image below said caption). WeaponizingArchitecture | scream at me 12:08, 25 May 2023 (UTC)Reply[reply]
    • I don't understand why we would want (or need) to say anything other than either option is allowed, because (as the OP notes) which is better depends on the specific situation. If one genuinely is preferred in some situations (and the OP gives no examples) then we don't need the guidance because it's already preferred. Thryduulf (talk) 12:08, 25 May 2023 (UTC)Reply[reply]
      I said so because there are many broad concept articles such as Physics or Ancient history that use a gallery because the subject it is talking about is too broad. Should these articles be treated the same as the consensus for galleries in city articles? CactiStaccingCrane (talk) 12:13, 25 May 2023 (UTC)Reply[reply]
      I think you misunderstand my comment - I'm not saying the consensus for one topic area should apply to another, indeed exactly the opposite - sitewide guidance should simply state that either option is allowed. It's completely irrelevant whether different types of articles most commonly use the same or different options, and equally irrelevant which options those are. If most e.g. city articles use e.g. option 1, then we don't need to say that option 1 is preferred for city articles, because that's the status quo. If a specific city article uses option 2 but someone would prefer it to use option 1, then either be bold or propose a change on the talk page. Thryduulf (talk) 12:30, 25 May 2023 (UTC)Reply[reply]
      Certainly not, especially if that would mean pressure to include such images where this isn't actually such a great idea. The article Chemistry wisely avoids starting with lots of somewhat-relevant images, while Physics displays a screenful of unexplained example images (at least on my phone) before even telling me what the article is about, and would be better without a lead image (in my personal opinion). Unifying this across all Wikipedia articles is at best an exercise in futility, but more likely actively harmful. —Kusma (talk) 13:57, 25 May 2023 (UTC)Reply[reply]
    • Cities are a better fit for infobox collages than many other articles, but they're often done poorly and overstuffed with too many images. I agree with Thryduulf that there's nothing for us to do at the pump here because it's contextual. However, the extra space that option 1 takes up is really a big cost, especially for infoboxes that are already overlong (as many of the ones with galleries are) — just how much longer they make the collage would be more obvious if the examples used the same city rather than different ones. Other factors that might influence which option is better are how obvious the images are and therefore how likely readers are to seek out the captions (if very likely, option 1 could be better), and whether or not it's possible to shorten all the captions to what will be a single line on most devices. Also, as an additional downside for option 1, I don't like how it breaks up the visual cohesion of the collage.
      And as I said at the last discussion, I think ultimately captions that appear on hover like the packed-hover gallery tag option could give us the best of both worlds. Is there any way to get that to work for {{Multiple image}}? {{u|Sdkb}}talk 18:04, 25 May 2023 (UTC)Reply[reply]
      The one thing I really care about with collages is that we not use just a single file, as this makes it more difficult to modify the set of images (e.g. if a new better option becomes available, or if one is deleted), and results in an inferior experience for readers (where clicking on an image does not make it full-screen but rather just makes the collage full-screen). {{u|Sdkb}}talk 18:09, 25 May 2023 (UTC)Reply[reply]
    • Avoid, or greatly reduce, collages/mosaics completely. Johnbod (talk) 02:25, 28 May 2023 (UTC)Reply[reply]
      Should be encouraging the reduction of images of this nature. Moxy-Maple Leaf (Pantone).svg 11:19, 29 May 2023 (UTC)Reply[reply]

    promotional phrase for Wiki - "You could look it up", from Yogi berra[edit]

    Dear Wiki: It occurred to me that an excellent promotional slogan for Wikipedia might be "You could look it up", one of Larry "Yogi" Berra's most notable quotes, made long before Wiki existed. The only problem I see for this idea might be name recognition - that if you know who Yogi was, you might well be close to my age (71 and counting). On the other hand, Yoogi's fame went beyond baseball.

    best regards, Allen Torino, Italy

    P.S. - don't add me to the fundraising mailing list; I'm already on it. AlienalWiki (talk) 19:58, 28 May 2023 (UTC)Reply[reply]

    This seems to be the default phrase already of anyone young enough to have been brought up in the Internet age, who include my children who are in their 30s. The days of interminable discussions in the pub about factual matters seem to be well and truly over. I'm a Brit, and not a follower of baseball, but I certainly know who Yogi Berra was. Phil Bridger (talk) 20:37, 28 May 2023 (UTC)Reply[reply]
    You may be old enough to remember, "look that up in your Funk & Wagnalls!" (For younger and non-U.S. Wikipedians, see Rowan & Martin's Laugh-In.) Donald Albury 21:58, 28 May 2023 (UTC)Reply[reply]
    Hey, we got it in the UK - twice, IIRC: once in the late 1960s, and again in the late 1980s. Sock it to me! --Redrose64 🌹 (talk) 22:51, 28 May 2023 (UTC)Reply[reply]
    Yeah, it got around. I even saw it on American Forces Vietnam Network. Donald Albury 23:21, 28 May 2023 (UTC)Reply[reply]
    "You could look it up" I think is more reliably sourced to the great Casey Stengel. Wehwalt (talk) 22:09, 28 May 2023 (UTC)Reply[reply]

    RfC at WT:GAN on changing GA criteria to require inline citations in all cases[edit]

    There is an RfC at WT:GAN on changing the good article criteria to require inline citations in all cases. Please comment there if interested. Mike Christie (talk - contribs - library) 12:08, 29 May 2023 (UTC)Reply[reply]