Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
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:

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, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53

Deprecating Wikipedia:Changing username[edit]

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). HouseBlastertalk 02:55, 13 November 2023 (UTC)Reply[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[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). HouseBlastertalk 23:13, 13 November 2023 (UTC)Reply[reply]
Or perhaps they're blocked at Meta-Wiki. WhatamIdoing (talk) 04:45, 18 November 2023 (UTC)Reply[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[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[reply]

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[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[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[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[reply]
BLPN ~11000 views in the past 30 days, RSN ~22700 views. ScottishFinnishRadish (talk) 02:14, 14 November 2023 (UTC)Reply[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[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[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[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[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[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[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[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[reply]
I've dropped notices on FTN, NPOVN, and NOR. -- LCU ActivelyDisinterested «@» °∆t° 22:01, 14 November 2023 (UTC)Reply[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[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). —PaleoNeonate – 01:37, 15 November 2023 (UTC)Reply[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[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? —PaleoNeonate – 07:06, 19 November 2023 (UTC)Reply[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[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[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[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[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[reply]
A merger has been rejected before Mach61 (talk) 05:39, 15 November 2023 (UTC)Reply[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[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[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[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[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[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[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[reply]

Editnotice on all mainspace talk pages?[edit]

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[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[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[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[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[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[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[reply]

Reenabling some form of PC2 to assuage complaints about ARBECR?[edit]

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[reply]

The pending changes backlog is effectively zero and has been such for maybe 2 years now, whenever I've bothered to check. I personally got permissions just to watch a single page that a reviewer made an inattentive mistake on, and I realized it's the only article of the ~800 on my watchlist that is under WP:PCPP. (Incidentally, the barrier to getting PCR permissions would be reasonably low, at least on paper, as long as you don't get audited like in an RfA -- I complained about my request for that reason.)
It seems to me that PCP is underused and WP:ECP is grossly overused. I find myself, not on some crusade but just on what I think is common sense, to be frequently advocating for IP and new user agency over the reverts of other editors (though more commonly when they make complaints on Talk pages, where neither protection applies.) I would suggest instead that admins apply PCP far more liberally over ECP. (The latter sets another barrier that discourages new editors making minor corrections on popular pages; at least with PCP they don't have to write an essay to fix a comma.) Another tier of PCP seems hardly necessary when there is no backlog and no usage of the existing, already quite restrictive tier.
(Not to sidetrack the issue, but looking through protections, why is WP:FULL used for a month or more on pages where registered editors are edit warring, such as in Common Dead? What the heck happened to restricting the individual editors?) SamuelRiv (talk) 12:11, 5 December 2023 (UTC)Reply[reply]
If I'd hazard a guess, blocked editors complain more and blocks are scrutinized more than protected pages. The page can't file an AN/ARBCOM report, after all. Jo-Jo Eumerus (talk) 12:22, 5 December 2023 (UTC)Reply[reply]

Running low on administrators[edit]

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[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[reply]
It wasn't required when I ran. --Redrose64 🌹 (talk) 21:09, 24 November 2023 (UTC)Reply[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[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[reply]
You seem to be pretty experienced. I'd say you have a decent chance. Wikiexplorationandhelping (talk) 21:43, 25 November 2023 (UTC)Reply[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[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[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[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[reply]
This isn't an RFC, just something that should have been posted on VPI Mach61 (talk) 02:53, 25 November 2023 (UTC)Reply[reply]
not everything is an rfc Edward-Woodrow (talk) 20:56, 25 November 2023 (UTC)Reply[reply]
But this was an rfcAlexis Jazz (talk or ping me) 21:02, 25 November 2023 (UTC)Reply[reply]
Oop, my bad. Striking. Edward-Woodrow (talk) 21:08, 25 November 2023 (UTC)Reply[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[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[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[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[reply]
That's when criterion 2 of WP:INACTIVE (originating rfc) went into effect. —Cryptic 06:07, 25 November 2023 (UTC)Reply[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[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[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[reply]
Aye, I knew I should've thought to think of specifics. Remsense 06:41, 25 November 2023 (UTC)Reply[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[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[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[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[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[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[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[reply]

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

Disallowing invalid signatures [edit]

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.

(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 <font>...</font> 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? HouseBlastertalk 02:53, 26 November 2023 (UTC)Reply[reply]

Pinging @Matma Rex, @AntiCompositeNumber, and @Jonesey95. WhatamIdoing (talk) 05:45, 26 November 2023 (UTC)Reply[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[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[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[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[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. HouseBlastertalk 07:27, 26 November 2023 (UTC)Reply[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[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[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[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[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[reply]
209 characters is not too long. --Redrose64 🌹 (talk) 19:50, 26 November 2023 (UTC)Reply[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[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[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[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[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[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. HouseBlastertalk 15:20, 26 November 2023 (UTC)Reply[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[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[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. HouseBlastertalk 15:20, 26 November 2023 (UTC)Reply[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[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[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[reply]
Ahecht, an effect similar to TALK
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[reply]
@Alexis Jazz Thanks, but I believe the tool is mistaken, as the technical enforcement prohibits line-break or carraige-return characters but not <br> and <p>. 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
) 17:10, 27 November 2023 (UTC)Reply[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 <br> this doesn't seem to be the case. But if your signature timestamp and signature userlink are separated by a <br> it might confuse some tools. At any rate, it looks terrible.
Your <br> 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>
TALKPAGEAlexis Jazz (talk or ping me) 18:10, 27 November 2023 (UTC)Reply[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[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[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[reply]
SIGIMAGE says that images in signatures are not an option. Anomie 01:51, 28 November 2023 (UTC)Reply[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[reply]
Here are some more versions to try: TALKPAGE TALKPAGE Anomie 02:26, 28 November 2023 (UTC)Reply[reply]
This should be done. The links you've presented already shows the 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[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). HouseBlastertalk 15:20, 26 November 2023 (UTC)Reply[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". HouseBlastertalk 15:20, 26 November 2023 (UTC)Reply[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[reply]
Fair enough; I have struck it as out of scope. HouseBlastertalk 19:31, 26 November 2023 (UTC)Reply[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[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[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). HouseBlastertalk 19:31, 26 November 2023 (UTC)Reply[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[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[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[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[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 <font>...</font>, 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). HouseBlastertalk 23:05, 26 November 2023 (UTC)Reply[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[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[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[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[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[reply]

Moving to VPPROP[edit]

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

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

Future crosswiki citation of Wikifunctions[edit]

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) — Please ignore this, I didn't state my ideas clearly at all, I will try again when I'm able to do so.Reply[reply]

I can barely understand your argument. First, can you elaborate the connection between your proposal and the pillars of Wikipedia? Next, can you give an example of how Wikifunctions can improve math articles, if not computer science articles? MilkyDefer 05:47, 5 December 2023 (UTC)Reply[reply]

Allow Page Movers to delete insignificant redirects[edit]

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[reply]

I think this needs stricter definitions of what "trivial" edit histories mean. Sohom (talk) 21:49, 1 December 2023 (UTC)Reply[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[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[reply]

Mandating 2FA usage for users with advanced permissions[edit]

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:

  1. 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?
  2. Is there a technical implementation for disabling advanced permissions-related functions when 2FA is disabled?
  3. 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[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[reply]
What was so bad about it? Szmenderowiecki (talk) 19:41, 2 December 2023 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[reply]
I'm not sure if "improve 2FA to be not terrible and irreversible" is an appropriate community wishlist item, but the next round is probably coming up in a few months. As to this idea, I could see mandatory 2FA for functionaries including Arbcom members, who are actually dealing with private information, and for intadmins, who have higher potential for widespread disruption, but requiring it for regular admins seems pretty unnecessary. Folly Mox (talk) 03:03, 3 December 2023 (UTC)Reply[reply]
Intadmins already must use 2FA. Szmenderowiecki (talk) 07:59, 3 December 2023 (UTC)Reply[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[reply]
  • Is it really in the project's interests to force all technophobic admins to retire at once? Espresso Addict (talk) 01:02, 3 December 2023 (UTC)Reply[reply]
    Why does not wanting to use the Foundation's implementation of 2FA make me "technophobic"? In fact, I resent that term being applied to me. The final 20 years of my working life was spent in writing production software and supporting computers and computer networks. I was also a volunteer sysop on the Novell Software Support Forums for several years.[1] Donald Albury 01:52, 3 December 2023 (UTC)Reply[reply]
Ah, sorry, I meant I am technophobic (as my edit summary makes clear) -- the word was not intended to describe you. I would certainly resign adminship if 2FA were to be required. Espresso Addict (talk) 01:59, 3 December 2023 (UTC)Reply[reply]
Strong no. Besides the fact that 2FA is a pain the rear, not everyone is even technically capable of using it. See my and Alexis Jazz's comments in this older discussion. Users shouldn't be forced to buy a smartphone just to pass RfA. Edward-Woodrow (talk) 15:58, 3 December 2023 (UTC)Reply[reply]

I'm going to pile on by mentioning that the admins who have adopted the current 2FA system are those with a fascination for this kind of technology. Even in that elite group, there have been quite a few plaintive pleas along the lines of "bad stuff happened and I can't log in". If hundreds of admins who do not want another hassle in their life were required to use 2FA, there would be many more problems. We might say, well that's the price of progress but there is no problem needing to be solved. A more significant issue with a bunch of admins not being able to log in would be that the system to manually reset their password and remove 2FA would be a gaping security problem where social engineering would be likely to allow bad actors access to admin accounts. Johnuniq (talk) 03:11, 3 December 2023 (UTC)Reply[reply]

Change edit summary after publishing an edit[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. Equalwidth (C) 14:36, 2 December 2023 (UTC)Reply[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[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[reply]
Isn’t that a little inconvenient? Equalwidth (C) 18:57, 2 December 2023 (UTC)Reply[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[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[reply]
    Please don’t use emojis in the village pump, they are not helpful at all. Equalwidth (C) 04:51, 3 December 2023 (UTC)Reply[reply]
    Please don't police other editors' language use unless it's legitimately disruptive. Folly Mox (talk) 05:06, 3 December 2023 (UTC)Reply[reply]
    I find them quite helpful, seeing them makes me smile and keeps my spirits high so I keep working hard and helping others. Remsense 05:12, 3 December 2023 (UTC)Reply[reply]
    WP:FUNPOLICE Edward-Woodrow (talk) 15:59, 3 December 2023 (UTC)Reply[reply]
I agree that a simple warning when you posting with a blank edit summary would be nice and a relatively clean add-on. When I accidentally do that, I make second dummy edit. Other ideas that would only require an extension, as opposed to new/changed WM code:
  1. AI-generated edit summary, with the suggestion generated if the summary is left blank, using a model trained off of GPT (provided WMF would fund a modest amount of API calls), or maybe even some simpler non-LLM that can be run on a small server. Alternatively, such a summary can be generated automatically for blank or terse edit summaries regardless of editor wishes, and then saved for a few months on the server, visible to editors with the extension.
  2. Simple edit summary checker, like spellcheck + automoderation, that warns you if you may be publishing something you regret. (Also useful for Meta and Talk page posts.)
That's all I got for now. Honestly I don't think auto-summarizing a typical WP edit requires, or even benefits from, a LLM, since most necessary info should be extractable from the markup templates used (or lack thereof) (thus an entirely competent program could be entirely linear with no AI jazz whatsoever). SamuelRiv (talk) 15:10, 3 December 2023 (UTC)Reply[reply]
There's already "Prompt me when entering a blank edit summary (or the default undo summary)" in Special:Preferences#mw-prefsection-editing, FYI. Anomie 15:21, 3 December 2023 (UTC)Reply[reply]

Portals on the main page[edit]

Portal links have been removed from the top of the main page, after a 2022 discussion. A 2021 discussion was closed as no consensus. However, in the wake of the 2022 discussion, portals were removed entirely from the main page, save for one small link promoting a "unique way to navigate the encyclopedia".

On the 14th of April, 2022, Izno implemented the Village Pump consensus. This removal was fatal for Wikipedia:Contents/Portals and for the broad-topic portals.

The graph speaks for itself. A major argument in removing portals from the main page is that they don't receive enough pageviews. Clearly, removing them from the main page significantly adversely affects the pageviews. And a little link isn't enough. The broad-topic portals are good. I say that because a lot of portals aren't, because they don't have enough maintainers.

  • Should we...
  1. Maintain the status quo and slowly kill off portals
  2. Insert links to the broad-topic portals lower down on the main page – that would point readers to quality, informative content.
  3. Have a "featured portal of the week" or similar section of the main page to highlight diverse topics
  4. Something else? This is the idea lab, after all, so suggest something new!

Edward-Woodrow (talk) 18:53, 3 December 2023 (UTC)Reply[reply]

I think even the portal-philes have accepted that the community doesn't want them and that the steep drop-off in views is an intended effect. Espresso Addict (talk) 21:06, 3 December 2023 (UTC)Reply[reply]
We shouldn't suppress quality content on the Main Page. (—Formerly Edward-Woodrow) Cremastra (talk) 15:18, 4 December 2023 (UTC)Reply[reply]
Clear consensus in the 2022 RfC disagrees. – Joe (talk) 08:28, 5 December 2023 (UTC)Reply[reply]
From what I gather, the problem with deprecating the namespace entirely is the importance of Portal:Current events? Mach61 (talk) 03:37, 4 December 2023 (UTC)Reply[reply]
It used to live in the main namespace at Current events and could easily do so again. It's always been a poor fit for the portal namespace. —Cryptic 08:40, 5 December 2023 (UTC)Reply[reply]
Wikipedia:Current events is also fine, currently a redirect. Izno (talk) 08:52, 5 December 2023 (UTC)Reply[reply]
Is there a reason any still active portals couldn't be merged with their relevant projects? They would seem a good match and would localise all editors active in a particular topic. -- LCU ActivelyDisinterested «@» °∆t° 20:06, 5 December 2023 (UTC)Reply[reply]
Because portals are reader-focused topic hubs that provide an overview of the topic and provide links to more detailed articles, wheras Wikiprojects are groups of editors interested in improving articles related to the topic. "Merging" them would make no sense. Cremastra (talk) 22:20, 5 December 2023 (UTC)Reply[reply]
It's not just portals directly linked from the main page that suffered, either. Take a look at the pageviews at Portal:Anime and manga. Cremastra (talk) 23:56, 5 December 2023 (UTC)Reply[reply]
Notified: WT:WPPORT, WT:PORTAL, T:MP. ~~~~

Thanks, Cremastra (talk) 22:16, 5 December 2023 (UTC)Reply[reply]

WP:ENDPORTALS and WP:ENDPORTALS2 found a substantial minority who would like to remove the Portal: namespace, though its most vocal opponents are no longer active on Wikipedia. Another major argument in the 2022 RfC was that the space at the top of the main page was urgently needed for other content, but this was never added or even identified. There is a logical connection between the main page and portals; they look superficially similar, and a good portal is what the main page would be if it were limited to one subject area. Although in a different namespace, portals are in a sense subpages of the main page. Certes (talk) 23:37, 5 December 2023 (UTC)Reply[reply]
It was a perverse decision, in my opinion, to remove the portal links in favour of an expansive blank space, yet that was the clear outcome of the discussion. Espresso Addict (talk) 01:24, 6 December 2023 (UTC)Reply[reply]
One option is to add a portal bar to the main page:
There may be room to squeeze one or two more portals in there, or even rotate one from a selection of portals which are good but narrower in scope, by adding a final entry something like |{{#switch:{{CURRENTDOW}} |1=Germany |2=Modern History |3=Music ...}}. Certes (talk) 12:08, 6 December 2023 (UTC)Reply[reply]
I like that, especially switching portals in and out occasionally. Cremastra (talk) 13:24, 6 December 2023 (UTC)Reply[reply]
It would need an RfC, as there is substantial opposition to making portals discoverable. Certes (talk) 14:33, 6 December 2023 (UTC)Reply[reply]
I would be against exposing a potentially unregulated and deprecated namespace being surfaced on the main page. Sohom (talk) 15:09, 8 December 2023 (UTC)Reply[reply]
Although not universally popular, I don't think the Portal: namespace is technically deprecated, as two well-attended RfCs decided against abolishing it. Certes (talk) 16:38, 8 December 2023 (UTC)Reply[reply]
What? Cremastra (talk) 20:44, 8 December 2023 (UTC)Reply[reply]
@Cremastra There are no actual guidelines wrt to what can go in and what cannot in a portal right? Not only that, these portals require maintainence, which the community seems to be unwilling to do. Exposing them as part of the Main page can cause people to have a bad experience especially if they end up on a page that nobody actaully maintains and has outdated information and/or is straightup broken.
Also, I agree that they are not "technically" deprecated, but at this point, the treatment the namespace gets is more akin to the failed Flow project (barely keep it working) which feels like a soft deprecation. Sohom (talk) 20:59, 8 December 2023 (UTC)Reply[reply]
Mhm. There are few guidelines on anything, because it would be instruction creep. There's a general consensus as to what a portal should look like, at WP:POG, and other guidelines at WP:PORTAL. Cremastra (talk) 21:24, 8 December 2023 (UTC)Reply[reply]
WP:POG explicitly states that it is a failed proposal and that it never achieved consensus and I'm unsure of how well updated and reflective of current consensus WP:PORTAL is (there is a maintainance tag on the top saying that it is somewhat out of date). Sohom (talk) 21:40, 8 December 2023 (UTC)Reply[reply]
I know it's a failed proposal, but most portals around at least roughly follow the suggestions within it. Cremastra (talk) 21:41, 8 December 2023 (UTC)Reply[reply]

Interest in testing a tool for Breaking News? Seeking feedback.[edit]

My team at the foundation, WME, has developed a dashboard that tries to identify new articles related to global "newsworthy" events as they are being written about across Wikipedia language editions at any given moment. You can read more about it here. I'm seeking help to improve the feature.

Here is the direct link to the dashboard. (desktop only).

I'd appreciate if anyone that tries it out can surface any potentially missing templates from across language projects that would help us capture more results. Using the thumbs up and down buttons in the demo to confirm or deny if entries are accurately identified as breaking news, would help me in the long and medium-term in building a better, more accurate tool.

Although Enterprises' focus is not on creating editing tools or gadgets, we hope this can be of use to the community, too.

Thanks! FNavas-WMF (talk) FNavas-WMF (talk) 16:19, 8 December 2023 (UTC)Reply[reply]

Are the thumbs up/down supposed to be if the article as a whole is about a current news event, or has been created in wake of a current news event? Because e.g. you have on the tracker Mama Diabaté who died two days ago, so that would be news and result in increased traffic and editing, but her notability would have been established over decades. On the other hand 2023 Guyana Defence Force helicopter crash was created for the purpose of covering a specific important recent news event. Are both to be considered "hits" for the tracker?
Also, "indications count" isn't documented, and I don't know what it means, and it seems odd (being a count) that you can only filter numbers equal to the count as opposed to higher or lower than. I also don't think the raw number of edits is too useful of a metric for the user to filter potential news articles, since news is rather localized by interest and region. Page-views-to-editor-ratio would seem more useful -- a niche new article or split may have a lot of edits from a dedicated editor and reviewers at first, but very few outside viewers will care to see it in the first hours. Any news event will blow it out of the water in viewer-to-editor ratio, even if news stories will have more anonymous editors. SamuelRiv (talk) 16:58, 8 December 2023 (UTC)Reply[reply]
Thanks for this feedback @SamuelRiv -- thumbs are to say, is this news or or not. there are a lot of false positives so were trying to filter what is not news. I'd consider both those examples as news. What is news and what isn't is so subjective, so really just up to the individual.
We don't use any pageviews right now, so all this is based on editing behavior/presence. Good call on the "viewer-to-editor" ratio idea ... My only issue that we could only calculate that 24/h too late (given how PV work right now). FNavas-WMF (talk) 21:10, 8 December 2023 (UTC)Reply[reply]
A 24h delay in the ratio is fine as long as you have some smoothing average on both views and edits -- it will be better than the metrics you currently have available. (I'm sure you can figure out better metrics once you get some data.)
News isn't really subjective in these clear cases -- your first verification would just be a Google n-gram call to see if there was a major spike in searches in the past week. If the API for that is free, that'd be the best metric I can think of. There's tons of simple algorithms to verify a spike or step discontinuity in rough data. SamuelRiv (talk) 21:20, 8 December 2023 (UTC)Reply[reply]
@FNavas-WMF many breaking news items are related to articles that already exist - so being able to see articles that have high "within last hour" activity instead of only new articles may be useful. — xaosflux Talk 18:08, 8 December 2023 (UTC)Reply[reply]
yep 100% agree @Xaosflux -- i'm working on getting us to within the last hour method you describe as we speak! FNavas-WMF (talk) 21:11, 8 December 2023 (UTC)Reply[reply]
I would go further and say that anyone who feels compelled to write about a news event on Wikipedia should look for existing articles to update rather than create a new one. This is an encyclopedia, not a newspaper. Phil Bridger (talk) 21:27, 8 December 2023 (UTC)Reply[reply]