RfC: Removing "Clear the watchlist" from main watchlist screen
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.
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 • {C•X})07:42, 15 April 2023 (UTC)[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 • {C•X})07:42, 15 April 2023 (UTC)[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 • {C•X})16:25, 1 May 2023 (UTC)[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]
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 • {C•X})10:03, 15 April 2023 (UTC)[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]
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]
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]
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]
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 • {C•X})09:16, 17 April 2023 (UTC)[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
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]
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]
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]
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]
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]
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]
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 Albury11:54, 1 May 2023 (UTC)[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]
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 Albury19:47, 1 May 2023 (UTC)[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 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]
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]
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]
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]
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]
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 • {C•X})15:06, 2 May 2023 (UTC)[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]
(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]
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]
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). — xaosfluxTalk13:33, 5 May 2023 (UTC)[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]
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]
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.
@Maddy from Celeste:how do you want this done? From your close above, it seems you are saying it should also work when scripts are disabled, so that means that another script to hack it away won't be the answer. I suppose you can open a feature request on this asking for it to be removed in core. — xaosfluxTalk15:10, 30 May 2023 (UTC)[reply]
Feature request seems reasonable. I'm not super familiar with the tech side of things, and haven't filed a feature request before, so I'm not entirely sure what information to include and which projects to tag. -- Maddy from Celeste (WAVEDASH)11:19, 31 May 2023 (UTC)[reply]
RfC on establishing a biography infobox guideline
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.
There's nothing approaching consensus in favor of any of the proposal changes. While there was initial clash on the merits (and some unfortunate personalizing during an occasionally passionate discussion) the two camps seem unmoved after 30+ days. BusterD (talk) 00:05, 3 June 2023 (UTC)[reply]
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]
Current guideline
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
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)
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.
[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:
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.
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]
Survey (establishing a biography infobox guideline)
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)
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]
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]
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]
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]
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]
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]
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 (talk • contribs) 21:43, 2 May 2023 (UTC)[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]
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]
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]
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]
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]
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. – bradv02:04, 3 May 2023 (UTC)[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}}talk02:17, 3 May 2023 (UTC)[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]
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]
”readers expect them in biographical articles”: do you have any evidence for this? It’s a claim I see thrown around frequently, but to date no-one has given any rationale for the claim. An IB-less article may have hundreds of thousands of users, but rarely to I see a reader ask about a box, only an editor. - SchroCat (talk) 06:11, 3 May 2023 (UTC)[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 (talk • contribs) 15:14, 3 May 2023 (UTC)[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 (talk • contribs) 17:02, 5 May 2023 (UTC)[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]
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]
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]
@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]
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]
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]
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]
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]
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]
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]
And I don’t mean you individually, but the opposition camp in general. The dominant reasons are “it should be determined on a case by case basis” (why?) and “more rules bad”. Dronebogus (talk) 11:34, 31 May 2023 (UTC)[reply]
Oppose (establishing a biography infobox guideline)
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]
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]
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]
(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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
“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]
@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]
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.
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]
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]
7 of the last 106 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]
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]
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]
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]
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]
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]
@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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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}}talk02:37, 3 May 2023 (UTC)[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]
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]
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]
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. --Jayron3212:45, 3 May 2023 (UTC)[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 Fuchstalk00:05, 4 May 2023 (UTC)[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]
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]
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]
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]
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]
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]
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]
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]
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. ~ HAL33301:56, 10 May 2023 (UTC)[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]
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]
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]
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]
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]
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]
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]
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]
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) buidhe04:43, 25 May 2023 (UTC)[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]
It’s about two individuals. It wouldn’t benefit at the top. But I see no reason why each individual couldn’t have a separate infobox. Dronebogus (talk) 12:03, 31 May 2023 (UTC)[reply]
And what would you place within the infoboxes except their names and date of births? If you're proposing they be placed in #Early lives, this information has already been explained in the lead and the first sentences of their respective sections, so we'd be printing it three times. Anarchyte (talk) 14:34, 31 May 2023 (UTC)[reply]
This proposal lacks support to adopt, but the article in question would not be effected by this proposal. I wouldn't recommend an infobox for that article and this proposal wouldn't require one. However, for the articles that were mentioned in the proposal that haven't reached consensus, they'll ultimately come up again. I guess they will have to be village pumped to overcome the localized opposition. I haven't looked, but there's probably not too many articles left where this is happening so I guess this is how this debate ends. Nemov (talk) 14:57, 31 May 2023 (UTC)[reply]
The problem is that if you remove the subjectivity (and I understand the proposal says "recommended", but let's be honest), articles like Boulton and Park, which is a collective biography (and therefore falls under "For biography articles"), will end up with infoboxes shoehorned in by people that made no other contributions to the page and have in all likelihood not read the sources. Anarchyte (talk) 15:02, 31 May 2023 (UTC)[reply]
I understand your point, but that could happen today if someone creates a RfC about it. One of the common arguments against infoboxes in cases where they've been easily approved is "there's no policy on infoboxes." When I've brought infobox RfCs here a common statement is "you should create a policy for this so these RfCs quit happening." Well, here we are... Nemov (talk) 15:12, 31 May 2023 (UTC)[reply]
Oppose. Mostly per Johnbod, but others make good points. Better to leave this to the discretion of individual article editors. The desire for consistency between similar articles is not automatically a bad thing, but it shouldn't lead us to establish rules that are sometimes going to be in conflict with the best outcomes for particular articles. Mike Christie (talk - contribs - library) 14:39, 31 May 2023 (UTC)[reply]
Discussion (establishing a biography infobox guideline)
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]
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]
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]
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]
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]
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]
"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"? ThreeFour 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]
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]
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]
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]
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]
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]
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]
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]
@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]
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]
@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]
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]
@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]
"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]
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]
@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]
@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]
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]
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]
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]
@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]
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. --Jayron3218:29, 4 May 2023 (UTC)[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]
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. --Jayron3211:39, 5 May 2023 (UTC)[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]
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]
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]
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]
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. — Rhododendritestalk \\ 13:27, 3 May 2023 (UTC)[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? — Rhododendritestalk \\ 13:29, 3 May 2023 (UTC)[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]
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]
[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... — Rhododendritestalk \\ 14:27, 3 May 2023 (UTC)[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]
faux-Arbitrary break
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]
@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]
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]
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]
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]
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]
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]
Your vote called the majority of infoboxes trash and said they should never be recommended, which sounds pretty much like “infoboxes are always bad and should be discouraged”. That’s a far cry from your neutral take here. Dronebogus (talk) 11:38, 31 May 2023 (UTC)[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]
@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]
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]
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]
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 Disciple14:15, 5 May 2023 (UTC)[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]
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]
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]
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 Disciple16:42, 5 May 2023 (UTC)[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]
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 Disciple17:47, 5 May 2023 (UTC)[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]
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]
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 Disciple23:53, 5 May 2023 (UTC)[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]
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]
@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]
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]
There's clearly no consensus for this proposal. Does this need an official close for posterity sake or do we just let the RfC expire and then archive? Thanks for everyone's input on this proposal and for the editors who generously volunteered their time drafting it. Nemov (talk) 15:21, 31 May 2023 (UTC)[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.
Thanking administrators for blocks
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.
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 Jazztalk to me | my contributions19:00, 6 May 2023 (UTC)[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 Jazztalk to me | my contributions19:24, 6 May 2023 (UTC)[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 Jazztalk to me | my contributions19:28, 6 May 2023 (UTC)[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]
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]
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]
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]
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]
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]
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.) AddWittyNameHere23:06, 6 May 2023 (UTC)[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]
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]
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]
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]
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]
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]
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 Albury12:48, 7 May 2023 (UTC)[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]
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. -- GreenC15:10, 7 May 2023 (UTC)[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. —Cryptic15:29, 7 May 2023 (UTC)[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]
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]
@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]
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]
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]
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]
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]
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]
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]
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 Jazztalk to me | my contributions14:10, 8 May 2023 (UTC)[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]
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]
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]
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]
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]
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]
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]
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×g16:11, 8 May 2023 (UTC)[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]
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]
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 (talk • contribs) 01:18, 11 May 2023 (UTC)[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]
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]
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]
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]
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]
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
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.
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]
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)
Sounds like something that should be changed with a serverside configuration option, and not by making changes to thousands and thousands of pages. —TheDJ (talk • contribs) 12:29, 25 May 2023 (UTC)[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}}talk19:20, 25 May 2023 (UTC)[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]
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]
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}}talk04:29, 29 May 2023 (UTC)[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]
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]
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]
@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]
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]
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}}talk06:11, 30 May 2023 (UTC)[reply]
I'm fine with increasing the default size, and also finding ways to explain the many options available to new editors. Johnbod (talk) 15:02, 30 May 2023 (UTC)[reply]
I don't have one, but you seem to know everything, so what's yours? We should also explain the various options for fiddling with the sizes and shapes in "traditional galleries. Johnbod (talk) 03:12, 5 June 2023 (UTC)[reply]
I don't think there is a good one. Every explanation that we add contributes to banner blindness. The easiest system for newcomers is one that chooses a good option by default. Thus why I support the proposal. {{u|Sdkb}}talk01:55, 6 June 2023 (UTC)[reply]
I think new editors are likely to copy what they find elsewhere or to use buttons on their editor. Could various editors (Visual?) have gallery buttons that default to packed mode? I don't use edit toolbars so I don't remember what they can do. —Kusma (talk) 22:53, 5 June 2023 (UTC)[reply]
Support, the packed mode is obviously better for most uses. With the bot adding "mode=traditional" art pages will not be affected. Really, all current pages will not be affected. It's only new pages that will be affected, and those who like having a traditional gallery on a new page can have it easily enough (just add "mode=traditional") Smallbones(smalltalk)02:07, 5 June 2023 (UTC)[reply]
It's unfortunate that this proposal conflates two issues, "mode" and size. In the current default (whatever that is, which no-one seems to know) the images are too small, and the margins too wide. That could (and should) be fixed as a separate thing. I'd imagine packed mode has its own accessibility issues, with the images butted up tight. We should explore that aspect. Johnbod (talk) 03:12, 5 June 2023 (UTC)[reply]
Comment. There is also the issue of default size of images. WMF denied Wikivoyage's request to increase the project-wide default on image sizes, as that would add a server load of creating and storing thumbnails of most used images in that size. This implies default image sizes should not be changed by project, but for all projects using Wikimedia's servers. I don't know how common galleries are, but I suspect that the want for larger images is not restricted to galleries. Ergo, one should talk to the technical folks at WMF, and use their advice in getting forward, instead of passing a decision that cannot be implemented because the power is by other people. There should probably also be a discussion on Meta, where one should involve the other projects and language versions. –LPfi (talk) 09:43, 5 June 2023 (UTC)[reply]
As I understand it, it would actually be easier on the servers if they migrated wiki by wiki, starting with smaller ones (=fewer pages/fewer images), instead of switching everything all at once. (The problem isn't really disk space itself, but the need to re-parse everything all at once.)
Also, while the English Wikipedia is a huge challenge, I understand that it is feasible with some advance preparation. I wouldn't be surprised if they asked for all image sizes in the ~top 1,000 most popular articles (or even the top 10K) to be manually switched to the goal size weeks in advance, but it could be done.
BTW, slowly increasing the size from one to the next to the next is not at all desirable. If you want the default image size increased, this is definitely a "rip the bandage off" task. Think about the size you'll want ten years from now, remember that it will be a big change that will take people a few weeks to get used to, and switch straight to that. Whatamidoing (WMF) (talk) 19:50, 5 June 2023 (UTC)[reply]
At the moment (and for many years past) any fixed size above the default is highly likely to be reverted, whether it used the "upright" system or specifies fixed pixels. This I think goes beyond what MOS:IMGSIZE says ("As a general rule, images should not be set to a larger fixed width than 220px (the initial base width), and if an exception to this general rule is warranted, the resulting image should usually be no more than 400px wide (300px for lead images) and 500px tall, for comfortable display on the smallest devices "in common use" (though this may still cause viewing difficulties on some unusual displays).") but is the reality. That would need changing first. Johnbod (talk) 21:09, 5 June 2023 (UTC)[reply]
Of course. But I think we could set this temporarily, until the servers adjust. Other wikis have done it in the past to get bigger images by default, and while we are unique here, we aren't incapable. It would take a certain about of effort to warn the obvious folks (e.g., AWB users), but it's all feasible. A bot run with a clear edit summary usually works for "counterintuitive" changes to wikitext, and then run the bot again to remove all the |300px settings a month after the switch is made. The open question is: Do experienced editors want to request the change? If we do, the worst they will say is "no, not this year". Whatamidoing (WMF) (talk) 03:25, 6 June 2023 (UTC)[reply]
Putting captions in {{multiple image}} galleries in infobox
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:
Option 1, caption per image
Option 2, caption at the footer
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
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]
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]
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 (talk • contribs) 14:46, 25 May 2023 (UTC)[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]
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]
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]
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 me12:08, 25 May 2023 (UTC)[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]
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]
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]
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]
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}}talk18:04, 25 May 2023 (UTC)[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}}talk18:09, 25 May 2023 (UTC)[reply]
You're referring to the packed-hover thought, I presume? Packed-hover currently displays as "packed-overlay" for mobile, it seems. If we designed the feature well, we could handle those issues. {{u|Sdkb}}talk15:19, 30 May 2023 (UTC)[reply]
Article like Detroit with 11 files in the lead are a scrolling nightmare. New York City even worse ....15 files for 4 paragraphs of info....so long need to scroll 3 times before any prose....most will never even read the first paragraph before moving on - dataMoxy-02:12, 6 June 2023 (UTC)[reply]
promotional phrase for Wiki - "You could look it up", from Yogi berra
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.
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]
For example, there is a gap between #3 and #6. I think the algorithm should pick a random number between 1 and 276 and display #174 if the ad indicated by the random number doesn't exist. Additionally, ads to defunct things (like certain WikiProjects) should be removed. Aaron Liu (talk) 01:53, 5 June 2023 (UTC)[reply]
_-_Restoration.jpg)
Option 1, caption per image
Option 2, caption at the footer
11:19, 29 May 2023 (UTC)