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, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

A way of resolving "No consensus"

In an RfC, when there are two choices and no consensus can be reached, we are left with no decision. If no consensus generally means we stay with what we had before, then at least we have something, but sometimes there is no established rule to fall back on and we are left with mixed usage. In that case, Wikipedia is inconsistent, looks sloppy, and nobody's happy.

However, at that point we could ask another question to see if there is a consensus that either option is better than no decision, then a coin could be flipped or the closer could make a decision based on a majority rather than a consensus.

I proposed this in one case and the answer was that we don't do that here. I've been involved in several such RfCs on matters of style and Wikipedia remains inconsistent. I think either choice is often better than no choice.

What think you? Has this been suggested before? Any other ideas? Thank you.  SchreiberBike | ⌨  23:45, 2 March 2023 (UTC)

No. --Jayron32 13:20, 3 March 2023 (UTC)

I cannot imagine why choosing a result that is not supported by consensus makes sense. A perfectly consistent Wikipedia is a mirage that will never exist. Forcing agreement won't help anyone. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 13:33, 3 March 2023 (UTC)

@Ixtal: No hope of forcing agreement or becoming perfectly consistent. Right you are. But we could hope to stop endless arguments between pedants who seem to prefer to argue rather than solve a problem. SchreiberBike | ⌨  23:03, 3 March 2023 (UTC)

It is fine for Wikipedia to be inconsistent, because the real world is. WP:ENGVAR is a great example of Wikipedia choosing to be inconsistent over one of the several options. This is a feature, not a bug, as it helps Wikipedia align with the real world. —Kusma (talk) 13:54, 3 March 2023 (UTC)

Could you give 2-3 examples of RFCs where you think this would have been a better outcome? It would help to understand what you are wanting to see. ~ ONUnicorn^{(Talk|Contribs)}problem solving 14:00, 3 March 2023 (UTC)

@ONUnicorn: Two I've been involved in were:

• Should Wikipedia say "the Gambia" or "The Gambia" midsentence. There are good arguments for both. A recent RfC closed as "No consensus", so we have usage in articles and in article titles that goes both ways. For some people, especially some Gambians, this is a very important issue. It's been a low-key edit war for years.
• Several books worth of writing and editor time has been spent trying to reach agreement on the capitalization of universe in an astronomical context. Again, reasonable arguments can be made both ways and no consensus has been reached.

Flipping a coin or picking an odd or even number in some lottery would resolve these and people would stop yammering about them for a while. Maybe people shouldn't care so much, but they do.  SchreiberBike | ⌨  22:12, 3 March 2023 (UTC)

I found the RFC for (T/t)he Gambia, but I'm not finding the one for (U/u)niverse. I can see Gambia being quite contentious. For (U/u)niverse, however, I would think it would be more context dependent. For example "There are billions of galaxies in the Universe" seems like it's being used as a proper name, thus should be capitalized, whereas in, "Imagine a universe where the laws of physics were different..." it is not being used as a proper name, thus should be lower case. I think your proposal might help provide clarity in a situation like (T/t)he Gambia, but it could also end up inflaming the situation, especially if Gambians feel strongly about it and do not feel their voices are being heard in whatever decision gets made. I do not think your proposal would be appropriate for something as context dependent as (U/u)niverse, but I could be misunderstanding the debate there as I have not found the actual RFC. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:45, 6 March 2023 (UTC)

@ONUnicorn: The last one I tried for universe was at Wikipedia talk:Manual of Style/Capital letters/Archive 16#Capitalization of universe - request for comment, eight years ago. Wikipedia talk:Manual of Style/Capital letters/Archive index lists six more. The details you mention were covered and there was general understanding that if universe was to be capitalized, it would only be capitalized in some contexts.

A common idea is that a rule is needed if there is disagreement among editors and editor time is being spent arguing about it. SchreiberBike | ⌨  03:45, 7 March 2023 (UTC)

The obvious question is, what happens if there is, in turn, no consensus for either option being better than no decision? Gnomingstuff (talk) 16:05, 3 March 2023 (UTC)

@Gnomingstuff: Then we are no worse off than we were before, but if there is a consensus that either option is better than continued inconsistency, it's a problem solved and Wikipedia is better, more consistent, more credible. SchreiberBike | ⌨  22:16, 3 March 2023 (UTC)

Solution in search of a problem. Papers have actually been written about how our epistemically conservative consensus system is uniquely well-suited to resolving the presentation of conflicts. _signed, Rosguill ^talk 16:19, 3 March 2023 (UTC)

@Rosguill: As an example, imagine Wikipedia as a new country with a new transportation system. I doubt we could reach consensus that we should only drive on either the left or the right; would we continue to let people drive as they please with the resulting accidents and inefficiency? Neither right nor left is inherently better. I'm wondering if people are interested in finding a new way to solve long-standing problems that have not been solved by our consensus system, even if that system usually works. SchreiberBike | ⌨  22:25, 3 March 2023 (UTC)

The obvious solution is for everyone to slow down enough that it does not matter which side they are driving on… sure it takes longer to get where you want to go, but there are no accidents. Blueboar (talk) 02:13, 26 March 2023 (UTC)

The roads analogy is hyperbolic and doesn't really correspond to any situation on Wikipedia. _signed, Rosguill ^talk 22:30, 3 March 2023 (UTC)

Of course it's hyperbolic, but the examples I give above of The Gambia and universe correspond closely. We let people edit as they please resulting in argument and inefficiency. It makes Wikipedia look less professional, less consistent and less credible and it wastes our time.  SchreiberBike | ⌨  23:14, 3 March 2023 (UTC)

It is a waste of time to attempt to enforce uniformity in stylistic matters that have no real importance. Given how poor our sourcing is in many areas, our credibility is arguably too high already. Note also that WP:ENGVAR, our deliberate inconsistency in using all kinds of different spelling systems does not seem to have caused any real world issues that I am aware of. Making decisions that go one way and possibly violate WP:NPOV is much worse than inconsistency. —Kusma (talk) 10:55, 4 March 2023 (UTC)

@Kusma: Yes we have several deliberate inconsistencies (ENGVAR, DATEVAR, ERA and SERIAL come to mind) and yes those do make English Wikipedia stronger. But we have also set standards in thousands of ways, that's largely what the policies and guidelines are, and those also make Wikipedia stronger. I can't see how having both History of the Gambia and Military history of The Gambia makes us better. (Unless it's good that it keeps people from taking what we write seriously.) SchreiberBike | ⌨  03:49, 7 March 2023 (UTC)

There are times when it would be preferable to settle a dispute rather than continue it via no consensus, but they're few and far between. The recent WP:ACAS is a good example, and in that case the closers did basically as you suggest: reduce one of the questions to a pure headcount. My [well-documented at this point] position is that the headcount question was the wrong one -- that we should've come out of that slog with at least a definition of what we mean when we call about "mass creation" or the like instead of a strange, arguably redundant rule applying to an ill-defined concept. What makes it hard in a case like that are the entrenched camps and drama carried over from specific cases/people, coloring an important policy debate. There are specific cases when I feel like it would be a net positive to the community to either grant the closers slightly more leeway than usual to glean important conclusions from an otherwise messy discussion, or to find some other approach like you're describing. I certainly wouldn't support and policy/proposal that included relying on coin flips or headcounts, but there are other possibilities. For example (I tossed this out at the arb motions board), run the same RfC again but don't allow anyone who participated in the first RfC to !vote (talk page only). I think that would be worth a try sometime, despite the inevitable complaints. YMMV. — Rhododendrites ^talk \\ 23:07, 3 March 2023 (UTC)

@Rhododendrites: There are plenty of problem solving methods we haven't tried yet. What I'm suggesting is that if there is a consensus that people are willing to accept the results of some method besides consensus, we should specifically allow that. SchreiberBike | ⌨  03:52, 7 March 2023 (UTC)

• Adopt some form of Speaker Denison's rule: when you have no consensus, preserve status quo as much as possible. dwadieff ✉ 17:40, 6 March 2023 (UTC)
  • @David Wadie Fisher-Freberg: Yes, we have a set of rules, which generally do amount to that. This would apply when there is no status quo. SchreiberBike | ⌨  03:54, 7 March 2023 (UTC)
• [1]. Phil Bridger (talk) 19:46, 6 March 2023 (UTC)

I've notified Wikipedia talk:Consensus and Wikipedia talk:Closing discussions of this discussion. Thank you, SchreiberBike | ⌨  04:03, 7 March 2023 (UTC)

Conclusion

I thought this was a good idea, but it has not gained support here and that's ok. I did find a similar discussion that went nowhere 17 years ago at Wikipedia talk:Manual of Style/Archive 24#Consistency.

I still want to explore the idea and I'm considering opening an RfC at the Manual of Style talk page for capitalization asking something like:

Given that we've been unable to reach consensus on the capitalization of universe in many discussions [which I will list], is there a consensus that the results of a coin flip (or similar random choice) would be better than what we have now?

Would I be acting in bad faith or forum shopping if I made that proposal there? SchreiberBike | ⌨  18:21, 14 March 2023 (UTC)

I think continue the discussion here, but change the title/create a new topic similar to- What should we do when Consensus cannot be reached when there are strong opinions on small changes? Wakelamp d[@-@]b (talk) 15:00, 27 March 2023 (UTC)

In that sort of example, it depends on the question!

"Do we capitalise [u/U]niverse in all cases", may get 'no consensus'. "Should we have a consistent capitalization for Universe" may get a strong consensus for 'Yes'. You can then build on the conversation to define /how/ we determine which to use (i.e. "having agreed we should be consistent, let's use whatever the BBC uses"), and finally let that discussion determine the answer. If the consensus is 'No' or 'Use the local consensus', 'Use whatever the sources use' etc. then you also have a consensus. Ultimately, it sounds like a lot of effort, and we don't require absolute consistency in matters of style anyway! JeffUK 16:00, 28 March 2023 (UTC)

@SchreiberBike Alterantes to random choice (which is a common Agile (or Fail-fast/learn fast approach) for low cost/low risk reversible decisions, these three wiki articles are relevant Consensus_decision-making, Group_decision-making, and Consensus-seeking_decision-making]]. We also have some extra constraints in terms of WMF unweildiness due to complexity (300+ languages and 800+ wikis) and long term technological under-investment

For instance, some group process chnages

- the Internet RFC approach which is a of requirements gathering, problem defintition, analysis, consensus, then summarise current arguments, and rinse and repeat. In this case I think the problem should be defined as "How we can allow people to display alternate content"

- Extend the consensus - If connsensus can not be reached then expand the electorate (consensurate??) involved in a non canvassing fashion. Start with article ->RfA-> Pump-> RfC-> Community-> Readers

- Focus on Problems first

Wakelamp d[@-@]b (talk) 04:34, 30 March 2023 (UTC)

Preprocessor for The Universe

@JeffUK Maybe we should interpret your phrase that "we don't require absolute consistency in matters of style anyway" in its broader sense, Why not allow readers to specify Wikipedia preferences for the style of words and phrases and then locally preprocess (or pre-process in the UK :-)) the wikitext before display (I just found [[2]]

A personal bugbear is when personal preferences in minor matters are imposed on groups (especially without evidence). Some issues with Vector 2022 were great examples as it stops evolution of systems and groups, and wastes time on the trivial but annoying/high friction)).

Things we could do with a preprocessor

- specify dialect fot spelling (UK/US/Indian/Australian/..) There is some 2019 research in the 90% for identification of dialect words.

- Use O/S or user preference for display of dates, numbers,

- Spelling "The Universe" as "the universe" off standard or private lists.

- Use different style (Wiki's own , Strunk, Oxford commas etc)

- Automatic conversion of amounts into currency of choice, and

- Display of prefered Nationality for those endless fights over BIOs

- or even showsing editor names as their preferred Avatar

- Display preferred language if available (as non auto translated) and then current page language (eg Spanish, Simple English, English, autotranslated into Spanish) by section

Some of these cases have already been mentioned for [[3]] @User:Sannita_(WMF), @WhatamIdoing, but it would be nice to implement some parts of Abstract earlier,

Ward_Cunningham (The creator of wiki wiki, had an | article level] approach to these and other centralisation issues with idea with Federated_Wiki/

Wakelamp d[@-@]b (talk) 05:25, 30 March 2023 (UTC)

Do you mean something like allow the user to set their language to en-gb and then wrap every word that has a variant in a template like {{i18n|color}} that renders as colour? Barnards.tar.gz (talk) 06:49, 30 March 2023 (UTC)

The below is a tortured attempt (with I am certain many errors) to show punctuation (quotation marks, Oxford comma, hyphenation), language differences, and spelling. The parts that woul be coloured would be The Gambia, camdy floss, crisps, and clag.

"He dreamt that night that he had apologised to his humourless neighbour from The Gambia by singing. ‘My accusation on the 1st of October 2012 AD at 8 AM (GMT) was unfounded; your well travelled llama did not eat candy floss coloured purple, or the crisps, or the pre-school’s clag labelled "toxic".’

"They dreamed that night that they had apologized to their humorless neighbor from Ghambia, by singing, “My accusation on October the 1st 2012 CE at 2000 UMT was unfounded; your well traveled llama did not eat cotton candy colored purple, or the potato chips or the preschool’s glue labeled 'toxic' ”.. Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 12:47, 30 March 2023 (UTC)

Immediate problem with that is that if it requires each word which has a possible variant to be marked up then it would make editing impossible for anyone who's not a computer programmer, and it couldn't be applied automatically, because you'll end up with "Color: spelling differences: Brits and the rest of the world spell color as 'color' while Americans spell color as color" either way, its' a hell of a lot of work simply to achieve consistency across articles, and there's a strong consensus that consistency across articles doesn't matter. Also, what about when Brits disagree with each other. e.g. "Dispatch Department" and "Despatch Department" are both in common use in the UK. JeffUK 19:37, 30 March 2023 (UTC)

Maybe no markup editing change is needed, and definitely not consistency - without our quirks Wikipedia becomes soulless and dull.

1. Mediawiki- Could you tell me where the dispatch department is at The Gambia's main airport?
2. New pre-processor - Has the reader specified a preferred dialect? Yes - British UK version 14 (despatch, Gambia)
3. Wikipedia displays : Could you tell me where the despatch department is at Gambia's main airport?
4. Displayed on Edit ; Could you tell me where the dispatch department is at The Gambia's main airport?
5. Displayed on Visual edit (for preference British UK version 14; Could you tell me where the despatch department is at The Gambia's main airport? Wakelamp d[@-@]b (talk) 05:53, 7 April 2023 (UTC)

Completely remove the idea of a "minor edit"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I 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.[4] 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)

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)

Show number of thanks in edit history?

As a follow up to my other proposal for improving/reducing discussions on edits... (really hope that first proposal will be picked up someday as it would help SO much)

Why don't we show the number of thanks an edit has received in the edit history?

It might help show "consensus" with other editors when editing certain pages and avoid edit wars. A user might be less inclined to just revert an edit if he notices that others support it but might be more inclined to start a discussion. {{u|Gtoffoletto}}  ^talk 17:23, 21 March 2023 (UTC)

I don't think we currently reveal which edits received thanks, only who thanked whom and when. Certes (talk) 17:27, 21 March 2023 (UTC)

Do we have the ability to reveal that? - L'Mainerque - (Talk - Signbook) - 22:36, 21 March 2023 (UTC)

Thanks log documentation suggests not: the information is not stored in logging. Certes (talk) 22:49, 21 March 2023 (UTC)

Okay, thanks (no pun intended) for letting me know. - L'Mainerque - (Talk - Sign) - 22:52, 21 March 2023 (UTC)

I think that if implemented this would pretty soon be gamed by spammers to such an extent that it would be meaningless. I get what seems to me to be a lot of thanks from other editors, and I also give some out. Let's all take private satisfaction in that rather than make this public. Phil Bridger (talk) 23:00, 21 March 2023 (UTC)

Now that I think of it, yeah, it would be abused by spammers and people acting in bad faith. - L'Mainerque - (Talk - Sign) - 23:08, 21 March 2023 (UTC)

Would it be abused? Thanks are pretty rare at the moment (or is it just me? :-P). If you could see who gave the "thanks" you could then evaluate it.

In any case I think @Certes is saying this feature would not be technically doable? {{u|Gtoffoletto}}  ^talk 22:46, 22 March 2023 (UTC)

Looking at the code (I'm not a coder so forgive me if I'm wrong), it would suggest that Certes is correct in saying that it would not be technically possible at the moment. - L'Mainerque - (Talk - Sign) - 23:04, 22 March 2023 (UTC)

I'm saying that the data stored in the obvious place only has thanker, thankee and time; no indication of which edit or even which page was edited. That information may be stored elsewhere, but I doubt it. There's a sample extract here. Certes (talk) 23:07, 22 March 2023 (UTC)

Actually this can't be right: when I get a notification of a "Thanks" it does show which specific edit received it. So that information is available somewhere. {{u|Gtoffoletto}}  ^talk 00:40, 23 March 2023 (UTC)

When you send a thank, you do send it for a specific edit or action (e.g. Special:Thanks/1146124820) - that could pass on to notification system and not actually "store" that part though, I haven't read all the code on this. — xaosflux ^Talk 00:51, 23 March 2023 (UTC)

See also phab:T51087 (from 2014) and phab:T324134 for related topics about this. — xaosflux ^Talk 00:54, 23 March 2023 (UTC)

I wasn't involved in that project, but I remember hearing that this was a deliberate decision. There are privacy implications in publicly revealing that Alice thanked Bob for a particular edit, because that means that Alice was reading a particular page or agreed with a particular contribution, which Alice might not wish to be public information.

The Echo/Notifications separately stores all of this information (thanker, thankee, timestamp, and diff). However, that is temporary (two years or 2,000 notifications, whichever comes first). The permanent log stores only the thanker, thankee, and the timestamp. This combination allows admins to check for certain kinds of problems (e.g., interaction bans) but doesn't publicize certain other kinds of problems (e.g., how many times someone got thanked for being rude). Whatamidoing (WMF) (talk) 01:53, 23 March 2023 (UTC)

Since you are thinking about Thanks, this might be interesting:

This week, the Growth team completed a quick analysis of Thanks usage.

In early January, the Comumity Wishlist proposal to Enable Thanks Button by default in Watchlists and Recent Changes was fulfilled. Since the Growth team has been working on a Positive Reinforcement project, we were curious to see if this change increased the number edits that were thanked. As is often the case, the answer isn't totally clear and seems to vary by wiki. But perhaps more interesting is to see that the ratio of edits Thanked varies considerably by wiki, and seeing the low percentage of newcomer edits that receive Thanks. I'm not necessarily surprised by either finding, but I'm always thinking about ways to ensure newcomers receive the support and encouragement they need to continue to contribute, so feel free to chime in here or on the Positive Reinforcement talk page if you have any ideas. :) KStoller-WMF (talk) 20:50, 24 March 2023 (UTC)

@KStoller-WMF I think the consensus here is that we shouldn't rely on thanks for content disputes. Which I think is a good point. However I think it's great that you are making it easier to give thanks to other users.

Another great place would be right here in the discussion page. I have a quick "reply" button but I don't have a quick way to send "Thanks" for your message. I wanted to do that for some of the messages received in this discussion such as yours and I would need to find them in the history log! {{u|Gtoffoletto}}  ^talk 15:29, 28 March 2023 (UTC)

Yes, I can see how Thanks could get problematic in content disputes if publicly connected to an edit.

I would love to see Thanks added to discussion pages! I know the Editing team was considering that work as part of the DiscussionTools work: T249893. My understanding is that the Editing team is hoping to shift to another project soon, so I'm not sure if that work will move forward. KStoller-WMF (talk) 20:50, 28 March 2023 (UTC)

Is there a way to "vote" this feature or provide support? It would be very helpful I think. {{u|Gtoffoletto}}  ^talk 14:07, 29 March 2023 (UTC)

The community norms on Phab discourage voting, but I can tell the team directly for you. Whatamidoing (WMF) (talk) 04:02, 31 March 2023 (UTC)

Thanks! @Whatamidoing (WMF) (would have clicked it if it was there :-D) {{u|Gtoffoletto}}  ^talk 16:53, 6 April 2023 (UTC)

I am happy that thanks are low-key. If we try to use them to resolve content disputes, I expect the collegiate informal nature of them would be lost, and we would start to see things like gaming the system, or creating an expectation/duty to “vote” on edits. It might also encourage users to eschew discussion in favour of just bumping the thank count. We already weigh edit count too highly when judging other editors; we don’t need another high score or anything approaching social media upvote/downvote buttons. Barnards.tar.gz (talk) 21:22, 24 March 2023 (UTC)

I totally agree on you there. - L'Mainerque - (Talk - Sign) - 22:29, 24 March 2023 (UTC)

Yes, I agree that's a legitimate concern. {{u|Gtoffoletto}}  ^talk 15:24, 28 March 2023 (UTC)

I think not. At best this will just be interesting trivia, at worst it could encourage WP:NOTVOTING on edits, "You can't revert my edit because 100 people liked it..." JeffUK 21:54, 26 March 2023 (UTC)

I like this idea, though it's too easily to use this to make Wikipedia a popularity contest, and I think it's obvious that we aren't Reddit. I'd suggest keeping it low-key similar to the position of @Barnards.tar.gz's idea above. InvadingInvader (userpage, talk) 20:51, 5 April 2023 (UTC)

Pending Changes for talk pages?

Has there ever been any discussion of the possibility of enabling pending changes for article talk pages? I've noticed an uptick in purely disruptive edits on some talk pages, especially those dealing with contentious subjects where the article is already protected. Currently pending changes is not an option for talk page protection. -Ad Orientem (talk) 14:28, 25 March 2023 (UTC)

@Ad Orientem This actually sounds like something I'd support, but maybe at a different level.

I know the Abuse Filter can tag edits for further review, but can it hold edits for review? i.e. the edits are not published until an admin/PCR approves them? That might be a good solution for disruptive edits to talk pages. Some forums like Reddit actually allow for this. Aasim - Herrscher of Wikis ❄️ 05:26, 27 March 2023 (UTC)

@Awesome Aasim no, there is no where for the abuse filter to put something pending review, regarding an edit it can TAG an action, it can interrupt an action with a warning, and it can prevent an action. — xaosflux ^Talk 20:04, 27 March 2023 (UTC)

@Ad Orientem One of my interests is analyzing reasons/location/processes for abuse, and trying to find causes to solve and prevent it. Most of disruptive/abuse edits I have seen have been on user talk

Can you provide some examples of some contentious topics where this is happening? ( I looked at you user page and your stated interests don't spring to mind as inspiring conflict). And what type of editorWikipedia:IP_users, experienced , SPA, very new troll, .... etc

@Xaosflux Do some abusive/disruptive edits get removed from history? And would the abuse filter tag/stop an issue that is only to do with the edit summary? I ask because I went through a dump of a day's edit summaries, and there weren't as many offensive ones as the comments on village pump and by WMF concerning the toxic culture indicate Wakelamp d[@-@]b (talk) 07:20, 28 March 2023 (UTC)

@Wakelamp disruptive edits may be deleted or oversighted. The abuse filter actions can happen alone, or in combination. Abuse filters can trigger on action summaries. An abuse rule that makes a "log" or "tag" does not stop an edit unless it also is set to warn and/or disallow. If an abuse filter is set to private, and it stops an edit it won't be publicly reviewable. You can see all public abuse entries here:Special:Abuselog. — xaosflux ^Talk 09:37, 28 March 2023 (UTC)

@Wakelamp The incidents I typically encounter are a result of reports that show up at WP:AIV as auto-reported by the edit filter. As an admin I try to keep an eye on AIV when I can. IPs are the most common, but sometimes we get newly created accounts that are in most cases socks of already blocked users. In a few cases I've seen some that I was pretty sure were some specie or other of LTA trying to get around the protection on the main article page. Good old-fashioned trolls also pop up now and then. -Ad Orientem (talk) 21:01, 28 March 2023 (UTC)

• I would prefer not to extend pending-changes to talk pages for two reasons. Talk pages are already much less visible than Article space, so the harm of leaving disruptive content there is far more minimal. And my second reason is user-interface wise, I find pending changes incredibly confusing when there are multiple edits in a row. I never quite fully understand what accepting a change means, if there's disruptive content followed by productive content. An edge case question, do we have Article talk pages that are protected? (I only found User talk pages that were protected), and if so, how are editors supposed to request edits to said Article talk page? {{Edit fully-protected}} can only be transcluded on a talk page for example. ~ 🦝 Shushugah (he/him • talk) 22:24, 28 March 2023 (UTC)

  do we have Article talk pages that are protected? 129 are semi-protected (see cat, but it includes archives, FAQs, and Wikipedia: namespace pages too), 0 full-protected (cat); mostly happens in WP:CTOPs, mostly very temporary, and: how are editors supposed to request edits, they're not! DFlhb (talk) 22:39, 28 March 2023 (UTC)

  In addition to HouseBlaster's correction below, I'll add that there are in fact quite a few more protected talk pages that are not categorized as such, a few of which are indeed fully-protected (see Special:ProtectedPages). These are largely subpages and redirects, but there are some exceptions (e.g. 1 2 3) 74.73.224.126 (talk) 03:10, 3 April 2023 (UTC)

  Editors can request edits to protected talk pages at WP:RFED. HouseBlaster^talk 00:32, 1 April 2023 (UTC)

A new edit filter now prevents some talk page edits which clearly have no useful content. It should solve some but not all of the problem described above. Further details: WP:EFR#Talk page junk. Certes (talk) 14:42, 6 April 2023 (UTC)

Organizing potentially another Wikipedia blackout over RESTRICT Act

Relevant bill(s) of the RESTRICT Act: - Text - S.686 - 118th Congress (2023-2024): RESTRICT Act | Congress.gov | Library of Congress and BILLS-118HR1153ih.pdf (house.gov)

Relevant analysis by civil liberties organizations: Government Hasn't Justified a TikTok Ban | Electronic Frontier Foundation (eff.org) ACLU Strongly Opposes House Bill that Would Ban TikTok and Threaten First Amendment Rights | American Civil Liberties Union

In short: these bills would allow for US to shut down platforms that it deems to be a risk to national security. There is a lot of coverage about this in the news about a possible ban of TikTok; however, the way the bill is worded can be very very arbitrary, goes beyond TikTok, and can result in serious infringement on the same First Amendment rights that allow Wikipedia to exist in the first place.

Wikipedia successfully was able to protest the Stop Online Piracy Act back in 2011, but this may actually be something even bigger.

I want to raise this in idea lab before an RfC is made about this. Of course, any RfC to organize a blackout in the United States would require a very strong consensus. We would need to come to consensus on how long the blackout should be and what the blackout message should be.

This is relevant because Wikipedia is hosted in the United States and is subjected to US laws, and Wikipedia is committed to rights to freedom of speech. More than 150 million Americans use TikTok, which means that more than 150 million Americans could have their rights to freedom of speech restricted if such a ban was implemented, as well as dozens of small American businesses. As a project, Wikipedia is committed to uncensored, free, open speech. And as such, I believe it is crucial that that right remains open, and that social network platforms used for free speech, even those that may be considered "adverse", are not taken down.

That said, I want to figure out what the structure of such hypothetical RfC should be. A blackout should be considered a last measure, but it would be a very effective tool at getting a large number of Americans to understand what is at stake with this legislation. Aasim - Herrscher of Wikis ❄️ 05:23, 27 March 2023 (UTC)

If you want any hope of an RFC getting support, you need to laser focus on how the law would be an existential threat to Wikipedia, written with the same care and sourcing you might bring to a featured article. You're not going to be able to get enough support based on a general "Wikipedia is committed to uncensored, free, open speech" argument to overcome the "no politics ever" faction. Anomie⚔ 11:53, 27 March 2023 (UTC)

As a project, Wikipedia is committed to uncensored, free, open speech. - this is... not exactly true. I agree that Wikipedia doesn't care much about "national security", but we certainly exercise censorship of other kinds, for our own reasons. Wikipedia:Hate is disruptive talks about it a bit. 199.208.172.35 (talk) 15:01, 27 March 2023 (UTC)

Wikipedia:Free speech is another example of how we don't consider "free speech" when making decisions. Thebiguglyalien (talk) 16:49, 27 March 2023 (UTC)

I recommend you all take a look at "EC. 3. ADDRESSING INFORMATION AND COMMUNICATION TECHNOLOGY PRODUCTS AND SERVICES THAT POSE UNDUE OR UNACCEPTABLE RISK." in https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#idfbf26f984311432c8fea2c897ba0c6ba and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#ida5b4cba33bf94543966620a1c4b88d23 and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#ida350534aa5104ba8af5353289a4eff43 and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#idfbf26f984311432c8fea2c897ba0c6ba. IANAL, but what I am hearing from TikTok is that this bill, going beyond TikTok, allows for the ban of communications platform that the United States government believes is a risk to national security. This may affect Wikipedia since it (from what I am reading) gives US government power to unilaterally ban Wikipedia if they deem it a threat to national security.

I think a lawyer and/or WMF legal should give a proper analysis of this Act to determine whether this actually is a problem for Wikipedia. Even if it isn't, if it could permanently change the notion of freedom of speech in the US, as said in Verge, then it is something that WP should absolutely protest with a blackout.

I generally stay out of politics on Wikipedia because Wikipedia:NOTSOAPBOX, but I do wonder if we should follow precedent from the SOPA protest back in 2012 to determine whether we should stage a blackout or not. Aasim - Herrscher of Wikis ❄️ 04:08, 29 March 2023 (UTC)

You should also see What experts say a TikTok ban would look like for U.S. users (nbcnews.com) - namely the US has never issued a blanket ban on any app. This does seem like government overreach that is quite concerning. This is going to be a difficult proposal to write, if it is proposed, but it might be something to consider. Aasim - Herrscher of Wikis ❄️ 04:11, 29 March 2023 (UTC)

Hi @Awesome Aasimthis is a really interesting discussion. I'm Ziski from the WMF Global Advocacy team. I can make sure you get the information you're after from our team. What would you like us to provide? Generally how we're monitoring the RESTRICT Act and our sense of how it does/doesn't threaten Wikipedia..or something else? Please let me now if you have specific questions and we'll work on getting a response to you. Cheers! ~ FPutz (WMF) (talk) 17:48, 6 April 2023 (UTC)

Hi @FPutz (WMF), I am wondering if WMF thinks that this bill can be potentially disruptive to Wikipedia and/or the open Internet it supports, and if this bill might have affects about as big as SOPA. Also any reliable secondary sources that might back up this idea. What you are saying about "Generally how we're monitoring the RESTRICT Act and our sense of how it does/doesn't threaten Wikipedia..or something else?" is kind of what I am at.

If there is, then it might be a catalyst for a blackout RfC. I haven't had time because of university to dive more into the impacts of this bill, but I do want to see what WMF thinks. :) Aasim - Herrscher of Wikis ❄️ 18:53, 6 April 2023 (UTC)

Thanks for clarifying! That shouldn't be a problem. I'll start putting together a response to those points and I'll dig around for some further readings in case you are interested. I hope to have it for you soon - good luck with Uni in the meantime. FPutz (WMF) (talk) 19:15, 13 April 2023 (UTC)

@Thebiguglyalien are you talking about this? Right to free speech just means government can't do anything to block the free flow of information. Private entities like WMF can choose who can speak or not to speak; that is them exercising their right to freedom of speech by letting who they will listen to. Aasim - Herrscher of Wikis ❄️ 04:17, 29 March 2023 (UTC)

I'm talking about the fact that Wikipedia's mission is not to babysit free speech in the United States. It is to build an encyclopedia. Unless you have incredibly strong evidence that Wikipedia is going to be imminently banned, I'm going to assume that this is an attempt to disrupt the entire website over a political issue. Thebiguglyalien (talk) 04:53, 29 March 2023 (UTC)

Any blackout on its own will be disruptive at some level to readers. The consensus last time there was such a government overreaching potentially free speech violating law (SOPA) was that a blackout would be appropriate. I do think any measure done to protest RESTRICT should be done in a manner that is as least disruptive to the project as possible.

That could mean having a full or partial blackout, having a full page banner (which a user could click dismiss to), or running a banner campaign on users in the United States to get people to tell their representatives that RESTRICT can permanently fracture the open Internet. That can certainly be raised in the proposal.

As Anomie said, any such proposal has a high chance of success when written with the same rigor as featured articles, otherwise it would be considered a waste of time to most. Aasim - Herrscher of Wikis ❄️ 12:22, 29 March 2023 (UTC)

I support your proposal to protest the banning of online platforms, including TikTok. Even though I detest the despotic regime in China, I think there are other methods to deal with spying than banning foreign media. It's incredible that Congress is considering such authoritarian step, copying behavior of the Soviet Union and Eastern Germany. Thinker78 (talk) 04:24, 29 March 2023 (UTC)

I Oppose as the legislation does align with us in part. Some of the reasons for the ban (privacy, stopping espionage and threats to the individual, social media is not a social good ) do line up with the beliefs of some wikipedia editors, but others do not (removes a platform for free speech). I do think a company or government should be able to ban an app for their employees or contractors on any BYOD or provided device.

We also don't have clean hands and a complaint could boomerang on us.

1. We monitor editors and readers [5], and we monitor donors intensively.
2. We have banned some admins for being government stooges, but I assume they had access to check user tools in their language wikipedias before the ban, and
3. the WMF work with Big Tech (which collect an enormous amount of information) on projects or creates apps that are part of the android/apple/ ... infrastructure. These apps are built on code libraries that could be leaking information.

Also will the legislation do anything? Or will it just become Whac-A-Mole with new apps or literal moles (espionage within big tech, inserting code into chips, creating surveys, buying card purchase and voter databases). Regardless of the legislation, the internet at all levels is monitored by the National Security Agency and equivalents. Wakelamp d[@-@]b (talk) 06:57, 7 April 2023 (UTC)

I support such a blackout, but freedom of speech really isn't the issue here though. It is still a massive issue for the internet though. It's how this affects the freedom of international communications on the internet. Under this law the US could theoretically enact bans on any internet services affiliated with a country deemed adversarial. While this shouldn't apply to Wikipedia in the most strict reading, neither would SOPA. This law could easily be manipulated by the US government to restrict practically any internet service that it chooses to.

It has an incredibly broad scope that could easily affect Wikipedia and the entire internet as a whole. This act is just as big a threat, if not bigger (due to its severe restrictions on foreign communications), to Wikipedia as SOPA was, and I believe that Wikipedia should take similar actions to protest the act as it did with SOPA. Serafart (talk) (contributions) 04:27, 29 March 2023 (UTC)

I also endorse such a blackout, for as long as consensus feels is necessary. Loki (talk) 05:35, 29 March 2023 (UTC)

• Please no. --Jayron32 15:23, 30 March 2023 (UTC)

  Addicted?

  In all seriousness, though, can you please explain your reasons why @Jayron32? - L'Mainerque - (Disturb my slumber) - 15:28, 30 March 2023 (UTC)

  I believe strongly that this is a disastrous piece of legislation, and that it should absolutely not be passed. I believe it represents an existential threat not just to Wikipedia, but to the internet as we know it, and the legislation is also fundamentally in conflict with basic U.S. constitutional principles. I also think it is not the place for Wikipedia as an organization to make any political statement, no matter how noble. That's the first step on a very slippery slope that, while we've made the grave mistake of doing so at least once in the past, we should never do again. Or, more succinctly "Please, no." --Jayron32 15:35, 30 March 2023 (UTC)

  Wikipedia should absolutely not make political statements without consensus to do so. Is that true for you, or not even that? Why is it a slippery slope? - L'Mainerque - (Disturb my slumber) - 15:45, 30 March 2023 (UTC)

  Look, if there's consensus to do so, it wouldn't the first time I would be on the wrong side of consensus, and it definitely won't be the last. My contribution towards developing a consensus one way or the other is, and I quote, in case you missed it earlier, "Please, no". I hope that clarifies the matter for you. --Jayron32 17:13, 30 March 2023 (UTC)

  Okay, thank you for clarifying. - L'Mainerque - (Disturb my slumber) - 17:16, 30 March 2023 (UTC)

• No - Wikipedia is not the place to WP:RIGHTGREATWRONGS. Advocacy for or against any cause is inappropriate. We don’t take action, we neutrally report on the actions of others. Blueboar (talk) 17:47, 30 March 2023 (UTC)

  @Blueboar it's a bit more complicated than that. While the content of our articles do not WP:RIGHTGREATWRONGS, as a platform we have participated in a number of advocacy, from the SOPA Blackout in 2012, other language editions Spanish and German Wikipedia participated in a blackout in 2018 over the EU Copyright Directive and of course WMF itself does a lot of lobbying for freedom of expression. If you think this specific issue or tactic is wrong venue, I respect that, but to say we're not politically active, feels imprecise to me.

  I think the text/purpose needs to be reworked a bit, but I support something like an informative banner, and think reaching out to Meta:Main would be useful to hear their perspective, and then we can make an RfC here. ~ 🦝 Shushugah (he/him • talk) 18:03, 30 March 2023 (UTC)

  I am aware of our past advocacy, and I disproved of it at the time. I still disapprove… Strongly. I feel that our responsibility to maintain a Neutral Point of View extends beyond just article content. Our job is to REPORT- not to participate. Blueboar (talk) 18:21, 30 March 2023 (UTC)

  Wikipedia is an encyclopedia and its articles should be neutral but Wikipedia is also a project with its own set of needs in order to fulfill its objective. From time to time if those needs are imperiled, Wikipedia should raise its voice. Thinker78 (talk) 03:51, 31 March 2023 (UTC)

  Wikipedia doesn't have a voice. It has neither vocal cords to speak, nor hands to sign, nor fingers to type. It is an abstract concept and a collection of code stored in computer servers. You have a voice, and if you feel strongly that your work on Wikipedia is imperiled, you should feel empowered to raise your voice by contacting your elected representatives and make your voice heard. --Jayron32 11:44, 31 March 2023 (UTC)

Here are some more sources about this Act, related Acts, and a possible TikTok ban: [6] [7] [8] [9] [10]. While it is not our place to decide the fate of something unrelated to Wikipedia, it is our place to protest legislation that can be twisted in a manner to impede Wikipedia's goals of providing a free, accurate encyclopedia. Also please remember that this is not for straw polling or !voting but for developing this idea into something that might be ripe for an RfC. Aasim - Herrscher of Wikis ❄️ 14:12, 31 March 2023 (UTC)

It may be your place to do so. It may be other people's place to do so (insofar as they want to). That is the "we" that matters here, you (as an individual person) and other people (as individual people) who care and want to enact change. Wikipedia, as an organization, should take no public stance on anything. Instead, feel free to organize and use your own voice how you see fit, there's no need to involve Wikipedia in it. --Jayron32 15:05, 31 March 2023 (UTC)

I respect the principle of neutrality and not activism of Wikipedia that you are advocating but I don't fully share it. Although I share your concern about politicization of Wikipedia, I think there is certain times Wikipedia should take a stand, specifically in legislation that could affect its ability to fulfill its objective. That is, to provide free encyclopedia knowledge to humankind.

Undue censorship of Wikipedia is always a problem. Imagine the US government blocking Wikipedia as the government of China does. The prospect of the government having the power to ban online websites it doesn't like actually imperils the very existence of Wikipedia. Regards, Thinker78 (talk) 05:21, 1 April 2023 (UTC)

Also, regarding Also please remember that this is not for straw polling or !voting but for developing this idea into something that might be ripe for an RfC It is also the place to say "this is a bad idea, don't do that". I'm saying that now. --Jayron32 15:07, 31 March 2023 (UTC)

If Wikipedia the organization wants to do something, the corporation contact Congress. Wikipedia the site should just do our job. A blackout is the opposite of our job. --User:Khajidha (talk) (contributions) 23:03, 31 March 2023 (UTC)

Except there is actually some precedent for having Wikipedia do advocacy like this. If there wasn't I'd agree, but there is.

I think these could be the options for a hypothetical RESTRICT Act protest:

1. Full blackout - the entirety of Wikipedia would be inaccessible for the time of the blackout, with a notice that Wikipedia is protesting the controversial RESTRICT Act, similar to the SOPA protest
2. Partial blackout - only essential pages such as medical topics would be visible
3. Full-screen click-through banner - a notice about the Act would be visible to readers and readers would be able to act on it by contacting their local reps
4. Banner at top of page like in a similar manner to all the donation banners, but would be dismissable
5. Nothing if it is determined that this Act is not protest-worthy.

But whether it is protest-worthy or not is what the focus of this RfC would be. Aasim - Herrscher of Wikis ❄️ 17:41, 1 April 2023 (UTC) (edited 14:22, 7 April 2023 (UTC) to correct misfired act I keep mixing up)

I would like to note that the SOPA blackout was not a 'blackout' since there were engineered ways to get around it. Sungodtemple (talk • contribs) 00:56, 2 April 2023 (UTC)

I don't think it was precedent so much as a cautionary tale, warning us about what happens when we let editors think that political activism is tolerated on Wikipedia. Thebiguglyalien (talk) 00:33, 3 April 2023 (UTC)

Disagree with the premise of 'E', we can believe that the act is protest-worthy and still not think that it's appropriate to use Wikipedia as a vehicle for that protest. If we protested everything that was protest-worthy, we might finally get a default 'Dark-mode'! JeffUK 11:11, 4 April 2023 (UTC)

• Support banner, oppose blackout. I believe the Wikimedia Foundation, as a prominent organisation committed to principles of free information and freedom of speech has some moral duty to protest when its host country (i.e, the United States) proposes terrible legislation like the RESTRICT Act that has significant potential to affect the free exchange of information worlwide. There has been past precedents with this, like with our SOPA protest, which AFAIK was broadly supported. A banner would be a good idea. That being said, IMO blackouts should only be used if there is direct potential to adversely affect Wikipedia/Wikimedia. The RESTRICT Act doesn't quite past that test. Obviously not a lawyer, but my reading of the Act is it can't be applied to the WMF as it is incorporated in the United States and is therefore not a "Covered Entity" within the meaning of Sec. 2 Cl. (4)(b) of the Act, but the Foundation's chapters in Russia/Venezuela/HKSAR have potential to be affected as being subject to the jurisdiction of a foreign adversary under subclause (ii). Satellizer el Bridget ^(Talk) 07:43, 4 April 2023 (UTC)
• Oppose - SOPA, and the other legislation that has been protested in the past, directly affected Wikipedia's ability to carry out its core mission. This law is not directly related to Wikipedia, this advocacy against government policy will put Wikipedia in direct conflict with the US government by choice, and nothing good will come of politicising Wikipedia unnecessarily. JeffUK 11:08, 4 April 2023 (UTC)

And you thought SOPA was "directly related" to Wikipedia, how? RESTRICT affects Wikipedia operations no more and no less than SOPA. Satellizer el Bridget ^(Talk) 11:27, 4 April 2023 (UTC)

SOPA would have made the WikiMedia Foundation liable for detecting and removing potentially infringing content identified on Wikipedia, potentially having a chilling effect on what would be allowed to be discussed or posted here. Also, the SOPA blackout was instigated and organised by a third party, Wikipedia joined a large number of other web companies in the blackout, that's different from us coming up with the idea ourselves. JeffUK 16:25, 4 April 2023 (UTC)

Alternative

As an alternative, perhaps we need a policy statement that says “WP should not engage in advocacy” (no matter what the cause, or how “worthy” we may think it is). Blueboar (talk) 18:08, 1 April 2023 (UTC)

I think that the only time WP should be involved is when there is a clear legal threat to WP's existence - RESTRICT does not do that directly, but the COPA/SOPA bills did. Masem (t) 18:30, 1 April 2023 (UTC)

I agree with this @Masem. This is where what Anomie's statement of how "[I'd] need to laser focus on how the law would be an existential threat to Wikipedia, written with the same care and sourcing [I] might bring to a featured article" would come into play. I was also thinking it would be helpful to get someone with an expertise in law to actually make this determination if in their opinion this RESTRICT Act is as bad as claims on the Internet are making it. That or a WP:RS legal opinion analyzing the effects on the Internet if this Act were to pass. Either of those two would be a basis for an RfC. Aasim - Herrscher of Wikis ❄️ 13:43, 2 April 2023 (UTC)

To be honest, I’m not sure we should be engaging in advocacy on WP - even when a proposed law might directly impact Wikipedia itself.

There are lots of on-line venues that are appropriate for advocacy by Wikipedians, but I don’t think WP itself is one of them. Blueboar (talk) 17:18, 2 April 2023 (UTC)

We got it Blueboar. Some of us simply don't fully share your opinion. Regards, Thinker78 (talk) 22:30, 2 April 2023 (UTC)

I know… and those of you who don’t are the most evil people on the planet. I would organize a day of blackout on WP to protest, but I don’t think WP is the correct venue for that. Blueboar (talk) 00:06, 3 April 2023 (UTC)

Lol. Hope you are joking. Thinker78 (talk) 06:11, 3 April 2023 (UTC)

Support. Advocacy is detrimental to the project, even more so than vandalism. Thebiguglyalien (talk) 02:58, 3 April 2023 (UTC)

• Oppose per WP:NOTBURO, etc. I also think that we shouldn't be enshrining such things in policy. While I personally oppose using Wikipedia as a vehicle of advocacy, I also oppose setting rules to stifle discussion. Who know, maybe I'll be convinced in the future to change my stance on this. I want to allow other the opportunity to convince me. I don't want rules that say "we don't talk about such things on Wikipedia". That's also bad. --Jayron32 11:55, 3 April 2023 (UTC)
• Why are people bold !voting against the guidance of this page? - instead, just discuss thoughts. I am almost the only person on en-wiki who has started a blackout RfC that did not either get the full majority (a single case) or an absolute hammering/snow close (the vast majority). In effect, the outcome of that was to show that even a significant possible threat (I realise all threats are inherently "possible") was viewed as insufficient by en-wiki (but not by some sister projects). It takes a particularly drastic state of affairs. That threshold means that an RfC along these lines would need to set out why such a thing is needed. Either we'd turn it down naturally, or some grave affairs are occurring. That catastrophic threat or issue might not be within the wording of the policy, so we might as well not bother creating a rule that inherently would only ever be actually of importance when it was overruled. Nosebagbear (talk) 12:17, 4 April 2023 (UTC)

  I didn't read that part of the guidance and will try to be better next time, but I think it shows the strength of feeling that this is not something we should do. JeffUK 08:57, 5 April 2023 (UTC)

• I do not think adding an explicit statement that Wikipedia shall not engage in advocacy is good for this project. As Masem states above, there are certain policies that, if enacted, are detrimental to this project and we should at least consider taking action. --Enos733 (talk) 16:39, 4 April 2023 (UTC)

  I agree, there are some things that are so egregrious or important whereby saying nothing is advocacy! JeffUK 13:11, 5 April 2023 (UTC)

  A terrible and dangerous potential law. But it appears that it doesn't directly affect Wikipedia and hypothetical application to Wikipedia looks pretty farfetched. IMO such advocacy is not our mission. Sincerely, North8000 (talk) 20:40, 5 April 2023 (UTC)

• I would support this, although I believe it is already covered by WP:SOAPBOX. BilledMammal (talk) 18:04, 6 April 2023 (UTC)

  If I am not mistaken, Wikipedia:SOAPBOX is meant to prevent editors from engaging in excessive self-promotion in articles, talk pages, project pages, etc. where such promotion is in of itself unencyclopedic. It does not apply to editors discussing whether or not the Wikipedia community should formally approve or disapprove of a piece of legislation (as was done with WP:SOPA back in 2012) or some other action by some other government or non-government entity. Also this forum is about workshopping ideas together, not for consensus polling. That is for when the idea gets formally proposed through one of Wikipedia's procedures. Granted, it has to be related or even tangentially related to the encyclopedia and/or its future for the issue to even be raised. One can also invoke WP:IAR but only if there are absolutely very good reasons to do so, not to engage in disruptive bad-faith edits. Aasim - Herrscher of Wikis ❄️ 20:38, 6 April 2023 (UTC)

  Wikipedia:What Wikipedia is not § Wikipedia is not a soapbox or means of promotion covers all forms of promotion, not just self-promotion. The first numbered point lists "advocacy, propaganda, or recruitment". It doesn't apply to this particular discussion, for example, but would apply to a change to mainspace, such as placing some kind of banner message. (The community can decide by consensus to take a certain action in spite of this guidance, of course.) Regarding the specific shortcut used: standing on a soapbox to give impromptu public speeches was historically related to propagating opinions, rather than direct self-promotion. isaacl (talk) 21:27, 6 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)

Census Population Bot

Having a bot which could quickly and accurately update population templates across Wikipedia would be beneficial. The bot would use the census data from each country to make its edits (the United States Census Bureau for US pages, for example). I remember there was a discussion a couple months ago involving the bot, CenPop, but the request expired after little interest. I think it's worth a shot to make a bot which can update population stats on municipal pages. This would minimize the work needed and pages missed by manually updating these stats. To add insult to injury, all this work would have to be done again when the data is inevitably superseded by the next counts. Thank you for your time, have a good day! DiscoA340 (talk) 18:12, 4 April 2023 (UTC)

It is probably easy to update the infobox by bot, but the body and any tables will likely require manual updates. —Kusma (talk) 18:44, 4 April 2023 (UTC)

It would likely have to be semi-automated, but I could imagine it working by searching for the old number and citation in the article, and replacing them with the new ones. Snowmanonahoe (talk) 18:47, 4 April 2023 (UTC)

Liberate notifications for article creators

If one expands a redirect, or creates an article from a redirect, I believe the one that created the redirect will be the beneficiary of the notifications. At least this was like this when I created articles from a redirect. Then also I do not create certain articles because I know I am not interested in the notifications and prefer some other editor with a greater interest in the subject and expanding the article creates it. The notifications are anyway at some point useless for the article creators, when they stop editing wikipedia. Couldn't we somehow develop a tool or button like the watchlist star, to subscribe and unsubscribe to notifications from an article? Paradise Chronicle (talk) 05:40, 5 April 2023 (UTC)

See Help:Notifications#Muting pages. It allows you to turn off notifications for pages you created.-gadfium 06:14, 5 April 2023 (UTC)

When you get a notification for a link to an article, it now gives you an option to mute link notifications for that article (on desktop site at least). Joseph2302 (talk) 13:52, 5 April 2023 (UTC)

Ok, thank you for the information about the muting. For information about a tool with which one can subscribe to those articles someone else has created, I'd still be grateful. Paradise Chronicle (talk) 17:10, 5 April 2023 (UTC)

@Paradise Chronicle, I think you're referring to notifications such as when an article is proposed for deletion/merge, nominated for deletion, tagged for speedy deleting? Notifications of prod/AfD/CSD don't happen automatically; the nominating editor notifies the article creator. (If the nominator uses Twinkle, the tool posts the notification on behalf of the nominator.) It would be a technical hurdle to create a class of editors "interested" in an article that could be recognized by a manual editor or Twinkle to notify in addition to the creator. I think your best recourse is to watchlist those articles. (If I've misunderstood your intent, I apologize.) Schazjmd (talk) 17:27, 5 April 2023 (UTC)

I was more referring to Wikilinks to and from the article so one gets aware of some potential expansion. But yes, of course such notifications would also be helpful for many editors. I actually get the notifications of two articles I initially created but then someone merged them and since I do not appear as their creator below the article title anymore (if one activates the xtool preferences) but still both are mentioned as their creator at the general xtools see here and here for 1967 Basel Picasso paintings purchase referendum. The other one is Baris Atay. So, I believe somehow it is possible to receive notifications of articles one has not created, I just don't know how it can be done. Paradise Chronicle (talk) 17:56, 5 April 2023 (UTC)

Yes, subscribing to these for pages you haven't created would be very useful. As others have said, you can already opt out for pages you have created. —Kusma (talk) 16:43, 5 April 2023 (UTC)

One-word talk page contributions

I'm seeing more of these than I used to, talk page edits where the heading and content are just one or two words each:

• Talk:Doppelgänger - Heading "Urdu", content "Enjoy"
• Talk:Plain - "Structural plain", "structural plain"
• Talk:The quick brown fox jumps over the lazy dog - "English", "English"

Some pages seem to attract these repeatedly. Is there some aspect of the talk page (re?)design that's making IP users think that they're typing in a search field? Or has this always been a thing?

I'm not sure what the solution is as I don't really know what's causing it.

When starting a new thread, the box to type a message in just says Description, which doesn't make it obvious what the box is for, or what the user is expected to type there. If that's the issue, would it help to change the message in the text box to something like Enter your comment here? Or maybe some kind of filter where a new thread consisting of just a single word in both heading and subject is rejected as almost certainly an erroneous or test edit? Belbury (talk) 16:08, 5 April 2023 (UTC)

Galobtter is already working on a filter; see WP:EFR#Talk page junk and WP:EFN#Setting 1245 to disallow?. The Description message is at MediaWiki:Discussiontools-replywidget-placeholder-newtopic. I agree that's not helpful; a description of what, exactly? I'm not sure what it should say, though? Remember the same message is shown on both article and user talk pages. On the old (now thankfully removed) mobile interface, we settled on "Make a suggestion or voice a concern." Suffusion of Yellow (talk) 23:33, 5 April 2023 (UTC)

I think the message probably should be updated to "Enter your comment here" which is a pretty good description of what the box is for (or something else as suggested). "Description" really isn't enough of a, uh, description. Galobtter (pingó mió) 23:41, 5 April 2023 (UTC)

My question also is why the tool allows adding new topic sections without a header.. Galobtter (pingó mió) 05:23, 6 April 2023 (UTC)

Or 2, 3 or 4 word edits. There are undoubtedly far more of these than in the past. I assume they are test edits, probably encouraged by some training stuff somewhere. I don't believe they (or most of them) are malformed searches. They are especially common on India-related articles, I find. Johnbod (talk) 14:17, 7 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)

New noticeboard for legal threats (WP:AN/LT)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Good day guys; every time I look at WP:ANI, I feel like that every other complaint or thread is on something which has to do with a legal threat. I think that discussion can be much more streamlined if editors who notice legal threats being posted are specifically redirected to a noticeboard dedicated to legal threats. Therefore, I would like to bounce around the creation of Wikipedia:Administrators' noticeboard/Legal threats (or WP:ANLT). With a new noticeboard dedicated solely to legal threats, a dedicated team of admins can find every reported ;legal threat in one place rather than having to sift through ANI discussions often longer than many articles. Additionally, discussions not affected by legal threats would benefit as there would be less potential for edit conflicts (though this problem is starting to become better handled with new WMF technical developments like better talk pages). InvadingInvader (userpage, talk) 20:58, 5 April 2023 (UTC)

@InvadingInvader I do not think such threats are super good for public discussion IMHO. I think admins have a mailing list and IRC channel? Aasim - Herrscher of Wikis ❄️ 23:42, 5 April 2023 (UTC)

I personally don't know, but scrolling through ANI sees plenty of legal threats. InvadingInvader (userpage, talk) 23:48, 5 April 2023 (UTC)

Most legal threats I see pop up at ANI are handled very quickly. I don't think splitting their handling off to another board with far fewer watchers would be as effective. ScottishFinnishRadish (talk) 00:10, 6 April 2023 (UTC)

I'm with SFR - I'm not aware of any particular issues with the status quo. In fact, it could be a nuisance for cases where we have a NLT and other issues overlapping. This is more relevant because a purely legal threat block is usually undone when retracted and awareness shown, while a mixed case may not. Nosebagbear (talk) 12:38, 6 April 2023 (UTC)

Legal threats rarely come in isolation, and moving them elsewhere would likely result in less scrutiny of the underlying issues. A bad fix for a non-existent problem. AndyTheGrump (talk) 13:10, 6 April 2023 (UTC)

• Meh ANI is not overwhelmed with NLT discussions. Someone posts an NLT violation, the person in question gets blocked rather quickly, and we move on. It's working under the current system just fine. --Jayron32 18:01, 6 April 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Embedding a Wikidata-Infobox within Wikipedia articles

Hi, the current method of Wikipedia for representing structured data of an article is by redirecting to its Wikidata item and doing a URL redirection from an HTML page to another HTML page. But this method is not consistent with Web 3.0. According to the article Semantic Web:

Specifications such as eRDF and RDFa allow arbitrary RDF data to be embedded in HTML pages.

So these structured data (from Wikidata) should be treated as metadata and should be embedded within HTML page of each article.

Hence, I have an idea for placing a template named "Template:EmbedWikidataInfobox" in all existing Wikipedia articles, that is by default hidden, but users can show that by clicking a button. This way all related structured data is embedded within that article as some metadata.

I should note that this new extracted and embedded "Wikidata Infobox" should have three columns to be consistent with the semantic triple format: one column for subject, one column for predicate, and one column for object. And in each row a structured data item should be placed.

This Wikidata-Infobox has benefits for both machines and for humans. For machines is discussed, but for humans a user can "rapidly" see what structured data "is not inserted" or "is not correct" and somehow refer to Wikidata to correct that data or add new not existing item.

Finally, I should note that services like ChatGPT and many other newly created bots certainly benefit from this embedded Wikidata Infobox to extract structured data more accurately, and to respond users more precisely. Thanks, Hooman Mallahzadeh (talk) 05:45, 10 April 2023 (UTC)

@Hooman Mallahzadeh, I think you need to spend a while reading https://www.rfc-editor.org/rfc/rfc2119.html. You have made a big jump from "allow" to "should". Just because specifications "allow" (permit, may optionally do something) doesn't mean that you "should" do them. A sales team might tell you that they will "allow" you to give them a large sum of money, but that doesn't mean that you should or must do so. WhatamIdoing (talk) 04:26, 11 April 2023 (UTC)

@WhatamIdoing Hi, implementing the Web 3.0 is like placing airbag in cars. Without an airbag, a car works perfectly without any problem, but in a special situation (an accident) this airbag is very vital and important. Here, without this metadata, Wikipedia articles work perfectly and users benefit from Wikipedia without any problem. But in the special situation that users would ask questions from a bot, Wikipedia does not work properly. So I really believe that for implementing something that is somehow ««standard»» we can use the word "should". Hooman Mallahzadeh (talk) 05:02, 11 April 2023 (UTC)

The actual standard says that this is permissible ("may"). It does not say that is recommended ("should").

Consider the difference between "You may drive a white car" and "You should drive a white car". You have gone from "The standard allows you to make a choice about whether to do this" all the way to "The standard recommends that you do this".

It's perfectly fine if you want to recommend that we do this, but it is incorrect to claim that the standard recommends it. The standard permits it. The standard says that you may do this. It does not recommend it or say that everyone should do this. WhatamIdoing (talk) 15:58, 13 April 2023 (UTC)

Parallel guideline to WP:PLOTSOURCE, but for non-fiction texts

Articles on non-fiction texts, for example on philosophical works, generally cite their summaries of the texts' contents directly to the original text, rather than using secondary sources.

For fiction texts, there is a clear guideline, WP:PLOTSOURCE, that clarifies the acceptability of this custom. It seems as if there should be a parallel guideline for non-fiction texts. I am not advocating for what this should say, only suggesting that this gap be addressed.

Is there any interest in working on this? Butterfly or Chuang Tzu? (talk) 16:17, 11 April 2023 (UTC)

Is there a problem to be solved here? Have you encountered any problems because of the perceived lack of this parallel guideline? I had no big issues getting the non-fiction A Voyage Round the World through FA despite (or perhaps because of) an extremely long "Content" section sourced only to the book... —Kusma (talk) 16:58, 11 April 2023 (UTC)

I've definitely encountered issues with this, and I've thought about making a post like this myself. Current guidelines are really unclear about best practices for non-fiction works. Even just a few sentences in a guideline somewhere would help. Thebiguglyalien (talk) 17:16, 11 April 2023 (UTC)

I've written several articles about nonfiction books. I just took the "spirit" of WP:PLOTSOURCE as a basis for the books' summaries. Schazjmd (talk) 17:24, 11 April 2023 (UTC)

I'm not a fan of the idea. Fiction plots are generally pretty straightforward. Other than attributed quotes, what is said in a work of nonfiction needs discussion. If it isn't discussed in RS, maybe it's not worth including in the article. If it is, let's summarize what those RS are saying. Valereee (talk) 19:13, 11 April 2023 (UTC)

Plot summaries of works of non fiction should be limited in the same manner as works of fiction, but I also think that fictional and non fictional narratives that have received extensive, nearly scene by scene coverage, can go long in the tooth as long as that additional analysis is included, and the longer plot section helps to guide our reader through the analysis. Eg, the plot of any Shakespeare play or Kubrick film could be longer die to the extensive coverage of each work. Same would apply to Around the zworld... above. Masem (t) 20:38, 11 April 2023 (UTC)

Can you provide some examples? I would be surprised if primary-sourced summaries of philosophical works did not veer into OR. BilledMammal (talk) 01:58, 12 April 2023 (UTC)

• There are many different kinds of non-fiction works, though. A narrative biography of a famous figure is vastly different from a scientific thesis, or an examination of art history, or a math book. Independent sources existing to demonstrate the notability of something like The Making of the English Landscape, it is fine to cite the work itself for a summary of its contents. BD2412 T 03:00, 12 April 2023 (UTC)
• One tricky area… figuring out how to appropriately summarize and cite a notable non-fiction work that advocates for a WP:FRINGE theory or topic. It can be done, but it takes skill. Blueboar (talk) 13:17, 12 April 2023 (UTC)

  Or even just a personal interpretation. I recently had a discussion at Talk:No, Ma'am, That's Not History about a summary of a nonfiction book. The summary had stated He presented many counter-arguments to Brodie's arguments, using logic to show inconsistency or casting doubt on her sources. He also criticized her psycho-historical method, stating that historians can't know what hidden emotions Joseph or Emma Smith felt unless they have a source that says so. I felt that this was the article creator's take on the nonfiction book's arguments and that we needed to find someone else saying these things. Valereee (talk) 13:30, 12 April 2023 (UTC)

  it should be readily possible to summarize a non fiction work on a FRINGE position without giving any impression the fringe position is "right". As a poor example 2000 Mules doesn't give the work any time to brief speak for itself, which given the amount of criticism for the work, should only be about 3 to 4 sentences. The details if the presentation which are wrong/disproven/fringe can be discussed with sourcing as appropriate in a criticism section (though with what I am seeing at 2000 mules, there are a number of synth/OR insertions, which can't be included). But the amount of valid criticism that film got would post most of the details next to the reality counterpoints. Masem (t) 16:03, 12 April 2023 (UTC)

• Just came across this project page, it's a bit of a start. Schazjmd (talk) 18:15, 12 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)

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)

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

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)

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)

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)

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)