Wikipedia:Village pump (idea lab)/Archive 48

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

Parallel Text Template

Should Wikipedia have a comprehensive parallel text template for language comparison, including a translation into English syntax? The Lord's Prayer has served in interlinear translations and language instruction for centuries, and more recently the Universal Declaration of Human Rights has been massively translated into virtually everything except, I think, Lojban. Which article does supply literal, syntactical translations into English. kencf0618 (talk) 19:13, 18 April 2023 (UTC)

Wikipedia should not have such material, however, the sister project known as Wikisource would probably be the best place to do such work. Here is the list of languages for the Lord's Prayer that exists in Wikisource. Here is the Universal Declaration of Human Rights. You can click the links next to the language in question to find the text of that document in that language. I hope that helps. --Jayron32 14:37, 19 April 2023 (UTC)

Binding optional recall capability

Hi all,

We have some known facts:

1. We have c.50 admins open to recall
2. Recall is currently completely dependent on that admin obeying their terms, as they cannot be compelled to be through an enforced process.
3. There is firm support for some mechanism of non-arbcom process, as seen in 2019.
4. There is no consensus as to a particular form of recall methodology

This proposal seeks provisional feedback on correcting issue 2, rather than attempting to find a magical process that covers everyone's desires and concerns with a general method.

Proposed Binding recall primary methodology

• Admins (et al) would purely be able to opt in to recall, as per status quo
• Admins opting in would have to specify one or more processes at Wikipedia:Administrators open to recall/Admin criteria
• Any listed process would then only be changeable with one month's notice at WP:AN. A recall process begun during this timespan (such as an RfC or RfA) that is ongoing when that notice elapses must conclude before any changes are made.
• The Bureaucrats are granted the authority to carry out the outcomes of a recall procedure, including desysopping.

Additional methodology notes

• 'Crats are also able to carry out related activities, such as if the recall procedure specifies that a Bureaucrat will close a recall discussion.
• Should an Arbcom case request be made and accepted, the admin may pause any community recall procedures, which will recommence after the conclusion of the arbcom case. — Preceding unsigned comment added by Nosebagbear (talk • contribs) 18:30, 5 April 2023 (UTC)

Comments and thoughts

• This is an interesting idea, and if it were proposed I'd probably support it on a "better than nothing" basis, but it does suffer from the same issue that recall suffers from now: the admins who opt in are almost always the ones who'd never need to be recalled. I imagine it'd get quite a few opposes along the lines of "recall is broken, and this is just putting lipstick on a pig" or something like that. (Also, I have a vague memory of something similar being unsuccessfully proposed in the past—it might be good to check.) If you do decide to propose it, you'll want to have answers to questions like "if there's a dispute about how to interpret someone's recall criteria, who makes the final decision—the admin, crats, the community, someone else?" As for There is no consensus as to a particular form of recall methodology, obviously there's some truth to that, but I still think there's some hope for reaching consensus: WP:DESYSOP2021 got to ~55% support, and a fair number of opposers were open to supporting a broadly similar proposal if the specifics were fine-tuned a bit. Perhaps what we need is for, say, a dozen editors (including some who have opposed previous proposals) to get together and try to negotiate a system they could all agree on; if successful, they could propose it to the community via an RfC. I think a lack of adequate workshopping is what's hurt some of the more recent community desysop proposals. Extraordinary Writ (talk) 21:26, 5 April 2023 (UTC)
• For context, a similar proposal was discussed as part of the 2021 RfA review: Wikipedia:Requests for adminship/2021 review/Proposals § Closed: 6A Binding recall criteria. isaacl (talk) 22:14, 5 April 2023 (UTC)

  Certainly that proposal shared many similarities with this one - however, it also presented quite a few differences, including prior signoff, worsening RfA, requirement to agree on "objective and enforceable" and so on. Many of the opposes were linked to those - and many weren't. Awareness of the issues it might face (plus Writ's correct note about the "lipstick on pig" potential complaints) are dominant in why I bought it to VPI first.

  To me, I think it stands a reasonable possibility of passing on a better than nothing basis if it isn't felt that it would make passing RfA notably harder. In this regard, it notably differs from the 6A proposal, because admins wouldn't be bound to eternity over recall criteria.

  Part of my reasoning for this was also because it could act as a good first step for community recall. A logical next step, if it passed, would be an updated and pushed "model process" (to replace the sample one from 2009). About 10% of the active admin corps and about 6% of the total corps have a recall procedure atm. Nosebagbear (talk) 23:10, 5 April 2023 (UTC)

• I get that some people want to recall some admins who under our current rulers don't merit a desysop. My suggestion to such people would be to try and clarify the additional criteria that you think should merit a desysop. We've recently lost about a hundred inactive admins by adding such tests as <100 edits in the last 60 months, so yes that strategy can get meaningful changes. If you think you can get consensus that a particular behaviour should result in a desysop, then if it requires judging people's actions try running an RFC "Arbcom should consider that admins found doing x merit a desysop", and if it is as clearcut as "must save >100 edits in the last 60 months" then you don't even need to involve Arbcom. One of the problems of some of the past desysop proposals is that clearly there is a desire to get rid of some existing admins, but without much openness as to what sorts of admins are being targeted. Changing the dialogue from "We want to get rid of some admins who Arbcom won't desysop" to "x is an offence or threshold that wouldn't currently merit a desysop, but we think it should" would clear the air. Maybe it would result in fewer admins doing x, maybe the community would be clear that there is a strong consensus for admins to continue to do x, at least provided they also did y, maybe it would result in all the admins who currently do x being desysopped or changing our behaviour. But at the least it would result in those admins who don't currently do x having the chance to think that "OK now I understand why some people want to get rid of a certain type of admin". You may even get a whole bunch of admins saying that they agree that x should be a brightline rule for admins. ϢereSpielChequers 10:57, 6 April 2023 (UTC)
• I support the idea of community recall. Astute readers will notice that I have not, however, declared that I'm subject to recall. Why the discrepancy? For much the same reason that while I'm a proponent of open source software, for a long time I declined to include an appropriate license with code I wrote because there were a bewildering array of possible licenses available and figuring out which one made the most sense was too hard. Plus fear of accidentally picking one which had unexpected consequences. What I'd like to see is all the admins who are open to recall (and I'll include myself in that set) get together and hammer out a process we can all agree to. Then I'd be happy to sign onto that. Once there's a single uniform process, it'll be a much easier target to entice/convince/cajole/berate/strongarm other admins into accepting. I'd be happy to make "Will you sign onto the Uniform Voluntary Recall Process?" a litmus test question I'd ask of all candidates. But a "general method" is a non-starter for me. -- RoySmith (talk) 15:33, 6 April 2023 (UTC)
• I think there should certainly be a community desysop process that does not waste the time of ArbCom. However, there are a few things that I think should also be the case (if they are not already):
  • Any administrator who resigns during an investigation into misbehavior shall not regain the administrator tools if consensus determines that misbehavior occurred, and must go through the RfA process again to regain the tools. If an admin loses the tools during this process provisionally, then they shall not regain the rights until any investigation into admin misconduct concludes.
  • Discussion of misbehavior and consensus for desysop shall start on the BNB. If there is consensus that there is misbehavior by that particular admin that might warrant a desysop then a request for desysop shall determine whether there is still consensus to keep the admin tools.
  • If there is no consensus (between 25% and 75% support for keeping admin tools) during that request for desysop then the issue may be referred to ArbCom. Also, if such misconduct is unsuitable for public discussion (such as if it involves confidential information), then the issue shall be referred to ArbCom.
  • During the request for desysop, the admin in question shall not use the admin tools except for the most uncontroversial of uncontroversial tasks, such as blocking and reverting blatant vandals and deleting pages needed for uncontroversial cleanup. Admins whose use of the tools is controversial shall have their rights provisionally removed until the discussion concludes.

Such process ensures that ArbCom is truly a last resort and avoids unnecessary bureaucracy with ArbCom. I don't think many admins would opt into a voluntary process, and I do not think we should waste the time of ArbCom when one of these admins does something incompatible with the tools. We can also have trial adminship and admin elections (in a similar manner to ArbCom and steward elections) where admins serve fixed terms rather than being admin forever. What are your thoughts on this? Aasim - Herrscher of Wikis ❄️ 21:11, 6 April 2023 (UTC)

I think your point about people who resign the tools temporarily in order to avoid scrutiny is already covered. We don't restore tools to those who resigned whilst "under a cloud". For the rest of your points, Arbcom is the committee we elect to handle things such as desysops. It isn't wasting their time to give them the sort of case that they were elected to handle. Sometimes they get very clearcut cases that they can quickly resolve by motion, sometimes they get complaints that merit a full case (these are the time consuming ones). If you want to design an alternative to Arbcom remember that for all their faults they can move very quickly when things really are simple, but they have the reputation of being much fairer than a mob with pitchforks, and yes that means that complicated cases can take time. We have a shortage of admins and it is very difficult to persuade new candidates to come forward, and that's despite what few RFAs we have often setting records for strength of support. If we want to solve the problem of too few people running at RFA, we should be judging any new desysop process on how fair it would be to all parties, not on how efficient it might be. You might also want to rethink that bit about between 25% and 75% - it is quite a wide band, but 75% is more than some candidates have when they pass RFA. ϢereSpielChequers 22:37, 6 April 2023 (UTC)

@WereSpielChequers Aren't RfAs with less than 75% support very unlikely to pass with consensus? Whatever the threshold for the RfA percentage to pass that is what I would have it for the desysop process. I just do not want to get so wrapped up in bureaucracy for what would be clear cut cases. Also to quote the WP:RFARB page: "A request for arbitration is the last step of dispute resolution for conduct disputes on Wikipedia." We already resolve by community consensus page bans, topic bans, interaction bans, and site bans. I see no reason how we can't use community consensus to resolve whether an admin should keep the tools or not. Aasim - Herrscher of Wikis ❄️ 14:04, 7 April 2023 (UTC)

75% isn't far from the current system - it is the top of the crat's discretionary zone. So yes we have had recent RFAs that have passed with a little less than 75%. But it was your 25% that I raised an eyebrow over. When it comes to clearcut cases Arbcom is surprisingly quick and unbureaucratic. That's the advantage of an elected committee with a remit that includes desysopping admins where necessary. If you want a process that is "less wrapped up in bureaucracy" than the current one then I suggest you look at some of the cases on Wikipedia:Former administrators/reason/for cause that were closed by motion When you've looked at them, can you be more specific as to what elements of those proceedings that you would remove as "wrapped in bureaucracy"? Remembering that one person's safeguards and fairness is another person's bureaucracy. ϢereSpielChequers 14:34, 7 April 2023 (UTC)

@Awesome Aasim - to respond to your suggestions: we'd actually have to tweak the CLOUD policy text, as it's determined on an attempt to resysop, but certainly I think that any attempt to avoid a recall procedure by resigning would be a clear indication of such!

Suggestions 2-3 are specifically about creating a community desysop procedure - that isn't what this thread is trying to do. A community desysop process needs a full workshopping based around what led to insufficient support last time. That was mostly about safeguards, or delays in the community expectations changing to match the new process, and such. The points may, or may not, turn out to be fundamental then - but they can't be included in this distinct "step 1" aspect.

Suggestion 4 - this is an interesting one. I think you meant it for a general community desysop process, rather than for everyone's individual recall processes. If the latter, then it might struggle - some of us have a "trigger aspect" (e.g. 5 editors) and then an RfC, which would work fine with that limitation. But others are just "15 people listing their names and I'll straight resign" - would 1 editor listing their name bar that admin from any actions? Seems unlikely to be wise. Nosebagbear (talk) 08:23, 9 April 2023 (UTC)

• Is there any reason why a desysop isn't handled through the same process as a community ban? It seems strange that the community can decide whether someone is allowed to continue editing, but the community can't decide whether someone is allowed to continue using admin tools. Thebiguglyalien (talk) 18:19, 7 April 2023 (UTC)

  I think we don't trust ourselves to be fair in the heat of the moment. We need admins to make unpopular decisions. We don't want them to worry that making a decision that is unpopular but correct will result in them losing their admin abilities. We also don't want the rest of us to be worrying that the number of unpopular decisions that can be taken is limited to the number of admins. WhatamIdoing (talk) 19:00, 7 April 2023 (UTC)

  There was also some discussion in the last big RfC that admins in different categories build up more hostility from doing their jobs than others (e.g. AE vs DYK admins), even if they avoid any singular unpopular action. It's not likely that those individuals alone would lead to being able to desysop someone, but there weren't any good suggestions for how to handle them breaking any process which otherwise would be close. Nosebagbear (talk) 08:27, 9 April 2023 (UTC)

• Meh Has there been a rash of admins backing out of the voluntary recall process? --Jayron32 16:26, 12 April 2023 (UTC)

• Good idea if it were well structured so that it's not a popularity contest or a mindless angry mob. But unless there were some (formal or informal) bifurcation of the admin role, this would be far too complicated. The basic current RFA criteria are just that be trusted with the tools, have competence in a few areas, and (unofficially) that have been mostly invisible. Most times I've seen where desysop is needed has been competence issues, either due to inactivity combined with that they got in back when it was easy. Eggregious conduct meriting a desysop is rare enough that I think arbcom can handle those. Handling tough cases like sanctioning experienced experienced editors or tough closes requires expertise in those areas that probably 80% of admins don't have. So just because one of the 80% blew it in a tough area doesn't mean that they can't meet entry level admin criteria to keep the tools. North8000 (talk) 16:48, 12 April 2023 (UTC)

• If an admin supported eugenics (sadly a practical scenario), there should be an easier way to request a community recall than the current process. It would also stop wasting the community's time with non-binding and heterogeneous "self-recall" processes that are mainly adopted by the more responsive admins in first place. I don't have a strong opinion on the specifics, and would support nearly any binding process as a step in right direction. Of course we need check and balance, that unpopular but necessary admin actions don't get jeopardized. ~ 🦝 Shushugah (he/him • talk) 07:46, 21 April 2023 (UTC)

Direct but hidden links to The Wikipedia Library proxies

In citations, we usually link to the DOI or to JSTOR or to similar other databases that are typically paywalled. What we do not do is link to WP:TWL, our own way around paywalls. For good reason: these links would be useless to the vast majority of readers. However, for other Wikipedians (I am thinking of GA reviewers or FAC reviewers) it would save a lot of time to have direct links via the TWL proxies. Could/Should we do something like we do for CS1/2 maintenance messages and include TWL links in our citation templates where appropriate, but only display them for users that choose to see them via user CSS? It could be super convenient. Or is this a daft idea that should never leave the Idea Lab? —Kusma (talk) 21:37, 1 April 2023 (UTC)

Great idea. One important thing to consider: how should it appear to those of us who opt-in? I would propose something like:

"FooBar". Archived from the original on 1 January 2000. <span class="The Wikipedia Library">Available at The Wikipedia Library.</span> Retrieved 1 April 2023.

HouseBlaster^talk 23:55, 1 April 2023 (UTC)

This seems really useful. I think Module:Citation/CS1 (ping to maintainer User:Trappist the monk) could actually automatically rewrite supported links to the Wikipedia Library proxy link, and show it as an addition for all extended confirmed users. I think this could also help improve visibility of the Wikipedia library. Galobtter (pingó mió) 00:38, 2 April 2023 (UTC)

If a structured url isn't possible for every case, e.g proquest might not work, then we could simply have an additional parameter for WML to store the separate urls. ~ 🦝 Shushugah (he/him • talk) 02:12, 2 April 2023 (UTC)

No doubt something could be done to incorporate wikipedia library urls as a parameter (|twl-url=) and it could be rendered hidden so that user css would be needed to display it. Doing so might cause pushback from the editing community because, if memory serves, wikipedia library urls are rather long. If there is a way to get an identifier-like value as is done for semantic scholar... compare:

|s2cid=144385167 → https://www.semanticscholar.org/paper/Molotov's-Apprenticeship-in-Foreign-Policy%3A-The-in-Watson/58fc040011fbf6b375ba53eac7bf6bf565838925

Short and unobtrusive would likely be an easier pill to swallow than the long url. Does wikipedia library support shortened urls?

There is no way for Module:Citation/CS1 to know that an editor has extended confirmed rights because the module runs before the article is cached as html; it is the cached html that MediaWiki serves to editors and readers. Personal css would be the only way for an editor to view the hidden wikipedia library link.

—Trappist the monk (talk) 11:55, 2 April 2023 (UTC)

Meta:WikiCite/Shared Citations would also solve this problem. ~ 🦝 Shushugah (he/him • talk) 00:28, 3 April 2023 (UTC)

Would it? How? I'm not going to hold my breath for shared citations to be done in my lifetime...

—Trappist the monk (talk) 00:39, 3 April 2023 (UTC)

Some (not all) TWL links are things like https://doi-org.wikipedialibrary.idm.oclc.org/10.1017/CCOL9780521871341 instead of https://doi.org/10.1017/CCOL9780521871341 that could be possible to generate automatically without manual input. —Kusma (talk) 10:31, 3 April 2023 (UTC)

Only if all doi and all jstor and all ... identifiers are available from the wikipedia library. Pointless to create a wikipedia library url from a doi that isn't available through the library. What to do when a source has both a doi and a jstor (or other) identifier? Which identifier prevails? What about sources that don't use an identifier? What do all wikipedia library urls look like?

—Trappist the monk (talk) 14:07, 3 April 2023 (UTC)

Indeed it is probably difficult to do this fully automatic, and we may need to specify either the full url or a switch that chooses either jstor or doi or (whatever) or a fully manual url. Samwalton9, do you have any thoughts on this? —Kusma (talk) 15:57, 3 April 2023 (UTC)

We could create a parameter that can be overloaded so: |twl=doi would fetch the value from |doi= and use that to build a url; similarly |twl=jstor, etc., or manual url: |twl=https://.... Keywords used would be the same as the identifier parameter names to minimize confusion; unrecognized keywords would cause an invalid parameter value error. Some sort of error message would be emitted when a valid keyword refers to an empty or missing parameter.

—Trappist the monk (talk) 16:21, 3 April 2023 (UTC)

That sounds like a brilliant way to do it. Should also easily allow future extensions. —Kusma (talk) 17:43, 3 April 2023 (UTC)

Can we not use {{if extended confirmed}} (or the corresponding HTML class, <span class="extendedconfirmed-show">)? HouseBlaster^talk 13:01, 3 April 2023 (UTC)

Doubtful. I haven't noodled out how that template works but were I a member of the group with wikipedia library access rights, and we could somehow implement {{if extended confirmed}}, I would not get the special link to the library because for me, this:

{{if extended confirmed|extended confirmed|{{em|not}} extended confirmed}} → extended confirmednot extended confirmed

returns: 'not extended confirmed'

So, that means that any editors with wikipedia library access who have sysop rights (and perhaps also those who have template editor rights) would not see the special link to the source at wikipedia library.

—Trappist the monk (talk) 14:07, 3 April 2023 (UTC)

Turns out that there are css classes for all of the editing rights so we could write:

<span class="extendedconfirmed-show templateeditor-show sysop-show">member of an appropriate user group</span>

member of an appropriate user group

But, that really should be qualified by user css so that only those editors who have the necessary rights and permissions and the desire will see the special link to a source at wikipedia library.

—Trappist the monk (talk) 15:14, 3 April 2023 (UTC)

@Kusma @Trappist the monk As I understand it it should be possible to automate the generation of these URLs, in a way that might be better suited to a gadget or user script, rather than manually entering the TWL URLs into the citation template data directly. URLs of the form https://foo.bar.com/path can be rewritten as https://foo-bar-com.wikipedialibrary.idm.oclc.org/path. You'd just need to know the list of URLs that TWL has access to, which we could look into publishing somewhere if someone wanted to move forward with this. Samwalton9 (WMF) (talk) 18:23, 3 April 2023 (UTC)

That would probably work in 90% of cases. If there is both a DOI and a ProQuest ID, what should the gadget do? Sometimes the DOI will work with TWL but ProQuest won't, sometimes ProQuest will work with TWL but the DOI leads to somewhere not covered by TWL. Or would the gadget only become active if there is a switch in the template? —Kusma (talk) 18:38, 3 April 2023 (UTC)

@Kusma Perhaps the gadget could present links additionally, rather than rewriting? That way you have to click a few times to figure out which one gets you through but at least you're not losing any options. Samwalton9 (WMF) (talk) 19:48, 3 April 2023 (UTC)

@Samwalton9 (WMF): I don't understand what the advantage of using a gadget/user script is here over hidden output from the citation templates: couldn't all the work be done at that level just as easily and perhaps easier than in post-processing? —Kusma (talk) 22:20, 3 April 2023 (UTC)

If I understand correctly, it would work automatically with all existing citations, without having to modify them. isaacl (talk) 22:27, 3 April 2023 (UTC)

Not with all. Many editors like to cite books just by ISBN. It might be easier to get people to accept an additional hidden TWL field than a redundant-seeming DOI. —Kusma (talk) 18:02, 4 April 2023 (UTC)

Sure, just for those with appropriate identifiers. To me, including information that is specific to the source alone and doesn't depend on a particular access method that might change in future would be more suitable as part of a citation. isaacl (talk) 20:50, 4 April 2023 (UTC)

The Zotero browser extension can also automatically rewrite proxy URLs. AntiCompositeNumber (talk) 23:19, 3 April 2023 (UTC)

+1, great idea. EpicPupper (talk) 23:49, 9 April 2023 (UTC)

Good idea. This should be something available for any registered account; this would also promote the existence of TWL to editors (many still don't know about it). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:39, 22 April 2023 (UTC)

Archive Namespace for refactoring help/historical

Create a new archive namespace which is not indexed by google, and is not part of the default wikipedia search.

This idea had genesis in a recent discussion (which I have misplaced) concerning help/ tutorials which overlapped or were out of date or were developed osperately on projects. There was no consensus on what to do, but it seems a shame to not keep all those pages.

An archive namespace would allow us to refactor/simplify the exisitng map of help and move historical essays somewhere else. This might allow us to create an article structure more suitable for context sensitive help/guideline access, Wakelamp d[@-@]b (talk) 12:37, 17 April 2023 (UTC)

I tend to think of page history as the historical record for out of date material. Revision history is typically not indexed or searchable (except via external tools like wikiblame). If there are some help pages that are no longer helpful, perhaps templates like Template:superseded could be applied, or failing that, just blank and redirect to a more helpful page (the history is still retained after turning a page into a redirect). Barnards.tar.gz (talk) 12:52, 17 April 2023 (UTC)

Wouldn’t this be similar talk page which often has further archive subpages? ~ 🦝 Shushugah (he/him • talk) 22:36, 21 April 2023 (UTC)

Talk page archives are first-class pages so are somewhat more searchable than page history, but I think the point is that there are a few existing approaches to archiving that mean there is probably no need for a separate archive namespace. Barnards.tar.gz (talk) 12:10, 22 April 2023 (UTC)

Completely remove the idea of a "minor edit"

The idea of a "minor edit" in Mediawiki (the software that runs Wikipedia) is a design mistake. Mediawiki should remove it entirely so that all traces of it are gone except for historical purposes. The problems with "minor edit" are manifold:

• the distinction between a minor and a non-minor edit is arbitrary and up to the user to decide
• the user is often unsure themselves how they'd classify their own edit
• other editors might (and would) often disagree
• obvious minor edits are often forgotten to be marked as such
• bigger edits are occasionally marked as minor (eg when an editor initially made a small edit but then went bigger)
• bigger edits might intentionally be marked as minor eg by vandals
• it's a bit rude to make people who like to copyedit constantly call their efforts "minor"

The idea that users can self-report edits that don't require review is outlandish. If anything, it'd be much smarter to allow users to flag edits that they think require review. But I think that all edits require review so the benefits of simplification of the editing process outweigh the pros of adding such flags. Of course there should be a "bot" flag and possibility others. I'm not saying flags are not needed at all. Just that our current usage of "minor edit" is pointless and needs major reconsideration. Jason Quinn (talk) 02:22, 9 March 2023 (UTC)

For reference, Wikipedia:Village pump (proposals)/Archive 177 § RfC: Disable minor edits on English Wikipedia is I believe the last large discussion on a similar proposal, where it was suggested that only rollbackers, admins, and bots should be able to flag an edit as minor, and by policy only when reverting vandalism. isaacl (talk) 02:39, 9 March 2023 (UTC)

I tend to agree with the editors in that RfC who pointed out that, while the minor flag is a weak signal when applied by a new user, it is more helpful when coming from an editor you know and trust. Barnards.tar.gz (talk) 08:41, 9 March 2023 (UTC)

Thank you for bring that past RfC to my attention. I have to say that RfC appears to have been poorly made. Literally no rationale was given leaving some to oppose with (meritorious!) "why?" comments. Plus in the absence of an argument to set the focus, many people brought an array of views that perhaps missed the point. It was also perhaps not the best idea to have two somewhat orthogonal concepts mixed together. A dissatisfying RfC for me. And kind of disheartening because it will affects and anchor future discussions like this one forever. Jason Quinn (talk) 14:41, 9 March 2023 (UTC)

As per RfC standards, the proposer started it with a neutral question. They then placed the rationale in their support statement. I wouldn't worry too much about long-term after-effects. Editors were commenting on how useful they found the minor edit flag; I think a discussion now or in the future will continue to be based on their experiences up to the point of discussion. isaacl (talk) 17:12, 9 March 2023 (UTC)

Some editors find it convenient to filter out long strings of humdrum edits (e.g. dash fixing with AWB) from contribution histories. Additionally at a recentish discussion about disallowing non-autoconfirmed users from marking edits as minor there was significant pushback because some participants felt it made vandals/spammers easier to identify as they often mark all their edits as minor. 74.73.224.126 (talk) 04:34, 9 March 2023 (UTC)

I agree with that last part. Maybe even making it an extended confirmed-only function ... Iskandar323 (talk) 07:27, 9 March 2023 (UTC)

There should be ways to filter out bot edits. I don't buy the experienced vs inexperienced editor arguments. I've been using the minor edit checkbox now for almost 20 years. I think it does cause editors to skip reviewing some of my edits. But I'd rather they did. My editing is not infallible and I too introduce occasional errors by mistake. I wish more eyeballs would review my edits. Maybe it's best if I don't mark my edits as minor anymore. Jason Quinn (talk) 14:41, 9 March 2023 (UTC)

@Jason Quinn both recent changes and watchlist have a built-in hide-bots option already. — xaosflux ^Talk 14:45, 9 March 2023 (UTC)

Hi, xaos. I know. My comment was intended to suggest that some kinds of filtering are valuable and we need to remain able to do it even if we remove the minor edit flag. I didn't mean to imply by "should be" that no such filtering currently exists. Jason Quinn (talk) 15:11, 9 March 2023 (UTC)

I would support its removal. I don't find it useful to screen out minor edits from my watchlist because it's too frequently misapplied. If it wasn't available, it would do away with user talk page and drama board kerfuffles about its misuse. From the viewpoint of a new editor, I would think "minor" meant I wasn't making a "major edit", which is the wp-wrong way to interpret it, so that's confusing. I think any perceived benefit to watchlist screening is negated by both unintentional and intentional misuse. Schazjmd (talk) 14:58, 9 March 2023 (UTC)

It took until I first ventured out of mainspace for me to realize that "watch page" wasn't the inverse of "minor edit". I also had no confidence in my contributions. So for 10 years I dutifully marked "watch page" for every edit that wasn't trivial c/e in the belief I was alerting "admins" to additions that needed reviewing. I found out even more embarrassingly recently that the star symbol wasn't a "like button". When I finally discovered my watchlist it already had like 800 articles... JoelleJay (talk) 00:40, 29 March 2023 (UTC)

When I was new, I thought that {{Cancer}} and [[Category:Cancer]] were two ways of writing the same thing, so I randomly removed one or the other whenever the navbox's name matched a category's name.

@Trizek (WMF), is the Growth team thinking about introducing new editors to their watchlists? Whatamidoing (WMF) (talk) 03:56, 31 March 2023 (UTC)

It is not on our roadmap. Wouldn't it be your team's responsibility as it is part of the post-editing? Trizek (WMF) (talk) 10:29, 31 March 2023 (UTC)

mw:Developers/Maintainers says that the Watchlist has been Growth's. In practice, I don't think any team has been thinking about it. Whatamidoing (WMF) (talk) 20:46, 6 April 2023 (UTC)

I never mark an edit minor for reasons stated. Marking an edit minor is to discourage the need to verify, which contradicts how Wikipedia operates. -- GreenC 14:59, 9 March 2023 (UTC)

@GreenC never say never? I'm assuming you didn't manually click minor - but that is the type of "minor" edit that I think is still useful to filter. — xaosflux ^Talk 15:33, 9 March 2023 (UTC)

I ceased marking edits as minor after being informed I wasn't following the "guidelines". Ah, okay. Why bother? Praemonitus (talk) 15:39, 9 March 2023 (UTC)

• I find it a useless feature, but apparently others do not. Useless to me, harmless across the board, and useful to somebody means there's no good reason to get rid of it. --Jayron32 15:41, 9 March 2023 (UTC)

  My thoughts are in agreement w/ Jayron. I do mark some edits as minor (e.g. removing unnecessary line breaks), tho. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 22:06, 9 March 2023 (UTC)

  There will always be people who think something is useful given a decent size user base. So "'Useful to somebody' implies a feature should be kept" is a very poor standard for software maintenance and development. It would effectively never removes anything and just allows cruft to accumulate. Instead software developers should constantly be asking, "Is this the way it it should be?". Plus, you are neglecting the negative effects of cruft on the rest of users. If a feature is useless to most but useful to a few, that does not mean it is harmless. Every UI element or every step/option in workflow adds complexity and that very complexity affects the usability of software. The minor edit option is something encountered upon first edits and adds yet another reason why a first time editor might get the "I don't know what's going on here" feeling and abandon their try. Plus it takes up space, and clutter is bad. Jason Quinn (talk) 10:25, 11 March 2023 (UTC)

• I support it being removed. I don't bother ticking the box myself because I don't see any value. Likewise, I ignore it when looking at other people's edits. From my experience at WP:SPI, I see it mostly used by miscreants as an attempt to avoid scrutiny. -- RoySmith (talk) 17:17, 9 March 2023 (UTC)
  • Perhaps instead the Pareto principle should be applied and we have check boxes for the top 3-4 edit categories? For example: fix spelling/grammar, add/repair link(s), warning tag(s), citation change(s). Praemonitus (talk) 18:14, 9 March 2023 (UTC)
    • This exists on the mobile app: they have "fixed typo, fixed grammar, added links" as buttons. Natg 19 (talk) 04:00, 29 March 2023 (UTC)
  • Misuse seems like something that would be easy to make backfire, at least sometimes. Couldn't we have a bot or somesuch that highlights edits that have a large byte difference but which are flagged as minor? That seems like a red flag for vandalism. Obviously that won't help when someone flags subtle date vandalism as minor, but it'd still be useful as far as it goes. EDIT: Blueboar has elaborated on this below; but we could automate it to an extent by somehow highlighting large edits that are flagged as minor, since that's a contradiction that bears further scrutiny. --Aquillion (talk) 19:37, 9 March 2023 (UTC)
• I find it useful - but for reasons that are exactly the opposite of the tags intended use. So many vandals and SPA editors check it (in an attempt to hide their nefarious/problematic edits) that I have learned to pay extra scrutiny to anything tagged as “minor”. In short the tag is a great way to identify nefarious/problematic edits. I would hate to lose that. Blueboar (talk) 19:19, 9 March 2023 (UTC)

  In that case, why not let IP's use minor edits? Sungodtemple (talk • contribs) 01:02, 2 April 2023 (UTC)

I'll skip over minor edits (by editors I trust) when reviewing a page history or on my watchlist, it saves me time. I flag my own minor edits as minor for the same reason. The list of problems can be summarized as sometimes people make mistakes with minor edits, or sometimes they don't use them as intended, or sometimes these edits start arguments. This is also true for non-minor edits. I don't think we should get rid of either. Levivich (talk) 19:24, 9 March 2023 (UTC)

The flag is useful but its name may be confusing. The definition of minor edit, whilst useful and correct, is not the obvious meaning of that term. For example, per WP:ME, "reversion of obvious vandalism" is a "minor edit", but I wouldn't class unblanking a page as minor.

All registered editors can mark their edits as minor. Should this be a revocable privilege, issued by default to all (or [auto]confirmed only) but removed from those who abuse it? Certes (talk) 22:04, 9 March 2023 (UTC)

That's an interesting idea, about making it a permission. Also, maybe rename it to "routine edit"? Levivich (talk) 04:29, 10 March 2023 (UTC)

'routine' is also subjective. If we're renaming it should be to something very specific like "formatting only", ('Mechanical editing' is probably the correct industry term, and has the benefit of starting with an m' JeffUK 08:06, 1 April 2023 (UTC)

I tend to use "minor" for anything that doesn't affect the meaning of the article body – e.g. I might get a large byte count from just converting a lot of bare-text footnotes to use cite-templates (so sfn/efn/harvnbs become possible) and then filling in empty fields (location, publisher, URL, ISBN/doi/etc.), but that's "minor" (and usually noncontroversial) in relation to the addition/deletion/move of the short word "not" to/from/among factual claims. – .Raven  ^.talk 06:07, 26 April 2023 (UTC)

I would support it being removed. It confuses me when I put in a new edit. And if I am making a lot of minor edits for cleanup purposes, I have to remember to check the box every time, which I don't because it's just another check box I have to check. Born25121642 (talk) 23:09, 9 March 2023 (UTC)

I think of the "minor edit" feature as something like an easily accessible edit summary and just as reliable as edit summaries in general. I would support removing all "hide minor edits" features from the default view, as whether an edit is marked as minor says nothing about whether it is minor. Better to rely on software detection than on user self reporting. —Kusma (talk) 10:47, 11 March 2023 (UTC)

I think this hits the key point. If we don't automatically hide minor edits, then none of the concerns of 'people using it to hide vandalism' will apply. Is there anywhere that we do hide 'minor' edits automatically? JeffUK 22:40, 28 March 2023 (UTC)

The default settings for Special:Watchlist hide minor edits. You can change this in Special:Preferences#mw-prefsection-watchlist (two-thirds of the way down the page). Whatamidoing (WMF) (talk) 03:58, 31 March 2023 (UTC)

I would absolutely support removing that default.. or making it much easier to configure. JeffUK 07:24, 31 March 2023 (UTC)

Agree, It's really pointless other than filtering. (which should really be an automatic thing like if its (+5) or (-5) or done by something like HotCat) It CAN be used for vandalism purposes, most of the time I forget to even flag it. ~With regards, I followed The Username Policy (Message Me) (What I have done on Wikipedia) 20:29, 27 March 2023 (UTC)

I don't think that it serves any purpose. Since you can't trust it, it needs to be reviewed, which removes it's reason for existence. North8000 (talk) 20:30, 9 March 2023 (UTC)

• I perform a lot of AWB runs in which I make edits that are really minor (e.g., adding missing spaces after commas or ref tags). I mark these minor by default. I would like to think the software will eventually get to the point where it can natively recognize that an edit is "minor" in this sense without any human choice being involved at all. BD2412 T 21:24, 9 March 2023 (UTC)
• I'd support removing it. If it were consistently used honestly, it would work, but it is not. I do not double check on editors I trust if they mark an edit as minor, but I don't check a trusted editor even if it not marked as minor. I don't think it provides the information it is intended to provide. SchreiberBike | ⌨  21:45, 9 March 2023 (UTC)
• Agreed, it's pointless. Its only use is the inverse of what was intended: some people attempt to hide bad edits by calling them minor, so minor deserve extra scrutiny. It also misleads novice editors who are nervous of claiming they're making a big contribution to Wikipedia when all they're doing is adding a new supporting reference, or a single sentence highlighting a new development in their field. They believe these edits are 'minor', which they are in terms of global authorship, but they're factual changes so they're major in Wikipediaworld. And then novice gets cautioned for misusing 'minor', which is scary and off-putting. Elemimele (talk) 17:42, 15 March 2023 (UTC)
• I agree it's more trouble than it's worth among the general editor population. There are a few valid use cases, though, e.g. allowing people to hide AWB edits in their watchlist and letting bots edit user talk pages without leaving a notification. Certes's permission idea is a good one, although I might make it available on request rather than a default. Extraordinary Writ (talk) 18:11, 20 March 2023 (UTC)
• "The idea that users can self-report edits that don't require review is outlandish" this statement is only true if you fail to assume good faith. In most cases, edits marked as minor ARE minor, and can be safely skipped over if trying to understand the content changes brought about by a series of good-faith edits by most editors. Conversely, a 3,000 byte edit marked as 'minor' is an excellent indicator of something that is more likely to need attention! JeffUK 16:06, 28 March 2023 (UTC)

  Assuming good faith does not mean that we should assume that every edit is equally beneficial to the encyclopedia. An editor can have all good intentions and still make mistakes, or not be aware of one or another point in our policies and guidelines. And we know from painful experience that some editors do not always edit in good faith. So, assume that an editor is editing in good faith until and unless the evidence shows otherwise, but do not assume that any edit is error-free and does not need to be reviewed. If I had the time, I would review every edit that shows up in my watchlist (I actually did do that for a while), but, as it is, with over 5,000 pages on my watchlist, I tend to skip over edits in mainspace made by editors I recognize. Donald Albury 18:19, 28 March 2023 (UTC)

  I'm the same, and for those editors who either I recognise, or see making good edits, I tend to trust that their 'minor' tags are appropriate and relevant; making the tag a useful indication of whether or not an edit has added content that may be likely to be challenged. JeffUK 18:36, 28 March 2023 (UTC)

  But, I think all my edits should be reviewed. I am terrible at proofreading my own work, and it has taken me up to six years to discover errors I have made.[1] Donald Albury 18:55, 28 March 2023 (UTC)

  And a few minutes ago I saw that an IP had just corrected a couple of capitalization errors I had made eleven years ago. Donald Albury 19:48, 28 March 2023 (UTC)

  I don't understand how removing the 'Minor' flag, as is proposed here, either helps or hinders that happening in the future. JeffUK 22:38, 28 March 2023 (UTC)

• I oppose the general removal of the “minor edit” button. Maybe I am in the minority but I do use it for routine correcting of typos (often my own) and others should have that option if they so choose. I do like the idea of revoking this button from those who abuse it. Frank Anchor 03:03, 29 March 2023 (UTC)

  Part of me is conflicted because I do TRY to mark an edit as "minor", and it'd be stupid if it was an autoconfirmed-only option (considering most of the constructive edits from IPs are probably spell check or capitalization), and revoking access because of abuse is frankly too much hassle than it's worth. See minor edits work on paper, if you give it to a majority of active Wikipedians it'll be used correctly, but like Wikipedia's main page slogan says "Wikipedia, the free online encyclopedia that anyone can edit" the fact anyone can edit makes it the largest encyclopedia, but that also means anyone could abuse this, sadly because of vandals a decent feature might be taken away from us. ~With regards, I followed The Username Policy (Message Me) (What I have done on Wikipedia) 05:05, 31 March 2023 (UTC)

  IP Users cannot mark their edits as minor, it's only available to registered users. JeffUK 07:58, 1 April 2023 (UTC)

• The minor feature gives an excellent indicator of whether a particular contributor should be supported (because they understand the simple concept) or should be eased out (because they can't follow even a simple suggestion). Johnuniq (talk) 05:43, 31 March 2023 (UTC)

• Remove, the different filters like bot or small/large edits would be better off with explicit filters for bot activities and or small/large edits. As long as it does exist, I do mark my edits as minor where applicable, but I have no reason to trust the veracity of other people's edits whether due to bad faith or simply difference in interpretation. Is adding one citation a minor edit? I certainly do not think so, but many other editors do. Removing this flag would simplify the ambiguity. If more explicit filtering/tooling can help, let's work on those, but the minor flag causes more confusion and headache than its existence is worth. If the minor flag exists for bot/certain conditions, I would be fine with that too. ~ 🦝 Shushugah (he/him • talk) 01:36, 2 April 2023 (UTC)
• I get that some people simply ignore the minor edit button and flag. Fine, you do you. Others have no problem using it and even see a use for it (yes a lot of my edits are minor). ϢereSpielChequers 20:39, 8 April 2023 (UTC)
• Nothing is wrong, leave it alone. The minor edit flag is a humane feature intended to give a hint to the reader of what to expect if they look into the content of the edit. If you're interpreting it as anything more rigid than that, you've completely missed the point. The OP writes: it's a bit rude to make people who like to copyedit constantly call their efforts "minor" - literally nobody is saying that. As has been noted multiple times above, you're not required to use the feature, or even pay attention to it.  — Scott • talk 12:00, 17 April 2023 (UTC)
• I'm of the mind that there are no minor edits. That said, if it serves as even a minor anti-vandalism tool, keep it. kencf0618 (talk) 18:31, 18 April 2023 (UTC)
• I've been flagging edits as minor when appropriate for a mumble long time. I do it for two reasons: (1) when I correct a typo, punctuation or a grammatical mistake which I consider minor; & (2) I make an edit I don't care whether it is reverted. Many times I flag it for both reasons. I would be disappointed if that flag were removed. -- llywrch (talk) 21:54, 18 April 2023 (UTC)
• Modify Whilst I myself find it useless for my use-cases, it seems others have a use for it so it's deletion as a whole seems temerarious. That being said, perhaps a restriction of what edits could receive minor status, or a small disclaimer that appears when you go to mark and edit minor that doesn't see, to be minor; would be useful to bridge the gap and address some of the concerns here? Mr.weedle (talk) 05:28, 26 April 2023 (UTC)

Fair Use on Commons

I would ask it on Commons but the licensing there is strict for good reasons, however on enwp we allow fair use images under certain criteria’s but it is a mess when multiple language editions of Wikipedia want to use the respective image in their local wiki. History is lost etc… is there a reason we don’t have a shared medium for hosting fair use images that can only exist if they’re used in one or more wikipedias with detailed rationale? ~ 🦝 Shushugah (he/him • talk) 22:27, 15 April 2023 (UTC)

@Shushugah Good question; I think the reason for no shared medium is that each wiki has to respect for the American and their own law. So even if we had a shared wiki hosting fair use, it would not help. For example, pl wiki is afraid to use fair use because of Polish law issue, and it's not like them being hosted on Commons or some Fair Use Commons would help. That said, for the wikis that do allow fair use, some sort of shared wiki might be good. Out of curiosity: what wikis other than English allow fair use images? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:35, 22 April 2023 (UTC)

I think the challenge will remain the same way either, but we could for example allow an opt-in per Wikipedia language edition, so that Polish Wikipedia would never be an option. Some languages like English, French, German, Spanish cannot be mapped to a specific country anyhow. But looking at Category:All non-free logos I see at least 10 Wikis, and scrolling thru random editions of Real Madrid CF I see many more language editions like Hindi also have a fair use logo of the FC Real Madrid team. The benefit would be...cleaner maintenance/deletion of images. Commons itself is not build for multi-lingual collaboration which is even more important with copyright disputes. Making a new tool that is more like Wikidata but for images...would help I think. ~ 🦝 Shushugah (he/him • talk) 10:03, 22 April 2023 (UTC)

@Shushugah I concur with your assessment. Not sure how to advertise your idea better, although I'd encourage you to link this discussion from some related WikiProjects, and from Commons, perhaps? _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:54, 22 April 2023 (UTC)

See also m:NonFreeWiki. GZWDer (talk) 12:48, 26 April 2023 (UTC)

Infobox scientific domain

What does everyone think about having a template infobox on a scientific domain? Examples I'm thinking of are:

1. Physics
2. Mathematics
3. Chemistry
4. Biology
5. Economics
6. Linguistics
7. Anthropology
8. Political science

But it could also be useful (or a separate one) for sub-domains, e.g.

1. Electrical engineering
2. Computer science
3. Artificial intelligence
4. Marine biology

I'm keeping in mind here also that these infoboxes are used by search engines for their knowledge graphs. Bquast (talk) 16:36, 21 April 2023 (UTC)

@Bquast: You might want to move this discussion to one of the village pumps. ☆ Bri (talk) 17:26, 21 April 2023 (UTC)

@Bri if you think that is best, could you please help. I wouldn't know the best one (proposals / idea lab). I'm also not sure how I should technically do this (copy paste?). tnx for your suggestion Bquast (talk) 12:19, 22 April 2023 (UTC)

At least some of those articles have a navbox. For example {{TopicTOC-Physics}}, {{Math topics TOC}}. ☆ Bri (talk) 13:58, 22 April 2023 (UTC)

Note: This conversation was moved from [[[Wikipedia talk:Wikipedia Signpost]] in this series of edits. Graham87 12:07, 23 April 2023 (UTC)

General navboxes tend to be clutter, rather than useful for readers.

As for the specific list, did you know that several of those aren't really sciences? Linguistics, for example, opens with essentially a disclaimer that the field uses a non-standard definition of science when it labels itself a science. If a "comprehensive, systematic, objective, and precise analysis of all aspects" of a subject is all that's necessary for something to be a science, then we will have the science of fashion, the science of poetry, and the science of which fork to use first at an official dinner.

If you want to make a list of sciences, you need to figure out which definition of science you're using. I favor a definition that includes progressivism (the idea that we know more about the subject in the 21st century than we did in previous centuries). This definition includes physics and excludes linguistics (also anthropology, political 'science', history, religion, art, etc.), because we really do know more about physics than we used to, but we do not know more now about ancient languages than the people who used those languages. WhatamIdoing (talk) 16:08, 24 April 2023 (UTC)

Linguistics studies language, language studies studies languages. (Though apparently language studies redirects to linguistics?) We do know more about language today than in previous centuries, even if we've lost the details of several languages. small jars tc 10:47, 25 April 2023 (UTC)

Studying something doesn't make it Science.

We know both more and less about language than we used to, which means that the field is not progressive. Some sub-specialties might be (perhaps theoretical linguistics? I don't know enough about how that field studies its subject to form even a tentative opinion), but the field as a whole isn't. WhatamIdoing (talk) 00:30, 26 April 2023 (UTC)

I can't think of any subdomains that are not better understood in the present day: Syntax? Check. Semantics? Check. Morphology? Check. Phonetics? Check. Even the various concerns of applied Linguistics (education, NLP, translation, etc.) all seem to be developed. But I still don't think linguistics is a science, so I don't like this "progressivism" definition. small jars tc 13:14, 26 April 2023 (UTC)

References

Proposal to establish merge review process

I've noticed that despite tons of articles that are in the process of being merged, a vast majority of merger projects have been dormant for at least a year. To be frank, I believe that the reason for this is because several people, myself included, feel that some of these merger proposals shouldn't have been accepted, and would like to contest them akin to a move review or deletion review. The problem is, I couldn't find a process to do that, which leads me to belive such a thing doesn't exist. I therefore propose that a merge review process akin to those regarding moves and deletions be established. 100.7.44.80 (talk) 15:08, 25 April 2023 (UTC)

I don't know that reviewing the closes will help all that much with the backlog. I've been working at Project Merge for several months, and the holdup that I see is...it's way easier to suggest a merge and apply the templates than it is to actually complete the merge. Sure, there are a few listed that I don't think should be merged, but lots of them just need someone who will come in and actually do the work. Joyous! Noise! 20:42, 26 April 2023 (UTC)

Kinda late to the party. I've taken the discussion here. 100.7.44.80 (talk) 23:15, 26 April 2023 (UTC)

I initially suggested this at the Administrators' noticeboard, but was told to go here or to The Proposals instead. 100.7.44.80 (talk) 15:23, 25 April 2023 (UTC)

We effectively already have a "merge review" program. You will find it at Wikipedia:Splitting.

NB that the main difference is that the existing process allows you to re-litigate the whole thing from scratch. A typical "review" process only allows you to get opinions about whether the person summarizing the discussion was patently unreasonable. WhatamIdoing (talk) 00:34, 26 April 2023 (UTC)

Except that page isn't for contesting accepted merger proposals. Rather, it's for proposing splits. 100.7.44.80 (talk) 13:14, 26 April 2023 (UTC)

...which is basically the same thing. WhatamIdoing (talk) 00:18, 30 April 2023 (UTC)

Why don't we have a single go to location for close reviews? Rather than having a page for deletion reviews where the same editors always comment and a page for move reviews where the same editors always comment, we have a single page (WP:Village pump (close reviews)?) where these and other closes, including merge closes and RfC closes, can be reviewed? BilledMammal (talk) 00:44, 26 April 2023 (UTC)

Honestly, that might not be such a bad idea. 100.7.44.80 (talk) 13:15, 26 April 2023 (UTC)

That does seem like a good idea. Creating a single venue to get an evaluation of discussion closing of all types would likely attract more eyes to all such discussions. I'm not opposed to something like that. --Jayron32 15:23, 26 April 2023 (UTC)

I also think it is a great idea but I would call it Wikipedia:Close review and include deletion review, move review and Administrative action review. Additionally it could also review merges, splits, RFCs and other discussion closes. Lightoil (talk) 07:40, 27 April 2023 (UTC)

So such a review page would be beneficial in the sense of being easier to find and gathering more eyes. The negative is that splits encourage speciality. I have little interest and less skill in move requests. But at DRV I can offer a useful perspective. Such a move should also consider before proposal how things like the archives would be handled. Nosebagbear (talk) 08:45, 27 April 2023 (UTC)

Anybody else think we should move this section to (or at least continue the discussion at) the Proposals page? 100.7.44.80 (talk) 12:42, 27 April 2023 (UTC)

• Moral support - Agree with the people above who say that it is much easier to propose a merger than it is to carry one out, and this is the crux of the problem. I think a big part of the issue is that people propose mergers as a compromise solution at AFD when in fact there is no either no reliably supported content to actually merge or the result is WP:TOOLONG, leaving a difficult task to the person tasked to carry out the merge. In many cases, what really should have been done is a straight-forward keep/redirect/delete. I have no idea how to fix this though. FOARP (talk) 10:36, 28 April 2023 (UTC)

Would it be feasible to automatically search unreferenced article histories for references?

A significant number of articles in Category:All unreferenced BLPs used to have a reference that at some point got removed by clueless IP editors. Would there be any way to do a search that checks the history of each article in that category and identifies if there was ever a cite template so that it can be restored? With 2,000 articles in the category, checking each history manually would be rather demanding. Thebiguglyalien (talk) 14:32, 29 April 2023 (UTC)

Easiest way might be to use Special:Export to export the articles with all history (but don't bother including templates), load it up in a text editor, and search for cite templates or <ref or whatever. Slightly more complex would be to write code to parse the export to do the same thing and print the relevant info. Anomie⚔ 15:06, 29 April 2023 (UTC)

A bot, whose name escapes me, seeks and reinstates certain types of deleted reference. I'm not sure what criteria it uses to avoid restoring bad references which were correctly removed. It's possible that I was thinking of InternetArchiveBot, which does something similar but different, but perhaps someone else can fill in the details. Certes (talk) 16:12, 29 April 2023 (UTC)

Why look for citation templates? Why not look for URLs and ref tags? Templates didn't exist at all in Wikipedia's earliest days, and citation templates were relatively unpopular for a while. If you look only for citation templates, you'll miss other citations.

(Also, I think this is the kind of thing that is done via database dump, not bot.) WhatamIdoing (talk) 00:27, 30 April 2023 (UTC)

@Certes: You seem to be thinking of the OrphanReferenceFixer run by AnomieBOT. Graham87 12:06, 30 April 2023 (UTC)

Yes, quite probably. Thanks. Certes (talk) 12:17, 30 April 2023 (UTC)

The criteria for AnomieBOT are simple enough: If a named ref exists without being defined anywhere in the article (i.e. it's an "orphaned" named reference), the bot tries to find what it's supposed to be referring to and updates the orphaned ref with that content. It doesn't add or re-add any references, it just fixes orphans. It doesn't do anything to try to determine if a reference is "bad" or not, on the assumption that a clueful human would have removed all the orphans if the reference really was bad, or will at least be watching the article and will notice the bot's edit if they accidentally missed one. Anomie⚔ 12:28, 30 April 2023 (UTC)

I bet a significant number were also removed by clueless registered editors. The problem with a bot is that it is (with the current state of AI, and, even if that is improved, for offline sources) practically impossible for a bot to tell whether a reference is valid. Phil Bridger (talk) 12:24, 30 April 2023 (UTC)

Idea: Mass conversion of WikiProject banners

I'm currently in the process of adding the recently implemented broad class ratings for {{WikiProject Banner Shell}}. I got some done, but with all the articles that we have on Wikipedia, it would be laughable to assume that a single editor could do it. So I was thinking of two things:

• Option I - develop a bot to mass convert banner shells, kind of like a User:Conversion script II
• Option II - assemble a provisional taskforce dedicated to editing these templates en masse

I would like to hear your thoughts on my proposal. - Knightoftheswords281 (Talk-Contribs) 16:07, 17 April 2023 (UTC)

I would assume that the people hard at work at Template talk:WikiProject banner shell are aware of this issue and have some plan for implementation. Thebiguglyalien (talk) 17:52, 17 April 2023 (UTC)

@Knightoftheswords281, I see you have been implementing this on your own. Please don't set up the banner shell to collapse the list of WikiProjects on high-level topics such as Talk:Engineering and Talk:Health. Hiding the projects defeats the whole purpose of having projects listed on talk pages. StarryGrandma (talk) 00:37, 19 April 2023 (UTC)

@StarryGrandma, I'm not sure that the community agrees on what "the whole purpose of having projects listed on talk pages" actually is, but I believe that the common rule of thumb is to collapse if there are more than three projects listed. WhatamIdoing (talk) 00:06, 30 April 2023 (UTC)

@WhatamIdoing, I'm not sure the community agrees that there is a common rule of thumb about collapsing the projects. The discussion at Wikipedia:Templates for discussion/Log/2021 January 8#Template:WikiProject banner shell found no consensus on autocollapsing for a particular number, but that there was support for the 4 to 6 project range. With so many things now being added to talk page headers, it hard to see how a few projects makes it much more cluttered. StarryGrandma (talk) 06:53, 30 April 2023 (UTC)

@WhatamIdoing, on further thought, are you thinking about the rule of thumb by which we collapse the project entries down to just the names of the projects if there are several on the page? This discussion is about the new project banner with an overall project rating. When collapsed the names of the projects are no longer visible. Someone coming to a talk page no longer sees which projects are involved unless they notice this small entry and expand it. StarryGrandma (talk) 15:42, 30 April 2023 (UTC)

Talk:Health has five WikiProjects listed. Some editors believe that these templates should be collapsed when there are more than three projects (i.e., 4+) WikiProjects listed. You don't. There's no firm requirement, but other editors aren't wrong to follow their preferences, just like you're not wrong to follow yours. WhatamIdoing (talk) 16:32, 30 April 2023 (UTC)

Be able to mark a source as permanently dead in the reference dialog in the visual editor

It looks like users currently must switch to source mode to add that a source is dead and that a fix was attempted. When the tag is added in the source editor, the UI for editing citations in the visual editor becomes completely different.

Is there anything discussing this? I'm not sure if this is the right place to post this, so please direct me if needed! Pneen (talk) 01:45, 1 May 2023 (UTC)

Make an "Add to Library" option

Adding a page to your Library means it will appear on the left hand side of your account under "Languages". This is then a shortcut back to the page at any time or you can simply remove from Library and it will disappear. This will make it easier for the user to re access any articles relevant to them 2A00:23C5:C32F:7901:C0A9:DFF:FED6:1A2C (talk) 13:27, 29 April 2023 (UTC)

Would the user not be better served by their browser's bookmarking/favouriting feature? Barnards.tar.gz (talk) 13:35, 29 April 2023 (UTC)

Often these can be forgotten about and become hard to find. If you can access ypur library with a click, ypu can easoly find any articles you had previously marked 2A00:23C5:C32F:7901:C0A9:DFF:FED6:1A2C (talk) 13:57, 29 April 2023 (UTC)

If you are referring to the Wikipeida Library, access is restricted to users who have been registered for at least six months and have made at least 500 edits total (and ten edits within the previous month) to Wikimedia projects. There would be no point to displaying a link to the library if those conditions are not met, and it would require building the logic into the user login process. Donald Albury 13:38, 29 April 2023 (UTC)

No I'm referring to anybody who has a Wikipedia account, using the library as a shortcut back to articles of interest to the reader 2A00:23C5:C32F:7901:C0A9:DFF:FED6:1A2C (talk) 14:02, 29 April 2023 (UTC)

IP editor, what functionality would you foresee this feature having that is not already implemented in Special:EditWatchlist? Folly Mox (talk) 00:20, 30 April 2023 (UTC)

The official apps have a reading list feature. WhatamIdoing (talk) 00:24, 30 April 2023 (UTC)

The Android app includes a Reading List feature. -- Random person no 362478479 (talk) 00:32, 30 April 2023 (UTC)

I do like this feature, and it would be nice if it connected with the website/across devices (for instance, my reading list does not sync between my phone and tablet). Nerd1a4i (they/them) (talk) 03:32, 1 May 2023 (UTC)

Asking for sources for AfC drafts

When users submit their completed drafts for AfC review, it could be a good idea for a prompt that asks the user for 2-4 of the strongest sources in the draft that establish notability. A feature of this ilk will be particularly helpful for drafts that are ref bombed. ––– GMH MELBOURNE TALK 03:56, 13 April 2023 (UTC)

I really rather like that idea. It would reduce both the number of disappointments where people try to write articles about subjects without appreciating that sourcing is necessary, and it would also avoid the ref-bombed things with 25 pretty useless sources.

But it would be more honest to require 2-4 freely-available online sources, preferably in a language that Google Translate doesn't mangle. I disagree with this requirement vehemently, but my practical observation is that no AfC reviewer is going to accept anything (or even look at it) unless they can check the sourcing in person. And since they're volunteers not necessarily fluent in Albanian or with access to a legal deposit library this means your article doesn't stand a snowball in hell's chance of being accepted if it relies on paper sources, paid-for material, or uses general referencing, despite these all being theoretically acceptable. Reviewers need to be pointed directly at something they can look at with minimal effort, that confirms the article is accurate and based on independent sourcing, otherwise they're (understandably) not interested. This is a bit of a bee-in-my-bonnet subject, but I think it's very off-putting to new editors if they never get their work accepted even when apparently they've followed the rules. We should avoid raising false hopes. Elemimele (talk) 18:04, 13 April 2023 (UTC)

I agree, @Elemimele.

On a related note, I've wondered occasionally about whether we could replace Wikipedia:Requested articles with a structured-data system. Imagine that instead of adding something to Wikipedia:Requested articles/Business and economics/Companies (a free-form wikitext page), you are sent to a Wikidata-connected form that asks things like:

• Name of company (free form)
• Location of company (using Wikidata here, to make sure that we get a real place)
• Website of company
• List of independent sources
• When was it founded?
• Does it still exist?
• What kind of business/industry is it? (e.g., technology, entertainment – a drop-down menu might be useful here)
• Is it for-profit or non-profit?
• Is it listed on a stock exchange? Which one? What's the ticker symbol?
• How many employees?
• Is there an existing Wikipedia article for any of the key people?
• Does it have a non-copyrightable corporate logo that has already been uploaded to Commons?

and so forth. Wikidata has a much broader notion of notability than enwiki, so if we were careful (and didn't want to include "Write one sentence that says why this business is especially significant, unique, interesting, or otherwise worth a volunteer's attention"), the whole thing could probably be stored there, and WP:REQ could get either a simple link to the Wikidata property, or a quick, infobox-in-prose summary^[1] to start off any interested editor.

^[1] Imagine that where we now hope to see something like "Acme Flypaper – flypaper manufacturer", we would instead see "Acme Flypaper (official website) manufacturing business in flypaper in Lake Woebegone, USA, AFP on New York Stock Exchange, 150 employees". WhatamIdoing (talk) 20:14, 13 April 2023 (UTC)

I guess we're getting a bit off topic here, but you've piqued my interest: why don't we use "Write one sentence that says why this [subject] is especially significant, unique, interesting, or otherwise worth a volunteer's attention"? I think the reason most editors avoid RA is that worthwhile topics there are like needles in haystacks, and that suggestion would certainly make the needles stand out more. Extraordinary Writ (talk) 22:51, 15 April 2023 (UTC)

This seems like a good idea to me. This could be an optional thing we could ask submitters do, with the explanation that this would mean they would probably receive a decision quicker. I would start a discussion at Wikipedia talk:WikiProject Articles for creation about this. Galobtter (talk) 17:59, 18 April 2023 (UTC)

Who runs Requested Articles? Yes, it'd be brilliant if the system at least offered the person making an article-suggestion a place to give two or three references or internet links as a starting-point for the potential article-author. A one-sentence summary of why the subject is notable would be jolly useful too. Elemimele (talk) 16:25, 22 April 2023 (UTC)

Honestly, this is a brilliant idea - why not have a sort of preliminary process when people try to start an AfC draft that has them go through the steps for creating a good article (provide 2-4 good sources, write a good lede, etc) - this splits up the review process into more manageable steps, helps weed out the nonsense early on, and allows the writers to get a better understanding of what is required of them. Nerd1a4i (they/them) (talk) 03:37, 1 May 2023 (UTC)

Making search easier

I propose allowing you to search for Categories and templates by using the [[]] and {{}} brackets. Instead of typing Category: or Template: you could simply add the brackets around the name of the category or template. For example, {{Infobox settlement}} or [[1960 births]] PalauanReich^🗣️ 01:42, 30 April 2023 (UTC)

@PalauanReich, have you looked at "Pages in these categories" in the advanced options for Special:Search? WhatamIdoing (talk) 19:13, 4 May 2023 (UTC)

Link colors and contrast in V22 (and mobile)

During the recent change to Vector 2022, I noticed that link colors were significantly lightened, so there is less contrast between words and the background (original comment). This is particularly egregious whenever the background color is adjusted, such as navboxes and table headers. In other words, by lightening the text color for links, the background must be very close to white in order to remain accessible. I believe the same colors are also used in the mobile skin. I've compiled the WCAG contrast ratios for various text/background combos (explanation) to quantify these changes. Note that MOS:COLOR says all text should meet AA standards, with AAA standards used when feasible – many V22 color combinations do not meet these standards.

Contrast between text and background

Colors and contrast under Vector 2010/Vector 2022 — normal text Background Link type V10 example WCAG rating V22 example WCAG rating Plain (body text) New Sample text 8.52:1 (AAA) Sample text 5.36:1 (AA) Visited Sample text 15.83:1 (AAA) Sample text 5.26:1 (AA) Table cell New Sample text 8.09:1 (AAA) Sample text 5.09:1 (AA) Visited Sample text 15.02:1 (AAA) Sample text 4.99:1 (AA) Table header New Sample text 7.21:1 (AAA) Sample text 4.53:1 (AA) Visited Sample text 13.39:1 (AAA) Sample text 4.45:1 (A) Common awards background New Sample text 6.21:1 (AA) Sample text 3.90:1 (A) Visited Sample text 11.53:1 (AAA) Sample text 3.83:1 (A) Navbox title (default) New Sample text 5.54:1 (AA) Sample text 3.48:1 (A) Visited Sample text 10.29:1 (AAA) Sample text 3.42:1 (A)

However, I was later informed that the V22 developers were working to meet a different accessibility requirement by lightening the link colors – the contrast ratio between plain text and linked text should be 3:1 (MediaWiki comments, WCAG explanation).

Contrast between plain and linked text
Relative contrast between text colors Types of text V10 example Contrast V22 example Contrast Plain and new link Sample text 1.89:1 Sample text 3.00:1 Plain and visited link Sample text 1.01:1 Sample text 3.06:1

Balancing these two requirements is very difficult. I have a few different ideas for how to address it, but each has its downsides.

1. Do nothing. This is always an option, but I personally don't like this because too many colors have issues and we would violate the MOS.
2. Lighten background colors that cause issues. This would focus on things like navboxes and other editor-modified backgrounds, which we could change without the WMF, but it would be very tedious to manually adjust many of those colors, and some cases (i.e., table headers) are part of the skin. And it wouldn't fix the fact that the range of acceptable background colors have been dramatically decreased.
3. Darken the link colors again and underline links. This would return the background contrast ratios to V10 accessibility standards, which most pages were designed to meet. This works because the 3:1 contrast ratio between plain and linked text is not required if the links are underlined. WCAG actually suggests using underlining instead of color to distinguish links, but for some reason, the comments on the MediaWiki page specifically rule this out; if anyone knows why that is, that would be great to know.

Before officially proposing any change, I'd appreciate feedback or any other suggestions for how we could improve text colors. Thanks! RunningTiger123 (talk) 03:19, 28 April 2023 (UTC)

I didn't like this change when it happened, but then I saw a "too light" link in the interface that I hadn't realized was there, and which I have found incredibly useful since then. I'd been using that page for almost 10 years without noticing the link. ¯\_(ツ)_/¯ WhatamIdoing (talk) 00:22, 30 April 2023 (UTC)

To clarify, were the links previously blending in with the background? I can't imagine too many places where the dark V10 links wouldn't be visible – I'm interested to see the page now (if possible). RunningTiger123 (talk) 01:02, 30 April 2023 (UTC)

The links were previously blending in with the rest of the text. It was a link in a sentence, and I never noticed that the link was there, because the link was too dark. It had very good contrast with the background + very poor contrast with the non-linked text. WhatamIdoing (talk) 19:10, 4 May 2023 (UTC)

Right, I think that's why WMF made the changes for V22, and I just wanted to gauge if that tradeoff is worthwhile if it impacts contrast with the background. RunningTiger123 (talk) 22:26, 4 May 2023 (UTC)

Detect reused citations in the visual editor

It could be a little bit easier to reuse citations in the visual editor.

Citations can get messy with large articles, and especially large articles written by different people, and users currently don't know if they're adding a citation that is already present in the article.

The process could be: create citation -> paste link -> generate -> inform users that their citation will be reused when they click insert, and inform them where it is used, and offer a button below to create new one.

Is there anything discussing this? I'm not sure if this is the right place to ask, so please direct me if needed!

Edit: see https://phabricator.wikimedia.org/T126488 Pneen (talk) 00:17, 1 May 2023 (UTC)

I have been working on cleaning up citations in Vaquita, where several sources each received three to five duplicate full citations in the article, each with a different numbered ref name, a total of 27 different numbered ref names. As I understand it, all of those numbered ref names had resulted from the Visual Editor, and they made it very difficult to understand the sourcing in the article. I would support any effort to improve howe sources are added using the Visual Editor. Donald Albury 01:05, 1 May 2023 (UTC)

Is there any cleanup bot which checks (e.g. searching the database dump periodically) for cases where the same external URL is present in multiple places in any article? That seems like the easiest kind of duplicate citation to find; searching for other kinds of duplicate cites would also be good. (And yes, if we could detect this at the point of entry, by having the Visual Editor / Citoid warn users of attempts to add already-present cites, that'd be good.) -sche (talk) 20:57, 7 May 2023 (UTC)

Please add downloading

In the mobile app, Please add downloading so you can view articles offline. 78.163.113.64 (talk) 20:24, 6 May 2023 (UTC)

I know this is possible on the web version of mobile. Is it really not available on the app? If not, then I would suggest that the same offline tool that Wiki/Chrome uses to display pages offline can be implemented onto the app. Basically, you'd only be able to view pages you've seen prior through the app's caching ability. Conyo14 (talk) 03:57, 8 May 2023 (UTC)

According to the relevant FAQs, both the Android and iOS apps already offer this functionality. Folly Mox (talk) 05:04, 8 May 2023 (UTC)

Global Fact Database

I had an idea about a single source of factual truth 'WikiFACTS', primarily within the context of sustainability, aiming at helping cut wasted effort on unnecessary/incorrect conjecture or opinion when a reference to a particular fact would help ground a conversation. The conversation could be 2 people, a team, a company or the world with facts being validated by appropriate academic establishments but, to the best of all scientific knowledge, absolute.

I wondered if Wikipedia might be a platform to host such a thing?

I envisaged a shopping cart style method of filtering to find 'products' that are proven-scientific fact that the world can use to base new ideas and common knowledge on. There is likely to be a requirement to summarise papers and findings so that the general public can consume the information without jumping to incorrect conclusions but the world seems to be missing a central repository for facts.

Questions that I thought it might help answer are:

• Is it really better to drive electric cars? What's the CO2 impact end-to-end. Rather than a 'self-taught' enthusiast looking at point solutions this page could give a summary supported by all of the available industry facts.
• What materials go into making a battery and how rare are they? There's a question about the dependency upon China for rare earth metals but I thought Lithium Ion batteries 'just' needed Lithium? Copper is NOT a rare earth metal.
• Why can't we simply recycle existing batteries rather that dig up more materials and what is the relative environmental impact?

And simpler ones

• What is the distance to the sun
• How many galaxies are there
• What has been the temperature of London on any given day since records began

WikiFacts could link off to the authoritative web publications but offer up the front end.

Just an idea but I wondered what you might think! I don't think we can really tackle big issues without globally available, correlated and corroborated facts. Ben Photon (talk) 16:12, 3 May 2023 (UTC)

There is no truth, only verifiability. In any case you need to propose this on meta-wiki. Dronebogus (talk) 16:18, 3 May 2023 (UTC)

Well, there is no verifiability without truth. Verifiability, after all, means "able to be shown to be true"[2],[3], etc. "Verifiability not truth" means that what we care about is the extra part of "able to be shown to be", but the true part is a necessary condition as well. --Jayron32 16:23, 3 May 2023 (UTC)

Many things cannot be pinned down to "facts". Consider the simple facts you list. We have an approximate, average answer to the distance of the Earth from the Sun, but the orbit of the Earth around the Sun is an elipse, so the precise distance varies over the course of a year. As to the number of galaxies in the Universe, we have only a very rough estimate, based on how many galaxies can be seen in images of a few very small segments of the sky. We don't even have a precise count of the number of galaxies in the Local group, and most of the known galaxies in the local group are dwarf galaxies, which become very hard to detect at longer distances. Every time a more powerful telescope is used for surveying galaxies, we see older/further away galaxies, so the estimated number has to be increased again. And remember, 100 years ago the scientifically accepted number of galaxies was exactly one. Finally, regarding the temperature of London, what we have are the records from one particular point, which means the value of the data may be limited. For one thing, the climate of cities changes with their growth. I don't know if this has happened in London, but in many places the point at which weather data is recorded has been moved, often from downtown or portside locations to airports. So, what we do in Wikipedia is repeat what is said in reliable sources.

I don't see how a repository of facts would benefit Wikipedia. If we are going to document facts in a separate repository with supporting citations, we might as well just do that in Wikipedia. Facts in a repositiory that are not supported by citations to published, reliable sources are useless to Wikipedia. Donald Albury 18:48, 3 May 2023 (UTC)

hi Donald, thanks for replying. I think you've kind of done the sort of thing that I mean. You've given details about an orbit and stated the variance and a level of understood accuracy. Your point about repeating information in reliable sources is also very relevant. My question is: is there a global index to such information. I'd suggest that most people will google a question and take the first answer that pops up regardless of it's actual (or relative) truth.

How do we, as a species, work together on global problems like to save our planet without a central source of trusted references. It seems that social media (and Wikipedia) can reach large audiences but what content are those audiences consuming?

I thought Wikipedia, because of it existing reputation, would be a good place to front given that large portions of information already exists.

I'm also thinking about the method of searching. To my knowledge, there isn't an 'Amazon style' filtering method to drive down to a topic. You search and generally, because the engines are good, find what you're looking for. But, if you DON'T know what to look for how are you educated as to what's possible and moreover WHO might know the answers to your questions.

If you don't have facts, even with details about how they've changed, then surely were basing our information largely on opinions which doesn't seem very scientific or indeed the best use of human diversity.

The sun is generally known to be ~93 million miles from the Earth but the wiki page on that could have that 'generally accepted fact' stated with the details you elude to described.... 178.248.134.231 (talk) 19:43, 3 May 2023 (UTC)

First, on a tangent mentioned above, some times objective accuracy / answers exists in which case wp:Ver is merely a means to pursue that accuracy goal. But most statements (including all of the examples that you gave) are much more complex situation where no simple "fact" answer exists. Instead to discuss it you basically need to discuss it in something like a Wikipedia article. :-)  :-) Sincerely, North8000 (talk) 19:24, 3 May 2023 (UTC)

Hi North8000. agreed - but there's a generally accepted 'fact' with a given level of accuracy. I think mostly people want the simple answer and as you say, if they want more detail they can look at the wiki page for that. As above though, the sun being ~93Million miles from the Earth is good enough for nearly everyone on the planet to accept as a fact AND THUS debate can be carried out with this common understanding.

I guess i'm trying to find a better alternative to 153,000 people liking a 3 min video by a skeptic of electric vehicle production who was displaying 'facts' in inaccurate forms and drawing conclusions that clearly a lot of people liked. I couldn't easily check his facts though and other than knowing Copper isn't a rare earth metal (because https://wiki.riteme.site/wiki/Rare-earth_element tells me :) ). I don't know whether to be a skeptic, think he actually represents an oil company with other vested interests or what. He was presenting un-proven facts and 153k people believed him (or at least liked his tiktok video).

It just seems that we, as a species, are more drawn to colourful pictures than the data/information/facts behind them and I'm pondering how the hell we tackle such an age old problem in a modern 'enlightened'(?) world. It seems that the answers to all of the worlds problems already exist in the world but I can't fathom that we don't somehow try and improve global understanding. 178.248.134.231 (talk) 19:56, 3 May 2023 (UTC)

WikiData is a global fact database. It includes facts like the distance from Sun to Earth (search for apoapsis). It doesn't answer questions like which is the best car to drive, because those are opinions rather than facts. Many Wikipedia articles include facts from Wikidata, and most articles have a "Wikidata item" link in the left sidebar (or hidden behind the Tools dropdown top right in Vector 2022) giving easy access to relevant facts. Certes (talk) 20:11, 3 May 2023 (UTC)

Not feasible. We'd be aggregating links to fact checks for the easier questions, duplicating Google's job, and we'd be synthesising published research into coherent arguments for the more complex questions, which would be too subjective (recall any debate club experiences you had). Even then, the desired cultural impact can't be achieved because information availability isn't the problem. Most people consume content to feel smart, be entertained, or feel empowered (the last one is why conspiracy content is popular). TikTok videos make them feel smart, Sci-Hub would make them feel dumb. Responsible cultural elites "hijack" this by trying to make content that is both informative and entertaining (Gore's An Inconvenient Truth, The Green Mile, or all the fictionalized "based on a true story" Holocaust/slavery documentaries). You have to "make the vegetables taste like candy", because informativeness alone has an audience, but no cultural impact. What you're looking for can only be achieved with things like Kurzgesagt. "Wikifacts" wouldn't be entertaining, so its audience would only consist of the people who don't need it — DFlhb (talk) 13:41, 8 May 2023 (UTC)

Reliable source search system

I work primarily in the pop-culture areas of Wikipedia. And that makes it quite hard to find good sources when I often have to try to sift through blogs and social media. So, what if we created a special searching system that searched all of the sources we have listed as reliable, and ignored everything else? Also, sorry for my unprofessional wording. QuicoleJR (talk) 00:50, 5 May 2023 (UTC)

I am unaware of any even partly comprehensive list of reliable sources. The list at Wikipedia:Reliable sources/Perennial sources covers only sources that have been repeatedly raised at the noticeboard. Even searching the archives will only find sources that have been brought up at least once. Most reliable spources don't show in the perennial list or even in the archives because they have not been challenged. There will always be many more reliable sources that are accepted without drama and have not been brought up at the noticeboard. Donald Albury 01:20, 5 May 2023 (UTC)

• Several pop-culture related wikiprojects maintain lists of sources that are often used and generally regarded as reliable (see, eg WP:ICTFSOURCES) and some have created custom search-engines to do what, I think, you are suggesting (see, eg WP:VG/SE). Abecedare (talk) 01:25, 5 May 2023 (UTC)

  Ok. I was kinda thinking we could make a project-wide version of that. QuicoleJR (talk) 12:55, 5 May 2023 (UTC)

  The problem is, there are thousands upon thousands upon thousands of sources in the world, and it isn't reasonable to expect anyone to have gone through all of them to have pre-approved even a tiny fraction of them. Instead, we have guidance at WP:RS which describes what Wikipedia considers a reliable source. What is supposed to happen is that you're supposed to assess the source yourself based on the criteria of reliability, and then decide whether it is good to use. Like everything else at Wikipedia, prior approval is not required, and you can just use your best judgement. --Jayron32 13:06, 5 May 2023 (UTC)

  Oh well, it was a good thought. QuicoleJR (talk) 13:35, 5 May 2023 (UTC)

  @QuicoleJR, are you signed up with Wikipedia:The Wikipedia Library? It gives access to some paywalled sources. WhatamIdoing (talk) 14:43, 5 May 2023 (UTC)

  Unfortunately, I do not meet the 6 month requirement. QuicoleJR (talk) 14:46, 5 May 2023 (UTC)

  It looks like you have another two months to go. I think you might find that useful when you get there. WhatamIdoing (talk) 15:30, 5 May 2023 (UTC)

  I also follow a lot of pop culture; the problem is that you have two bands of time for which online search is unreliable:

  • Anything before the mainstream Internet era (roughly pre-2000). Virtually all sources will be print, and for pop culture these print sources are not easy to retrieve without special access.
  • Anything older than maybe 5-10 years. This is when the sources were online, but due to link rot, they are inaccessible. The Internet Archive's Wayback Machine has a way of searching by keyword, but not everything makes it to the archive. Massively, massively frustrating. Gnomingstuff (talk) 15:54, 5 May 2023 (UTC)

You could install this script that highlights sources we consider unreliable. It's super useful when glancing over a reflist. JoelleJay (talk) 22:00, 8 May 2023 (UTC)

Establishing a biography infobox guideline

It seems we've had some issues with infoboxes in certain biographies for quite a while, with some editors generally favoring the inclusion of infoboxes and others generally opposing them. The thing is, we don't have an actual policy that specifies what criteria a biography article must pass for it to qualify for an infobox, so most RfCs related to infoboxes end up as headcounts. This is a possible proposal that, if implemented as policy, would specify the minimum criteria that an article must meet for it to qualify for an infobox regardless of arguments that oppose infoboxes because some infoboxes repeat the content found in the lede.

What should the minimum requirements for a biography article be for it to qualify for an infobox? Perhaps a minimum number of bytes? Or a minimum number of infobox parameters? Please specify what you support and/or what could be improved. – Nythar (💬-🍀) 13:38, 30 April 2023 (UTC)

Over the last six months the articles that have come up via RfC have been over 20kBs of readable prose which are larger articles. Perhaps there should be a recommendation for infoboxes on articles over 10kBs of readable prose? Nemov (talk) 14:12, 30 April 2023 (UTC)

• It will be a guideline you’re proposing, not a policy.
  This is rather pointless, trying to determine by something as meaningless as a page size. An IB isn’t about page size, it’s about the potential useful information. I’ve recently written two articles that are larger than the proposed size, but don’t have enough valid information to populate an IB. Are you proposing that articles over a certain size have to have an IB, even if one would not have beneficial use? Size is a crap criteria on which to build a guideline. - SchroCat (talk) 14:57, 30 April 2023 (UTC)

  Guideline, yes. Now about page size: perhaps that or a minimum number of infobox parameters could work. 5? 6? 8? We'll see. This is a discussion on developing a guideline proposal, so there will hopefully be more discussion as this progresses. Nythar (💬-🍀) 15:06, 30 April 2023 (UTC)

  Very much agree. Prose length is not a suitable metric. The metric that makes the most sense to me is non-trivial, unambiguous facts (e.g. excluding occupation, non-notable spouses, genre, influenced, religion, etc) that are not found in the first paragraph of the article. If the topic has associated standalone articles, like a list of works or awards, links to those could count towards the minimum.

  The reason I specify the first paragraph of the article is because that's the only bit displayed above an infobox on mobile. Anything in there is probable to be read already by the time the reader reaches the infobox.

  I'm a little leery on the wording. It seems like you're aiming for criteria where an infobox is mandatory (or at least "should" or "strongly encouraged"), but as presented what you're defining are criteria below which an article cannot (or should not) contain an infobox, which may very well have the effect of spurring infobox removal discussions rather than avoiding infobox addition discussions. Folly Mox (talk) 15:15, 30 April 2023 (UTC)

  Again, no. This isn’t something you can set a hard and fast rule on. One of the articles I’ve written recently has no date of birth or death and several potential nationalities. No spouse or children are recorded either. An IB would be of zero benefit to readers, but it would still fall within your “must have an IB criteria”. The other article I’ve worked on has a date of death but none of the other ‘obvious criteria for inclusion. The current guidelines of ‘per individual article’ works well enough. - SchroCat (talk) 15:49, 30 April 2023 (UTC)

  I think you make a valid point that there will be exceptions, but, with respect, I'm curious if you think the general community would agree with your assessment that the articles you've referenced shouldn't have an infobox. To just say it bluntly, from what I've seen, you've been on the oppose side of a lot of infobox discussions that have ultimately yielded a consensus supporting the infobox.--Jerome Frank Disciple (talk) 15:59, 30 April 2023 (UTC)

Some have, some haven’t. That does not detract from my argument or diminish my opinion. Given the criteria I have shown above, I would struggle with any guideline that insists on an IB when such fundamental information is missing. - SchroCat (talk) 16:16, 30 April 2023 (UTC)

Sure! And that's fair! But what I'm asking if you think the community would agree with your assessment that an IB would be of "zero benefit" to those articles. And I'm asking because you've made similar claims on other pages, and, I'd venture to say that a supermajority of the time ... the community has concluded the reverse. I think it's a fair question since your point is that article size or parameters are imperfect metrics. The obvious question is "imperfect compared to what"? And I think the answer has to be "compared to what the community consensus would be using the current approach?" So, it's worth asking just how imperfect they are. --Jerome Frank Disciple (talk) 16:19, 30 April 2023 (UTC)

”a supermajority of the time”? No, not even that. Votes that include the activists who have decided to take part have led to win some, lose some, and certainly no “supermajority”.

Given the criteria I’ve said that are missing, I’m struggling to see what actual useful information an IB for these two would include.

There is a wider question on where they are of best use. I am a big fan of IBs for the right type of articles, including biographies, but for the liberal arts they are of less general use, often regurgitating the information of the first line, but including information that is not core to the individual. You erroneously claim the community has a ‘supermajority’ in the question, but while I have a higher threshold for inclusion, it is based on a solid basis, not a IDONTLIKEIT reaction to an absence of a box on every biography over a randomly chosen size.

A final point is that the pushing of IBs onto articles is very rarely done by readers, only editors, who claim (with no evidence at all) that readers want or need IBs. This thread is another example of an editor-driven exercise to impose a dubious format for no other reason than it’s something they think should be there, trying to force a metrics-driven approach without regards to who it benefits (if anyone), ignoring any question of downsides and trying to force a one-size-fits-all approach when the opposite is the case. - SchroCat (talk) 16:48, 30 April 2023 (UTC)

Fair enough! Just to clarify: I understand your overinclusion point and think it's probably true. You're saying, "I can think of pages off the top of my head in which an infobox would serve no value but the proposed guidelines would require an infobox." But, based on the discussions I've seen, you're far more likely to say "this infobox adds no value" to a page than the rest of the community (though I take your point that the discussions you've taken part in might have been overtaken by pro-info box partisans!). And, since, for reasons I completely understand, you're not linking to those pages, I can't check them myself and confirm "oh for sure an infobox would be useless here". So it's hard to know how big the overbreadth problem is. --Jerome Frank Disciple (talk) 17:00, 30 April 2023 (UTC)

• Comment: Relatively weak-opinioned editor here. I've only been a part of one infobox discussion, where my contribution was ultimately a "neutral". But I've reviewed many of these discussions. I understand the currently guideline is that determining infobox appropriateness requires a tailored inquiry— we should ask "how useful would an infobox be here?" instead of participating in general discussions like "aren't infoboxes great/distracting?" But as User:Nythar says, and having reviewed many discussions, I think it's fair to say this isn't mostly what happens. One concerning feature of the relevant RFCs: the same editors seem to appear in these disputes over and over again, and, regardless of whether they say they're tailoring their rationale to the article, they're basically always casting the same !votes. (That's not an allegation of bad faith—I think it's probably just very easy for someone who thinks infoboxes are essentially always/never useful to think that an infobox on the particular page would be useful/useless.) Given that this is a recurring, repetitive issue concerning, chiefly, general arguments, it does seem like the type of issue that more guidance would greatly help.

That said, I don't think I agree with the proposals here. User:SchroCat makes a great and valid point—article size is an imperfect gauge of infobox usefulness, and I don't think we should develop a hard-and-fast rule based on an imperfect metric. I suppose it'd be too radical a rework of WP:Consensus to ask for some kind of rebuttable presumption or default option (i.e. a size > X warrants an infobox; a size < X does not ... unless a consensus says otherwise). The parameters option is intriguing, though still imperfect. From what I've seen, when editors complain that a bare infobox doesn't have enough parameters, users tend to stretchhh the infobox by filling in parameters that probably shouldn't be filled in. Ideally, we could say that a consensus would reject these types of changes, but, more realistically, I imagine that most users who strongly support infoboxes will be, internally, willing to accept some stretches for the overall benefit of the infobox (and, of course, most users who strongly oppose infoboxes will say that parameters that legitimately could be filled in shouldn't be filled in). Also, given the amount of infoboxes (and amount of potential parameters unique to each), I'm not totally sure that a one-size-fits-all approach would work in practice. User:Folly Mox's suggestion might work best—though I worry that "nontrivial" will be too hard to pin down, and certainly we would have to clarify whether external links themselves count as non-trivial facts--Jerome Frank Disciple (talk) 15:41, 30 April 2023 (UTC)

Something like infoboxes are encouraged in larger articles where essential facts that are not found in the first paragraph of the article. I don't think our goal should be to create a commandment. Editors should have some discretion based on the article because not every article is the same. Having something to prevent editors from cramming infoboxes in every article or blocking them on every article would be a nice style guideline to use in these discussions. Nemov (talk) 15:55, 30 April 2023 (UTC)

@Jerome Frank Disciple: The parameter idea would allow us to determine what generally counts as non-trivial (perhaps excluding the spouse, children, religion, etc. parameters). We could then agree on a minimum number of non-trivial parameters (perhaps 5 or 8 or 10?); any article with the minimum number of non-trivial parameters qualifies for an infobox. This wouldn't mean every such article must have an infobox, but it would mean that infoboxes are acceptable parts of such articles, and if an article passes the minimum criteria, it generally should have an infobox. – Nythar (💬-🍀) 15:53, 30 April 2023 (UTC)

• I think that discussions about whether an infobox is "useful" or beneficial in a specific article are kind of missing the point. Infoboxes are effectively part of our Trade dress. They are what (in the eyes of some editors and many readers) makes a Wikipedia article look like a proper Wikipedia article. We will therefore always have people who want to add an infobox – people who deeply believe that it is always "useful" and "beneficial", even when the infobox does little more than draw a different type of line around the lead image. That's because their use case is making the page look like a proper Wikipedia article, which has almost nothing to do with the contents of the infobox, and everything to do with its mere presence. WhatamIdoing (talk) 16:47, 30 April 2023 (UTC)

  I think this is probably correct. But the guidelines currently say it's usefulness that should determine, and I think the ArbCom decision pretty straightforwardly rejects what you're suggesting most users do—treat infobox inclusion as a maintenance task.--Jerome Frank Disciple (talk) 16:51, 30 April 2023 (UTC)

  Is there any evidence to back up that readers think they are beneficial and the absence is detrimental? If not, it’s an IDONTLIKEIT based on personal taste. De gustibus non est disputandum is a good point to hold in mind when considering an IB discussion. - SchroCat (talk) 16:54, 30 April 2023 (UTC)

  That is a complete dismissal of all the meaningful points listed above and in other discussions. And "taste" can be argued in any discussion; for instance, why do we write articles in chronological order from top to bottom? Why not write them the other way around? One could argue that is simply other editors' taste, or perhaps society's taste, and that it holds no water (although admittedly, that's a stretch). – Nythar (💬-🍀) 17:00, 30 April 2023 (UTC)

Not at all. Asking for evidence of a claim about what readers want is entirely justified. The rest of your arguments are a straw man. We write for readers, so it’s they who have to be considered first. - SchroCat (talk) 17:11, 30 April 2023 (UTC)

That's probably right, but I'm also a little skeptical of the notion that editors (who, it should be noted, are readers, too) are just dying to have these infoboxes in articles because ... well, why exactly? They're just desperate to get some template-coding practice? In fact, it seems pretty common for stray IP editors to post on a talk page and ask why an infobox isn't there.--Jerome Frank Disciple (talk) 17:13, 30 April 2023 (UTC)

Funnily enough when I once pointed out that I was both a reader and editor (in an infobox discussion), I was accused of ownership! Such are the levels of debate for holding an unpopular opinion. The vast majority, and I mean vast majority, of IB discussions don’t include any IP editors. There are occasional questions from IPs, but when you consider how many readers there are of a particular article, the figures are fractions of percentages, rather than any meaningful amount. We’re looking at 99.9999 per cent of participants being registered editors and not IP readers. - SchroCat (talk) 17:21, 30 April 2023 (UTC)

Ha! And I'd certainly agree that most participants are registered editors. But, and correct me if I'm wrong, when I do see IP editors, I think I usually see them supporting an infobox. See the sections started by IP editors on the Mozart and Colleen Ballinger pages—combined, they made less than 10 edits. To be clear: that's not at all conclusive—it's a probably an egregiously nonrepresentative sample. But it is a data point, if what we're trying to do is guess what non-editor readers would want.--Jerome Frank Disciple (talk) 17:27, 30 April 2023 (UTC)

I’ve seen them supporting and opposing, although a slim majority in supporting the inclusion, but there are still some that post to oppose the inclusion. - SchroCat (talk) 17:38, 30 April 2023 (UTC)

That is not at all a straw man; it is simply exaggerated for effect, as I said. One could argue that almost everything we do is based on "taste", and as I have repeatedly stated, this isn't just a matter of ILIKEIT or IDONTLIKEIT. My points nevertheless keep getting dismissed as such. Nythar (💬-🍀) 17:25, 30 April 2023 (UTC)

No, not everything we do is based on taste. You ask why articles are in a particular order, well it’s because the MOS suggests it. That’s not taste, that’s the current guidelines and the way that encyclopaedias and reference and history books do things. I will go back to my point that you seem to be pushing against: someone made a claim about what what readers expect to see: I’ve just asked if there any evidence or research on the expectations regarding IBs? Do you have any? - SchroCat (talk) 17:33, 30 April 2023 (UTC)

"Is there any evidence to back up that readers think they are beneficial and the absence is detrimental? If not, it’s an IDONTLIKEIT based on personal taste". Sure, if a group of editors wants to include infoboxes only because they feel it creates "proper articles", that wouldn't be a meaningful argument, and would be based heavily on personal taste. But what I am saying above is that it is entirely misleading to suggest that any of this has to do with personal taste, as most editors aren't unreasonably supportive of infoboxes. This only serves to dismiss the reasonable arguments that exist in discussions. Nythar (💬-🍀) 17:47, 30 April 2023 (UTC)

Do you have any evidence of what readers expect, want or find useful? That’s who we write for. - SchroCat (talk) 17:57, 30 April 2023 (UTC)

With respect, the fact that there's never been an official research grant for whether readers expect an infobox (I haven't found anything on meta or any RSes that make this claim) seems a bit of a red herring. There are many examples of clueless editors showing up to an article that's new to them and adding an infobox despite years of wrangling on the talk page, or asking why an article doesn't have an infobox. Examples of randoes dropping in and excising an infobox as unnecessary, or asking why there's one there: that I haven't been able to find either. The very magnitude of their proliferation implies that infoboxes are found useful, and as noted above, they're kinda part of our brand.

For clarity, despite my recommendation of possible metrics above, I wouldn't support (nor oppose) a guideline suggesting inclusion of infoboxes based on a set of criteria, but I do recognize an inexorable historical trend when I see one. Folly Mox (talk) 19:57, 30 April 2023 (UTC)

Glad someone can fess this up, because in so many IB discussions (including this one), we’re continually seeing someone claim ‘it’s what readers want’. That’s always been a false claim. The magnitude of proliferation is driven by editors, not readers. As I’ve pointed out elsewhere in this thread, there are biographies that get thousands, hundreds of thousands of readers, but only one or two of the readers mention it. It’s not readers driving this: it’s editors. Yes, there is an inexorable trend, but only because of the constant pushing by editors, not readers. If we’re going to force IBs into articles by some form of metrics, I’d like it to be based on research on what readers need, not what activist editors want. - SchroCat (talk) 20:07, 30 April 2023 (UTC)

To be fair, don't we inherently not know the preferences of readers who aren't editors? I think I see the general outline of what you're saying—though, as you said, a majority of stray IPs do seem to prefer an infobox, the vast majority of readers don't comment, and therefore they aren't demanding infoboxes. All in all, though, I think that's a valid ... but relatively weak point. "If readers really wanted all theses infoboxes we would see more of them demanding as such on talk pages" is a bit of a question mark. If a reader knows there is a mistake in a Wikipedia article, but doesn't correct it or request it be corrected on the talk page ... does that mean we should infer that the reader wants Wikipedia to be inaccurate?--Jerome Frank Disciple (talk) 20:11, 30 April 2023 (UTC)

You can characterise it as a “weak point” if you wish, but I’m consistently told in IB discussions (including this one) that a box should be included because it’s what readers want. Unfortunately, no-one has bothered asking them, but it’s still trotted out time and time again, and I’m sure I recall seeing it in a closing statement as some form of definitive fact, when in fact it is, at best, guesswork, and at worst, straight fabrication. - SchroCat (talk) 22:23, 30 April 2023 (UTC)

Found an example of the claim in a closing statement: the one for Laurence Olivier in which this spurious piece of information was accepted without question by the closer. - SchroCat (talk) 22:28, 30 April 2023 (UTC)

... First, to my eye, that's a pretty big mischaracterization of the Olivier closing statement. Can you quote the portion you're referring to? I see a closing statement that simply describes the arguments made by supporters and opponents of the infobox. I also don't see a discussion of what "readers prefer" or "readers want". "Supporters of adding an infobox to this article offer a number of reasons in support of the inclusion of an infobox. Many editors argued that adding an infobox would allow for a concise presentation of basic biographical facts .... The infobox, per supporters, would allow for information to be available at-a-glance and would make it easier for readers to find information. While this information is also available in the lead and in the article, supporters argue, readers are better served by compiling all of that information and presenting that in the way that only an infobox can do."

And, frankly, I still don't know why you're distinguishing so harshly between editors and readers (I know you said you once said that and someone told you that was an WP:OWN issue ... but ... is that it? ...) My guess is that editors are going by what they prefer themselves, what they see most editors saying they prefer, and what a majority of IP editors say they prefer. That's not airtight, but it's not "spurious".--Jerome Frank Disciple (talk) 22:32, 30 April 2023 (UTC)

”Discussion largely focused around the extent to which the infobox would add net value to the article from the perspective of the reader”. Don’t accuse me of mischaracterisation please. If we’re down to that level, I think I’ll step away from this. - SchroCat (talk) 22:42, 30 April 2023 (UTC)

Even if that is "readers would prefer" ... and I can see the argument but it's not clear cut at all (is "this would be useful for readers" the same as "readers would prefer"?) ... where is the closer accepting that fact as true? The sentence you pulled is the closer describing what the discussion "focused around". The conclusion of the closer's statement says what the consensus position was. That the closer found a consensus that the template would at net value, from a reader's perspective, doesn't mean the closer agreed the template would add net value from a reader's perspective.--Jerome Frank Disciple (talk) 22:47, 30 April 2023 (UTC)

@SchroCat, looking at this with the distance of a few days, I'm still disappointed by your response. Here's what I saw:

• Me: It doesn't matter if infoboxes are beneficial.
• You: So where's your evidence that infoboxes are beneficial?

Again: I don't think it matters if infoboxes are beneficial. I'm sorry to say that I don't even think it would matter if we had incontrovertible evidence that infoboxes were harmful. That's because whether or not they're useful or beneficial is the wrong question. Editors are not (always) adding it because they believe that an infobox provides a benefit. They are adding infoboxes because they believe that is the normal and correct thing to do (for most articles).

More specifically, my point is that people expect infoboxes. Nobody is ever surprised by infoboxes appearing in Wikipedia articles. If you look at articles I've created, I don't personally tend to add them (nor do I insist that they be removed). Relative to the overall site average, I'm (much) less than half as likely to add an infobox as the typical editor. However, that's my personal approach, and, as you say, my personal approach isn't necessarily what everyone should do.

In my experience, there are basically three elements that make people think something looks like a Wikipedia article: putting the title in bold in the first sentence, having blue links out to other articles, and – relevantly – an infobox, or at least an image at the top of the lead.

What an infobox seems to provide is not direct "benefit" or immediate "usefulness", but the look and feel of a Wikipedia article. As a result, it doesn't matter if it provides, e.g., educational value. What matters is that it visually signals "This is a real Wikipedia article!" And – relevantly for this particular discussion – so long as editors believe that an infobox is what makes their newly created article look normal, there will always be significant pressure to add them, and you won't be able to reason people out of that desire. WhatamIdoing (talk) 20:50, 4 May 2023 (UTC)

I’m a little staggered by this response. “I don't even think it would matter if we had incontrovertible evidence that infoboxes were harmful. That's because whether or not they're useful or beneficial is the wrong question”. I utterly reject and refute that as an argument and I can’t believe you don’t think it matters if they are harmful! If something is harmful it should not be in an article. An IB doesn’t signal an article is a “real article” - that’s a matter of personal taste and we’re back to de gustibus again because it’s an opinion, not “right” or “wrong”. - SchroCat (talk) 21:11, 4 May 2023 (UTC)

(When you say refute, you mean "disagree with", not "provide actual evidence that it's wrong", right?)

I personally would prefer that articles not contain harmful content. But I have also noticed that I have never been made queen of Wikipedia, and even if this is purely an oversight on the part of the community, it does mean that my own personal opinion does not carry any more weight that anyone else's personal opinion. It appears that some less experienced editors really do respond to infoboxes as a signal that they've managed to do the right thing. It seems to make them feel like they have successfully created a proper Wikipedia article. It might not make you and me feel that way about the articles we create, but it does seem to have that effect on others, and they're not wrong to have their own feelings about it. Or, to use your words, whether an infobox signals that the article is a "real article" is itself a matter of personal taste. Some people believe it does; you and I, apparently believe it does not. But it is a matter of taste, and if their personal taste sees infoboxes as the marker of a "real article", then they are not wrong. After all, it is just your personal taste (and generally mine, too) that says an infobox is irrelevant to article quality.

Additionally, when we have discussions about provably harmful content in articles (e.g., articles about basic subjects that are written poorly, or with a degree of jargon and complexity that would be more appropriate for graduate school), the response from the community tends to involve much shrugging of shoulders or declarations that some WP:UPPERCASE prevents us from remedying the situation. Consequently, I imagine that if some hypothetical paper concluded "Infoboxes make people learn 3% less information about the subject", we would probably not remove infoboxes just to prevent the learning loss. We'd probably instead say that the paper was garbage and do whatever we wanted, exactly as we do now. WhatamIdoing (talk) 23:36, 12 May 2023 (UTC)

• This really isn't the place for a discussion about the merits of an infobox. It's well established that some editors have strong opinions about them. The real topic is do we stick with the status quo? The status quo has resulted in 10+ RfCs about the inclusion of infoboxes over the last six months. The only RfC that didn't end in inclusion was Maddie Ziegler. If we are unable to come up with a policy or guideline then the current process will continue, but it seems like we could save a considerable amount of time for the community by creating a path forward. Nemov (talk) 18:11, 30 April 2023 (UTC)
  • We have a general policies on IBs already, but the proposal here is flawed. Trying to force an IB onto an article based on prose size is not the right approach. Some smaller biographies would work well with a box, some longer ones now have misleading information thanks to an IB and the article would be better for readers without one. At the moment the general policy works for biographies as well as any other articles. - SchroCat (talk) 18:18, 30 April 2023 (UTC)

    This proposal is not about trying to force an IB onto an article based on prose size. It is a general proposal. For instance, I support a minimum number of notable parameters. Of course, you are entitled to disagree with this as much as you want, but this is, after all, a proposal presented to the entire community. I am simply waiting for feedback. – Nythar (💬-🍀) 18:29, 30 April 2023 (UTC)

    • Actually, that’s what it is, partially at least (“Perhaps a minimum number of bytes?”, to remind you) And that’s a bad basis. A minimum number of parameters? I can see a lot of gaming to include or exclude a box. Should boxes be removed if these nebulous thresholds are not met? You’re trying to force an issue that doesn’t need forcing, to impose a set of criteria without any basis in why those criteria or why those numbers. We have guidelines that work already and the instruction creep isn’t beneficial. - SchroCat (talk) 18:38, 30 April 2023 (UTC)

  • As guidance is usually derived from practice, are there commonalities between these various RfCs that can be used as a starting point for discussion? isaacl (talk) 18:33, 30 April 2023 (UTC)

    Many of the RfCs were biographies about actors or musicians. One example is Laurence Olivier. The infobox included list of works and awards, plus the number of years he was active. It also included his place of birth and death. Many of the infoboxes for these articles were similar. Nemov (talk) 18:38, 30 April 2023 (UTC)

    To clarify, are there commonalities between the arguments that led to inclusion of an infobox, and those that led to the exclusion of an infobox? isaacl (talk) 18:46, 30 April 2023 (UTC)

    Ah, I believe the closing editor for the Olivier RfC did a good job of summarizing the arguments that have occured on the RfCs I have observed. Nemov (talk) 18:57, 30 April 2023 (UTC)

    Sure, I'm familiar with these broad arguments over the years. Akin to what Phil Bridger states, can the considerations in question be formed into specific questions or other guidance that can be evaluated when deciding on adding an infobox? The easiest cases are categories of people whose key characteristics can be summarized with discrete items, such as athletes. The community may not be able to formulate specific rules to avoid most discussions, but it may be able to at least jump forward in those conversations to focus on answering specific questions in order to make a decision. isaacl (talk) 21:24, 30 April 2023 (UTC)

    Almost all the articles in question are on lengthy articles. A person's place of birth isn't mentioned in the first two sentences of a lead. The list of works isn't mentioned in the lead. Something like Tamzin suggested is probably a wise place to start. Nemov (talk) 21:36, 30 April 2023 (UTC)

    Because a place of birth isn’t an important piece of information for 99.9 per cent of biographies. It may be for Bruce Willis or Arnie, where the country is important, but the town? That’s largely trivial, which is why it’s not mentioned in the lead. - SchroCat (talk) 21:43, 30 April 2023 (UTC)

    Yeah, @Nemov, I'm largely with you, but I think @SchroCat has you here. In terms of arguments for how infoboxes are useful, "Think of the readers who want to quickly see where someone was born!" seems, to me, to be a bit of a stretch.--Jerome Frank Disciple (talk) 21:44, 30 April 2023 (UTC)

    There's a variety of information not mentioned in the first two sentences that can be included in the infobox. I don't want to get bogged down arguing about specifics. Persionally, I do find that information useful. Nemov (talk) 21:53, 30 April 2023 (UTC)

    Length of article was not one of the considerations listed in the closing statement for the Olivier RfC. I think as a starting point, it may be more fruitful to have editors consider which topics have key characteristics that can be adequately summarized by discrete items. isaacl (talk) 21:46, 30 April 2023 (UTC)

    @Isaacl, I agree with you that guidance should be based on practice, but to that end, I think the sensible approach is to document what's done, and not to have yet another RFC about creating rules.

    @Nythar, years ago, I did a survey of section headings for MOS:APPENDIX. (It's still there, if you want to read it.) Instead of saying what editors "should" do, I wrote what was most popular. There have been almost no disputes about those section headings since then. We didn't need a rule.

    You (or anyone) could do something similar for infoboxes. This could be simple ("About half of all articles have an infobox") or you could get more detailed (compare the number of uses in Category:People and person infobox templates against the number of biographies in Wikipedia:WikiProject Biography/Assessment#Statistics, and write "About ___% of biographies have an infobox"). WhatamIdoing (talk) 19:26, 4 May 2023 (UTC)

• Thinking out loud here... I think the vast majority of editors would agree with the statement "Most (non-stub) biographies should have infoboxes, but some should not". It's only a small faction on either side who favor more radical interpretations in one direction on the other. But leaving it up to an RfC each time one person decides they don't like an infobox is a drain on editorial resources. Perhaps a bright line is needed at this point? Something like "If there is information that could be put in an infobox beyond what is found in the article's first two sentences, and the article is not a stub, an infobox is presumed acceptable absent clear consensus to the contrary; in other cases, there is no presumption for or against an infobox". -- Tamzin^{[cetacean needed]} (she|they|xe) 18:52, 30 April 2023 (UTC)
• I mentioned above that I thought new guidance would be worthwhile since this issue are (1) repeatedly litigated and (2) often dominated by general (rather than page-specific) arguments. In case anyone is curious, I thought I'd include a table (below) of RFCs on infoboxes in biographical entries. I think the table and the debates listed therein are telling for multiple reasons and relevant to the proposals.

1. First, the debates are all contentious, feature many repeat players, and are often dominated by general arguments.
2. Second, there's not an obvious logic to the outcomes of these debates. Compare the Pyotr Ilyich Tchaikovsky infobox, which was, by consensus, included, and the nearly identical Claude Debussy infobox, which was, by consensus, excluded. Compare also the Jenny Lind discussion where a short infobox was accepted, to the Mackenzie Ziegler discussion, in which a longer infobox is rejected. Of course, complete consistency would be unrealistic, but I do think the guidelines can maybe, well, provide a bit more guidance.
3. Third—the elephant in the room—there's a pretty obvious 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? ... Well, both of those articles now have an infobox.

--Jerome Frank Disciple (talk) 19:25, 30 April 2023 (UTC)

Prior RFCs about infoboxes on biographies

Prior RFCs on biographies and results (feel free to add to list!)

Chronologically ordered[1] (except Grant, since he had two)[2] Page Consensus? Date Gustav Holst No consensus September 2016 Harry Lauder Exclude September 2017 Cary Grant No consensus January 2018 Include January 2021 Nicholas Hoult No consensus April 2018 Include June 2018 Penny Rowson Include October 2019 Jean Sibelius Exclude[3] August 2020 Mary Shelley Include October 2020 Dafne Keen Not closed October 2020 Nikki Amuka-Bird Exclude[4] March 2021 Stanley Kubrick Include November 2021 Cole Porter Not closed October 2022 Laurence Olivier Include November 2022 Maddie Ziegler No consensus December 2022 Mackenzie Ziegler No consensus (Not a formal RfC but given a formal close with rfc-close template) January 2023 Pyotr Ilyich Tchaikovsky Include January 2023 Claude Debussy No consensus January 2023 James Joyce Include January 2023 Jenny Lind Include February 2023 Wolfgang Amadeus Mozart Include March 2023 Rod Steiger Include March 2023 [1] These were discovered if they were explicitly mentioned in one of the debates I'd seen or if they showed up when I searched in the Talkspace for "RFC infobox" (no quotes). [2] Hoult also had two, but, at least as the time I made the list, that would not change the order—his were roughly back-to-back. [3] Infobox later added to the article after discussion. [4] 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

Arbitrary break (Establishing a biography infobox guideline)

• I think that "should this article have an infobox" is the wrong question to ask first. That should be "what should go in this article's infobox", and if the answer is nothing, because we can't give uncontroversial facts about the subject which should be contained in an infobox, or the article is very short and people could just as easily find the information in the prose, then we should not have an infobox. By "uncontroversial facts" about a person I mean things like known birth and/or death dates or teams that a footballer has played for, not things like "best known for" which are always controversial. Phil Bridger (talk) 20:43, 30 April 2023 (UTC)

  That is not a meaningful solution. We'd just continue to have RfC after RfC. The purpose of this proposal is to solve this recurring problematic issue. Nythar (💬-🍀) 21:13, 30 April 2023 (UTC)

  But is it problematic? We have a solid policy on IBs and there have been RfCs on the point, some of which have ended with an IB and some without. Can you show where the problem is? - SchroCat (talk) 21:19, 30 April 2023 (UTC)

  I mean, as I understand, the policy is currently "make arguments tailored to the page". But it seems pretty clear that's not most of what's happening. Based on my review of the various debates, what we usually have is:

  1. quite a few editors who participate in quite a few infobox RFCs and essentially vote the same way every time (sometimes making general arguments, sometimes specific, though the consistency of position casts a partial shadow on the specificity—I even stumbled on one user who keeps his boilerplate objection in the user space so he can copy and paste it into various disputes);
  2. a few editors who make general arguments about why infoboxes are good / bad; and
  3. editors who make arguments specific to the page.

  In short, many of these discussions are dominated by the same general arguments—that is to say, the debates are dominated by users expressing whether or not they like infoboxes. Additionally, these debates, repeatedly, get ... weirdly personal and antagonistic.

  I also think that, once you look at the various outcomes, there's not an obvious logic to which pages get infoboxes and which don't. (Compare the Jenny Lind discussion, above, where a short infobox was accepted, to the Mackenzie Ziegler discussion, also linked above, in which a longer infobox is rejected. See also the Pyotr Ilyich Tchaikovsky infobox, which was, by consensus included, and the nearly identical Claude Debussy infobox, which was, by consensus, excluded.) Of course, complete consistency would be unrealistic, but I do think the guidelines can maybe, well, provide a bit more guidance.--Jerome Frank Disciple (talk) 21:41, 30 April 2023 (UTC)

  I will add, that once I left notifications on WP:VPR and on the WP:BIO project (see: Steiger) there was a clear consensus from the community. That's why I went ahead with this exercise. If this ultimately goes nowhere that will by the standard practice for future RfCs in order to get more of the community involved. Nemov (talk) 21:47, 30 April 2023 (UTC)

• The summary given above for why some editors do not favor Infoboxes in bio articles is highly misleading. While sports and politician bios can benefit from infoboxes, most articles in liberal arts fields do not. 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". I disagree with including an infobox in such articles because: (1) The box would emphasize unimportant factoids stripped of context and lacking nuance, in competition with the WP:LEAD section, which emphasizes and contextualizes the most important facts. (2) Since the information in the box must already be discussed in the body of the article and the Lead section, and likely has also just been seen in a Google Knowledge Graph, the box would be a redundant 3rd (or likely 4th) mention of these facts. (3) The IB's overly bold format would distract readers and discourage them from reading the text of the article. (4) Updates are often made to articles but not reflected in the box (or vice versa), and vandalism frequently creeps in that is hard to detect because of the lack of referencing in the box. (5) Boxes in liberal arts biographies lattract fancruft and repeated arguments among editors about what to include. (6) IBs in arts bios distract editors from focusing on the content of the article. Instead of improving the article, they spend time working on this repetitive feature and its coding and formatting. -- Ssilvers (talk) 21:27, 30 April 2023 (UTC)

  I think it's fair game to point this out since I said it elsewhere, this comment is part of the reason I think we should get rid of the fiction that the current guidance—endorsing article-specific comments—is actually leading to article-specific debates. (To be clear: I think you're doing what the clear majority of editors are doing.)

  You've now made this comment—almost verbatim—in the Mozart RFC, a Rupert D'Oyly Carte discussion, the Carl Nielsen RFC, the Jenny Lind RFC, the Claude Debussy RFC, and the Mackenzie Ziegler RFC (probably more, I just got tired of going back). In fact, I can't find an infobox RFC where you didn't make this comment.

  Now, maybe, to the extent it is tailored at all, you're only participating in RFCs where, by happy coincidence, all of its tailored points apply (and, just to clarify, there are times that you add a point or slightly modify a phrasing ... although the first and second points appear to be carbon copies every time). But I think what's a bit more likely is that, just as those who support infoboxes are often just saying, generically, "it's helpful to have easy access to this information" are expressing their preference for infoboxes, you're just expressing your general opposition to infoboxes in each of these discussions.--Jerome Frank Disciple (talk) 22:02, 30 April 2023 (UTC)

  I think it is fair to point out that I have never seen a reason to include an infobox in a liberal arts or pop culture bio that is anything other than ILIKEIT, it looks nice, it is (becoming) standard. The articles for which I have participated in infobox discussions have all been ones that I have worked on extensively and that have excellent Lead sections that present all of the key information about the person with more nuance and in context (which the boxes do not do), or were FA articles that had numerous experienced reviewers (including me), commenting at FAC. So, yes, the points that I make above were applicable to those articles. These articles all suddenly had infoboxes shoved into them by drive-by editors who had never worked on them before and had no interest in the subject; when they did not get their way in the IB discussions, they opened RfCs. Those editors are clearly violating the ArbCom rulings that one shouldn't go around adding infoboxes to a massive number articles just because one likes them. The RfC system, in the case of infobox discussions, has basically become a canvassing system for pro-infobox crusaders, and the same pro-infobox crusaders are here, in this discussion, strategizing on how to change the ArbCom decision that infoboxes be considered on a substantive case-by-case basis, to, instead, add a guideline that favors them. -- Ssilvers (talk) 15:14, 1 May 2023 (UTC)

  For sure that's fair! And, again, I'm not trying to single you out—as I said above and in my survey vote, I think the vast majority of discussions are controlled by these sorts of general arguments. My only point is that the current guidance (which, as I understand the ArbCom decision, suggests page-specific arguments) isn't really having an effect, and so alternative guidance might be useful.

  I do take your point about canvassing—if that's happening, then that certainly casts some doubt as to seeming dominance of "include" among the most recent consensus-obtaining RFCs. I think you'll find that, though I support infoboxes generally (though to my recollection I've never voted in favor of an infobox), I'm taking a fairly moderate approach below—I suggested altering the proposals because I thought they could be too easily manipulated by pro-info box partisans--Jerome Frank Disciple (talk) 15:41, 1 May 2023 (UTC)

• Everyone remember this is the idea lab - our goal here is to figure out how to turn an idea into a concrete proposal. If you simply oppose adding guidance, no matter how it is formulated, then just oppose when this goes to an RfC. There's no point continuing the argument over infoboxes here. I personally agree, based on how repetive the arguments are, that a guidance would be good. I think Tamzin's formulation is a good start. It'd be good to see how different versions of possible guidance would apply to the various RfCs we've had. Galobtter (talk) 23:52, 30 April 2023 (UTC)

  Assuming some kind of guideline was adopted where would the policy be placed? I'm looking for some examples of other guidelines to get an idea of how to word this the right way. Nemov (talk) 00:18, 1 May 2023 (UTC)

  It'd add to/modify MOS:INFOBOXUSE. Galobtter (talk) 00:23, 1 May 2023 (UTC)

• This is the part of MOS:INFOBOXUSE that would have to be modified.

  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.

• A modified version based on Tamzin's suggestion could read:

  The use of infoboxes is neither required nor prohibited for any article. However, if there is information that could be put in an infobox beyond what is found in the article's first two sentences an infobox is presumed acceptable absent clear consensus to the contrary; 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.

  This isn't perfect, but it's a nice starting point. Nemov (talk) 00:43, 1 May 2023 (UTC)

  One concern here is that this generalizes from biography infoboxes to all infoboxes. For some kinds of articles, like abstract concepts, the default is to not have an infobox; it's hard to think of a useful infobox that could be put on Security, for instance. So it might be better to limit these to biographical articles, or maybe to something like in an article about a clearly-defined concrete entity. -- Tamzin^{[cetacean needed]} (she|they|xe) 02:39, 1 May 2023 (UTC)

  I agree with Tamzin - let's make sure the guidance is only modified for biographical infoboxes, to avoid any unintended consequences for non-biographical infoboxes. Galobtter (talk) 03:00, 1 May 2023 (UTC)

  Agree, so modify the second sentence to something like For biography articles, if there is information that could be put in an infobox beyond what is found in the article's first two sentences an infobox is presumed acceptable. Nemov (talk) 03:11, 1 May 2023 (UTC)

  I agree. It does seem that the guidance here is for biographies. - Enos733 (talk) 04:14, 1 May 2023 (UTC)

  Honestly, I think the current draft is a bit of a weak proposal, if only because if the goal is to reduce RfCs on this topic, people will try to find ways to get that clear consensus to the contrary. I would suggest a slightly stronger proposed policy, perhaps along the lines of The use of infoboxes is neither required nor prohibited for any article. However, for articles about a clearly-defined concrete entity, if there is information that could be put in an infobox beyond what is found in the article's first two sentences an infobox is encouraged. 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. Nerd1a4i (talk) 03:15, 1 May 2023 (UTC)

  As an aside, I'll note that the comments earlier in the discussion, which will likely reflect those when this policy goes to RfC, largely seem to reflect disagreements about first, the infobox's purpose, and second, how readers should read articles/get information from articles. I would suggest that the policy be designed in order to help answer these questions. For instance, I would argue that we should not dictate how readers get information from articles, and indeed, the infobox acting as a distilled, non-text-heavy summary, is a great counterpart to the lede, and one that I enjoy having as a reference when reading. I made some comment as to the purpose of the infobox in the modified policy above, but I would be curious what you all think the purpose of the infobox is. Nerd1a4i (talk) 03:20, 1 May 2023 (UTC)

  I think clear consensus against should be a fairly effective at stopping RfCs simply because people are not going to keep starting RfCs if they keep failing (and if they keep doing that, that is disruptive); it seems pretty clear from the RfC results that it is rare to get a consensus against an infobox. It's also more likely to pass, which is important for something this contentious. Galobtter (talk) 03:24, 1 May 2023 (UTC)

  That's fair, but I must admit I still think a stronger policy would be more helpful. Another example would be for new editors - a clear 'encouraged' seems better than 'presumed acceptable'. (In general, I do think Wikipedia policies could do with clearer, less over-the-top-legalistic language, but that's a discussion for another time probably.) Nerd1a4i (they/them) (talk) 03:29, 1 May 2023 (UTC)

• This is using a sledgehammer to crack a nut. That there’s been a few RfCs doesn’t mean we need new guidance. Bondegezou (talk) 07:03, 1 May 2023 (UTC)

  Indeed: it appears to be a solution in a desperate search of a problem. We have general guidelines on IB use and a working RfC system that rejects IBs on some articles and adopts them on others. - SchroCat (talk) 10:35, 1 May 2023 (UTC)

  If I may quote Galobtter - everyone remember this is the idea lab - our goal here is to figure out how to turn an idea into a concrete proposal. If you simply oppose adding guidance, no matter how it is formulated, then just oppose when this goes to an RfC. Considering your only contribution to this conversation has been repeated and lengthy disagreement, I think it is pretty clear what your position on this is! You are not adding anything new with this comment. (To be clear, this is not meant as an attack - you are more than entitled to your opinions! I just think this is the exact sort of thing that makes Wikipedia discussions so excessively lengthy and internet-argument-y. You have stated your position, some agree, some disagree, when the policy is eventually taken to RfC you can vote, and so forth. I don't see the need for continuing to denigrate the proposal in this space.) Hope you have a good day! Nerd1a4i (they/them) (talk) 23:01, 1 May 2023 (UTC)

  Thanks for trying to silence me. Pointing out problems in the underlying rationale stops bad proposals, but feel free to continue in trying to push away people with opposing viewpoints, that’s a great idea. You may not mean your comment as an attack, but trying to silence someone really is one. - SchroCat (talk) 06:43, 2 May 2023 (UTC)

Proposal ideas

• I have reviewed the updates and crafted 3 versions.

Version 1:

The use of infoboxes is neither required nor prohibited for any article. For biography articles, if there is information that could be put in an infobox beyond what is found in the article's first two sentences an infobox is presumed acceptable. Absent clear consensus to the contrary; 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.

Version 2:

The use of infoboxes is neither required nor prohibited for any article. For biography articles, if there is information that could be put in an infobox beyond what is found in the article's first two sentences an infobox is encouraged. 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.

Version 3:

The use of infoboxes is neither required nor prohibited for any article.

For biography articles, infoboxes are encouraged if there is information that could be put in an infobox beyond what is found in the article's first two sentences. 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.

• I prefer version 3 that's based on Nerd1a4i's recommendation. I understand Galobtter's point about the contentious nature, but based on the non-idea feedback here there's no policy or guideline that will ever get their support. A clearer policy would be better in the long run. - Nemov (talk) 13:12, 1 May 2023 (UTC)

  These examples seem great, Nemov, but "is encouraged" and "is presumed acceptable" both sound a bit too weak. Perhaps it should read differently, because the current wording sounds like infoboxes are simply "encouraged" but not actually too important -- a recommendation, you could say. – Nythar (💬-🍀) 13:21, 1 May 2023 (UTC)

  So another version with this: For biography articles, infoboxes are recommended if there is information that could be put in an infobox beyond what is found in the article's first two sentences. I agree that recommended is a better word in this instance. Nemov (talk) 13:32, 1 May 2023 (UTC)

  @Nemov: I'm not sure, but perhaps more specific wording should be used. For instance: For biography articles, infoboxes generally should... Meaning if articles pass certain criteria, an infobox generally should be there, but not necessarily. What do you think? – Nythar (💬-🍀) 13:43, 1 May 2023 (UTC)

  I do just want to flag that the stronger the language seems (i.e. the more obviously that the text favors editors who almost always favor infoboxes), the more pushback it'll get from editors who almost always oppose infoboxes. (That said, as I documented above in the table, it seems like consensuses more and more frequently favoring infobox inclusion, so I do think this proposal is, on the whole, fine.)--Jerome Frank Disciple (talk) 13:46, 1 May 2023 (UTC)

  Remember that very many editors are in neither camp. Phil Bridger (talk) 14:00, 1 May 2023 (UTC)

  Fair! Although based on how the discussions have gone in the table I listed above ... it does seem like the editors most likely to have thoughts on an RFC will have ... very strong thoughts.--Jerome Frank Disciple (talk) 14:22, 1 May 2023 (UTC)

  These are great @Nemov—really minor feedback:

  1. Version 1 has a grammatical issue in sentences 2/3. I think the start of sentence 3 was meant to be paired with sentence 2 ... but, even if I'm wrong, the semicolon shouldn't be there. I would also suggest just saying "consensus" rather than "clear consensus".
  2. Version 2 should have a comma after "two sentences".

  I like Version 3 best, but I see an issue: By its terms, doesn't it suggest that, so long as you can include an external link (say, to a subject's YouTube page) in the infobox, an infobox is encouraged? Or does multimedia count? If you can include a picture, that's not in the first two sentences, is that enough?--Jerome Frank Disciple (talk) 13:35, 1 May 2023 (UTC)

  This is a good point, but I'm not sure how to word it. "Vital information" seems a bit nebulous. Nemov (talk) 14:17, 1 May 2023 (UTC)

  ... I mean, it's going to be controversial, and I say this as someone who favors infoboxes, but maybe exclude links and multimedia? That doesn't mean that an infobox with just a birth and death date + a picture would be discouraged—your version itself says that infoboxes are either encouraged/recommended or neither encouraged/discouraged.--Jerome Frank Disciple (talk) 14:24, 1 May 2023 (UTC)

  Like this: For biography articles, infoboxes are recommended if there is vital information that could be put in an infobox beyond what is found in the article's first two sentences. Nemov (talk) 14:38, 1 May 2023 (UTC)

  I would ditch vital and just say For biography articles, infoboxes are recommended if there is information that could be put in an infobox beyond what is found in the article's first two sentences, not including multimedia or external links. Jerome Frank Disciple (talk) 14:42, 1 May 2023 (UTC)

  Any chance that gets interpreted as barring external links from the infobox? Nemov (talk) 14:45, 1 May 2023 (UTC)

  I don't think so? Because someone who has that interpretation would also have to conclude that multimedia would be barred from the infobox. ... Though it might be a little funny if some good faith editor was like, "Welp, guess I gotta take all the pictures out of infoboxes now ..."

  Still, just to be safe: For biography articles, infoboxes are recommended if there is information (aside from images, videos, or external links) that could be put in an infobox beyond what is found in the article's first two sentences.

  Actually, that's clunky. Not sure how to clean it up. Maybe: For biography articles, infoboxes are recommended if there is textual information^[a] that could be put in an infobox beyond what is found in the article's first two sentences.
  ^[a] That is, information aside from images, videos, or external links. --Jerome Frank Disciple (talk) 14:47, 1 May 2023 (UTC)

  I think I like the original one based on your reasoning. No need to make it too complicated. Nemov (talk) 14:58, 1 May 2023 (UTC)

  Honestly...I think multimedia/external links do add to an article. Isn't it nice to have a picture of a person in the article? If such a picture exists that we can use, I do think infoboxes should be encouraged in that context, to be quite honest. Perhaps this is controversial though. I also agree with the upgrade from encouraged to recommended. Nerd1a4i (they/them) (talk) 23:06, 1 May 2023 (UTC)

I think Nemov's Version 3 is a good basis for a proposal; it makes clear the changing patterns of consensus formation around biographical infoboxes, while also being clear about the scope of the proposed change to the guidance. Jerome Frank Disciple's revised version of that language, which specifies "textual information" and provides more detail in an EFN, is also sensible; however, my inclination is to leave it out of the language for now, to avoid potential instruction creep. If the textual/non-textual distinction becomes an issue later, that point could be revisited. ModernDayTrilobite (talk • contribs) 15:21, 1 May 2023 (UTC)

Fair point on instruction creep! I just think, in terms of a proposal that can reach consensus, we'll probably have to address those issues. If you take a YouTuber, for example (to think of one debate currently ongoing), this guidance could be read to say that the mere fact that that YouTuber has a YouTube page (which, inherently, of course they do) and we can link to it in an infobox ... means we should have an infobox.--Jerome Frank Disciple (talk) 15:45, 1 May 2023 (UTC)

I think the standard of "beyond the first two sentences" is arbitrary, and too weak to be useful, given that there is only a small amount of data that can be held in two sentences. For biographies, Wikipedia:Manual of Style/Biography § Opening paragraph recommends that the first sentence include the subject's name, dates of birth and death, what makes them notable, and location or nationality information for where they were notable. Items such as birth place and details of death are not recommended for the lead unless specifically tied to what makes them notable. Thus these proposals would essentially make infoboxes recommended for the vast majority of biographies, in which case, it would be simpler to just recommend them for all biographies. isaacl (talk) 18:09, 1 May 2023 (UTC)

This is a well reasoned point. It comes down to what the community really believes. If the community believes that infoboxes are an improvement to biography articles in most cases something like this could work:

The use of infoboxes is neither required nor prohibited for any article.

For biography articles, infoboxes are recommended if the information in the infobox augments the article. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to improve 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.

So essentially future discussion would be around whether or not editors find an infobox an improvement. Nemov (talk) 18:27, 1 May 2023 (UTC)

Nemov you've put a ton of effort into this and I hate to be a downer ... but I'm not sure that guidance would do anything distinctly from the current guidance. I mean, at bottom, aren't editors already just debating whether they think an infobox would be an improvement? That said, guidance that memorializes the ArbCom decision might focus the discussions a bit more, though I'm personally skeptical.--Jerome Frank Disciple (talk) 18:31, 1 May 2023 (UTC)

As it stands there's no guidance right now. At least both version state that there's a general recommendation. Shifting gears... does anyone have an example of biography article over 15kB in readable prose that wouldn't be improved with an infobox? That's where the battlegrounds are happening. Nemov (talk) 18:39, 1 May 2023 (UTC)

I'm not sure what you mean by "augments the article". I think this is the matter under dispute in these discussions. Perhaps to help fast forward the discussions, there could be an explanatory essay outlining the arguments on how the article is or isn't improved, with examples of previous discussions. isaacl (talk) 18:51, 1 May 2023 (UTC)

This whole exercise is built on the idea that the general community thinks infoboxes improve the article. That's been the consensus over the last few RfCs. If there is no community consensus that they're an improvement then no policy will be approved at the moment. Believe me, if this put forward we will see many comments about why this is a terrible idea, for a non-existent problem, and infoboxes aren't an improvement. Nemov (talk) 18:57, 1 May 2023 (UTC)

If you're proceeding with the assumption that an infobox improves the article, then having a criterion "if the information in the infobox augments the article" is unnecessary. It just continues the article-by-article arguments over whether or not an infobox improves each article. isaacl (talk) 19:01, 1 May 2023 (UTC)

Honestly that might capture more than you think. I've seen at least a few discussions that concern templates that essentially only have a birth name, birth date, and death date filled in. A few are listed in the table above.--Jerome Frank Disciple (talk) 18:24, 1 May 2023 (UTC)

For any biography that's more than a bare stub, there'll be at least a third sentence that can be drawn upon to put into the infobox. The proposed standard effectively shifts the discussion to what should go into the infobox, under a default assumption that an infobox is recommended. I think if the interested parties want to make a proposal along these lines, it would be better to start with directly recommending an infobox for non-stub biographies. isaacl (talk) 18:43, 1 May 2023 (UTC)

• Reviewing MOS:LEADLENGTH and WP:LENGTH these are a good sources for how some alternative ideas about how to phrase MOS:INFOBOXUSE in regards to size/length or an article. Nemov (talk) 00:28, 2 May 2023 (UTC)

  Perhaps we could use article quality as a proxy for length/depth of content? A start or stub class article is not likely to need an infobox, but I would probably be surprised as a reader to not see an infobox for a C class article, and I certainly would be surprised if there were not one on a B class or higher article. Nerd1a4i (they/them) (talk) 06:27, 2 May 2023 (UTC)

  • I like this idea. Here's another version based on the class reasoning:

The use of infoboxes is neither required nor prohibited for any article.

For biography articles, infoboxes are recommended if the article is C-Class or higher. The purpose of the infobox in these contexts is not to replace the lede or to re-summarize it, but to augment it on articles better developed in style, structure, and quality.

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.

This doesn't make it mandatory, but still encourages the use of an infobox on better developed articles. Nemov (talk) 12:56, 2 May 2023 (UTC)

I'm fine with this, but, just to state the obvious, oh boy is that proposal going to get pushback. That said, maybe it's worth trying anyway—if Wikipedians have, in fact, embraced the infobox more and more in recent years, then perhaps a fairly radical proposal is warranted.--Jerome Frank Disciple (talk) 13:11, 2 May 2023 (UTC)

That would severely limit us. According to Wikipedia:WikiProject Biography/Assessment#Statistics, start-class is the second largest classification of biographies (691,951) after stubs (1,035,097). I don't think we should limit infoboxes according to article size or condition; it should have more to do with infobox parameters (or at least the amount of "infoboxable" information in an article) regardless of other factors. For example, a C-class article with barely enough infobox-appropriate information probably shouldn't have an infobox, while a start-class article with lots of information that would neatly fit into an infobox should have one. Nythar (💬-🍀) 13:11, 2 May 2023 (UTC)

There wouldn't be a prohibition on infoboxes on start-class articles. Is your fear that editors will start stripping away infoboxes? That would be disruptive and sanctionable. Nemov (talk) 13:30, 2 May 2023 (UTC)

My fear is that this proposal would ignore all biography articles below C-class by not setting a minimum criteria. What if Colleen Ballinger were a start-class article? It would still have more than enough information for an infobox, but this proposal would do nothing about that. Nythar (💬-🍀) 13:38, 2 May 2023 (UTC)

I'm not sure "how would this affect this one current dispute?" should be the top priority though, right? As I understand based on what other have posted, the goal is guidance that (1) provides more actual guidance than the current barebones policy, (2) results in less repetitive debate on various talk pages, and (3) reflects the Wikipedia community's increasing preference for infoboxes. And, of course, the background goal has to be: is capable of garnering support by consensus.--Jerome Frank Disciple (talk) 13:55, 2 May 2023 (UTC)

I'm not sure anyone here is getting the point, so I will clarify myself; the entire point of this is: what is the minimum criteria a biographical article must pass for it to have an infobox? No article must have an infobox. However, there should be a "general" minimum requirement for an article to have an infobox. What is this requirement? How do we determine if an article should have an infobox? Is it article size, or the number of infoboxable pieces of information that exist in an article? And why should this requirement be limited to C-class articles and above? If I came accross a start-class article that has enough information for an infobox but lacks one, the infobox that I insert can be removed by anyone, and an RfC would ensue. In that case, this proposal would have solved nothing. Nythar (💬-🍀) 14:07, 2 May 2023 (UTC)

Serious question: are you actually wanting to make that the focus of the guidance? If so, that's fine, and I'm happy to continue to help formulate a proposal, but I do want to note I'd probably object to it. Your bolded text (what is the minimum criteria a biographical article must pass for it to have an infobox?) effectively flips all of the proposals so far on their head. If that were the focus, the proposed guidance would be:

• Infoboxes are not generally recommended for articles that X
• Infoboxes are not otherwise encouraged or discouraged.

But the proposal so far have been

• Infoboxes are generally recommended for articles that X.
• Infoboxes are not otherwise encouraged or discouraged.

--Jerome Frank Disciple (talk) 14:11, 2 May 2023 (UTC)

My idea makes sense to me at least, although many here seem to disagree. Let me take a random stub as an example: Anton Kunz. This article has an infobox. Why? Why should that article have an infobox? Is an infobox appropriate in this case? Why are infoboxes appropriate in species articles like Orius laticollis? Perhaps that's because of the amount of information the infobox contains? Articles that contain too little information usually do not have infoboxes, regardless of the topic. Whether we are dealing with a biography, species, organization, or city article, this is almost always true. Here of course we are dealing with biographical articles, but it is still true; articles with too little infoboxable information shouldn't have infoboxes, and articles with sufficient information should have infoboxes. What is otherwise the point of this proposal? Nythar (💬-🍀) 14:20, 2 May 2023 (UTC)

I totally understand what you're trying to do, but I would remind you that don't let "perfect be the enemy of good." A general guidance is better than no guidance. The battleground behavior on this topic is happening on larger, well established articles. I haven't seen a RfC on small articles. Nemov (talk) 14:25, 2 May 2023 (UTC)

So from what I'm reading here, this proposal isn't actually intended to generally dictate when and for what reasons biographical articles should have infoboxes, right? Well, I suppose something is better than nothing, but I thought it would establish a sort of usable guideline. This won't provide guidance for below-C-class articles, it seems. Nythar (💬-🍀) 14:34, 2 May 2023 (UTC)

So from what I'm reading here, this proposal isn't actually intended to generally dictate when and for what reasons biographical articles should have infoboxes, right? ... ? I'm not getting that impression at all. The proposal, as I understand, is meant to suggest factors that might warrant an infobox.--Jerome Frank Disciple (talk) 14:40, 2 May 2023 (UTC)

What are these "factors" that warrent an infobox? And why are they limited to C-class articles? Please elaborate. Nythar (💬-🍀) 14:44, 2 May 2023 (UTC)

... I feel like I'm taking crazy pills, isn't that what we've spent this entire conversation trying to figure out? Either factors for infobox inclusion or proxies that would generally indicate an infobox is appropriate.--Jerome Frank Disciple (talk) 14:46, 2 May 2023 (UTC)

But what are the factors? I'm totally confused. Any ideas? Nythar (💬-🍀) 14:49, 2 May 2023 (UTC)

... I mean, so far we've considered (as factors/proxies): (1) length of the article (in bytes), (2) number of parameters of a template that could be filled in, (3) class of the article, ... --Jerome Frank Disciple (talk) 14:51, 2 May 2023 (UTC)

I was thinking parameters, because then we'd have guidance for articles regardless of size, but I could be wrong. Which do you think we should focus on in this proposal? Nythar (💬-🍀) 14:56, 2 May 2023 (UTC)

I was personally partial to parameters, but, to achieve a consensus, I think we'd have to include exceptions. I suggested:

For biography articles, infoboxes are recommended if there is textual information^[a] that could be put in an infobox beyond what is found in the article's first two sentences.
^[a] That is, information aside from images, videos, or external links.
I don't think anyone would agree to a proposal if they thought it was endorsing an infobox so long as an external link or photograph could be included. But that thought generally wasn't well received, so we moved on. --Jerome Frank Disciple (talk) 15:02, 2 May 2023 (UTC)

Oh I agree, and I think that sounds good. But are you sure "two sentences" isn't arbitrary? Could it be improved, perhaps? Nythar (💬-🍀) 15:11, 2 May 2023 (UTC)

Sure, we could say "in the lead", if you wanted. But I really think @Nemov should probably take the lead on crafting the proposal here.--Jerome Frank Disciple (talk) 15:13, 2 May 2023 (UTC)

Perahps "first paragraph" is a better idea, as the lede can sometimes be too long to have to search through. The "first 100 words of the lede" sounds even better to me. Nythar (💬-🍀) 15:19, 2 May 2023 (UTC)

Final proposal

Here's a draft of the final proposal based on all the feedback. I suppose we'll use this to get an idea of how much support there is for a policy so this can be framed as support/oppose/alternative. If it's just a bunch of oppose any policy in general we can move on.

The use of infoboxes is neither required nor prohibited for any article.

For biography articles, infoboxes are recommend if there is information 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.

Any further changes? - Nemov (talk) 15:32, 2 May 2023 (UTC)

• Support - Seems excellent. I'd support that. Nythar (💬-🍀) 15:34, 2 May 2023 (UTC)

I am really concerned about how the reaction will be once external links are brought up, but Nythar if you're happy with that, I say go.--Jerome Frank Disciple (talk) 16:13, 2 May 2023 (UTC)

Nemov, could a footnote like [a] That is, information aside from images, videos, or external links be added, like Jerome Frank Disciple recommended above? Nythar (💬-🍀) 16:31, 2 May 2023 (UTC)

I would support the addition of the footnote. - Enos733 (talk) 16:35, 2 May 2023 (UTC)

this stage I'm kind of perplexed. What I've outlined is too strong, too weak, too vague, or too specific at the same time. t Nemov (talk) 16:35, 2 May 2023 (UTC)

@Nemov: The footnote is inteded to indicate that images, videos, and external links aren't what found in the article's first paragraph is referring to, and that they aren't contributing factors for deciding if an infobox should be included. Otherwise the proposal is good. Nythar (💬-🍀) 16:38, 2 May 2023 (UTC)

Well, you’d be right. It is all those things. It tries to take every possible side and it doesn’t work. Dronebogus (talk) 16:39, 2 May 2023 (UTC)

@Nythar: I think this works better than the footnote:

The use of infoboxes is neither required nor prohibited for any article.
For biography articles, infoboxes are recommend 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.

Textual implies not media, and then external links are the only thing set aside.--Jerome Frank Disciple (talk) 16:41, 2 May 2023 (UTC)

Oppose this is literally just the status quo. It solves nothing. It just codifies the established unwritten rule that each contentious article is WP:OWNed by editors who make their own arbitrary rules on a case-by-case basis, which inevitably just means “established anti-box editors get stonewalling privileges.” Dronebogus (talk) 16:14, 2 May 2023 (UTC)

So those are totally valid thoughts for Nythar to consider—but I'd suggest avoiding voting here. As many have said, the point of VPI is to help an editor craft a proposal, not determine whether the editors here would support the proposal.

I agree that the outcomes don't currently seem to follow much external logic. (As I said above, compare also the Pyotr Ilyich Tchaikovsky infobox, which was, by consensus, included, and the nearly identical Claude Debussy infobox, which was, by consensus, excluded.) But the point of the guidance is to create some more consistency by, well, providing more guidance. Maybe a mandatory rule—no infoboxes per or yes infoboxes always—would be the only thing that could do that, but I think the ArbCom decision is far to recent to try to implement any mandatory rule. --Jerome Frank Disciple (talk) 16:21, 2 May 2023 (UTC)

I’m going to be blunt: I want a mandatory rule, namely one in favor of all biographies of a normal length having infoboxes. But a guideline saying that is just as good in my opinion. Dronebogus (talk) 16:24, 2 May 2023 (UTC)

So Infoboxes should generally be used on all non-stub-length articles? You can try to propose that, but I'm really not sure it can attract a consensus. I could be wrong.--Jerome Frank Disciple (talk) 16:29, 2 May 2023 (UTC)

MOS:INFOBOXUSE already exists and makes no recommendation. How would this codify the status quo? Nemov (talk) 16:22, 2 May 2023 (UTC)

Because that’s not the reality. The reality is what I outlined above. Dronebogus (talk) 16:24, 2 May 2023 (UTC)

@Dronebogus: If you don't mind me asking, how would this proposal inevitably mean “established anti-box editors get stonewalling privileges”? This is a pro-infobox proposal; are you worried that it isn't pro-infobox enough? Nythar (💬-🍀) 16:34, 2 May 2023 (UTC)

Because literally any infobox could be blocked by saying “well the lead could say that too” or “that isn’t important information”. The only “pro-infobox” thing here is that infoboxes are recommended if, essentially, there is an external link available. Dronebogus (talk) 16:38, 2 May 2023 (UTC)

@Dronebogus: Then what would you have first paragraph be changed to? Perhaps first 75 words or first 50 words? They can't stuff everything into that, now, can they? If an article is so short that everything exists in the first two or three sentences, it probably wouldn't need an infobox anyway and would be considered to be a stub. Nythar (💬-🍀) 16:48, 2 May 2023 (UTC)

I don’t like arbitrary numbers. To me, a stub here is any article that physically couldn’t fit an infobox, rendering one clumsy and pointless. Dronebogus (talk) 16:50, 2 May 2023 (UTC)

• I've started drafting the proposal. If anyone would like to contribute to the details/background that would be great. We can plug in whatever the final policy ends up being. Nemov (talk) 16:54, 2 May 2023 (UTC)

I like that better. Just outright saying “infoboxes are recommended for biographies” is good. What I’m worried about is having to re-litigate the wheel with inevitable questions of “but WHY are they recommended?” (I’ve outlined the long, long list of reasons at the link below). Dronebogus (talk) 16:59, 2 May 2023 (UTC)

Yeah like, I'm thinking for instance "What would an anti-infobox editor say about Marcus Beeck? How would we deal with that? Nythar (💬-🍀) 17:05, 2 May 2023 (UTC)

Generally speaking the idea here isn't to argue about infoboxes. Editors who comment on this either have to believe infoboxes are useful, they're not useful, or they don't care enough to have a policy for it. Nemov (talk) 17:07, 2 May 2023 (UTC)

There are articles that are too short and contain too little information to have infoboxes. In the proposal discussion, someone could argue against this new proposal by saying it doesn't draw a line between which articles do and which do not qualify for infoboxes. Even if this proposal passes, we're still stuck with the fact that it doesn't specify when we should add infoboxes to articles; we'd need to have an RfC for every article to determine that. There needs to be guidance or else nothing would meaningfully change. Nythar (💬-🍀) 17:26, 2 May 2023 (UTC)

I stated this already, but I think the standard should be: “will an infobox literally even fit on the page without overwhelming it?” Dronebogus (talk) 17:29, 2 May 2023 (UTC)

I think we should still state the primary reason we’re arguing for standardization is not “infoboxes are SOOOO GOOOD” but rather the aforementioned very good point that recent “local consensus” has been wildly arbitrary with no logic between articles. Dronebogus (talk) 17:27, 2 May 2023 (UTC)

Woah! We went pretty dramatic on the proposal all of a sudden. Infoboxes are recommended for all biographies? To be clear, if Nythar or Dronebogus wants to go with that, great—as has been said, VPI is the place to help editors craft a proposal that they want. But if we're taking that extreme a position, I'm very skeptical a favorable consensus is even possible.--Jerome Frank Disciple (talk) 17:30, 2 May 2023 (UTC)

Why? What is the point of opposing these anymore? Dronebogus (talk) 17:35, 2 May 2023 (UTC)

I mean that's based on my analyses of the debates so far. Based on this conversation, I think you're probably one of more the radical pro-infobox users. (Which, to be clear, is fine!)---Jerome Frank Disciple (talk) 17:38, 2 May 2023 (UTC)

Agree, some level of pragmatism is going to have to be used to find consensus on this topic. I don't believe a rigid guideline is going to be acceptable at this point. Nemov (talk) 17:40, 2 May 2023 (UTC)

My analysis, if you’re referring to infobox rfcs, was that consensus as a whole swings pro-box but a handful of hardline anti-box users are able to drag debates out into “no consensus” and a few more say “well they know best since they edit the article more” Dronebogus (talk) 17:41, 2 May 2023 (UTC)

Based on what Nemov just said and what Nythar and I are saying ... I think that's an exceedingly optimistic analysis.--Jerome Frank Disciple (talk) 17:43, 2 May 2023 (UTC)

@Dronebogus if there's a desire for a stronger policy it will likely be voiced during the RfC. If a consensus for that were to happen changes to the proposal could be made. Nemov (talk) 17:54, 2 May 2023 (UTC)

I don't want to go with that. I believe the old proposal above is best. Nythar (💬-🍀) 17:35, 2 May 2023 (UTC)

Oh okay, well, Nythar, if you're already ready to propose an option, I guess the thing to do is to start an RFC at Wikipedia talk:Manual of Style/Infoboxes? (I'm not actually positive that's the next step, but it seems reasonable to me)--Jerome Frank Disciple (talk) 17:40, 2 May 2023 (UTC)

I was thinking we'd post it at WP:Village Pump/Proposals because there it'll be more visible. That way we'd also avoid the heavily opinionated environment of Wikipedia talk:Manual of Style/Infoboxes. This is my proposal. Any improvements? Nythar (💬-🍀) 17:57, 2 May 2023 (UTC)

Sounds good! I did make one change—I think you took my earlier suggestion to specify multimedia, but, once I thought about it, I realized that didn't make sense (I was using multimedia as a synonym for videos and pictures, but that's not right ... and since it already says "textual information", no need to be redundant.) Also, I do think you should post notice at Wikipedia talk:Manual of Style/Infoboxes--Jerome Frank Disciple (talk) 18:02, 2 May 2023 (UTC)

@Jerome Frank Disciple: I'm having some trouble writing the background section. Any help is appreciated. Nythar (💬-🍀) 18:11, 2 May 2023 (UTC)

@Nythar you can check out my draft as well, I had started a background section you can build off. Nemov (talk) 18:15, 2 May 2023 (UTC)

@Nemov: Please review it and improve it if necessary. If it's fine, I will proceed and propose this at the village pump. Nythar (💬-🍀) 18:24, 2 May 2023 (UTC)

@Jerome Frank Disciple @Dronebogus please review. It's not perfect, but it's better than the currently non-guidance. Nemov (talk) 18:27, 2 May 2023 (UTC)

Shoot I started writing a background before I saw @Nemov's post, and then I got edit conflicted. I've added my version of the background—which includes the table I made and a few key points I made above but I think that we all agree with, in case you want to blend the backgrounds.--Jerome Frank Disciple (talk) 18:36, 2 May 2023 (UTC)

Outstanding. Great work. Nemov (talk) 18:38, 2 May 2023 (UTC)

I've removed the other background in favor of what you wrote. I will post this at the village pump now. Nythar (💬-🍀) 18:43, 2 May 2023 (UTC)

Okay! I just made a final copy edit :) Good luck! I hope you feel like coming here helped you to craft the proposal. I have to run but I'll check in tomorrow. --Jerome Frank Disciple (talk) 18:46, 2 May 2023 (UTC)

Are we going to close the other discussion so it's not confusing? Should probably ping those who commented. Nemov (talk) 18:48, 2 May 2023 (UTC)

Good call—I agree.--Jerome Frank Disciple (talk) 18:49, 2 May 2023 (UTC)

Did all I could! I closed the older discussion and tried to ping everyone—I'm in a bit of a rush, so I may have missed someone? Someone might want to double check. Sorry if so!--Jerome Frank Disciple (talk) 19:06, 2 May 2023 (UTC)

Eh, it’s not my ideal proposal, but that’s not really a problem I can “fix”. Dronebogus (talk) 18:06, 2 May 2023 (UTC)

I think this draft continues to be something focused on drawing a big circle around articles for which infoboxes are recommended, rather than trying to build a consensus view accommodating the concerns raised regarding the shortcomings of infoboxes. The proposal may still gain sufficient numerical support to proceed. However I don't think it will help build buy-in from those who feel an infobox is unnecessary for a given article. I feel it will shift the arguments to what should be included in an infobox, with pressure to essentially make it a mini-article. isaacl (talk) 17:12, 2 May 2023 (UTC)

Yes, that’s exactly what we should be doing here and are doing here— drawing a big circle around the articles we’ve argued enough about. Dronebogus (talk) 17:25, 2 May 2023 (UTC)

"Should" depends on what approach is being taken. If you just want a proposal that includes infoboxes in as many articles as possible, sure. If you want to try to get as many people supporting a change in guidance as possible, accommodating concerns is desirable. isaacl (talk) 17:40, 2 May 2023 (UTC)

I'd agree—this guidance is limited, and it will result in people stretching infobox parameters. But, hopefully, that kind of stretching can usually be called out and won't appeal to most participants in an RFC. That said, do you have any ideas for a proposal that does build a consensus view accommodating the concerns raised regarding the shortcomings of infoboxes? In a way, the "article-by-article" approach suggested by ArbCom does that, but, as we've seen ... that's not what's happening, and I do think it's fair to take into account that—at least based on the RFCs that reached a consensus—there seems to be a trend towards accepting infoboxes.

As I see it, the Nythar proposal (at least as of the last edit) doesn't supplant the article-by-article approach, but, rather, uses parameters and repetition as a proxy for whether an article would benefit from an infobox—though still making clear that an infobox shouldn't automatically be added to such articles. In essence, I see it as creating a default position. Now, will it change anything? Very possibly no. But maybe it's a start.--Jerome Frank Disciple (talk) 17:28, 2 May 2023 (UTC)

I think the unwritten point of this discussion is that the ArbCom solution isn’t working and infoboxes should just be standardized in one way or another, so that should be our goal here. Dronebogus (talk) 17:31, 2 May 2023 (UTC)

I mean I think you're packing two different ideas in there. It's one thing to say the ArbCom solution isn't working—I say that, because editors aren't taking an article-by-article approach. But it's another thing to say that the ArbCom decision was wrong and we should be treating infoboxes as a maintenance task, with a goal of standardization. I mean, "The ArbCom decision isn't working for people who always/never want infoboxes" is undoubtedly true, but that's not quite what I mean when I say "not working"--Jerome Frank Disciple (talk) 17:34, 2 May 2023 (UTC)

I've made suggestions earlier regarding how to set the baseline for discussions on specific articles. I appreciate, though, that those who support having infoboxes in every non-stub biography prefer guidance that is less dependent on discussions weighing considerations for each article. isaacl (talk) 17:54, 2 May 2023 (UTC)

What would a version of your guideline look like? Nemov (talk) 17:56, 2 May 2023 (UTC)

As I mentioned before, I think we should look at the objections in the various discussions for each article, and consider under what circumstances can an infobox be written that avoids these objections. Of course, it's fine that participants are more interested in other ways at defining a guideline. I've only raised it again for this current draft in order to highlight that it's not one designed to gain further broad support with the community. That's not the end of the world, however it's likely to be dissatisfying to a significant percentage of editors, including those who don't feel strongly either way but would prefer to see a solution that attracts more support from editors with diverse viewpoints. isaacl (talk) 18:10, 2 May 2023 (UTC)

I mean, a bit easier said than done, no? (I assume that's why you haven't done it?) Also, as I've said, a lot of these debates (which I linked to above) are dominated by hardliners—people who always support or always oppose infoboxes. I actually think "consider the amount of useful information that could be put in a template" does address the article-by-article concerns; it just also sets a threshold by which an infobox is recommended, owing to the apparent increasing desire for infoboxes among the community.--Jerome Frank Disciple (talk) 18:17, 2 May 2023 (UTC)

It’s the same situation as always, just with slightly different wording. Dronebogus (talk) 18:25, 2 May 2023 (UTC)

It's of course easier said than done; it's also not something that can be done alone as the whole point is to build a group consensus. Since no one followed up on the suggestion earlier, that indicates this particular group of participants doesn't feel it is a good fit for their objectives. isaacl (talk) 20:58, 2 May 2023 (UTC)

I mean I'm the one who gathered all the prior examples of discussions and summarized them, and several people have chimed in here with there opinion that there should be no guidance or that we should, as a rule, not have infoboxes on these pages. I'm sorry if you feel there was a "make everyone happy" solution that we missed, and I wish you luck if you decide to dedicate yourself to finding that solution.--Jerome Frank Disciple (talk) 21:04, 2 May 2023 (UTC)

It's not necessary to make everyone happy. Proposals can be priced to move, though, to gain maximum support. However I appreciate that simpler guidance is frequently more effective than more complex guidance, so that's an advantage of just recommending infoboxes for all biographies. isaacl (talk) 21:32, 2 May 2023 (UTC)

• Another piece of housecleaning... should we close the other discussion? It's just muddying the waters at this point. When this is officially presented someone can ping those commented there. Nemov (talk) 18:22, 2 May 2023 (UTC)

  I commented there just to be safe, so yeah it’s definitely too confusing. Dronebogus (talk) 18:23, 2 May 2023 (UTC)

Alternate proposal

I made a draft proposal about infobox standardization a while back. I thought I should probably link to it here as it seems relevant. Dronebogus (talk) 16:35, 2 May 2023 (UTC)

If you're actually serious about proposing those, I would suggest using option 1. No one who opposes option 1 will support option 2.--Jerome Frank Disciple (talk) 16:45, 2 May 2023 (UTC)

Okay, option 1 it is Dronebogus (talk) 16:48, 2 May 2023 (UTC)

Alternate proposal 2

Infoboxes aren't additions to the lead. They are an even more brief and structured way to show some key factoids.

Infobox debates usually are one of these two things:

• IMHO trying to put something into an infobox that shouldn't be there.. Typically it's some judgement call/ characterization type item. Being inherently brief where explanation, clarification, calibration or attribution is required but won't fit, IMO these are items that should be left out

• Somebody wanting to put in an info box when there isn't really good material for one (see previous item) Happens often on biographies.

So my proposal is: Regarding presence of infoboxes in articles, and inclusion of items in infoboxes: When in doubt, leave it out.

Sincerely, North8000 (talk) 17:31, 2 May 2023 (UTC)

No. Absolutely oppose. That’s just trying to brute-force the situation away from the emerging meta-consensus that infoboxes are normal and expected in biographies. Dronebogus (talk) 17:33, 2 May 2023 (UTC)

RfC posted at Wikipedia:Village pump (proposals)#RfC on establishing a biography infobox guideline. Nythar (💬-🍀) 18:50, 2 May 2023 (UTC)

Final thoughts

If this topic comes up again I would recommend the alternative that was proposed during the discussion. The use of infoboxes is neither required nor prohibited for any article, although for biography articles, infoboxes are recommended. This proposal is probably the best path forward. Some of the the opposes seemed confused about this being a mandatory solution. The language of the background could have done a better job outlining the problem and how this would solve the contentious discussions on longer articles. There's no issue with small articles and the suggestion that a simple recommendation would cause arguments on smaller articles is a bit of a fantasy. Also, there was far too much arguing from the support side that wasn't helpful. It just creates a wall of text, creates confusion, and discourages comment. A note in the background recommending that debate be held in the discussion section would help keep the survey cleaner. Thanks for all the help with this idea. Nemov (talk) 14:08, 9 May 2023 (UTC)

There’s little practical difference between that and the existing guideline. No IB is mandatory anywhere, and “the best path forward” is the status quo that allows flexibility depending on the individual article. - SchroCat (talk) 21:25, 10 May 2023 (UTC)

Invisibility of the original source of a topic

I refer to a lot of Sanskrit and Vaidika Literature. I have noticed that wherever the information is authenticated there are systematical references, listed under the heading References, which are very useful for further readings. Unfortunately, these citations include only those scholars or writers, who have, either studied, researched and written about it in the near past. Actually, the original source is not given as a reference, although it may be stated in the main body as a part of a statement. For example, take Sanskrit word Nyaaya. The article gives the dictionary meaning by Monier-Williams' Sanskrit-English Dictionary, Cologne Digital Sanskrit. Lexicon, Germany, but its origin in the Nyaaya Shaastra is missing. Almost all references appear to be following the same system! We seem to be losing the True Source of Knowledge, and inadvertently, authorizing the knowledge of commentaries and researches only. I do not mean to devalue them in any way; but how could there be a river without it original source? It means, all articles may have perfect citations, but without the Origin of the Knowledge! I feel it needs to be improved and changed. Thank you. Hasujee (talk) 14:36, 2 May 2023 (UTC)

Wikipedia is a work in progress, and if you find something lacking, that is almost never by design, but almost always because no one has done it yet. This being English language Wikipedia, most of the writers of the articles will be using English language sources, which for the material you note, is often many generations removed from the source texts. If you are familiar with the source material in question, you can add it where needed, perhaps alongside the already cited English-language sources. If there is additional information to be gleaned from those sources, you can also use them to expand Wikipedia articles. --Jayron32 14:43, 2 May 2023 (UTC)

For clarity, WP:NONENG sources are permitted; they're just not popular. WhatamIdoing (talk) 14:40, 5 May 2023 (UTC)

Absolutely, my commentary was based on what has been done rather than what could be done. Up to now, (and likely into the future), most of English Wikipedia is written by English speakers who are only familiar with English language sources, so existing content is largely cited to English sources. However, non-English sources are perfectly fine. It's just that so few people here are often familiar with them, or the languages that they are written in, that they aren't often used. Nothing wrong with them. I (and most editors here, I suspect) don't speak all of those other languages to mine their corpus for good sources. --Jayron32 16:00, 5 May 2023 (UTC)

Regardless the truth of WP:NONENG, I do see AfDs with rationale like "cannot locate English language sources ... therefore fails WP:N." (Source; specifically chose an AfD resulting in delete so as not to impugn the nom despite their rationale.) Perhaps increased messaging around the acceptability of non-English sources would be beneficial? Folly Mox (talk) 22:59, 7 May 2023 (UTC)

Did anyone find any Chinese Language sources for that article? Wikipedia needs actual sources to write articles from, and no sources is a good reason to delete. We don't just keep an article around because no one has proven that no sources exist; quite the opposite, someone actually has to show sources exist. Can you please provide the Chinese Language sources (or any other language) that would demonstrate notability? I don't read Chinese, but if someone who does will confirm the source material is solid and meets WP:GNG, I'll undelete that article immediately. --Jayron32 12:27, 8 May 2023 (UTC)

Sorry if my example was confusing. I deliberately chose an example that turned up no notability-establishing non-English sources despite the nominator's poor rationale. The AfDs of this genre where sufficient non-English sourcing is already present in the article at the point of nomination do close as keep, so the system is working, but they do waste time. I didn't want to bring those examples here because I didn't want to chasten anybody specifically. Folly Mox (talk) 12:54, 8 May 2023 (UTC)

It's not really a waste of time. Taking time to get it right is always well spent. --Jayron32 18:48, 8 May 2023 (UTC)

I haven't looked at any of the articles about Sanskrit and Vaidika literature, but in general the original source for anything will be a primary source, which is discouraged on Wikipedia. We usually prefer articles to be based on secondary sources, to avoid interpreting primary sources ourselves. Phil Bridger (talk) 19:40, 2 May 2023 (UTC)

My personal experience – as seems frequently the case – has been the opposite. My content work is primarily in early Chinese topics, and although we don't see a huge amount of primary sources there, I frequently see articles sourced entirely to secondary sources compiled hundreds or thousands of years ago, presumably because they're all freely available online where recent scholarship is locked behind paywalls or under copyright in books that are difficult to obtain without access to a legitimate research library system.

User:Hasujee, if you have access to earlier materials that are quoted by or interpreted by secondary sources cited in articles in your topic area, you can always add that information, or a reference to the primary material so quoted or interpreted, in an adjacent citation or somewhere else in the footnote, to help other readers trace the river back to its source. If you're more concerned that we privilege secondary sources, that's by design, and anyone interested in diving more deeply into the topics we cover is guided to the published and peer-reviewed literature as their next step. Folly Mox (talk) 22:27, 7 May 2023 (UTC)

Under the English Wikipedia's rules, if the source is hundreds or thousands of years old, it should be treated as if it were a primary source. WhatamIdoing (talk) 23:59, 12 May 2023 (UTC)

Personally I still think that in most cases it shouldn't matter whether a source is primary, secondary, or tertiary, the one exception being when we're evaluating WP:N. The rest of the time we demand that any source be reliable and that we don't analyze or synthesize beyond what the source actually says regardless of the "type" of source. Yes, to write a good article we need sources that give us analysis and interpretation to use, but arbitrarily labeling those "secondary" and others "primary" doesn't really help. Anomie⚔ 12:31, 13 May 2023 (UTC)

• You seem to be talking about Nyaya and Nyāya Sūtras - the spellings you use are redlinks. The 2nd is certainly mentioned in the first article, and from them it seems the word was in use well before the Sutras, so "its origin in the Nyaaya Shaastra is missing" may be rather misleading, and quoting a dictionary definition is perfectly appropriate. According to nyaya the philosophical approach had been developing for some centuries before the time the Nyāya Sūtras seem to have been written. In general, we should use modern references, adding key primary ones either in the text or notes. The best articles do this. Johnbod (talk) 13:17, 13 May 2023 (UTC)