Wikipedia:Village pump (idea lab)

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, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57

Wikipedia Truth-O-Meter

I think people have suggested this before but maybe we have a personality-test style rating scale on each article (1-5) to see how true an article is. It would go False, Slightly True, Half True, Mostly True, True. The result is displayed as a bar graph. I know there's problems with this (bots, spam, people might vote straight away, e.c.t) but with enough polishing out we might have a good system. Maybe we could have a citation system like this too (same scale but majority is displayed) to show which ones are good and which ones might need to be replaced. 99.226.2.176 (talk) 12:57, 2 November 2023 (UTC)[reply]

How do you define what is true and who would how "true" the article is? The essays at WP:TRUTH and WP:IKNOWITSTRUE might be applicable. RudolfRed (talk) 14:49, 2 November 2023 (UTC)[reply]

This would be way too easy to abuse. QuicoleJR (talk) 17:03, 2 November 2023 (UTC)[reply]

So now we also have to define truth? Way too much to ask of volunteers. Edward-Woodrow • talk 20:08, 4 November 2023 (UTC)[reply]

We work on the basis of making all articles as true as we can. This sounds like a more agressive version of a POV tag, or some sort of social media "I like this" thing. Our problems are I think mostly about particular statements or sections rather than whole articles. I don't see this working. Johnbod (talk) 02:47, 8 November 2023 (UTC)[reply]

Wikipedia articles are supposed to be verifiable from reliable sources; absolute truth is not a philosophical criterion. (Defining reliable sources gets murky though.) To your point though, the most common inaccuracy I see in articles is failed verification of cited material -- for at least half of the cited material in half of articles based on recent random spot checks I've done. (As for uncited material, you shouldn't be trusting it anyway, but we have a banner template for those articles.)

Rather than have users gauge truth of an article based on what from your proposal sounds like their personal feelings (which would be a fun exercise for any remotely political issue), a simpler tool that's already implemented in bits and pieces if you install the extensions on your account (so in other words completely useless to the general public) is to have a citation-reference template that can be scoped to specific paragraphs/sentences/fragments in the text. Then the user can see text flagged by various highlighting: new edits with unreferenced content; changes to scoped material without accompanying changes to the citation text (flagged for oversight), or else moving of citation text or the like; and so on. No rating scale needed. SamuelRiv (talk) 19:41, 14 November 2023 (UTC)[reply]

See also Wikipedia:Article Feedback Tool. WhatamIdoing (talk) 04:01, 18 November 2023 (UTC)[reply]

Interactive collages/galleries for articles

Hello. I don't know if this is possible but I propose a way to make galleries more interactive (i.e. infobox collages and/or static gallery sections on articles become more like image slideshows). These slideshows could be linked to Commons categories relating to each topic; Commons galleries, which have a more refined selection of images; and/or manually queue images by adding them into the template. If manually inputted, each image caption could be edited as well. For the linked categories, it could either use the image captions on Wikimedia Commons or one umbrella caption for the template. To sum it up, collages and/or gallery sections on pages could be combined into one interactive thumbnail box which is animated (moves automatically) with the ability to become semi-static for mobile users (move between images with arrows). I have noticed many conflicts in the past about the size of infobox collages and whether gallery sections are notable enough to be included on pages. So this might be a compromise because the size of collages/galleries are limited to standard thumbnails but still include multiple images. Thank you for your time and have a great day! -- DiscoA340 (talk) 14:16, 4 November 2023 (UTC)[reply]

@DiscoA340, there's already a slideshow mode. See mw:Talk pages project/Usability#Design for an example. WhatamIdoing (talk) 04:15, 18 November 2023 (UTC)[reply]

@WhatamIdoing: Many thanks, have a great day! -- DiscoA340 (talk) 16:09, 18 November 2023 (UTC)[reply]

I would really appreciate it if we could put the village pump back.

Many moons ago in this village, there was a wonderful picture of a village pump where anyone could go get some fresh sweet Wikipedia water. I miss that pump so much. Look Wikipedians, I know its the future now, its 2023 and all, but what the heck is a village pump page without the village pump? Please all of you fine citizens of this magnificent community, please bring back the famed village pump. JaydenBDarby (talk) 18:59, 6 November 2023 (UTC)[reply]

Boldly

Done... I'll see how long it takes for it to be reverted for some reason. Edward-Woodrow (talk) 22:08, 7 November 2023 (UTC)[reply]

We are going to PUMP YOU UP! RoySmith (talk) 22:23, 7 November 2023 (UTC)[reply]

Thank you very much, Edward-Woodrow! I appreciate it! That fresh, cold Wikipedia water is so good! JaydenBDarby (talk) 01:49, 8 November 2023 (UTC)[reply]

Someone downsized our village pump and moved it down the page. The water is going sour, lol. JaydenBDarby (talk) 03:29, 8 November 2023 (UTC)[reply]

It can only be speculated that, like the modern office water cooler, the village pump must have been a gathering place where dwellers discussed ideas for the improvement of their locale.

That would be this one →, removed without discussion here. I'll admit I kind of miss it too. —Cryptic 23:28, 6 November 2023 (UTC)[reply]

(ec) - I agree.

I was thinking that Wikipedia:Village pump should also have an accompanying piece of prose explaining how the town well/village pump was the common gathering place in society.

So I did some quick looking around, and we don't seem to have much on the subject. Noting that Village pump redirects to Well.

And Well#Society_and_culture doesn't say much at all.

I did some google searching, and I'm seriously wondering if an article could be started on this topic... - jc37 23:53, 6 November 2023 (UTC)[reply]

Hand pump is a bit better. —Cryptic 00:00, 7 November 2023 (UTC)[reply]

About pumps, but not much on the cultural part. I looked at Watering hole, and it has even less. - jc37 00:33, 7 November 2023 (UTC)[reply]

I second that, jc37. Let's start an article on that. Make it top shelf, like the Cleopatra article. JaydenBDarby (talk) 03:47, 7 November 2023 (UTC)[reply]

I'm game : )

Maybe we should see if we can better expand Well#Society_and_culture. If we can, then we can always split to a separate article. - jc37 15:26, 7 November 2023 (UTC)[reply]

Not much more explanation in the sandbox that edit says it's copying from, either. Anomie ⚔ 23:43, 6 November 2023 (UTC)[reply]

Incidentally both the sandbox editor and the live editor are now under editing restrictions preventing them from repeating the edit (the sandbox editor is banned outright and the live editor is topic-banned from template namespace. * Pppery * _{it has begun...} 00:42, 7 November 2023 (UTC)[reply]

Actually that edit was reverted (for reasons unrelated to the image removal). The later removal that stuck was here, calling the image "just simply useless". I'd be inclined to agree. * Pppery * _{it has begun...} 00:42, 7 November 2023 (UTC)[reply]

What that edit removed was this. (Non-admins: It irritatingly shuffled through File:Wikipump.jpg, File:Amstetten Württemberg Wasserhahn und Gasleuchte 2008 10 11.jpg, File:Beypazarı Hırkatepe Köy çeşmesi.jpg, File:Village pump in India.jpg, File:John Snow memorial and pub.jpg, File:Thatched water pump at Aylsham, Norfolk.jpg, File:Town pump Vingtaine de la Ville Jersey.jpg, File:Clonakilty County Cork - geograph.org.uk - 209126.jpg, File:Reczna pompa studzienna - rzeszow p.jpg, File:Old manual pump in Crespino, Italy.jpg, File:Dorpspomp te Diepenveen -03.jpg, File:Doel - Water pump 1.jpg, File:Brunnen Rinnen 1569.jpg, and File:Balga, February 2010, Women around the water pump - conversation.jpg.) I'd've been tempted to get rid of it, too; only a couple of the alternates had the gravitas, and none the nostalgia value, of good ol' Wikipump. —Cryptic 01:06, 7 November 2023 (UTC)[reply]

I like idea of rotating images of pumps around the world. Drives home the universality of it. Levivich (talk) 01:52, 7 November 2023 (UTC)[reply]

Thanks for the explanation Cryptic. My instinct is to disagree with Levivich; I feel universality is helped by having one common pump. That said, either that or the rotating seems relatively harmless. CMD (talk) 04:21, 7 November 2023 (UTC)[reply]

My instinct is to disagree with Levivich - it's a common human instinct. Levivich (talk) 05:33, 7 November 2023 (UTC)[reply]

Not mine, though. I like the rotation. Jo-Jo Eumerus (talk) 09:33, 7 November 2023 (UTC)[reply]

Thirded. And since it was removed without discussion, see little reason not to just put it back. If someone wants to go through the horrible mess the markup has become... Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 23:42, 6 November 2023 (UTC)[reply]

Put the pump back. RoySmith (talk) 14:56, 7 November 2023 (UTC)[reply]

I agree! undump the pump!! Sm8900 (talk) 22:39, 7 November 2023 (UTC)[reply]

That was terrible. I'll add it back in a proper way later, but in general... please stop using tables for designing pages. —TheDJ (talk • contribs) 10:59, 10 November 2023 (UTC)[reply]

It's still incredibly ugly and totally messes with the readability, but at least it's not an accessibility problem this way. —TheDJ (talk • contribs) 21:57, 10 November 2023 (UTC)[reply]

I removed it. Mach61 (talk) 19:21, 13 November 2023 (UTC)[reply]

I put it back :-) RoySmith (talk) 19:39, 13 November 2023 (UTC)[reply]

PS, I get that this isn't the most visually pleasing image. I think we would do well to replace it with one which is both a nicer image and which also emphasizes the historical role of the village pump as a gathering place for communication and discourse. I've been looking through commons:Category:Village pumps but haven't found any good candidates yet. Anybody see any good ones we could use? RoySmith (talk) 15:32, 14 November 2023 (UTC)[reply]

Yeah, I heartily agree with you RoySmith but I was not about to complain as the image WAS placed there for me after I asked for the village pump to please be reinstated. JaydenBDarby (talk) 20:54, 22 November 2023 (UTC)[reply]

How about the Clonakilty County Cork village pump? JaydenBDarby (talk) 21:00, 22 November 2023 (UTC)[reply]

Stamping out Scams

The series of recent scam reports show that Wikipedia scams are alive and ongoing. There was a small discussion at Wikipedia talk:WikiProject Articles for creation § Where should we place the scam warning? that suggested that this issue requires a larger solution than just a disclaimer on the WP:Article Wizard. So I am posting here to raise awareness and bring out ideas.

Recent examples: [1], [2], [3] Ca ^{talk to me!} 11:09, 8 November 2023 (UTC)[reply]

Why not run banners like the fundraising-drive pleas from Jimbo for a week or two? Garish, sure, but I bet they'd raise the profile of the issue. XOR'easter (talk) 04:35, 14 November 2023 (UTC)[reply]

Or continuously, but at a low level. Say, 1% of page views? Or even 0.1%? It could say something like "Business owners: Wikipedia is 100% volunteer and never charges for articles. Don't get fooled by the scammers" and link to the scam warning (or to the WP:BFAQ).

A less-intrusive form would be to put a small note at the end of the Main Page. WhatamIdoing (talk) 04:35, 18 November 2023 (UTC)[reply]

Develop an RfC to reduce the advocacy from the Find sources module

We have a major problem with WP:ADVOCACY in Module:Find sources/templates/Find sources and, in particular, the associated Template:Find general sources. This is an elephant in the Wikipedia room and a major embarrassment that nobody got around to fixing so far. Work is needed at User:Boud/sandbox/draft RfC Reduce advocacy in Find sources Module to develop the RfC, with an associated talk page. The arguments given against my initial proposal of the RfC were meta-level arguments and the arguments that proposing to reduce advocacy is itself advocacy and that describing the sky as being blue is not neutral. In any case, the aim is to avoid wikilawyering and generously edit the draft and discuss any edits that need discussion. Boud (talk) 22:49, 11 November 2023 (UTC)[reply]

Any objections to the ~~current draft RfC~~ 22:26, 15 November 2023 draft RfC at User:Boud/sandbox/draft RfC Reduce advocacy in Find sources Module? Boud (talk) 20:57, 15 November 2023 (UTC) (update) Boud (talk) 23:07, 15 November 2023 (UTC)[reply]

Deprecating Wikipedia:Changing username

SUL has been a thing for almost a decade. Is there a reason why we have our own rename page? Renaming is truly a global function; Special:GlobalRenameRequest is easier if you have an email address, and m:SRUC works if you don't. From my POV, it is just a redundant layer of bureaucracy.

On the other hand, Wikipedia:Changing username/Usurpations is at the very least different from m:Steward requests/Username changes#Requests involving merges, usurps or other complications (one week versus one-month waiting period), but is there a reason we need to have two separate venues? It probably would be easier for stewards to reduce the waiting period at meta if it would have qualified for a usurp here (if there is a reason to keep the shorter waiting period). House Blaster^talk 02:55, 13 November 2023 (UTC)[reply]

May be because for local users it is much easier to go to a local page than to some project completely alien to them? Ruslik_Zero 20:30, 13 November 2023 (UTC)[reply]

Probably? In any case, Special:GlobalRenameRequest can be done locally. I would guess (though you would know better than I do) the set of users who (a) do not have an email attached to their account, (b) want to change their username, and (c) do not wish to even edit metawiki is fairly small (or, at least, not large enough to outweigh the added CREEP). House Blaster^talk 23:13, 13 November 2023 (UTC)[reply]

Or perhaps they're blocked at Meta-Wiki. WhatamIdoing (talk) 04:45, 18 November 2023 (UTC)[reply]

Yes, the main purpose of the page is to serve users without an email attached. I'm indifferent to removal or keeping it, FWIW. — Frostly (talk) 03:35, 22 November 2023 (UTC)[reply]

If you're serious about deprecating it, WP:BN is the place. But last I heard there were still occasionally situations that called for a local rename. Andre🚐 06:02, 25 November 2023 (UTC)[reply]

Original Research Noticeboard is a gray hole

It appears that the Original Research Noticeboard doesn't have a community of volunteers, and that no one responds to concerns and complaints at it. I became aware of this problem when I referred a dispute from DRN to NORN to it about three weeks ago. See Wikipedia:No_original_research/Noticeboard#Hickory_Wind. After not seeing responses, I invited the editors to discuss at NORN, and they discussed, and did not get any third-party input. I had to start an RFC to address their question. Content noticeboards should exist so as to resolve disputes, or at least to provide some input. I hadn't previously sent a content dispute to NORN, and so I assumed naively that, like RSN and NPOVN, it might sometimes provide third-party input. I then mentioned this at WP:AN, although I knew that wasn't the place to do anything about the problem, and it was discussed: Wikipedia:Administrators'_noticeboard/Archive355#Original_Research_Noticeboard. The suggestions there were that maybe we should combine it with the Neutral Point of View Noticeboard, which does have activity. I think that we have semi-agreement that something needs to be done, but that what needs to be done needs to be discussed and semi-agreed on. The simplest, but maybe not best, idea is to ask the submitters to go either to NPOVN for biased articles, or to the Fringe Theory Noticeboard for crackpottery, and we do have biased articles, and crackpottery, and we need to deal with them. So what should we do about synthesis amounting to original research that isn't obviously wrong, just not sourced? Robert McClenon (talk) 23:00, 13 November 2023 (UTC)[reply]

We should roll the low traffic content noticeboards into WP:NPORINGEN. NPOV, fringe, OR, and SYNTH are all intertwined and would benefit from a deeper pool of watchers. This is also why niche boards for closure reviews and admin action review aren't great. Few watchers, little traffic, little input. ScottishFinnishRadish (talk) 23:15, 13 November 2023 (UTC)[reply]

Someone mentioned at WP:AN that there once was a Content Noticeboard, which is hibernating, marked historical, and was implying that we could wake it up and merge the content noticeboards, except for BLPN, into it. There was a mention of the Reliable Source Noticeboard. I don't consider it to be a content noticeboard, because sources are where the content comes from. So the idea was to migrate NPOVN, FTN, and NORN into CNB. That seems like a reasonable first cut in my opinion. Robert McClenon (talk) 23:42, 13 November 2023 (UTC)[reply]

Some stats for this past year:

WP:NORN: edits: ~1100; pageviews / day: ~95
WP:FTN: edits: ~4300; pageviews / day: ~230
WP:NPOVN: edits: ~3750; pageviews / day: ~183
WP:VPI: edits: ~5150; pageviews / day: ~257
WP:AN: xtools times out

Folly Mox (talk) 02:07, 14 November 2023 (UTC)[reply]

BLPN ~11000 views in the past 30 days, RSN ~22700 views. ScottishFinnishRadish (talk) 02:14, 14 November 2023 (UTC)[reply]

WP:AN 14920 edits in the last 365 days with 1321 views/day; WP:ANI 51698 edits and 3295 views/day. —Cryptic 06:23, 14 November 2023 (UTC)[reply]

Low traffic isn't inherently a problem. If an issue only comes up occasionally, then it only needs to be discussed occasionally. We only have one or two RfBs a year and nobody is talking about shutting down. The problem comes if, when an issue does come up, not enough people are there to provide third opinions, because then the noticeboard isn't fulfilling its purpose. But you can't judge that from traffic stats. – Joe (talk) 10:22, 14 November 2023 (UTC)[reply]

RfB is a very weird example in this context: Wikipedia:Requests for bureaucratship has redirected to Wikipedia:Requests for adminship since it was created in 2004. If it were a separate page today, it's very likely people would advocate merging the two because there are so few requests and having two separate pages just splits the attention each gets.

In the case of WP:NORN, this thread was begun because at least one person did experience a problem with not getting attention to a query there. Low traffic might not inherently be a problem, but if someone is reporting a problem for which low traffic is a likely cause, data on the page traffic seems like fairly useful information to bring to the discussion! Caeciliusinhorto-public (talk) 14:36, 14 November 2023 (UTC)[reply]

Lack of function (ORN) and low traffic (the other boards being dragged in) are two separate issues and not necessarily linked, is what I'm saying. – Joe (talk) 08:26, 15 November 2023 (UTC)[reply]

Wikipedia:External links/Noticeboard is my favorite noticeboard. It is low traffic, usually friendly, and editors can realistically expect to get a sound response within a day. WhatamIdoing (talk) 05:00, 18 November 2023 (UTC)[reply]

Thank you for the stats, User:Folly Mox and User:Cryptic. WP:NORN has the fewest edits of any of those noticeboards. More importantly, as User:Caeciliusinhorto-public says, I posted to NORN and did not get an answer. I then saw that most of the other threads were not answered. The traffic stats do not distinguish between questions and answers. I am not aware of a way to distinguish between questions and answers other than human examination of the threads. At this time, on 14 November, I see that there are 13 threads, including mine, and that 5 of them have not been answered, including mine. There is one thread that the Original Poster has "bumped" three times due to lack of response. I am not sure, but would guess that the underlying problem is that NORN does not have a community of regular editors who answer questions. I know that RSN does have its own community, and that it appears that most of the other boards do. As User:Joe Roe says, low traffic isn't inherently a problem, but too few editors who answer questions (as opposed to asking questions) is the problem. We don't have as easy a way to measure that, but there is a problem. WP:NORN is where questions about original research go to be ignored. Robert McClenon (talk) 17:38, 14 November 2023 (UTC)[reply]

I'm not sure a centralised notice board will actually help. OR and NPOV issues tend to be much more complicated than giving opinions on reliable sources, and about much lower interest articles than seen on BLPN. Easily sorted NPOV and OR issues tend to end up at ANI before one of the notice boards. So the issues that end up at the board are messy, complex, and require effort and time to start to be able to offer any advice. Centralising the boards may just see the OR and NPOV threads going unanswered there instead, how to encourage editors to take part is going to be the issue. -- LCU ActivelyDisinterested «@» °∆t° 18:46, 14 November 2023 (UTC)[reply]

OR questions might be better addressed at Wikipedia talk:WikiProject Example & friends, since OR sometimes requires a degree of topic area knowledge. A combination board seems like it would be better than the current situation though. Does anyone in favour of combining the boards want to notify WT:FTN and WT:NPOVN to see if the folks there have any input on that idea? Folly Mox (talk) 21:40, 14 November 2023 (UTC)[reply]

I've dropped notices on FTN, NPOVN, and NOR. -- LCU ActivelyDisinterested «@» °∆t° 22:01, 14 November 2023 (UTC)[reply]

I think I said this before, but part of the issue is simply posting a link to where discussion has happened, rather than seeking a fresh discussion on NORN. I am far less likely to help resolve an issue if I have to go to a different talk page and participate there, rather than be given a brief summary and starting the discussion fresh in front of a larger audience. And a lot of NORN posts tend to be pointers than fresh discussions. Masem (t) 21:58, 14 November 2023 (UTC)[reply]

Noticeboards can be expected to serve that main purpose though, to bring attention to current events under their scope, rather than being discussion forums (although related discussions can certainly take place and in the case of places like RSN, community polls, etc.) I can understand that if it doesn't receive enough attention, a poster may feel that their notices are fruitless. This last part of my post is not necessarily in response to you and is likely already obvious, but just a reminder that I wanted to keep in the same comment: a main difference between canvassing and a board notice is that canvassing attempts to gather the attention of select editors, when the noticeboard is for a more general public notice in relation to general WP policy (like if the issue involves original research or synthesis, in this particular case). —Paleo Neonate – 01:37, 15 November 2023 (UTC)[reply]

Yes, I'm not talking about canvassing issues; using NORN to drop a link (of many) to an RFC at a central location that includes NOR aspects is absolutely fair. I am speaking when, after a local talk page debate that ends up nowhere, that a single notice is posted to NORN to ask for input at that talk page. I'd rather see the summary and further discussion on NORN for when a local page issue required further input. Masem (t) 02:21, 15 November 2023 (UTC)[reply]

I'm not talking about canvassing issues I agree, it was a general side note. My impression of the general scope is the lack of popularity or participation at the particular noticeboard. However, it's still common practice to use them to bring attention to the main article's discussion. Because it's very recent, FTN's "Muscovy duck" could be used as an example: (warning: this is a permalink for the archives, anyone editing should update the page first) there was some on-noticeboard reaction, but the more serious discussion really happens at the article's talk page, where consensus is also likely to be evaluated in the future for the outcome). Local consensus issues also exist, but noticeboards also help to mitigate that (if they manage to gather community attention, of course)... The summary or closure can sometimes be posted at the noticeboard and it may be good practice where possible, but I don't see that often except at administrator noticeboards or RFCs. It may be worth encouraging, perhaps? —Paleo Neonate – 07:06, 19 November 2023 (UTC)[reply]

Original research means claims that are lacking reliable sources. It is essentially a reliable sourcing problem. RSN would be the best place to discuss original research. Sennalen (talk) 05:05, 15 November 2023 (UTC)[reply]

For clarity, OR means claims that have never been published in any reliable source, including uncited sources. WhatamIdoing (talk) 04:59, 18 November 2023 (UTC)[reply]

Wikipedia:No original research is structurally just sort of an explanatory essay and expansion on some aspects of Wikipedia:Verifiability. A WP:Nor violation is just a WP:Ver violation. WP:Ver permeates nearly every aspect of Wikipedia, is written to be slam-dunk for many situations and any "gray area" discussions inevitably involve or revolve around something more specific like WP:RSN, behavior issues, process issues etc. etc.. For these reasons, just as with WP:Ver, I don't see a noticeboard being useful/viable. Sincerely, North8000 (talk) 22:10, 14 November 2023 (UTC)[reply]

That's not really a view that we take, as NOR is a core content policy. Further, SYNTH is not something covered under WP:V. Masem (t) 02:10, 15 November 2023 (UTC)[reply]

SYNTH is covered under WP:V, because SYNTHd content is not actually verifiable. We just explain it in detail over at the NOR page.

Years ago, there was a more significant distinction, namely:

Original research is when the thing you wrote is something you personally made up and wasn't published anywhere, not even on USENET, and
Unverifiable is when the thing you wrote might have been published somewhere, but there aren't any reliable sources for it.

Now, OR is defined as no reliable source has ever been published anywhere in the world, in any language, about this, and unverifiable is defined as no currently accessible extant reliable source anywhere in the world (including sources not yet cited in the article) says this. They are basically synonyms. We've just split the explanation up across two pages. WhatamIdoing (talk) 04:52, 18 November 2023 (UTC)[reply]

A merger has been rejected before Mach61 (talk) 05:39, 15 November 2023 (UTC)[reply]

As User:Masem points out, there are at least two different types of original research issues. Regular original research is a verifiability issue, but synthesis amounting to original research is more complicated, because it normally involves at least two reliable sources, from which an editor draws a conclusion that is not directly in either of the sources. Synthesis is not a matter of the reliability of the sources. Robert McClenon (talk) 04:46, 16 November 2023 (UTC)[reply]

There are also WP:STICKTOSOURCE issues, where interpretation of just one source may involve some aspect of OR, and potentially hit a grey area between re-interpretation and the rewriting we are meant to do. CMD (talk) 05:46, 16 November 2023 (UTC)[reply]

I agree with Robert that "Synthesis is not a matter of the reliability of the sources"; it is a matter of straight-up verifiability. Content that is not in any source (e.g., a conclusion drawn by an editor that is not directly in either of the cited sources, nor in any others) is a case of {{failed verification}}. That we have a special name and detailed description for this particular method of content failing to be verifiable does not change the fact that the content is not verifiable.

Perhaps one misunderstanding is this idea that sources are "always" (or never) reliable. A source's reliability cannot be judged unless you know the content it is being cited in support of. I could imagine less-experienced editors thinking that WP:V is primarily about how to identify low-quality sources, but even the most excellent source, if it is cited in support of material it does not even mention, is a failure of verifiability. WhatamIdoing (talk) 04:57, 18 November 2023 (UTC)[reply]

My comment was more as structural background/context in order to reflect on the noticeboard issue, (including explaining it's non-use) not to get into some bigger issue between the two policies. I'll stand by my comment that A WP:Nor violation is just a WP:Ver violation because structurally WP:VER sourcing requirements inherently exclude synthesis as a means of compliance. Similarly for research etc. that is not covered is wp:ver-suitable sources. And wp:NOR has some good stuff in it which is unique to wp:Nor, I didn't say otherwise. I called it "just sort of an explanatory essay and expansion on some aspects of Wikipedia:Verifiability" in my comment which started this subthread but within that (admittedly arguable) characterization there is a lot of good and important stuff that is not in WP:VER. Sincerely, North8000 (talk) 16:42, 16 November 2023 (UTC)[reply]

A couple of years ago I wrote a program that monitored the activity of all the noticeboards, but I don't remember where I stored it all. I will take a look and see if I can get any actual numbers. There are a few inactive/dead noticeboards I've noticed, though. Wikipedia:Current events noticeboard is one of them. jp×g 🗯️ 00:04, 20 November 2023 (UTC)[reply]
User talk:JPxG I would be interested in those stats. A board could however be active, but purposeless if there is no response or one with a glacial time scale. Wakelamp d[@-@]b (talk) 07:01, 22 November 2023 (UTC)[reply]

I'm looking at it and it has 50 pages of archives and 11 active topics in the last 2 days so, not a lack of activity or want for lack of activity, and I don't think merging or combining noticeboards (or policies) is the answer. Some more organization like a task force or wikiproject is a good idea, but someone has to lead it and someone has to participate. Could it be maybe that the world and people's lives are a little nutty right now across the board, causing backlogs to rise? A backlog drive is an idea that people sometimes participate in, but not if there's no energy or appetite. One option is something like the "RFC solicit bots" but for a random un-addressed noticeboard posting. Andre🚐 06:10, 25 November 2023 (UTC)[reply]

Proposal: Make RATER into a Gadget

Basically what it says on the tin, this is a proposal to make User:Evad37/rater, a tool intended to allow experienced users the ability add and/or modify the {{Wikiproject banner shell}} and related Wikiproject class and importance parameters on the talk page of a page.

Making this a gadget would allow for the following:

Better maintainence by interface-administrators and/or anyone with access to the wikimedia-gadgets Github org :)
Easier installation procedure especially for newer users

Ping @Evad37 as a maintainer of the rater script. Sohom (talk) 19:44, 22 November 2023 (UTC)[reply]

This would 1000% need buy in from Evad37 as really the only maintainer, and User:Evad37/rater/app.js would need to be adjusted to a more human-readable presentation. — xaosflux ^Talk 19:51, 22 November 2023 (UTC)[reply]

Agreed, I don't have any intention of pushing this through unless Evad37 agrees. Wrt to the human-readability issue, the source appears to be at github.com/evad37/rater with clear build steps :) Sohom (talk) 19:59, 22 November 2023 (UTC)[reply]

General bias in all articles about "2023 Israel–Hamas war"

Hello,

I want to express my analysis of the impression that the articles, their titles and their sources give me about this war between the state of Israel and the Palestinian resistance factions, since the operations carried out by the Palestinians on October 7, 2023.

Indeed, this war, which is the continuation and consequence of 75 years of colonization, dispossession and humiliation of the Palestinian people by Zionist groups, then by the state of Israel, via its army and its forces of Order and security, as well as by settlers in occupied areas, must be treated in a fair and balanced manner, taking into account the reality of both camps.

The versions of the belligerents can be considered non-neutral, since they seek to justify their action. Therefore, the media in countries at war cannot be considered neutral, especially if they support a war-torn government. However, as Western governments have decided to uncritically support the version of events delivered by Israel, and as the major Western media have decided to repeat these versions without doing too much fact checking (at least, this is the perception of many criticism of the media treatment of this conflict).

In fact, the reader's impression, when we see the caution of uncertainty when the abuses target the Gaza Strip, and attributed in part by some to Israel, compared to the certainty of the information in relation to the acts committed by Palestinian factions on October 7. In summary, by bringing together the different perceptions, we see that most of the articles and the different points of view discussed only relay the points of view from the Israeli side and their inherent narrative. However, this denies Israel's history of occupation of the Palestinian territories. Since several Western media relay the Israeli point of view, the use of these sources will make the texts biased. Let us not add another layer of unconditional support to the story of an oppressive state suspected of having committed several intentional crimes against innocent civilian populations. Let's not forget that Wikipedia is a source of information for the general public, but also a source of information for journalists. Likewise, the fact of writing these versions makes it possible to legitimize the reasoning of one camp or the other.

Thank you in advance, this was my perception of the current state of treatment of the conflict on the English Wikipedia.

--Anas1712 (talk) 02:11, 23 November 2023 (UTC)[reply]

Could you give some specific examples of bias and how you would suggest they could be improved? – Joe (talk) 05:40, 23 November 2023 (UTC)[reply]

Editnotice on all mainspace talk pages?

I've noticed that sometimes IPs or new editors create mainspace talk pages that appear to be articles about the corresponding subject, which I usually tag with WP:G8. Presumably, these editors go through the process of: looking up subject and finding page does not exist -> try to create page but is blocked by software -> realises that they can create talk page -> creates article there.

I wonder if it would be worth the effort to create a namespace-wide edit notice for all mainspace talk pages suggesting the new editor to use the WP:AFC process instead. The message would be something along the lines of "If you are here because you want to create an article about [insert page title], please use the Wikipedia:Articles for creation process instead."

I do admit that I have doubts about whether this would be that useful, since firstly, there aren't many such cases (I would estimate less than a dozen per day), and secondly, people might not read it due to banner blindness. Any suggestions? Liu1126 (talk) 11:14, 23 November 2023 (UTC)[reply]

I am against creating a edit notice due to banner blindness, but maybe we can get ArticleCreationWorkflow (which is what WP:ACTRIAL uses) to do two things:

- Show MediaWiki:searchmenu-new-nocreate when searching for Talk pages (if the user meets ACTRIAL restrictions)

- Remove the Talk: header tab in the WP:LANDING display when creating a new page. Sohom (talk) 12:54, 23 November 2023 (UTC)[reply]

Note having a notice on every Talk namespace page would exacerbate banner blindness, such that the effectiveness of existing Talk page notices would get diminished. Thus absent more info on the frequency of the issue, I do not feel this scenario warrants an edit notice. isaacl (talk) 16:31, 23 November 2023 (UTC)[reply]

It is not uncommon for editors to create “draft” articles in their userspace so that they can work on them at leisure. I have several attached to my userspace. If someone creates one in the talk page of an article in Mainspace, I would simply move it to the creator’s userspace. Blueboar (talk) 18:14, 23 November 2023 (UTC)[reply]
Would preventing the creation of such talk pages not be a better solution (since for new editors, these will need to go through AFC anyway)? Note, I'm also not in favour of editnotices, but some kind of software hack (such as the one I proposed) would be useful. Sohom (talk) 18:17, 23 November 2023 (UTC)[reply]
I agree with User:Blueboar; userfying such creations is simple and elegant, and avoids adding to banner blindness. Donald Albury 21:06, 23 November 2023 (UTC)[reply]
Also, in the early years of WP, when an article needed a major rewrite, it was common for editors to set up a “draft” page in talk, so they could work on a new version of the article behind the scenes (in “talk” space) without disrupting what faced the “public” in Mainspace. When done, they simply copied and pasted their end product into Mainspace and moved the “draft” page to talk archives to maintain a record of who contributed what. In such cases there is no single “creator” to move the “draft” to… and it is best left in the article’s talkspace.

In short, you need to ask why the “draft” exists - who started it and who worked on it, and whether it was part of the article’s history and development. Blueboar (talk) 01:46, 24 November 2023 (UTC)[reply]

Reenabling some form of PC2 to assuage complaints about ARBECR?

Looking at RFC which prevented PC2 from being used, many of the oppose arguments have lost relevance over time, specifically lingering hostility towards PCR and complaints that ECP had only recently been enabled. In the meantime, ECP use has massively increased, and not without some pushback. Obviously this would be a long process, but a trial of PC2 may be in order Mach61 (talk) 05:39, 25 November 2023 (UTC)[reply]

Running low on administrators

Running ~~out of~~ low on administrators

Hey guys, I feel like this is an issue that is important to address. According to WP:Admin count, which other users and I have contributed to - since 2011, we have been having a net loss of administrators. There has been a long, gradual decline since then, with a sudden decrease in early 2023 due to new policies. I don't know how well this project can be managed with less admins around to do ever more tasks. I feel like something should change, but I do not know what should. What does the community say? Cheers, Wikiexplorationandhelping (talk) 20:48, 24 November 2023 (UTC)[reply]

I've considered running for administratorship, but I don't want to give up personal info. If the latter isn't required? Then I'd make a bid, only if nominated by another editor. GoodDay (talk) 20:54, 24 November 2023 (UTC)[reply]

It wasn't required when I ran. --Redrose64 🌹 (talk) 21:09, 24 November 2023 (UTC)[reply]

What personal information is required to be given? Personal image? I haven't been able to find anything in this regard. Wikiexplorationandhelping (talk) 22:10, 24 November 2023 (UTC)[reply]

I just may throw my hat into the ring. But, I'm aware that my chances of being elected (even though I've been on Wikipedia for 18 years), may be near impossible. GoodDay (talk) 22:13, 24 November 2023 (UTC)[reply]

You seem to be pretty experienced. I'd say you have a decent chance. Wikiexplorationandhelping (talk) 21:43, 25 November 2023 (UTC)[reply]

I've seen people who have edited less and became admins, just letting you know. Wikiexplorationandhelping (talk) 21:44, 25 November 2023 (UTC)[reply]

Well, it depends how you define "editing a lot" or "editing a little". 0xDeadbeef (talk · contribs) ^[no ping] passed RfA fine and they only have ~8K edits over two years. Edward-Woodrow (talk) 21:46, 25 November 2023 (UTC)[reply]

That's one example right there. If a user gets adminship and has less than 20k edits, I would consider that to be little. Wikiexplorationandhelping (talk) 21:55, 25 November 2023 (UTC)[reply]

This is endlessly discussed on WT:RFA, and there have been many proposals and previous RfCs to fix this - I don't see the point of this RfC. Galobtter (talk) 21:12, 24 November 2023 (UTC)[reply]

This isn't an RFC, just something that should have been posted on VPI Mach61 (talk) 02:53, 25 November 2023 (UTC)[reply]

~~not everything is an rfc~~ Edward-Woodrow (talk) 20:56, 25 November 2023 (UTC)[reply]

But this was an rfc — Alexis Jazz (talk or ping me) 21:02, 25 November 2023 (UTC)[reply]

Oop, my bad. Striking. Edward-Woodrow (talk) 21:08, 25 November 2023 (UTC)[reply]

Yeah, I wanted more people to come to a consensus on something that can be done to increase adminship. I felt like starting an RfC right from the get go was a better option for quicker consensus. Wikiexplorationandhelping (talk) 21:46, 25 November 2023 (UTC)[reply]

Note that inactivity requirements were very mildly tightened a year or two ago. Administrators who left due to this criteria weren't really admin'ing much or at all before anyway, so them losing the bit doesn't actually change much in those cases. SnowFire (talk) 03:24, 25 November 2023 (UTC)[reply]

I've been covering this subject in The Signpost a few times as recently as last month, and will be adding to it in the upcoming issue. Others took it up before me, probably most in-depth by Kudpung here. Yes, it is happening, and no, nobody knows really what to do about it. ☆ Bri (talk) 05:00, 25 November 2023 (UTC)[reply]

Moving to WP:VPI.
Wikiexplorationandhelping, with a sudden decrease in early 2023 due to new policies For those who aren't called Alexander, can you provide some links? — Alexis Jazz (talk or ping me) 05:48, 25 November 2023 (UTC)[reply]

That's when criterion 2 of WP:INACTIVE (originating rfc) went into effect. —Cryptic 06:07, 25 November 2023 (UTC)[reply]

Thanks. Admins who made <100 edits over a period of 5 years probably weren't having too much of an impact on any backlog anyway. Appointing a million administrators won't have any impact if they don't edit. — Alexis Jazz (talk or ping me) 06:16, 25 November 2023 (UTC)[reply]

Maybe this is so obvious that it's naïve for me to suggest it, but...would it be possible to have another tier below admin where many of the less-sensitive tasks can be afforded, but perhaps has less broad requirements? It sounds like kind of a huge paradigm shift, but since I feel the bar for adminship is about correct, I'm not sure what else can help. Remsense聊 06:16, 25 November 2023 (UTC)[reply]

We did that, and called them rollbackers. Then we did it again and called them template-editors, and again and called them pagemovers. (Maybe in the other order for the last two, I don't remember.) There's not really anything else to split out except the core admin abilities of deleting, blocking, and protecting, and they're too interconnected. See WP:Perennial proposals#Hierarchical structures and WP:Unbundling administrators' powers. —Cryptic 06:37, 25 November 2023 (UTC)[reply]

Aye, I knew I should've thought to think of specifics. Remsense聊 06:41, 25 November 2023 (UTC)[reply]

Remsense, fawiki has "eliminators". On Commons I suggested creating a "general maintainer" user group 4 years ago. ("huge paradigm shift" is my middle name 🤪) It didn't happen, partially because of technical limitations, partially because of concern it would cannibalize RfAs. — Alexis Jazz (talk or ping me) 06:38, 25 November 2023 (UTC)[reply]

Alexis Jazz, hum. At this point, the question of cannibalizing RfAs would seem to be moot, and perhaps even the reverse dynamic would be observed, because the intermediate "eliminator" role could be seen as a "stepping stone" to adminship that would make more people comfortable going through an RfA in the long run. Remsense聊 06:40, 25 November 2023 (UTC)[reply]

Remsense, let me quote myself from 2019: General maintainer can be a step towards adminship, but doesn't have to be.
But that was Commons and that was 2019, so who knows. Maybe enwiki in 2023 wants general maintainers/eliminators/lite admins. — Alexis Jazz (talk or ping me) 07:01, 25 November 2023 (UTC)[reply]

fawiki's eliminator has all the permissions that make people treat RFA like a big deal here. I'm not seeing anything their admin has that eliminator doesn't that anyone would care about, except for undelete and granting permissions (including eliminator!) as a kind of bureaucrat-lite. (And eliminator has deletedtext anyway, which is the part of undelete-broadly-construed that people object to handing out willy-nilly here.) That's not going to make it easier to become an admin here; it'll be just as hard to get eliminator as admin currently is, admin as hard as bureaucrat currently is, and bureaucrat as - I don't even know, we appoint checkusers and overseers and arbitrators more often than that. —Cryptic 11:24, 25 November 2023 (UTC)[reply]

For those interested, compare fa:Special:ListGroupRights#sysop with fa:Special:ListGroupRights#eliminator - there are 50 admin permissions that eliminators don't have; there is one (autoreviewrestore) that eliminators have but admins don't. Admins can also grant and remove certain permissions to others, eliminators are unable to do either. Their admins also have several rights that ours don't, mainly concerning abusefilters and flow. --Redrose64 🌹 (talk) 15:54, 26 November 2023 (UTC)[reply]

Also, does anyone know, on average, how many edits a user has made before getting adminship? It's quite a lot of information for me to dig, was wondering if anyone knows a quick answer. Wikiexplorationandhelping (talk) 21:57, 25 November 2023 (UTC)[reply]

Wikipedia:Request a query/Archive 3## of edits each admin had at the time of their RFA and #Candidate edit count at time of RFA. —Cryptic 23:24, 25 November 2023 (UTC)[reply]

Note: This was originally posted to the proposals village pump. Graham87 (talk) 08:12, 25 November 2023 (UTC)[reply]

Disallowing invalid signatures

(previous title was "Disallowing signatures with LINT errors")

We currently have a bunch of humans and bots fixing WP:LINT errors, and we do not let people create new signatures with LINT errors. However, signatures set before c. 2020 are not affected and are used in discussions, creating more errors for bots to clean up. Per this post at phab, the technical infrastructure is already in place to eliminate the grandfather clause, in which case invalid signatures would default to the "standard" signature. Therefore, I think we should set $wgSignatureValidation to disallow and $SignatureAllowedLintErrors to an empty array (which would implement the described changes). We would have to send out some mass messages to inform people of the change.

This would also "disable" signatures that have a link to none of: (ADDENDUM 19:31, 26 November 2023 (UTC): this category would comprise the majority of signatures affected)

Your user page
Your user talk page
Your contributions

(This bit is already part of WP:CUSTOMSIG/P, but it is not enforced via the software on old signatures)

Relevant links include:

The February RfC which resulted in consensus for bots perform LINT fixes en masse
The proposal/consultation (at MediaWiki) which led to signature validation
The list of LINT bots
The guideline about ... tags in signatures
The list of users with LINT errors in their signatures and who have contributed to a discussion in the last three months (ADDENDUM 19:31, 26 November 2023 (UTC): this report also tracks sig-too-long-post-subst errors; those signatures would not be affected by this proposal.)
The userscript that made getting these links so much easier. No more underscores in section links!

Thoughts? House Blaster^talk 02:53, 26 November 2023 (UTC)[reply]

Pinging @Matma Rex, @AntiCompositeNumber, and @Jonesey95. WhatamIdoing (talk) 05:45, 26 November 2023 (UTC)[reply]

Thanks for the ping. I don't really have anything to add to this discussion right now. I would be happy to answer questions about how exactly this works (I wrote the code some years ago), although it looks like the confusion in the discussion below has already been cleared up. Feel free to ping me again if you need any answers, though :) Matma Rex talk 16:35, 27 November 2023 (UTC)[reply]

This seems very desirable. I believe the proposal would result in non-compliant signatures being automatically replaced with username/talk/date as in my following signature. Johnuniq (talk) 05:58, 26 November 2023 (UTC)[reply]

Seems like a good idea to me. We would just need to mass message everyone who would be affected as mentioned so that people aren't confused. Galobtter (talk) 06:04, 26 November 2023 (UTC)[reply]

HouseBlaster, _{Thanks for the script link, I should add page title copying (already do whole wikilinks, but I can see how page titles are sometimes preferred) to my script as well.}
I suggest we leave a talk page message for all 226 users from your link with a templated message to suggest they fix their signature themselves and making the config changes a month later. Even if all 226 users fix their signature, there will be users with bad signatures who just haven't been active for a while.
There are actually a few names on the list I recognize. @Adam Cuerden, @Ahecht, @Davest3r08, @EarwigBot (@The Earwig), @InternetArchiveBot (@Cyberpower678, @Harej), Y U NO have valid signature? — Alexis Jazz (talk or ping me) 07:09, 26 November 2023 (UTC)[reply]

I will note that the list is just for people that edited in the last three months. If this goes ahead, we should do a quarry to get everyone. I realize that we will be messaging a bunch of accounts last active a decade ago, but I would point to WP:USURPNAME or the mass messages sent for SUL finalization (m:Single User Login finalisation announcement and phab:T74123) as precedent. House Blaster^talk 07:27, 26 November 2023 (UTC)[reply]

We should notify everybody, not just the editors on that three-month list. I will note that the vast majority of signature errors are not actually Wikipedia:Linter errors, since a group of editors has been notifying editors for over three years with messages like this. Almost all of the errors are for other validation failures. – Jonesey95 (talk) 07:40, 26 November 2023 (UTC)[reply]

Is there an error after the templates are substituted? Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:10, 26 November 2023 (UTC)[reply]

Adam Cuerden, looking at User:Adam Cuerden/FP signature maybe it's a false positive. That page is 251 characters so would push you over the limit of 255, but it contains some substitution itself and your actual signature is 209 characters after all substitution is done. I suspect the software wouldn't block your signature as it's not a lint error. — Alexis Jazz (talk or ping me) 17:21, 26 November 2023 (UTC)[reply]

If that shows up in a list of LINT-failed signatures, how many others are false positives? Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:42, 26 November 2023 (UTC)[reply]

The list includes more than just lint errors - it mentions for Adam Cuerden's signature that the error is that the signature is "sig-too-long-post-subst". I would hope the actual software check fully substs before checking length. Galobtter (talk) 18:24, 26 November 2023 (UTC)[reply]

209 characters is not too long. --Redrose64 🌹 (talk) 19:50, 26 November 2023 (UTC)[reply]

It appears that the tool does not fully expand nested substitutions, unless I am missing something (which happens a lot). I have posted a note to T248632. – Jonesey95 (talk) 20:22, 26 November 2023 (UTC)[reply]

@Alexis Jazz: Thanks for the ping. I'm pretty confident my signature (and my bot's) is not too long: 114 and 106 characters respectively. And thanks for your subsequent clarification that these non-issues wouldn't be affected by this proposal. ;) — The Earwig (talk) 14:11, 27 November 2023 (UTC)[reply]

There is enough agreement here to move the question (without these replies) to proposals. I would just notify recent editors. Notifying everyone would probably involve pointless commentary on long-gone users, including those who have been indeffed. Lighting up people's watchlists is unwelcome. If someone who hasn't edited in the last three months returns and notices their signature isn't what they expect, they should think that something has changed during their absence and with luck they will find somewhere to ask. Johnuniq (talk) 09:42, 26 November 2023 (UTC)[reply]

Johnuniq, maybe the period for inactivity could be stretched to 2 years or so. (and exclude indeffed editors, and if possible also exclude {{Deceased Wikipedian}}) I'd wager someone who returns after more than 2 years won't remember they had customized their signature anyway. — Alexis Jazz (talk or ping me) 10:04, 26 November 2023 (UTC)[reply]

This already links a larger project, phab:T248632 about this topic, which seems to be for all WMF projects? I'd rather see this done a wmf-default then try to do something for only enwiki. — xaosflux ^Talk 10:57, 26 November 2023 (UTC)[reply]

There are two reasons I brought this here (i.e. enwiki). One is per this comment which says in part If you convince the community of English Wikipedia (or any other project) that they should disallow obsolete HTML tags in signatures, then I'd be happy to make a config change that would enforce that (for that project only) (this is now the config flag $SignatureAllowedLintErrors). Second, getting this change done globally would entail cross-wiki mass messages, which brings in questions of translation, how many notifications we need (do we notify a user once? once per project they have an account? once per project they have edited?), etc. I would like this to be global, but I think just doing enwiki is a good first step. House Blaster^talk 15:20, 26 November 2023 (UTC)[reply]

The mw:Editing team had been planning at least two messages per affected user, at each affected wiki, probably for editors who had made any action during the last year. WhatamIdoing (talk) 23:35, 26 November 2023 (UTC)[reply]

This is trying to fix a non-problem. Already there have been bots and people putting in a lot of effort to fix something that does not matter. Just let the signatures decay in newer browsers that don't support the old syntax. They will likely still display the text for the name of the user. Early on I just signed "GB" and it could be hard for bots for figure out who that was. But it does not matter. Graeme Bartlett (talk) 11:08, 26 November 2023 (UTC)[reply]

I realize that we are on opposite ends of this particular debate (and I deeply respect your opinion), but I think that ship has sailed. Bots are already fixing old signatures; this would actually decrease the amount of edits they will make. House Blaster^talk 15:20, 26 November 2023 (UTC)[reply]

The problem, Graeme Bartlett, is that there are still people signing with invalid sigs like "GB". That diff is from 27 October 2023. Those people's signatures should be changed to something valid. – Jonesey95 (talk) 20:31, 26 November 2023 (UTC)[reply]

@Jonesey95: If you spot such "signatures", serve them a {{subst:Uw-siglink}} as I did here. --Redrose64 🌹 (talk) 22:19, 26 November 2023 (UTC)[reply]

Thanks for that link. I think the idea of this discussion is that a bot or AWB editor would deliver a similar message to a few hundred editors all at once, and then after some period of time without a change, their signatures would be changed for them. I'll wait for this discussion to conclude before taking action on my own, since it wouldn't make much sense (to me) for those editors to get two such messages in close succession. – Jonesey95 (talk) 22:33, 26 November 2023 (UTC)[reply]

Ahecht, an effect similar to TALK
PAGE without line break may be achieved with TALK PAGE though the actual display may depend on browser/installed fonts. Perhaps it can be optimized. — Alexis Jazz (talk or ping me) 11:49, 26 November 2023 (UTC)[reply]

@Alexis Jazz Thanks, but I believe the tool is mistaken, as the technical enforcement prohibits line-break or carraige-return characters but not   and . I'll keep that in mind if I get any serious complaints that my signature is disruptive, I believe it meets the spirit of WP:SIGAPP even if it's a technical violation since it doesn't negatively affect nearby text display. --Ahecht (TALK
PAGE) 17:10, 27 November 2023 (UTC)[reply]

Ahecht, I gave it some thought. Line breaks are probably prohibited because they break up lists and would complicate finding the signature in wikitext. For   this doesn't seem to be the case. But if your signature timestamp and signature userlink are separated by a   it might confuse some tools. At any rate, it looks terrible.
Your   lives inside of an inline-block. I doubt this particular case would cause technical problems. The font is very tiny so accessibility could be a concern, but you also have a userlink with the regular font size so the talk page link is just extra. There may be an alternative though that doesn't require a line break nor depends on word wrapping:

<b style="background:#f4a;color:#fff;padding:0.04em;"><sup style="display:inline-block;min-width:3em;font-size:0.5em;">TALK</sup><sub style="margin-left:-3em;font-size:0.5em;">PAGE</sub></b>

Result:
^TALK_PAGE — Alexis Jazz (talk or ping me) 18:10, 27 November 2023 (UTC)[reply]

Comparison of three different ways to format Ahecht's sig

This is what those three options look like for me. The original is the only one that displays like I expect it to. WhatamIdoing (talk) 19:59, 27 November 2023 (UTC)[reply]

WhatamIdoing, hmm, guess it still depends on what fonts you have installed and/or browser engine. SVG would be more appropriate I think, but images are not allowed in signatures. — Alexis Jazz (talk or ping me) 20:51, 27 November 2023 (UTC)[reply]

@Ahecht and Alexis Jazz: I mean, you can change the target link of an image, so there's always an option to use a small image in a pinch. Though that could have issues for our blind Wikipedians. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 00:55, 28 November 2023 (UTC)[reply]

SIGIMAGE says that images in signatures are not an option. Anomie ⚔ 01:51, 28 November 2023 (UTC)[reply]

Isn't there an emoji for "TALK OVER PAGE BLUE BACKGROUND" yet? We seem to make an exception for those. —Cryptic 02:09, 28 November 2023 (UTC)[reply]

Here are some more versions to try: TALKPAGE TALKPAGE Anomie ⚔ 02:26, 28 November 2023 (UTC)[reply]

This should be done. The links you've presented already shows the en.wiki community consensus and the greater WMF one on the matter. We don't really need yet another discussion for this. Gonnym (talk) 12:24, 26 November 2023 (UTC)[reply]

As the guy who BOLDly deprecated WP:A5, I hate discussion for the sake of discussion. However, the folks at phab really like RfCs with closing statements (see also step two of m:Requesting wiki configuration changes#How to request a change). House Blaster^talk 15:20, 26 November 2023 (UTC)[reply]

Another thought while we are here: should we also propose enforcing the post-subst sig length limit? I do not see that documented as a configurable option, but I don't think it would be too hard to implement. Maybe phrasing this as (two separate proposals?) "enforcing WP:SIG through the software however feasible" + "no more LINT, period". House Blaster^talk 15:20, 26 November 2023 (UTC)[reply]

HouseBlaster, enforcing the post-subst sig length is difficult I think. For the MediaWiki software to check it it would have to substitute the entered signature. It needs to access the DB, have any further templates substituted, have parser functions executed, all while saving preferences. That's a very different kind of validation compared to validation required for other inputs which can be completed without accessing other resources. This could result in bugs. I suppose it could be done onblur() of the signature input field, such a check could be circumvented but that doesn't really matter as changing the content of the substitution target afterwards is easier than disabling JS in your browser. But a gadget can't do this as those can't be loaded on Special:Preferences, so that would have to be part of the MediaWiki software. — Alexis Jazz (talk or ping me) 16:26, 26 November 2023 (UTC)[reply]

Fair enough; I have struck it as out of scope. House Blaster^talk 19:31, 26 November 2023 (UTC)[reply]

I continue to believe the entire concept of lint errors is nothing more than a classic WP:Parable of the wildflowers and hence oppose this change. * Pppery * _{it has begun...} 16:40, 26 November 2023 (UTC)[reply]

Oppose. I've never seen a Lint fix actually touch my signature as done; I think it just doesn't like the pre-subst: and flags it. If you can't point out a LINT error in the signature at the end of this, then the bad-LINT detection is wrong. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 17:14, 26 November 2023 (UTC)[reply]

I have clarified the proposal: your signature would not be affected. sig-too-long-post-subst is tracked at the list, even though there is no currently no technical way to enforce it (which is probably why it less accurate than the other errors). I originally came across this as a way to reduce lint errors, but framing this as mainly a LINT fix was a mistake on my part: most signatures would be disabled for non-LINT reasons (namely, they do not have a link to their local user / user talk / user contribs page). House Blaster^talk 19:31, 26 November 2023 (UTC)[reply]

Forgive me if I'm wrong, but surely that's a requirement already, right? Is there any example of not doing that (Presuming one-out-of-three is sufficient). I mean, there's always ways around it; For example, this (between the arrows) → Adam Cuerden ← technically contains a link to my user page (It's linked to a hair-space, the narrowest possible whitespace character I found on a quick glance, just after my first name), but sometimes you just have to accept that certain violations have to be dealt with by admins, not programming. But that's kind of an aside. I'd say requiring a link to one of the three is fine, and if that affects a subst: chain in someone's signature where the link gets buried, well, can't be helped. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:34, 26 November 2023 (UTC)[reply]

It would be great if we could Obi-Wan the brains of people who are referring to this as a discussion about Linter (or "LINT", which is not valid capitalization), since only 19 of the 226 current errors in this week's list are Linter errors like "missing end tag". Most of them are violations of other signature rules, like not having a link to your user/talk/contributions, or linking to a user page that does not match your username (105 and 31 entries, respectively). I don't think anyone is talking about retroactively fixing pages where those invalid signatures were applied. We're just talking about fixing signatures that are presumed to be currently in use (i.e. the editors have at least one talk page edit in the last three months). As far as I can tell, the "too long after substing" list is also out of scope because the detection is not working properly. P.S. to Adam Cuerden: Yes, a link to a user or similar page is a requirement, but the new requirements applied only to new or changed signatures. Existing signatures were grandfathered in and continue to be used more than three years after the requirements started to be enforced via technology. – Jonesey95 (talk) 20:52, 26 November 2023 (UTC)[reply]

Wikipedia:Signatures#Links requires a link, but that hasn't been enforced in software in the past. WhatamIdoing (talk) 23:39, 26 November 2023 (UTC)[reply]

It's possible this discussion got off on the wrong fooot: I'd be absolutely fine with the not matching username/missing link ones being dealt with, but the framing of this was very Linter-heavy, including me getting called out for showing up in one of the buggier detection checks. It's clear that we shouldn't try and use every error code, but starting with some of the robust and non-controversial ones would make this an easy proposal to pass, then we can discuss the other codes in turn. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:59, 26 November 2023 (UTC)[reply]

This is turning out to be a great exercise in why RFCBEFORE is so important.... I have done some more digging and think I have untangled the various things I conflated in my head. My original proposal was born from the toolforge list linked above, but this proposal addresses a separate (but overlapping) problem.

Setting $wgSignatureValidation to disallow is hopefully uncontroversial. It is currently set to new, which prevents invalid signatures from being saved in preferences, but does not affect signatures from before this was implemented. Setting to disallow would eliminate that grandfather clause, defaulting old invalid signatures to MediaWiki:Signature.

mw:New requirements for user signatures is the complete list of reasons a signature is considered invalid, and (as I now realize) it is not identical to what is tracked at the toolforge list. The validator cares that the signature contains a link to their user / user talk / user contribs, and a few other things (all of this is already in force for newly saved signatures). Notably, Line breaks and sig-too-long-post-subst are not considered invalid by the software (and this proposal would not change that). The validator also requires signatures be lint-free unless that type of lint error is listed at $wgSignatureAllowedLintErrors (see Wikipedia:Linter § List of lint errors for the different types). Currently, that list contains only obsolete-tag (primarily ..., but also <strike>...</strike> and <tt>...</tt>). Setting this to the empty array would make the validator care about obsolete tags (which would prevent them from being used in new signatures, and if $wgSignatureValidation is set to disallow, default old signatures to MediaWiki:Signature). House Blaster^talk 23:05, 26 November 2023 (UTC)[reply]

It would be great to disallow these long-obsolete tags in signatures. Allowing them to be added with new edits just means more bot and human cleanup when support is eventually removed for those tags. – Jonesey95 (talk) 01:17, 28 November 2023 (UTC)[reply]

Adam Cuerden, your hair-space userlink is technically fine, tools like DiscussionTools, reply-link (if you manage to load it), ConvenientDiscussions and my own userscript should detect that just fine. If any bot would use it (not sure any do), they should have no problem with it either.
The admins might have a problem with it though. — Alexis Jazz (talk or ping me) 22:09, 26 November 2023 (UTC)[reply]

@Alexis Jazz: Well, yes. Just pointing out we can't try to block everything. At some point, humans are better judges. So if we can stop the problems one can make by mistake, e.g. failing to link or, say, if I linked to User:Adam by mistake (more likely if my name was, say, User:Adam356, admittedly) ... that's going to be very helpful, but if we focus on trying to fix everything, including things with buggy reporting tools, and especially if we're going to have continuous checking so something can suddenly go wrong one day, it feels like this becomes a mess. Adam Cuerden ^(talk)_{Has about 8.6% of all FPs.} 20:36, 27 November 2023 (UTC)[reply]

A reminder that VPI is not the place for bolded support/oppose !votes. Also the list of users is for more than just lint errors; in fact most of the people listed here are for not lint error issues. Galobtter (talk) 18:30, 26 November 2023 (UTC)[reply]

It's also worth noting, this or the future discussion isn't a question about lints and whether you think they are worth fixing or not. We had that discussion here and any argument on the merit of that is purely disruptive. The discussion should only be on if or how to implement the above proposal. Gonnym (talk) 12:02, 28 November 2023 (UTC)[reply]

Moving to VPPROP

I have drafted an RfC in my sandbox (permalink); feedback/wordsmithing is welcome. House Blaster^talk 06:16, 27 November 2023 (UTC)[reply]

Future crosswiki citation of Wikifunctions

Of course, in its present state Wikifunctions doesn't even support numerical datatypes, so that this is not going to be realizable in the next few years is a given. And I suppose it might be obvious given their stated goals with that project, but: understanding why the pillars of Wikipedia are designed the way they are, I don't see why one couldn't just cite a mature Wikifunctions in math articles to support mathematical claims. There would need to be some assurance that the algorithm cited actually does what it's claimed as doing, but that seems in itself like a solveable second-order problem. Now I'm excited. Thoughts? Remsense留 16:50, 29 November 2023 (UTC)[reply]

Allow Page Movers to delete insignificant redirects

When I am working WP:RMTR I often run into redirects that have just a few insignificant revision history entries that always require a round robin page swap. I know these can be mostly semi-automated now but they still make a mess of everything. I think page movers should be allowed to delete redirects with trivial history to facilitate page moves better. My general idea is that on redirects page movers would have access to the "delete" button directly if the redirect has never gone above a certain byte count. They wouldn't have access to deleted revisions or anything like that which I know would be a concern. This idea basically boils down to expanding the delete redirect user right to allow PMs to use the delete button directly on multi-revision redirects. Seawolf35 ^T--C 16:07, 1 December 2023 (UTC)[reply]

I think this needs stricter definitions of what "trivial" edit histories mean. Sohom (talk) 21:49, 1 December 2023 (UTC)[reply]

If they don't have access to deleted revisions, then they can't undelete if they make a mistake, which seems a bit of an issue. Why couldn't this be solved with a speedy deletion criterion, or just doing it under G6? Seraphimblade ^{Talk to me} 22:24, 1 December 2023 (UTC)[reply]

In my definition, ""trivial" edit history is a redirect that has less than a certain number of revisions, say 5, and never has gone over a certain byte count, basically making sure it would have never gone above the byte count that would be a redirect + rcat tag. PMs could have access to deleted revisions of deletions done by other PMs so they could undelete. Seawolf35 ^T--C 22:35, 1 December 2023 (UTC)[reply]

Mandating 2FA usage for users with advanced permissions

Right now, two-factor authentification is an option for all users. If you are a user without advanced permissions, you have to request metawiki stewards to give you access. Which probably is fine for an average user but advanced permissions require advanced security. Right now, certain users on metawiki already must use 2FA.

What I propose is an analogous requirement for certain users with advanced permissions (as listed in H:ACCESS2FA, plus ArbCom members, ArbCom clerks and SPI clerks that are not already covered. I think bots could be covered as well, because a rogue actor automatically deploying malicious code via bots is probably about as dangerous as a rogue admin). So in order to get to the advanced permission/role, a user must enable 2FA or else not be able to use the account within advanced roles (they will still be able to do so within EC rights).

Now, before this goes to VPR, I have a couple technical questions:

Admins and other advanced permission users have automatic 2FA access but they don't have to use it. Is there a way to check that a given user with 2FA access actually uses it, i.e. they did not disable it?
Is there a technical implementation for disabling advanced permissions-related functions when 2FA is disabled?
In particular as relates to ArbCom correspondence (as theoretically non-admins can be ArbCom members, just that it didn't happen yet), is there a way to deny access to the internal email system for users not having enabled 2FA? Because surely internal mailing list access is only given to specific users confirmed to be arbs, right?

See also WP:PASSWORD. This will be impacted. Szmenderowiecki (talk) 13:39, 2 December 2023 (UTC)[reply]

Given my experience (while serving on ArbCom) at using 2FA as currently implemented in Wikipedia, I will resign my adminship if forced to use 2FA to keep it. - Donald Albury 18:22, 2 December 2023 (UTC)[reply]

What was so bad about it? Szmenderowiecki (talk) 19:41, 2 December 2023 (UTC)[reply]

Too easy to brick an account using the Wikimedia 2FA. I do use 2FA for some non-Wikipedia accounts. I don't want to risk bricking an account that I have been using for more than 18 years. Donald Albury 00:20, 3 December 2023 (UTC)[reply]

@Szmenderowiecki: What problem does this solve? Is there a large number of compromised admin accounts that would be prevented by this requirement? RudolfRed (talk) 19:54, 2 December 2023 (UTC)[reply]

First, it's about defence in depth. Cybersecurity kinda works the way that it works well until it doesn't. 2FA in my view is a reasonable thing to activate - setting up takes 3 mins, takes another 5 s to login, but it is much better security-wise than just a password.

Secondly, the cases in which admins' accounts being compromised had some effect on Wikipedia are not nonexistent. As far as my research went these were User:AlisonW in 2016, User:Staxringold in September 2022. From global perspective, Rubin16 was compromised in March and glocked (was admin on Commons). So it's not hypothetical, it happens. Not every week to be sure, but

Of course, you can be compromised by other ways, such as keyloggers on your computer, viruses or other malware, and you can deploy antiviruses, firewalls, adblockers etc. to combat it. This, unlike 2FA, is beyond our control.

Also, to be clear: the idea is that admins will have their bits whether or nor they use 2FA, but it will not be possible to use these bits unless you log in with 2FA (I imagine the system can distinguish between a user logging in with a simple login and then enable 2FA while logged in and disable it before logging out vs a user logging in with a 2FA token. Szmenderowiecki (talk) 21:07, 2 December 2023 (UTC)[reply]

Szmenderowiecki, you don't need me to tell you that fundamentally, security is not merely about denial of access, it is also about availability of access, and is a balance. Defense in depth is a valid framework to analyze a lot of different issues, but mostly those where the possibility for knock-on effects is systematic, which compromised admin accounts do not appear to have already by design.
This isn't the most direct counterargument, but the enwiki is already suffering a bit of an adminship crisis for reasons unrelated to this discussion, and if a measure is implemented, A potential reduction of the admin pool further or one that prevents it from growing is, in my mind, a bigger distributed security flaw in the broad sense. So if it is true that this would seriously dissuade adminship, that needs to be seriously considered. Remsense留 22:28, 2 December 2023 (UTC)[reply]

Ultimately what we are speaking here is the balance between the cost of developing the system and needing to log in with an additional factor and the benefits of not needing to direct volunteer efforts on compromised admin accounts and feeling better about security of power users. For me the benefits outweigh the costs even in the current implementation in the vast majority of situations, and anyway any mandate will have some downsides, but if what is needed first is an improvement we know we are going to push for before rolling it out I can wait for it, but only if we actually do sth about it.

Also, if 2FA is the hill admins feel they have to die on, then OK I guess but IMHO that's not tackling the problem that's chickening out of it. Szmenderowiecki (talk) 23:35, 2 December 2023 (UTC)[reply]

There are shortcomings with the current implementation, as described by Risker during the 2019 RfC on requiring admins to use two-factor authentication, who also provided additional details on required improvements in their view. (Some of the concerns are specifically around the need for users to have full admin control over a personal computing device, so that appropriate software can be installed. While this is true for many, it's not something that can be assumed for all admins.) Until the infrastructure and ongoing support issues are addressed, mandated widespread use of two-factor authentication would be operationally challenging. isaacl (talk) 21:08, 2 December 2023 (UTC)[reply]

From a technical standpoint, I support #1 and #5 in Risker's suggested improvements; the WMF should have a code steward designated for the extension, and some further design work would be beneficial. — Frostly (talk) 21:19, 2 December 2023 (UTC)[reply]

If it means confronting WMF about not doing anything for the past 4 years on that front and doing their job for once with the money they have I think it's worth a try. Idon't expect much from that but the alternative is arguably worse. Szmenderowiecki (talk) 21:24, 2 December 2023 (UTC)[reply]

That, I'm all for. But while I do use 2FA, there are a fair number of requirements for that. I have full and (essentially, notwithstanding some use by family) exclusive control over several computers, including the one I normally use to edit and the one I use for the authenticator. I have a safe and secure place to keep my backup codes in case the device I use for authentication fails. That is not necessarily true for every editor, including every admin, certainly not at every point in their life. Before we start requiring 2FA, we need both improvements to how it works (I see Risker's excellent summary of those issues has been linked above), and a defined process by which someone who does get locked out can prove their identity and regain access. Seraphimblade ^{Talk to me} 22:52, 2 December 2023 (UTC)[reply]

OK, so shall we discuss the steps we should do to get to that stage? As in write a letter to WMF, or sth else? Szmenderowiecki (talk) 23:41, 2 December 2023 (UTC)[reply]

I think bots could be covered as well, because a rogue actor automatically deploying malicious code via bots is probably about as dangerous as a rogue admin). I really don't think this is the case, a bot account can't really do anything more than any other editor, other than make edits faster. Also malicious code can be run using any account. Galobtter (talk) 23:38, 2 December 2023 (UTC)[reply]

Change edit summary after publishing an edit

I am annoyed when I’m using the Visual Editor, publish my edit, and add an edit summary, only to realize that I put an edit summary I instantly regret putting. It happened to me tens of times. I want a solution to this problem. I propose a solution named “Live Summary” which does just that. Equal width (C) 14:36, 2 December 2023 (UTC)[reply]

I note this sort of thing has been suggested before. Once it was pointed out that then you'd need a history for edits to edit summaries, and then the edit summaries in each edit summary's history would similarly need to be editable and have history, it has generally been acknowledged that this seems like a lot of complexity for not much benefit. Even if you do get consensus for it here, you'd need to convince software developers to write all the code to make it happen. Anomie ⚔ 15:07, 2 December 2023 (UTC)[reply]

I make a lot of mistakes in edit summaries, mainly typos. If you think an edit summary will cause problems, make a dummy edit to mitigate the problem in a new edit summary. Donald Albury 18:27, 2 December 2023 (UTC)[reply]

Isn’t that a little inconvenient? Equal width (C) 18:57, 2 December 2023 (UTC)[reply]

I'm like Donald Albury in that I make many errors. Usually they are inconsequential, so I just let them go, but occasionally I will make a dummy edit to correct things. I don't think that that approach is any more inconvenient than correcting the summary would be. As Anomie says it would be nice to be able to correct the original summary, but that would be a lot of work for very little benefit. Phil Bridger (talk) 19:11, 2 December 2023 (UTC)[reply]

Just to be snarky… this doesn’t happen to those of us who don’t bother writing edit summaries. 😉Blueboar (talk) 23:15, 2 December 2023 (UTC)[reply]