Jump to content

Wikipedia:Village pump (idea lab)/Archive 56

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

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

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

I think everyone already knows what these things are. They’re the bane of Wikipedia. They’re pure fancruft magnets. They’re glorified trivia sections. They’re almost never cited, and when they are the citations are usually irrelevant. And yet sometimes established, respected users are willing to fight to the death to preserve even the most god-awful looking examples, like here. I think a great solution has already been figured out: if the topic of “x in fiction” is notable, it deserves a well written, well-sourced article like Venus in fiction. If there’s only a few notable examples, then they could just be written into a section like “history” or “impact”. But there is absolutely no reason we should have mundane, unvetted lists of things appearing in media or whatever else a person thinks counts as “popular culture”. So is it finally time to just ban any kind of “in popular culture” style cruft sections from articles? Dronebogus (talk) 11:12, 26 February 2024 (UTC)

Many "in popular culture" sections are as you describe, but some are OK, so I don't think a blanket ban is what is needed. I would rename even the good ones, however. There is no need for us to distinguish popular culture from "high" culture. Phil Bridger (talk) 11:41, 26 February 2024 (UTC)
There is some relevant guidance here: Wikipedia:Manual of Style/Trivia sections and a sensible essay here: Wikipedia:"In popular culture" content. I think we could usefully trim these sections (especially anything unsourced) rather than ban them outright. Barnards.tar.gz (talk) 11:43, 26 February 2024 (UTC)
I agree with that’s the common sense solution, but read the cringeworthy popular culture section at Ha-ha, then read the linked talk page discussion where you have some of the biggest names in Wikipedia defending it (MoS be damned), and explain how you would get around that without some kind of brute force ban. Dronebogus (talk) 11:56, 26 February 2024 (UTC)
Jane Austen's mention of the ha-ha seems like an excellent example of a legitimate in-popular-culture item, in that I can see numerous mainstream and academic sources linking the two (examples: [1] and [2]). It looks like your intervention resulted in a citation being added for it - so something is working. Barnards.tar.gz (talk) 13:12, 26 February 2024 (UTC)
I still think the others are terrible, and you could remove them and put Austen’s example somewhere better in the rest of the article, like at the end of the “examples” section with the beginning “in fiction, a ha-ha appears in Jane Austen’s…” blah blah blah. Why do we have the others? Because I wasn’t going to fight with three established users even when their arguments were poor and contradicted what is arguably well-established best practice. Dronebogus (talk) 13:18, 26 February 2024 (UTC)
They're not great. At a minimum, there needs to be sourcing to demonstrate that the reference has some significance, otherwise it's original research. Barnards.tar.gz (talk) 13:55, 26 February 2024 (UTC)
But apparently some big-name users think it’s cool, so it stays. I’m admittedly getting into conduct issues here, but if we really have people like Johnbod, a 270,000+ edit veteran, playing the WP:ILIKEIT card with this crap we need a hard rule against it. Dronebogus (talk) 13:59, 26 February 2024 (UTC)
Apologies for nitpicking: there needs to be sourcing to demonstrate that the reference has some significance, otherwise it's original research is not true. Original research == has never been published in any (reliable) source – anywhere in the world, in any language, regardless of whether a source is cited in the article or even known to editors. It is literally the "Dear Mr. Usenet personality, please don't put your unpublished 'proof that Einsteinian physics is wrong' garbage anywhere in Wikipedia" policy.
Sourcing that demonstrates "significance" helps us meet the requirements of WP:DUE and WP:BALASP.
Also, naming a source in the prose of the article is a type of Wikipedia:Inline citation. When the text says "Alice Jones said in her 2008 book, The Sun Is Really Big..." – or, in this case, "In Anthony Trollope's Barchester Towers, a ha-ha...", nothing is actually improved by adding a little blue clicky number afterwards that repeats the information already provided in the text. WhatamIdoing (talk) 17:19, 26 February 2024 (UTC)
OTOH, if the cite behind the "little blue clicky number" gives the specific page number and such, that can be useful. Anomie⚔ 17:51, 26 February 2024 (UTC)
For famous works, there are so many editions that a page number is likely to be useless. Page 127 in my copy won't match page 127 in your copy. WhatamIdoing (talk) 18:04, 26 February 2024 (UTC)
True, but for classic Victorian novels a chapter number is certainly useful. I suspect most templates don't allow them, another good reason for not using them. Johnbod (talk) 18:06, 1 March 2024 (UTC)
Template:Citation allows at in place of page or pages using text to specify a place in a source. Template:Sfn allows loc in place of p or pp for the same purpose. I have used those options a number of times for e-books and on-line journals that do not have page numbering. Donald Albury 20:26, 1 March 2024 (UTC)
{{cite book}} has |chapter= for this purpose. Of course, this all assumes that the content can be found on a single page/section/chapter. Sometimes you're citing a book for its whole contents: "Paul Politician published a book, Motherhood and Apply Pie, promoting his vision for the country's future". WhatamIdoing (talk) 00:31, 3 March 2024 (UTC)
That can often be overcome with a sufficiently precise citation (to a specific edition, or a specific print run, or whatever), but this is perhaps a digression from the main point which is that if we are going to claim that there is a significant (as opposed to trivial) mention of Subject A in Subject B, then a citation to Subject B as a primary source does nothing to prove the significance. We need at least a secondary source. Barnards.tar.gz (talk) 18:30, 26 February 2024 (UTC)
"Foo was mentioned in the 628th episode of The Simpsons" is not a claim of significance. Merely mentioning the existence of something is not inherently a claim of significance.
Many articles might benefit from setting some Wikipedia:List selection criteria that require exclusion of insignificant items, but merely saying that ____ was mentioned does not automatically require a secondary source that says it is significant. WhatamIdoing (talk) 18:40, 26 February 2024 (UTC)
Merely mentioning the existence of something is not inherently a claim of significance. It is in an article that complies with WP:DUE and WP:NOTEVERYTHING, where we must have a reason for including a piece of information beyond its mere existence. Absent such reason, including such statements amounts to the personal opinion of the editor. Barnards.tar.gz (talk) 18:56, 26 February 2024 (UTC)
Not really? The opening for most biographies gives the dates of birth and death, but we're not claiming that it's really significant that this person happened to be born on Octember 32nd.
A fact does not become an opinion merely because you don't (or someone thinks you don't) have a good reason to mention the fact. WhatamIdoing (talk) 01:35, 27 February 2024 (UTC)
There are two separate things here: the fact that A mentions B, and the inclusion of that fact in an article. The former is a plain fact, verifiable with a primary source reference. The latter is what amounts to an editor’s opinion if there’s no source with which to evaluate the due weight of the fact. Barnards.tar.gz (talk) 07:40, 27 February 2024 (UTC)
I don't think that's true, or that it's the community's view. If it were true, we'd have to ban all use of primary sources. WhatamIdoing (talk) 20:14, 27 February 2024 (UTC)
When including primary sources, policy requires us to take care. We are expected to have a good reason for including a primary source. “Cultural references” sections are a great example of why care is needed. When we can’t readily evaluate due weight, personal opinion is usually what remains. This is why the MoS calls for secondary and tertiary sources to support inclusion of cultural references. Barnards.tar.gz (talk) 07:52, 28 February 2024 (UTC)
WP:PRIMARY says we have to be careful how we use the primary sources that we are using. WP:PSTS says that articles overall need to be WP:Based upon secondary sources, which naturally puts a relative limit on the volume of primary sources in an article. However, no policy actually says that we have to have a good reason for including any given primary source (except to the extent that we usually have a reason for using [or for excluding] any reliable source).
The Manual of Style shouldn't be telling editors what kinds of sources to use at all. That's not a style question. WhatamIdoing (talk) 00:35, 3 March 2024 (UTC)
For what it's worth, WP:IPCV already discusses the need for sources that establish significance, and while that's part of an essay, it links to an RfC from 2015 that was closed with, "The consensus is very clear that a secondary source is required (emphasis theirs) in almost all cases. A tertiary source is even better, if available. In the rare case that a primary source is judged to be sufficient, it should be properly cited. The source(s) cited should not only establish the verifiability of the pop culture reference, but also its significance." I'm more than content to have that be the final word on the matter, and I've frequently used it as justification when deleting unsourced or non-secondarily sourced IPC content. DonIago (talk) 02:21, 3 March 2024 (UTC)
I've never been impressed with the closing statement for that RFC. There were 20 participants in the RFC, exactly one (5%) of them mentioned tertiary sources once. Not only did 95% of the participants not agree, the one person who did mention tertiary sources described it as "sourcing which establishes the notability of the connection", which is not what a tertiary source does. That's what a secondary source does. It's just nonsense to think that a dictionary or an index (both of which are tertiary sources) is better than a scholarly analysis (=secondary source) for the purpose of establishing the significance of a connection. We should treat that as someone accidentally using the wrong word, not as a real desire for tertiary sources. WhatamIdoing (talk) 19:57, 4 March 2024 (UTC)
I can't readily imagine an IPC-related circumstance in which I'd push for a tertiary source, but the RfC did set a precedent for requiring secondary sources. In any event, I certainly don't feel the need to revisit it, though if other editors feel it should be revisited, it is almost ten years old now. DonIago (talk) 21:22, 4 March 2024 (UTC)
Ignoring the dubious summary, most editors expressed support for "a source that shows significance", which can technically be a primary source such as an interview or an opinion piece (though not generally "the" primary source, i.e., the pop culture work itself).
As an example, a source that shows the significance of a film could be an interview with one of the actors in the film, saying something like "This film is really important because it's the first film produced by a major studio that cast two actors from Tiny Ethnic Group to play the lead roles". That would be primary, non-independent, and showing significance all at the same time. WhatamIdoing (talk) 23:11, 4 March 2024 (UTC)
I'd be content to let those kinds of edge cases be settled on their respective Talk pages, assuming they even became disputes to begin with. Typically in IPC situations the primary source being invoked is the media itself, and it's being invoked because the editor adding it doesn't realize/understand that a source is needed that establishes significance rather than merely existence. Anyway, the summary did carve out the possibility with, "in almost all cases". DonIago (talk) 02:13, 5 March 2024 (UTC)
No. They're always at the bottom of the page, which hardly any readers reach, and do no harm, perhaps usefully engaging younger readers and would-be editors. "Cultural references" is often a better header though, especially when eg operas are listed. Johnbod (talk) 13:35, 26 February 2024 (UTC)
Johnbod, I think I’ve extensively explained why your inexplicable support for these things is so disappointing to me, but now you’ve added even more very bad arguments for them— WP:HARMLESS? “Nobody sees them anyway”? “They’re for the kids”? “New users should be encouraged to add fancruft because it’s more fun than doing something actually constructive”? Dronebogus (talk) 13:41, 26 February 2024 (UTC)
Everyone has to learn how to edit somehow, and having new users screw up by adding unimportant information at the bottom of an article is probably better than having them screw up with important content. (Or maybe your first edits were all perfect? Mine weren't.)
Over the last couple of years, @DMacks and I have been adding citations to an article that has some significant lists (historical examples and cultural references). Mostly, this has involved clicking on the linked article, scrolling halfway down the page, copying the refs, and pasting them into the first article; it's appropriate and constructive work, but it's also not really important. I'd like to approximately halve the number of "Popular culture" entries (which includes Shakespeare and other classics, so it's not all "pop culture"), but I'm aware of my limitations here. I don't want to remove something just because I personally WP:NEVERHEARDOFIT. WhatamIdoing (talk) 17:58, 26 February 2024 (UTC)
My first contributions were uncontroversial copyediting as an IP, which I think is better than either “screwing up by adding unimportant information” or “screwing up with important content”. Dronebogus (talk) 18:45, 26 February 2024 (UTC)
Many people manage to screw up copyediting. There is no foolproof task. WhatamIdoing (talk) 01:36, 27 February 2024 (UTC)
Yeah. Many's the time that I've seem a newbie making good-faith spelling corrections of words like "centre", "traveller" and "colour". Or altering 27 February to 27th February. --Redrose64 🌹 (talk) 22:17, 27 February 2024 (UTC)
On the general question, I don't think we should ban them. I think we should figure out what makes a good section, and promote that as the goal, but I don't think we should ban them.
I find that the sections I find lacking usually look like this:
  • In the 639th episode of The Simpsons, a character pretended to have/do/be _____.
  • ____ was mentioned twice in the 2019 Box Office Hit.
  • A minor character in Popular Teen Book mentioned _____ in passing.
What I find less irritating is:
  • ____ was a major plot point in Classic Work.
What I find desirable usually sounds like:
  • Fairly Popular is generally recognized as the first significant representation of a character with _____.
  • Its appearance in Television Show changed public perception of _____ in the following ways...
  • ____ is usually misrepresented in popular culture, with cultural representations combining _____ with irrelevant and stereotypical features of Unrelated Subject.
For example: Shirley Temple publicly disclosed her breast cancer diagnosis on television, and the Breast cancer awareness movement was never the same again. Lucille Ball's on-screen pregnancy changed both television and the American public's perception of pregnancy. This is "In popular culture", but it's not trivia. WhatamIdoing (talk) 18:37, 26 February 2024 (UTC)
Pop-cult/In fiction/In art and culture sections and articles can be awful, and they can be ok. Start with removing everything without a decent independent cite (WP:PROPORTION) and you're off to a good start. Or try citing, sometimes there's good stuff in there. I have afd:d [3][4], made edits like this [5], started listicles like Christopher Marlowe in fiction and Cultural depictions of Belshazzar, and started sections like Shakespeare_authorship_question#In_fiction. Metatron#In_popular_culture was improved during a discussion at the talkpage. Someday I may start a William Shakespeare in fiction article (the person, not the writings). Gråbergs Gråa Sång (talk) 18:37, 26 February 2024 (UTC)
Some "in popular culture" sections are, or can be, sourced to high-quality or academic sources so, no, I don't think it is time to "ban" all such sections. Newimpartial (talk) 20:56, 26 February 2024 (UTC)

I think that they are always a problem. The heading is something which distorts the inclusion criteria. Like "the section is there, so we need to look for something to put in it." Also they are magnets for promotional and fancruft inclusions. BTW in a few cases they work in the opposite direction. There can be something truly worth including which gets minus points if it is under a "In popular culture" heading. If something is worth including, it doesn't need that heading. North8000 (talk) 18:07, 26 February 2024 (UTC)

They often do need looking after, but that's true about most things on this website. Gråbergs Gråa Sång (talk) 18:40, 26 February 2024 (UTC)
I feel that the phrase “in popular culture” should be replaced since it raises questions such as “What culture is ‘popular’?” 71.239.86.150 (talk) 01:58, 5 March 2024 (UTC)
Maybe the fact that they are magnets is actually doing us, as editors, a bit of a service, by encouraging people to put all of the IPC-related content in one place, where it can be more easily managed, versus trying to wedge it into other portions of articles, where it might be more easily overlooked? Which is to say, functionally I'm not sure how this proposal would work in execution. If we literally ban "In popular culture" sections, people who are sufficiently motivated will just create "Legacy" sections instead, or insert their preferred pop culture references into other sections of articles. If we try to ban IPC content in spirit then we're going to get into arguments over whether content falls under that ban, and we may end up removing material that demonstrates genuine cultural significance in the process. DonIago (talk) 05:55, 1 March 2024 (UTC)
@Doniago, thanks for this. I hadn't thought of it this way before, and I think you're right. WhatamIdoing (talk) 20:41, 2 March 2024 (UTC)
I usually am. ;p DonIago (talk) 02:12, 3 March 2024 (UTC)

If there are secondary sources describing something's effect in popular culture, then it warrants inclusion and our opinion that it's trivial isn't relevant. If the statements are cited to the work itself, then it should be removed and the person who added it should have WP:PROPORTIONAL and WP:PRIMARY explained to them. If someone keeps adding or restoring unsourced or primary-sourced examples, then explanations should escalate to warnings. Thebiguglyalien (talk) 18:51, 26 February 2024 (UTC)

What do you do if the person who added it should obviously, obviously know better? Dronebogus (talk) 18:56, 26 February 2024 (UTC)
...WP:DR? Gråbergs Gråa Sång (talk) 19:04, 26 February 2024 (UTC)

In addition to the concerns already noted above relating to primary sourcing (or none), and to the proliferation of trivia, I think it should probably be noted just how systemic bias, in multiple forms, is inherent in such sections. They aren't 'popular culture' in the abstract, but instead, almost without exception, the familiar 'popular culture' of the contributor, who sees a reference to something-or-other in their favourite TV show etc, and then looks for an article on said something to shoehorn it into. This reduces interaction with 'popular culture' to nothing but passive absorption and regurgitation of mass media. That isn't 'popular culture' as any sociologist would define it, it is merely a small and frequently uninteresting facet of it. Real culture ('popular' or otherwise) is something you interact with. Something you play with and subvert, something that both makes you who you are, and enables you to change yourself, and the culture you experience around you as you do so. Reducing it all to stuff seen on episodes of the Simpsons is an insult to the endless creativity of humanity. AndyTheGrump (talk) 19:11, 26 February 2024 (UTC)

I think you're getting a bit away from the question originally posed and into the definition of culture (popular or otherwise). My English culture involves queuing for buses but not in pubs (although informal self-policing usually means that people are served in roughly the right order), which is the reverse of many countries. They are far more important elements of my culture than my favourite TV show or computer game. Phil Bridger (talk) 20:19, 26 February 2024 (UTC)

There are entire academic journals devoted to this. A journal for Robert Louis Stevenson comes to mind. Every issues contains 100+ new entries - movies, plays, games, mentions, etc. It's called cultural studies. It's an academic field of study. It doesn't have preconceived pretensions about ignoring video games and the Simpsons. All culture is academically interesting, when you study culture. The only question is where to draw the line for an encyclopedia, since Wikipedia is not trying to be a complete record. -- GreenC 22:46, 27 February 2024 (UTC)

I am well aware of the field you describe. It does not in any shape or form revolve around creating random listings of appearances of something in something else, as typified by Wikipedia's so-called 'popular culture' sections. That isn't academic study. It imparts no useful understanding of any specific aspect of culture, and as raw data it is so utterly skewed by the narrow demographic and limited passive mass-media obsessed perceptions of 'culture' of those contributing it that nothing useful could come from an analysis of it. Whatever else Wikipedia is, is is undoubtedly not intended to be a means to amass data on 'popular culture'. AndyTheGrump (talk) 23:24, 27 February 2024 (UTC)
I believe the current policies, including the essay Wikipedia:"In popular culture" content, are adequate. Like it has been said before, while there are many bad examples on this type of topic, but there are also good ones which fit to Wikipedia's goals as an encyclopedia (and are a feature which distinguishes Wikipedia from more traditional encyclopedias). I oppose the suggested global ban of "in popular culture" sections and articles as that would throw out the baby with the bathwater. It is also my personal experience that bad "in popular culture" sections can still be helpful in writing good ones if one is willing to put in the effort to improve them. Such, the overall process of Wikipedia to slowly build up and improve (even niche) content should be upheld also for "in popular culture" content. Daranios (talk) 11:52, 1 March 2024 (UTC)
My take on the matter is:
1) People like to write them
2) People like to read them
3) People who don't like to read them don't have to
4) So why not concentrate on doing things that you like to do rather than worrying about people doing things that they like to do. Herostratus (talk) 15:13, 1 March 2024 (UTC)
(Replying to Herostratus) That’s a weak argument. “Don’t like don’t read” is not compatible with Wikipedia— if everyone thought that way, Wikipedia would be balkanized into 500 different websites with completely different rules because nobody would be allowed to just say “no, this is not how things should be run”. Dronebogus (talk) 15:42, 1 March 2024 (UTC)
I don't think so? There's plenty of content here that I have no interest in reading, and my solution is: I just don't read it. That includes whole topic areas (e.g., almost anything about BLPs or sports) and sections of articles (e.g., almost all of the pop culture sections). I can do that without balkanizing Wikipedia at all. WhatamIdoing (talk) 20:49, 2 March 2024 (UTC)
Yes and no—there's no question that the presence or absence of certain content in itself matters somewhat, that's what WP:NPOV revolves around. I'm pretty pro-cap, though I understand this isn't universal: articles get mechanically and mentally harder to read the longer they are, and the more cruft there is interpolated throughout. I don't go about actively removing borderline-WP:UNDUE trivia sections while I'm copyediting, but if I were trying to get an article to FA, I would start with that. If that's my particular fixation on a certain notion of what an encyclopedia should be, then I can live with that. Remsense诉 02:32, 3 March 2024 (UTC)
I have some concerns about long-form articles, even though I write them myself. But I've seen a problem recently with Wikipedia:Splitting as a way to control article size: We split Blenheim Palace in film and media off from Blenheim Palace because there's too much pop culture; then we send the split to AFD because someone thinks the split is not a valid article; when it's (inevitably) kept, the people who disagree with its existence blank half the content, including cited content – and then complain that there aren't enough sources. WhatamIdoing (talk) 20:09, 4 March 2024 (UTC)
It's a sticky wicket. Here's an idea I've thought nothing about but will just throw out there: why don't we entertain allowing subpages in article space? Say, there's a 'subpage manager' permission that allows their addition or configuration so that trivia sections don't become trivia articles/TVTropes 2.0, but they're considered in terms of the larger topic in terms of notability, and are explicitly not standalone, while the main articles should remain so. Remsense诉 20:48, 4 March 2024 (UTC)
If content isn’t notable it shouldn’t have so much text it needs a subpage. If it is notable and has too much text in one article it should have its own article. A subpage is a middle ground that doesn’t need to exist because there’s no situation where it could exist under broader policy and simple common sense. Dronebogus (talk) 20:52, 4 March 2024 (UTC)
See, that is how I presently operate, I hate the categories but I am in some sense a "deletionist", but I think there's a real case here: the issue is that articles are limited to one linear page. I agree that content should be exactly as WP:DUE as it's always been, but I think a stumbling block is that text can seem undue if it's actually just...difficult to fit into an article? Which would make it worth excising if we were writing novels where linear engagement is expected, but the more I think about it, the more I think having "cut-out" subpages for content in specific circumstances could improve the encyclopedia. Remsense诉 21:00, 4 March 2024 (UTC)
I do like this idea a lot, and I believe that these cases can occur and are not at all against common sense, even though there may not be a huge number of them. I fear a little about how to spell this out and add another level of complexity to the already complex jungle of Wikipedia policies and guidelines, though. Daranios (talk) 21:06, 4 March 2024 (UTC)
We are in agreement on that much. Remsense诉 21:28, 4 March 2024 (UTC)
If content isn’t notable it shouldn’t have so much text:
"Content" isn't supposed to be notable; notability is for topics. :-D
Notability, fundamentally, means "topic other editors agree to have a separate article about". That's why the notability guideline says things like Editors may use their discretion and Editorial judgment goes into each decision and We require editors to use their judgment about how to organize subjects. In this instance, the split article was kept at AFD. Kept at AFD == notable, as far as Wikipedia is concerned. But now what? Some editors don't want that kind of information anywhere in Wikipedia. If you think it's garbage, then you will try to get rid of it. WhatamIdoing (talk) 23:21, 4 March 2024 (UTC)
I think you’re trying to make this sound vaguer than it really is. Notability by and large means “reliable secondary sources exist covering a topic in depth”. It’s not really up for debate. There are borderline cases, but I don’t think anyone questions that basic premise. By extension, content should be notable information about the topic. If it’s not essential, objective information (like a plot summary of a film or what a bird looks like) then it’s not up to editors to decide whether it’s notable— it needs secondary sources. Dronebogus (talk) 01:44, 5 March 2024 (UTC)
That's how Wikipedia operated 20 years ago. It was removed for a bunch of reasons, including that it created artificial and often arbitrary dependencies (an example used was: should "History of Algeria" be a subpage under "History" or "Algeria"?)
Incidentally, it was replaced by a lot of the systems we presently use (namespaces, categories, disambiguations, splits). Chaotıċ Enby (talk · contribs) 09:32, 5 March 2024 (UTC)
See, I had the vaguest notion that was the case since I've seen ancient pages that used to be subpages. But yeah, I guess a bureaucratization of this potential problem may not solve it. Remsense诉 09:34, 5 March 2024 (UTC)
A part of what makes Wikipedia valuable is it's selectivity. There's already another place available that doesn't have that. The internet.  :-) North8000 (talk) 20:09, 4 March 2024 (UTC)
A lot of people would say “TVTropes is for fancruft”, but even TVT bans mundane mentions/appearances of things in pop culture— this is referred to as “people sit on chairs”. IMO, Wikipedia’s fancruft is mostly people sitting on chairs, which is not informative or useful to anyone, anywhere. It’s just an annoying faux-contribution by people who don’t want to do actual research. Dronebogus (talk) 20:12, 4 March 2024 (UTC)
Why stop there? Why not just ban all Wikipedia coverage of popular culture? Why have an article on The Simpsons at all, it's just a TV show. It's not as though popular culture is of any real-world importance, or has any impact on people. BD2412 T 22:41, 4 March 2024 (UTC)
That's not really what anyone is trying to say. "Popular culture" is a misnomer here, "trivia" is a little better, but perhaps not much. Remsense诉 01:08, 5 March 2024 (UTC)
Either BD2412 is making a modest proposal (likely), or is being genuinely elitist against all “popular culture” (unlikely). Either way, their comment is not helpful since it misconstrues the entire topic of this discussion as being about “popular culture” as a whole and not a type of section dominated by fancruft. Dronebogus (talk) 01:35, 5 March 2024 (UTC)
"Pop culture" sections, controversy sections, and similar sections that are regularly scrutinized are useful to the reader. GrammarDamner how are things? 15:20, 5 March 2024 (UTC)
The "regularly scrutinized" part is key here, and a stronger application of MOS:POPCULT would be more welcome. Chaotıċ Enby (talk · contribs) 17:28, 5 March 2024 (UTC)
The "useful to the reader" part is key here. Far too often, useful information is removed from articles by editors who prefer wikibureaucracy to helping the reader. GrammarDamner how are things? 20:03, 6 March 2024 (UTC)
I absolutely agree with this too, and one doesn't prevent the other. We can both check for quality/sourcing while not removing information just because we don't find it personally helpful.
On the other hand, things that are completely unverifiable should be removed (WP:ITSUSEFUL doesn't supersede WP:Verifiability), but that's a small part of these sections' contents and shouldn't be used as an excuse to remove everything else. Chaotıċ Enby (talk · contribs) 23:18, 6 March 2024 (UTC)
The proposal as made throws out the baby with the bathwater, and merits a "modest proposal" response. BD2412 T 16:56, 5 March 2024 (UTC)
We're in the lab, though. ⚗️ We'll just fabricate another specimen. Remsense诉 16:57, 5 March 2024 (UTC)
WP:Trivia sections are already disallowed, so why allow them under another name? We already have MOS:POPCULT regulating pop culture sections, which calls for curation and a strong sourcing requirement to avoid them becoming trivia lists. Chaotıċ Enby (talk · contribs) 17:28, 5 March 2024 (UTC)
  • Our entire website is a collection of stuff which constitutes excruciatingly uninteresting trivia to 99% of people; this includes the typical stuff like Anelosimus eximius, but also Second Punic War. Go ahead and poll 100 random people on the street in re whether they give a hoot about Chester Arthur -- the result will be disappointing and enlightening. I think that people who talk about 'trivia' fail to recognize the extent to which Wikipedia editors are nerds; if we simply adopted a policy to 'delete all of the boring crap for obsessive nerds', under any reasonable interpretation, we would become a celeb gossip site with no other content. jp×g🗯️ 19:22, 5 March 2024 (UTC)
    ...that's not at all what was suggested. The proposal isn't to delete "all of the boring crap" or even "all of the pop culture stuff", it's about not having them in unstructured trivia-like sections, which often have some irrelevant or non-notable stuff along with it. There's no reason why it shouldn't have the same threshold as any other content.
    Again, when we say "trivia", it's not an opinion on the content itself, but on the way it is (un)structured and presented, as described in WP:Trivia. That's the issue. Chaotıċ Enby (talk · contribs) 19:34, 5 March 2024 (UTC)
    Unstructured trivia-like sections are candidates for cleanup and structuring, not for blanket removal. BD2412 T 21:23, 5 March 2024 (UTC)
    I tend to agree with this, but in either case we shouldn't have these kinds of unstructured sections. Of course rewriting and structuring is better than removing potentially relevant content, which is a pretty important thing to keep in mind. Thanks for the addition! Chaotıċ Enby (talk · contribs) 23:36, 5 March 2024 (UTC)
    There is content that can should remain until reworked, as it is a net benefit to the article, and there is content that should probably be removed pending reassessment, and can be retrieved from the page history if need be. That line is in a different place for everyone, but it's worth remembering "deleting" is potentially easier to justify than remaining in this particular way—especially if one makes a habit of briefly looking at a page's edit history. We generally don't do that, but I think it should be a habit more people should get into. Remsense诉 20:08, 6 March 2024 (UTC)
    That has nothing to do with anything. Not to mention rather insulting to both readers and editors. It’s like saying Chewbacca isn’t from Endor, so Pop culture cruft lists are valuable. Dronebogus (talk) 21:00, 5 March 2024 (UTC)

xkcd referenced Wikipedia's tolerance of “in popular culture” sections in Comic #446 on 7 July 2008[6]. Certes (talk) 10:28, 7 March 2024 (UTC)

I'd call that satire, rather than 'reference'. It does well to illustrate the issue though. It would be absurd to list the appearances of something as common as wood in 'popular culture', so we don't. Instead, we compile such lists for an arbitrary self-selected subset of topics, with absolutely nothing in the way of sourcing to suggest that such topics merit it. AndyTheGrump (talk) 11:12, 7 March 2024 (UTC)

Changes to Wikipedia:Arbitration/Policy#Ratification and amendment

Currently, Wikipedia:Arbitration/Policy#Ratification and amendment says:

Once adopted by the Committee, this policy will undergo formal ratification through a community referendum and will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this policy is ratified, the existing arbitration policy remains in effect.

Amendments to this policy require an identical ratification process. Proposed amendments may be submitted for ratification only after being approved by a majority vote of the Committee, or having been requested by a petition signed by at least one hundred editors in good standing.

The Committee is responsible for formulating its own processes and procedures under this policy, which do not require ratification.

I think it should be retitled to "Amendments" and revised to say something like:

Proposed amendments to this policy may be submitted for ratification by a majority vote of the Committee or a petition signed by at least one hundred editors. Once submitted, an amendment will undergo formal ratification through a public referendum. The vote will last for thirty days, and is successful if it receives majority support with at least one hundred editors voting in favour.

The Committee is responsible for formulating its own processes and procedures under this policy, which do not require ratification.

The substantive difference is that the community would be able to reject changes. The current situation reminds me of the Corwin Amendment, in that things should really have an expiration date. If a change needs to be proposed again, someone can start a fresh petition.

Less important changes of the while-we-are-updating-the-section variety include:

  • Removing the spent enactment for ratification
  • Removed the nebulous reference to "good standing" (like a recent change at ACERFC2023), because site blocked/site banned/topic banned from Arbitration/etc. editors are already unable to sign a petition
  • Clarifying that the ratification vote is public (WP:ACE uses SecurePoll, so I think it is worth clarifying)

Thoughts? Different ideas? HouseBlaster (talk · he/him) 23:13, 2 March 2024 (UTC)

It would be good to look at amending the required level of support, as was discussed during the last amendment proposal. I'm not certain if it's necessary to mandate a public referendum. The most appropriate method can be decided at the time. isaacl (talk) 02:22, 3 March 2024 (UTC)
Struck the line about being public; I agree. As for threshold, I feel like that would be bundling two major questions into a single proposal (which is not to say that it shouldn't be considered separately). I feel like there is a difference between gnomish updates and major changes. HouseBlaster (talk · he/him) 02:57, 3 March 2024 (UTC)
I don't think this proposal is that major; it reflects standard procedure for English Wikipedia discussions. Some commenters in the previous discussion felt that altering the threshold was too minor for a standalone proposal, and were considering bundling it with another proposed change. As your proposal is in the same area, it feels like a suitable one to combine with. isaacl (talk) 05:00, 3 March 2024 (UTC)
Again, good point. The proposal process is terrible for finding compromises, given that it requires a finalized proposal followed by an up-or-down vote. Therefore, I think having a straw poll to get to a sense of what threshold people think would be appropriate is the best way forward, before turning that into a concrete proposal. Personally, 2/3 seems a little high; maybe 60% to match the requirement for a two-year term at WP:ACE? HouseBlaster (talk · he/him) 03:53, 4 March 2024 (UTC)
@HouseBlaster I've done a fair amount of work in this area at User:Barkeep49/ARBPOL amendment sandbox. The change I had landed at when it looked like ArbCom might vote on a couple of different amendments last year was:

Once adopted by the Committee, this policy will undergo formal ratification through a community referendum and will enter into force once it receives majority support, with at least one hundred editors voting in favour of adopting it. Until this policy is ratified, the existing arbitration policy remains in effect.

Amendments to this policy require an identical ratification process. Proposed amendments may be submitted for ratification only after being approved by a majority vote of the Committee, or having been requested by a petition signed by at least one hundred editors in good standing with-in 30 days. A proposed amendment will enter into force once it receives majority support, with at least one hundred editors in good standing voting in favour. Ratification votes must run for at least 7 days and may not run longer than 30 days.

My priority is to avoid "Zombie" amendments hence adding a timeframe for the 100 signatures as well as for adoption. The time frame for approval was trickier. Arbcom amendments have not traditionally done full 30 day amendments and it has worked. In case of an ArbCom that has gone off the rails I think it's actually incredibly important for the community to have a check that doesn't require 30 days of time which is why I landed on minimum of 7 maximum of 30. But despite the fact that ArbCom amendments haven't required 30 days in the past, and this hasn't been controversial, I know some don't like the 7/30 idea so I'm pretty open to other ideas, even if it means the community loses (what I see as an important) check on the committee. Best, Barkeep49 (talk) 03:56, 4 March 2024 (UTC)
I agree that the rapid amendment process is an important check on the committee. Perhaps we keep a 50%+1 threshold for a proposal to pass after 30 days, but allow an early closure if it receives some supermajority after 7 days? I really like the "rolling" quorum idea. Maybe 7.5%? There were 1,591 votes last ACE, and 120 editors seems about what we are aiming for. 160 seems a little high. HouseBlaster (talk · he/him) 04:12, 4 March 2024 (UTC)
Personally I prefer that concept myself. But I also think it's complicated and my worry is that adding complications sinks the whole amendment which is why I stuck with just 100 and went with 7/30 as the simplest way to balance those things. Barkeep49 (talk) 04:14, 4 March 2024 (UTC)

I think framing it as a WP:SNOW closure would aid in making it less complicated. Something like Ratification votes must run at least 7 days and may not run longer than 30 days. After 30 days, a proposal is successful it it receives majority support with at least 7.5% of editors at the last annual ArbCom election voting in favour. Ratification votes may only be closed before the 30-day mark if supported by at least two-thirds of editors, with at least 7.5% of editors at the last annual ArbCom election voting in favour.

On a slightly different subject, looking at WP:ARBPOL, I think the line about MedCom can go. HouseBlaster (talk · he/him) 14:39, 4 March 2024 (UTC)

Conceptually do I like that? Yes. But I don't think it should be what's proposed. It adds too much complexity in a way that will draw opposition and sink the whole concept. I've been advocating for this sort of change for 3 years and been waiting for the right moment to propose it which has allowed me to talk to a number of people along the way about it, not just on the talk page. But on the talk page you can see the way getting consensus over this is going to be hard. Barkeep49 (talk) 14:45, 4 March 2024 (UTC)
30-->90 seems more reasonable for the petition timer. — xaosflux Talk 14:45, 4 March 2024 (UTC)
Why? What process do we have that runs 90 days? I can't think of any. Barkeep49 (talk) 15:51, 4 March 2024 (UTC)
:cough: :cough: :cough: :cough: — xaosflux Talk 16:26, 7 March 2024 (UTC)
Neither are RfCs nor ArbCom cases are designed to run 90 days. They might run 90 days but they're not designed that way. Barkeep49 (talk) 17:34, 7 March 2024 (UTC)
Well you asked "that run" not "that are designed to run".... Moving from indefinite->90 seems like a reasonable first pass though; the goal of a limit is to not have zombie petitions. — xaosflux Talk 19:36, 7 March 2024 (UTC)

Urging people to register an email account

I just read yet another sad case of a productive editor who lost access to their account because they lost the password and didn't have an email address registered so they couldn't recover it. What would people think about a bot which looked for accounts that don't have email registered and dropped them a message on their talk page explaining the risk of not being able to recover a lost password and how to fix that? We'd probably want some filter criteria like only doing it for accounts which have been active in the past N days and only sending a reminder once per year. RoySmith (talk) 17:02, 13 February 2024 (UTC)

Maybe we should start with a watchlist notice or a sitenotice that displays only to extended-confirmed editors. I don't know whether the sitenotice can be controlled according to whether e-mail is registered, but perhaps that's not terribly important. Some of us may have invalid/outdated e-mail addresses.
As for making a list for personal messages, we could consider 500+ or 1,000+ edits and perhaps 1+ years old, or anyone with "advanced" user rights. Maybe it would be worth excluding the handful of people who have an e-mail address registered at another SUL-connected wiki (but disabled here).
Have you thought about Echo/Notifications messages? It's also possible to send to any list of individuals. That would be more private for the notified people and less potentially annoying to the people watching their pages. Once we've dealt with the backlog, it's possible to have an automatic trigger for a notification when a milestone is reached. Wikipedia:The Wikipedia Library congratulates people on reaching 500 edits. Maybe when you reach a certain level, it could suggest making sure that an e-mail address is set in your prefs. WhatamIdoing (talk) 17:44, 13 February 2024 (UTC)
Have you considered to edit milestones notifications locally? Trizek_(WMF) (talk) 17:51, 13 February 2024 (UTC)
I like the idea of this being a notification, for all the reasons WhatamIdoing pointed out. RoySmith (talk) 18:09, 13 February 2024 (UTC)
"Has email" isn't something I think we can determine publicly, but for most people "Is emailable" (which can be determined) is good enough - we could MMS ("is NOT emailable" AND "in some group") I suppose. — xaosflux Talk 21:19, 13 February 2024 (UTC)
I'm assuming whatever causes the "Email this user" link to show up in the sidebar is the same thing that allows you to do an account recovery, no? RoySmith (talk) 21:48, 13 February 2024 (UTC)
That's what he means by "is emailable". The user has to not deselect "allow emails from other users" for that link to show up. Aaron Liu (talk) 22:13, 13 February 2024 (UTC)
Worth highlighting phab:T58362 here which enables bots to send notifications to users for a community-defined usecase like this. The ticket is waiting on code review. – SD0001 (talk) 21:56, 2 March 2024 (UTC)
@SD0001 Thanks for linking that! I'm assuming that you are aware of how that gerrit patch failed testing last September and has never been updated since? Aaron Liu (talk) 23:37, 2 March 2024 (UTC)
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/928980 is the currently active patch which is not failing any tests. – SD0001 (talk) 05:41, 3 March 2024 (UTC)
Ah, so there were multiple patches. Thanks. Aaron Liu (talk) 14:47, 3 March 2024 (UTC)
What about people who know they could do that but don't want to? 🌺 Cremastra (talk) 22:30, 13 February 2024 (UTC)
I envision that they'll get one reminder and there will be a way to opt out of additional reminders. RoySmith (talk) 22:35, 13 February 2024 (UTC)
Or, we only add it to the 500 edits milestone and maybe the 5000 (or the 10000) one, and foresake any further warnings. Aaron Liu (talk) 23:55, 13 February 2024 (UTC)
(Wikipedia:The Wikipedia Library is a 500-edit milestone, so I think we should pick a different round number.) WhatamIdoing (talk) 03:34, 16 February 2024 (UTC)
Why not both? Aaron Liu (talk) 12:33, 16 February 2024 (UTC)
Because if you get one message in January, and a different message in February, you're more likely to take action on both of them than if you get both at the same time.
Also, do we really want to wait for 500 edits? Why not show this suggestion sooner? WhatamIdoing (talk) 22:29, 16 February 2024 (UTC)
I don't see why that'd be the case, especially since both messages are short.
Maybe 100? Aaron Liu (talk) 22:57, 16 February 2024 (UTC)
There are milestone notifications for the 1st, 10th, 100th, 1,000th (etc.) edits. There is a WP:TWL notification for the 500th edit. We should pick a number that isn't already being used. Maybe 150? WhatamIdoing (talk) 01:20, 27 February 2024 (UTC)
I don't see why we should pick a number that isn't already being used. Aaron Liu (talk) 02:31, 27 February 2024 (UTC)
I repeat: Because if you get one message in January, and a different message in February, you're more likely to take action on both of them than if you get both at the same time.
This is because people are easily distracted. They say "Ooooh, I wanna play with the new shiny toy" and when they toddle off to do this, they forget that the second message existed (and the Notifications icon is no longer red, so they get no reminder, either). WhatamIdoing (talk) 20:06, 27 February 2024 (UTC)
But the milestones don't tell you to do anything either. Aaron Liu (talk) 21:51, 27 February 2024 (UTC)
I lost my initial account, User:Union Tpke 613, since I was not yet old enough (13) to get a gmail account, and thus didn't link it to an email. Kew Gardens 613 (talk) 06:46, 16 February 2024 (UTC)
We could require an email address or a phone number to finish registration. It would also make enforcing sockpuppetry easier, since it is much more involved to get a new phone number (at least in the United States). We could also disallow VoIP services like Skype and throwaway email services as well. It would also give the case for SMS based authentication. Awesome Aasim 20:23, 7 March 2024 (UTC)
There are a lot of privacy people who are against that. See criticism of Signal. Aaron Liu (talk) 20:29, 7 March 2024 (UTC)
We could require an email address or a phone number to finish registration. Hell no. Registration numbers would plummet more steeply than Mount Thor and many productive editors would resign on principle. Sorry, but I can't articulate how bad an idea I think this is. Please do not do this. 🌺 Cremastra (talk) 20:43, 7 March 2024 (UTC)
I agree. I walked away from a registration flow recently when I forced me to give a valid email address or phone number. Even if we ignored the (very real) privacy concerns, it would do very little to prevent socking. Folks who are serious about socking will just use throw-away email addresses to verify their throw-away wiki accounts. RoySmith (talk) 21:08, 7 March 2024 (UTC)

Providing public rationale for speedy deletion

I feel like it could be beneficial to editors looking to recreate a page that was previously speedily deleted for them to see rationale from the remover to help them better understand why they might not want to recreate it. This wouldn't be a requirement for performing a speedy deletion, though, and should probably be separate from the existing rationale parameter. Kolventra (talk) 00:56, 9 March 2024 (UTC)

Isn't this already done? When creating a page that was previously deleted (or even just viewing it), you see the deletion log in a red box above the editing area (or under the exclamation mark button in visual editor), which includes the deletion reason. Aaron Liu (talk) 01:35, 9 March 2024 (UTC)
No, the deletion log only shows under what criterion it was speedily deleted, but not anything the deleter gives as rationale. In my case, I deleted a redirect page with the criteria that I was the author requesting removal, as no other criterion matched what my purpose was as closely, so I wanted to provide a little more in-depth of a reasoning for the deletion. Kolventra (talk) 01:56, 9 March 2024 (UTC)
WP:G7 is author-requested deletion. When further explanation is needed, it'd also be given in the deletion log. Aaron Liu (talk) 02:17, 9 March 2024 (UTC)
Back when I was in the business of handling CSD requests, I sometimes put an extra sentence in the deletion log entry to explain more fully why a CSD criterion applied. Jo-Jo Eumerus (talk) 09:14, 9 March 2024 (UTC)

When deleting a page through the speedy deletion process, please specify the reason for deletion in the deletion summary, so that it will be recorded into the deletion log.
— Wikipedia:Criteria for speedy deletion § Procedure for administrators

Aaron Liu (talk) 14:09, 9 March 2024 (UTC)

Citations on policy pages

Have we ever discussed the merits of including citations on policy and guideline pages, pointing to the talk page sections that influenced the current wording? We have the equivalent of this on WP:RSP, which I think is quite useful. Barnards.tar.gz (talk) 08:19, 3 March 2024 (UTC)

That's already in place in some places such as WP:ITNR. It'd be needed to convert all existing footnotes under the note refgroup, though. Aaron Liu (talk) 14:49, 3 March 2024 (UTC)
Too complex… there are sections of policy that have had dozens discussions over the years, each of which has influenced what we see today. We would have to have a long chain of “citations” for each sentence (and sometimes even for specific words). Blueboar (talk) 15:00, 3 March 2024 (UTC)
We could use it for simpler sections. Aaron Liu (talk) 15:35, 3 March 2024 (UTC)
Having it for some but not others will result in wikilawyers claiming that the rule they dislike isn't "really" true; linking many discussions will be used as proof that it's "repeatedly contested".
RSP is different because it's meant to be a handy summary of prior discussions, rather than a rule itself. There shouldn't be anything in RSP that can't link to at least two prior discussions (a source that's only been discussed once, or never, isn't "perennial").
If you're interested in the general subject, you might like reading the history section of Wikipedia:Core content policies. WhatamIdoing (talk) 23:05, 4 March 2024 (UTC)
We could use WP:BUNDLING to reduce the visual clutter, and perhaps passages which have had dozens of discussions are exactly the ones where a collation of all that history would be very useful. Barnards.tar.gz (talk) 19:18, 3 March 2024 (UTC)
I've suggested it before on the talk page for Wikipedia:Policies and guidelines. I agree there are challenges in making these annotations, and don't think it's worth the effort to do it in retrospect for most situations. (The primary exception I can think of is when the provenance of a given passage is questioned, and the groundwork is done to trace it back. At that point, adding a reference is the simple part.) When it's easily added for a new change, though, I think it's worthwhile in order to help put the change into context in future. isaacl (talk) 19:33, 3 March 2024 (UTC)
I'm in favor of the idea in principle, but the implementation sounds non-trivial. If there is a push for this I would be happy to help with the efforts. spintheer (talk) 18:23, 5 March 2024 (UTC)
I think we already do this to some degree for some of the more contentious PAGs (you can see the footnotes on every PAG page), but we aren't consistent. While I think citations may be useful (I know some newer WikiProjects/taskforces do this), digging through years of discussions to retroactively "cite" high-traffic PAGs may not be feasible. InfiniteNexus (talk) 18:34, 5 March 2024 (UTC)
No doubt it would be a lot of work. But then, working through massive backlogs is something we do all the time. Perhaps a good place to start would be to take a look at the last RfC which touched policy or guideline wording, and mock up what a citation to it would look like. Barnards.tar.gz (talk) 19:30, 5 March 2024 (UTC)
A simple <ref> linking to the discussion would suffice, or an efn that says something like "See the following discussions: [1] [2] [3]". InfiniteNexus (talk) 19:35, 5 March 2024 (UTC)
For an interesting example of what this could (probably, kinda) look like, take a look at WP:ACERULES, which uses quite a lot of <ref>s to link to the RFCs where the rules were decided. --rchard2scout (talk) 14:54, 11 March 2024 (UTC)

Special period advertising sister projects

  • Proposal: Launch a multi-week campaign in some format (e.g. more prominent links on the Main Page, banners, or any other ideas you have) that encourages en.wiki readers to explore and possibly contribute to our sister projects. (e.g. Wiktionary, Wikisource, Wikifunctions)
  • Why? Quite simply, sister Wikimedia projects have a lot to offer readers, and as one of the most viewed sites on the internet (globally!) we should help introduce readers to these resources. As you know, other Wikimedia projects include a dictionary/thesaurus which includes translations; a travel guide; a library of digitized public domain texts that anyone can download or distribute; a travel guide; a media repository; and many others. The sister project links are currently buried far down on the Main Page, and are especially distant for mobile viewers who make up an increasing share of our readership. Why would we not want to help readers discover some of the useful resources our sister projects have to offer?
  • I am conscious this proposal is extremely unlikely to succeed or even make it to the RfC-at-VPPR phase, if only because it's either too drastic a change (it isn't!) or because Wikipedia is infected with the conceit that it is the primary and greatest Wikimedia project and shouldn't lift a finger to help smaller ones (In 2024, we are the seventh most-visited website in the world. We're fine. Adding a few links is not going to cause en.wiki's readership to collapse.)

Happy editing, 🌺 Cremastra (talk) 21:17, 27 February 2024 (UTC)

I like the idea of promoting, but one question is, indeed, how. I'd suggest just using a banner.
As a tangent, I really don't feel compelled to contribute to Wikifunctions as long as we can't invoke these functions anywhere else. Aaron Liu (talk) 21:55, 27 February 2024 (UTC)
Banners are probably the best option (and I have a couple of ideas on that front)
Continuing the tangent: yeah, nobody seems to be breaking down the door to get at the free python functions. I guess the eventual plan is to implement wikifunctions in sister projects, i.e. in modules, in the same way that wikidata supports some infoboxen. 🌺 Cremastra (talk) 21:58, 27 February 2024 (UTC)
I've drafted a few sketchy ideas here. 🌺 Cremastra (talk) 16:44, 28 February 2024 (UTC)
I'd 1. Remove the serif style and make the button look like Wikipedia's buttons 2. Add a bit of padding inside around the border 3. Link to the "welcome, wikipedian" templates or guides Aaron Liu (talk) 17:40, 28 February 2024 (UTC)
  1.  Partly done I like the serif font for the names; but this is an aesthetic issue at the end of the day
  2.  Done
  3.  Not done Only a small percentage of readers are Wikipedians.
🌺 Cremastra (talk) 18:25, 28 February 2024 (UTC)
Sounds good. Maybe make "ikisource" in smallcaps to match the wordmark? Aaron Liu (talk) 18:47, 28 February 2024 (UTC)
Probably, we can change the statistics given in bold and instead write
• Wikisource : Unlock the Library of Free Knowledge!
• Wikitionary : Your Gateway to Words and Meanings!
I think readers who have never edited will not be encouraged to contribute to our sister projects; the lines will make them curious to open up the projects and will casually make them fall into the rabbit hole. Harvici (talk) 15:17, 7 March 2024 (UTC)
These taglines are pretty corny (sorry) and too long. I don't think taglines like "the free encyclopedia" will make one any more likely to contribute. Aaron Liu (talk) 16:01, 7 March 2024 (UTC)
But wouldn't the lines attract readers to the projects, and while going through many pages wouldn't the readers be able to contribute to the pages they deem incomplete? Harvici (talk) 17:27, 7 March 2024 (UTC)
I don't think the lines would attract any more people, and readers would go through some pages anyways regardless of the tagline. Plus, Wikisource and Wiktionary aren't the kind of stuff one'd conventionally be able to wander through, unlike Wikipedia. Aaron Liu (talk) 17:31, 7 March 2024 (UTC)
I agree with Aaron Liu on this one. Let's go with what Wikimedia does well: quiet, sober, thoughtfulness. 🌺 Cremastra (talk) 20:45, 7 March 2024 (UTC)
I would definitely support a multi-week campaign, but also some way to more effectively link to other projects permanently. For example the Wikivoyage article for "Australia" is not accessible from our article Australia at all on mobile and rather obscurely linked from desktop. If the campaign is successful we need to back it up after it is done. Commander Keane (talk) 03:01, 29 February 2024 (UTC)
While I'm not against Wikivoyage, personally I'm against linking articles to Wikivoyage as it is by definition quite opinionated. That said, you can use the template {{wikivoyage}}. Aaron Liu (talk) 03:14, 29 February 2024 (UTC)
I was wrong, you can access the Wikivoyage article from mobile on Australia if you expand External links and then expand In sister projects. As to the general proposal for a campaign, Aaron Liu do you support Wikivoyage banners as long as they don't specifically link to particular Wikivoyage entries? Commander Keane (talk) 03:28, 29 February 2024 (UTC)
Yes. Aaron Liu (talk) 12:04, 29 February 2024 (UTC)
@Theklan might have some ideas about this. WhatamIdoing (talk) 20:58, 2 March 2024 (UTC)
Well, yes, there are some things that can be done, like adding a link below the main image of articles to point to Commons (look at eu:Txinpantze), or adding Wikisource links inline (eu:Txantiloi:Wikiteka-lotura). Visiblity could come directly in the Vector style, with links to the sister projects below the title. But this proposal was dismissed by the WMF (T287609#7384679) and any alternative is also blocked (T328077). Theklan (talk) 08:22, 3 March 2024 (UTC)
We already have it under the portlet's "In other projects" when applicable. This is about something to just generally advertise these sites, not links on specific pages. Aaron Liu (talk) 14:46, 3 March 2024 (UTC)
I wouldn't mind doing something to raise awareness of other projects, but we should make sure that it is unobtrusive. The constant fundraising banners that readers see have gotten worse and worse in recent years. In 2009, even the WIKIPEDIA FOREVER fundraiser banner was seen as garish and widely panned in tech press, in addition to having a petition circulated to remove it. Every year they've just gotten more obnoxious, including these examples from 2022. If we do something, we should keep it simple, small and unlikely to disrupt the reader experience. The WordsmithTalk to me 17:20, 7 March 2024 (UTC)
Oh yeah, the fundraising banners suck (and the WMF seems to be deaf to our hints about them). I was thinking something similar to the banners advertising, say, the steward elections. 🌺 Cremastra (talk) 20:46, 7 March 2024 (UTC)
I'm all for it as long as it's not super intrusive vghfr, harbinger of chaos 03:01, 12 March 2024 (UTC)

Goldlock WP:IAR?

There's really no reason for people to be editing it. 2003 LN6 23:29, 5 March 2024 (UTC)

Not seeing a reason to edit it is not, in itself, a reason for maximum page protection. There isn't any high-level vandalism, and some of the recent edits have been constructive (e.g. additions to the "See also" section). Chaotıċ Enby (talk · contribs) 23:38, 5 March 2024 (UTC)
cf. relevant talk page section:
It's an extremely punk rock policy of us to have, and we're better off for it. But, alas, protecting it wouldn't be very punk rock of us, would it?? jp×g🗯️ 01:32, 6 March 2024 (UTC)
In the spirit of the page, we should put the lock template there, but not actually protect it :P ― novov (t c) 05:26, 6 March 2024 (UTC)
 Technically indistinguishable Remsense诉 09:06, 6 March 2024 (UTC)
There are some things where for the sake of keeping things unchanged, it's ironically better not to protect in this instance than it is to full-protect. Duly signed, ⛵ WaltClipper -(talk) 16:14, 7 March 2024 (UTC)
Against the spirit of WP:PREEMPTIVE 🌺 Cremastra (talk) 22:39, 7 March 2024 (UTC)
I think WP:SPARE puts it pretty well -- Protection should not be standard practice. It should only be done as a last resort, when failure to do so would stand in the way of the page's purpose to readers. Duly signed, ⛵ WaltClipper -(talk) 13:17, 8 March 2024 (UTC)
Maybe we should ignore those though. :-) J947 ‡ edits 01:44, 13 March 2024 (UTC)
That would really be against the spirit of IAR, it's "ignore all rules if it would improve the encyclopedia", not "ignore all rules if you feel like it". Chaotıċ Enby (talk · contribs) 01:58, 13 March 2024 (UTC)

Why is AfC so strict compared to NPP?

For new pages patrol, it is common to see pages with a single source or two (in some cases even none) which are not even very reliable be reviewed and accepted. NPP seems to pass every article which doesn't have speedy deletion criteria-meeting problems, while AfC is much more strict with everything. I would even go further and say that some declined AfC submissions are better quality than over 15% of mainspace articles. Often, a declined AfC submission has incredible potential but gets declined, and the draft just dies after 6 months. What do you think? I think this discourages new users and kills out articles with potential to be well-sourced and notable. Youprayteas (t • c) 16:39, 25 February 2024 (UTC)

I suspect the reason is that an actual article can only be deleted either if it meets one of the strict CSD criteria, or if it undergoes the community effort of an AFD. On the other hand, a single reviewer is allowed to decline an AFC submission purely because the reviewer thinks it's too low quality to submit as an article. Animal lover |666| 17:15, 25 February 2024 (UTC)
I think the real reason is probably as above, but I would point out that the best time to deal with any problems that an article might have is when it is brand new, so if an article author cooperates with the reviewer, rather than just abandoning things, a better article may result. A few reviewers seem to just reject any non-English or offline sources out of hand. If you come across one of those then it should be remembered that most of the time an author can simply move the article to main space where it will be subject to speedy deletion or an AfD discussion in the usual way. That option should be better publicised. AfC should be regarded as a service to article authors rather than a hurdle to be jumped over. Phil Bridger (talk) 17:57, 25 February 2024 (UTC)
I think it's more structural than that: an AFC reviewer may be yelled at if they accept articles that meet the rules ("unlikely to get deleted at AFD") but are ugly ("How dare you put that short/incompletely cited/poorly written article in the mainspace?! Won't somebody think of our reputation!"). They are almost never yelled at if they decline these articles. Therefore, they are incentivized to ignore and decline articles that should be accepted. Therefore (since they are rational people), they will ignore and decline articles that should be accepted. WhatamIdoing (talk) 05:15, 26 February 2024 (UTC)
I think this is spot on. —TheDJ (talk • contribs) 11:57, 26 February 2024 (UTC)
Very true and relevant. I wrote more on this below. North8000 (talk) 19:04, 4 March 2024 (UTC)
Perhaps we should strike a middle ground on both of them. AfC reviewers should be expected to review them a little more leniently if they're sourced but WP:NOTFINISHED (which is inherent to any article), and NPP reviewers should be a little more willing to draftify or AfD weak articles if they don't immediately demonstrate notability. Thebiguglyalien (talk) 18:56, 26 February 2024 (UTC)
Makes sense to me. Youprayteas talk/contribs 18:58, 26 February 2024 (UTC)
One issue here is user reputation: you lose nothing if you do nothing, but you risk losing some if you do something. In this context, neither declining an AFC (it will probably be unseen for a few months and then deleted), nor marking a page as patrolled (leaves behind a log entry, but few will notice it), is truly considered something; on the other hand, accepting a draft, or nominating an article for AFD, is. In borderline cases, the primary incentive is to do nothing. Animal lover |666| 17:41, 27 February 2024 (UTC)
@Animal lover 666, you might be interested in this discussion at WT:NPP earlier this month, about how to make "doing nothing" a little more visible to other patrollers. (The context is that we need all new articles reviewed at least once in the first few minutes more than we need any single article silently reviewed 20 times.) WhatamIdoing (talk) 19:26, 27 February 2024 (UTC)

It's true, typically AFC is tougher than typical NPP. This is due to a combination of human nature plus common practices and structure at AFC. NPP primarily screens by "should an article on this topic exist in Wikipedia?" which 90% of the times is by wp:notability. AFC also screens by other article quality criteria and has rejection templates for those other criteria. This can be both a plus and a minus...the plus is that more article improvement work gets done and editors learn while doing that. Also, I think that AFC reviewers are a bit more cautious. I think that sometimes they are viewing it as putting their stamp of approval on the overall articles. Also because a rejection at AFC often means just "work on it some more" whereas a rejection at NPP means taking it to AFD. Finally, I think that NPP tends to pass edge cases regarding wp:notability, a partial adaptation to the fact that even articles/topics which clearly fail wp:notability often get kept at AFD. I think that AFC reviewers tend to play it safer regarding this. Sincerely, North8000 (talk) 17:46, 4 March 2024 (UTC)

  • The review process is different even though they are both quality control. However I have come across several new articles which were moved to draft space when they should not have been. My goal at AfC is to help good faith editors ensure their article won't be deleted, whereas at NPP I'm basically making sure there's no copyvio/putting template headers up so people understand what's wrong with the article. SportingFlyer T·C 19:08, 4 March 2024 (UTC)
    I agree with North that AFC reviewers are viewing it as putting their stamp of approval on the overall article.
    By way of reducing the incentives to decline articles, I wonder whether a third AFC nomination should result in a procedural AFD. Then it's no individual's "fault" if the "bad" article ends up in the mainspace, and AFC won't have to go through multiple rounds of "No, really, getting mentioned on Facebook doesn't mean your garage band qualifies for a Wikipedia article". WhatamIdoing (talk) 19:49, 4 March 2024 (UTC)
For a newer editor, the WP:Notability decline template is hard to understand, doubly so because the Wikipedia meaning of wp:notability is different than the real world one. I've done a few help desk items there and have said it more directly (when there is not an SNG in play) "Find two published independent sources that discuss the topic of your article in depth and put them into the article as references. If you can't find those, IMO it's best not to try to create an article on this topic". North8000 (talk) 20:17, 4 March 2024 (UTC)
@WhatamIdoing: I once sketched a streamlined replacement for AfC that incorporated a mechanism like that (though MfD instead of AfD, and on the first 'decline'). The idea was that if you restrict the range of options available to reviewers to a) accepting as-is, b) CSD, or c) sending to XfD, it removes the tendency for AfC to turn itself into an elaborated peer review process and returns it to just being a quick sanity-check on article creation requests. The detailed reviewing is then done by NPP, who were going to do it anyway. It would create quite of bit of extra work at XfD, however, so I think it would only be viable if combined with stopping encouraging new editors from using AfC (see below) and reserving it just for editors prevented from creating things in mainspace by a COI or partial block. – Joe (talk) 14:08, 15 March 2024 (UTC)
I think it needs to be AFD (because that's where the subject-matter experts already are), and I think that making it the third round would cut the volume significantly. Anything that survives AFD shouldn't get further review by NPP and should be ineligible for future draftification (which is what some NPPers prefer to do with ugly articles on notable subjects – these editors care about article quality, rather than deletion-worthiness). WhatamIdoing (talk) 16:49, 15 March 2024 (UTC)
  • I'm not sure it matters that the standards differ (though WhatamIdoing's explanation is spot-on, and I like their procedural-AFD idea too). What we need is better appreciation of the different routes by which articles can arrive in main-space. AfC and NPP are quite different, and some articles simply don't suit one or the other. For example, an academic editor writing about a historical figure, using non-English, written (book) sources as referencing shouldn't hesitate to bypass AfC because it's highly unlikely that anyone there will feel qualified to assess the article, or have access to the sources. At the very least, the article will sit there for months. Meanwhile, AfC reviewers, when in doubt, shouldn't feel bad about accepting and instantly sending to AFD in WhatamIdoing's procedural sense. The whole guiding principal of Wikipedia is that it's a multi-editor, collaborative project. An AfC reviewer can reject once, but as soon as the article's author disagrees, it's a dispute that requires community consensus - and AfD's where that gets discussed. This needs wording correctly, so that everyone understands that the article has arrived at AfD for a second, multi-editor opinion, not because the creator committed a crime in submitting it, or the AfC reviewer is evil for their one-editor view that it's not okay. Elemimele (talk) 13:13, 15 March 2024 (UTC)
    It's common to see AFD nominations marked as "procedural nomination", so that latter idea fits right in with existing practices. WhatamIdoing (talk) 22:53, 15 March 2024 (UTC)
  • It's broken by design. AfC primarily exists to give people who we don't actually want to create articles a way to create articles (classic Wikipedian logic there), and as such there is no real reason to make the process effective or encouraging. No editor with a modicum of experience or good advice uses AfC unless they have to. We should stop encouraging good-faith new editors to use it too. – Joe (talk) 13:57, 15 March 2024 (UTC)

Decade overviews

I have set up Category:decade overviews as a set of categories, as well as articles, and navboxes, as part of WikiProject History Contemporary History task force, which I chair.

Please feel free to contact me any time, with any comments, ideas or questions. thanks! --Sm8900 (talk) 14:40, 18 March 2024 (UTC)

Split WP:DRV into two pages?

WP:DRVPURPOSE gives five criteria for starting a new discussion. Of them, criteria 1-2 and 4-5 all involve some sort of wrongful action during the deletion process. But criterion 3, (which authorizes using the forum for when significant new information has come to light since a deletion that would justify recreating the deleted page), has nothing to do with any mistake on part of the closer and/or deleting admin, and is generally used for when someone looking to recreate a page with new sources wants to avoid a {{db-g4}} tag and/or wants to have the original article refunded as a draft for reference. This in and of itself isn't a problem–DRV is still a low traffic forum–but I think that having both of these types of discussions in the same place has lead to a bit of a "culture clash". When a review under criterion 3 is started, there are often !votes to the effect of Endorse, deletion discussion was several years ago so WP:G4 doesn't apply, even though that is completely unhelpful to the requester (especially if they want a drafted copy of the deleted article).

Since legitimate criterion 3 reviews are quickly approved, I think we should split them off into a "Possibly controversial undeletions" section of WP:RFU or a new Wikipedia:Requests for recreation page, where requests can unilaterally be fufilled by a single administrator without substantial discussion, and keep genuine deletion challenges at DRV. Mach61 04:53, 19 March 2024 (UTC)

Problem is, a lot of requests can not fit the uncontroversial criteria, and all evaluations will undergo the same kind of review by people, even if we split to another venue. I think the page should be kept as-is. Aaron Liu (talk) 11:48, 19 March 2024 (UTC)

Have a way to prevent "hallucinated" AI-generated citations in articles

A major issue observed at Wikipedia:WikiProject AI Cleanup is the ability for LLMs to make up entire citations that never actually existed, given a veneer of verifiability to actually completely unsourced articles. Examples include Leninist historiography (now turned into a redirect), with completely made-up references. Another example is Estola albosignata, with LLMs generating foreign-language sources that actually existed, but had nothing to do with the topic and would be unlikely to be detected by a non-specialist not speaking the relevant languages.
As LLMs become more commonplace, and this kind of insidious "sourced-but-really-unsourced" text generation becomes harder to detect than plain unsourced text, should we try to work on a way to limit such situations? Chaotıċ Enby (talk · contribs) 01:30, 27 February 2024 (UTC)

Ultimately edits have to be checked. It would be a good university research project to build an AI to evalute edits and highlight ones that appear to be unsupported by citations. The rate at which content was falsely flagged would probably be high to start (including content supported by sources in some more distant location in the article), but it could still help produced a prioritized list of edits for human checking. isaacl (talk) 01:52, 27 February 2024 (UTC)
True, but as interesting as it would be, a university research project isn't a Wikipedia policy or task force. And that wouldn't solve the specific problem of AI-generated text making up convincing-looking references, which something like a limitation on AI reference generation could do. Something as simple as having to disclose the references as having been AI-generated (and tagging them for further review) could be helpful. Chaotıċ Enby (talk · contribs) 03:51, 27 February 2024 (UTC)
Unfortunately, the only way to truly know whether a citation is genuine is to manually check it. Blueboar (talk) 12:17, 27 February 2024 (UTC)
Yep, and that's why tagging AI-generated citations for manual reviews is the best way to go. Chaotıċ Enby (talk · contribs) 13:02, 27 February 2024 (UTC)
Your base assumption seemed to be that it was hard to detect when a citation had been AI-generated. Ultimately all edits have to be checked. isaacl (talk) 17:29, 27 February 2024 (UTC)
No. Please stop assuming what others' "base assumptions" were, it's strawmanning and doesn't help the discussion at all. Citations in the middle of AI-generated text are easy to recognize as AI-generated, but the lack of policies on AI generation means they currently stand without any extra scrutiny. Despite being spurious in the vast majority of cases. Chaotıċ Enby (talk · contribs) 17:05, 28 February 2024 (UTC)
It would be a good research project for Wikipedians to work on, too. I only mentioned universities because I feel it's a natural fit for the WMF to engage in partnership, with external timelines from the university and other funders also driving progress. But Wikipedia editors can apply for WMF funding, or just work on it for free if they desire. isaacl (talk) 17:29, 27 February 2024 (UTC)
To clarify, the task would be to mimic what human verification does: examine the change, look at any related references (either as part of the change or pre-existing ones that seem appropriate), determine if the references exist, read the cited works if they are accessible, and evaluate if the change is supported by the references. This is of course a difficult task. But a program working on it will do it tirelessly and continually. It wouldn't be a magic solution, but it could help enable human checking to find more problems more rapidly. At a minimum, it would help identify plausible but fictional references. isaacl (talk) 17:48, 27 February 2024 (UTC)
So, you are proposing a solution to a problem caused by AI that involves more AI. Surely it would be easier just to not use AI in the first place? Phil Bridger (talk) 12:22, 27 February 2024 (UTC)
Well, yes. Similarly, the best solution to gun crime would be for criminals not to use guns, but arming the police is a good plan B. If AI has any place in Wikipedia, it's in suggesting edits which an experienced human can consider critically and make or discard. There are plenty of problems where finding a solution is hard but verifying it is easy. As long as no one implements alleged solutions without verification. AI can have a role. Certes (talk) 12:47, 27 February 2024 (UTC)
The assumption in the original comment seemed to be that it was difficult to distinguish when the source of the edit was program-generated text. Sure, it would be easier to say text shouldn't be written by programs (and I think there's a reasonable chance that this could attain consensus support), but it wouldn't stop the problem of editors ignoring this policy. Ultimately, all edits have to be checked; AI could be used to help prioritize which edits to check first, but it doesn't have to be. Either way, we need to find a way to ramp up the amount of verification effort in a sustained manner, which isn't going to be easy. isaacl (talk) 17:37, 27 February 2024 (UTC)
Saying that making a policy doesn't stop editors from ignoring the policy, while technically true, doesn't mean it isn't helpful. That's the reason we have policies at all to begin with. Also, I never suggested banning AI writing altogether, but using AI to generate citations, as they are nearly always incorrect or completely made up.
Also, your suggestion of implementing automated verification of all edits is pretty far off from the original discussion, and doesn't really answer the specific issue raised. I suggest you open a separate discussion for this proposal, to avoid both getting mixed up. Chaotıċ Enby (talk · contribs) 17:07, 28 February 2024 (UTC)
You asked for ways to manage fictious citations, and I suggested one way was to find automated ways to detect them. I feel this aligns with your suggestion of tagging them. Are you considering a manual process for tagging them? isaacl (talk) 18:10, 28 February 2024 (UTC)
I'm just considering tagging or disclosing citations that are AI-generated. The question is how to deal with a tool (LLMs) that facilitates adding spurious citations, rather than how to make a tool to verify every single citation (which would be a project at a much bigger scale, and relying on it for the first issue would make the process take much longer).
I'm not against an automated way to verify citations. To the contrary, I feel like this would be extremely beneficial to the encyclopedia, and I encourage you to work on it! My point is just that relying on this (very powerful, but harder to implement) tool to solve the more specific problem would be slower than implementing a tagging/disclosing/etc. policy, with warnings/sanctions for editors adding false citations with LLMs. Chaotıċ Enby (talk · contribs) 20:40, 28 February 2024 (UTC)
Again, no hard feelings at all, I really believe your idea has potential! I just feel like it would be better for both to have their own sections/discussions as they solve different, although certainly related, problems. Chaotıċ Enby (talk · contribs) 20:41, 28 February 2024 (UTC)
I appreciate the response. I don't think relying on editors to flag their own edits as containing citations generated by text-writing programs is going to very effective, since editors who follow policy will be manually checking that any citations are valid and support the added content. I think some kind of automated tagging would be needed to avoid editor fatigue, and to free up editor effort for the real problem of verifying edits. It's already counter to policy to include a false citation, regardless of where it came from, so administrators can take appropriate actions as needed. Although English Wikipedia's good-faith and welcoming traditions underlie its ability to attract more volunteers, they also mean there isn't much way to prevent a new editor from doing things they really want to do. isaacl (talk) 02:54, 29 February 2024 (UTC)
Your comment below on an approach that would "only solve half the problem" seems to indicate that you are also concerned about verifying if a cited work actually supports the content added. This also aligns with having tools to help assist with that verification. isaacl (talk) 18:17, 28 February 2024 (UTC)
In related news, AI researchers have started reviewing their peers using AI assistance. Certes (talk) 16:09, 19 March 2024 (UTC)
So what I said at Wikipedia:Village pump (policy)/Archive 179#What can chatbots do? actually came true... 0xDeadbeef→∞ (talk to me) 12:55, 27 February 2024 (UTC)
I think this is going to be the most challenging thing with LLMs. Unsourced text is trivial to spot, but these generated citations can be really convincing, e.g. using the names of real authors with expertise in that subject alongside titles they would plausibly (but didn't) write. And most of our quality-control processes are too undermanned to manually verify each citation.
One solution I can think of is to start insisting that references include at least one external identifier (ISBN, ISSN, DOI, etc.). These could be used to automatically check the existence of a publication matching the citation in external databases. We could start gently at first, with warnings for missing template parameters and tags like {{ISBN missing}}. – Joe (talk) 13:27, 27 February 2024 (UTC)
I at least ocassionally use books as sources that were published before ISBN existed. I also often use articles as sources from journals that do not have ISSN or DOI identifiers, but which I regard as reliable sources for what I use them for. The journal articles and many of the older books that I have cited for many years now are on-line, either free-access or available through the WikiLibrary, and I link the URL when there is no DOI, JSTOR, or similar link, but I would oppose any measure that prevents us from using relevant, reliable sources that do not have an ISBN, ISSN, DOI, etc identifier, and are not (yet) on-line. Donald Albury 16:07, 27 February 2024 (UTC)
I also often work with sources that legitimately have no ISBNs etc, and I agree that a hard requirement for ISBNs is a non-starter -- it wouldn't even help much against LLMs, because they often do provide (fake) ISBNs. But! Since the LLM's ISBN is usually fake, it rarely points to the book being cited (especially when that book is fake too) -- a mismatch would be a useful diagnostic symptom to prompt scrutiny. It seems tricky but not impossible to have a bot that, e.g., looks up a cited ISBN for its title and compares that title to the title in the citation. If these mismatches were given a maint tag, they could then be scrutinized more easily. ~ L 🌸 (talk) 00:24, 28 February 2024 (UTC)
Yes, that is what I'm suggesting. But in order for such mismatch-checks to be effective, we'd need a stronger (but not totally-inflexible) requirement to provide identifiers. Otherwise you could circumvent the whole thing by simply getting the LLM to generate fake citations without ISBNs. – Joe (talk) 13:28, 29 February 2024 (UTC)
I'm not a stranger to using old sources either. But ISBN/ISSNS will be issued for any new editions or republications of older volumes, and failing that we could look to things like OCLC or national library catalogue numbers, which are assigned retrospectively. There will still be things that fall through cracks, of course, but I imagine well over 99% of sources can now be matched with authoritative identifiers. I don't envisage that this measure would stop people using sources without identifiers, just strongly encourage them to provide them where possible. Like all our rules, it would be ignorable when necessary. – Joe (talk) 13:26, 29 February 2024 (UTC)
That would only solve half of the issue, at best. A lot of times, AI-generated citations link to actual works in the general domain of the topic, that could plausibly match, but which don't address the specific topic or verify the claim at all (see the Estola albosignata example discussed above). Chaotıċ Enby (talk · contribs) 17:12, 28 February 2024 (UTC)
It seems like a potentially useful application of AI would be to download a corpus of (sentences with citations, full text of the cited sources) pairs, and train/finetune an AI model to evaluate whether it thinks the source supports the sentence. Even if it produces some false negatives, it could still generate a useful prioritised worklist for human editors to manually verify. Of course, not all sources are readily available to download, but many are. This would help catch cases of verification failures in general, not just LLM hallucinations. Barnards.tar.gz (talk) 17:46, 27 February 2024 (UTC)
There was some work ~a decade ago that did this sort of in reverse: it took unsourced statements in Wikipedia and checked one of the big newspaper sites to see if it could find a suitable source. It seemed to work most of the time, especially for simpler things (e.g., "Joe Film announces his new film"). WhatamIdoing (talk) 20:53, 2 March 2024 (UTC)
@Chaotic Enby, I'm curious about the claim above that Citations in the middle of AI-generated text are easy to recognize as AI-generated. Is the idea here that we should assume that text we've detected as being AI-generated should be assumed to not include real citations, or is there something specific about an AI-generated citation that would let you detect that specifically?
My experience with the free LLM-detection tools online is that they think the articles I've written were AI-generated too often for me to trust their accuracy. WhatamIdoing (talk) 20:58, 2 March 2024 (UTC)
I'm not talking about LLM-detection tools (which always lag behind LLMs and aren't very reliable), I'm just saying that we can recognize some of the "obvious" AI-generated text (with, for instance, the usual ChatGPT keywords/text structure), and infer that the citations inside it are very likely also AI-generated. There's more information about this on Wikipedia:WikiProject AI Cleanup if you want! Chaotıċ Enby (talk · contribs) 21:17, 2 March 2024 (UTC)
That page, particularly "Other indications include the presence of fake references", sets up the possibility for circular decision-making: I know it's LLM-generated text because the refs are fake, and I know the refs are fake because it's LLM-generated text. WhatamIdoing (talk) 22:03, 2 March 2024 (UTC)
Refs being fake alone shouldn't be used to decide something is AI-generated text, it's an indication. And, if you read my proposal, you'll see I never said that any LLM-generated text should have its references automatically seen as false, but as to be reviewed by humans. The solution is obviously to actually check if the references are fake or not, rather than to get caught up in circular reasoning. Chaotıċ Enby (talk · contribs) 16:58, 3 March 2024 (UTC)
In a way, I wonder whether this is a problem that's going to have to be solved in the bigger world - just as Captcha became so important, and we realised first that a human is something that can identify fire hydrants, and later that a human was something that moves a mouse towards a fire hydrant in a wobbly way. LLM's can work very fast, and are extremely good at faking references in very convincing ways. They require neither intelligence, ethics, nor good will from their users. So at the moment, they're a huge risk not only to Wikipedia, but to accuracy of almost every web result, all the way from Wikipedia-references to pictures of people in no clothes. The world desperately needs good ways to identify and screen-out LLM-products, and it's going to be the same battle of will as happened with Captcha: as AI gets better at generating human-like text, other AI will get better at detecting AI-produced text. It may be that anything we do in Wikipedia-world is actually a pointless and partial duplication of something that Google and others are probably working on as we speak. With the current state of AI and LLM's, I definitely favour a flat ban on all AI-generated material in WP. The risks outweigh the benefits by a vast margin. Elemimele (talk) 12:26, 15 March 2024 (UTC)
Enforcement of a ban will depend on being able to identify AI/LLM-produced material with a reasonably high success rate while keeping false positives at an acceptably low rate. But, why should we be more concerned by the source of material than about the quality of material? Humans are also capable of introducing false information, bad sources, and misleading images to WP. Anyone can edit Wikipedia, and anyone can verify content. The emphasis needs to be on what will improve the encyclopedia. Donald Albury 13:08, 15 March 2024 (UTC)
My money is on identifying AI/LLM being the easier of the two problems, and verifying content the harder. Part of the problem is old, pre-internet paper references, which are very easy for AI to fake, and very hard for individuals to verify (in fact near impossible: all you need to do is claim that it's in a pre-ISBN book from a nice long time ago, preferably in a foreign language, and the chances of anyone managing to prove the book doesn't exist are very slim). But it would be very bad for the encyclopedia if we had to ban old, paper sources, because they're too hard to verify and too easily faked. I do think we should be concerned at the source of the material. We have a general principle that every editor is responsible for what they submit; if you submit falsified sources you will get banned very quickly. If you submit falsified material on behalf of another editor, you will also get banned pretty quickly. So given that AI purports to create material like an editor, but falsifies its referencing depressingly often, every current AI-bot is ripe for banning; and those editors who are using them to create wrongly-references gunk are equally ripe. If an editor whose mother tongue is Spanish writes material that's not great grammatically, but is factually correct, some other editor can easily gnome it into shape. This is much, much more productive than having to deal with the misleading nonsense produced by someone who thinks it's okay to edit Wikipedia using AI to circumvent the fact that they are incompetent in the language, the subject, and the whole general idea of writing encyclopedia articles. Elemimele (talk) 19:08, 16 March 2024 (UTC)
This isn't really a new problem. There have been jokes like these since for decades:
Proof by reference to inaccessible literature:
The author cites a simple corollary of a theorem to be found in a privately circulated memoir of the Slovenian Philological Society, 1883.
Proof by ghost reference:
Nothing even remotely resembling the cited theorem appears in the reference given.
People who want to tag sources rather than find them may want a new template, maybe [fake source?] or something along those lines. But what works best is when editors pitch in to find good sources. WhatamIdoing (talk) 01:30, 19 March 2024 (UTC)
"What works best" would be an ideal-case scenario, but, given that not every editor is always available to find good sources, it would be a good thing to tag AI-generated sources for potential fakeness in the meanwhile. Tagging/removing a false source shouldn't need the much higher prerequisite of bringing a better source to replace it. Chaotıċ Enby (talk · contribs) 16:42, 19 March 2024 (UTC)
  • I think that it might be possible to make a bot that checks citations for possible red flags and tags it for review by a human (or adds it to a list somewhere for review by a human.) Verifying that an ISSN is valid and is at least not too far off from the information in the citation, for instance, is reasonable to automate. Links that are dead the first time they're added as a citation, as opposed to going dead later, would also be a red flag, and could be reasonably examined by a bot. Other stuff like "does a book of this name by this author actually exist" is something a bot can potentially determine by searching public databases and APIs. If it's built well, some of the potentially problematic or broken citations it catches might be worth catching even aside from any issues with AI-generated stuff. --Aquillion (talk) 16:48, 19 March 2024 (UTC)
    That could be a great idea indeed! There could be issues with less-referenced books, but that's still a reason for flagging for further verification and not, like, immediately removing them. Chaotıċ Enby (talk · contribs) 19:01, 19 March 2024 (UTC)

Adding a byte count to both editors

I have a hard time figuring out if my edits are minor or not, and usually I have to submit my edits to see the byte count. I think it would be helpful if we had a byte count display so we wouldn't have to make meaningless edits just to say that our previous edit was "Minor or NOT minor." 3.14 (talk) 22:39, 18 March 2024 (UTC)

Edits consisting solely of spelling corrections, formatting changes, rearrangement of text without modification of the content, WP:MOS changes, and reverting vandalism should be flagged as minor edits. Anything else is not a minor edit. The byte count doesn't matter, although minor edits usually have a small bytecount. Aaron Liu (talk) 22:45, 18 March 2024 (UTC)
Also, keep in mind that nobody is going to criticize you for not marking an edit as minor, even if it is minor. Other editors only get annoyed when non-minor edits are marked as minor when they shouldn't be. Schazjmd (talk) 23:00, 18 March 2024 (UTC)
I still think it's a good idea. 3.14 (talk) 23:06, 18 March 2024 (UTC)
Honestly, the best solution would be to remove the "minor edit" function entirely, as most people find its purpose and/or use confusing, for very little benefit as they're rarely marked. Chaotıċ Enby (talk · contribs) 23:08, 18 March 2024 (UTC)
@Chaotic Enby, I agree, but other editors don't (pretty sure there was a recent RfC on it that failed to pass). Schazjmd (talk) 23:11, 18 March 2024 (UTC)
Oh, didn't know about that RfC, thanks for the info! Chaotıċ Enby (talk · contribs) 23:15, 18 March 2024 (UTC)
Found two of the discussions: Wikipedia:Village_pump_(policy)/Archive_186#Proposal_to_remove_"rearrangement_of_text"_from_definition_of_minor_edit. and Wikipedia:Village_pump_(idea_lab)/Archive_48#Completely_remove_the_idea_of_a_"minor_edit" I think there was a formal RfC after the most recent discussion but haven't found it. Schazjmd (talk) 23:31, 18 March 2024 (UTC)
Can you give me the link to that RfC? I really want to read it. 3.14 (talk) 23:29, 18 March 2024 (UTC)
I still haven't found the one I'm thinking of; this RfC was from 2021. Schazjmd (talk) 23:39, 18 March 2024 (UTC)
It's alright. I have the info I need. 3.14 (talk) 01:48, 19 March 2024 (UTC)
BTW: Found it for you. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_177#RfC:_Disable_minor_edits_on_English_Wikipedia 3.14 (talk) 01:51, 19 March 2024 (UTC)
That's the one Schazjmd linked from 2021. Aaron Liu (talk) 02:04, 19 March 2024 (UTC)
??? 3.14 (talk) 02:12, 19 March 2024 (UTC)
Check the link Schazjmd said in "I still haven't found the one I'm thinking of; this RfC was from 2021." above. Aaron Liu (talk) 02:40, 19 March 2024 (UTC)
I found the specific one though. 3.14 (talk) 16:49, 19 March 2024 (UTC)
Again, that's the same one that they linked. There's a link on "this RfC". Aaron Liu (talk) 16:58, 19 March 2024 (UTC)
Oh. 3.14 (talk) 19:06, 19 March 2024 (UTC)
Another point that might be useful is: If you never use the 'minor edit' button, nobody will ever yell at you about it. Using it is strictly optional. Not using it is always acceptable. WhatamIdoing (talk) 02:10, 19 March 2024 (UTC)

You DO know you can reply, right?3.14 (talk) 07:13, 19 March 2024 (UTC)

??? A misplaced message from the future? Aaron Liu (talk) 02:40, 19 March 2024 (UTC)

Proposal: preference to hide maintenance tags

Moved from WP:VPR

For many Wikipedia readers, maintenance tags are annoying to see. While WP:OVERTAG does try to mitigate this, it would be great if there was an option in preferences to hide maintenance tags. Pksois23 (talk) 06:45, 15 March 2024 (UTC)

That's something you could probably do with a CSS gadget. Most readers don't have an account though, and I think maintenance tags do the important job of warning that the article isn't up-to-quality or even is misleading. Aaron Liu (talk) 11:42, 15 March 2024 (UTC)
Note: @Pksois23: this is not currently an actionable proposal, hard moved from VPR. Feel free to continue discussing here. — xaosflux Talk 14:11, 15 March 2024 (UTC)
Got it. Side note, VPR links to Vermont Public Co. Pksois23 (talk) 14:18, 15 March 2024 (UTC)
Fixed VPR link. Schazjmd (talk) 14:22, 15 March 2024 (UTC)
Agreed with Aaron. Maintenance tags present information that's important for readers to know (and to the extent they don't, they should be removed), so we don't want to make hiding them at all a default option. And for those who really want to anyways, despite the information literacy risk, there's already CSS. Sdkb talk 15:45, 15 March 2024 (UTC)
Another possible way to do this would be to have a hide button like [hide] next to the tags Pksois23 (talk) 14:23, 15 March 2024 (UTC)
One world still have to click it everywhere. Aaron Liu (talk) 14:28, 15 March 2024 (UTC)
I can sympathize with the tags being "annoying", they often are. But that's the thing: they're supposed to be. Their purpose is to make sure the reader isn't accidentally misled by content that may not be up to our usual standards. They're supposed to be noticeable. That said, I wouldn't mind a userscript or CSS that could show/hide them for logged-in users who know what they want, similar to what we have for CS1 errors in citations at Help:CS1 errors. I also think it wouldn't be a bad idea to take a deeper look into whether our maintenance tags should have their appearances updated for modern aesthetics. I don't think there's anything wrong with the old classic look (I still use Monobook unless I'm updating page layouts where I'd need to check other skins) but as long as they stay noticeable I think consensus for a redesign pass could probably be achievable. The WordsmithTalk to me 16:11, 15 March 2024 (UTC)
There was {{mbox/sandbox}}, which changed the icons used (see Template:Ambox/testcases#name= text=text 2 for how it looks), but the community didn't like it. Aaron Liu (talk) 16:17, 15 March 2024 (UTC)
I remember a few proposals to update the boxes, but if I'm remembering right most of them were fairly small changes, backend stuff or accessibility. I don't think there's been a comprehensive major overhaul attempt in a while, but its possible I missed that discussion. Would you happen to have a link to the discussion for the last round? The WordsmithTalk to me 16:24, 15 March 2024 (UTC)
Scrounged a bit for this, it's at Wikipedia:Village pump (idea lab)/Archive 37#Changing to flat icons which also links to the same failed proposal's discussion in 2020. Aaron Liu (talk) 16:36, 15 March 2024 (UTC)
For many Wikipedia readers, maintenance tags are annoying to see. I have literally never seen a person IRL express this sentiment, nor any comments from new/ip users calling tags ugly at the Teahouse or the like. Mach61 23:19, 15 March 2024 (UTC)
Neither have I. I've also not seen any complaints (in real life or on wiki) from readers saying that they really missed the maintenance banners when they were hidden (for years and years) on the mobile site.
I'm seeing comments above like Maintenance tags present information that's important for readers to know – dubious, discuss? We have WP:No disclaimers in articles. Maintenance tags present information that's important for people doing maintenance work to know. That could include readers (aka "potential editors").
I think what we might need is a shared understanding of what the purpose of these banners is. Is it really to make sure readers know what the issues with the article are? If so, then a whole lot of tags need removing, because they're not actually problems that readers should care about. WhatamIdoing (talk) 01:59, 19 March 2024 (UTC)
If we really want to pursue that path of hiding unimportant tags, things get complicated, and the simplest solution would involve excluding IPs from seeing such tags. Aaron Liu (talk) 02:07, 19 March 2024 (UTC)
The guideline you listed specifically lists cleanup templates as "acceptable disclaimers" that are considered an exception. The WordsmithTalk to me 03:46, 19 March 2024 (UTC)
I think WAID is arguing based on principle. Aaron Liu (talk) 11:46, 19 March 2024 (UTC)
What it actually says is that they're acceptable because they're "temporary" and "should be cleaned up quickly". It does not say anything even remotely like "It's important for readers to know that there is inconsistent American and British spelling used in this article". WhatamIdoing (talk) 00:32, 24 March 2024 (UTC)

I think the public is used to our tags and they serve a cautionary purpose. In particular I've seen the phrase "citation needed" used outside a Wikipedia context and it is becoming part of the language. There is room for improvement in the tagging system. In particular I think some of the more contentious tags should always be accompanied with a new section in the talk page. No drive-by tagging. --agr (talk) 21:18, 21 March 2024 (UTC)

There's even a XKCD about it! Chaotıċ Enby (talk · contribs) 10:12, 22 March 2024 (UTC)
Wikipedian protester
User:xkcd generously gave us a free license for that favorite comic. It looks like it's used in several articles and even more talk pages.
(Oooh, lookit Citation needed#Usage outside Wikipedia. This might turn out to be an WP:IPC section I could enjoy reading. Hmm, a custom-printed scarf to sneak into events?) WhatamIdoing (talk) 00:58, 24 March 2024 (UTC)

WikiNLP

This is the concept of a machine learning-assisted countervandalism tool, made using Natural Language Processing (NLP). We will train the system to distinguish vandalism from constructive edits; the system will then share the data with countervandalism users and bots such as ClueBot NG. If it works as intended, it has the potential to significantly reduce vandalism. 2804:14D:72B3:9F5D:0:0:0:1F54 (talk) 17:36, 20 March 2024 (UTC)

Great idea, but isn't this already mw:ORES? Chaotıċ Enby (talk · contribs) 17:40, 20 March 2024 (UTC)
It's also the already mentioned ClueBot. Q T C 17:43, 20 March 2024 (UTC)
ORES predicts the quality and the intent of edits. A new revert risk models is developed by the Wikimedia Foundation Research team, with two components: a multilingual model, with support for 47 languages, and a language-agnostic model. Trizek_(WMF) (talk) 17:52, 26 March 2024 (UTC)

Captchas

I think we need more complicated CAPTCHAS in case a more complex bot comes on to the system and tries to log in Amoxicillin on a Boat (talk) 14:24, 19 March 2024 (UTC)

Our CAPTCHA system is not managed locally here on the English Wikipedia. There are several idea open for changing CAPTCHAS, you can review them here (including possibly using reCaptcha v3). — xaosflux Talk 14:29, 19 March 2024 (UTC)
Our current system has been enough for the last ten years. Aaron Liu (talk) 14:58, 19 March 2024 (UTC)
The current system is an impediment for some impaired persons. reCAPTCHA v3 may be better; here's a study on its effectiveness for those with visual impairments. isaacl (talk) 15:29, 19 March 2024 (UTC)
That's a good point, but I'm pretty sure our current captcha was developed so we wouldn't have to use Google. Maybe hcaptcha? It has a special sign up thing where you can get a cookie to skip all hcaptchas for the visually ipmaired. Aaron Liu (talk) 16:15, 19 March 2024 (UTC)
Feel free to give feedback to the MediaWiki devs. phab:T6845 is a ticket on accessibility of CAPTCHA; phab:T250227 is a ticket on using hCaptcha; and there are a number of other tickets at the link Xaosflux provided. Yes, the sticking point is how to keep user information private, which hinders dropping in a third-party solution. isaacl (talk) 16:26, 19 March 2024 (UTC)
There's a CAPTCHA? 3.14 (talk) 19:07, 19 March 2024 (UTC)
It only appears sometimes, like when the IP address has too much editing activity, when the edit triggers certain edit filters, and after too many failed login attempts. Aaron Liu (talk) 20:28, 19 March 2024 (UTC)
That may need to be expanded upon. BTW, possible vandalism in Just Shoot Me! - Missing Neilsen Awards. 3.14 (talk) 22:03, 19 March 2024 (UTC)
Not sure what you mean. Aaron Liu (talk) 01:20, 20 March 2024 (UTC)
The list of things that trigger CAPTCHAs needs to be expanded to things like creating an account (Speculation, IDK much about bots) or stuff like that. 3.14 (talk) 01:38, 20 March 2024 (UTC)
The last thing that I heard about our current system is: It keeps out humans (especially if they're not using a Latin-script keyboard, because typing correcthorse is difficult यदि आपका कीबोर्ड इन अक्षरों का उपयोग करता है), but it is easily defeated by bots.
Also, I've heard that creating our own could require a decade's worth of work for a team of engineers. Unless someone shows up with a US$10M grant and a determination to do it right, that project will probably continue to be postponed. WhatamIdoing (talk) 04:27, 27 March 2024 (UTC)

Changing {{Broken anchors}} to the pattern of {{dead link}}

Hi all. User:Soni suggested changing {{Broken anchors}} to the pattern of {{dead link}}. I think this is a good idea. Since this task affects all Category:Pages with broken anchors pages, I'm here to ask for your opinion on this suggestion. If it goes well, I'll be ready to start modifying it. Kanashimi (talk) 07:20, 18 March 2024 (UTC)

Do you mean to change it to a tag that will be displayed in the article? Wouldn't that look very weird, since anchors are invisible? Aaron Liu (talk) 11:31, 18 March 2024 (UTC)
These are links to anchors, rather than the anchors themselves. The issue is anchors get changed, but the links to them don't. So there are 70,000+ articles with such broken links. -- LCU ActivelyDisinterested «@» °∆t° 16:59, 18 March 2024 (UTC)
Oh. In that case I agree. Aaron Liu (talk) 17:25, 18 March 2024 (UTC)
Can you explain further? I'm unclear on what change is being proposed. isaacl (talk) 17:50, 18 March 2024 (UTC)
To change the current system for tagging broken anchors into a {{fix}} template put after wikilinks to nonexistent anchors. Aaron Liu (talk) 18:14, 18 March 2024 (UTC)
At the moment the {{Broken anchors}} template is added to the talk pages of articles that have links to non-existent anchors. From my reading the proposal is to replace this with an inline template directly after the broken link, similar to how {{dead link}} is used to mark broken weblinks. -- LCU ActivelyDisinterested «@» °∆t° 18:30, 18 March 2024 (UTC)
@Kanashimi: can you please confirm whether your proposal is as described by ActivelyDisinterested, perhaps with a before and after example? isaacl (talk) 21:14, 18 March 2024 (UTC)
Thanks for joining the discussion. I did a demo edit here. Kanashimi (talk) 23:03, 18 March 2024 (UTC)
Sorry, I still don't understand what you are proposing to do. Is Cewbot intended to make edits that show how to invoke a template, rather than invoking the template? isaacl (talk) 23:13, 18 March 2024 (UTC)
Cewbot is supposed to stop adding these banners altogether and use a {{fix}} template to mark wikilinks to broken anchors. Aaron Liu (talk) 23:33, 18 March 2024 (UTC)
It looks like you're in favor of changing it to {{broken anchor}}? Kanashimi (talk) 23:36, 18 March 2024 (UTC)
That's not what appears in the link that Kanashimi provided. Perhaps you can let them explain their proposal? I still don't understand what is the current situation, and the proposed new situation. isaacl (talk) 23:39, 18 March 2024 (UTC)
This discussion started User talk:Kanashimi#Broken anchor edits. Perhaps you could take a look at what User:Soni has to say. Kanashimi (talk) 23:46, 18 March 2024 (UTC)
I am very confused. Is the proposal not to replace Cewbot's current talk-page-banner mechanism with one that puts {{broken anchor}} after links to broken anchors? That is what appears in the link (Note that Cewbot's first edit was wrong and Kanashimi fixed it.), and that's what appears on Kanashimi's talk page:

Personally I'd just add a template to the main article page, like Template:citation needed shows up inline. That way it's immediately obvious to editors where the potential anchor is.
— User:Soni

Aaron Liu (talk) 23:54, 18 March 2024 (UTC)
OK, so that sounds like what ActivelyDisinterested said. Is that correct? isaacl (talk) 23:58, 18 March 2024 (UTC)
Yes, if the bot can't fix it, it will insert {{Broken anchor}} after the link or template. Kanashimi (talk) 00:40, 19 March 2024 (UTC)
There was a mistake in the test settings, so I changed them manually. The current version is the one that will be available after the robot modification. Kanashimi (talk) 23:34, 18 March 2024 (UTC)
To re-cap:
Imagine an article that contains a link to Example#typo_here. This is a working link to an article, but there's no section called ==typo here== in the article.
  • The current behavior is: A bot adds a note to the talk page to say that there's no section called ==typo here== in the linked article.
  • The proposed behavior is: A bot adds a [broken anchor] template in the article, after the relevant link.
Is that right? WhatamIdoing (talk) 02:07, 19 March 2024 (UTC)
As far as I know, yep. Aaron Liu (talk) 02:08, 19 March 2024 (UTC)
That's pretty much it. The only distinction is that the bot currently adds {{broken anchors}} which resembles the talk page Wikiproject headers. My suggestion was to add [broken anchor] in the article and (additionally) maybe also adding a message in talk page. Like Talk:1st_Academy_Awards#External_links_modified from Internet Archive Bot. If we need something on the talk page, that's better than a banner. Soni (talk) 04:26, 19 March 2024 (UTC)
Is the change going to move the template for the current 70,000+ pages? Perhaps it would be better to hide the visual appearance by default, while allowing editors to enable its display through a personal CSS file if desired. isaacl (talk) 02:15, 19 March 2024 (UTC)
I say just grandfather keep the talk-box version and make new versions the inline {{fix}}. Aaron Liu (talk) 02:42, 19 March 2024 (UTC)
Yes, this change will affect all 70K pages. I'm expecting the same behavior as {{dead link}}, so I'll leave a marker to let users know to fix it manually. This is just like the behavior of {{dead link}}. Kanashimi (talk) 03:39, 19 March 2024 (UTC)
The problem with keeping the talk-box version grandfathered is that they are very hard to fix. As I mentioned in User_talk:Kanashimi#Broken_anchor_edits, I manually tried editing 2-3 of them to see how it was. There's no easy way for a human to see the talk-box template and find the respective text that was actually broken. You have to search through the text of the article, look for history (just in case the text got changed but the broken anchor remained) and crosscheck that with the talk page itself.
In fact, given how current automation works, you have no way to remove the talk-box notification when it's fixed. Of the articles I spot-checked, 2 were already fixed years ago, out of which one was even a redirect page.
Essentially the 70K pages with talk box version will contain a lot of pages that are already fixed, and everything else will be tiresome. It's simpler to just shift to a new functionality and have the script rerun on the 70K pages. The backlog can then be semi-automated (using AWB/similar) and the main fixes will become a lot easier Soni (talk) 04:21, 19 March 2024 (UTC)
Sure, but that can still be done while keeping the text hidden from readers by default (which I'm guessing was the original reason for placing the message on the talk page). isaacl (talk) 05:17, 19 March 2024 (UTC)
We don't keep {{dead link}} hidden, so I don't think we should keep broken anchors hidden either. Aaron Liu (talk) 11:46, 19 March 2024 (UTC)
If we were starting from scratch, then perhaps the two should be handled in the same way, though I'm guessing that {{dead link}} appears mostly in references, thus not affecting the visual appearance of the main content. But if the only discussion about this is on the idea lab village pump, then a lot of people will be surprised when thousands of indicators pop into existence. A more reader-friendly approach may be warranted. isaacl (talk) 15:15, 19 March 2024 (UTC)
I'd say these are no more intrusive than maintenance tags or {{cn}}. Aaron Liu (talk) 15:30, 19 March 2024 (UTC)
Agreed. I think it's not a big deal to put maintenance tags on talk page. I'd personally not attribute a lot of weight to why the template was originally written as it was, since it was basically "Because another template used this way" more than anything.
I am okay if the template was hidden (in which case it may just as well be a single Category:Articles with broken anchor link), but I think that's still less preferable than a tag similar to {{cn}} Soni (talk) 01:43, 20 March 2024 (UTC)
  • User:Kanashimi Out of curiosity, what's the process for this usually? Does his need to go through another village pump/RFC/Bot approval/something else? Soni (talk) 08:09, 26 March 2024 (UTC)
    This is basically within the scope of the original bot application. But since it affects a lot of pages, I'm looking for suggestions here. I've recently started implementing it, and you can see it in action at Visa policy of Russia. Kanashimi (talk) 11:45, 26 March 2024 (UTC)
    I think the template needs to add a category as well, otherwise it'd be impossible to find broken anchors to fix. I don't think I see it in the Visa Policy article.
    Also if the broken anchor is on a redirect, should it default to just redirecting to the overall page? Soni (talk) 12:00, 26 March 2024 (UTC)
    Problematic articles are added to Category:Pages with broken anchors. You can see it on Union Pacific 1982. If there is a problem with the redirect page, I think sometimes it's just that the target of the redirect has been deleted and needs to be checked manually. Kanashimi (talk) 12:06, 26 March 2024 (UTC)
    I don't see why redirect links should be changed. If an anchor doesn't exist, it doesn't do anything either Aaron Liu (talk) 12:23, 26 March 2024 (UTC)
    Mainly because I think most broken anchors are just redirects, so the category is full of them. I can't check offhand though, and there doesn't seem to be a simple way to see everything in the category that's not a redirect.
    @Kanashimi Is there no way to check if an article exists? If the anchor (redirect or not) is at a deleted article, it probably shouldn't be a broken anchor template use anyway. (I forget if there's another template for redlinks) Soni (talk) 12:27, 26 March 2024 (UTC)
    Redirects to nonexistent articles fall under speedy deletion, and I'm pretty sure some bot like AnomieBOT already detects them. I don't see why broken anchors are mostly redirects = we must remove the anchor. Aaron Liu (talk) 12:30, 26 March 2024 (UTC)
    Sorry I didn't make it clear. I was referring to the situation where the article still exists, but the entire section has been deleted. Kanashimi (talk) 12:30, 26 March 2024 (UTC)
    I still do not see why we cannot change any redirect pages with broken anchors to instead be a redirect to the overall article instead. Without a "fix" redirects like Union Pacific 1982 already behave that way.
    Essentially I just want "Redirects with broken anchors" treated slightly differently than "Pages with broken anchors" just because it'll be a bit different dealing with both those backlogs Soni (talk) 15:20, 26 March 2024 (UTC)
    Without a "fix" redirects like Union Pacific 1982 already behave that way. So why should we remove the extra information of where it was meant to point? The same reasoning applies to normal wikilinks too. Aaron Liu (talk) 15:22, 26 March 2024 (UTC)
    My primary concern is the Category:Pages_with_broken_anchors page. Right now it's 70K pages, including talk pages. I think the non redirect pages would be much less in number. I think that any "backlog removal" efforts at the non redirect versions will be a lot different than the redirect pages.
    If we had some way to see "Non redirect pages with broken anchors" in the category easily, it's good enough for my concerns. "Redirect pages with broken anchors" can be hacked at in it's own free time Soni (talk) 05:09, 27 March 2024 (UTC)
    I still don't see the difference between those of redirects and those of links, and why we should separate them. Fixing them is the exact same process. Aaron Liu (talk) 11:29, 27 March 2024 (UTC)
    What's the purpose of the |target_link= parameter? Aaron Liu (talk) 12:27, 26 March 2024 (UTC)
    I'm thinking of using this parameter to quickly find all broken anchors linked to a specific page. Kanashimi (talk) 12:32, 26 March 2024 (UTC)

Unpacking the infobox

Sometimes I run across an article where the infobox has been packed up in a tight wad of code that requires much more effort for an editor like me to analyze. Should we have a global 'bot' edit those into a more human-readable form? I think that would make it much easier for editors to maintain and expand. Here's an example edit: https://en.wikipedia.org/w/index.php?title=NGC_2523B&diff=1215012630&oldid=1214766725 . I've seen much worse. Thanks. Praemonitus (talk) 16:26, 22 March 2024 (UTC)

We can start with a regex like \{\{ ?[Ii]nfobox.*?(?:[^\n ]|[^\n] )(\|).*?(?:\{\{|\}\}) (and replace the captured group with \n\|), with the caveat that it doesn't work if other templates are nested in the infobox as regex (a glorified finite-state automaton) cannot count nested brackets. Chaotıċ Enby (talk · contribs) 17:09, 22 March 2024 (UTC)
Such a bot would be against WP:COSMETICBOT. -- LCU ActivelyDisinterested «@» °∆t° 20:38, 22 March 2024 (UTC)
Yeah, probably just ask to include in Wikipedia:AutoWikiBrowser/General fixes instead. I'll try to work on an AutoEd module for this. Aaron Liu (talk) 03:28, 23 March 2024 (UTC)
Thanks. The one concern could be inline cites in the infobox. Praemonitus (talk) 15:52, 23 March 2024 (UTC)
You can define use TemplateData for any template, to specify how the wikitext should be displayed in source mode. When defined, any edit to an article will activate the formatting from the TemplateData, and format the template the way it was defined. Trizek_(WMF) (talk) 17:56, 26 March 2024 (UTC)
Not really. It's limited to adding templates using TemplateWizard in source mode and adding/modifying templates in VE. The article won't automatically convert these every time you save an edit. Aaron Liu (talk) 18:40, 26 March 2024 (UTC)
No, but it will convert them every time you touch any part of the template in the visual editor. Eventually, that makes all of them conform. WhatamIdoing (talk) 04:30, 27 March 2024 (UTC)
Yeah, that's what I meant. Aaron Liu (talk) 11:26, 27 March 2024 (UTC)
I had the same info WhatamIdoing had, but apparently it wasn't really reflected in my sentence. Trizek_(WMF) (talk) 16:22, 27 March 2024 (UTC)

Semi-Administrator right

I believe that there should be an extended level of protection named "Semi-Administrator" that requires a user request their permissions on a WP:PERM page. I believe this should be added because it would prevent WP:PGAME and a possible future WP:INVASION. It would be like requesting WP:TPE or WP:RBK, but instead it gives users the right to edit semi-administrator protected pages which would likely become commonplace in the future due to the expansion of media bias, systematic bias, and political extremism, all leading to increased vandalism. Combined with the reduction of editors, this will cause disasterous effects. Another idea is to make WP:ECP a requested right instead of an automatic one. To reduce request backlog, however, there must be more administrators which means WP:RFAINFLATION needs to stop. 2003LN6 18:34, 18 February 2024 (UTC)

WP:WTF? OMG! TMD TLA. ARG!
I don't think we should worry about anything that has no indication of happening. Permission gaming isn't happening on a large scale, and I'd rather preserve adminship being no big deal. Aaron Liu (talk) 19:44, 18 February 2024 (UTC)
Sounds good, but I still believe a backup plan is good or else admins will have to do mass rangeblocks on pretty much the entire world during an WP:INVASION, which would be quite hostile to newcomers. 2003LN6 05:37, 19 February 2024 (UTC)
I think mass-enabling WP:Pending changes would be a good plan. Aaron Liu (talk) 13:25, 19 February 2024 (UTC)
How about phasing out edit requests in favour of pending changes for any protected pages? This is pretty radical, sure, but it'd make it much easier to propose a change quickly, rather than going through the hassle of putting up the template, etc... This would also make it easier for newcomers to quickly do some copyediting. Cocobb8 (💬 talk • ✏️ contribs) 20:46, 18 March 2024 (UTC)
I feel like this would put too much of a burden on pending changes patrollers. QuicoleJR (talk) 00:42, 19 March 2024 (UTC)
Approving 100 pending changes is much faster than responding to 100 edit requests. It could only require more effort from the community if we got far more contributions (e.g., 100 people willing to an edit under PC vs only 10 willing to figure out edit requests). On the other hand, if we believe what the Wikipedia:Editing policy says about Wikipedia being best when it has the most knowledge, then maybe that's a burden we should try to accommodate, at least to some extent.
BTW, a few years ago, an admin removed semi-protection from a bunch of articles (appropriately selected ones, not those likely to be targeted by spammers or juvenile vandals) and added PC. I believe the increase in activity was negligible. It might be possible to do something along these lines, e.g., to reduce some EC-protected articles to semi+PC. WhatamIdoing (talk) 01:15, 19 March 2024 (UTC)
What's "semi+PC"? Aaron Liu (talk) 01:19, 19 March 2024 (UTC)
I'm not 100% certain what the setup is these days, but I believe that it at least used to be possible to stack protections in a way that would prevent editing by IPs and new accounts entirely, and have PC protection for other accounts. WhatamIdoing (talk) 03:45, 20 March 2024 (UTC)
There is not currently an EC level of pending changes. There is only one level of pending changes at the moment, and a consensus would be needed to add a new one. QuicoleJR (talk) 12:09, 20 March 2024 (UTC)
Consensus would be needed for any of this, so that's not a showstopper. WhatamIdoing (talk) 16:19, 20 March 2024 (UTC)
There used to be another level of pending changes, but there was consensus for its removal. Chaotıċ Enby (talk · contribs) 16:24, 20 March 2024 (UTC)
That would be Pending Changes Level 2. It used the reviewer userright (before extendedconfirmed existed) and locked approval of pending changes to that. It was trialled in 2010 and had failed RfCs to approve it in 2012, 2013, 2014, and 2016 before finally achieving consensus to remove it completely in 2017. Wikipedia:Pending changes#Timeline gives more context. Frankly, now that we have ECP there doesn't seem to be much use for Pending Changes at all anymore. The actual extension (mw:Extension:FlaggedRevs/m:Flagged Revisions) is unmaintained and the WMF has had a moratorium on new installs since 2017. I think it would be easier to get consensus to remove FlaggedRevs altogether than to expand it's usage. The WordsmithTalk to me 18:45, 20 March 2024 (UTC)
I doubt it. FlaggedRevisions is used on all articles at the German-language Wikipedia. While one might not wish to emulate their overall trajectory, it would is unheard of for any of the larger communities to voluntarily give up any software that allows them to exercise greater control over article content or new editors. WhatamIdoing (talk) 23:10, 20 March 2024 (UTC)
I don't think removing FlaggedRevs is likely, I just think that gaining consensus for expanding its use would be even less likely. The WordsmithTalk to me 17:25, 27 March 2024 (UTC)
The number of active editors (registered accounts making 5+ edits in a given month) has been stable at the English Wikipedia since about 2013.
@2003 LN6, just in case it was the very old image at the top of the page that made you believe that the number of editors is still declining, I've made an updated image for you.
As you can see, the number of active editors has been stable for 10+ years. There are some seasonal effects, but most months have 36K to 38K registered editors making five or more edits during the calendar month. The English Wikipedia isn't growing, but there is no decline, either.
If you want to see what a decline looks like, then check out the numbers for the German Wikipedia. Other communities, like the Persian Wikipedia, are growing. Overall, across all the languages, I understand that the number of editors was increasing slowly over time, spiked up during the first year of the pandemic, and might be settling down to a natural growth rate again. WhatamIdoing (talk) 07:18, 25 February 2024 (UTC)
I genuinely don't think a hypothetical scenario of thousands of vandals hacking into Wikipedia is a reasonable basis for such drastic changes. Blocking is easy for admins, and, if your hypothetical WikiInvaders can hack into established accounts, what would stop them from also hacking into accounts with that new user right? Chaotıċ Enby (talk · contribs) 13:30, 27 February 2024 (UTC)
I agree. This is highly unlikely, and many of the outlined potential changes are a horrible idea. QuicoleJR (talk) 23:01, 7 March 2024 (UTC)
On the other hand, wikipedia is a free encyclopedia that anyone can edit, and nobody WP:OWNs the content here. I actually doubt that introducing new measures to increase barriers of entry would actually address the bias problems that you raise. It might even have the opposite effect. This would be an interesting topic to study. spintheer (talk) 03:58, 27 March 2024 (UTC)

Have we ever ran a banner explaining the quality topicons to readers?

Hi, y'all! After reading Wikipedia:Village_pump_(proposals)#Proposal:_Remove_the_topicons_for_good_and_featured_articles, some editors say that readers are not aware of what the topicons represent. Has the wiki ever ran a campaign or put up banners explaining what they are? If not, could it be done? — ♠Ixtal ( T / C ) ⁂ Non nobis solum. ♠ 21:34, 5 March 2024 (UTC)

Hovering over the icon produces a tooltip explaining what it means, and the icon itself also links to GA or FA. InfiniteNexus (talk) 22:10, 5 March 2024 (UTC)
Generally speaking, readers hate banner messages that get in the way of the information they were seeking. Personally, I feel a banner to explain page status indicators would be overly intrusive. A link to a legend would be better. isaacl (talk) 22:22, 5 March 2024 (UTC)
As above, a banner is overkill. IMO it's obvious and any final concerns should be solved by the tooltip. Aaron Liu (talk) 22:36, 5 March 2024 (UTC)
Well, I support it. The WMF runs banners for fundraising and random non-enwp-related stuff all the time -- giant ones, too -- so I don't think we can act like the presence of a banner is an unwelcome imposition on readers ipso facto. I mean, look at this: meta:CentralNotice/Calendar. Here is what enwp has flying atop the page:
  • Awareness of Wiki community run Wiki Loves Folklore International Photographic contest
  • Movement Charter Community feedback period
  • Movement Charter ratification period
  • Ukraine's Cultural Diplomacy Month 2024
  • Wikidata Leveling Up Days 2024
  • Wikimedia Stewards elections
  • International Women's Day/International Women's Month
  • Every Book Its Reader 2024 in English speaking countries
  • Wiki Loves Monuments 2024
  • Some dozen or so fundraising campaigns in different countries
At worst, it's background noise that they're thoroughly used to, and at best, it's something that might actually improve their understanding and skill at using the website -- something for readers -- as opposed to something like e.g. steward elections, that even 99% of editors don't participate in, or the photography contest, which is of interest for photographers and contributors. Not that it's bad to run banners for these things, it's just that I think in practice the bar is pretty low for how relevant something has to be to get a sitenotice. jp×g🗯️ 01:41, 6 March 2024 (UTC)
...and readers complain about them, and users ask for ways to suppress them. And there should always be a way to figure out what the status indicators mean; there are always new readers, and even existing readers should be able to learn about them outside of a time-limited campaign. isaacl (talk) 02:02, 6 March 2024 (UTC)
As one of the people who raised that in said discussion, I feel there's many other aspects of the encyclopedia that would warrant more reader attention, and it seems a bit odd to solely prioritise this. A good amount of people are going to ignore the banner anyway, see banner blindness.
A better idea IMO would be having a running section on the Main Page that cycles through various elements of the encyclopedia that we feel readers should know about. It could go below featured pictures. ― novov (t c) 05:25, 6 March 2024 (UTC)
That's a promising idea: a sort of "tip of the day" but for readers. Certes (talk) 09:43, 6 March 2024 (UTC)
I agree. — ♠Ixtal ( T / C ) ⁂ Non nobis solum. ♠ 10:06, 6 March 2024 (UTC)
That could be a great idea! Although "featured pictures" is often too low for new readers to see without scrolling, so maybe our new section could be placed higher up instead? Chaotıċ Enby (talk · contribs) 13:46, 6 March 2024 (UTC)
I don't know if that would get support for a permanent spot in the page, but what about a temporary thing? Like, for one month each day has different information in the section and it could be done yearly or something so it doesn't take up too much space all the time. — ♠Ixtal ( T / C ) ⁂ Non nobis solum. ♠ 14:39, 6 March 2024 (UTC)
There's {{Main page banner}} when you need it. Aaron Liu (talk) 17:12, 6 March 2024 (UTC)
I like this, we hide the inner workings of Wikipedia too well from the viewers in a time where we are losing editors. ♠ Ca talk to me! 01:05, 13 March 2024 (UTC)
What are the inner workings that viewers don't know we feel they should know the most? — ♠Ixtal ( T / C ) ⁂ Non nobis solum. ♠ 10:31, 13 March 2024 (UTC)
Not sure where to start editing? Create an account, and we'll offer you a bunch of easy tasks to get started! Ghosts of Europa (talk) 16:57, 14 March 2024 (UTC)
OOOOOOOOh! I think actually something that could get a lot of support in the community is running some kind of recruitment drive with tips of the day as part of it. Not sure how it could look doe. — ♠Ixtal ( T / C ) ⁂ Non nobis solum. ♠ 19:10, 14 March 2024 (UTC)
That's a pretty good text! Probably combine it with File:Wikipedia-logo-banner-ihojose.png as the image on the left and link create an account, while linking "a bunch of easy tasks" to either Wikipedia:Task Center, Template:W-graphical, or, if we're feeling adventurous, Wikipedia:Dashboard. Aaron Liu (talk) 19:22, 14 March 2024 (UTC)
Active editors at the English Wikipedia 2001–2023
@Ca, the English Wikipedia has not been losing editors for a decade now. WhatamIdoing (talk) 01:35, 19 March 2024 (UTC)
Thank you for the updated graph! All of the editor count graph I've seen has been horribly outdated. It's nice to see the editor count is at least not in decline. ♠ Ca talk to me! 00:18, 20 March 2024 (UTC)
Just wondering, why has there been a yearly peak of active editors in March in every year since 2014 (except 2020)? Sungodtemple (talk • contribs) 01:12, 23 March 2024 (UTC)
Summer vacation? Aaron Liu (talk) 01:21, 23 March 2024 (UTC)
Summer vacation is July and August in most places (June and July for the US), and editor activity goes down then (just like it goes down on weekends and holidays).
March is when International Women's Day happens, and there are a lot of organized events around that, so maybe that's relevant? WhatamIdoing (talk) 04:17, 27 March 2024 (UTC)
Spring break is another possibility. Some1 (talk) 22:54, 27 March 2024 (UTC)

Automatic page blocks to prevent 3RR violations

Hi! I have spent a few days patrolling recent changes and noticed that it can be quite easy to break the 3RR if you're not careful. I have thought of an idea that could help reduce accidental 3RR violations and/or impulsive edit wars from good-faith editors.

My idea is that somewhere in the preferences, there is an option named: 'Apply page block to self after revert limit reached'. If this is checked and the user then makes 3 edits tagged as some kind of revert to 1 page, a bot automatically blocks them from that page (not extending to its talk page). The block expires 24 hours after the first revert. If it is technically possible, it may also apply the block after 1 revert where there is a 1RR.

The aim of the block is to act as a sort of 'guard rail' to prevent the good-faith user from crossing the bright line. If they anticipate that they will have a legitimate reason to perform a 4th revert (e.g. blatant vandalism), they can turn the preference off before the 3rd revert. QwertyForest (talk) 21:11, 31 March 2024 (UTC)

That could be made into a user script, if you replace "be blocked" by "be warned that you might break 3RR" (especially since making 3 reverts shouldn't prevent you from editing the rest of the page normally) Chaotıċ Enby (talk · contribs) 21:21, 31 March 2024 (UTC)
That could work too. Nice suggestion! QwertyForest (talk) 21:24, 31 March 2024 (UTC)
Of course you could slow down a bit and be more careful. Phil Bridger (talk) 21:40, 31 March 2024 (UTC)
The thing is violations of 3RR may result in a block, but does not guarantee a block. Any kind of automated program such as the abuse filter blocking needs to be such that an admin would block the user in all cases. As aptly stated here, 3RR does not apply to reverting vandalism, BLP, or ban/block evasion. So unfortunately no I don't think this idea is a good one. Awesome Aasim 02:42, 1 April 2024 (UTC)

New logging interface

Tracked in Phabricator
Task T71596

Here's an idea for a new way of signing up and logging in to Wikipedia (and maybe other projects too, if proven useful).

Instead of being brought to a new page (separate URL) and having to go through, in total, two separate page loads to finish signing in (which, for people with a poor connection, could mean minutes), I would like to suggest that the logging interface opens in a popup window within the tab (I.E. in the same URL), such that it automatically closes once signing is successful.

Thoughts?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 14:04, 2 April 2024 (UTC)

This sort of suggestion would likely be an upstream software change. A similar feature request for this is open at phab:T71596. Feel free to comment on it or submit patches there. — xaosflux Talk 14:26, 2 April 2024 (UTC)
Either every page download would have to include the appropriate code to perform a login, or the browser would have to load the appropriate logic from another URL when displaying the popup. While the extra cost of the login code is likely small, all non-logged in users would be affected, whether or not they ever log in. So while there may be other reasons related to user experience that would favour this change, I don't think resource usage is the best motivation for it. isaacl (talk) 16:00, 2 April 2024 (UTC)

Articles for Creation/Disambiguations

Hi. I've been reviewing redirect and category requests for some time now and I have an idea: Disambiguation requests.

Currently, requesting the creation of a disambiguation page is not easy for new and IP editors, as it can only be requested with the same process as normal articles. Therefore, I would like to discuss the possibility of a new AFC page, AFC/D, which will be used for the requests of disambiguation pages.

The format of such requests can be something like this: 

== Disambiguation request: [Disambiguation page name] ==
=== Pages ===
# [Article 1]
# [Article 2]
...

The request can then be reviewed by experienced editors with help from user scripts such as the afcrc-helper, which will make the process much easier and quicker.

Thank you. CanonNi (talk) 01:40, 2 April 2024 (UTC)

Redirect deletion

Just floating this idea.. MediaWiki now includes a specific permission for deleting redirects with only one revision. The delete-redirect user right could be granted to page movers to allow them to delete pages that had been moved to draftspace by a non-PM and subsequently tagged with CSD R2. I see these pages pop up in the new pages feed from time to time, where the article had been draftified but sometimes the R2 tag lingers for quite awhile. To be clear, this permission only allows deletion of redirects that have only one revision (namely those created as a result of a page move). We could also probably set up an edit filter to further restrict usage of this feature to only permit deletion of the page if the person attempting the deletion is the original author, or if the R2 tag is on the page (I know there was at least an experimental/joke edit filter at one time to prevent deletion of the main page, so the functionality is there). Thoughts? Taking Out The Trash (talk) 01:10, 3 April 2024 (UTC)

Makes sense. If we trust page movers to move articles without leaving a redirect, we can trust them to help other users do the same. On the other hand, CAT:R2 very rarely has more than a couple of pages in it, so I don't think there's a pressing need for more hands there right now. – Joe (talk) 07:15, 3 April 2024 (UTC)
This proposal seems useful and reasonable. If R is a one-revision redirect to article A, a page mover could already delete R badly by moving A to R then back to A without leaving a redirect. (Don't try this at home.) Let's give them the tool to delete R well instead of badly. Any redirects we really need to keep should be protected anyway. Certes (talk) 09:09, 3 April 2024 (UTC)
The challenge this idea creates is setting up a "You can do X, but you can't undo yourself" situation. That isn't necessarily a showstopper, but something to consider. — xaosflux Talk 14:11, 3 April 2024 (UTC)
I had thought delete-redirect still only helped during page moves and was currently granted to page movers: Wikipedia:Page mover#delete-redirect. (I've also looked through Wikipedia:Page mover/delete-redirect.) I think expanding it to just delete single revision redirects is maybe unwarranted; maybe with additional limitations as mentioned but I'm not sure the expansion of the right would be added to MediaWiki if it depends on local edit filters? Skynxnex (talk) 14:19, 3 April 2024 (UTC)

Workshopping a trial admin process

In WP:Requests for adminship/2024 review/Phase I, I proposed trial adminship but it appeared that the proposal was not quite ready. I want to figure how can we have a trial admin process that is most likely to hold well with the community. There definitely should be a method for there to be trial admins when consensus is unclear or to dispel any doubts about current user conduct. Or maybe trial adminship should be the only result of an RfA. I do not know. Awesome Aasim 18:16, 12 March 2024 (UTC)

The framework that I think has the best chance would be a kind of limited adminship. I would make a permission, requestable at WP:Perm and grantable/removable by a single admin as appropriate. The permission is designed to counteract vandalism and be used by a new change patroller. The permissions would be:
Block any account that is not autoconfirmed for a short time (37 hours?)
Semi-protect any page for a short time (probably same time frame as blocking)
Delete any recently-created page.
This gives these permission holders the full block/protect/delete triad to avoid the law of the instrument. It also gives them enough ability to break up most common/simple cases without letting them get into a lot of situations where they generate controversy.
The permission would NOT have viewdeleted. This is awkward because they could delete a page and not have any way to revisit it, but it is a WMF requirement for any process that didn't go through a full RfA or similar.
The way the actual restrictions on the perms are enforced could be technical or social. If they have the technical ability to make any block, but there's a brightline policy against it and a bot that reports any discrepancy to AN, I think that's still fine.
I know this isn't exactly what you had in mind from trial adminship (giving the full tools and a period of time to use them before some kind of reconfirmation), but I think it's the best way to practically solve some of these issues. Tazerdadog (talk) 18:40, 12 March 2024 (UTC)
That feels like a pretty good idea, as making it a perm removes the need for a double RfA, and it can still show experience and trust in light of a future RfA. Chaotıċ Enby (talk · contribs) 19:31, 12 March 2024 (UTC)
On many Fandom wikis, there is this right called "content moderator". This right gives users the ability to edit fully protected pages (but not interface pages), delete/restore pages, rollback, and protect pages. We can have something similar particularly for those extremely familiar with the deletion policy. Awesome Aasim 03:43, 15 March 2024 (UTC)
Yeah, but having the ability to protect/delete but not the ability to block suffers from the law of the instrument. Chaotıċ Enby (talk · contribs) 14:10, 15 March 2024 (UTC)
That is indeed a problem, but I don't think it is that big of a problem when other administrators are able to immediately intervene when there is an incident of disruption going on. Awesome Aasim 16:42, 15 March 2024 (UTC)
That's not the issue. It's not about "they can't block and will have to wait for other admins", it's "they can't block and thus will likely protect instead of blocking, which is often not ideal". Chaotıċ Enby (talk · contribs) 16:44, 15 March 2024 (UTC)

I am thinking any trial admin process needs to allow users to demonstrate that they know how to act appropriately with the admin tools. Conduct as a non-admin is not necessarily an indicator as to whether they will behave that same way with the admin tools. In fact, people are more likely to be careful when given the tools just because they know the community can easily take the tools away. Awesome Aasim 20:11, 21 March 2024 (UTC)

I can think of lots of ways to do this. The trail admin might be paired with a full admin who would supervise the, trial admin. More high powered use of the tools might be reported to a notice board, Blocks might be limited to 24 hours to give a full admin time review, assuming a longer block is appropriate. The whole trial admin concept itself might be done a trial, say one year with a pause after to evaluate how it went.--agr (talk) 21:29, 21 March 2024 (UTC)
What do you have in mind when you say "supervise"? isaacl (talk) 02:02, 22 March 2024 (UTC)

I like the idea in general. The details would need work. There's nothing that precludes working on this even if it outside the main current review. North8000 (talk) 20:23, 21 March 2024 (UTC)

Well, re "delete/restore pages"... restoring pages (which perforce would require the right to read them first) is probably the most sensitive right on the project. Sure, for the overwhelming majority of deleted pages, there's nothing sensitive there. But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. One single person could cause a deal of mischief by reading these articles and giving them to a third party. (Yes, admins can do this, and some have, but I think we want to keep this ability as tightly controlled as possible.) As for deleting pages, are not enough pages being deleted? Could be quite the opposite. Herostratus (talk) 02:17, 26 March 2024 (UTC)

But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. That is what WP:SUPPRESS is for. Awesome Aasim 19:34, 2 April 2024 (UTC)
I don't think arbitrarily increasing the workload of a 45-person team that is already swamped with other stuff is a good idea. Aaron Liu (talk) 20:41, 2 April 2024 (UTC)

Okay, trying a different way to frame the problem:

There is a decently strong consensus that deletion, protection, and blocking are a core trio of permissions which should be packaged together.

The viewdeleted permission is incredibly sensitive for the reasons Herostratus listed above. Restoring a deleted page is also dependent on viewing it. Being able to delete a page but not undelete or review it is incredibly awkward for both admin accountability and mechanical reasons.

Trusting any user enough to give them the viewdeleted permission, along with all the other buttons, without having seen them use protection, blocking, or deletions before is a tall ask and is one of the reasons RFA is struggling.

I'm going to try to attack this from a different angle. Would it be possible from a technical perspective to create an adminbot that would email you the contents of a deleted page if and only if you were the person who most recently deleted it, and you had an appropriate userright, and/or undelete that page for you under the same conditions.

If we can do that, I think unbundling block/unblock, protect/unprotect, and delete/undo own deletion would be viable. Tazerdadog (talk) 19:51, 4 April 2024 (UTC)

It would require some code but it is not impossible to do. It already is possible to disallow editing of other user pages with a pre-edit hook or something similar (though it is not used on Wikipedia), to throw up the "permission error" message. I don't understand why stuff like copyright violations and etc. are not suppressed more regularly; if a page is G10'd or G12'd it almost definitely qualifies for suppression. Attack pages are defamatory in nature, and copyright violations have legal ramifications. Suppression isn't reversible; it can be reversed as easily as it is done. Awesome Aasim 03:21, 7 April 2024 (UTC)

About to open RfC but need last minute feedback

Wikipedia:Requests for comment/Enforcing ECR for article creators is intended to address the problem of WP:ARBECR where only extended confirmed users are allowed to edit in a specific topic area. I am posting here to get last minute feedback on the format of the RfC before I open it formally. Any suggestions for changes to the format or what? Awesome Aasim 02:36, 1 April 2024 (UTC)

Would speedy dratification be a valid option? Aaron Liu (talk) 03:14, 1 April 2024 (UTC)
@Aaron Liu If you think it should be an option please feel free to boldly add it. Awesome Aasim 17:31, 1 April 2024 (UTC)
Really not sure how to word it.
Option D: Addition of a draftification criteria for articles with enough merit to Wikipedia:Drafts#During new page review, with another specified option taken if it does not have enough merit.
? Aaron Liu (talk) 17:56, 1 April 2024 (UTC)
That's fine. Awesome Aasim 21:53, 1 April 2024 (UTC)

Is everything all good? If so then I will start the RfC. Awesome Aasim 22:35, 7 April 2024 (UTC)

Looks good! Chaotıċ Enby (talk · contribs) 23:07, 7 April 2024 (UTC)
Okay let's go. Wikipedia:Requests for comment/Enforcing ECR for article creators Awesome Aasim 04:15, 8 April 2024 (UTC)

Expunged criminal offences

The state of Virginia, where most Wikipedia servers are, permits the expungement of certain less serious criminal records. This is common across the US. Most democratic countries have similar arrangements, for example the UK and Australia allow for many offences to become 'spent'. In the US, it is usually a misdemeanour to report expunged convictions without good reason (acceptable reasons are laid out in the relevant legislation); in the US and other countries like the UK it is a tort (a civil harm, and so actionable in civil court) to report without good reason. Should Wikipedia policy permit the removal of expunged convictions from articles? Charlie Campbell 28 (talk) 06:48, 5 April 2024 (UTC)

As a general rule our content should be guided by reliable sources rather than the location of the WMF's servers. How do they usually treat expungement? – Joe (talk) 08:03, 5 April 2024 (UTC)
Thanks, Joe. My question was inspired by coming across an ex-offender's article where all his expunged criminal convictions are listed in detail. So I guess we allow it at present? Charlie Campbell 28 (talk) 11:42, 5 April 2024 (UTC)
Several major US newspapers (e.g. the Cleveland Plain Dealer, the Boston Globe) have in the past few years implemented a right to be forgotten policy. See Miller & Folkenflik, NPR 2021-02-23 and Ahmad, CJR 2019-12-12. SamuelRiv (talk) 13:47, 5 April 2024 (UTC)
This is interesting, @SamuelRiv, and thank you. I read a good roundup of the US situation which suggested that the media might take this forward in their own way according to local editorial policy. This seems to be a good example. It's why I wondered if Wikipedia might consider doing the same. https://thecrimereport.org/2021/09/10/expungement/ Charlie Campbell 28 (talk) 22:40, 5 April 2024 (UTC)
I'm not sure about other jurisdictions, but here in England records of crimes that attract sentences of more than a couple of years' imprisonment are never spent. Less serious crimes should not be covered at Wikipedia anyway (per WP:BLP). If the location of the servers leaves us open to court action we should consult our legal team. Phil Bridger (talk) 08:20, 5 April 2024 (UTC)
Thanks, @Phil Bridger. I can't see a reference at WP:BLP which says that spent (less serious in your formulation above) offences should not be covered. Are you sure? Charlie Campbell 28 (talk) 12:18, 5 April 2024 (UTC)
I also don't think this is quite right. We shouldn't be including trivial events in any article, on due weight grounds, but minor crimes can still receive significant coverage (see, for example, the Paris Hilton article). Barnards.tar.gz (talk) 13:07, 8 April 2024 (UTC)
On legality, if WMF has any concerns about the possibility of liability for hosting such information, it can take an office action to say so. I'd suggest that you would be hard-pressed to find any example of a speaker like an encyclopedia, newspaper, or blog (rather than a consumer reporting agency, government official, or person in possession of a restricted government record) being held liable in the United States (or in a foreign judgment enforced in the United States consistent with the SPEECH Act) for continuing to report true information about a past criminal proceeding that was published in the news before it was expunged. See United States defamation law (a major theme/adage of which is that truth is an absolute defense to defamation) and Gertz v. Robert Welch, Inc. (requiring at least culpable falsity for defamation on a matter of public concern), to say nothing of Section 230. SilverLocust 💬 09:21, 5 April 2024 (UTC)
Thanks, @SilverLocust. I looked up the law in some states and in Europe. In US states like Virginia and Michegan, reporting an expunged conviction without justification is a misdemeanour, but you are right to say that it is far harder to secure a successful defamation action on that basis in the US than in Europe. There is a good brief here https://www.rcfp.org/disclosure-expunged-records-does-not-invade-privacy/. The media organisations discussed there won their case because they could show good reason. In the UK, it is simply a breach of tort law to report any spent offence without good reason. In mainland EU, the rules are even tougher. One question which might arise, then, is whether Wikipedia should observe the law in other jurisdictions (like UK and EU) or just US? Charlie Campbell 28 (talk) 12:00, 5 April 2024 (UTC)
Per WP:NOTCENSORED, just United States law. SilverLocust 💬 13:11, 5 April 2024 (UTC)
If the crime was minor, and the only material available to verify it are things like court records, WP:BLPCRIME already says it shouldn't be in the article. Of course if there was substantial coverage about it in independent sources, then it might merit inclusion. As to the claim In the US, it is usually a misdemeanour to report expunged convictions without good reason—[citation needed] on that one; I would very much have expected to see a First Amendment challenge to that, and I would expect it to win. Laws muzzling the general public from disseminating truthful information almost never pass constitutional muster. UK law may say that, but well, we're not in the UK (though that may be a concern for individual editors who are, but it's on them to comply with law in their jurisdiction, and that doesn't affect anyone else). Seraphimblade Talk to me 11:48, 5 April 2024 (UTC)
Thanks @Seraphimblade. Replies here don't appear to permit in-line citations so I was reluctant to simply cut and paste as that seemed to be against the purpose of the functionality. I'm not a lawyer and so I'm reluctant to cite the law (one of my own reference points was Virginia law) but was rather giving what I feel is an accurate pen-picture. I completely agree that it would be very hard, if possible at all, so win a defamation case in the US. It would, by the looks of it, be straightforward in Europe. The fact remains, however, that the legislation has a purpose, however difficult or feasible it might be to enforce. I think Wikipedia should have a clear policy on it. Charlie Campbell 28 (talk) 12:12, 5 April 2024 (UTC)
There is no problem using in-line citations. Just add {{Reflist-talk}} after your post to keep the full citation associated with your post. Donald Albury 13:01, 5 April 2024 (UTC)
Thanks so much, @Donald Albury. I'll do it that way in future. Charlie Campbell 28 (talk) 13:16, 5 April 2024 (UTC)
Reporting of criminal records in the media is an interesting read from the perspective of UK law, particularly this bit: Once a conviction is online, and so in the public domain, the media can quote it in their outlets since they are not ‘revealing’ anything new, just stating a known fact. Nobody’s data is being invaded if past news sources are quoted and privacy rights are not being compromised. This seems to be true even in the case of ‘spent’ convictions. If the conviction is on record, it is likely that in certain situations the media are able to justify the ability to publish these details even though it is spent. This does seem to be speculative on their part rather than constituting legal advice.
Since Wikipedia is based on sources, perhaps Wikipedia should follow the sources, meaning that if action has been taken to "unpublish" a source on privacy grounds, then we could consider removing any material that relies on that source. We would weigh such unpublishment as evidence of a privacy interest. Conversely, while the source remains online, we would not take any action. Barnards.tar.gz (talk) 13:58, 8 April 2024 (UTC)

I have read all the very useful posts here and follow through wherever I can. I should say that my original thoughts were about Wikipedia policy rather than liability. My takeaway so far is as follows: US and EU law does allow for expunged convictions but it is highly unlikely that any case for defamation would succeed in the US. A similar type of case in the EU might be successful against the individual editor if resident there, however that editor would need to be identified and Wikipedia would be unlikely to yield to requests for such disclosure from outside the US. It does not seem that liability is a pressing question which could drive any kind of policy change.

However, a policy change can be driven by things other than legal liability. It also seems true, though, that US wikipedia editors in particular (but perhaps many elsewhere) would likely defend the stronger US freedom of expression over an emphasis in the EU towards a right to be forgotten. This all seems to rule out any policy of the automatic removal of expunged criminal records, regardless of jurisdiction.

It seems possible (likely?) that most editors recognise the sensitivity around different democracies' differing public policy and prefer to avoid conveying the impression that the US-based nature of Wikipedia is used to ride roughshod over every other part of the world. Might other, already extant, policies have relevance upon the way expunged convictions are reported in Wikipedia articles (e.g. proportion as per WP:NPOV?). Or is any kind of revision required? I come back to the example which prompted my post here, where an article largely comprises a list of an individual's spent convictions. Charlie Campbell 28 (talk) 13:18, 5 April 2024 (UTC)

That policy is WP:WEIGHT. Also, in the specific case that prompted this query, the subject of the article is a high-profile individual, a former British MP. In other cases, WP:BLP1E could apply and we could choose to not cover the person at all. Also because in this specific case the subject is a former MP, it seems extraordinarily unlikely that any attempts to suppress discussion of his criminal history would be successful in court. VQuakr (talk) 00:18, 6 April 2024 (UTC)
MPs are NPOL, no? I don't think minor criminal history would, in general, be sufficiently covered to be DUE in any BLP articles, though obviously specific cases may vary. Alpha3031 (t • c) 07:04, 6 April 2024 (UTC)
Thanks, @Alpha3031. I've looked that up. I think my example was a bad one. The problem with that article is not that it mentions offences (I don't think very well known people can expect the same treatment as much less known people) but that it's so imbalanced. I think this one in England is probably a better example. The guy has a Wikipedia page because he was known in the 90s. I don't see why his DUIs should be mentioned so long after he ceased to be famous. Charlie Campbell 28 (talk) 13:44, 6 April 2024 (UTC)
Agree that misdemeanor offenses years after a BLP person's window of notability (proposed WP term?) are entirely wp:undue. I'd also suggest that in the case of backbench MPs, briefly famous actors, temporary celebs, that wp:oneevent notability guidelines apply, namely: Editors are advised to be aware of issues of weight and to avoid the creation of unnecessary pseudo-biographies, especially of living people. This should probably be cross-quoted in the BLP P&G. I think it gives suitable grounds to remove the misdemeanors in the John Alford article you link. (The felony and tangential trial in the first two paragraphs are probably justifiable, both by the weight of events, and that they are interlinked with other independently notable events/people.) SamuelRiv (talk) 18:20, 6 April 2024 (UTC)
Thanks, @VQuakr. Yes. I now think the problem with that article, particularly the main body, is that there's so much NOT there. It looks like all the guy ever did was get convicted of stuff. I have a better example of the thing I'm talking about here, though. My Dad reminded me of this guy he knows a bit. He was in a TV soap for a year or two in the 90s and got caught taking drugs. He lost his job and hasn't worked in the media since. He was once well enough known to have a Wikipedia article, but now he's 50 and just a regular guy. He finds it hard to get even casual jobs. He got a DUI years ago and it's on his Wikipedia page. That doesn't seem at all right to me. Charlie Campbell 28 (talk) 13:38, 6 April 2024 (UTC)

The Developing Countries WikiContest

Several editors on the Wikimedia Discord server have come together to organize a new contest focusing on improving content from parts of the world that don't get enough attention. We aim to make this a three-month event running from July through September. Ixtal and Sawyer-mcdonell have volunteered as coordinators, and they're looking for a third! The organizers are also seeking feedback from the wider community, particularly from editors with experience running wiki-events. Please leave comments, questions, and suggestions below, or sign up here. Thanks! —TechnoSquirrel69 (sigh) 05:27, 9 April 2024 (UTC)

Onboarding for new users?

This was promted by a wikimedia-l thread

New users are given zero guidance and then get yelled at when the break the rules they didn't know about. Therefore, I propose that, after sign up, we make a page (perhaps something like H:INTRO?) that we then direct new signups to

Two questions I have:

  1. Will new users simply click away without learning anything?
  2. How much will this help?

As it stands, the current onboarding procedure is basically nothing: just set them out there and yell at them when they mess up. Something needs to change and I hope my proposal will generate some discussion on how to make the onboarding process better. NW1223<Howl at me•My hunts> 01:37, 7 March 2024 (UTC)

The current onboarding procedure is to use Wikipedia:Welcoming committee templates and new users also get a newcomer home (see Wikipedia:Growth Team features). I'm pretty sure automatically sending new users welcome templates is at Wikipedia:Perennial proposals. Aaron Liu (talk) 02:00, 7 March 2024 (UTC)
Wikipedia:Perennial proposals#Use a bot to welcome new users is probably what you were thinking of. Anomie⚔ 12:40, 7 March 2024 (UTC)
Aaron highlighted the Growth team features. To summarize them, new users get Special:Homepage as their base-camp (you might have to activate it in your preferences). There, they have access to selected help links and,
Some wikis also post a message at talk pages. From what I observe*, a successful welcome message requires the following:
  • it is a real message, not a block of links
  • it is clearly signed by a real human
  • it includes a clear indication "contact me if you have any question"
  • they are posted before the user make an edit (so that they can ask a question to the user who welcomed them**).
Messages consisting of blocks of links are not successful (a known issue), in particular when the message look like a banner or something else than a discussion. Signatures have to be clear, as the way we format our messages on wikis is not something the rest of the works is used to.
* Of course, what I observe is not a proof of anything, but I observe a lot of newcomers/experienced users at a lot of wikis since a long time. :)
** This is how Mentorship works: you get a name to contact at Special:Homepage (but unfortunately, at your wiki, not everyone gets one as we don't have enough mentors).
The discussion at wikimedia-l was more focused on explaining the rules while editing, which is also something the Wikimedia Foundation works on.
Trizek_(WMF) (talk) 15:09, 7 March 2024 (UTC)
Since so many recent changes have the "newcomer task" tag, I think it's enabled by default for newcomers. Aaron Liu (talk) 15:28, 7 March 2024 (UTC)
It is default for all new accounts, correct.
But Mentorship is only available to 50% of new users for the reasons I explained, and a key feature to discover editing, Add a link, is still missing at your wiki.
Trizek_(WMF) (talk) 16:48, 7 March 2024 (UTC)
or we could just not yell at them... It is my personal opinion that a lot of our users have themselves forgotten they are on wiki that anyone can edit. —TheDJ (talk • contribs) 21:48, 7 March 2024 (UTC)
I wish our policies had TL:DR versions of them too because some of them are very lengthy and I have no doubt that that's put some people off from editing here. ♠JCW555 (talk)♠ 22:16, 7 March 2024 (UTC)
Most policies have {{nutshell}}, a summary, on top, and welcome templates already link many summaries, such as Help:Introduction and Help:Getting started. Aaron Liu (talk) 22:51, 7 March 2024 (UTC)
Although experienced editors do make mistakes from time to time, in my experience, the vast majority of new editors who get "yelled at" are spammers, self promoters, POV pushers, axe grinders, conspiracy theorists and others whose manifest goals are not in alignment with improving this great encyclopedia. As I see things every day on the firing line, any editor who comes here with a genuine intent to neutrally improve this encyclopedia is almost always welcomed with open arms. So, when an editor puts forward vague assertions of "yelled at", I expect diffs and specific cases. Who in particular got "yelled at", and why? Cullen328 (talk) 09:49, 9 March 2024 (UTC)
When I see an edit that degrades the encyclopedia, I revert it, and usually use Twinkle to leave a message on the user's page, with or without an additional comment. I think that kind of response is what some are calling "shouting". I will not leave unreverted an edit that damages the encyclopedia, no matter how well intentioned. I think the lowest levels of the Twinkle warnings are benign enough. I use the stronger versions of Twinkle warnings when a user repeats the same kind of edits after being warned. I block users who repeatedly over a short period of time make obviously problematic edits after being warned. It may be that new users don't see messages on their talk pages, but that is not a reason to allow them to continue to make edits that degrade the encyclopedia. Donald Albury 14:13, 9 March 2024 (UTC)
@Cullen328, how would you describe to an external observer how English Wikipedia welcomes good faith users with open arms? I'm asking it as finding how bad faith users are treated is easy (Donald gave a good example above), but examples of how one deals with good faith users is more difficult to find.
Actually, what I observed over the years is that vandalism or damageable edits get a warning message, while good faith edits are just left as they are, with no message, because they fit what is expected.
Thoughts? Trizek_(WMF) (talk) 15:18, 10 March 2024 (UTC)
Sometimes they get a thanks and they get a welcome if they're a new user. Aaron Liu (talk) 15:29, 10 March 2024 (UTC)
And {{cookies}}! Chaotıċ Enby (talk · contribs) 17:59, 10 March 2024 (UTC)
Yea, that makes sense, especially because then newcomers could fix the typod on articles, like (off-topic warning) how I fixed an typo on the article for WFSU-TV. The thanks option is actually pretty cool. mer764KCTV5 / Cospaw (He/Him | Talk • Contributions) 16:37, 13 April 2024 (UTC)
Trizek (WMF), we have places like the Teahouse and the Help Desk where new editors can get assistance, and they are easy to find given the amount of traffic they get. I have over 10,000 edits to the Teahouse and over 1,200 to the Help Desk, so I have considerable experience helping and encouraging new editors. Many new editors come to my talk page asking for advice. and I have 5,600 edits there. I agree that bad edits and those that make them get more attention in general than good editors making uncontroversial typo fixes, converting bare URLs into bibliographic references, and reverting vandalism. If I notice particularly good work from a new editor, I will definitely thank them. I think that a brief, personalized compliment is better than 100 "welcome templates". The analogy that comes to mind is that few people give detailed thanks to people doing routine work. Few people go into a McDonald's and lavishly compliment the people sweeping the floors, taking the orders and packaging up the french fries. We just treat them politely, with a "thanks" to the order taker being about the extent of it. Cullen328 (talk) 20:09, 10 March 2024 (UTC)
Trizek (WMF), I don't know if the WMF collects any statistics, but I wouldn't be surprised if the English Wikipedia gets more than its fair share of bad faith users, making experienced editors more cynical. At least if I were a spammer, self promoter, POV pusher, axe grinder, conspiracy theorist or any other bad faith user I'm sure I would prefer to target the largest Wikipedia that has the largest readership. Phil Bridger (talk) 20:35, 10 March 2024 (UTC)
@Aaron Liu, is "sometimes" good enough? :)
@Cullen328, thank you for the details. I think volunteer-me have the same profile as yours, but at my wiki. I don't really count places mike the Help desk or the Teahouse as proofs of being welcomed, as these are places you have to discover (or at least find the link to them). Thanks are apparently only for "particularly good" edits as you said. Messages are often perceived as costly to create. What would you (any of you) do to show a user that they edit is going in the right direction, at low cost?
@Phil Bridger, I'd say the bigger the wiki, the more likely it is to attract people. But as I read it quite often, I kind of think there is a perception of a mass of bad faith users that damage things, while only a few users do it right. I'm not sure this is true: maybe there is a perception bias, as badly behaving users are way more visible than users who do things the right way, don't you think?
Trizek_(WMF) (talk) 00:28, 15 March 2024 (UTC)
I meant that they sometimes get a thanks and nearly always eventually get a welcome. Aaron Liu (talk) 00:31, 15 March 2024 (UTC)

examples of how one deals with good faith users..

--Dustfreeworld (talk) 02:55, 19 March 2024 (UTC)
I'm assuming that, in this context, you're using "getting yelled at" not to mean overt incivility (which is against policy), but rather more subtle snubbing, e.g. ignoring messages or responding curtly. I honestly think that this encyclopedia could improve if this just didn't happen at all, regardless of the person. spintheer (talk) 03:43, 27 March 2024 (UTC)

Trizek (WMF), there used to be a bot called HostBot that would send welcoming Teahouse invitations to new accounts in good standing that had made 10 edits within a few days. Sadly, the bot operator, User:Jtmorgan, is far less active in recent years, and the bot no longer operates. Maybe you can look into that.

If you take a look at the Home Page, you will see that the first prominent word is "Welcome". The prominent phrase "anyone can edit" links to Help:Introduction to Wikipedia. There is a prominent link to Help:Contents on the Home Page, which links to many other help pages. Further down are links to the Community Portal, the Village Pump, the Teahouse, the Help Desk, the Reference Desks, and so on. In other words, the page that new editors first see shouts "Welcome! How can we help you?" I know about banner blindness but I doubt if it would make much difference if we displayed "WELCOME" in bold, bright orange all caps, flashing and flickering. It wouldn't help and it would make us look ridiculous.

Most new accounts do not ever edit. Of those that do, most of those make only a handful of edits and then lose interest. Of those that continue editing, a significant percentage have motivations incompatible with the goals of the project as I described above. Of those who really want to improve the encyclopedia, many are here to create or improve one or two articles about topics of great interest to that person, and then they stop editing. Student editors are here to get a good grade, and only a tiny percentage continue after the course is over. People go to edit-a-thons to satisfy their curiosity, meet cool people and get some free food. Only a tiny percentage keep editing.

I have been wondering for nearly 15 years what the positive psychosocial factors are that separate all those types of people who contribute little or no encyclopedic content from the "rare beasts" who make improving this encyclopedia in countless ways an avocation for many years. I cannot answer that question with confidence although I have my pet theories. I hope that the WMF could make that research happen but I do not know.

As an adminstrator, I believe that blocking bad actors like harassers, vandals, spammers and the like is essential, because showing such people the door makes the editing environment more hospitable. And so I am not ashamed to have blocked nearly 10,000 accounts. I think my work in that area makes Wikipedia a more welcoming place. I think I have said enough so I will stop now. Cullen328 (talk) 02:49, 15 March 2024 (UTC)

There's been some research on the psychological profile of Wikipedians. I am not sure you would consider the factors to be "positive", but if memory serves, we are above average for neuroticism and below average for agreeableness. In plain English: we start editing because there's a typo, we would rather be right and have an argument than go along with something that's wrong. We also don't like change. This all aligns with my experience. How about you? WhatamIdoing (talk) 01:53, 19 March 2024 (UTC)
I like change and demand a link to such a study immediately >:( Aaron Liu (talk) 02:05, 19 March 2024 (UTC)
@Cullen328, thank you for your detailed answer. You describe what I would call "passive welcoming": various signs, at various places that convey the idea of welcoming others. At the opposite, "active welcoming" goes more on the way of telling users personally that you can mentor them, thank users for their edits, etc. This is something you do, and I believe it is super important.
It tights to positive reinforcement: someone getting a positive stimulus on their edits are more likely to continue participating. If that positive discourse comes from a human, it has way more chances to be received and appreciated, compared to one coming from an information message on static page.
Following what @WhatamIdoing said or what @Dustfreeworld illustrated above, we, communities, are apparently very good at saying when something gets wrong. Worse, we are very good at qualifying one edit as not good even if just a part of it is not good. Reverting seems to be sometimes easier than fixing up an edit. And I'm not talking of vandals and trolls there: my focus is on users who genuinely came to fix something and saw "be bold" written at various places.
This topic started with the question of onboarding new users, but it is also on how to keep them editing. As we are in the ideas lab, I'm looking for your ideas: what would you (any of you) do to show a user that they edit is going in the right direction, at low cost? What do you miss to encourage users in an easy way?
Trizek_(WMF) (talk) 16:29, 19 March 2024 (UTC)
@Trizek (WMF), thanks for the ping :-) I’m not sure if I can give much useful comment about your questions, because I’m facing issues very similar to those described in the “How do we ... “ discussion myself as well… ...
My problem is, there’s a user who really doesn’t like me. It seems that my edits are being watched. When they think there’s an “opportunity”, they will suddenly “jump out”, sometimes just within minutes after my edit, nominate the article I edited for AFD, or have half of an article deleted, or criticise me on talk page and have the thread I opened being closed, or, directly yelling at me that “You’re sprouting ... “, etc. All within a short time / same day, like heart attacks. You can’t feel the stress/threats just from viewing the page history unless you’ve experienced them (and that can only be felt from those notifications popping up). And when I tried to restore the removed content, I faced 3RR and 2 warnings, all within minutes; followed immediately by very unpleasant “discussion”/criticism on the project’s talk page.
When I look up the warning templates pages [7][8], I can’t find the warning template that they used. There is no such (level 4) warning template which says “restoring good-faith content is disruptive” (not to mention those are sourced long-standing content not added by me). It seems that they have “tailor-made”/created their own version of warning message for me.
If I were a new user, I would have been threatened and left already. Definitely, with no doubt. I’m quite sure that they have done similar tricks (3RR + level 3/4 warnings) to other good-faith editors as well. (This differs greatly from most other editors do, like providing a detailed edit summary, just remove one or two sentences/sources at a time unless they are doing a rewrite, tagging it first, try fixing the problem first, discuss civilly on talk page first, and only remove outright contentious bad content like those involving BLPs, etc.)
But I can understand why other users may not notice that or can’t see the problem because one can’t feel the tension just from viewing the page history, or, they might not understand how bad I felt when I saw large amount of valuable content that had been there over a decade was deleted mainly because of me. I came here to improve articles and to add content, not making them vanish. That completely goes opposite with the reasons that I’m here. What they did do affect my editing. I’ve left WP for a few days because of that, but it seems no use. Some of the above happened after I came back. I’ve asked for advice on another editor’s talk page, it seems that I was misunderstood. I was mainly asking for suggestions on the likely animus / uncivil behaviour, not on article’s content. I regret having asked that.. yes, my fault.. it was misunderstood.. and it seems that I’ve put someone in a difficult situation, which is not what I intended ... (As a side note, if we’re talking about content, removing a large amount of content at a time of course is not good. No one knows everything about every subject, and everyone makes mistakes. Removal like that will just increase the risk of mistaken removal, even when done in good-faith, without leaving the chance for correction).
I won’t deny that perhaps some of my edits/comments had irritated that user .. but I don’t think what they did is the way to go. Perhaps they just want to prove that “See? The article has problems that you didn’t notice and I’m correcting them now.”? I hope that can come to an end.. but that kind of behaviour has been lasting for quite some time already, and I’m not that optimistic ….. I choose to speak up here, anyway. What also troubled me is their fluctuating attitude/behaviour. Sometimes they seem to be very civil (mostly to others, but once or twice to me also). But when they are unhappy / don’t like you, it’s just totally different. I’ve been told to “find way” to like them, but it’s just too difficult.. I have tried not to escalate during the discussions (if you are familiar with my edits you’ll know how assertive I can be) but I wonder if that helped. I hope I’ve made it clearer now on why I said “I’ve tried my best already”. It’s not about “discovering the value of others”. Nothing like that. You can’t really like someone if they treat you (and others?) like that, no matter whatever value they have ...
Back to the “How do we welcome new medical editors?” thread at WP:MED talk page.. well, I think that user (one different from the above) has taken some of the advice in that discussion and probably has become more civil (as seen from their comments at least) now. And they have never been uncivil to me, which I really appreciate; despite the fact that I’ve pointed out several times what they shouldn’t have done. I believe that’s an editor with good intention. For that I’ve even given them a barnstar. So, perhaps I should go on and start a new discussion called “How do we work with our newly-joined colleagues?” Do we work with them by ... 3RR … warnings ... following … ?” I don’t think I have the energy (or should spend the time) for that though .. after all, it’s just Wikipedia ..
(N.B. I’m talking to myself and reply is welcome but not absolutely needed.. I’m not providing any diff, because I really don’t want to piss people off… if you know you know, anyway ..) --Dustfreeworld (talk) 18:35, 21 March 2024 (UTC)
WP:Wikihounding is against policy. You might want to consult someone to see if it fits. Aaron Liu (talk) 18:47, 21 March 2024 (UTC)
Thank you for sharing this, @Dustfreeworld. I'm really sorry for your bad experience. First and foremost, as Aaron Lui said, you need to report the behavior you describe.
On your message, I agree regarding the attitude. Welcoming users and providing suggestions to their edits is a positive and active way to have more editors joining. Trizek_(WMF) (talk) 17:47, 26 March 2024 (UTC)
@Trizek (WMF) The biggest blocker with any active welcoming and mentorship plan is that... They all fail thanks to no longevity plans and too much effort required.
I have never seen WP:Welcome Committee in action (but it's hard to, because the idea is decentralised anyway), WP:Teahouse has longevity (because it's low frills for everyone), but Wikipedia:Adopt-a-user pretty much has dried up (It's a lot of effort per mentor), WP:Co-op never really got off the ground (too much effort for everyone), WP:Snuggle is disbanded now (don't think many users used it but I might be wrong), WP:TWA is... I am not even sure if it's alive or not, it's not very easy to see the impact of it there, Growth Team's Mentorship space is currently indecipherable for any veteran editor (I don't even have an enwiki page to link for it), Hostbot is unfortunately inactive (not sure why), WP:Twinkle welcoming templates are still active.
Of all of these, I'd recommend reviving Hostbot and encouraging more Twinkle Templates for your active welcoming purposes. One is a bot, the other is a simple 2-clicks per user who's already installed Twinkle. Essentially the simpler and lower effort your solution is for everyone, the more impact it'll have overall (because it's much more likely to be used 3 years later instead of 3 months).
I could go in more depth, but essentially I'd like to see WMF dedicate more resources to simple easy to maintain ideas that solve one problem each, instead of overarching mega-goals that fail soon after the "patronship" dries out. Soni (talk) 06:42, 1 April 2024 (UTC)
There was research that showed people liked TWA but it did not improve editor retention. Not sure what your suggestion about Twinkle is; isn't Twinkle-welcome already working? Aaron Liu (talk) 14:45, 1 April 2024 (UTC)
Yeah I was pointing out Twinkle-welcome as one of the few "active welcoming" things that do already work; so if I were WMF, I'd focus some resources towards "Can we encourage this more". Right now it's mostly used by veterans who already know what Twinkle is/how to use Twinkle/are used to welcoming via Twinkle often enough. I don't have any specific plans already, but I assume anything that boosts any of those three will increase active welcoming. My point of highlighting Twinkle was "Improve something that works" vs "Make a new project that first crosses the longevity barrier".
I do think there's better avenues to explore, roughly in 'more automated and less heavy on maintenance' things. I'd like Hostbot revived, if only because it'll give us a lot of data on impactful retention. Soni (talk) 18:34, 1 April 2024 (UTC)
Some kind of encouragement to use Twinkle Welcome messages more might indeed help. After using Twinkle for many years, I only recently realized that I should be using the welcome messages more often when dealing with problem edits from (apparently) new editors. I think part of my problem was that I did not realize that besides the purely welcoming messages I often saw on user talk pages, there are also welcome messages that deal with a subset of problem edits that I can use instead of a pure warning message in many cases. Donald Albury 13:09, 2 April 2024 (UTC)
Most initiatives to help newcomers in a direct way (not through passive messaging) are time consuming, that's true. In my opinion (which is just an opinion), it is also the price of quality welcoming, to create a new generation of wikipedians. At the moment, the lack of time creates a gap on who will join: only users with "survival" skills will succeed, while less assured people will give up.
What I call "Passive messaging" are user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. Donald just gave good context about them.
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits.
@Soni, if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Trizek_(WMF) (talk) 16:47, 2 April 2024 (UTC)
user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. I actually disagree. I get the main point you're making, but in practice, I find Template:Welcome cookie to be strictly better than literally everything (including Special:Homepage). There are a lot of worse templates, agreed, but tweaking to adjust the templates to better serve your purpose (A simple message saying "You can contact me at [my talk page]")
Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits. That's why I mentioned Snuggle from earlier. If you specifically want "Let us encourage editors who made good editors recently" you may be better off partially or completely reusing codebase that should already exist from before. The project had an interface like WP:Huggle and pointed out newer editors with "good" edits that I could then send welcome messages to. It just was a separate interface that editors had to get used to using, so ended up not actually being used much (IIRC).
if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Like I tried to mention earlier, I think this problem is best solved by breaking down each subproblem separately. I think reviving Hostbot could be good for "Identify lots of promising editors, send them to pipeline of "editors training others". I think Growth homepage is good for "Every new editor sees this" but it needs severe updates to allow experienced editors to interact or help (Teahouse and a bunch of onwiki resources are still not added, there's no enWiki landing page or talk page, there's no WP project page with simple "Here's example screenshots of how the growth page looks", all of those will allow veterans to point out specific things that can be improved). I think there is room for space to grow "Mentor and retain editors who are promising (100+ good edits)", probably an evolution of WP:Adopt in some way. (I don't offhand know what that could be, other than "You could probably ask WP:WER and WP:EotW folks". Those have done excellent work in retaining promising veterans from burnout, simply by encouragement. So I can totally see something similar working for newcomers).
In essence, I'm recommending "Iterate and improve on every subproblem" as a way. "Will veterans use and maintain this space 2 years later" can be very hit-or-miss, but my best guess for increasing those odds involve asking a few Wikiprojects, then improving the projects they are most excited by/most likely to use. Soni (talk) 17:56, 2 April 2024 (UTC)
Interesting thoughts, thank you. They will feed into my work on mentoring and how to help communities in this area.
Regarding pre-formatted messages, my definition may not apply to some messages, but the majority of them are actually not that good across wikis. Even the Welcome cookie one could be improved for the benefit of new users. It is a problem in itself. :)
Anyway, to be continued, probably somewhere else. Trizek_(WMF) (talk) 19:01, 3 April 2024 (UTC)
My favorite welcome template is {{w-graphical}}, which neatly categorizes the links. Aaron Liu (talk) 19:06, 3 April 2024 (UTC)
Oh I completely agree that things could always be improved, I just think the improved templates are really "solid" and cover a lot of useful ground consistently (even if a bit impersonal). I also like automation because I treat this process as a scaling problem.
We probably have thousands of new editors monthly who make a useful edit, a few hundred who stick around for 10 edits, and probably dozens who I'd call "promising" (>20% odds of editing 1 year later, say). Each group requires a different approach to maximise our "odds", simply because otherwise you'd spend a lot of time personalising messages that might never be ever seen.
The more we can accurately go "Okay we have 20 new editors with 50 unreverted edits made over the last month", the more we can focus vet effort on personally interacting/encouraging/mentoring those. And the "They made 2 edits that weren't flagged as vandalism" folks can be handled by automated/semi-automated systems to get them to "Okay this is what talk pages are, also ask questions on this link" levels Soni (talk) 19:50, 3 April 2024 (UTC)
@Trizek (WMF) Also if you'll solicit future community input, I recommend WP:Helpdesk, Wikipedia:IRC/wikipedia-en-help regulars as well. Both locations deal with large volumes of newcomers constantly, so the vets there would know exactly the things that would smoothen their mentoring curve. Soni (talk) 19:54, 3 April 2024 (UTC)
You know that we don't have a common definition of a "useful edit"? The one used is based on reverts: a non-reverted edit after 3 days. We have data about this.
Regarding automated system providing guidance, they could work, but human-to-human interactions are way better to improve retention. We are working on the Wikimedia Foundation's annual plan, and it has a question regarding how we can distinguish ourselves from other platforms. I think the human factor is important there. It doesn't mean that we should not use any form of semi/automated ways of helping users (like we plan to do with Edit check), but we can make a difference on how we encourage new users with a more human -centered approach. Again, it is still a question with no proper answer. Yet!
Trizek_(WMF) (talk) 14:15, 4 April 2024 (UTC)
Oh I completely understand, I'm just making sure to emphasise making it sustainable for human volunteers. The last time I checked the Growth dashboard (6 months ago?) my realisation was that most of the human effort on veterans' end was fairly wasted. You do not want to burn out all your experienced editors trying to reply to everything when it's way more important for the "promising newcomers" (People who have already shown they understand Wikipedia basics AND are sticking around for more than 1-2 days) to get that interaction. I do not believe the latter is happening at all (or enough) right now, so I feel former (Spreading out volunteer attention to everyone) is not helpful enough.
You know that we don't have a common definition of a "useful edit"? I don't know if this is the biggest problem to solve, but I'm fairly confident I've seen something like this before. Snuggle, Huggle, mw:ORES all have some way of judging the quality of edits. I know I've seen this in my Watchlist as well. This is a perfect usecase for this or similar tooling: Decent accuracy but sorts through everything. Soni (talk) 14:33, 4 April 2024 (UTC)
I've often written about the inefficiencies of Wikipedia's discussion processes, and combined with the realities of most volunteer recruiting, where the vast majority of people stopping by aren't going to commit to staying around, agree that recruiting is costly. (There's a commonly used solution for that, but it's not one that I feel the English Wikipedia community is ready to accept: have paid staff do the welcoming and hand-holding.) That being said, I think that's just something that has to be paid to feed the pipeline for maintaining English Wikipedia at its current scale. While I also agree that having tools to help identify promising newcomers would be helpful to target them for retention, I additionally feel we need to work on ways to get more editors to the point where their promise can be evaluated. As others and I have previously suggested, perhaps there should be recruiting initiatives targeting groups whose interests align well with the idea of volunteering to write encyclopedia articles. This can be on a one-on-one personal level (current editors reaching out to people they know who would be interested) and on a higher level, such as trying to get history buffs involved. isaacl (talk) 15:34, 4 April 2024 (UTC)
@Soni, well the sustainability of any program that involve humans to help new users feeling welcomed and capable of editing is precisely the challenge.
My realisation was that most of the human effort on veterans' end was fairly wasted -- could you elaborate on this?
Regarding the quality of edits, there are two different cases: ORES can give a prediction of the intent or the level of damage. It is a possibility to guess if the edit is useful, but it is not qualifying as such for sure. Some obvious cases are immediately identified, but the grey area between vandalism and constructive edits is left to humans' appreciation. If we had a proper definition of a useful edit, the prediction models (ORES or its replacement) would work differently.
Regarding assigning a mentor to active users who already shown apetite for Wikipedia by a few edits could be a mistake. Being a mentor myself at my wiki, I often get questions from users who aren't sure if they can change something on a page. Their very first edit is a question to me. If i put aside SPAs, the majority of them are now active users (even if not regularly).
@Isaacl, if you have any link to your writings at hand, I'm curious to read about welcoming new users.
The Growth team worked on a tool to identify promising users, so that their mentor can encourage them. We tested it at a few wikis, but it is not ready at all for a larger release. We also have plans to assign mentors to newcomers who match their interests, but it is not on Growth's scope for now. Trizek_(WMF) (talk) 14:13, 5 April 2024 (UTC)
I think it's a good idea to try to match mentors to new editors based on common interests, as well as directing new editors towards active groups of editors with matching interests. Unfortunately, many WikiProjects no longer have high levels of engagement on their talk pages, which makes it harder.
I don't think I've written much about welcoming new users. I once wrote down some quick thoughts on active mentorship for new editors. At the editor retention WikiProject talk page, I have discussed selective recruitment and challenges in understanding how to make English Wikipedia more attractive for new generations to edit. (I do not remember where I discussed recruiting from historians/history buffs.) On the general theme of trying to attract people to help out, I've floated an idea for volunteer weeks, where editors host "open house" activities to recruit potential volunteers for specific initiatives. (If you're asking about something else, you might find something relevant on my "Community" user sub-page.) isaacl (talk) 18:08, 5 April 2024 (UTC)
could you elaborate on this? We've actually discussed exactly this last year. I noticed that the Growth dashboard was casting too wide a net, so I got 10 mentees who had never made an edit (and never would again). I don't believes any changes were made from there. And the dashboard continues to not be clear on what "level of editors" you'll get questions from. Veterans are a 'non-renewable resource' so I always prefer them fully knowing what they're signing up for and/or being tapped after there's already a "filter" applied on their potential mentees.
Their very first edit is a question to me I guess we disagree. I would like those editors to also get some assistance, but I personally believe it's way more important to first build a sustainable structure at the "higher levels of the pyramid". That is currently missing, so in my opinion, you are giving good human support to a few thousand editors who edit once, but have nothing for few dozens/hundreds who are already super likely to stick around.
I would rather Growth team's efforts be on building the "newbie to experienced editor" mentorship pipeline for all levels of newcomers, than focus all new initiatives trying to redo fancy new ideas but only for the newest editors. The reason I suggested ORES is because it probably isn't perfect but it's definitely "good" as a starting point. The scale at which enWiki operates, I'll rather have an existing tool that's 70% accurate in iding newcomers, than a tool that comes a few months later. I'd rather WMF spent more resources improving current tooling and reviving good projects with promise, than continue churning out newer plans every few months. Soni (talk) 18:14, 5 April 2024 (UTC)

Timestamp on video references

If a web reference leads to a more than hour-long video, but the citation in question involves a 10-second clip, I believe that could be made more accessible to a reader. I see this being something like an optional field on the web citation, but I’m really not very sure. Aaronlearns (talk) 01:47, 11 April 2024 (UTC)

{{cite video}}? Aaron Liu (talk) 02:59, 11 April 2024 (UTC)
{{Cite AV media}} already has a time parameter. For an example of it being used, see the references section of Half-Life (series). ― novov (t c) 03:02, 11 April 2024 (UTC)
Thank you both for these, sorry to bother.Aaronlearns (talk) 05:38, 11 April 2024 (UTC)
For YouTube videos you could add {{rp}}, as seen at Draft:New York City Jazz Mach61 13:21, 11 April 2024 (UTC)
@Aaronlearns, the |at= parameter works in a lot of the citation templates. It accepts free-form text describing where to find the source. You could easily write something like "starting at 23 minutes, 11 seconds" WhatamIdoing (talk) 02:42, 20 April 2024 (UTC)

Recreating an article that was deleted in 2023

Hi. Am I allowed to try and recreate an article that was (ironically) created by me, but was deleted later, because it didn't have good sources. I'm asking this because I'm not sure if the article will be just automatically deleted. FYI, I have gathered much better references this time, so I was wondering if I could recreate the article with new sources. --Pek (talk) 16:45, 20 April 2024 (UTC)

See WP:REFUND. More specifically it would likely be best to approach the admin that deleted the article and ask that it be recreated in user or draft space, so that you can then add the references. Once you do that, you should then ask that admin if the article is good enough to move back into mainspace. Masem (t) 16:50, 20 April 2024 (UTC)
As Masem said, with the addition that if the article was deleted via the WP:PROD procedure it can be restored to article space, but you may find that it gets nominated for deletion at WP:AFD if you don't add notability-defining sources very quickly. Phil Bridger (talk) 18:36, 20 April 2024 (UTC)
In your place, I would start a new draft, take your time writing it, and when you're done, submit it for review. Gråbergs Gråa Sång (talk) 09:36, 21 April 2024 (UTC)
You can recreate it the day after it's deleted if you want – As long as the content is substantially different and you've made a good faith effort to address the reason for deletion. You can do so via draftspace as suggested above, but you don't have to. Either way, the important things to be aware of are 1) there's also nothing stopping someone else immediately nominating it for deletion again and 2) repeatedly recreating something that other editors don't think should exist is the kind of thing that very quickly exhausts the community's patience. – Joe (talk) 11:16, 21 April 2024 (UTC)

Small utility

https://foundation.wikimedia.org/wiki/Legal:Wikimedia_trademarks/Word_mark_creation contain instructions to correctly create svg wikipedia logo. Is there any chance to create a small utility that contain only 3 fillable fields (first is for project name, second is for slogan and third is for language code) and one button (create svg, which save svg file on desktop), similar to this? 

+------------------------------------------------+
|  __________________________                    |
| |__________________________|    ___________    |
|                                |create svg|    |
|  __________________________     -----------    |
| |__________________________|                   | 
|                                                |   
|  __________________________                    |
| |__________________________|                   |
|                                                |
+------------------------------------------------+


The utility could be used for help graphists to make faster the process of logo creation. --93.47.36.228 (talk) 15:00, 23 April 2024 (UTC)

I'm not really into graphics design, but shouldn't there be more to this? The 🏎 Corvette 🏍 ZR1(The Garage) 16:55, 24 April 2024 (UTC)

Give deletion ability to pagemovers

I believe that the ability of deletion should be extended to pagemovers because there aren't very many of them (406 to be exact) and are probably able to be trusted with the tools. The CSD backlog can be high at times, and there are not very many admins to deal with that issue. 2003 LN6 14:32, 26 April 2024 (UTC)

"Are probably able to be trusted with the tools" is not a great argument given that any admin can add new people as pagemovers, and that the qualifications needed for pagemover are not immediately CSD-related. Plus, giving only one part of the block/protect/delete triad would lead to the law of the instrument. Chaotıċ Enby (talk · contribs) 14:34, 26 April 2024 (UTC)
(Note: Page movers already have the deleteredirect permission, but it is exclusively for moves overwriting previous redirects, and doesn't give them deletion powers outside of the scope of page moving) Chaotıċ Enby (talk · contribs) 14:36, 26 April 2024 (UTC)
One would think that admins were approved by the community because they are trustworthy. Dege31 (talk) 17:50, 28 April 2024 (UTC)
Having only delete but not undelete is pretty bad since mistakes can happen, and WMF wants undelete to only be conferred to those vetted by the community, e.g. admins. Aaron Liu (talk) 15:50, 26 April 2024 (UTC)
It has been years since I last saw a serious CSD backlog (50 pages were normal, and 200 pages were common ten years ago), so I disagree that there is a need for more people at CSD. We generally need more admins for everything, though: those who "are probably able to be trusted with the tools" should just become admins as soon as possible. —Kusma (talk) 17:15, 26 April 2024 (UTC)
As a pagemover I agree, I wouldn't want delete without a way to undo my mistakes, and undelete as it currently exists in the software is not something we should be handing out widely as it can expose plenty of stuff that shouldn't be semi-public. That said, there's no reason that mediawiki couldn't add the ability to view and undelete only pages that you deleted, it would just take community consensus and the WMF to apply time and resources to making it happen. --Ahecht (TALK
PAGE) 17:23, 26 April 2024 (UTC)
This is nontrivial: you should not be able to undelete any revisions except those you have deleted. —Kusma (talk) 17:29, 26 April 2024 (UTC)
@Kusma: Making sure I understand you correctly - if a page that had some revision(s) deleted was then as a whole deleted and then undeleted, you're saying those revdels would be undone? Tazerdadog (talk) 02:34, 27 April 2024 (UTC)
The "undelete" screen shows all deleted revisions. To implement @Ahecht's idea, I think we would need an additional "pagemover-deleted" state that a revision can be in (in addition to visible, deleted and oversighted) and allow pagemovers to see and undelete all pagemover-deleted revisions. —Kusma (talk) 06:33, 27 April 2024 (UTC)
Forgive my ignorance (I'm not an admin) but I wonder whether there is a wider problem here. Putting pagemovers aside for a moment, suppose an admin deletes a page which already had certain revisions deleted. The admin then undeletes the page. Does the admin have to remember to repeat the revdels, or at least deselect them from a list of versions to be restored, or do those revisions stay deleted automatically by default? From an ordinary user's perspective, revision deletion looks different from page deletion. I can see that a deleted revision exists and (unless someone deliberately stops me) see which user contributed it and read the edit summary. For a deleted page that data isn't available without some digging. Certes (talk) 17:55, 27 April 2024 (UTC)
I don't remember how it is with revdel (when I passed RfA, revdel was done by hand, by deletion and selective undeletion, and some people dealt with bad revisions that are nowadays oversighted by a combination of deletion, undeletion and page moves), but if you delete a page, somebody recreates it, then you delete it again (this scenario is more common than undeleting pages that have revdel'd revisions), "undelete" makes no difference between the two sets of page revisions. —Kusma (talk) 18:07, 27 April 2024 (UTC)
Revdelled revisions stay revdelled after a page undeletion. I was pretty certain this was already the case, but I've just confirmed it at User:Cryptic/sandbox4.
What I'd be more concerned about is whether there are old deleted revisions hanging around somewhere at a title that predated the deletion log, which is the only way to find out who deleted it. There don't appear to be any, but revdeletion and oversighting play nasty tricks with what's visible in the toolforge replicas. —Cryptic 20:11, 27 April 2024 (UTC)
Random serendipity. I stumbled across some of those only a few hours ago at XXXDial. But they're just random nonsense that could be made public. Anyway oppose this as having too little to do with page movers' existing rights, but I could be talked into supporting a separate deleter role with many of the same caveats as above. * Pppery * it has begun... 20:15, 27 April 2024 (UTC)
Thanks to you both. I hoped that retaining revdels was too obvious a feature to have been overlooked. Obviously(?) oversight/suppression will be kept too, as most admins won't have the opportunity to restore those revisions in a visible state. Certes (talk) 20:23, 27 April 2024 (UTC)
Oh, duh, I badly bungled my query. Yes, there are lots of these. But on further reflection, I guess it wouldn't matter; since there aren't already any pagemover-deleted deleted revisions to worry about, it could be done by adding a who-deleted-this column to archive. (Not that I think the overall proposal is a good idea either.) —Cryptic 20:26, 27 April 2024 (UTC)
I agree that pagemover is not the ideal role for this, but I think Pppery's deleter role is worth exploring. We could make a role and give it delete. Then we make an adminbot, which will email and/or undelete the page for a deleter on request if and only if they were the most recent person to delete it. This should solve issues with WMF wanting vetting for viewdeleted (the bot only lets you view and undelete stuff you delete), issues with undeleting too much (the bot does the undeletion on the deleters behalf and so can't mess it up), and accountability (the deleter can view their deletions and fix mistakes - there's actually a higher level of accountability than there is for admins, because viewing deleted pages will be logged). This role could get combined with some level of protect/unprotect and block/unblock, but that can be hashed out later. Tazerdadog (talk) 16:03, 28 April 2024 (UTC)
That is an interesting idea, though I still don't see a need for it. Aaron Liu (talk) 16:10, 28 April 2024 (UTC)
There is no need for a separate role. Anyone who wants to be able to delete pages can apply for adminship. The requirements should be the same for deleting articles as for the other parts of the admin package. Phil Bridger (talk) 16:19, 28 April 2024 (UTC)
I think that we can make unbundles that are both useful to the people who recieve them and require a level of trust such that they can be given out at the discretion of a single admin. It would be nice if the RfA process was a good solution, but it is often intimidating or unpleasant. Examples of these unbundles include giving a recent changes patroller the ability to delete a recently created page and use the bot to view/undelete, semiprotect a page temporarily, or block a non-autoconfirmed account temporarily. Alternatively, a regular at AFD who is good at evaluating consensus could be given the delete/use the bot to undelete buttons. AfD is an area where I have noticed significant backlogs. The enforcement on this can be social or technical - giving our AfD regular the full delete permission and a bright line social rule that they don't use it outside of an AfD closure seems perfectly workable to me. Tazerdadog (talk) 16:54, 28 April 2024 (UTC)
Many editors are trusted to behave responsibly but do not claim competence in every single activity that the sysop bit makes possible. Such people are put off applying for RfA but could usefully contribute more if given carefully designed lesser privileges matched to their expertise. Certes (talk) 18:30, 28 April 2024 (UTC)
The ability to delete articles is not a "lesser privilege", but the most powerful part of the admin toolset, because it directly affects what the reader can see. I can't imagine trusting anyone with that power who I would not also trust with blocking and page protection. Phil Bridger (talk) 19:19, 28 April 2024 (UTC)
This bot can't possibly work. As described, it lets you undelete any page: if you weren't the most recent deleter, then you just create it and delete it. It can't even work if you try to make it only allow undelete of pages where you're the only deleter, or only undelete revisions that you deleted: because of the deleted pages from before the deletion log - there are some 70000 of them - it won't even be able to tell that a page had been previously deleted, let alone when or by who. Pages whose deletion logs have been revdelled or suppressed have the same problem. —Cryptic 18:55, 28 April 2024 (UTC)
Wouldn't creating, deleting, and undeleting only show the version of the page one created? Aaron Liu (talk) 19:17, 28 April 2024 (UTC)
I think so too. Any earlier revisions are of a different page that happened to have the same title. Have we missed something? Certes (talk) 19:19, 28 April 2024 (UTC)
That's not how it works. See Kusma's comments above. —Cryptic 19:24, 28 April 2024 (UTC)
1. I'll admit that on re-reading, I don't understand what "no difference between the two sets of page revisions.
2. The user will not have access to the undelete screen; the bot will restore the last version deleted. Aaron Liu (talk) 19:39, 28 April 2024 (UTC)
So if someone replaces, say, Ton with spam, a minideleter deletes it, everyone shows up to his talk page to complain that it was a legitimate page, and he tries to undelete it, he only gets the single revision with spam? And he doesn't even have any way to first check that he's not undeleting spam - or, for that matter, something that should have been oversighted instead of just deleted? That's significantly worse than having no method of undeletion at all. —Cryptic 20:01, 28 April 2024 (UTC)
No. My assumption is that different creations of pages have different histories associated with them, and by "version"' I didn't mean revision, but everything associated with what was deleted by the minideleter (including re-suppressing relevant revisions) Aaron Liu (talk) 20:46, 28 April 2024 (UTC)
Your assumption is incorrect. Once a page is deleted, it's only accessible by namespace+title, and its invididual revisions only by namespace+title+timestamp. This is why history merging works. —Cryptic 22:37, 28 April 2024 (UTC)
The proper amount of history for the bot to restore is everything after the most-recent non-self deletion (i.e. what the minideleter could see when they deleted it). That means that the minideleter should still have the most recent versions of Ton to back up to almost always. The minideleter should be able to have the content eligible for restoration emailed to them, including the history and any revision they could see when they deleted the page, so I'm not worried about that excessively, although it might get annoying if it's complex. The problem is I'm doing basically what @Cryptic: said above - only undeleting revisions the minideleter deleted. Can't an adminbot see revdelled deletion logs? Can a database query get us the 70k pages with deletions that predate the logs? We could just exclude those pages and have the bot tell the minideleter to go get a "real" admin to sort those pages out, or have the bot refuse to restore a revision that predates the deletion log. Are deletion logs actually suppressed, and if they are, doesn't this create a minefield where a normal admin can restore oversighted pages without seeing they can do it? Tazerdadog (talk) 20:49, 28 April 2024 (UTC)
Yes, deletion logs get suppressed all the time, and revdeleted somewhat more rarely - whenever someone puts something suppressible in the page title itself, or in their username. Hiding either part by either method hides the entire log from queries, which means that any way to generate a list of deleted pages without corresponding logs is going to find both the ancient ones and ones where any part of the deletion log had to be removed. There are 1265 such titles in Draft:, for instance, and that's only counting the ones that have at least one deleted revision that hasn't also been revdelled or suppressed. A human will know not to undelete a page titled Draft:Tazerdadog's real name is Aaron Certes and he works for Cryptic Inc., and we can trust them not to because they've gone through seven days of community-wide vetting at RFA. If content like that is only in the page text, the revision will get revdelled/oversighted instead of the log and will remain so even if that revision is undeleted. Admins can see revdelled deletion logs, but have to jump through unintuitive hoops to do so. Forbidding restoration of old-enough revisions isn't a solution either; Wikipedia was already pretty big by the end of 2004, and lots of accidentally-deleteable pages have revisions that old.
This is a complex problem with many, many edge and corner cases, and the places it's most likely to go wrong are the same ones where we can least afford to let it. If we're dead set on doing this - and I don't think it's a good idea even without the technical considerations, at least a quarter of my deletions have to be followed up with a block, salting, blacklisting, or some combination - there are robust ways to do it. An adminbot cludge like this isn't one of them. —Cryptic 22:37, 28 April 2024 (UTC)
Thank you for clarifying. It sounds as if undeletion would be difficult to do correctly and hence unsafe. There's also the issue of undeleting revisions from before a page move, which sounds equally difficult if not particularly unsafe. Certes (talk) 11:55, 29 April 2024 (UTC)
Yep, thank you for the patient explanation Cryptic. I would be interested in hearing what you had in mind as a more robust way to do it - an adminbot was definitely a clunky way to do it, but I didn't expect the level of corner cases. Tazerdadog (talk) 18:45, 29 April 2024 (UTC)
I mentioned one above - add a column to the archive table with the actor_id of the person who deleted each revision. Or add a list of affected revisions to the log_params column of the delete log; that still might break, but doesn't need a schema change, and has the side benefit of making an operation like "undelete all revisions that were deleted by this deletion" possible and be a step toward making history merges less horrific to undo. The common theme is that they fail secure instead of open: if all or some part of the necessary data isn't there, then undeletion is denied. What I don't see is a way to implement this without any change to MediaWiki at all. —Cryptic 19:59, 29 April 2024 (UTC)
Honestly, at this point everything should be unbundled. I support @Pppery's "deleter" right. 2003 LN6 16:16, 30 April 2024 (UTC)
After my RfA passed, I quickly became curious about the contents of all the stupid goofy-ass deleted pages over the years, and set about to looking at some of them. Mostly, what I found is that the user interface for undeleting pages is horrifically bad. My hunch for why this is that, while Wikipedia's famous for being difficult to use, most of its features are exposed to hundreds of thousands of people -- whereas the admin-only features are only usable by a few thousand (many of whom have been using them for 15 years and have no desire to see them changed anyway). This means that not a lot of development time is devoted to fixing stuff like undelete, or making it easier to use, and it's not really that much of a priority (seeing as you only get to use the tools if you pass RfA, i.e. are extremely good at following complicated processes to begin with). Deleted revisions are also a total zoo: all sorts of crazy-go-nuts dreck is in there. jp×g🗯️ 04:53, 30 April 2024 (UTC)
No. There is no backlog worthy of the name at CSD. Even though my time zone doesn't match most admins it usually takes no more than a couple of hours for me to get a response. Don't be in such a hurry, and if you want to be able to delete pages then apply for adminship rather than for the pagemover right. Phil Bridger (talk) 19:13, 26 April 2024 (UTC)

Some form of ECC-style protection for infoboxes or leads

I looked briefly to see if this had been proposed before, and was surprised that I didn't immediately find it. I accept that this could potentially be both annoying technically and hostile socially, but I figure it's worth a shot since I haven't managed to convince myself it's a bad idea yet: for a small subset of articles, specific sections or elements should be eligible for ECC-style protection—namely the lead, specific tables, or specific infoboxes. So much busy work goes into reverting good-faith edits made to infoboxes that frankly in all likelihood will never need to change again—or at least will simply never require changes likely to be made by inexperienced users. I suppose if ECC's 500 edit threshold seems too high for this proposed permission, the proposal would be dead in the water since adding another privilege tier wouldn't be worth it in my opinion.

This should only be allowed for articles that have already passed some form of systematic peer review—i.e. FAs, and maybe GAs following an additional spot-check. Additionally, it would likely be good to require that no material in the protected section is at all time-dependent.

I totally understand that this is a paradigm break for some on its face: in part, the proposal is based on the thesis that some articles can sometimes pass a threshold whereby, purely statistically speaking, the average edit is a net negative, and some classes of edits are almost always deleterious to the article. I worry myself, but I simply cannot convince myself that it's wrong given a sufficiently narrow scope.

You can tell I'm confident in my idea, but am I also evil? Remsense诉 04:57, 1 May 2024 (UTC)

If I'm understanding the proposal correctly, and you are referring to extended confirmed protection (and not protection based on error correcting codes): note it's generally not a good practice to include metadata (such as access restrictions) within the data itself, as this opens up more possibility for vulnerabilities. The protection model is simpler when each protected object is the same type. In the case of Wikipedia, the unit of protection is a page, and transclusion can be used to include the content from one page into another, thus allowing that portion to be protected. However this doesn't keep someone from removing the transclusion from the parent page. isaacl (talk) 06:02, 1 May 2024 (UTC)
Yes, it seems pretty possible that technical restrictions kill this particular suggestion dead. I suppose I still feel like I assume a lot of people did when Wikidata was first getting off the ground: it somehow shouldn't have to be possible that a piece of data gets fat-fingered somewhere and is only wrong on one particular page. We are very certain about what day James VII and II was born—because we are adults that can handle the coexistence of two calendars!—barring changes in consensus regarding formatting, there shouldn't be a single second where that article displays anything in that spot but 14 October until the end of time. Of course, being correct 99.999% of the time is still pretty good, but I'm using this to illustrate the greater headache of deleterious, often good-faith edits falling through the cracks, and staying put for weeks or months before someone notices. Remsense诉 06:35, 1 May 2024 (UTC)
I realise that this wont totally solve the issue that you're talking about but maybe something similar to, {{Not a typo}} (called not a mistake?) could give pause to drive-by editting and could maybe prompt a GF editor to check why that template is there. -- D'n'B-t -- 06:59, 1 May 2024 (UTC)
Hmm. See, would it be fair to say that HTML comments are the rough equivalent of this idea currently in use? Me personally, I'm in the habit of removing almost every embedded comment in articles I'm working on yelling at future generations not to touch XYZ, because they're usually shrill and cumbersome to edit around—unless there's obvious evidence that it's actively preventing improper editing of course. This would be less disruptive, but I think it's more fruitful to consider what it means for parts of Wikipedia to be "done". I am aware this is a conversation that has occurred trillions of times and we have good reasons not to lock down articles for this. To be totally clear, this thread is about remedies to a problem that is not that big of a deal, fully granted. Still, are there ways to "lock" parts of articles that simply don't have to change?
On a related, perhaps more interesting note, could there be more robust ways of transposing information between articles (and maybe with Wikidata)? We already have so much "raw material" on the site in the form of data, prose, references, bibliographies. A ton of what's already sitting in a given article could be "spread around" and used to improve other articles, and that can save a lot of time and effort. How much time do I spend formatting citations for works that are already sitting formatted on some other page, for example? OI don't do a search because I am lazy, but what if there was some tool that made it quicker? Editing often involves looking for sources or paragraphs to crib from related articles: how could we make this part of the process more fruitful? I think a ton of improvement can be made to the site just by remixing work other editors have already done. Remsense诉 07:17, 1 May 2024 (UTC)
Check out {{excerpt}}. Aaron Liu (talk) 10:58, 1 May 2024 (UTC)
Yeah! And that's useful but for a surprisingly narrow band of use cases, basically when you're summary-styling but also don't actually have to shorten the passage? I'm thinking almost of a lighter "templating system" that does no transformations whatsoever and probably just runs client-side—a search bar that's just smart enough so I can type "Han dynasty span AD" and it will spit 202&nbsp;BC{{snd}}220&nbsp;AD directly out into my editor or something. A communal pool of grabbable high-quality wikicode snippets, or also maybe a rudimentary ability to search for existing content in articles and quickly grab and CWW it. No idea, throwing stuff at the wall here. Maybe this is a useful application of neural networks, but I feel dumb even saying that so I'll have to think more about what exactly the scope could be. Remsense诉 11:17, 1 May 2024 (UTC)
Perhaps we write articles in a different manner. I don't look for paragraphs to use from related articles, and look for sources directly, rather than examining those used by other articles. isaacl (talk) 15:51, 1 May 2024 (UTC)
Of course. Sometimes it can be directly incorporated, but is often just an anchor or point of inspiration when writing. Remsense诉 18:15, 1 May 2024 (UTC)
Basically if you want a container to include specific items, then access to modifying the container has to be controlled. So limiting access to modifying a page component translates into limiting access to the page overall. Perhaps one day the Wikipedia community will be more open to restricting edit access more generally, but at present it prefers to allow broader access. Alternatively the page could be composed of pre-defined types of components in a fixed manner, so there is no ability to change how it is assembled. However I think the community is even less open to restricting flexibility in this way, and it would be a significant change from the current page-oriented data model. isaacl (talk) 15:51, 1 May 2024 (UTC)
@Remsense I think this is somewhat similar to the "verify data" function in {{chembox}}. When you take a look at Carbon dioxide and scroll down, you can see a X mark next to "verify" link, and clicking on it will transfer you to a dialog box on Special:ComparePages. After you verify that the data did not change, you can then update the verifiedrevid and that should give you a V mark next to "verify", i.e. the box has been verified. CactiStaccingCrane (talk) 11:35, 1 May 2024 (UTC)
This is good because 1. this idea has been implemented for over a decade and 2. we don't need to hack any new tools to make this work. Maybe we can make a small template similar to one at ChemBox, name it {{verify data}} and wrap it inside the infobox that you don't want the data to change. CactiStaccingCrane (talk) 11:37, 1 May 2024 (UTC)
I also agree that this is a good idea, but a better idea would probably be adding a |verified= parameter to the {{infobox}} template. Blank would mean to omit verification, and specialized infoboxes can default to setting the parameter to zero to display verification. Aaron Liu (talk) 19:05, 1 May 2024 (UTC)
Oh, yes! Very low-tech in the best possible way, I think you're onto something here. Remsense诉 18:15, 1 May 2024 (UTC)

Further extended confirmed

Hi. I feel that the current user access level system is somewhat flawed. There's not really a "in-between" right between extended confirmed and adminship. Although users can apply for advanced roles at WP:PERM, there isn't a general confirmed role for more experienced editors.

Therefore, I'm starting this discussion to discuss the idea of a new user right: the Further extended confirmed (I couldn't think of a better name, please help!), which is automatically granted to users with 5000 edits. Users with this right will be able to:

  • Apply for adminship (EC users will no longer be able to do so, as the average edit count for a successful RfA candidate is somewhere around 9000)
  • View hidden edits in a page's history
  • Delete pages with less than 10 edits and are less than 500 bytes long
  • Create a salted page
  • Other abilities (please discuss!)

Basically, a FEC user will be able to do some simple tasks currently exclusive to admins, which gives admins more time to carry out complex tasks. Please give your thoughts below! '''[[User:CanonNi]]''' (talk|contribs) 07:40, 2 May 2024 (UTC)

@CanonNi user groups are bundles of permissions, and we can't create permissions here (they have to be made in the software that powers all mediawiki sites). For your list:
  1. This can just be done with a rule, it wouldn't really need a technical control.
  2. The Foundation requires this access be restricted to people "elected", so we can't just bypass that here
  3. This type of permission doesn't exist, you would need to develop it in software before we could issue it (i.e. be able to use delete, but only in some cases)
  4. This type of permission doesn't exist, you would need to develop it in software before we could issue it (i.e. be able to use protect, but only in some cases)
— xaosflux Talk 09:27, 2 May 2024 (UTC)
There is a good idea here in principle. For example, I've had legitimate reasons for creating a blacklisted page (slightly different from salted), though an admin did it for me without fuss. As you suggest, the details need some work. Adminship might still be appropriate for someone with few edits on enwp but a good track record of adminship on other projects. Viewing hidden edits might create legal problems: we hide libel etc. for a reason. A 500-byte limit for deleting pages, even if our software were capable, could be easily circumvented. Certes (talk) 09:29, 2 May 2024 (UTC)
I'm not sure edit count deserves any further elevation as a proxy measure of editor quality/trustworthiness. It's already quite gamey. Barnards.tar.gz (talk) 11:13, 2 May 2024 (UTC)
Not a good idea at all, having a high edit count isn't proof of the level of competence needed for this. Also, the WMF requires that people with viewdeleted be vetted by the community. I don't see any reason to automatically be given this type of permission by edit count alone.
Giving intermediate permissions before adminship (or even a permission bundle, cf. proposals at WP:Moderators) is an idea that has been discussed already and can still be considered, but it really shouldn't be by edit count alone.
Also, some of the permissions don't really make sense. Salted pages aren't salted so that only admins can be able to add their preferred content, but usually as a result of disruptive attempts to recreate it. And admins are the ones specifically trusted to not recreate it without (likely) community consensus—a trust that doesn't automatically come with a certain level of edit count. A good admin shouldn't use their privileges to unilaterally create a salted page. If there's a reason to recreate it, asking and getting consensus on why the situation has changed can just as well be done by anyone. Chaotıċ Enby (talk · contribs) 12:52, 2 May 2024 (UTC)
There seems to be a common theme running through this and several other threads that I've seen on discussion boards recently - that people want some of the powers reserved for admins but don't want to go through WP:RFA. It would be better to discuss reforms of the adminship process, so that trusted people want to be and are made admins, rather than for us to have a form of semi-adminship. Phil Bridger (talk) 18:04, 2 May 2024 (UTC)
This would in theory be a good idea but I don't know if it will be workable. Some things such as viewing hidden edits aren't going to work due to WMF policies. User3749 (talk) 05:36, 3 May 2024 (UTC)

Publications on watchlist

Editors interested in regular internal publications such as Signpost, Tech News and the Admins' Newsletter can subscribe to receive messages on their user talk pages. This suits many editors, and should remain as the default method, but the watchlist could provide a simpler alternative. Watching WP:Wikipedia Signpost will notify me of each new issue. However, it also fires every time someone makes a comment on its talk page which may be valuable to Signpost writers but not of direct interest to me. That wouldn't work for Tech News, where the relevant page is on another wiki, nor for WP:Administrators' newsletter/Current issue which magically transcludes the latest edition without any change to its wikitext.

Would it be sensible to create a dummy page for each regular publication, perhaps in WP: namespace, and add it at the start of the relevant mass message list? That way, anyone wishing to be notified of a new edition can simply watchlist that page without troubling the bot or having their user talk cluttered. Old editions could either be archived, left in place or ideally replaced by the new edition in a single edit, though I don't expect the mass message bot could do the latter. Certes (talk) 20:43, 2 May 2024 (UTC)

If they posted an announcement at a designated page, you could watchlist that page, or (if it's a talk page), use mw:Help:DiscussionTools#Topic subscriptions to get an Echo/Notification about it.
The method that works best for me is to notice the deliveries on other people's talk pages. WhatamIdoing (talk) 21:01, 2 May 2024 (UTC)
Yes, I'm doing that, though it's a bit hit-and-miss. I recently lost one accidentally by unwatching the talk page of the last subscriber I followed (or perhaps they just unsubscribed). Certes (talk) 10:15, 3 May 2024 (UTC)
An alternative would be to have a dummy account subscribed to each publication (called something like User:Signpost publications), so you could follow their talk page? Not sure how policy-compliant that would be, but hopefully it could be implemented. Chaotıċ Enby (talk · contribs) 21:08, 2 May 2024 (UTC)
An alternative is "newsletters" and you can see how they look here: mw:Special:Newsletters. — xaosflux Talk 21:21, 2 May 2024 (UTC)
I watchlist Wikipedia:Wikipedia Signpost/Templates/Issue, which I believe was setup for this purpose.-Gadfium (talk) 22:30, 2 May 2024 (UTC)
For future reference, putting Wikipedia:Wikipedia Signpost/Templates/Issue on your watchlist is one of the documented methods on the Signpost "subscribe" page. (Unfortunately, there are some layout issues with the current format; they're being discussed on the Signpost talk page.) isaacl (talk) 23:08, 2 May 2024 (UTC)
Thanks; I've changed my watch entry to that page. It seems that Signpost has already implemented for itself the solution that I'm suggesting for wider use. Certes (talk) 10:17, 3 May 2024 (UTC)
When I re-established the Wikipedia:WikiProject Baseball newsletter, I set it up in the same way as the Signpost: Wikipedia:WikiProject Baseball/Outreach/Newsletter/Current issue number is updated to release a new issue, which causes Wikipedia:WikiProject Baseball/Outreach/Newsletter to transclude the latest issue. Wikipedia:WikiProject Baseball/Outreach/Newsletter/Current issue number in turns transcludes the newsletter when viewed directly, so watchlisting it and then visiting it from your watchlist will show you the latest issue. (Side note: the newsletter is on haitus once again.) isaacl (talk) 23:18, 2 May 2024 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_56&oldid=1234523766"