Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59

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)

Modifications to the default settings of Vector 2022

While it isn't clear whether the close of the Vector2022 RfC will stand, I believe it is still beneficial to determine what modifications we want to make to the skin. This would include both modifications that we can make by editing MediaWiki:Vector-2022.css and MediaWiki:Vector-2022.js, and modifications that we would need to ask the WMF to make.

I'm opening this discussion to determine the format of that discussion, and to determine which changes should be discussed as part of it.

For format I believe a multi-part RfC would be best, with each proposed change a separate question. For the questions I have created an initial list of those I consider worthy of discussion; I have included questions that I would support and questions that I would oppose but expect to have some support among the broader community.

• Main menu:
  1. Should the main menu be visible by default?
  2. Should the choice to expand or collapse the main menu be persistent?
• Header:
  1. Should the mystery meat buttons be replaced with text buttons?
  2. Should readers be able to disable the sticky header?
  3. Should the sticky header be disabled by default?
  4. Which, if any, of the following should be moved out the right hand drop down menu and moved into the header bar?:

     A: "User talk"

     B: "User sandbox"

     C: "User preferences"

     D: "Beta"

     E: "User contributions"

     F: "Log out"

• Table of contents:
  1. Should pages include a table of contents at the top of the article, similar to Vector2010, in addition to the sticky table of contents?
  2. Should sub-headings in the floating table of contents start expanded (Collapsed sub-headings, expanded sub-headings)?
• Other:
  1. Should the previous state of the article title bar be restored (Previous state, current state)? This would involve:
     • Moving coordinates to be inline with the slogan "From Wikipedia, the free encyclopedia"
     • Moving icons denoting page protection, featured status, etc for featured article, to be inline with the article title
     • Moving the language selector to the main menu
  2. When a user selects "expanded width", the content only expands to use the white space on the left of the page, not the right. Should the white space on the right also be used? (This question may have already been asked, depending on the interpretation of "full width by default")

BilledMammal (talk) 14:53, 19 March 2023 (UTC)

• Main menu: 1. yes; 2. no.
• Header: 1. neutral; 2. yes; 3. yes; 4. C, D, F.
• Table of contents: 1. yes; 2. yes.
• Other: 1. yes; 2. the page should be expanded by default as it was in V10.

Æo (talk) 12:12, 20 March 2023 (UTC)

Why shouldn’t the main menu choice be persistent, and why shouldn’t the sticky header be enabled by default? Also, why should beta and logout be out of the drop-down instead of more obvious choices such as the talk? Aaron Liu (talk) 01:45, 2 April 2023 (UTC)

With Vector-2022 now having passed all the hurdles to remain as the default this question becomes more relevant and input from interested editors is welcomed. Please also see the discussion at VPT about implementing the consensus to set Vector 2022 to full width by default. Note that this isn't the RfC yet, and is instead attempting to work out what questions should be asked, rather than asking those questions. BilledMammal (talk) 20:30, 29 March 2023 (UTC)

I don't think it's helpful to bundle all of these into one RfC, or even into multiple simultaneous RfCs. It's a lot to go through, and the issues are not all of similar priority. CMD (talk) 01:23, 30 March 2023 (UTC)

That makes sense; which ones do you believe have a higher priority? BilledMammal (talk) 01:25, 30 March 2023 (UTC)

I would combine the Main menu questions into one question. I would also ask header question 4 and TOC question 1. These are the questions that seem most relevant to the average Wikipedian, or reader. The most important ones IMO are the main menu questions and the TOC question.

On a side note, V2022 is pissing me off. I always switch back to it when I want to engage in discussion about it, and I just noticed that there is no direct way to generate a random article—you have to reach into the dropdown, click Special Pages, and scroll until you find it, or alter urls. Why? I don't get it. It was there before. How am I supposed to hone my wikipedia game skills? Cessaune [talk] 14:25, 1 April 2023 (UTC)

@Cessaune The hamburger menu/main menu has random page, just like how everything above what links here is there. Also, I agree with your suggestions on the upcoming RfCs. Aaron Liu (talk) 01:46, 2 April 2023 (UTC)

Ah. Good. I assumed it would be under Tools. Cessaune [talk] 02:36, 2 April 2023 (UTC)

@BilledMammal: Can we proceed with this? Æo (talk) 13:06, 4 April 2023 (UTC)

Needs to draft first IMO, the early version of rbv22 shouldn’t repeat Aaron Liu (talk) 13:22, 4 April 2023 (UTC)

You are asking the WMF to make a bunch of micro-configuration changes that will be specific to this wiki and take time to implement. I agree with what TheDJ has been saying—giving this much decision-making power to the community on these aspects are a bad idea. These tickets will all be closed as invalid. Snowmanonahoe (talk) 14:07, 4 April 2023 (UTC)

WMF can decide that they don't want to give this much power to us. We shouldn't be limited by the idea that WMF might try to limit us. We should proceed and see what happenes, I think. Cessaune [talk] 16:35, 4 April 2023 (UTC)

I think his point is “we should leave aesthetics to the professionals not the community”, which I disagree with. Aaron Liu (talk) 16:49, 4 April 2023 (UTC)

Not just because professionals may be better at picking, but they also fully understand what's possible. They mentioned on the Discord that they knew the unlimited default width would be impossible from the start. I imagine most of these changes will have similar issues. We may be able to make them via JS and CSS, but if a lot of these end up being different from how they currently are special pages will look significantly different from normal pages. Snowmanonahoe (talk) 18:35, 4 April 2023 (UTC)

Selena Deckelmann mentioned on the Discord that they knew the unlimited default width would be impossible from the start—what. Why? And, even if this is the case, why was this not mentioned in the RfC?

Also, I don't see why most of these questions would be technically impossible to implement, or even hard. Something like a dual static/sticky TOC might be hard to implement, but we already know it is possible to move stuff out of dropdowns (Log in) and we know that persistence is possible. Cessaune [talk] 18:41, 4 April 2023 (UTC)

We already have a css (CSS!) hack to implement unlimited width, why would it be impossible? Aaron Liu (talk) 19:25, 4 April 2023 (UTC)

This looks like it could end up being 10 RFC questions, or worse, a single RFC that a closer would have to try to assess consensus for in 10 different areas. I am a bit worried that the ROI on this would be low. That is, it'd take a lot of editor time and not necessarily result in the WMF listening to us. Perhaps we should focus our political capital and editor time on getting unlimited width implemented first. Another thing we could do is create these 10 tickets on Phab, which is the normal way to request software, and see if any get accepted. Some of these likely already have Phab tickets - perhaps these phab links can be edited into the original post, and we can see if any of these features are both popular and declined, and then discuss and decide if we want to push for some of these further. –Novem Linguae (talk) 20:53, 4 April 2023 (UTC)

I don't know what is ROI, but we could open 10 RFCs on a single page. Æo (talk) 12:51, 5 April 2023 (UTC)

I think they mean a figurative Return on Investment Aaron Liu (talk) 13:45, 5 April 2023 (UTC)

Yes, I meant return on investment. In other words, is the benefit worth the effort? Another mega RFC / 10 little RFCs is quite a bit of editor time if WMF isn't likely to action it. –Novem Linguae (talk) 20:44, 5 April 2023 (UTC)

If the Wikipedia community is worth anything, then another RFC / 10 little RFCs are worth the effort. It is the only way for the community to manifest its views to the WMF. Æo (talk) 00:49, 6 April 2023 (UTC)

Seconded. It's only an RfC,one that could potentially define, for a long time, how enwiki functions. RfCs are costly, and there might not be a 'return on investment', but the enwiki community isn't a company, and, at the worst, a bit of time was wasted. Cessaune [talk] 01:21, 6 April 2023 (UTC)

RFCs aren't the only way for this community to manifest its views to the WMF, although it's the only one most members would think of, if you believe Conway's law.

Editor time is valuable. Let's not waste any of it. If you think these are good ideas, then let's write them up in Phab:, and see what the team does with them. If they think that need evidence of community support, then the Phab tasks will get a community-consensus-needed tag added. If they think they're good ideas, then they'll likely prioritize them and implement them. If they think they're bad ideas, they'll likely give you an explanation for why, which could be valuable for any future discussions. Whatamidoing (WMF) (talk) 20:57, 6 April 2023 (UTC)

I don't think this would be efficacious and that it would represent the general view of the community. What we are discussing here are ways to represent the general view of the community. Moreover, the team have already demonstrated that they are not willing to follow the community's consensus. Æo (talk) 19:22, 7 April 2023 (UTC)

Is this project stalled?

Is this project stalled? Æo (talk) 23:38, 14 April 2023 (UTC)

@BilledMammal: ? I cannot believe that the silent majority of users are passively accepting this imposition of an interface which is obviously hideous and destined to damage the project. Æo (talk) 08:03, 15 April 2023 (UTC)

1) It's not objectively hideous, let's not pretend like everyone hates it. In fact, there is a lot about V2022 I like.

2) Destined to damage the project? How? Cessaune [talk] 14:31, 15 April 2023 (UTC)

1) 60% of the community opposed it. 2) That is indeed my opinion; I think that the mobile-esque design will inevitably lead to a further fragmentation and loss of quality of the articles' content, because of structural reasons which were widely discussed in the RfC. Æo (talk) 17:18, 15 April 2023 (UTC)

From what I've seen in the RfC, the removal of the inline ToC simply disrupts certain people's geometry of the article, not the article content itself? Aaron Liu (talk) 18:37, 15 April 2023 (UTC)

There are many other controversial aspects beyond the ToC, which is indeed a major one. For instance, I see that the font size in V22 seems to be bigger than in V10. I don't think this is an improvement; I feel better with the smaller font and wider texts of V10. Has this ever been discussed? Æo (talk) 13:13, 16 April 2023 (UTC)

Both skins' body text font sizes are 1em * 0.875, defined in div#bodyContent. The font size didn't change. So what aspects harmed article content quality besides ToC, which I'm still not quite convinced of? Aaron Liu (talk) 13:42, 16 April 2023 (UTC)

The main one is certainly the ToC, the other one is the general shrunken appearance of the articles' spaces. V22 gives (me) the impression, at the same time, of both "wasted white space" and claustrophobic "lack of space". Æo (talk) 14:29, 16 April 2023 (UTC)

Wasting lots of space doesn't lead to degraded article quality. Aaron Liu (talk) 15:43, 16 April 2023 (UTC)

Shrinking the articles in a smaller space certainly does. There is something weird in the general appearance of V22, and it has been expressed in different terms by different users according to their different outlooks. It is a general weird appearance given not by a single characteristic but by many of them together. For some it is the width, for others it is the ToC, for still others the menus. In general terms, V22 has not been appreciated by the community. Æo (talk) 16:14, 16 April 2023 (UTC)

I don't find this argument particularly compelling. The community you refer to is no where near agreement on anything pertaining to V2022. V22 has not been appreciated by the community—maybe? This is just opinion; personally, I think it's pretty evenly split.

Secondly, how does shrinking the articles in a smaller space lead to degraded article quality? I mean, I don't like the shrinking, but I don't see how smaller body size is necessarily good or bad. Cessaune [talk] 16:30, 16 April 2023 (UTC)

Hasn't 60% of the users who took part in the RfC opposed V22? 60% is the majority. Æo (talk) 19:09, 16 April 2023 (UTC)

You will have a hard time proving that is representative of all users. I strongly suspect that many users who are satisfied with V2022 (as I am) didn't bother to participate in that RfC. Donald Albury 19:23, 16 April 2023 (UTC)

I think the RfC was a good representation of the opinion of the general community. I also read comments by users (including at least two admins) who defined V22 "horrible" and yet did not take part in the RfC. Æo (talk) 19:28, 16 April 2023 (UTC)

P.S. A majority, in this case an absolute majority, in any case is not representative of all users, it is representative of significantly more than half of them. Æo (talk) 19:42, 16 April 2023 (UTC)

60% isn't representative of the general community, just most of it. 40% is still quite big. Plus it's 58.7% if you count the neutrals, which doesn't count as an absolute majority. Aaron Liu (talk) 20:41, 16 April 2023 (UTC)

An absolute majority is by definition a majority over 50%. 60% is the absolute majority of the Wikipedia community; 40% is a big minority. Æo (talk) 20:59, 16 April 2023 (UTC)

Huh, I may have confused it with other qualifiers of majority. Still, 40% is a very big minority, so you can't use 60% to represent the entire community. Aaron Liu (talk) 21:27, 16 April 2023 (UTC)

Selection bias plays such a major factor in all of this that I think using direct numbers isn't a good way of going about things. Cessaune [talk] 21:28, 16 April 2023 (UTC)

As I already wrote above, I think that the general opinion of the community was well represented in the RfC. Æo (talk) 15:16, 17 April 2023 (UTC)

Whenever I am not logged in with my account (set with V10) and I have to read a Wikipedia page in V22, I find it repulsive; the new structure and organisation of spaces is literally distracting, disturbing and annoying. While the font looks bigger, all the elements of the page look cramped, and at the same time they look disconnected, disorganised and confusing. The ToC does not provide a structure to the article and the two appear as separate things. Æo (talk) 15:26, 17 April 2023 (UTC)

Okay. This, however, is all opinion. How do you qualify the statement that V22 has not been appreciated by the community? None of the things you are saying are objectively true. Cessaune [talk] 15:27, 17 April 2023 (UTC)

For me, that V22 has not been appreciated by the community — at least by a significant majority of it (the aforediscussed 60%) — is a fact. The things I have expressed have been widely discussed, from different points of view, in the RfC. Æo (talk) 15:34, 17 April 2023 (UTC)

58%/60% is an absolute majority but not a significant one. Aaron Liu (talk) 15:37, 17 April 2023 (UTC)

That absolute majority does not even represent merely a non-appreciation, but also a rejection, since the opinion vote was for V22's withdrawal, i.e. against its deployment. Æo (talk) 15:44, 17 April 2023 (UTC)

As I said above, the font is the same size as it was before. Aaron Liu (talk) 15:31, 17 April 2023 (UTC)

It looks bigger, maybe due to an optical effect. Æo (talk) 15:36, 17 April 2023 (UTC)

Looks the same to me, on my screen. Cessaune [talk] 15:40, 17 April 2023 (UTC)

Dear Lord, if this isn't bludgeoning, I don't know what is. There's a simple solution: change your personal skin. Here. Wikipedia is a global multilingual project, why would you wanna change the user experience only here and only based on anonymous unqualified opinions of a few? It's sad that this is happening. I'm sure many are getting tired of it. 38.68.160.148 (talk) 18:30, 17 April 2023 (UTC)

How is this bludgeoning? It's not a ton of comments repeating the same thing, it's a couple of different proposals on a topic. Aaron Liu (talk) 19:25, 17 April 2023 (UTC)

• @User_talk:38.68.160.148 "based on anonymous unqualified opinions of a few". In my (anonymous, but possibly professional) opinion - most of the feedback was high quality and the users/editors are passionate and knowledgeable. The WMF devs tried to engage (but it was with a completed product), but they were constrained by centralisation and the mission which you mentioned indirectly
• " Wikipedia is a global multilingual project, why would you wanna change the user experience only here' Other wikis have also complained. Wikipedia is not a global multilingual project - it's a series of once off translations of content that swamps local editors and destroys editor community building . (Christian missionaries are the only one other group that translates into 300+ languages ).
• 'There's a simple solution: change your personal skin" It is unjust if readers don't have the same choice. It should be changeable everywhere as users similar to editors (just the same as developers and researchers) NEED control of their environment thrugh preferences, information density, and efficiency (often to the point of negative cost/benefit because something annoys them); Wikipedia is an IDE for the editors, and similar to all IDEs an information dense screen is needed.

Wakelamp d[@-@]b (talk) 16:42, 1 May 2023 (UTC)

I think that EN:Wikipedia is the best ones to make these decisions. Wikipedia is the ship that the WMF ivory tower and it's pet projects rides on. And until we can implement structure for the Wikipedias to decide together, en:wikipedia being the largest is the best place for that to come from. The largely self-appointed WMF ivory tower certainly isn't. North8000 (talk) 20:37, 17 April 2023 (UTC)

From the WMF's viewpoint, I expect the project is now permanently stalled. They've achieved their objective of pushing out Vector 2022, its developer has left the organisation, and the rest of the WMF team will have moved on to changing something else. If there's consensus to mitigate some of the worst effects of the new skin, it's now up to enwp to implement it locally. Certes (talk) 08:11, 18 April 2023 (UTC)

AHollender was the lead designer, not the sole developer. Of course there's still a team on v22. Aaron Liu (talk) 11:44, 18 April 2023 (UTC)

• Should we set up a page so we can coalesce all the comments? We are good at creating articles, but our community discussions tend to become very large and eventually just sort of end.
• As part of that it would be good to discuss how WMF's engagement with the community could be improve. "The non-profit noted that it has worked with 30 different volunteer groups from all over the world, including from India, Indonesia, Ghana, and Argentina to conceptualise and actualise the improvements made to the desktop interface, which is the first major redesign introduced by Wikipedia in over 10 years." [2].
• I am sorry to hear he left, as I liked that they and their teams were trying to engage. (I am not certain whether his article on V2022 has been mentioned so I have included a link. [3].
• The claimed benefits seems very high though. "Wikimedia Foundation makes clear that it hasn't removed any functionality, and that the changes led to real-world gains in testing with international volunteer groups. Users searched 30 percent more often, and scrolled 15 percent less. " [4]. I would also be concerned about the reasons for more searching and less scrolling - both of those could have an opposite explanation in terms of vector 2022 creating a worse UX.

Wakelamp d[@-@]b (talk) 17:33, 1 May 2023 (UTC)

That’s a great idea! Problem is what comments we should include and whether we should just merge it in an existing article like Wikipedia:Vector 2022 Aaron Liu (talk) 17:40, 1 May 2023 (UTC)

Support: The discussions about V22 have become rambling, and therefore fewer users are seeing them and taking part in them. It would be better to gather them on a single page. I also agree with the concern: who says that more clicks are better than scrolling in terms of reading and understanding an encyclopedia article? Æo (talk) 20:21, 2 May 2023 (UTC)

@Certes, Aaron is right. Alex was a designer ("lead" is a prefix indicating his professional experience, the same way I'm a "senior" and Olga is a "principal"), and he wasn't the decision-maker regarding what the team would work on. Perhaps we'll pick projects tied closely to Vector 2022 and resulting from the code cleanup which, from the technical perspective, Vector 2022 is. Perhaps we'll have a meeting focusing on the plan for the next fiscal year itself. Subscribe to our newsletter and look out for news! SGrabarczuk (WMF) (talk) 13:34, 18 April 2023 (UTC)

My apologies for getting the job title wrong, but the point stands: the person in charge has completed their work and moved on (whether internally or externally isn't really important) and it's now time for enwp to pick up the pieces. Certes (talk) 17:52, 18 April 2023 (UTC)

It’s not just the job title. Just one experienced person leaving doesn’t mean the project’s over. Aaron Liu (talk) 18:51, 18 April 2023 (UTC)

The team, in their statistical analyses, highlighted the increase of clicks to navigate articles as an indicator of V22's increased usability. This is not necessarily and indicator of usability, let alone of success among the users; to the contrary, the increase of clicks needed to navigate the articles indicates that with V22 moving between the various sections of an article and between different articles has become more awkward, as pointed out by many commentators during the RfC. Does the team realise that an encyclopedia project needs content quality and not more clicks? Was V22 specifically designed to increase the overall amount of clicks?--Æo (talk) 14:41, 21 April 2023 (UTC)

Increased number of what clicks? What’s the context/source? How is moving between the various sections of an article and between different articles more awkward? Aaron Liu (talk) 14:52, 21 April 2023 (UTC)

Here: ...we saw the new ToC increased ToC usage overall (and thus the number of sections of an article people navigate to) , with 53% more clicks on new ToC for logged-in users and 45.5% more clicks on new ToC for anonymous users. Æo (talk) 18:13, 23 April 2023 (UTC)

How does increased ToC clicks not reflect navigational usability? If anything it does reflect that the new ToC is useful in aiding navigation. It's not like there's a faster way to navigate between article sections. Aaron Liu (talk) 18:32, 23 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)

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)

Making diff the first parameter in the diff template

{{diff}} has title as the first unnamed parameter, despite it being optional. The diff ID is also the most important parameter and most of the times you can just link to a diff with only the diff ID, so I think the diff ID should be the first parameter. Putting this here as the template talk page doesn't seem to have traction Aaron Liu (talk) 16:03, 12 April 2023 (UTC)

I don't disagree with you about which field is more important, but as a practical matter, {{diff}} is a widely used template. Making a change like this now would be quite disruptive. -- RoySmith (talk) 16:21, 12 April 2023 (UTC)

Would this change be compatible with the 30,000+ existing uses of {{diff}}? Certes (talk) 16:23, 12 April 2023 (UTC)

That was what I was thinking about. We could use a bot or autowikibrowser to do this, maybe like move the template to "/old" or something, add in the fixed version, and replace all mentions of it with the newer syntax. Aaron Liu (talk) 17:53, 12 April 2023 (UTC)

That would fix the template for future revisions of a page, but when you view an old revision of a page, the current code of the template is executed, so all the 30k+ uses in several millions of old revisions will be broken. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:16, 15 April 2023 (UTC)

Just use {{diff2}} with the diff id as its unique parameter. MarioGom (talk) 18:34, 14 April 2023 (UTC)

A much better suggestion than breaking the template in old revisions. —Kusma (talk) 19:14, 14 April 2023 (UTC)

Why don't we have warning banners about scams?

One of the facets of WP:ARC#Paid editing recruitment allegation is that some poor guy got scammed out of a large amount of money (I've seen $15k and $20k mentioned) by somebody promising to write an article for them. It's not the first time, but wouldn't it be nice if we could make it the last? Let's put a warning banner on every page: "If somebody is offering to write an article for money, it's probably a scam. See WP:PAID for more information". -- RoySmith (talk) 00:25, 13 April 2023 (UTC)

The key challenge is that the community would have to accept a prominent banner forever, including on small screens where space is limited. Given the number of possible scams, it would be tricky coming up with a concise message that would still have some effectiveness. Banner blindness issues would also be exacerbated (and I imagine WikiProject Medicine would renew its call for a warning banner). But if the problem is significant, it may be worth considering. On a side note, I think the banner should link to a page tailored for it, rather than the paid-contribution disclosure page. isaacl (talk) 03:20, 13 April 2023 (UTC)

Those are reasonable points, but let's not get bogged down in the details. The gist is that we should be doing more to alert users (especially vulnerable new users) to the risks. Maybe one of those messages that keep showing until you click the "dismiss" link? Or make it part of the welcome message that gets dropped on new user's talk pages? Or an email to new users? There's lots of technologies to help get the message out. And, yes, the details of the message could be fine-tuned more than WP:PAID.

Not long ago, I needed help with managing a page I have on Facebook. I (foolishly) decided to try joining /r/facebook/ on reddit. I immediately got a message from a bot warning me that the group was rife with scammers. And sure enough, by the end of the day I had gotten several PMs from people offering to help me solve my problem in exchange for money. I've been around the block a few times, so I'm pretty good at recognizing scams, but having been put on alert primed me to be particularly suspicious.

Some of these scams are quite sophisticated. A few years ago, I got an email from somebody purporting to be a high-level WMF employee who had recently left WMF, attempting to enlist my help with a paid editing project. It was well-targeted to my past activities and editing interests and slick enough that I spent quite a bit of time trying to figure out if it was legitimate or not. It's not hard to see how somebody (even somebody who's been around the block a few times) could have been sucked in. -- RoySmith (talk) 15:05, 13 April 2023 (UTC)

Another idea; there are several mainstream (at least in the modern sense) media outlets which cover wikipedia. HalfAsInteresting just did an amusing (but reasonably accurate) piece on how arbcom works. Slate has published a number of well-researched articles examining wikipedia topics. I'm sure there's others. Perhaps they could be encouraged to write about wiki scams. The more it's talked about, the more potential marks will be educated about the problem. -- RoySmith (talk) 15:12, 13 April 2023 (UTC)

The detail on whether or not the warning appears on every page is an important one, though. A one-time welcome message would be less intrusive, but potentially less effective. Maybe a one-time message and some form of collapsed message on each page? Not sure what would be the best way to present the collapsed message on a small screen, though, and that's how a lot of readers experience Wikipedia. I don't think messaging new users will do much to reach the extremely broad group of potential victims. (On a side note, I feel the HalfAsIntereseting video is reasonably accurate on describing dispute resolution, with the key omission that it failed to describe how the arbitration committee doesn't directly rule on content issues.) isaacl (talk) 15:35, 13 April 2023 (UTC)

I'd hate to see it on every article all the time, too. Maybe something that could be seen by IPs/new accounts, maybe a click-through page that shows up randomly when someone opens a Wikipedia article, and that registered accounts could turn off? Agreed that it should link to something that very briefly explained the scams. Valereee (talk) 14:54, 13 April 2023 (UTC)

Are there any estimates for how large a problem this scamming is? We've got hundreds of millions of readers; we don't want to overreact given any action will negatively impact their reading experience.

Depending on the scale of the problem, another option may be to run the banners for a week as an education campaign. BilledMammal (talk) 15:23, 13 April 2023 (UTC)

@BilledMammal, for an idea of how much this is attempted, see WP:List of paid editing companies. How often it's successful is a different question, of course. A lot of these people are really bad at it. Valereee (talk) 16:15, 13 April 2023 (UTC)

I think that's a different issue, although it is related; some paid editing companies are just scams but others do try to provide the service that is being paid for. BilledMammal (talk) 16:28, 13 April 2023 (UTC)

Most UPE companies are deceptive to customers (we are Verified Editors, we have Wikipedia Moderators in our team, we strictly follow Wikipedia Rules, etc). Whether they cross the line to be considered criminal is a different matter. MarioGom (talk) 17:29, 13 April 2023 (UTC)

Roughly once a month someone pops up on the help desk asking where the article they paid for is. It's a pretty common scam. I don't think it being shown to people when they register is ideal; I think most of the victims never make an account - why would they? They've paid someone else to do that. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:34, 13 April 2023 (UTC)

• No one reads banners or warnings anyways. The only way people learn anything is when natural, negative consequences happen to them. If that natural, negative consequence is "they lose money to someone who scammed them", then the lesson they will learn is "don't get taken in by scams". They don't learn that lesson because we have a banner they don't bother to read. They only learn it because they actually experience being screwed by the scammer. In summary: there's no need to bother, it's not our responsibility, and if your goal is to educate, there's no greater education than losing a bunch of money to someone who scammed you out of it. --Jayron32 15:31, 13 April 2023 (UTC)

We could put something about scams in the disclaimers. Gråbergs Gråa Sång (talk) 16:28, 13 April 2023 (UTC)

There's a related discussion at WT:COI#Do we need a disclaimer/warning?.

I agree in part with editors who point out that the most likely victims of scammers are unlikely to benefit from any "education" from us, and I also agree that making banners too intrusive would mostly just be annoying. But I also think that there is an unmet need to make information about scams easier to discover than it currently is – if only for editors who want to learn more about how to combat it. I also think it's a bit harsh to take pleasure in how someone losing money will learn a lesson. Short of warning banners, I think we should find multiple places to link to things like WP:PAIDLIST and WP:SCAM. It might be a good idea to look at the help pages we have for new editors, and find ways to incorporate more information about the need to beware of scams into those. --Tryptofish (talk) 16:52, 13 April 2023 (UTC)

@RoySmith Putting a warning banner on every page seems excessive to me, and I don't think it would get community support. Does Kobresia sibirica ned a banner on it telling readers about paid editing? I would argue no.

I think a refined version of your proposal would definitely have legs though. Rather than putting a banner on every page we could put notices and banners in specific targeted places: those that are likely to either be abused by paid editing companies as part of a scam, or those where people in the process of being scammed are likely to go for help.

Here's a couple of ideas off the top of my head:

• These scams often focus on impersonating admins, checkusers, oversighters, members of the arbitration committee etc. If these people put a standard boilerplate disclaimer at the top of their user and talk pages saying "If someone claiming to be me has offered to perform edits or actions in exchange for payment you are being scammed" that would make it much more difficult for these scams to occur. If these notices were present the scam that resulted in this current mess would have fallen apart as soon as the scammer sent the victim to bradv's user page.
• One very common scam involves looking through AFC submissions for biographies or pages on companies that have been declined/rejected then messaging the subject asking for payment to publish it. {{AfC submission}}, {{AfC reject}} and {{AfC decline}} could all have prominent notices added warning about this kind of scam.
• AFD would be another good place to put warnings. There's a lot of scams based around nominating articles for deletion then extorting protection money to prevent this (by having a bunch of socks flood the discussion with keep votes). A message that anyone asking for payment in regards to page deletion is a scammer could be useful.

I'm sure there's other places we could add warnings which would impede the scammers but wouldn't impact most of the project. 192.76.8.84 (talk) 17:04, 13 April 2023 (UTC)

I also think that a site-wide warning is excessive, but AFC and AFD disclaimers would be nice. There's some common scams and extortion operations that focus in these areas, and the disclaimers can be added to banners that are already in these pages. MarioGom (talk) 17:28, 13 April 2023 (UTC)

I'd oppose a banner, but places like Wikipedia:About could carry visible warnings about payment scams. —Kusma (talk) 19:16, 14 April 2023 (UTC)

Another place for such a warning might be Help:Introduction or one of its subpages. --Tryptofish (talk) 20:09, 15 April 2023 (UTC)

All of the above is well intentioned but is likely to be ineffectual. What's the chance that a contentious group of Wikipedians will agree to put this into effect? Well, there is one very simple thing that every Wikipedian can put into effect immediately and will have some results depending on how many editors post this warning. All you need to do is post the following at the top your user or user talk pages:

Does it work? I've had this warning at the top of my talk page for 6 years (in a slightly different version). It's the only such warning that I know of. About 2,000 visitors see the page every month. Yes, there must be some other links somewhere, but if we have hundreds of links to WP:SCAM, we'll likely have many times more visitors to that page. See Page Views. Smallbones_(smalltalk) 19:14, 13 April 2023 (UTC)

I've added it to my page, though I changed the language because I think the average reader probably doesn't know what AfC/an AfC participant is. Good idea! Valereee (talk) 19:22, 13 April 2023 (UTC)

As I said above, IMO something to this effect should be included in the {{AfC submission}}, {{AfC reject}} and {{AfC decline}} templates (maybe not quite as big, and maybe including a bit more information on what the scam is) that way everybody using AFC should see it. 192.76.8.84 (talk) 19:26, 13 April 2023 (UTC)

Speaking as the person who will probably be getting the emails to paid-en-wp, sending people who have been scammed there rarely helps. Between the inexperience of the people who were scammed and the general untrustworthiness of the scammers, there's rarely anything actionable. GeneralNotability (talk) 20:45, 13 April 2023 (UTC)

Speaking as a person who has tried to do something about scammers operating on Wikipedia, I do think there is at least some minimal benefit from directing people to WP:SCAM. It explains to the victims what happened to them - maybe, at least, they can avoid the same thing happening again. It also warns others not to fall into the same trap. Nevertheless, it must be totally unsatisfying to the victims that there is nothing that we can do, nothing that we can recommend. This scam has been going on for at least 10 years, IIRC. We have some responsibility to try to come up with some way to combat it. Ultimately the major blame is not with the scammees or even with the scammers. It falls on us for offering such an attractive field with such easy access for scammers, and not doing anything about it for 10 years. We need to take responsibility for the situation we have created, and at least try to do something about it.

It should help to describe how I came to write WP:SCAM. I saw an article or letter to the editor in some small UK paper, describing how he had been scammed by Wikipedia. The article was only on Google News for 1 day, so it is fortunate that I found his email and responded the same day. I recognized something in his description that reminded me of something in the Orange Moody scandal. I told him that it wasn't Wikipedia scamming him, rather it was probably somebody that we know about and I could probably direct him to somebody here who could help, in at least some small way. I still haven't found that person. Can anybody tell me where to look? His response was more disturbing than I had thought it would be. He was physically disabled, but had accomplished quite a lot given his situation. I didn't think that he was notable enough though for an article. I surmised that his income was mostly government support, and that the $5,000 or so that he paid the scammer (this is all from memory) would be sorely missed. What to do? I think I first discussed this at talk:Paid editing disclosure and it was basically pooh-poohed. After asking around a bit on-Wiki without much sucess, I sent a general inquiry to the WMF. Over time I was able to focus a bit on a specific WMF department - but they didn't have a solution or even a real suggestion. Things began to move a bit after I researched the Orange Moody records. One newspaper (The Telegraph?) had a strange section in it describing how the victims were convinced to part with their money. There was a 26 word series there that exactly matched a 26 word series in an email the scammer had sent to the victim. I think I emailed an arb or two about that time. No real solution was offered but somebody suggested sending the email to arbcom (with an official email address). At the same time I searched for the 26 word series elsewhere on the internet, and found something, a small German programming coop-type organization. (Jtydog got involved about this time on the PAID talk page so things get confusing) Jt. ydog and the other coop-ers explained to the main guy there what had happened to "their" money. There didn't seem to be anything that could be done for them and they were resigned to the loss. So the folks at the PAID talk page started taking it a bit more seriously, but ultimately not much got done. The arbs didn't have much to add. The big "success" was that the WMF department suggested that I should write a scam warning and post it where I thought best. Amazingly enough, it sorta worked a bit. Jtydog didn't totally ruin my write-up. Some people start reading it and editing it. The reporting email address got changed about 3 times - nobody seemed to want to deal with it, I guess. But if nobody can do anything about the reports, it's not really enough, is it? Could somebody with some sense of responsibility step up to help?

BTW, there is one alternative: just tell them to report the scam to the police, or to the FTC, or their State Attorney General's office, or maybe even to the Serious Fraud Office (after 10 years at $5,000-$20,000 a pop it does add up to serious money). There are downsides to that of course, but maybe after another decade of scams somebody here will make an effort to put an end to the scam.

Smallbones_(smalltalk) 01:43, 14 April 2023 (UTC)

(EC)

Much the same can be said about Amazon. And they seem to at least be trying to do something about it on the education front. Just today I got an email today with a bunch of anti-spam suggestions ("Be careful installing apps or software", "Never pay over the phone", etc. And a link to a page where you can learn more. It may not be much (and most of the advice is fairly generic), but it's something. Surely we can do as little as they do. -- RoySmith (talk) 00:53, 14 April 2023 (UTC)

A project page with concise and clear guidance on avoiding scams would certainly be useful. For example, it can be an additional resource to link to from WP:VRT responses about scams, which are pretty frequent, as well as linking from AFD or AFC banners. MarioGom (talk) 10:35, 14 April 2023 (UTC)

Wikipedia:Articles for creation/Scam warning is a good start. But it could be moved to Wikipedia:Scam warning and expand it to make it clear that this does not apply to just AFC. MarioGom (talk) 10:39, 14 April 2023 (UTC)

Am I alone in that my first reaction to this discussion was to think that anyone who is so vain as to pay thousands of dollars/pounds/euros for an article about themself or their business deserves to be scammed? We can't legislate against stupidity. Phil Bridger (talk) 18:18, 14 April 2023 (UTC)

@Phil Bridger I doubt that you are alone, but that doesn't make it right. Lots of people pay money to promote their businesses on social media, etc. On some platforms, that's totally acceptable and encouraged by the platform owner. We're not one of those platforms, but a lot of people don't understand that. If I approached a businessperson with an offer to build them a website on Wix, and drive traffic to it with additional presences on Facebook, Twitter, and Wikipedia for money, it would be 3/4 legitimate. Our job is to educate people how we're different from the other 3/4.

Nobody deserves to be scammed. That's just blaming the victim. But, it's not just the people who pay for articles that never appear (or get sucked into AfD protection rackets) that are being scammed. You and I are getting scammed too. We're volunteering our time to build something only to have people use what we've built for their own nefarious purposes. We've been taken for our hard work just as certainly as the mark has been taken for their money. -- RoySmith (talk) 20:34, 15 April 2023 (UTC)

The difference is that Wikipedia is an encyclopedia. I have no sympathy for anyone so stupid as to think that an encyclopedia you can pay to be in would be any good. --User:Khajidha (talk) (contributions) 12:00, 18 April 2023 (UTC)

This is not a good faith comment at all. Cessaune [talk] 16:06, 18 April 2023 (UTC)

If having a warning message on user pages is thought to be helpful, then perhaps we should request a software change to allow user page notices, and then the warning can be placed there for all user pages. isaacl (talk) 17:05, 16 April 2023 (UTC)

User page messages could be helpful and would raise awareness of the issue, but I wonder how many of the victims have a user page. I suspect that many people who would consider an offer to write an article for them may not edit themselves, and so would be unlikely to see any warnings about it that do not appear in mainspace.EdwardUK (talk) 17:52, 16 April 2023 (UTC)

The goal for a user page warning is so if a scammer claims to have a specific editor working for them, should a victim look that user up, they would see the warning. I agree this probably doesn't help the vast majority of victims. As adding the warning was suggested, though, I think if it's really going to be done then the software should do it by default, rather than the community relying on users voluntarily adding the warning. isaacl (talk) 21:28, 16 April 2023

Perhaps a data point: in 2014 someone was putting up profiles on some freelancing site claiming to be me and offering paid editing services, so I put a notice on my user page warning about it and inviting anyone who heard from the scammer to contact me with details. I left it up for six months and never got an email. That said, I only ever heard of it thanks to an off-wiki attempt at stirring up scandal about me blatantly engaging in paid editing, so the profile may well have been created to try to frame me for breaking enwp policy rather than to actually try to scam anyone... GorillaWarfare (she/her • talk) 23:02, 16 April 2023 (UTC)

Short of plastering the Main page with "Don't Let This Happen To You!" banners, I don't believe we can effectively help would-be BLP subjects who are victims of take-the-money-and-run scams. However, in cases where actual, paid-for BLP articles are created (if only in draft space), I believe most of them will include an infobox or EL link to the subject's webpage. Might it be possible to develop a bot that screens new articles for such a webpage, and then somehow/someway contacts the subject through that webpage (email I assume) with a paid editing scam warning? Perhaps that would give the victim sufficient time to stop payment on their check, so to speak. JoJo Anthrax (talk) 14:51, 18 April 2023 (UTC)

Wikipedia article on paid editing on Wikipedia

At the moment, we don't appear to have an article on the topic - if we did have one it would end up near the top of any search on related topics and would likely be one of the first thing targets read if they attempt to find out more before sending money.

At the moment, I think an article solely on scam paid editing might not pass WP:N as all the sources appear to be in relation to the 2015 event (BBC, Wired, the Guardian, Forbes), but a broader article would meet notability guidelines, and I think including information showing that many of these companies are scammers might dissuade some people wishing to engage the services of those who aren't scammers.

Are there any issues with this idea? If not, I'll draft something when I have time. BilledMammal (talk) 15:50, 13 April 2023 (UTC)

@BilledMammal we have Conflict-of-interest editing on Wikipedia 163.1.15.238 (talk) 15:56, 13 April 2023 (UTC)

Thank you. I think the article needs some work, as it appears to be closer to a list of paid editing incidents than an article, and it lacks detail on how paid editing can be a scam, but it is where we would hope readers go. However, googling various search terms it isn't, at least in my results:

• Paid editing on wikipedia turns up a series of ads, and then links to various internal pages; Wikipedia:Paid editing (guideline), Wikipedia:Paid-contribution disclosure, Wikipedia:Paid editing (essay), Wikipedia:Paid editing policy proposal, and Wikipedia talk:List of paid editing companies. Our article isn't in the top results.
• Buy a wikipedia article turns up the same ads, and then the top results are for various companies selling article creation services; the only Wikipedia results are Help:Buying Wikipedia and Wikipedia:Buying Wikipedia articles in print or another form, although a WMF news article shows up; You don't need to pay for Wikipedia articles.

Various other searches I tried along these lines turned up similar results. Problematically, the first results for Make a wikipedia article were also sponsored links from article creation services.

I'm not sure how we can increase the prominence of our article - more redirects might help - but it might be worth having the WMF update their news article to include information on scams, as it is a relatively prominent result. I also wonder if WMF Legal can do anything about ads for Wikipedia article creation services. BilledMammal (talk) 16:19, 13 April 2023 (UTC)

Trying to influence google by editing articles shouldn't really be an on-WP issue. Gråbergs Gråa Sång (talk) 16:59, 13 April 2023 (UTC)

We need to get WMF to dedicate budget to buying google ads. The first google result for buy a wikipedia article should be our PSA explaining about our paid editing policy and warning people about scammers. Surely WMF can out-bid these guys for top placement in the sponsored links. -- RoySmith (talk) 15:34, 14 April 2023 (UTC)

We should certainly get the WMF to talk to Google about this issue. In the old times (when Google wasn't evil) I think they might have been persuaded not to run ads for Wikipedia scams. I'm not super happy about donation money going to Google, but it could be worth a try. —Kusma (talk) 19:29, 14 April 2023 (UTC)

Well, Google is already a WMF customer, so it wouldn't all be donation money; some of it would be Google money. In any case, worrying about who pays for it is secondary. One of the (reasonable) objections to my original idea is that the people we want to reach won't see our message if we deliver it on-wiki. So we need to put the message where they will see it. -- RoySmith (talk) 19:48, 14 April 2023 (UTC)

I don't think SEO is outside our scope; there was recently a discussion, though I can't find it now, about shorter titles being beneficial for that reason. I also think that trying to prevent people from engaging in UPE is worth while. BilledMammal (talk) 18:36, 16 April 2023 (UTC)

Sort of related, we also have Wikipedia coverage of American politics, List of political editing incidents on Wikipedia and since April 1, Wikipedia coverage of Donald Trump. Gråbergs Gråa Sång (talk) 16:25, 13 April 2023 (UTC)

We should have a much better article than the Conflict-of-interest editing on Wikipedia one, which is a very jargony term which predictably doesn't turn up in any of the source titles. Reliable sources explicitly discuss both paid editing[5] and scams [6][7], we should have something titled along those lines. CMD (talk) 04:54, 14 April 2023 (UTC)

I see no reason we can't have an article called "Paid editing scams on Wikipedia" alongside COI editing on Wikipedia. small jars tc 10:44, 14 April 2023 (UTC)

We could, to the extent that it's a topic covered by reliable sources. But an article in mainspace instead of project space would limit our ability of writing it in a more direct tone and include contact resources, etc. A project page like Wikipedia:Articles for creation/Scam warning would be more appropriate, since we wouldn't be constrained by the article manual of style, reliable sources, etc. MarioGom (talk) 15:15, 14 April 2023 (UTC)

Such constraints can only be a good thing if you want it to be readable to someone new to Wiki jargon. Take a second look at the project-space page you just linked. What would people make of phrases like "article space" and "AfC reviewer." small jars tc 20:11, 14 April 2023 (UTC)

I think the one I linked needs to be improved. But a regular article cannot start with a warning like "Warning! If you received emails asking for money, that is a scam! Wikipedia will never solicit money in exchange content services, etc, etc." I am not arguing against anyone creating an article about paid editing in Wikipedia, to the extent that it is compliant with content policies, but I think it's not the primary informational resource we should be working on in response to these scams. MarioGom (talk) 08:44, 16 April 2023 (UTC)

I don't believe it would need to; a well written article that reflects the sources would act as sufficient warning on its own. However, we could include a hatnote to a Wikipedia-space article that provides a more explicit warning, similar to hatnotes at AN and MOS. BilledMammal (talk) 18:36, 16 April 2023 (UTC)

Legal action against scammers

Fully stopping scammers with legal action is not possible, for the same reasons that other online fraud like bank phishing still exists: the identity of the scammers is hard to discover, and when it is discovered, they are often located in jurisdictions where it's harder to sue them. However, many scammy UPE companies use US-based services (Zendesk, Tawk, Zoho, Cloudflare) and if WMF started a criminal complaint in the US, they could possibly terminate these services. This would not make the problem go away, but it could be a significant disruption to their daily operations. I think it would be worth to explore this idea with WMF Legal. MarioGom (talk) 17:35, 13 April 2023 (UTC)

I agree. --Tryptofish (talk) 17:38, 13 April 2023 (UTC)

To the extent that scammers are misrepresenting themselves as Wikipedia staff or professional employees, there may also be trademark issues that can be pursued through litigation. BD2412 T 23:33, 14 April 2023 (UTC)

Not to mention wire fraud. But yeah we have to consider actions that WMF can take on its own, which would limit one to torts. ☆ Bri (talk) 22:23, 2 May 2023 (UTC)

Nothing prevents us from informing and cooperating with law enforcement. BD2412 T 22:27, 2 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)

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)

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)

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)

Modifications to CANVASS

When determining consensus the ideal is that the discussion reflects the views of the broader community. Part of our policies in ensuring this is WP:CANVASS, which restricts who we can notify and how we can notify them. How this is done in practice is controversial, and recently there has been discussion about how we should alter this guideline to better do so.

This discussion is to have a preliminary discussion of the various ideas I present here and how they could be presented as proposals to reword the guideline, as well as generate other ideas for how CANVASS might be adjusted to better support this ideal.

• Should discussions be informed when notices to them are posted?

  Generally I believe they should; transparency is always a positive and it makes it easier to identify when canvassing takes place. I am hoping that this will be uncontroversial.

• Should the examples listed at WP:APPNOTE be exceptions to WP:INAPPNOTE, or just examples of notifications that are usually acceptable?

  I don't think it makes sense for these to be exceptions; notifying a partisan editor who has asked to be notified of "all contested AfD's" on a topic doesn't help the discussion reflect the views of the broader community and creates a wide loophole in our CANVASS requirements.

• Can WikiProjects be partisan in relation to a topic, and should WikiProjects that can reasonably be seen as such be notified of discussions on that topic?

  I think it is obvious that any group of editors, including WikiProjects, can be partisan. I also think that if they are partisan they shouldn't be notified; we want the discussion to reflect the views of the broader community, not the views of the WikiProject when those views don't align with the broader community.

  However, I wouldn't consider deletion sort lists and similar to be notifications; they make it easier for interested editors to find discussions but they don't notify editors of the discussion.

• Should RfC's that would affect the broader community be held at WikiProjects?

  I would believe they shouldn't, in line with WP:CONLEVEL; while the formal discussion invites participation from outside the WikiProject the forum still results in disproportionate participation from the WikiProject. In such cases, I believe it would be better to hold the discussion either at a relevant talk page or WP:VPR/WP:VPP, and I can't see any benefit from holding it at the WikiProject.

BilledMammal (talk) 07:52, 18 April 2023 (UTC) Editing for clarity BilledMammal (talk) 13:32, 18 April 2023 (UTC)

I noticed you mentioned there has been some recent discussion, but you have not linked to it. Which discussion or discussions do you refer to? Huggums537 (talk) 07:58, 18 April 2023 (UTC)

Wikipedia talk:Canvassing#APPNOTE vs INAPPNOTE is the main discussion; there have also been discussions at ANI and on my talk page. BilledMammal (talk) 08:05, 18 April 2023 (UTC)

And you are thinking of yourself as someone who should be seeking consensus about well informed discussions? I find this to be both fascinating and yet somehow appropriate at the same time. Huggums537 (talk) 08:23, 18 April 2023 (UTC)

I don't understand what you are asking, but it seems to be a comment on me rather this on questions posed here so I would ask that you take it to my talk page. I would add that several editors have asked me to open this discussion, including in the discussion that I linked and that you participated in. BilledMammal (talk) 08:34, 18 April 2023 (UTC)

I wasn't asking anything. It was a rhetorical question. I just think it's interesting that someone who appears so concerned with informed discussions failed to make this an informed discussion. It was just a simple observation of irony, not about you, but about the ironic editing situation you created here. Huggums537 (talk) 09:12, 18 April 2023 (UTC)

This recent discussion may be one of those alluded to. Folly Mox (talk) 08:29, 18 April 2023 (UTC)

For the ANI discussion it is more this one: Wikipedia:Administrators' noticeboard/IncidentArchive1119#User:BeanieFan11 and WP:BATTLEGROUND at NFL AFDs. BilledMammal (talk) 08:34, 18 April 2023 (UTC)

For the first three second and third questions, I am skeptical that any usable policy or guideline text could be based on answers to these questions, because I don’t think the concept of a partisan editor oder partisan project can be operationalized outside of extreme cases (the Article Rescue Squadron, perhaps). Any editor will tend to see thise editors with whom they consistently agree on a topic as non-partisan and motivated by P&Gs, while seeing editors with whom they consistently disagree as partisan. This is exemplified by the tendency of editors to defend "per so and so" !votes as policy-based when agreeing with a !vote, while dismissing opposing !votes that cite P&Gs or other evidence as not being policy-based when an editor disagrees with the logic or policy interpretation contained within a !vote.

Any proposal to base policy guidance on a prior assessment that an editor or a Wikiproject is partisan - "partisan" in relation to what? - seems doomed to be only a tool in winning disputes and a means of gatekeeping to keep an editor's "allies" at hand and their "opponents" far away. Newimpartial (talk) 10:13, 18 April 2023 (UTC) corrected by Newimpartial (talk) 12:05, 18 April 2023 (UTC)

See WP:INAPPNOTE and WP:VOTESTACKING; we already forbid the notification of a partisan audience, with partisan defined as editors who have or are thought to have a predetermined point of view or opinion. For example, I would be considered partisan on topics related to notability.

I would also argue that it does the opposite of what you fear; an editor who tries to keep their "allies" at hand and their "opponents" far away by notifying only their allies would be in violation of the policy.

Relating your comments to the question at hand, you seem to be arguing that editors should be free to notify whomever they want; we can add a question to that effect proposing that VOTESTACKING is removed from INAPPNOTE? BilledMammal (talk) 10:25, 18 April 2023 (UTC)

Thanks for asking for clarification: I am not at all proposing that editors should be free to notify whomever they want, or that VOTESTACKING be removed from APPNOTE. But I'm not sure about your interpretation of the passages (of INAPPNOTE) in question: they do not prohibit the notification of partisan ... editors, which seems to be the concept you are using here, but rather it prohibits the notification of editors on the basis of partisanship. Posting an appropriate notice on users' talk pages in order to inform editors on all "sides" of a debate (e.g., everyone who participated in a previous deletion debate on a given subject) may be appropriate under certain circumstances - there isn't any carve-out to exclude some previous participants because they are perceived (by whom?) to be partisan.

extended content
The following discussion has been closed. Please do not modify it.
As far as an editor who tries to keep their "allies" at hand and their "opponents" far away by notifying only their allies would be in violation of your proposed new policy language, this is already covered in APPNOTE (The audience must not be selected on the basis of their opinions) as well as INAPPNOTE (WP:VOTESTACKING). It seems to me that policy based on your comments on your second and third questions would be weaponized by editors who don't see their own biases (lacking your self-awareness with respect to Notability discussions, for example) while tending to restrict participation in instances where the inclusion of more, diverse perspectives would be better for the project. It seems to me that including too few rather than too many audiences is the bigger problem in the notification ecosystem. Creating GAMING opportunities by excluding "partisan editors" and "partisan projects" doesn't help with this - do we really want Women in Red excluded from notifications as a partisan project? To give a more hypothetical example that might be easier to discuss: Canadian content may well be overrepresented on-wiki, and Wikiproject Canada may well skew towards the inclusion of Canadian content at AfD and may not align perfectly with the rest of the community in the assessment of Canadian sources at RSN. I would not see those situational factors (hypothetically) as valid reasons that Wikiproject Canada should be seen as a partisan audience when such articles and sources are under discussion or that a project notification would have a negative impact on such discussions. Sometimes members of a project hold views that differ from non-members for reasons of familiarity with sources or with policies, and there isn't anything in your proposal that could save that infant when disposing of the waste water. As another example, Wikiproject Role-Playing games has a section of the project page dedicated to noticeboard discussions (including AdD and MfD), which results in watchers of the project page being alerted when such discussions begin (or end). The main impact of this in recent years has been that some salvageable articles have been improved and "saved" at AfD, while nothing perceived as "CANVASS" or disruptive on-wiki has happened. I don't see any advantage to the Wikipedia community in banning practices like this, which is what your views on your third question seem to require. The assumption that including editors who are sensitized to a topic will result in disruption in discussions on that topic seems to me not to be proven as a working assumption. The point should be to notify a broad and diverse range of editors who can bring experience or fresh perspective on a topic, but to create levers for GAMING the notification system.

TL;DR: INAPPNOTE and VOTESTACKING currently refer to "partisan audiences" but not "partisan editors" or " partisan projects". This is as it should be: editors are only "partisan" in relation to specific topics and should not be notified on the basis of their opinions (which policy already stipulates). Projects also only have the potential to be partisan in relation to specific topics or discussions, and the best way to ensure that project notifications reach all relevant parties is for people to join projects when they are interested in any aspect of its domain, not to treat the project as similar to a political party (in the words of VOTESTACKING). Notifying a broader range of projects and pages to reach more voices is an approach more in line with wiki values than creating gameable rules about those who must not be notified. Newimpartial (talk) 12:03, 18 April 2023 (UTC)

I agree with the concerns about gameability, and I'd also be surprised if a proposal encouraging not notifying certain projects is adopted by the community. I'm not actually sure what problem the current guideline is causing. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 12:36, 18 April 2023 (UTC)

Regarding gameability, I don't think it can be gamed. An editor might try to do so by selectively applying the guideline - ignoring it for notifications of their side, but applying it to notifications of the opposing side - but that behaviour is possible for most of our guidelines, including WP:CANVASS as currently worded, and usually results in sanctions.

The issue with the guideline is that it is disputed whether it forbids notification of partisan WikiProject; we need clarity on whether this is permissible. The issue with notifying partisan WikiProjects is the same issue as with all vote stacking. BilledMammal (talk) 12:57, 18 April 2023 (UTC)

To be clear, when I say "partisan" I mean "partisan in relation to the topic under discussion". As for your proposed solution of having editors join all WikiProjects they are interested in, I don't think it is a plausible solution (how would we encourage editors to do so?), but it also wouldn't work; using your example, an editor might not be interested in Canada, but they might be interested in excluding unreliable sources or deleting non-notable articles.

We also can't balance out partisan groups by notifying groups that are partisan in the opposite direction because such groups rarely exist. This is why I didn't consider the WP:VOTESTACKING exemption you mention relevant; it works for and refers to individuals, but it doesn't work for groups.

In regards to your comment about editors who are sensitized to a topic, that isn't what this is regarding - it is about editors who are partisan to a topic. As far as I know, WIR is not partisan, which means that while they might be sensitized to a topic there is no issue with notifying them, and based on your comments about Wikiproject Role-Playing games the same is true with them.

Finally, you say that the point should be to notify a broad and diverse range of editors who can bring experience or fresh perspective on a topic; I agree, but notifying partisan groups increases the participation of that group in the discussion, thus making it less representative of the broader community and thus less diverse. BilledMammal (talk) 12:57, 18 April 2023 (UTC)

How does including everyone in the broader community even the "partisan" groups mean it is now less represented or somehow less diverse? You make no sense at all. Huggums537 (talk) 14:57, 18 April 2023 (UTC)

Let me take that back. You make a lot of sense on some things, but on that you didn't make no sense at all. Huggums537 (talk) 15:09, 18 April 2023 (UTC)

Sorry. I have to backtrack myself there because I realize I have an issue with coming across as severely critical of those I disagree with, especially if the disagreement is a strong one. Please overlook it if you are able to. Huggums537 (talk) 15:14, 18 April 2023 (UTC)

I understand; assuming you still want me to respond to meat of the question:

What we want is for the partisan group to be represented but not over-represented. Notifying the group will result in them being over-represented; notifying the broader community will result in them being appropriately represented. BilledMammal (talk) 15:40, 18 April 2023 (UTC)

It sounds to me like what you want is something similar to legalized spamming so you can notify a whole bunch of people and groups who are not even related to the topic while excluding the very people who might be related it. I can not tell you how much I hate these ideas. Huggums537 (talk) 16:05, 18 April 2023 (UTC)

What I am advocating is context-based notification, and I would oppose efforts to remove the current rule on spamming. For example, an RfC related to the reliability of a source should result in WP:RSN being notified and an RfC about a policy change should result in WP:VPP being notified. BilledMammal (talk) 16:21, 18 April 2023 (UTC)

BilledMammal has objected to my prior comment because the wikiproject system cannot be guaranteed to represent "both sides" of the issue at hand proportionately to "public opinion" on enwiki at large. I take issue with the underlying assumption here, which seems to be that Wikipedia is divided into party-like entities in conflict over outcomes (or perhaps one consensus party and dissident "partisans"). The way I see notifications working best is not by new restrictions or by spamming, but to do what policy calls for at present and invite editors into discussions who are related to a topic in different ways (defying BM's apparent assumptions).

extended content
The following discussion has been closed. Please do not modify it.
For example, an assessment of a source published on a historical topic in French in Quebec to assess its relationship to FRINGE concepts might be relevant to wikiprojects focused on History, on Canada and Quebec, on French-language sources (I haven't checked whether such wikiprojects exist, but they should) and the FRINGE noticeboard. The idea that some of these should not be notified because they might be partisan on the topic (and yes, the FRINGE noticeboard has been accused of partisanship) seems like the opposite of the approach our P&Gs ought to promote. Meansbile, the idea expressed here, that a project should not be notified because no project exists to represent the contrary bias onwiki (where is our PROFRINGE noticeboard?), seems to assume those voicing this view are already treating their own networks and other preferences as similar to a political party (as this comment by another editor also does), which runs directly against the approach WP:VOTESTACKING - and CANVASS more generally - tries to promote, IMO. From reading the rest of this discussion, BM has not shown readers that "partisan projects" exist and can be identified in relation to specific topics, or that disruption has been caused by the notification of "partisan projects". Their clearest expression of how partisan projects could be identified seems to be this one, but it imposes a false dichotomy - the situation they describe could result from various causes, including a situation where non-project members, who are less motivated to investigate deeply, do not read the sources provided (especially when sourcing has been presented after their !votes), where they engaged in a motivated interpretation of notability guidelines to justify their prior preference concerning deletion, or where keep or delete !votes differ over the same evidence in a reflection of differences within the broader community over how to interpret WP:N. The idea that such differences - or even differences in !voting patterns between project members and others - could only be explained by "partisanship" seems logically flawed and unsupported by empirical evidence. BM states here that A WikiProject having members who are interested in a topic doesn't make it partisan, just as it having members who are knowledgeable about a topic doesn't make it partisan - but if editors who are knowledgeable about a topic !vote differently on that topic than editors who are less knowlegeable, according to the operational metrics BM has repeatedly put forward, that means the more knowledgeable group of editors are partisan in relation to the topic, and informing them is VOTESTACKING! However, I see no community support for the idea that editors are presumed "partisan" when they disagree with certain other editors' interpretation of a community consensus, whether or not they belong to a project - this whole framing sounds to me like an WP:AGF fail, to be honest. Also, I would point out that, while BM has amended the OP to refer to projects that are partisan in relation to a specific topic, in their other comments they seem to slip back into thinking of projects simply as "partisan" (e.g., here) as though a list of partisan projects could and should be maintained. That kind of evaluation - even in relation to specified topics - would require a community consensus that is currently clearly lacking, and proceeding with the approach BM seems to prefer, without any community agreement about the topics on which a particular group has shown partisanship, would be a clear invitation to GAMING as other editors have mentioned. As another example, it would be easy for an editor to assume that Wikiproject Feminism is partisan concerning topics and sources about feminism, but my sense is that the knowledge held by members of that project would be generally helpful to evaluations of feminist sources, not detrimental, even if on average they might disagree with a random sample of editors outside the project about the evaluation of certain sources.

In the absence of agreement about what would make a project (or a noticeboard, for that matter) "partisan", the most likely use of "partisan project" language would be for editors to assert without evidence that projects they distrust should be considered partisan based on those editors' own preconceptions and assumptions (or possibly, in the case of the OP, based on statistical inferences representing flawed logic and unsupported by policy).

I think one final example puts the logic of the proposal into a stark light: I haven't been even linking to, much less notifying, the wikiprojects I've discussed in my two lengthy comments. But if this proposal leads to an RfC, would it be inappropriate for editors to notify wikiprojects of this proposal to restrict notifications on wikiprojects? I think the answer to this is a reflection of how we see P&G concerning community processes more broadly - whether we aim for evolving structures to facilitate community engagement or whether their main purpose is to limit the participation of presumed "bad actors" and where disagreement with prior majorities is seen as evidence of "partisanship". Newimpartial (talk) 10:52, 19 April 2023 (UTC)

It is true that the wikiproject system cannot be guaranteed to represent "both sides" of the issue at hand proportionately to "public opinion" on enwiki at large. For example, the regular participants at a WikiProject tend to know something about the subject matter. I would oppose any proposal that would lead to discussions being dominated by editors of average ignorance. WhatamIdoing (talk) 15:46, 24 April 2023 (UTC)

• When notifying editors of a discussion there are two “rules of thumb” to follow: 1) notify as many people as you can 2) make the notification neutral. Blueboar (talk) 13:45, 18 April 2023 (UTC)

  The current wording of WP:INAPPNOTE suggests that the first rule of thumb is wrong; see Wikipedia:Canvassing#Spamming and excessive cross-posting. Should we include a question proposing that we remove that aspect? BilledMammal (talk) 15:29, 18 April 2023 (UTC)

  INAPPNOTE objects to posting a hundred messages. It does not object to posting one message to a page that gets a hundred page views per day. WhatamIdoing (talk) 15:46, 24 April 2023 (UTC)

• This partisan bullshit essentially boils to saying we want rules to say we can restrict the very people who would be most interested in participating. I hate the very notion of it. Huggums537 (talk) 14:27, 18 April 2023 (UTC)
• Per Huggums, this seems very much the opposite of what we want. In any discussion, we want not just Randy in Boise and his compatriots to be giving random opinions. We should value the opinions of people with more knowledge of a topic, and not deliberately exclude them. If I'm trying to decide "Is this hard-to-understand topic from molecular biology worth its own article, or should we delete it or merge it?", I don't want to exclude molecular biologists from the discussion. Sure, I'd welcome any comments, but I'd find the presence of molecular biologists in the room with everyone else to be a huge benefit; they can explain what the topic is and what its relevance is to others who are unfamiliar with the subject. The OP is basically saying "Inviting knowledgeable people should be seen as canvassing, and we should ban the practice." What are we really after here? Are we after bringing in the best people to help write the best encyclopedia with the best information available, or are we interested in winning battles and destroying our enemies? --Jayron32 14:55, 18 April 2023 (UTC)

  The OP is basically saying "Inviting knowledgeable people should be seen as canvassing, and we should ban the practice." That is not what I am saying. I am saying that inviting partisan groups should be seen as canvassing, even when the group is organized as a WikiProject, and we should make it clear that doing so is banned.

  Being knowledgeable about a topic is not the same as being partisan about a topic; if this is a common misunderstanding it might be worth modifying WP:CANVASS to make this clear. BilledMammal (talk) 15:29, 18 April 2023 (UTC)

  If a WikiProject is actively disruptive, appropriate sanctions will be employed against members of that WikiProject doing the disruption. It seems to me this is putting the carriage before the horse by attempting to prevent predicted disruptive activity rather than tackling past disruptive activity by a group of editors, and using CANVASS's notification guidance as an awkward crowbar to do so. I'd be much more concerned with such guideline creep being misused or (more likely) wasting editors' time with endless discussions about whether WP:LGBT oder WP:GEOG are partisan. I'm almost certain some random POV-warring editor would seek for WP:LABOR to be essentially shadowbanned, for example. Additionally, just because we write rules doesn't mean they will be followed. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 15:44, 18 April 2023 (UTC)

  Addendum: And if the WikiProject isn't being disruptive but just happen to share one opinion, then that is not something we are meant to fix. Sure, it sucks when some crowds aren't very wise at all but that's life. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 15:50, 18 April 2023 (UTC)

  To be clear, partisan WikiProjects aren't being disruptive, but it is disputed whether notifying them about topics they are partisan on is. To prevent issues going forward we need to determine whether it is or isn't, which is why we need to have a discussion to clarify this.

  Personally, I don't see why notifying a partisan group organized as a WikiProject is any different from notifying a partisan group organized in a different manner; Wikipedia:Arbitration/Requests/Case/Eastern European mailing list#Canvassing said messages to fora mostly populated by a biased or partisan audience — especially when not public — are considered canvassing and disrupt the consensus building process by making participation lopsided, which appears to partisan WikiProjects just as well as it does to other public groups. BilledMammal (talk) 16:02, 18 April 2023 (UTC)

  To be clear, partisan WikiProjects aren't being disruptive, but it is disputed whether notifying them about topics they are partisan on is. Could you explain to me how it could be disruptive to notify them without their consequent participation being disruptive? The same case you mention contains many examples of coordinated disruption happening as a result of the canvassing, such as edit warring and coordinated voting. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 16:10, 18 April 2023 (UTC)

  Because it disrupts the consensus building process by making participation lopsided. The individual editors participating aren't doing anything wrong, but the editor who provided the notification did.

  Could you explain to me why you see notifying a partisan WikiProject as different from notifying a partisan group organized in a different manner? BilledMammal (talk) 16:20, 18 April 2023 (UTC)

  Because if the WikiProject has a genuine interest in the discussion and can be notified in a neutral manner in a public forum, not notifying them would essentially be WP:VOTESTACKING. Say I believe WP:LABOR is partisan in favor of organized labor groups (an understandable concern, given the purpose of their project is to maintain and expand the coverage of said groups on the wiki) and I want to delete a labor group article. How would failing to notify them, yet notifying other wikiprojects, be anything but votestacking? If no known coordinated effort is being made by them to preserve labor group articles at all cost, am I not preventing knowledgeable, constructive editors that are more likely to know of possible sources that could demonstrate notability from participating in the discussion? Am I not myself causing lopsided participation in consensus building processes as a result of assuming bad faith? Biased editors are still entitled to their opinions. This is not a new phenomenon. We've built processes to deal with issues that result. I'm also completely confused as to what you mean by in a different manner so can't answer on that part of the question. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 16:36, 18 April 2023 (UTC)

  How would failing to notify them, yet notifying other wikiprojects, be anything but votestacking? Assuming that the other WikiProjects aren't partisan and WikiProject Labor is, how would it be votestacking? Notifying the non-partisan WikiProjects wouldn't make participation lopsided, but notifying WikiProject Labor would.

  I'm also completely confused as to what you mean by in a different manner so can't answer on that part of the question. Organized in a manner other than being a WikiProject. Pretend there are ten editors who share a position on a topic.

  If I notify those ten editors directly then I am in violation of CANVASS. If the ten editors form a group organized in any manner other than as a WikiProject and I notify the group, then I am still in violation of CANVASS.

  However, if the group is organized as WikiProject, then some editors argue that notifying them is not a CANVASS violation; I am hoping you can explain why the method of organization is relevant. BilledMammal (talk) 16:55, 18 April 2023 (UTC)

  I'd argue assuming a WikiProject is partisan is a pretty strong one to make. I'm unconvinced your logic makes any sense when replacing "is partisan" with "I believe is partisan". What would the burden of proof even be to show a WikiProject is partisan, under your proposal? Even harder still, what would be the burden of proof to show a WikiProject is not? How could WP:WIR not be partisan but WP:SCEPTIC be? How could WP:WMNSPORT not be but WP:CFB be? You do understand that such a guideline would be scrutinized in this way if it is not guided by editors' belief of what is partisan and what is not. I.e. if you are assuming it is clear to the community what is partisan and what is not, you should be able to draw such a line for us and be confident it can pass scrutiny. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 17:19, 18 April 2023 (UTC)

  To prove that a group is partisan within a broad topic area we need to review the prevalence of opinions of members of that group within the broad topic area compared to non-group members. If there is a significant difference between the two then the group should be considered partisan for that topic area.

  For a hypothetical example: We are considering whether members of a WikiProject are partisan in relation to whether articles on fish should be deleted.

  If we see that the average support for deletion of these articles is 30% (3 out of every 10 !votes are 'Delete') among editors who are not members of the WikiProject, but for editors who are the average support is 90% (9 out of every 10 !votes are 'Delete'), then the WikiProject should be considered partisan for the broad topic area of "deletion discussions about fish".

  If you see any issues with this then please say; I think a workable definition is possible but it may need some work. BilledMammal (talk) 17:31, 18 April 2023 (UTC)

  My issues with this are as follows:

  1. How is it that the individual members of this WikiProject are not engaging in misconduct related to AFDs and therefore should not be individually sanctioned if, on average, they vote to keep 90% of fish articles?
  2. This assumes that future participants in the WikiProject will inherently share the bias of past and current members
  3. Until I'm shown evidence that it is rare for WikiProjects to overwhelmingly want to keep articles within their purview, I believe your definition would apply to almost every WikiProjects.

  — Ixtal ^{( T / C )} ⁂ Non nobis solum. 17:44, 18 April 2023 (UTC)

  For 1, !voting against consensus is rarely sanctionable and I don't think I've ever seen an editor sanctioned for consistently !voting against consensus is a single broad topic area at AfD. I'm also not sure they should be sanctioned; editors being against consensus isn't an issue, the issue is if they sway the debate by votestacking, rather than by convincing the broader community that their position is the correct one.

  For 2, it doesn't make that assumption. If future participants don't share the opinion of past and current members then the prevalence of opinions will change.

  For 3, I doubt it is true for most WikiProjects; while some are concerned about quantity, others - I believe most - are more concerned about quality. Further, while my example was deletion discussions it wouldn't only affect deletion discussions; it would also affect RM's, RfC's, etc.

  I can look into getting that sort of evidence for you, but it will take a few weeks before I have time to do so. BilledMammal (talk)

No need to get that evidence for me personally. I'm not even sure one could even gather it. In any case, I'm withdrawing from the discussion since I don't think I can give any more constructive feedback on your proposal nor do I think either of us will convince the other of our views on the matter. I still do not believe it would be good for the wiki or likely to pass, but appreciate you having discussed it with me. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 18:33, 18 April 2023 (UTC)

• Being knowledgeable about a topic is not the same as being partisan about a topic You've not made any such distinction in the manner you are using "partisan". How do I know if a Wikiproject is "partisan" vs. if a Wikiproject is "knowledgeable and interested in a topic"? --Jayron32 16:06, 18 April 2023 (UTC)

  WP:CANVASS doesn't make any such distinction; I wouldn't think one would be necessary because it seems obvious to me that the two aren't synonyms. However, if this is a common misunderstanding then CANVASS needs to be modified to make such a distinction; do you think it is common, and how would you propose making that distinction? BilledMammal (talk) 16:20, 18 April 2023 (UTC)

  It's obvious to me they aren't synonyms. However, you seem to be using "partisan" in a way that doesn't make it clear you have made such a distinction. My point is, if you're going to say "These WikiProjects over here are full of wonderful, knowledgeable editors, and the discussion could really benefit from their deeper knowledge of the discussion" and "The other WikiProject here is full of a bunch of partisan assholes, and if you notify them, they're going to show up and ruin the discussion". How do you define the difference? Because if you can't, then you have no leg to stand on with your proposal. --Jayron32 17:45, 18 April 2023 (UTC)

  The same way you determine if an editor is partisan; for more detail, see my response to Ixtal. BilledMammal (talk) 18:06, 18 April 2023 (UTC)

  I've read your response to Ixtal; what it shows me is some phenomenal lack of AGF in interpreting the actions to mean "is partisan" rather than "is knowledgeable". For example, people who write articles about fish (from your example) are more likely to know of, and have access to, source material about fish than the average person. Difference in voting in a discussion is quite easily explained that way. The fact that a member of a Wikiproject voted one way, and someone who is not a member of that project voted another, does not mean that the member of that project did so because they were "partisan". Your assumptions that that is the best interpretation of that data is problematic. --Jayron32 18:16, 18 April 2023 (UTC)

  If the members of the WikiProject are presenting sources then a difference in prevalence of opinions can only occur if the broader community disagrees with their conclusions about those sources. The difference isn't because they are more knowledgeable, it's because their beliefs on sources are not aligned with the beliefs of the broader community - in other words, it is because they are partisan. BilledMammal (talk) 18:27, 18 April 2023 (UTC)

  Jayron32's question, "How do I know if a Wikiproject is 'partisan' vs. if a Wikiproject is 'knowledgeable and interested in a topic'?", is very much on-point for me. I'm not a wikilawyer. When someone else moved Theban alphabet (its original title since creation) to Theban script, and reverted my reversion without having discussed it on talk, that left it to me to open up that discussion on its talkpage, a page move request to get it back to the stable status quo ante, rather than the mover requesting his preferred move there. That is, the page is sitting in its changed state while the request ages. I knew that the request would show up automatically on a list, for those who watched it, but I thought past editors of the page, still active, should also have a say, so I notified those in the revision history who had any contributions on en:wp within the past year or two. Now I've got to worry whether I fell afoul of CANVASS, despite not knowing in advance which article title they would prefer? – .Raven  ^.talk 07:17, 19 April 2023 (UTC)

  I don't agree that WikiProject are inherently "partisan", and I've seen enough disagreements on project talk pages to discount the idea that project members are always "of one mind" on a subject. WP:CANVAS explicitly allows notifying projects of related discussions, and I see no reason to change that. Schazjmd (talk) 16:09, 18 April 2023 (UTC)

  WikiProjects aren't inherently partisan, but some are partisan. Further, disagreements doesn't mean a group of editors, whether organized as a WikiProject or not, isn't partisan; if 90% of the members of a group support something but only 30% of the broader community do then the group is partisan on that question even though there is some disagreement within the group. BilledMammal (talk) 16:20, 18 April 2023 (UTC)

  There can be honest disagreements between different groups of editors based on their underlying assumptions or experiences, without making them partisan. The only way to evaluate the arguments in context is to hear them out. I agree it's not necessarily helpful to hear the same arguments over and over again, but that's a problem with English Wikipedia's decision-making traditions in general. isaacl (talk) 16:37, 18 April 2023 (UTC)

  Or to take a wildly hypothetical example: if over 99% of virologists and MDs specializing in public health, epidemics, pandemics, etc., believe something called, say, "COVID–19" is real... but over 50% of the population think otherwise... that doesn't mean the first group are "partisan". – .Raven  ^.talk 07:26, 19 April 2023 (UTC)

  WikiProjects are just groups of editors sharing a common interest and working together to further the goals of Wikipedia, usually by working on various initiatives. Most of them are oriented around a content area, and thus attract the knowledgeable editors in that area. Notifying the corresponding WikiProjects for related content areas is considered to be a neutral way of reaching the interested editors who are best able to bring greater context to a decision. It's not partisan to be interested in a content area. There are other groups of editors interested in managing deletion who monitor the deletion request pages; they're not necessarily partisan, either. For better or worse, the best way to reduce the impact of vote-stacking via canvassing is to reduce the effect of raw numbers on the decision-making process. This means weighing arguments in a manner not solely tied to the number of people speaking in favour of them. I know this isn't easy, but the ultimate way to avoid a behavioural problem is to remove the incentive for it. isaacl (talk) 16:33, 18 April 2023 (UTC)

  I think a lot of this discussion is based on a misunderstanding; we are only talking about partisan WikiProjects, with partisan having its standard definition of a strong supporter of a party, cause, or person. A WikiProject having members who are interested in a topic doesn't make it partisan, just as it having members who are knowledgeable about a topic doesn't make it partisan.

  It seems there is a common misunderstanding about what partisan means; this needs to be resolved, because even if there is a consensus that WikiProject's can't be partisan CANVASS still uses the word and this misunderstanding must be causing issues. Do you have any suggestions for how to resolve this misunderstanding? BilledMammal (talk) 17:20, 18 April 2023 (UTC)

  I don't know if anyone can provide a suggestion for what you mean by partisan. At the incidents' noticeboard discussion you linked to above, you called WikiProject NFL a biased audience that shouldn't be notified. To me this is a group of editors interested in a specific content area, and so notification is appropriate. Rather than trying to label groups, it might be better to focus on the criteria for notification: they shouldn't be tailored in such a way that only editors with a specific viewpoint would be interested in being notified. isaacl (talk) 17:36, 18 April 2023 (UTC)

  The Article Rescue Squad is the usual group people point to for inappropriate notifications. While I understand why, I also understand why some editors feel motivated to try to fix articles that seem promising and are currently undergoing a deletion discussion. It might be a reasonable approach for that group to concentrate more on the fixing and limiting their contributions in deletion discussions to just noting what sources they have added to illustrate that the standards for having an article are met, without further comment. isaacl (talk) 17:44, 18 April 2023 (UTC)

  I followed that for years and never understood it. What was most disturbing to me was the "gamification" of the AFD discussions. Some people seemed to think that once an article arrived at AFD, everyone divides into two camps, "Delete" or "Keep", and the winner was the one who got their votes enacted. Like it was somehow cheating to try to improve the article while it was at AFD. --Jayron32 18:04, 18 April 2023 (UTC)

  I've been templated for editing an article's text body while (and had my edit reverted because) a page move request was underway. (The template was topped with the user-written comment: "There is an on-going discussion on these articles, which you are engaged in. Wait for them to resolve...". The revert comment: "rv: this is an ongoing discussion -- wait for the result") I'd never heard it was somehow cheating to try to improve the article while it was awaiting a decision whether to restore its original and long-time name over the name it had just been moved to without discussion. – .Raven  ^.talk 07:49, 19 April 2023 (UTC)

  To understand what you are saying; are you saying that the group can be partisan but that it is appropriate to notify them anyway because they are interested in the topic area, or that they can't be partisan?

  For individual notifications I agree that focusing on criteria is a good idea, but I don't think it will work with groups. This is because for individuals when you have the correct selection criteria you balance out editors who are partisan for side A with editors who are partisan for side B; with groups it is often impossible to obtain such balance because in many cases there are groups that are partisan for side A but no groups that are partisan for side B. BilledMammal (talk) 18:06, 18 April 2023 (UTC)

  In the context of making content-related decisions, I feel the concept of partisan is akin to failing to be impartial: that is, failing to set aside one's personal feelings to make a decision based on evidence and in consideration of community guidance. I don't believe it is reasonable to declare, for example, the set of editors interested in baseball to be partial with respect to baseball-related content. I also don't agree with the assertion that a group that disagrees with a larger superset group must be disagreeing due to partiality. There can be differing interpretations leading to disagreement, or different levels of expertise. To take an extreme example, a general group of people might agree that a particular software feature can be easily coded with minimal effort, while a small subgroup of experts might say it isn't. Both sides can be honestly weighing the considerations in their minds fairly and yet reach different conclusions based on their knowledge.

  There are groups that, by their nature, have self-selected a set of editors with a specific position on some issue, and thus its members are more prone to make partial arguments for that position. Although the community has rarely ruled against the formation of groups of collaborating editors, it has happened when it agreed that the group's purpose was counter to the best interests of the overall project. I don't think a blanket statement can be made that "groups can/can't be impartial". It depends on how the group is selected. This comes back to the question of the criteria for notification: if a list is created for the purpose of notifying those who wish to always vote to delete articles, then notifying them results in vote-stacking for deletion. isaacl (talk) 21:26, 18 April 2023 (UTC)

  @Isaacl, I think the concept of partisan is very well understood in practice: If you agree with me, then you're non-partisan. If you consistently disagree with me, you're partisan. (The fact that I consistently disagree with you doesn't make me partisan; it is impossible for me to be partisan. It's a little surprising that this isn't already recorded in Wikipedia:WikiSpeak#P.

  We don't invite altmed supporters to NPOVN to discuss pseudoscience; we do invite the denizens of Wikipedia:Fringe theories/Noticeboard. We know that FTN is partisan in a dictionary-definition kind of way, but it's a POV that the community supports, so they're not partisan. AFAIK the community has never agreed that a complaint about someone inviting FTN to join a discussion on pseudoscience was a violation of canvassing's partisanship rules. We should not change that. WhatamIdoing (talk) 15:54, 24 April 2023 (UTC)

  Yes, some groups are self-selected to have specific approaches. If these approaches are designed to evaluate evidence and consider community guidance in making decisions, then generally speaking they are suitable for making an impartial decision. Being open to consider different opinions fairly is the key characteristic. (Regarding wikispeak, disagreeing editors just say biased; it's a little shorter to type and direct to the point they think they are making.) isaacl (talk) 16:54, 24 April 2023 (UTC)

  > "I feel the concept of partisan is akin to failing to be impartial" – Pretty much by the definitions and etymologies of "part isan" and "part ial", respectively:

  • "(adj.) of or pertaining to a party or faction ... (noun) especially one whose judgment is clouded by prejudiced adherence to a party", and
  • "one-sided, biased, inclined to favor one party in a cause or one side of a question more than the other"

  Both ultimately from Latin pars, 'part'. – .Raven  ^.talk 17:23, 24 April 2023 (UTC)

• In regard to the second bullet point: Considering that this website works on consensus, I think that it's important for users to feel that their perspectives and opinions are taken into account during discussions, so in general I believe that notifying editors who have asked to be informed should be allowed, even if their view on the topic in question is known. The specific example given is a rather extreme case; if an editor wants to know about every discussion in a certain area, it might be more efficient to advise them to watchlist a deletion sorting list, talk page, or noticeboard than notifying them individually every time, but is it really an issue if another editor does so, considering that if the first one cares so much, they may well find their way to the relevant discussions on their own? As for the other bullet points in the OP, I don't think it's helpful to treat WikiProjects as partisan (largely based on what Isaacl wrote above), but I don't have any objection to the 1st & 4th bullets; APPNOTE already says that doing the first is good practice and it would make sense to make that into a requirement, as long as other users don't come down like a ton of bricks on editors who forget once or twice. Hatman31 (talk) 16:54, 18 April 2023 (UTC)

  As I wrote in the discussion on the canvassing talk page, it's common practice for editors to request to be notified about certain discussions. Typically it's for a specific set of discussions, such as the notification list the arbitration committee set up for discussions on changing the discretionary sanctions system. I agree interested editors should be pointed to the existing notification systems in place, including watching relevant noticeboards and WikiProject talk pages. In cases where someone chooses to send notifications for a more tailored situation, they should open it up to anyone to use. I appreciate, though, that within the bounds of English Wikipedia's current decision-making traditions, there is a vote-stacking issue when the criteria for notifications is chosen such that those interested in the notifications have the same opinion. isaacl (talk) 17:16, 18 April 2023 (UTC)

  but is it really an issue if another editor does so, considering that if the first one cares so much, they may well find their way to the relevant discussions on their own The issue is that it's a loophole in our CANVASS restrictions; it means that any editor who wants to be canvassed just needs to ask to be so. If we are going to permit that loophole then there isn't much point in having CANVASS restrictions. BilledMammal (talk) 17:20, 18 April 2023 (UTC)

• How are "members" of a WikiProject defined? I think I have added myself to a list of members for 4 WikiProjects (two of which I wasn't certain I'd listed myself until I checked just now, and I wouldn't consider myself to be actively editing in the subject area for one of them). I have userboxes on my talk page that put me in a category for members of one WikiProject, and one task-force. I've watchlisted the talk pages of 36 WikiProjects that I'm would say I'm highly interested (i.e., I have some desire to weigh in at AFDs, RMs, etc). Of those, there are probably 21 where I've made more than 1,000 edits to articles in the scope of the project, and several more where I have repeatedly contributed to discussions on the WikiProject's talk page. I guess I'm a "member" of all those, but I haven't felt the need to formally list myself as such.Plantdrew (talk) 21:08, 18 April 2023 (UTC)

  Each project is free to set its own rules. In the case of WikiProject Military history, editors sign up at Wikipedia:WikiProject Military history/Members. The membership list is maintained by the project bot, which moves members to the inactive list if they have not edited Wikipedia in the last 365 days. Hawkeye7 (discuss) 22:11, 18 April 2023 (UTC)

  @Plantdrew, one doesn't actually notify "members"; one posts a note on the group's talk page, which notifies members, non-members, participants, non-participants, editors passing with requests for help on other subjects, RecentChanges patrollers, etc. WhatamIdoing (talk) 15:56, 24 April 2023 (UTC)

• We want more editors to be informed, not less. Imagine societies where the media is restricted and people have no way of knowing what is really happening in their government. That is basically what is being proposed here, to our governance model. --Rschen7754 22:40, 18 April 2023 (UTC)

  Were it up to me I'd strike WP:CANVASS from the list of policies wholesale. I think it does more harm than good—it serves no legitimate purpose other than giving people who are sore about losing a debate means to tattle on their opponents at one of the drama boards in hopes of getting the newly-established consensus overturned. Such policies are the worst thing about Wikipedia; they turn off far, far more potential contributors than any supposed benefit they give us. —Scott5114↗ [EXACT CHANGE ONLY] 23:05, 18 April 2023 (UTC)

• I disagree with the premise. I'm in a handful of wikiprojects and none of the ones I'm in votes as a unified block in anything. In every project I've participated in, the debates between the project members aren't that different than the ones seen in the wider Wikipedia community. I don't deny there has been a handful of arbcom cases where it's come to light there has been off-wiki collusion to affect a vote count. However, those are the extreme cases, not the norm. What I see starting to happen is accusations of canvassing are becoming a cheap allegation to retroactively poison the well when ones opinion isn't popular in a debate. It's an easy allegation to make, impossible to prove ones innocence. It's not unlike baseless accusations of plagiarism in academia or abuse in a divorce case. I'm concerned accusations of canvassing are starting to become the Wikipedia equivalent of Stop the Steal. Dave (talk) 23:42, 18 April 2023 (UTC)
• Comment I remember an AfD from a couple years ago on some Ancient Rome topic (don't remember the specific article). It was quite technical and none of us AfD participants could really understand it, so we shot a neutrally-worded message to Wikipedia:WikiProject Classical Greece and Rome for expert assistance. Curbon7 (talk) 23:46, 18 April 2023 (UTC)
• Comment. What about Wikiprojects that follow their own notability standards that are at odds with the community's? We saw after a well-attended 2017 RfC that the larger community strongly supported the (existing) requirement that all sportsperson articles meet GNG, but since the larger community is not directly notified about selected AfDs and is less likely to participate in them anyway, the sports projects went right on using their criteria without consequence. The same thing happened for many months after the NSPORTS2022 RfC where editors from these projects deliberately ignored the consensus and continued !voting keep based on deprecated criteria even when no one could find any SIGCOV. Many of these AfDs got closed as keep because project members are already over-represented at AfDs on their topic, and this becomes even more lopsided when members alert each other to particularly contentious AfDs.

Perhaps what this discussion is telling us is that we should make an "article deletion task force" WikiProject where all the editors frustrated with lax standards and inconsistent application of P&Gs in AfDs can combine their efforts across multiple topics. Then perhaps it wouldn't be a month-long painful ordeal--including a keep close in the middle--to delete a subject because some editors claim GNG/ANYBIO is met with 40 words in a local newsletter reproducing verbatim a facebook post by the subject's team announcing the results of an anonymous Google docs poll held by the Twitter account for the league's fan club... JoelleJay (talk) 05:08, 19 April 2023 (UTC)

Or, maybe it's telling us that your "article deletion task force" standard isn't working all the way across the board like you wish it did, and maybe our existing P&Gs need to be updated to be more inclusive of that fact so editors wouldn't be that frustrated anymore... Huggums537 (talk) 05:28, 19 April 2023 (UTC)

Good lord, an "article deletion task force"? You can't delete your way to making the encyclopedia better. The only thing that would accomplish is sending the project into irrelevancy by scrubbing it of content a reader might find useful. —Scott5114↗ [EXACT CHANGE ONLY] 06:17, 19 April 2023 (UTC)

I actually would welcome such a development. Then we know where everyone stands. --Rschen7754 06:20, 19 April 2023 (UTC)

No one "stands" anywhere. What every person does is they assess each article, and then they compare what information they can find about that article and its subject, and they also compare that to the standards for whether or not we should 'have' an article at Wikipedia on that subject, and based on all of that information, they decide, for themselves, whether the article and/or subject meets the minimum requirements. People don't have "stands", they just do the best they can to make the best assessment possible each time. The fact that people may read or interpret the standards and different ways doesn't mean they take "stands". Different is not wrong, and the world will always have differences over what the standards mean, and whether any one particular article may meet those standards. --Jayron32 14:30, 19 April 2023 (UTC)

That is a very optimistic view of things, but when the same people vote the same way over and over against the same subject area, it's time to call a spade a spade. Please read [8] and tell me that this is not a stand. Rschen7754 00:13, 20 April 2023 (UTC)

When people vote the same way over and over it means they are consistently applying the standards as they understand them. --Jayron32 12:44, 20 April 2023 (UTC)

Not necessarily. They might just have a bias against that subject area. Rschen7754 16:45, 21 April 2023 (UTC)

The fact that this is your first interpretation of someone's actions is problematic. If you set out assuming people are doing things because they are bad actors, 1) you're going to believe that evidence points you that way and 2) you're going to interpret all of their actions, no matter how benign, that way. That's why the WP:AGF policy exists. Actions should be viewed as people doing their best to make the encyclopedia better. Yes, of course, there are vandals and POV pushers, and all that. But merely because people have a different interpretation of policy than you do, and vote differently than you would have in a discussion, doesn't mean they "have a bias". It just means they read things differently. No one has presented any evidence of bias beyond what could be easily seen as a difference of interpretation.--Jayron32 17:12, 21 April 2023 (UTC)

It's not just "applying the standards" in the sense of applying the written rules. But I agree that people with all sorts of views are doing their best to make the encyclopedia better. One editor might believe that keeping an underdeveloped, weakly sourced two-sentence stub makes the encyclopedia better; another might believe that deleting the same article makes the encyclopedia better. This view goes beyond "a different interpretation of policy", as there is no policy about whether the English Wikipedia's quality should be measured by its aggregate collection of information (4.2 billion words total) or the length of the average article (~650 words for the mean, a bit lower for the median). An editor who supports the Least publishable unit approach (lots of very short articles on narrow subjects) is not really applying "policy" any more than an editor who supports m:mergism (fewer, longer articles on broader subjects). WhatamIdoing (talk) 17:18, 24 April 2023 (UTC)

My "stand" is that articles should be subject to consistent inclusion criteria across the encyclopedia without being influenced by how much one group likes or dislikes a given topic area. When the global community has a consensus view on what criteria or types of coverage contribute to notability, whether that consensus is enforced at a given AfD should not depend on who happens to show up. And yet that is exactly what happens because even if a wikiproject represents a minority of the global community, it is highly overrepresented at discussions on topics within its scope, and thus if those members reject consensus in favor of their own internal metrics, they can easily form a local majority. The hypothetical "deletion task force" would exist to promote compliance with our P&Gs, regardless of whether that results in a keep or delete outcome. JoelleJay (talk) 01:52, 25 April 2023 (UTC)

I think it is a very false assumption to say the groups showing up are a minority view while the ones not showing up represent some "global community consensus" that is absolutely opposite to whatever was decided by whoever showed up. It could just as easily be interpreted that by not showing up, the "global community" has given implied consent to the outcomes since they did not show up opposing them. We wouldn't know either way because they didn't show up to say, and you are not the one for acting like an arbitor of that decision for the global community or as a representative for the creation of any kind of "force" based on such faulty assumptions. It could also be interpreted that in the case the global community did in fact imply consent for the outcomes made from participants by not opposing, such a "force" being created would actually become the offending partisan group itself. Huggums537 (talk) 02:36, 25 April 2023 (UTC)

Re: {When the global community has a consensus view on what criteria or types of coverage contribute to notability - sure, but this premise exists more often in the minds of certain editors than it does in reality, IMO. For some, WP:SIGCOV is to he interpteted as "independent RS have to show a topic is important by writing about it at length" whereas other editors contextualize that guideline differently and interpret it more as "independent RS must provide usable information that can be used in writing an article". Still other editors read SIGCOV as though it meant the same thing as WP:SIRS (which is supposed to be NORG-specific). My limited experience at AfD suggests that many editors approach most discussions with a preconceived view of "this article should/shouldn't exist" and then base their assessment of SIGCOV - or even of source reliability - on that preconception.

In any case, the view implied by BM's comments - that there is an underlying distribution of support and opposition (e.g., to AfDs) that ought to be reflected in specific formal processes and that is distorted by wikiproject notifications - does not appear, from this discussion, to be widely supported within the community (in a discussion that, as far as I know, has *not* been subject to CANVASSing or other notifications). Newimpartial (talk) 10:18, 25 April 2023 (UTC)

Obligatory note that this discussion is also not an indication of "the global community" -- it's maybe 20 people -- nor is it a representative sample, since the majority of people in it have also been in the last 5000 discussions about sports articles at AfD making the same points (which is what this is really about). Gnomingstuff (talk) 14:09, 26 April 2023 (UTC)

I really really hate this dumb inclusionist vs. deletionist debate because it only leads to comments like this one. Then we know where everyone stands is absolutely not a phrase that should be uttered by any editor, let alone an admin. Curbon7 (talk) 14:39, 19 April 2023 (UTC)

Though, I don't think any editor should be campaigning for a task force to delete as much as possible, either. BeanieFan11 (talk) 14:45, 19 April 2023 (UTC)

Two wrongs do not make a right. Curbon7 (talk) 15:03, 19 April 2023 (UTC)

I'm not sure that it's really a task force to delete as much as possible. It might be more fairly described as a task force to follow the letter of the law. WhatamIdoing (talk) 00:24, 26 April 2023 (UTC)

+1 -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 20:52, 19 April 2023 (UTC)

Did you know that topics don't have to have standalone articles to be covered in an encyclopedia? JoelleJay (talk) 01:05, 25 April 2023 (UTC)

The Free Encyclopedia Anybody Can Edit + Article Deletion Task Force + NPP(effectively an Article creation task force) = Wikipedia, The site that used to "Make The Internet Not Suck" has become the angry Karens of the internet, who call 911 and demands the swat team gets rid of everyone new who shows up at the park "acting wierd". Dave (talk) 15:32, 19 April 2023 (UTC)

I'd say that Wikipedia:Articles for creation is the "article creation task force". NPP's original and most important job is to identify new pages that meet any of the Wikipedia:Criteria for speedy deletion. WhatamIdoing (talk) 00:25, 26 April 2023 (UTC)

I always leave a message saying if I've placed notifications, just as a courtesy and for transparency. I don't think restricting notifications that are made in a neutral manner is helpful. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:03, 19 April 2023 (UTC)

Answering questions from the lead. 1) yes, transparency is good and notifications to everyone are best practice. Linus's law logic applies: the more eyes... etc. 2) no opinion at present, this is somewhat unclear to me 3) I agree WikiProjects can be partisan, but I also think it's fine to notify them IF they are relevant. For example, if an article is tagged as within scope of WikiProjects A, B and C, they should be notified. Technically they already may be through Article Alerts and like, but there is nothing wrong IMHO from notifying them in other ways (their talk pages, I guess?). 4) I agree they should not, unless they concern that WikiProject only, which would be quite rare. Arguably, this can be a case by case basis issue, but I don't recall an RfC that was held at WikiProject in a long time. Some examples might help refine my vierw, if anyone would care to provide them and ping me. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 05:32, 22 April 2023 (UTC)

I like this idea about "Linus's law". It supports the idea that Blueboar saying earlier about giving notice to the most eyes possible. There is a difference between giving notice to as many people "as possible" (with a good faith assumed meaning being "as allowed" of course!), and spamming people not even related to the discussion. Huggums537 (talk) 08:51, 22 April 2023 (UTC)

The purpose of this page is to provide creative and positive feedback, not to bicker endlessly about the merits of ideas. To address the four suggestions: 1) seems fairly uncontroversial; It is good practice to leave a note at the discussion itself about notifications which have been made, particularly if made to individual users is already part of the guideline, and I don't think there'd be too much resistance to tuning "It is good practice to..." up to "Users should..." or something like that. 2) I think APPNOTE already makes clear that even when making notifications covered by APPNOTE, you should not send inappropriate notices, as defined in the section directly below. I don't know that an RfC on this fairly narrow issue would go very far toward resolving your concerns. 3) I mean, I get where you're coming from, but this has been discussed for years (cf. the Article Rescue Squadron debates) and there's just not going to be a consensus to prevent neutrally worded notices to WikiProjects (and as long as we have the Article Alerts Bot, it wouldn't matter if there was). As all the drama above indicates, an RfC on this issue is likely to shed more heat than light. 4) I'm honestly not sure how this would land. Personally I'd tend to agree with you, but you're going to have a hard time convincing people that a well-advertised RfC presents a CONLEVEL issue, and the "disproportionate participation" issue is true in all sorts of forums (the people who watchlist policy talk pages, for instance, are rarely representative of the community at large). One option would be to hold all RfCs on separate subpages of Wikipedia:Requests for comment, but that might be a larger-scale change than most people would be comfortable with. Hope this is helpful. Extraordinary Writ (talk) 19:44, 23 April 2023 (UTC)

There's an important distinction between the Article Alerts bot and a project talk page post, which is that the latter pretty much only occurs for contentious (or expected-to-be contentious) AfDs, and the poster anticipates project members will support their desired outcome. JoelleJay (talk) 01:02, 25 April 2023 (UTC)

• If a group of editors frustrated with lax standards and inconsistent application of P&Gs in AfDs were formed, then BilledMammal's proposal would ban us from telling them about any AFDs.
• I believe these editors tend to hang out at Wikipedia:Deletion review.

WhatamIdoing (talk) 16:00, 24 April 2023 (UTC)

• ...Yes
• The regular editors at DR tend to be more likely to support keeping articles. JoelleJay (talk) 00:56, 25 April 2023 (UTC)

  They seem to favor consistent application of policies and guidelines. Will "opposing lax standards" and "supporting consistent application of the policies and guidelines" going to turn out to be contradictory goals? Our written standards are lower than people might expect if they're relying on our informal advice. Plausible interpretations (NB "plausible", not "my own preferred") of the actual written policies and guidelines require the existence of just two independent sources in the real world, only one of which must be secondary, using the lowest possible standard for secondary, and these sources don't technically have to be cited, unless the article is about a BLP. Also, all sources considered in combination must have a quality that we call "significant coverage" but refuse to define in any way, so it is a case of SIGCOV being in the eye of the beholder. WhatamIdoing (talk) 00:15, 30 April 2023 (UTC)

  Out of thousands of discussions, I've only come across two editors who have claimed only one source has to be secondary and that SIGCOV is distributive (for non-NBASIC subjects). What part of "sources should be secondary sources" implies a GNG-contributing source can be primary? JoelleJay (talk) 01:58, 30 April 2023 (UTC)

  @JoelleJay, did you ever read the footnote in the middle of that sentence? The one containing the words "In the absence of multiple sources", i.e., that the guideline says it's not strictly necessary to have multiple secondary sources? WhatamIdoing (talk) 23:27, 2 May 2023 (UTC)

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)

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. Wirtschaft
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)

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)

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)

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)

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)

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)

• 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)

• 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 oder 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)

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)

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)

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)

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)