Wikipedia:Village pump (idea lab)/Archive 51

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

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

Years articles and timelines: Combined or split?

As articles like 2002 are destubified, they end up in a situation where half of the article is prose and half is timeline. This has been mentioned at WP:YEARS, but there hasn't been any community discussion. I'd like to get feedback on whether the timeline and the prose should be kept in the same article, or if the timelines should be split to create articles like Timeline of 2002. And if the latter is the better option, should we write prose for 2005 and then split, or should we move 2005 to Timeline of 2005 to preserve article history and then create a new article in its place? I just want a sense of where the community stands on this or if there are any other thoughts on the matter before I consider doing any drastic reorganizing. Thebiguglyalien (talk) 02:28, 2 September 2023 (UTC)

split, the prose thing is a great idea, makes it look a lot more cleaner and more great and along with the collages make the article a lot more updated and a lot more awesome, and whenever prose get written split off the timeline of said article. I mean, it sucks the WP:years thing had been stonewalled for over 10+ years, and I'm happy we're getting progress of fixing that and making these articles a lot more updated to modern Wikipedia standards. 4me689 (talk) 04:51, 2 September 2023 (UTC)

Not sure I see the case for a split -- is there a particular problem it intends to solve? The 2002 article isn't that long, though 2001 is. In practice, there are tricky consequences in the decision to interpret year articles as should-be-articles rather than should-be-lists in the first place, because we've spent 22 years developing reader expectations that they're lists. There are a few complex reader-expectation-things that I'm currently working towards structured research of the impacts of, e.g. our formal cautions against controversy sections don't coincide very well with the fact we have and have had so many such sections it's where readers expect to find the relevant content. If the thing readers are looking for at 2002 is "a list of events that happened in 2002", then moving that to "Timeline of 2002" is a net negative, because the useful-to-genpop article is at the less intuitive title (consider the Genetics vs Introduction to genetics issue, where the first article has over ten times the views of the second, and the second is the one any general reader has a chance in hell of understanding). If the thing they're looking for is a prose explication, maybe that's fine. If we don't know yet what they're looking for... Vaticidalprophet 10:21, 2 September 2023 (UTC)

I can certainly get where you're coming from, people may get confused that they are a list and not a prose article. I can see certainly something like the 2001 article being split but not the 2002 article based on what events happened on that year, WP:SIZE, and WP:SPLIT (just like when we split off the death sections of year Articles post-1980) in my opinion overall we should add prose to every year article post 1980 and see which ones need to be split from there. and if people are interested in a timeline, we can do something like we do with deaths, we can just add the timeline section as a redirect to the Timeline of xxxx article. 4me689 (talk) 20:31, 2 September 2023 (UTC)

I've raised this issue a couple times now and there doesn't seem to be much interest. I'm wondering if this means the community is fine with pretty much whatever, or if it means an RfC needs to be drafted. Thebiguglyalien (talk) 17:47, 6 September 2023 (UTC)

@Thebiguglyalien I would say draft a RFC if you feel like some change is needed, which I'll be happy to open a RFC on this issue, otherwise just leave the discussion here. 4me689 (talk) 19:09, 6 September 2023 (UTC)

I guess my opinion is that a mixture of prose and timeline in a single article is not inherently problematic. I think it's probably best to present information in the framing that best suits it, and also in the context that best suits it. Sometimes this results in big tables or long lists in an article that's mostly prose, or long introductory paragraphs in an article that's mostly data, and I think this is healthy and for the best. Folly Mox (talk) 23:11, 6 September 2023 (UTC)

Tool for integrating CC-BY video clips into Wikipedia articles

In my capacity as a volunteer, not as WMF staff, I was thinking about creating a tool that could help editors (including myself) to A. pull relevant clips of CC-BY licensed videos into Commons

B. Streamline a process of finding articles the video clip might be relevant for

C. Help generate the citation to the video.

Overall, my goal would be to add more relevant video to Wikipedia since that is a complaint by younger users and people more used to rich media sites. I

I do realize that there are some editors who don't like video. And also, there are some problems that make video much more difficult to be relevant to an article than text that can be easily edited. I'm posting here in hopes that people who think this is a good idea could suggest functionality and people who think this is a bad idea can explain their rationale to help me scope this better. Again, this isn't an official project, but I was pretty inspired by the success of Wiki Loves Broadcast, and thought this could be a way I could help.

Finally, I think the beta would work specially with YouTube CC-BY labeled videos and the proof of concept would be limited to videos that already are created by reputable sources that are openly licensed. SSpalding (WMF) (talk) 04:15, 26 August 2023 (UTC)

• I think this would be great for younger people in Western democracies. But I'm just mindful of how much of our audience is in less developed countries, accessing content on phones and dealing with limited bandwidth. Often English is a second language and such users benefit from being able to read at their own pace. Incorporating more media content would be a disservice to those users.—S Marshall T/C 09:12, 26 August 2023 (UTC)

  I'm not against the idea of adding more media to articles, but I do think there should be some mechanism where the reader has to decide to load video content rather than having it load by default. I'm not in a less-developed country, but I do pay for my bandwidth, and I'm not going to watch videos from encyclopaedia articles, so forcing my device to download the content is something I'd prefer not happen. Folly Mox (talk) 17:32, 26 August 2023 (UTC)

  To my knowledge this is already how it works. Loading an article with an embedded video only loads the video thumbnail image, in the same way that loading an article with a large embedded image (like, say, the 273.61 MB File:The Night Watch - HD.jpg) only loads a much smaller thumbnail, not the full-size original. Video content should only start streaming when the reader clicks on the video thumbnail. :) Shells-shells (talk) 00:34, 27 August 2023 (UTC)

  Oh that's a relief. Sounds like I don't have any other concerns about adding multimedia. Folly Mox (talk) 02:43, 27 August 2023 (UTC)

• I have lots of video clips that I think would be useful in articles, but uploading them to Commons is a huge pain because of the need to convert them to a license-free format. An automated way to do that would be very helpful.--agr (talk) 00:45, 29 August 2023 (UTC)

  Yes, the restriction on .mp4 is pretty limiting, but from my understanding it is there for patent licensing/royalty reasons so it probably won't change until those patents expire in a couple years. If I work on creating the tool, it probably won't natively do file conversions since that might be too complex for a version 1.0. that said, I'm curious to know more about this barrier. There are quite a few bulk file converters online as well as downloadable freeware for conversion.

  Is it the extra step and friction of going to one of these online converters or downloading this software that is the biggest barrier? Or is it something else? Thanks! SSpalding (WMF) (talk) 04:06, 30 August 2023 (UTC)

This is probably what you meant, but to clarify just in case: In the RfC about adding full or partial MP4 support to Commons that the WMF's Multimedia team (RIP) launched in 2014, it was stated that "the Wikimedia Foundation's legal department has evaluated the situation and determined that the licenses that would be required for our use (AVC video encoding and decoding from MPEG-LA, as well as AAC audio codec from Via) have acceptable terms." Community members rejected that RfC mainly because of free software principles, although some remaining FUD concerns about patent royalties played a role too.

What's more, if m:Have the patents for MPEG-4 Visual expired yet? is to be believed, at least some MP4 patents have expired somewhere since, and a 2019 RfC showed overwhelming community support for server-side transcoding of MP4 at least (an option that had been rejected in the 2014 RfC). Regards, HaeB (talk) 07:40, 30 August 2023 (UTC)

The video2commons tool already does much of this and is widely used (although it could probably use some more developer love [1][2]). Regards, HaeB (talk) 07:40, 30 August 2023 (UTC)

Thanks. I might see what ways my idea can dovetail with this since it has at least half of my ideal functionality. I'm curious why it isn't more used, well-known (considering so many articles that could have existing CC video integrated don't) SSpalding (WMF) (talk) 11:58, 3 September 2023 (UTC)

@SSpalding (WMF): Well, I think that there's a lot of videos on YouTube mislabeled as CC-BY, so license laundering is a risk to consider. QuickQuokka ^{[⁠talk • contribs]} 22:03, 11 September 2023 (UTC)

Knowledgeable users tagging template

Hello, I want to draw your (users of the English Wikipedia) attention to one of the most useful Templates we have in the Hebrew Wikipedia, in a hope you will find it useful as well. The template is called בעלי ידע (which means, as far as I can translate, "knowledgeable (users)"), and it allows everyone to tag a group of users who defined themselves as knowledgeable in a certain topic. for example, {{בעלי ידע|שפות שמיות עתיקות}} ({{Knowledgeables|Ancient Senitic languages}}) tags the users who added themselves to תבנית:בעלי ידע/שפות שמיות עתיקות (Template:Knowledgeables/Ancient Senitic languages). Although tagging participants of a certain Wikiproject can help, a template specifically intended for tagging that can include knowledgeable users who are not active in a wikiproject can be much useful.

Some specific issues: the template is called "knowledgeable(s)" and not "experts" for a reason, it is not a template for expert and it is one of its most important features, it allows users to add themselves based only on their own definition - anyone who feels he(/she) can contribute in a certain topic can add himself. There is also no rule that forces using this template in any kind of disscution, it completely depands on the users' judgement, and it can be used in article name-changing proposals, deletion voting and even for the smallest questions ("What does this Greek word mean?"). It can however raise some issues in sensitive topics, such as users who allegedly‏ added themselves to the LGBT knowledgeable(s) template in an attempt to influence votings to the anti-LGBT direction (see here), we didn't solve this kind of issues in the Hebrew Wikipedia but you might want to discuss them before creating the template.

I hope you will adopt and benefit from it. פעמי-עליון (talk) 22:43, 13 September 2023 (UTC)

Pros and cons of abolishing ITN

The idea lab is not a place to !vote. Please discuss the idea presented. Requesting change, including abolition, should be effected at WP:VPPRO if/when there is a general feel for why there is support or opposition to the idea. Izno (talk) 04:32, 23 August 2023 (UTC)

Per above, that's not the place; here. I don't find the "dumpster fire" aspects of it that bad, as a filthy bastard myself, though I certainly appreciate what others at AN/I have reported seeing. I mainly posit that the Current Events portal is already a far superior alternative. For a reader, there's a longer blurb with the parent article (or articles) and checkable news source right there, far more of them and they show up on time. For an editor, what hassle? In short, Support. InedibleHulk (talk) 23:32, 22 August 2023 (UTC)

(RD readers, likewise, get all the benefits of all the death blurbs at Deaths in 2023, unless they consider the photo and viewing one dead celebrity as better than the rest a "benefit".) InedibleHulk (talk) 23:37, 22 August 2023 (UTC)

I've been here many years and barely knew that such a thing existed. How does that motivate the creation of or improvement of articles? (an actual question) 331dot (talk) 00:01, 23 August 2023 (UTC)

It doesn't address that issue. InedibleHulk (talk) 00:12, 23 August 2023 (UTC)

• Support. I'd be entirely okay with losing ITN, and its space on the front page should not be replaced by something like the current events portal. A link, maybe, but not any meaningful space. Wikipedia struggles with WP:NOTNEWS: there are thousands of articles about random non-notable events where the only sources are the news coverage from when it happened. Things like ITN and the current events portal incentivize this and give users misunderstandings about what's expected before an article is created. Thebiguglyalien (talk) 00:04, 23 August 2023 (UTC)

  One person's "random non-notable event" is another person's very notable event- which is kind of the root of the issues at ITN. 331dot (talk) 00:08, 23 August 2023 (UTC)

  If someone wants to challenge what's "notable", then they can propose a change to WP:N or WP:NEVENTS. Until then, those are how we decide whether an event is notable. Subjective opinion about "significance" should not come into play (something ITN struggles with). Thebiguglyalien (talk) 01:42, 23 August 2023 (UTC)

  Yeah, I don't know what we'd put in the top-right corner of the Main Page, I just meant we wouldn't be leaving our fans in the cold (if we even have fans). InedibleHulk (talk) 00:12, 23 August 2023 (UTC)

  Maybe a big stylized link to WikiNews? Edward-Woodrow :) _[talk] 21:28, 23 August 2023 (UTC)

  Edward, I literally doubled over laughing because that very thing used to exist in the middle of ITN. It was removed in 2013, following this discussion, another incident in certain Wikipedians' years-long crusade to destroy Wikinews (in my opinion, they aided in weakening Wikinews, but it is not an ex-project yet). This crusade included a coordinated trolling campaign at Wikinews in 2010, The Signpost's glorification of a 2011-2012 fork, the OpenGlobe, and a 2012 formal attempt to close the English Wikinews, shot down by LangCom within hours. The late Pi zero said it better than I can in this discussion about links to Wikinews. Heavy Water (talk • contribs) 05:06, 13 September 2023 (UTC)

• I would disagree with any proposal to abolish that doesn't keep RD (Recent Deaths) alive. RD is working fine, discussions remain cordial and productive, and serves as a great venue to encourage content creation and improvement. Curbon7 (talk) 00:07, 23 August 2023 (UTC)
  • I think Ongoing also works reasonably well. Perhaps we should replace the main aspect of ITN with "Topical high quality articles"? For example, if someone was willing to improve the article, during the Olympics we could link Olympics. BilledMammal (talk) 00:12, 23 August 2023 (UTC)
• Oppose I don't see how this makes Wikipedia better, as I'm often drawn to articles I didn't know about. We should be focused on identifying the toxicity, which I was also unfamiliar with. SportingFlyer T·C 00:10, 23 August 2023 (UTC)

  I'm very familiar with the toxicity and I'll tell you identifying it makes it happen. Not an argument. Just advice. InedibleHulk (talk) 00:19, 23 August 2023 (UTC)

• Support - Wikipedia shouldn't deal in "breaking news" at all. Even sources which are normally very high-quality and highly reliable are terrible at breaking news reporting. Encyclopedias are not newspapers and Wikipedia should wait to write about current events until the reporting on those events stabilizes; ITN essentially showcases our least stable content, and that most likely to contain errors, on the front page. I for one would not be sad to see it go. Ivanvector (^Talk/_Edits) 00:22, 23 August 2023 (UTC)
• You can't have your cake and eat it too. There are some that want to say that news articles are all primary. This is the logical conclusion of that effort. Even though, it brings in tons of page views and provides a valuable service. --Rschen7754 00:38, 23 August 2023 (UTC)

  That's not how I got here. I think a news story is secondary coverage of its interview subjects' accounts (besides news that reports on news stories). I'll let one of the numbers guys field the traffic part. InedibleHulk (talk) 01:21, 23 August 2023 (UTC)

  WP:Secondary does not mean secondhand. Please read WP:PRIMARYNEWS. Most newspaper articles are primary sources. WhatamIdoing (talk) 19:22, 24 August 2023 (UTC)

  That "some" includes the entire field of historiography (as explained here) and our own Wikipedia policies (as seen here). Thebiguglyalien (talk) 01:39, 23 August 2023 (UTC)

Strongest possible oppose -

Is in the news fundamentally broken?

Yes

Is the answer to do away with ITN?

No

Let's keep it real, this is more than sour grapes [sic] by a few people (most of them who I've never seen contribute to ITN, by the way) who are annoyed that people at ITN disagree, as @DarkSide830: claims; are Rockstone35 (talk · contribs), Banedon (talk · contribs), and Levivich (talk · contribs) not (or at least were) ITN regulars (btw, the reason why I'm mentioning them is that they both support dissolving ITN)? Let's not pussyfoot around this anymore; that's exactly how we've landed in this predicament in the first place. The writing has been on the wall for probably years, definitely for as long as I've been on ITN. I knew that eventually, we'd luck out and the leeway the rest of the community has kindly and gracefully bestowed upon us for years would run out. This is the product of years of incivility, refusal to compromise, user laziness, and a fundamental inability to put our foots down and seriously address the fact that ITN is structurally broken and needs serious reform, something that almost all ITN regulars openly acknowledge, and yet effectively refuse to tackle. You're part of the problem, I'm part of the problem, WaltCip is part of the problem, The Kip is part of the problem, and everyone else that regularly contributes to ITN is complicit and has enabled and facilitated all of this. As we hurdle insults and disrupt ITN, we ought to seriously stop and think, humble ourselves, and learn that our actions, if continued, will be terminal for ITN.

To the rest of the community - listen, I understand that we have seriously dropped the ball for years now. We have definitely failed to understand the assignment for a while, and I wholeheartedly understand why many of you have reached your limits and are calling for ITN's abolition. If I was a non-ITN regular, I would call for ITN being marked as WP:HISTORICAL; hell, there have been times that I have been seriously disillusioned with the mini-project and had seriously contemplated just leaving and diverting energy towards other areas of the project. I understand y'all's plight. I just want y'all to know that we can do better, and we can have capacity to finally pull through and repair the decaying husk that is ITN, hopefully utilizing your input. With greater leadership, from both admins and regular users, from regulars to external editors, we can reform to ITN, especially since this genuine threat of deletion should likely be waking people up. I at the very least promise to combat the rampant culture of toxicity and collaborate to make a better ITN. For all the bad rep ITN somewhat deservedly receives, many on the project also appreciate it for introducing them to topics they would have otherwise know nothing about or highlighting quality articles, in spite of its many, many flaws. In the news can be reformed; for all the disruption it bears, there are many brilliant regulars who can help turn the direction of this mini-project, she just needs at least one more chance. — Knightoftheswords 04:26, 23 August 2023 (UTC)

Knightoftheswords281, I appreciate the sentiment and agree with much of it (even though we came to different conclusions). But could I ask that you avoid using specific names to identify "the problem"? Even if you're dividing the blame equally, it's not productive. Thebiguglyalien (talk) 05:24, 23 August 2023 (UTC)

• Oppose. I have been away for some time and have not had a chance to come up to speed on the events from the last few weeks. ITN does have a few problems, but the answer is not doing away with ITN. On an urgent basis -- we need additional admin hands on ITN and also we need technical / technology support (e.g. folks who can update templates, come up with promotion queues and the like). My technical roadmap / backlog will be as below:

1. Trending topics support
2. Photograph rotation script
3. Automatic queuing and promotion (doing away with the need for admins to promote non-contentious articles like RD, allowing editors to do this and hence freeing admin capacity)
4. Template edits to seek inputs on quality separate from significance (which is more than half the daily battle between editors)
5. And, replacing the easter egg link that has "Ongoing" linked to portal current events.

So, if you know of some technology hands -- please send them our way at WP:ITN Ktin (talk) 00:44, 23 August 2023 (UTC)

I'm not sure #3 is tenable and is certainly beyond the scope of this discussion, since these items will be featured on the main page; even DYK's queues are cascade-protected. Regardless, I like the rest of this idea; the photo rotation in particular should be something that is quite straight-forward to do, as many portals do something like this. Curbon7 (talk) 01:09, 23 August 2023 (UTC)

Sure. Re: #3 -- maybe promote to a holding area and have an admin come-in periodically and promote from the holding area. Just throwing it out there. Irrespective, I strongly believe we should not throw the project away. Urgently need some technical hands who can come-in and get some of the low hanging fruits out. Ktin (talk) 01:20, 23 August 2023 (UTC)

• Oppose. This whole debate feels like sour grapes by a few people (most of them who I've never seen contribute to ITN, by the way) who are annoyed that people at ITN disagree and that things don't perfectly all of the time. I for one also like CE, but the solution here is just to find a better solution on linking to it, which, yes, has been hard in the fast, but perhaps this situation just shows we need to revisit this issue in particular. DarkSide830 (talk) 01:41, 23 August 2023 (UTC)

  Linking to CE isn't a problem. It's already "Ongoing". If that box disappears, there may be a problem, but one for another venue. And I'm not annoyed or anything. Just seems more practical without. InedibleHulk (talk) 02:03, 23 August 2023 (UTC)

  I'm nor referring to you, regardless of whether or not this is your proposal. I'm referring to several persons who have previously voiced support for removal at ANI. DarkSide830 (talk) 18:05, 23 August 2023 (UTC)

• Oppose. Let's not throw the baby out with the bathwater. There could be a better system in place with different criterion, but ITN is a great way for me to learn about current events. I would propose somehow streamlining CE & ITN, because navigation at the moment is difficult. JuxtaposedJacob (talk) 04:12, 23 August 2023 (UTC)

  Difficult how? InedibleHulk (talk) 04:33, 23 August 2023 (UTC)

• Rather this than outright eliminating subjective notability for blurbs (so, I guess weak support?) we are, ultimately, an encyclopedia rather than a news agency or especially a "For You" trending page; as such, any news coverage on the Main Page ought to be concerned with things of genuine significance. I got the mop on ITN credentials, and see nothing wrong with the status quo, but if push came to shove a replacement might be in order, either to a Current Events portal or who knows what. – John M Wolfson (talk • contribs) 04:38, 23 August 2023 (UTC)

1. Keep ITN, block everyone who has posted there >100 times in the last 365 days Ceoil (talk) 05:36, 23 August 2023 (UTC)

   I'll be sorry to see AnomieBOT go. —Cryptic 05:49, 23 August 2023 (UTC)

   I support this idea but I think 122 would make a better threshold. Levivich (talk) 05:56, 23 August 2023 (UTC)

   I don't know how serious you are, but I've officially summarily resigned and think this wouldn't be a bad idea, for a limited trial period. I'm thinking a fortnight sounds feasible. That's two weeks. InedibleHulk (talk) 05:57, 23 August 2023 (UTC)

• Proposing closing this discussion for now to give the above thread room to breathe. I think we should focus on discussing how we could improve things before discussing throwing the baby out with the bathwater and calling it a loss. Curbon7 (talk) 05:55, 23 August 2023 (UTC)

  I think people can focus on the idea that most interests them, organically. Should, though? I won't fight you on it. InedibleHulk (talk) 05:59, 23 August 2023 (UTC)

• Oppose. ITN provides a useful service and does not appear to be broken / in need of fixing. Solution in search of a problem. By the way, if this isn't ready for support/oppose !voting, perhaps this should be removed from T:CENT, and/or the section heading Abolish ITN outright should be changed so that it isn't a yes/no question. –Novem Linguae (talk) 06:08, 23 August 2023 (UTC)

  "Pros and cons" look alright, no "outright"? InedibleHulk (talk) 06:13, 23 August 2023 (UTC)

• Oppose — Per Novem Linguae. elijahpepe@wikipedia (he/him) 06:27, 23 August 2023 (UTC)
• Why on Earth are so many experienced individuals who should know better (and at a minimum, be capable of reading the rules at the top of the page), bold voting? To give some non-bolded commentary, I would say that for this proposal to have merit it really needs to show that the community is prioritise NOTNEWS when our editing aspects indicate against it. If we're more annoyed by the execution of ITN, then the section above this one is the place to go. Nosebagbear (talk) 08:35, 23 August 2023 (UTC)

  Same reason "only affects one country" votes are made, and credited, at ITN. Nobody gaf. This is why Wikipedia can't have nice things. Levivich (talk) 16:14, 23 August 2023 (UTC)

• Comment what I would say is that ITN's original aim (to encourage the improvement of currently-relevant articles) is really not obvious. It looks to anyone from outside as though its aim is the same as a newspaper's headline. Abolition might be a bit drastic. Are there better ways to align it to its real aims? I'd say this debate (on whether to abandon it) is premature. Let's sort out whether it can be made better first. Elemimele (talk) 11:30, 23 August 2023 (UTC)
• STOP VOTING. If you want this to be a vote, this needs to go to WP:VPR and NOT here at idea lab. Cheerio, ⛵ WaltClipper -(talk) 17:10, 23 August 2023 (UTC)

  Support, this is not the place for voting TheRealOj32 (talk) 01:56, 11 September 2023 (UTC)

• As someone who never looked behind the curtain of ITN I have no opinion on its state. But I would like to comment on some arguments. As far as I can see criticism of ITN seems to be based more or less on three criticisms: (1) objection in principle based on (some variation of) WP:NOTNEWS; (2) the claim that ITN is toxic; (3) the claim that ITN has become unmoored from the rules. In my opinion of these only (1) can reasonably be the basis for an argument for the abolition of ITN. If the only way to address (2) and (3) is to get rid of ITN then we have a dramatic and worrying failure of enforcement of policies and guidelines. -- Random person no 362478479 (talk) 17:15, 23 August 2023 (UTC)

  If you looked behind the curtain at ITN, you'd find we have a dramatic and worrying failure of enforcement of policies and guidelines. Levivich (talk) 17:17, 23 August 2023 (UTC)

  Has anyone gone to ANI to say that policies are not being enforced at ITNC? 331dot (talk) 17:29, 23 August 2023 (UTC)

  Lol, um, yeah, like the thread that we were just participating in before you opened the discussion above, WP:ANI#In the news discussion of Lucy Letby. There have been a few others, too. Levivich (talk) 17:36, 23 August 2023 (UTC)

  I considered doing so a few months ago, but I worried that ANI-drama might make the situation worse, so I made a post at the Village Pump: Wikipedia:Village pump (policy)/Archive 182#Wikipedia guidelines and In the news. ITN is entirely divorced from Wikipedia's usual consensus processes and understanding of weight/notability/OR. Of course, there have been many sitewide discussions about the issue, including the one I made and these two that are now side by side. There's general agreement in these discussions that ITN needs change, but no meaningful change has ever come from any of them. Thebiguglyalien (talk) 19:49, 23 August 2023 (UTC)

Pros for abolishing. It's a short term newspaper, the opposite of Wikipedia is supposed to be and by having linked articles also encourages articles to be newspapers. It also pushes more enclopedic items below the fold. Pros for keeping: I find it to be very useful, always read it, and find the articles that it links to to be far better and having more thorough coverage (except for lacking images) than what any US news media outlet produces. North8000 (talk) 18:22, 23 August 2023 (UTC)

• We should outsource any news-style content to Wikinews– a project built exactly for that purpose. I understand the idea: to highlight quality articles that are recently relevent – but it's too much like, well, news. Edward-Woodrow :) _[talk] 21:31, 23 August 2023 (UTC)

  It's already common practice for dictionary definition articles to be deleted and the creator pointed toward Wiktionary. I would fully support a similar practice for articles where all of the sources are news coverage of the topic. If no one is writing about it in journals, books, or retrospectives, then it's not an encyclopedic topic: it's just one of the countless news stories that get printed every day. You'd be surprised how many articles we have about individual car crashes and traffic accidents (I'll give you a hint, it's in the thousands). Thebiguglyalien (talk) 22:38, 23 August 2023 (UTC)

  Yes. PLEASE. This would be amazing casualdejekyll 04:04, 24 August 2023 (UTC)

  casualdejekyll Unfortunately, even if this were to become common practice (which is a long shot), it doesn't help with the thousands upon thousands of other random irrelevant events that still need cleanup. They need a concentrated effort, because my past attempts and other related discussions have only identified that there's a problem, but a solution is harder to come by. Thebiguglyalien (talk) 06:39, 24 August 2023 (UTC)

• Given the strong opposition to "abolishing" ITN, I doubt anyone would get very far with that platform. Abolition, in general, may be a less palatable idea than incremental reform, wouldn't you say? Why not pivot to a more constructive idea. Andre🚐 21:38, 23 August 2023 (UTC)

  The reason we are here is because people seem to have lost faith in such reform, which is sad honestly, but that doesn't make TNT the correct approach. Perhaps that this comment comes from someone who does not appear to be a frequent ITN contributor shows that we need to cast a wider net and have more participation in general at ITN and for it's proposals. It always seems like the same persons contribute to the same discussions and we get nowhere. Perhaps commentary from non-ITN regulars would help. DarkSide830 (talk) 04:16, 24 August 2023 (UTC)

  You are right that the limited pool of contributors is a problem. On the other hand you have to ask: why is the pool so limited? And from what I read major factors are the toxicity and breakdown of rule enforcement. So why would anyone want to contribute? You have to root out the toxicity first, then you can ask new people to join. Based on ITN's reputation alone I wouldn't even consider taking part. -- Random person no 362478479 (talk) 18:21, 24 August 2023 (UTC)

  Well, honestly, if anyone truly cares about the state of ITN and their solution is to just leave, then that's a them problem. Not trying to fix a problem is never going to have the problem fixed. And honestly the very fact that many would rather just get rid of ITN then actually try and fix it's problems kinda just shows that people don't care about fixing the problems. DarkSide830 (talk) 22:46, 25 August 2023 (UTC)

  If an area of Wikipedia is so toxic people don't go there then the people who don't want to deal with the toxicity are not the problem. The problem is that the toxicity is allowed to fester. I agree that the solution to the problem should not be getting rid of ITN, the solution should be to get rid of the toxicity. But you don't achieve that by exposing more people to the toxicity. You achieve that by enforcing the rules. The fact that a lot of people seem to have given up hope that that will happen means that ITN is only a symptom of a far deeper and far more troubling problem. Getting rid of ITN is an abandonment of responsibility. Instead of addressing the problem at its root it gets rid of a visible symptom and pretends the underlying problem doesn't exist. -- Random person no 362478479 (talk) 19:16, 26 August 2023 (UTC)

  This sounds like Somebody else's problem: There's a problem (toxicity), and I refuse to fix it, because somebody else should fix it. Who's going to enforce the rules, if you don't show up to do it yourself? Feel free to read our policy on enforcing the rules before answering. It's at Wikipedia:Policies and guidelines#Enforcement and I particularly recommend the last sentence of the first paragraph.

  Also, in the particular case of poorly behaved editors, we do sometimes find that having a lot more people involved in the discussion causes people to behave better. Besides, then each of us can say "That comment was uncalled for" or "I disagree" once or twice, instead of the same editor burning out by trying to do it all and also being perceived by the badly behaved folks as a civility shrew, instead of being perceived as the voice of the community. WhatamIdoing (talk) 20:00, 28 August 2023 (UTC)

  "This means individual editors (including you) enforce and apply policies and guidelines." While this applies to content issues it the only way it applies to behavior issues is that there are community sanctions. But as others have already pointed out efforts at WP:CESSPOOL have so far been in vain. And I am not going to a toxic place in my free time, thank you very much, especially not when everyone tells me that toxicity there is accepted as a given. -- Random person no 362478479 (talk) 20:13, 28 August 2023 (UTC)

  That policy statement applies to all policies and guidelines, not just content. The paragraph gives "other editors can persuade the person to adhere to acceptable norms of conduct" as the first step in that process.

  The question is: If not you, then who? WhatamIdoing (talk) 23:15, 28 August 2023 (UTC)

  The way I see it, there's opposition to ITN and to its abolition. The section above suffices for incremental reform ideas. There's an old trope that "destruction is a form of creation"; it's not a very creative thing to say, imaginationwise, but could still truly open new doors for the regulars and foster an unfamiliar sense of well-being in viewers. InedibleHulk (talk) 10:04, 24 August 2023 (UTC)

• I would !vote in favor of deprecating ITN, with community-imposed general sanctions for ITN as a second choice.
  I think NOTNEWS arguments are worth considering, but they aren't especially persuasive to me. Wikipedia isn't a paper encyclopedia and isn't bound by the constraints of a static print format. I have a hard time imagining any print encyclopedia containing an article titled Pronunciation of GIF, but it's one of our finest articles and would rightly be snow-kept if it were nominated at AfD. We should always prioritize our readers, and we're providing them with a useful service by writing articles about current events. I'm intrigued by the ideas regarding WikiNews, but I don't know enough about that project to have an opinion.
  I don't think ITN is a bad idea in principle, but in its current form it just doesn't work. I've never been a regular there, but I assumed for many years that it was much like the rest of Wikipedia and its many sub-projects and processes: intrinsically flawed, but mostly functional and generally working as intended. As anyone familiar with ITN knows, this isn't the case. There are no objective criteria for inclusion and arguments often boil down to WP:ILIKEIT/WP:IDONTLIKEIT. This inevitably results in wildly divergent opinions that can't be resolved through discussion, which in turn contributes to ITN's well-known conduct issues. It's unconscionable that we allow such a dysfunctional process to dictate content on the home page of a top 10 website.
  I'm not optimistic that this can be resolved through an RfC. I've seen this story before, and I know how it ends. Around half a dozen competing proposals are raised and none of them gain majority consensus after a month-long series of discussions with enough ink spilled to fill several Encyclopædia Britannica volumes. We've seen this happen at WP:ADAS, and Wikipedia:Requests for comment/Portals guideline has been in the "brainstorming phase" since 2019. A likely result would be "no consensus" for every substantive change and an indefinite continuation of the status quo. This is not an acceptable outcome.
  I think the only solution is to blow it up and rebuild it from scratch. This would create a much more compelling incentive for the community to implement objective guidelines that would prevent the sort of nonsense that's become the norm there. SIGCOV in reliable sources from around the world would be one possible criterion. Some sort of aggregate metric like Google Ngrams or whatever service has replaced Alexa rankings could also be useful.
  Community-authorized sanctions are badly needed if ITN isn't deprecated. I've lost count of how many editors have been dragged to the drama boards over shenanigans at ITN in the past six months, and reading any discussion over there with more than 5-10 comments makes my eyes bleed. — SamX [talk · contribs] 21:18, 24 August 2023 (UTC)

  The thing to know about WikiNews is that it's for writing the news – like, you phone up the mayor in your town, ask about the budget, and write a news article at WikiNews about your town's budget. It's not really for encyclopedia articles. If you're not violating Wikipedia:No original research by citing previously unpublished information, then it's probably not ideal for WikiNews.

  ITN is more like "Hey, we have encyclopedia articles about subjects that happen to be in the news." WhatamIdoing (talk) 20:06, 28 August 2023 (UTC)

  WhatamIdoing, not really for encyclopedia articles, certainly. But, at Wikinews, we certainly don't just publish original research (naturally, we call it original reporting, OR). In fact, most of our OR pieces cite non-OR sources. Moreover, a majority of the articles we publish are "synthesis", i.e., not inclusive of any OR. Heavy Water (talk • contribs) 03:55, 13 September 2023 (UTC)

  That's good to know, thanks. As I said above, I think well-sourced encyclopedia articles about current events are a useful service. Accordingly, I wouldn't support outsourcing ITN to WikiNews barring a fundamental change in that project's scope. — SamX [talk · contribs] 20:12, 28 August 2023 (UTC)

• In reading the above discussion, there seem to be three minds about things as it stands regarding ITN:
  • Some favor keeping ITN and looking for ways to improve it, or they believe there is nothing wrong to begin with.
  • Some favor abolishing ITN outright.
  • Some favor general sanctions being applied to ITN/C, either as an alternative to or in lieu of abolition.

With those three choices in mind, that ought to be enough to go forward with an actual proposal if someone felt it was necessary. Personally I feel that general sanctions are warranted one way or another, if no consensus for abolishing it is found, for most of the reasons espoused above and in particular by SamX. _{Duly signed,} ⛵ WaltClipper -(talk) 13:29, 27 August 2023 (UTC)

• Support - Wikipedia is not a news site and does not need to be. So many good editors have run into issues trying to edit there that I think it is mostly a net negative. At the very minimum I could be in favor some proposals to reform it to make it much less subjective to the whims of whoever is the loudest that day. PackMecEng (talk) 00:02, 29 August 2023 (UTC)
• Oppose - One of the purported advantages of a paper encyclopedia is that in looking up articles one is exposed to varying material one might not otherwise seek. The Wikipedia home page, it seems to me, partially address that concern by providing an artful, dynamic display of interesting content. ITN is a useful part of that, connecting readers to articles relevant to current events. It does not try to provide full and timely coverage of the news, as would a newspaper or news channel or Wikinews. Only a smattering of events are covered and often well after they are in the headlines. If there is some disfunction in creating ITN, we have dealt with such things before. It's a valuable service to our readers and I wold miss it greatly.--agr (talk) 00:41, 29 August 2023 (UTC)
• I would support, this measure obviously, per WP:NOTNEWS. The button pushers at ITN cause more drama than they should. Or mean to, to be fair. But the process is beyond repair and there are plenty of other areas of the project that need that kind of... commitment. If that's the word. It's not. But. SN54129 16:30, 9 September 2023 (UTC)
• At some point between when I started editing Wikipedia and today "In the News" seems to have lost its original purpose of highlighting articles that are relevant to news stories to providing the news stories themselves, in violation of WP:NOT#NEWS. For example the current top story is the earthquake that has hit part of the Atlas mountains in Morocco. Instead of linking to articles about the Atlas mountains, the more specific places that have suffered, or about earthquakes in that part of the world, so providing some encyclopedic background, it just links to an article about the specific news event, which it is not the job of an encyclopedia to provide. Phil Bridger (talk) 18:58, 10 September 2023 (UTC)

  That's the most persuasive explanation I've heard yet of the NOTNEWS problem. Thanks for that. DFlhb (talk) 19:58, 10 September 2023 (UTC)

  Thank you for that summary. I would add that just by having ITN, we make Wikipedia seem like a for all these NOTNEWS-violating articles; functionally, a self-induced OTHERSTUFFEXISTS failure. Happy editing, SilverTiger12 (talk) 19:23, 11 September 2023 (UTC)

  OTOH, given that NOTNEWS begins by saying "Editors are encouraged to...develop stand-alone articles on significant current events", I don't think that it represents the community's views on whether we should have articles about specific news events. WhatamIdoing (talk) 03:05, 14 September 2023 (UTC)

Oversight of the main page

Given the handful of recent controversies at DYK, ITN, and now TFA over the last few weeks, I think it's time to start talking about a sitewide consensus for how main page content is selected and curated. The English Wikipedia main page is one of the most widely visited webpages in the world, but there's next to no oversight as to what actually goes on it. Currently, the different corners of the main page operate on their own rules in a bubble, and their quality assurance processes are insufficient. The best solution we have so far is WP:ERRORS, which is for mistakes caught after the fact, and it's not that useful for policy-related issues.

We need some sort of solution to prevent these issues, which often go undetected or ignored by the ingrained culture of each corner posting on the main page. This might be a separate guideline codifying how things are posted to the main page. Or maybe something like Wikipedia:Main Page/Tomorrow could be made more visible to editors specifically for the purpose of checking items on a policy basis for WP:BLP, WP:N, WP:NPOV, etc in the days before they're posted. Or it should be possible to have a script identify each link to be posted on the main page and then provide information about that article's quality statistics as a quick check to make sure poor quality articles aren't getting through. But I'm placing this here in the idea lab hoping that progress toward any sort of solution or improvement can be made. Thebiguglyalien (talk) 01:46, 17 September 2023 (UTC)

A big issue is that you're talking about two different things: quality, and selection of what gets featured in the first place. Speaking in terms of quality: The best solution we have so far is WP:ERRORS, which is for mistakes caught after the fact is an outright incorrect statement, as WP:Errors covers multiple days in advance; this has been used as recently as today. As you state in the third sentence of your second paragraph, the best solution thus is to encourage editors to more often look at main page candidates days in advance. A minimum quality guideline would be easily achievable, as the three non-TFA areas have pretty much the same minimum quality requirements; WP:ITNQUALITY may be a good baseline in such a case. Curbon7 (talk) 02:46, 17 September 2023 (UTC)

Getting more editors to look at future main page content would be the trick to making WP:ERRORS more useful. But even then, that would still just be a one day head start without future main page content being more broadly accessible. And it wouldn't help with ITN, which goes straight from a few votes to the main page, often with a very loose interpretation of WP:CONSENSUS and with virtually no checks for policy compliance like TFA and sometimes DYK have. That latter point is why I have little faith in the criteria set by ITN. Thebiguglyalien (talk) 03:05, 17 September 2023 (UTC)

To be frank, and of course I say this respectfully, I think you're wrong with the statement with virtually no checks for policy compliance like TFA and sometimes DYK have with regards to ITN from a quality-perspective. It's quite uncommon that a candidate that has been posted is pulled for a quality-related reason; every candidate article undergoes a check for quality and has to be manually posted (thus has to be checked) by an admin. You state that you have little faith in the criteria set by ITN, but what specifically in WP:ITNQUALITY do you take issue with? Curbon7 (talk) 04:00, 17 September 2023 (UTC)

I've made a bit of a stink about this at ITN in the past, but the general idea is that there's no expectation of articles being evaluated for policy issues like WP:OR, WP:NPOV, WP:V, WP:N, etc (and that last one can bring us down a separate tangent about whether events that just happened can meet notability guidelines at all). From there, the actual selection process is essentially the wild west, which is a structure that most of Wikipedia has moved on from. Once the article isn't a stub, whether it gets posted is basically down to whatever the voters feel like. I contend that this is an inherent, blatant OR problem. DYK by contrast has uniform standards where any article can be posted if it meets certain requirements (eliminating OR in the selection process) and at least nominally requires checks for V and NPOV (even if they're not applied as well as they could be). Thebiguglyalien (talk) 04:27, 17 September 2023 (UTC)

You are definitely wrong with ITN content. We have maybe at most a 1% error rate in target articles having major problems with the core content policies, which usually results in them being pulled; article quality is checked by many people during the ITNC process. TFA always has to start with featured content. DYK has content requirements too, but these typically are only checked by one person so can have possible issues, but I would think from history its error rate is also less than 1%. That's all working as intended, so this all seems to be a nonissue. Masem (t) 04:10, 17 September 2023 (UTC)

• Actually, the solution would be to remove about 75% of the content featured daily on the Main Page, which would make it less cluttered, more visually appealing, and less prone to error or selection of content that isn't likely to attract interest. We should be able to see how many people click through on each individual item on the main page to figure out which ones are actually gaining sufficient attention to keep; I'm sure a bot could be programmed to produce a daily report. Risker (talk) 04:18, 17 September 2023 (UTC)

Let's see:

• DYK works by peer review/promotion, with little oversight outside of the DYK bubble.
• ITN works similar to DYK, but with broader discussion (i.e., not just one reviewer).
• TFA is controlled by a few "coordinators".
• OTD works by random people unilaterally updating things. I mean, it's the least bureaucratic and it's easy to get things done, but little oversight anywhere until the last minute...

Yep, I see a problem. Edward-Woodrow :) _[talk] 18:05, 17 September 2023 (UTC)

Except for TFA, all these are volunteer and open processes, any editor can get involved (and increasing participation absolutely can help). TFA require featured content, which itself is already volunteer-based through consensus to push anything through, and its only managing the rotation of articles that is generally limited to the coordinators. Masem (t) 18:23, 17 September 2023 (UTC)

I'm not denying that, I'm just saying that each section does, as Thebiguglyalien said, have a tendency to operate in its own bubble. Edward-Woodrow :) _[talk] 18:25, 17 September 2023 (UTC)

Most of the recent Main Page controversies were not really about the quality of the encyclopedic content, but about the question whether it was appropriate for the Main Page. The Main Page isn't part of the encyclopedia, and rules and expectations are different (for example, it is subject to censorship). The ethical issues around mentioning embarrassing things in a BLP and highlighting them on the Main Page are also different, and neutrality questions inherent in content selection are different from each of the articles adhering to NPOV. So we might need a more journalistic code of ethics covering the Main Page. In the absence of such a code, we have a lot of disagreement, often with poor arguments ("it is common sense not to run this" doesn't really explain why).

I don't think quality control is such a major issue; wrong statements on the Main Page are fairly rare. We should perhaps follow good journalistic practice and issue corrections/retractions, though. —Kusma (talk) 05:17, 17 September 2023 (UTC

Does Creation/Edits of articles related to username get flagged by the various AI bots?

I found one the other day (and I have misplaced my paper notepad :-)) where the article was John Smith edited by JohnS or JS1234? Does this get flagged for an editor to review? Also is it flagged (assuming anonymity is preserved) if the editors IP address (or domain email address) owner on whois and DNS is related to the article topic?

(Apologies in advance if I have the terminology wrong) Wakelamp d[@-@]b (talk) 09:07, 17 September 2023 (UTC)

We have tags that are applied if a username is similar to an article title or external link, see [3]. I don't think there is any IP address matching, and there probably should not be for privacy reasons. —Kusma (talk) 09:54, 17 September 2023 (UTC)

@Donald Albury @Kusma Thank-you. With IP address matching I was thinking of blackbox- its flagged, but you don't know the details. But as David wrote assume good faith and he has every right to edit Albury

I looked through the special search, the last 30 days of examples but didn't see a match on initials. It does match on

• article name and user name match
• any article word match with any part of username (and I assume common words are excluded, and
• non English alphabet! (but why can editors create articles in other character sets?? Or write comments not partly in English [4]

(But David - Albury is always suspect because it is [New South Wales|North of the Border]] rather than in Mexico)

Wakelamp d[@-@]b (talk) 10:59, 20 September 2023 (UTC)

If someone edits without being logged in, then the IP address is exposed (although the Foundation plans to change that sometime in the future) and anyone can look for a connection to the topic being edited. If a user edits while logged in, then only a Checkuser can see the IP address, and may do so only under certain circumstances. There is no automatic process that tags the types of connections you are asking about. If a user thinks there may be a connection between an editor and an article they have edited, then that editor may be asked if they have a conflict of interest to disclose. Always assume good faith, as many apparent connections are not real. For instance, I have edited Albury a number of times, but I have no connection to that city other than sharing the name. Donald Albury 14:47, 17 September 2023 (UTC)

Working on a script to help editors make report here

I'm currently working on a script to help editors make reports here more conveniently, since some cases are really simple and obvious but take time to report them manually, e.g. revoking TPA due to talk page abuse. This idea came from the WarningDialogue on metawiki.

The first version is on User:Lemonaka/WD.js. However, it is buggy. I also afraid I might reinvent the wheel. But Twinkle and Redwarn are all working on WP:AIV instead of here, so I'm not sure and asking for helps from experts here. -Lemonaka‎ 23:56, 20 September 2023 (UTC)

• Clarification: This was originally listed at ANI, so "here" means AN/I. Anyways... I can't read Javascript beyond let x = 5; so I can't assess the code, but the idea sounds great. Edward-Woodrow • talk 00:04, 21 September 2023 (UTC)

It's useful. I will say that if we're soliciting feedback on it, having section links in the edit summary would be helpful and save me a click. ―Justin (koavf)❤T☮C☺M☯ 00:58, 21 September 2023 (UTC)

@Edward-Woodrow@Koavf Partially done, no obvious bugs found by me now. Needing some volunteers to help and test it. -Lemonaka‎ 15:22, 21 September 2023 (UTC)

I haven't tested it yet, but everything appears to be perfect. I have one suggestion: could we make the reason box a bit larger? 𝙳𝚛𝚎𝚊𝚖𝚁𝚒𝚖𝚖𝚎𝚛 ^{𝚍𝚒𝚜𝚌𝚞𝚜𝚜} 16:17, 21 September 2023 (UTC)

@DreamRimmer Partially done, I'm working on word break or line break now. -Lemonaka‎ 18:31, 21 September 2023 (UTC)

Drafting below redirects

I want to open a discussion here on the practice of drafting content below a redirect that is nominated for discussion at RFD. It is a fairly common result of these discussions that a redirect page is converted to a disambiguation page or even a standalone article, and for many years it has been a common practice for an editor proposing this result to add a draft of their proposal below the templated redirect notice, and for the proposal to then be debated in the discussion. I'll highlight some examples of redirects with draft proposals over the years below.

Recently I was in a dispute with another editor which led me to believe that seeking feedback on this practice would be useful, and that wider input from editors who are not "regulars" at RFD might expose faults not previously considered, which is why I'm posting here. There currently is no policy or guideline that covers this, it's more like a common sense thing that's evolved over many years, and I don't think anyone has felt the need to write it down before now.

In general, RFD is a disruptive process - the nomination template breaks the redirect temporarily. It's a necessary evil - there wouldn't be a way to highlight that a redirect is under discussion if the redirect still skips over the page that has the notice on it. I think that since the redirect is disabled during the discussion anyway, drafting a proposal below the notice is harmless. It also ensures that if the redirect is converted that its edit history remains intact, as the history of any redirect nominated for discussion will have a history entry referring to the discussion. It's also simpler to keep the proposal on the page being discussed - if the proposal is accepted then all that needs to be done is removing the redirect code, and if not then it's just reverted, all of which can be done by any editor (and RFD tends to be kind of a proving ground for non-admin closes; whereas drafting on a separate page requires linking to the separate page, and then either history-merging the draft into the redirect page if it's accepted or deleting it otherwise, both of which require an admin and would require an admin to close per WP:BADNAC. On the other hand the redirect code can make editing the proposal/draft confusing, but that extends from the "necessary evil" of having the template in the first place, and I don't think it would be less confusing to have to edit a different page instead.

But - all of this happens in article space, while the proposals tend to follow draft standards, so the process might display low-quality or poorly-sourced content to readers throughout the discussion. I think this also falls under "necessary evil" but I think it's worth considering.

tl;dr: Please discuss whether or not content should be drafted below redirects listed at RFD. I don't have a proposal, but I'm interested in others' feedback and a proposal might grow out of this discussion. Please comment below. Ivanvector (^Talk/_Edits) 12:41, 22 September 2023 (UTC)

Am I allowed to call myself an RfD regular? I hope so. Anyway, I think the drawbacks are, as you said, a necessary evil that must be taken with the large benefits that the system provides. Edward-Woodrow • talk 22:40, 22 September 2023 (UTC)

Examples of redirects with draft proposals below the discussion template

These are permalinks to a revision of the redirect page with the notice and proposal drafted below. The discussions can be accessed from the notice on the page. The oldest of these is from 2010, the newest is currently open for discussion. Ivanvector (Talk/Edits) 13:04, 22 September 2023 (UTC) Wikipedia:Copied text Rulership Equational Offcut V discography Trol Arthur Harley Latin Portuguese I-95 exit list Victory dance Principality and Diocese of Monaco Sony Television Industrial food N, Watered Down Fastest thing alive Year of three prime ministers Post-Soviet studies Thumbprint United States military occupation Data diddling I Wish You Knew Yeshay White Car Mile road system Libran Ginseng coffee

• I don't hang out there and so, like many, may not know how it "flows" there or what the common cases and problems are regarding this. Does doing that often "mess up" the RFD process? By freezing it or putting it into limbo? North8000 (talk) 12:59, 22 September 2023 (UTC)

  The most common case where this comes up is a redirect with ambiguous possibilities, for example the (now former) redirect Industrial food targeted the page food industry, and an editor nominated it for discussion believing it to be derogatory. In the discussion a few different possibilities for suitable targets were discussed, and then an editor drafted a disambiguation page under the redirect notice (here) to illustrate their proposal to convert the redirect to a disambiguation page listing the different potential targets. Others reviewed the drafted content and agreed with the proposal, and that redirect is now a disambiguation page. Less often a standalone article is created by the same process. It doesn't disrupt RFD, in my opinion the discussion is enhanced. I did notice a pattern going through this that once a proposal is drafted it is almost always accepted, so perhaps there's a first-mover advantage dynamic here, but I found enough examples of discussions with these proposals where the pages are still redirects or are now deleted that I don't think that's a significant issue. Ivanvector (^Talk/_Edits) 13:17, 22 September 2023 (UTC)

I looked at a bunch of those....most seem to have ended up as disambig pages which IMO was the best resolution of all for those and if the RFD served as a fast incubator for that I think that that was a good thing. The Wiki system fails to recognize that we are often dealing with mere terms and normally operates under the delusion that it is innately a distinct topic that is being named by a term vs. the reality that it is often the reverse of that. And that those terms can have multiple meanings. In those cases the "classic" results (of keeping as a redirect or completely deleting) are not the best ones and if there's no harm done, then using the described process to facilitate conversion to a disambig seems like a good thing. I guess one potential downside is that it might be first mover/ facilitate creating an article which grabs "dibs" on a term that really should be a disambig or something else. North8000 (talk) 13:58, 22 September 2023 (UTC)

• The current practice of drafting dab pages on the redirect page is fine, works well and does not seem to require any additional formal regulations. —Kusma (talk) 13:30, 22 September 2023 (UTC)

• I’m not sure how important and/or relevant to this discussion it is; but in case anyone’s interested, I thought I’d note that the unless you're drafting … part of the Don't add anything after this line unless you're drafting … comment left by the {{RfD}} notice seems to have been there since August 2018 (having been inserted in Special:Diff/854174944 from what I can see). Best, ^user:A smart kitten_meow 14:10, 22 September 2023 (UTC)

Changes to ITN

Please do not discuss the possibility of abolishing ITN outright here; I'm interested in generating a proposal to change it. It is clear that ITN is unsustainable as presently constituted. In some ways it is very toxic, and there are frequently long periods without any postings. I was once a frequent participant there, but have reduced my involvement due to the environment there. I think that many of these issues can be reduced if notability/merit were taken out of discussions at ITNC, and that only article quality and recentness be criteria. Other areas of the Main Page have criteria to meet and not much discussion. I might propose the following as a starting point, but I don't claim to have all the answers- actually, no, I don't have all the answers.

An article about an event receiving news coverage may be posted to ITN if it meets the following criteria:

1. the event occurred in the previous 7 days(as it is now)
2. the event receives original reporting in more than one news outlet
3. a preexisting article related to the event receives a quality update of at least five sentences, or a new article is created of at least three paragraphs
4. "Quality update" means no orange maintenance tags or deletion process underway

The purpose of discussion at ITNC would be to determine a blurb, the quality of the update, and if needed, what image to display. If implemented, this would obviate the need for WP:ITNR and that could be marked as historical.

Too many postings is not a problem ITN seems to have. There is often several days without a new post- too many valid postings is a problem that I would want to have. There is also fear that it would turn ITN into a celebrity news outlet- what's the issue there if there is a quality article update? I often see the criticism that ITN is just about death, disaster, destruction, and maybe elections. Variety is good and improving articles is good. This would also allow for more postings from underserved areas where one editor might have done good work improving a news article about an event from an underserved area.

Thanks for any ideas that you might have. 331dot (talk) 16:53, 22 August 2023 (UTC)

Not opposing this proposal myself, but isn't the counterargument against this the WP:NOTNEWS argument? I agree with you that ITN could or should have more postings, but it seems that others argue that ITN is not meant to be a "news ticker". Natg 19 (talk) 17:03, 22 August 2023 (UTC)

Two frequent objections that get brought up when similar ideas are floated are "We're going to turn into a US ticker!" and (as you mention) "We're going to get flooded with news about the Kardashians!". The solution to both of these is the same as over at DYK: limit stories relating to any particular country to no more than one half the blurbs, and to any particular subject area to no more than a quarter. In practice, that's 2 and 1 (with a typical four blurbs) compared to DYK's 4 and 2 (of 8 hooks). —Cryptic 17:06, 22 August 2023 (UTC)

Unlike DYK where the whole of human knowledge is available and thus limiting topics from the same area is possible, no one can control how news happens. If ITN ends up with every topic about one country or from one topic area (like sports), that's just the way it happens. Masem (t) 17:15, 22 August 2023 (UTC)

If we have a half-dozen postable candidates every day and a seven-day backlog to pull from, then we can pick and choose. And if we happen to get separate earthquakes on the same day that dump both San Francisco and Tokyo into the sea, that's what WP:IAR is for. —Cryptic 17:26, 22 August 2023 (UTC)

The problem is that we often don't get blurbable candidates on some days. That can be a combination of a slow news day and a lack of volunteer effort to nominate and/or improve an article. If the ITNC throughput fwas much higher, it would be great to have a backlog of ITNs ready to go so we can try to do some balance managing. But outside the period of Nobel Prize award week, I have rarely seen anything that approached that backlog. Masem (t) 17:36, 22 August 2023 (UTC)

Then we can delay or decline an update, or we can replace another blurb; or maybe we make the limits advisory ("try really hard not to run three Dutch blurbs at once") instead of being stated as absolutes, or apply only if there's alternate blurbs to pick from. —Cryptic 17:52, 22 August 2023 (UTC)

I don't believe the other front page sections have such restrictions- often someone will spend time improving a slew of articles in the same general topic area for DYK, but those are posted as they come. 331dot (talk) 14:45, 10 September 2023 (UTC)

Personally, I think we need to address the failure of the community as a whole to follow the principles of NOTNEWS and NEVENT, which bleeds into some of the problems at ITN. We are creating articles on every event that gets some type of immediate coverage, and where we have existing articles, we are overly detailed on events as the break (eg see our COVID timeline articles for how bad this is). We need to keep the mindset WP is not a newspaper, and we do include current events, it should be towards comprehensive summary of a topic. We also look towards enduring coverage of events, rather than the burst if coverage.

With this kept in mind and better application if NOTNEWS, we should hopefully get coverage of topics from a broader spectrum of fields (eg we typically are woefully shy on medical and scientific items) where the articles are of high quality when they become news. Its why the mantra "ITN us not a news ticker" is there so that we are looking for a diverse array of topics that have demonstrated long term relevance than simply resorting to reading news headlines. Masem (t) 17:32, 22 August 2023 (UTC)

What does "long term relevance" mean? Natg 19 (talk) 17:54, 22 August 2023 (UTC)

For this purpose, it would be WP:LASTING and WP:PERSISTENCE. Thebiguglyalien (talk) 18:39, 22 August 2023 (UTC)

In the case of current events,is often the case that neither WP:LASTING nor WP:PERSISTENCE is known with any certainty, so this will be a guess. What is known for certainty is that the people here are poor at estimating them, and usually underestimate. Hawkeye7 (discuss) 21:49, 22 August 2023 (UTC)

+1. It doesn't help that AfD is often visited by the same few regulars, many of whom believe that "it was in the news" means it received secondary coverage. Thebiguglyalien (talk) 18:38, 22 August 2023 (UTC)

This seems very much a view of certain (very vocal) Wikipedians (esp the FA crowd), that is not shared by most people actually using Wikipedia. Most people just want the information they need. Delaying that information for some archaic view of what constitutes an 'encyclopedia', that is rooted in the limited space and the production method of these older encyclopaedias is the route to irrelevance (as was the fate of the encyclopaedias before us). —TheDJ (talk • contribs) 14:08, 25 September 2023 (UTC)

I've been basically calling for the implementation of this system for months now; we clearly cannot agree on what notability is, with the vagueness of ITN being literally inscripted on WP:ITN, so why not just reduce nota standards to a base amount of basic variables. I'm always amused how people would openly state, "this shouldn't be posted to our front page because it doesn't fit my notability standards" and how that would just be tolerated on ITN. In the past, I've stated that "if a subject has an article, and you don't think its of encyclopedic significance to be included on ITN, then you know where to go." People keep screaming about how we will become like TMZ or whatever, and I honestly think that this whole anti-celebrity news mantra you see on a somewhat ubiquitous scale on ITN is just a lazy placeholder of an argument used to tear down noms they don't like, pulling on the popularity of hating popularity to garner support. For example, there have been repeated calls by some to have a link to WP:25 or have some sort of "trending topics" page related to ITN, and it's been shut down since "We'Ll bEcOmE lIke MsM oR tMz." Hell, the Titan submersible incident had people dismissing as celebrity news and comparing it to Anne Heche's death. Additionally, as Snow Rise (talk · contribs) once brilliantly pointed out, on Wikipedia, we follow what WP:RSes say, so for ITN to go against that since some users have a vendetta against some story is hogwash. But alas, as Snow again stated, this push of mine hasn't been popular since some of the regulars there won't be able to dictate what's notable or not based on vibes. We all know ITN is fundamentally broken, but we're so fragmented and polarized that we can't even come to a consensus to compromise on the most minor of issues. — Knightoftheswords 17:50, 22 August 2023 (UTC)

This essentially says what I was going to say. I've also advocated this approach, and I've criticized the editors at ITN for creating a closed off bubble from the rest of the project that sees fit to ignore WP:OR, WP:NOTNEWS, and WP:CONSENSUS. The time has long since passed for the community as a whole to implement changes to ITN, as the regular participants have essentially come up with their own rules and are unwilling to budge from them. I've lost count of how many times someone's argument in a discussion was challenged at ITN because "we don't do that at ITN". Thebiguglyalien (talk) 18:45, 22 August 2023 (UTC)

Besides the issue with TOP25 being more beholden to pop culture interests, there is no quality control for articles listed at Top25, which fails a necessary facet of being on featured on the main page. Also "we follow what RSes say" only applies to WP:V, it doesn't factor into other p&g, like notability.

What I don't think many complainers (who are generally those relatively new to UTN) get us that is that ITN was made to feature quality articles that happened to be in the news. This included articles created in a high quality form within hours of an event happening, like 9/11 or Jan 6. What we are seeing is more demand to follow the news, leading to article of okay quality but not what we'd consider anywhere close to the expectations of TFA or DYK ones. Which is why ITNC discussions can be diversity as I'd guess half of the regulars are looking for good encyclopedic articles while the other half are looking for newsworthiness and timeliness. Masem (t) 20:53, 23 August 2023 (UTC)

I just feel like you can't have defined ITN criteria that allows ITN to function for it's stated purpose with a simple streamlined set of rules defining "notability". That is why "the event receives original reporting in more than one news outlet" is a problem, because like past proposals designed to grant any news item automatic ITN inclusion for being covered by a certain number of sources, we are then beholden to what the media in a general sense thinks is important, and given most publications operate online now, they post countless articles a day, meaning if you have, say, 20 set publications you are looking across, you probably have dozens of stories that all of them have covered in some way. In a sense, there has to be a "do people care" aspect to any ITN posting. I know we bash his approach a lot, but Andrew is certainly not completely off point in citing readership as it pertains to certain news stories. Not that ITN should operate by readership (which will be biased towards stupid celebrity drama, movies, stuff like that most of the time), but it is valid to ask the question of "do our readers give a you-know-what about this news item?" That is why ITN/R has seen a decent scaling back in the past year, as many have questioned just how vital for posting certain stories are (ie, very few care about the Boat Race, the launch of a new type of rocket, or G7 summits where nothing of note is resolved). I think, as I have opined in the past, ITN needs more voices and less red-tape, so as to allow us to more properly judge what people believe is important and of the public interest. DarkSide830 (talk) 22:57, 22 August 2023 (UTC)

I think the four proposed criteria constitute reasonable minimal criteria. I would like to see stricter/clearer criteria for overall article quality. Maybe something like "the article must have GA status". -- Random person no 362478479 (talk) 17:37, 23 August 2023 (UTC)

No, that is a non-starter GA review takes time - something that we do not have if we want to post relevant, current news. DarkSide830 (talk) 18:02, 23 August 2023 (UTC)

That is certainly true for cases where a new article is created. I still think we need some kind of quality criteria. Maybe another way to go at this is to make a list of issues an article may not have, e.g. lack of citations, ongoing disputes about WP:NPOV, WP:BLP, WP:OR, ... -- Random person no 362478479 (talk) 19:49, 23 August 2023 (UTC)

I guess that is at least partially covered by criterion 4. -- Random person no 362478479 (talk) 19:50, 23 August 2023 (UTC)

Yes, I believe this should be covered by #4. DarkSide830 (talk) 04:10, 24 August 2023 (UTC)

The minimum quality standard for ITN is already, broadly, pretty much the same as DYK. Curbon7 (talk) 04:37, 24 August 2023 (UTC)

As far as I can tell there are three main objections to the current state of ITN. a) it should not exist because of WP:NOTNEWS, b) it has become toxic, c) it no longer complies with the rules. Reforming ITN doesn't address a) and b) at all. As to c) why should we assume that the people will comply with new rules if they didn't comply with the old rules? Any reform of ITN has to come with a clear commitment to enforcing the rules or we'll just end up with the same problems. -- Random person no 362478479 (talk) 19:33, 26 August 2023 (UTC)

Comment on criteria I quite like this list of criteria, but obviously No. 4 (requirement of no quality-tags or deletion processes) must be applied with common sense. There have been accusations of toxicity in ITN in the past, and it would be a real pity if people decided to game the system by deliberately putting articles into AfD or sticking debateable maintenance tags on them to exclude something they don't like (though in practice, subjects that appear in the news will attract more attention, so they may acquire quite honest maintenance/deletion tags). It's not insurmountable: basically there just has to be an appreciation that if people game the system and mess around, they're liable to be topic-banned. Comment on regionality This debate has been prompted by an ANI debate, in turn prompted by concerns about whether it's okay to put UK-news on ITN given the global position of en-WP, and whether opposition to this was xenophobia. I suggested that a technical solution might be to have region-specific material. ANI wasn't the right place to raise it, and the one response suggested it might be impractical and imperfect. But I'm mentioning it here because it might help to deal with the lack of updates; if people felt able to add regionally-relevant ITN's, we might get more coverage. It might be appropriate to allow logged-on readers to specify their region (so, for example, a UK-interested person living in Mauritius could opt for UK-ITN). But I don't know if there is any mechanism to deduce the approximate locale of an IP user. Elemimele (talk) 18:50, 22 August 2023 (UTC)

• Comment I like the criteria. Maybe #2 could be a bit more stringent, to avoid super-trivial local news? Along the lines of "# the event receives original reporting in at least three news outlet from at least two different countries". Khuft (talk) 20:22, 22 August 2023 (UTC)

  I think that we should see if that is actually a problem before doing something about it. The first priority right now should be a change period, we can always tinker as time progresses. 331dot (talk) 20:35, 22 August 2023 (UTC)

  I guess there could be a pilot phase where we would see how it works in practice. And sorry, forgot to mention that I support your idea overall! One more thing to consider: RD Blurbs. I think we should forbid them. Deaths would simply be covered by RD; only assassinations & the like would get blurbed. Khuft (talk) 21:09, 22 August 2023 (UTC)

  Per that definition Queen Elizabeth- the head of state of several nations- would not have merited a blurb; but I think that issue should be considered separately. The more changes we try to make, the harder it will be to gain consensus- and it's already going to be challenging. 331dot (talk) 21:33, 22 August 2023 (UTC)

  The death of Queen Elizabeth II would have been blurbed under your criteria (+ the RD Blurb restriction) because it resulted in a change of monarch in the UK. So it's shouldn't be a showstopper. Khuft (talk) 21:38, 22 August 2023 (UTC)

  Page view data indicates that the readers are nowhere near as discriminating as Wikipedians on the ITN/C talk page and will eagerly gobble up the latest doings of the Kardashians. When it comes to regionalism, xenophobia is the real problem. The biggest manifestation is the attempt to insulate American readers from the reality of a global internet. The reader in Mauritius is quite used to news feeds on overseas events and will not be put off by the Bundesliga results. Given our global scope and our educational mission, I advocate dropping the concept of regional relevance, and a lower bar for blurbs. Readers in the UK can and will accept news from Mauritius . Hawkeye7 (discuss) 21:49, 22 August 2023 (UTC)

  I've been considering a notion of ITN as an easy-access box for readers rather than a place for editors to prove that Wikipedia is for siriuz bidness. I'd like ITN's contents to overlap substantially with articles that will appear in the Signpost's traffic report – things readers are looking for, that have been updated recently. WhatamIdoing (talk) 22:22, 22 August 2023 (UTC)

  Most RD blurbs will be ruled out by criterion #3, "a quality update of at least five sentences". —Cryptic 22:34, 22 August 2023 (UTC)

• Criterion #2 is unbelievably loose. Every individual F1 race or tennis tournament would get posted on ITN. Every death of a famous person would get posted on ITN (need 5 sentences? just gather a bunch of social media reactions!). Every regional election would get posted on ITN. The season finale of every reality competition show would get posted on ITN. -- Kicking222 (talk) 23:42, 22 August 2023 (UTC)

  Almost all deaths are covered by RD. Only those where the death itself is an event would go to ITN(as it is now). The end of a TV show is not generally newsworthy. The rest I don't see what the problem is. People writing and reading more articles is a good thing, not bad. 331dot (talk) 00:16, 23 August 2023 (UTC)

  Agree. InedibleHulk (talk) 06:06, 23 August 2023 (UTC)

  I looked at the first example I thought of, the finale for the most recent season of "American Idol" (a show that is no longer hugely relevant and that many people forget still exists). There was SO MUCH news coverage from reliable sources. Someone could unquestionably, undoubtedly create enough of an update that, under your criteria, would breeze onto the main page. Stories would last maybe a few hours in most cases- hell, all of ITN would get wiped out every weekend thanks to golf, tennis, auto racing, MMA, pro wrestling, etc. I'm starting to think you haven't even considered the ramifications of your proposal- which would, in essence, turn into ITN into a 24-hour news ticker and nothing more. Kicking222 (talk) 21:43, 23 August 2023 (UTC)

  Which values would that contradict? WhatamIdoing (talk) 19:18, 24 August 2023 (UTC)

  Kicking222 I have about ten years of experience off and on with ITN so I am well aware of what I think ramifications might be. I don't think it would be as bad as you claim, and I also don't see the problem if it were. We shouldn't have super-notability for ITN; if a topic isn't notable enough for ITN it should not be notable enough for Wikipedia. Too many postings is a problem I would love for ITN to have because it would mean that people are working on and improving articles. 331dot (talk) 19:26, 24 August 2023 (UTC)

  Cool, have fun posting every single WWE pay-per-view (they're all updated and have reliable sources) on the Main Page. Too bad we couldn't implement your idea in time for "Succession", since every episode would have its own article posted.

  By the way, this would essentially lead to massive amounts of advertising for new products. Every video game and film that comes out will be on the Main Page upon release, since they all get updated with a "Reception" section. Kicking222 (talk) 22:04, 24 August 2023 (UTC)

  @Kicking222, why do you think that posting recently updated articles that readers want to read would be an inherent problem? Look at pages like User:Jimbo Wales/Statement of principles and Wikipedia:Five pillars. Do you see anything in there that says anything remotely like "It would be bad if readers saw links to new video games" or "An encyclopedia might be stuck having articles about some television show, but it shouldn't ever put them in the Main Page"?

  It feels like you have a gut feeling about something harmful, and I'm hoping that you can articulate exactly what the harm is. WhatamIdoing (talk) 19:54, 28 August 2023 (UTC)

  I've been very clear about the harms, but sure, I'll expand. It would create tremendous turnover on the Main Page that would take tons of maintenance. It would put out a huge amount of free advertising, which is quite clearly obviously against WP's tenets; it would also open up a great avenue for self-serving editing. It would put on the Main Page not necessarily what people are searching for, but what users choose to edit and submit to ITN. It would take actual important stories and kick them off the Main Page in a heartbeat. It would unfairly and heavily favor sports and entertainment (which is a huge problem to me, and I work in sports).

  I'm not saying ITN is perfect- boy howdy, is it flawed- but throwing any old article on the Main Page as long as it's sourced isn't the solution. Kicking222 (talk) 23:17, 28 August 2023 (UTC)

  Thanks for the organized list, @Kicking222. Here are my thoughts on each item:

  • I'm not sure that it would create any additional turnover on the Main Page at all. In fact, we could choose to update it less often than we do right now. Nobody here has suggested an automated ticker.
  • I believe that Wikipedia:We don't care what happens to your website, and I don't see anything in any of the principles or value statements that says anything about trying to minimize any "free advertising". It's true that some individual editors hold this POV, and most of us loathe the idea of COI editors secretly manipulating articles, but there is no general principle that we should edit in ways that minimize the financial effect (whether positive or negative) on the subjects of articles.
  • I don't understand how a human-controlled but page-views driven metric would encourage editing. I could imagine someone trying to drive up page views, but (a) having more people read an article is not necessarily a bad thing, and (b) page views aren't editing.
  • It is currently true that ITN puts on the Main Page not necessarily what people are searching for, but what editors choose to edit and submit to ITN. My suggestion ("things readers are looking for, that have been updated recently") would change the current 100%-editor-focused process to consider both readers (their interests, as represented by page views – perhaps a bot would post a traffic report for editors to look over once a day) and editors (because the article still has to be updated, submitted, approved, and manually added to the ITN page).
  • If the articles about subjects that are important (in your personal and subjective opinion, of course) aren't interesting to readers (in their individual, personal, and subjective opinions), then why should we be giving "free advertising" those uninteresting subjects? If the articles about subjects that are unimportant to you are important enough to readers that they're actively searching for them, then why shouldn't we make it easier on readers to find the things that are important to them?

  WhatamIdoing (talk) 15:44, 30 August 2023 (UTC)

  I certainly think a reader-first approach as opposed to an editor-first approach is the right idea. I also certainly understand most of your points, which are well-reasoned and well-stated. I completely disagree with your first one, though; I cannot foresee any scenario in which turnover is not greatly increased if we're expanding the scope of ITN from "important things that happen" to "anything that happens". I further believe that, if that were the case, you would find a ton of people complaining- "I submitted this article, and it's in great shape, and people said it meets the criteria, but you still didn't post it! What gives?"

  As for advertising, let's consider a specific scenario. I have personal connections to the game Unavowed; it has an article that is written, updated, and sourced properly (indeed, it's a GA). If I submitted to ITN/C "Point-and-click adventure video game Unavowed is released to positive reviews", there's no way anyone could argue against it. If that's the type of thing you want on the Main Page, cool- you're entitled to that opinion, and by virtue, the game is able to get a lot more eyeballs on it. Is merely having that on the Main Page a problem? Is that pushing off a more important story a problem? If I proposed posting it with a free-use photo of the game designer, would that be a problem? If you think the answer to all of those is "no", I won't argue with you because it's totally subjective, but I don't love it (besides from my NPOV "I want my friends who made the game to succeed" perspective). Kicking222 (talk) 18:49, 30 August 2023 (UTC)

I find Masem's comment somewhere above resonating with me, about topic areas of ITN coverage. As I write this, the current stories are of the form: politician inaugurated; politician elected; criminal receives sentence; sporting event concludes. Meanwhile the ongoing events are: natural disaster, organised violence, organised violence, organised violence. Honestly, I'd almost prefer if some pointless celebrity gossip were included to round it out.

I do take WhatamIdoing's point close above how the service to the reader will align with links they would likely arrive at by other means (search, search from external site), but I feel like there's a whole lot of life missed out on when ITN blurbs fall almost exclusively into politics, sports, violence, and extreme weather events.

I get trying to represent more regions more fairly, but this is the inadequate representation that vibes more with me. What if we had three open slots, where any story whose article meets quality critera could socket into, one slot for anything not US/UK, and one slot for anything but politics, sport, violence, and extreme weather events? Folly Mox (talk) 23:45, 22 August 2023 (UTC)

That might work. InedibleHulk (talk) 03:16, 23 August 2023 (UTC)

I actually really like the idea you make in the third para. Curbon7 (talk) 06:15, 23 August 2023 (UTC)

I've been thinking about this, I'm not sure if it's logistically possible (or at least logistically uncomplicated). The issue is that the number of blurbs constantly changes due to WP:ITNBALANCE; just recently, there have been times where there are as many as 7 blurbs and as few as 3. I'd be interested in workshopping this, as I think it is a meritorious idea, but it should be straight-forward for the sake of both participants and admins. Curbon7 (talk) 21:02, 23 August 2023 (UTC)

Oh I agree that my simplistic 3+1+1 idea hastily jotted down on the way out the door for sure requires workshopping. I never even knew of the existence of WP:ITNBALANCE. It doesn't have any effect on or benefit to mobile view. That has to be a weird feeling, to have the output of your consensus process directly affected by prose wording from two unrelated processes like a second class citizen. Folly Mox (talk) 22:33, 23 August 2023 (UTC)

"one slot for anything not US/UK" I would go even further and say "one slot for anything not North America or Western Europe". That might encourage more quality work on geographic areas that are underrepresented on Wikipedia. -- Random person no 362478479 (talk) 17:24, 23 August 2023 (UTC)

As I said above, I think we should make the more general change first before tinkering with it. The more complicated the proposal, the harder it will be to gain consensus to do it. 331dot (talk) 17:28, 23 August 2023 (UTC)

I don't mean to be a downer, nor to start consensus polling, but I quite frankly find nothing wrong with the ITN status quo. Maintaining notability requirements for blurbs is essential for not crowding out the really important news stuff from ITN (I know this is essentially a WP:FASTCYCLE argument, but that whole essay only applies when there even is notability to be argued about). Similar to RfA, ITN has its practices and customs that have developed over a decade and a half and I feel that they serve useful functions and oughtn't be removed. I'd actually rather see ITN abolished altogether than have "free rein" without any feelings of overall importance. – John M Wolfson (talk • contribs) 04:33, 23 August 2023 (UTC)

In establishing what a notable event for ITN is, prospective reformers would be prudent to grant a degree of leniency while ensuring that ambiguity does not cloud purpose. This proposal does not particularly impose clear restrictions on what ITN coverage entails. If one were to seriously considering standardizing ITN notability—a daunting task itself—one would need to establish the elements of a proper nomination. A proper set of ITN guidelines assumes inequality in what stories are presented to ITN. A mass shooting in which eight people are killed would be exceptional for Norway but above-average for the United States. ITN cannot function if context is absent. On a grander scale, stories need to hold individual merit; celebrity news will never meet that requirement because celebrity news is inherently tabloid, but the change of a head of state or major scientific discovery is "in the news". Lucy Letby's conviction is internal news to the United Kingdom. It holds no global significance and is not particularly exceptional in the U.K. With regards to ITN's processes, I take no issue with the consensus system. However, consensus is difficult to achieve with geographic differences and systemic bias. elijahpepe@wikipedia (he/him) 06:26, 23 August 2023 (UTC)

The ITN box is big enough to easily hold 4-6 thumbnail pictures, and still have room for the Ongoing and RD tickers at the bottom. I would get rid of blurbs and replace them with pictures. The "significance" criteria should be replaced with something objective and measurable, like "front page coverage in multiple national newspapers outside the country where the event occurred." I don't agree with the 5-sentences/3-paragraphs rule for "recently updated" -- in fact, we don't need a rule for that at all; if it's front page coverage in multiple national newspapers outside the country where the event occurred, it's 100% guaranteed to have been updated in a Wikipedia article somewhere (or a new article created). I think "no" orange tags is too strict for quality -- some tags are OK, it depends on the tag. I think the one place where some subjectivity is OK is quality. Levivich (talk) 19:04, 23 August 2023 (UTC)

First, what are "front page headlines" in today's digital world is an impossible metric as spelled out on the ITN pages. But moreover if we did that we would succuum to the Western/US/UK bias that global media has. For example, we have just posted the Indian moon lender's arrival...That ain't going to be a front page topic against to-night GOP debates or Trump and codefendents turning themselves in. We need to have encyclopedic considerations of what topics that have been in the news that should be posted to avoid the systematic bias of the media. Masem (t) 20:28, 23 August 2023 (UTC)

Here are paper front page headlines in today's digital world. The India moon landing happened today; it'll be in the world's papers tomorrow as it's already on the websites. You can look at this morning's world front pages and see that BRICS is getting far more coverage than Trump or GOP debates. The evidence contradicts your assumptions. Levivich (talk) 20:38, 23 August 2023 (UTC)

The landing only just happened today so it won't be flecked for another 24hr. And to add to.the craziness of the news we have the plane crash in Russia. While India's success will likely be big in India, there's too much else that the media will grab onto to bury that elsewhere. That is we'd never see major scientific milestones at all, nor most elections, nor most sporting events, if we stuck to headlines. We want diversity of topics at ITN, so following the importance given by the press fails that. Masem (t) 21:00, 23 August 2023 (UTC)

You can click that link now and see the India moon landing on the front page of today's papers in China, Germany, Saudi Arabia, UAE, among others. The Russian plane crash is also all over the world's front pages. Not Trump or GOP or American politics. Levivich (talk) 04:27, 24 August 2023 (UTC)

I agree with Levivich; and I want to expand ITN and make it less focused on notability and newness. Cover more topics. Andre🚐 21:24, 23 August 2023 (UTC)

Do you really want to make "In The News" be less about what's in the news? WhatamIdoing (talk) 19:19, 24 August 2023 (UTC)

If you want ITN to be something other than ITN, that would probably be better discussed with its abolition, below. 331dot (talk) 19:28, 24 August 2023 (UTC)

That could be easily be solved, though, by defining a broader range of media that would be considered reputable global media. Off the top of my head, we could consider the Times of India, the South China Morning Post, the Straits Times, Al Jazeera - and these are just some English language ones. Khuft (talk) 20:59, 23 August 2023 (UTC)

We already determine that at WP:RSN and WP:RSP Andre🚐 21:25, 23 August 2023 (UTC)

I'd actually much rather abolish RD altogether and just leave the hook to Deaths in 2023 in the box. That page gives you more information then just a link on the homepage and covers almost all deaths, not just ones that someone bothered to work on the page for. Just a box of deaths feels kinda boring and would lead to endless debate over what picture to use, which is always a silly debate that can be solved by "who cares, don't have a picture". DarkSide830 (talk) 04:13, 24 August 2023 (UTC)

RD has been effective and works well; I strongly oppose removing it even if ITN was ultimately done away with(which I also oppose). 331dot (talk) 19:27, 24 August 2023 (UTC)

And you are entitled to that opinion, but I simply think a short list of names of dead people on the mainpage is less useful when you are already linking to a longer list of dead people already. But to each their own. DarkSide830 (talk) 22:47, 25 August 2023 (UTC)

I'm not seeing any evidence that RD is "effective and works well". It tends to work in a perverse way so that, the more accomplished a person, the less likely they are to be posted – see Jimmy Buffett for a recent example. And, even if someone is posted, the listing is so brief, content-free and perfunctory that most readers don't notice and so the effect on readership is negligible. Andrew🐉(talk) 12:16, 11 September 2023 (UTC)

The Buffett situation is less of an RD issue and is more emblematic of the poor state of many of our articles on actors and musicians. In recent weeks, plenty of very accomplished people, such as Bill Richardson and Heath Streak, were posted in a timely manner. Curbon7 (talk) 21:10, 11 September 2023 (UTC)

The Jimmy Buffett article is graded C-class just like the Heath Streak article. And, for most of our readership, it's far better because it has good pictures while Streak has none at all. And our readers have voted with their feet, ignoring ITN's idiosyncratic and irrelevant obsessions. The only thing resembling a complaint on Buffett's talk page seems to have been from the man himself. He observed that communications were poor and that's for sure. And now we'll never know what was on his mind, alas. Andrew🐉(talk) 10:21, 12 September 2023 (UTC)

Right, I get the point about readership, but the issue is that since these are going to be highlighted on the main page, there is a degree of basic quality (not too dissimilar from DYK) needed. If I remember correctly, several blurbs of the most recent Nobel winners, including the peace prize, were not posted on similar quality grounds; perhaps a solution could be to more actively encourage ITN editors to improve articles with sourcing/prose issues rather than simply commenting on those issues. Curbon7 (talk) 19:18, 12 September 2023 (UTC)

Given the daily violations of WP:OR, WP:CONSENSUS, and WP:OWN after countless warnings (for the main page no less), the additional disregard for WP:N and WP:NOT, and the fact that these frequent village pump discussions have yet to accomplish a thing, the idea of an ANI discussion about the ITN community as a whole is sounding more and more reasonable. Thebiguglyalien (talk) 18:47, 6 September 2023 (UTC)

There are plenty of ideas floated here, you are welcome to be bold and start an RfC on any you want. Curbon7 (talk) 21:27, 6 September 2023 (UTC)

An ANI discussion about the entire ITN community? As if that place didn't have enough drama to fill a hogshead. What are you suggesting; indef blocks all around? _{Duly signed,} ⛵ WaltClipper -(talk) 14:17, 10 September 2023 (UTC)

I proposed something similar, but with a slight twist: require articles in newspapers of record in 3 (5? more?) separate countries. That includes non-Western countries. Criteria for cleanup tags/quality can be debated separately, but the main problem at ITN is the total subjectivity of "this topic is worth featuring at ITN, this topic isn't". Only one way to solve that: defer to an external authority (our sources), otherwise people just make up criteria as they go. That subjectivity increases Western bias, it doesn't decrease it, contrary to widespread belief. And it just needs to go. DFlhb (talk) 15:48, 10 September 2023 (UTC)

@BilledMammal also suggested this, and I think something like that would be optimal. I also like @Levivich's suggestion of using frontpages as a metric for what current events are important globally. Everyone I know who isn't a wiki editor already thinks the only purpose of ITN is to highlight the biggest news stories around the world. JoelleJay (talk) 20:34, 10 September 2023 (UTC)

I'm honestly not surprised that both this discussion and similarly the abolition discussion has petered out yet again. ITN seems to be one of those issues where people would like to see it changed, but it's such a low-profile section of the Main Page that the only time we notice it is when there's a Big Problem. And once the Big Problem more or less quietly lapses into obscurity, its back to business as usual. Thinking out loud, rather than focusing the topic around getting rid of ITN in particular, perhaps any discussion on altering the Main Page needs to specifically be more additive/constructive, i.e. is it worth changing or replacing any section so that we can publicize Wikipedia:Featured lists? _{Duly signed,} ⛵ WaltClipper -(talk) 14:34, 24 September 2023 (UTC)

WaltCip, I think based on how this discussion went, a good start would be community-imposed WP:General sanctions for civility at ITN. Curbon7 (talk) 04:46, 25 September 2023 (UTC)

It's worth a try, though I think at this point, we'll honestly have to wait for yet another flareup of incivility at ITN/C before the community will have an appetite to reconsider the issue. _{Duly signed,} ⛵ WaltClipper -(talk) 14:02, 25 September 2023 (UTC)

I think an ANI discussion would be a good idea. In general however I think the ban hammer should be wielded more liberally. Let's make it a designated 'strict' space, with immediate 1 year ITN-specific interaction bans for those who are not conductive to a participatory and collaborative environment. —TheDJ (talk • contribs) 14:42, 25 September 2023 (UTC)

There have always been ANI discussions regarding individual problematic editors at ITN; two recent examples I can remember are this civility restriction) and this p-block. If you want a comprehensive look, that's probably going to have to go through WP:ARBCOM as I reckon it'd be way out of ANI's capability. Curbon7 (talk) 16:53, 25 September 2023 (UTC)

Rewording WP:General sanctions' mentions on discretionary sanctions into contentious topics

As noticed on the General Sanctions page, many topics are still listed as using the old discretionary sanctions system, and not the superseding Contentious Topics procedure now in force. To avoid potential editor confusion, I think we should brainstorm on how to reword the general sanctions' listing into Contentious Topics. I would be bold, but I'm concerned that one editor, let alone a non-admin, would be able to do so officially and with wide-ranging acceptance from the community. InvadingInvader (userpage, talk) 18:58, 11 September 2023 (UTC)

I would be even bolder and split "WP:CT" into "Community designated contentious topics" and "Arbitration designated contentious topics". The same procedure as designated by ArbCom would apply for both. Aasim - Herrscher of Wikis ❄️ 18:12, 12 September 2023 (UTC)

Hmmmm – maybe that might be needed. If you end up taking it to VPPR, I'd probably back it. InvadingInvader (userpage, talk) 18:26, 12 September 2023 (UTC)

@InvadingInvader How would this RfC format look like:

----

Title: "RfC: Converting Community Authorized Discretionary Sanctions to Contentious Topics"

Should all community sanctions previously authorized under the discretionary sanctions procedure be formally converted to "contentious topics" as set out by the Arbitration Committee? /sign/

Background:

In 2021-2022, the Arbitration Committee has overhauled its discretionary sanctions system with new procedures specifying how people are alerted to contentious topics. While these changes are great, the old community discretionary sanctions procedure still technically applies to community authorized contentious topics.

The purpose of this RfC is to formalize if and how this conversion process should be undergone. There are multiple ways this merge can be done, including:

• Moving Wikipedia:Contentious topics and all subpages to Wikipedia:Contentious topics (arbitration), move Wikipedia:General sanctions to Wikipedia:Contentious topics (community) and add/disambiguate more information about contentious topics in general to the main title
• Merge information on Wikipedia:General sanctions to Wikipedia:Contentious topics and archive the old page
• Update and merge the related templates to work on both community and arbitration designated contentious topics

----

I think this could be edited further but I absolutely think it is a great idea to unify the two together. Aasim - Herrscher of Wikis ❄️ 16:05, 20 September 2023 (UTC)

Note "general sanctions" is not synonymous with community-authorized discretionary sanctions. (Also note that strictly speaking, authorizing the use of discretionary sanctions or designating an area as a contentious topic isn't a sanction yet.) Thus I think Wikipedia:General sanctions should continue to cover all types of sanctions that apply to all editors (such as page restrictions), and not be subsumed under a title of "Contentious topics". Personally I would prefer keeping "Contentious topics" as the page name for the community-consensus approved system, with a separate Arbitration-committee controlled page that describes specifics for its customizations. isaacl (talk) 17:12, 20 September 2023 (UTC)

Paraphrasing a comment I made at Template talk:Gs, I think a good way forward is for the community to formally convert all of its previous authorizations for discretionary sanctions into community designations of contentious topics, and then to work with the arbitration committee to take over responsibility for the contentious topics process and procedures, providing the committee the ability to add its own customizations as desired. This would keep the base process and pages describing it under community control and so they wouldn't disappear in future if the committee decided to move away from contentious topics. isaacl (talk) 21:32, 12 September 2023 (UTC)

I actually started a little in Module:Sanctions/sandbox and Module:Sanctions/data/sandbox what a merged Contentious Topics handling both ArbCom and community designations module might look like. You can see Template:Contentious topics/alert/first/sandbox and Template:Contentious topics/alert/sandbox for what the merged alerts would look like. Of course I would probably have to ask ArbCom before the behavior could even be merged. It probably would be a quick and simple motion to authorize the merge though. Aasim - Herrscher of Wikis ❄️ 23:30, 25 September 2023 (UTC)

Suggestion for "Recent Deaths" category

I'm not sure this would be technologically possible, but thought I would raise my suggestion. If one goes to the category "Deaths in 2023", one can see the sub-category "Recent deaths". Today (September 22 2023) there were at one time six entries in this category, but now there are only four. My suggestion is this. How would folk feel about being able to click on the "Page history" tag of "Recent deaths", and be able to see what names were formerly there? This would give readers of Wikipedia a chance to see which names have recently been moved from this category, and when they have stopped having the "Recent deaths" tag heading their page. YTKJ (talk) 19:59, 22 September 2023 (UTC)

The listings of articles under a category are automatically generated based on the category tags in the text of an article. Implementing this change would require changes to the MediaWiki internals, and I imagine going through every previous edit of every article in the past to see if a category was added or removed and then caching that data would be a substantial undertaking. ― novov (t c) 00:40, 23 September 2023 (UTC)

Several related proposals are listed at Meta:Community Wishlist Survey 2023/Search and Categories ~ 🦝 Shushugah (he/him • talk) 16:45, 23 September 2023 (UTC)

@YTKJ: Try User:Nardog/CatChangesViewer. Works on any category, but only for the last 30 days. Suffusion of Yellow (talk) 23:26, 26 September 2023 (UTC)

Source variable expansion?

Essentially, I would like to open a discussion around the citation variables, although not required by APA/MLA/IEEE/etc format, is in the interest of user clarity (who may or may not be familiar with the different styles yet seeking verification or further reading) and finding the same edition. And I'm not sure if 'format' is meant to take the place of some this or not. However, for ISBNs, there are quite a lot of variations. Location is one, though this is made up for by specifying 'location'. However, most editions have around 3 variations for ISBNs: hardcover, paperback, and ebook. For DOI, there are chapter DOIs (Brill and Cambridge University Press are two common examples of publishers that create separate DOIs for their chapters in addition to their books) just as there can be chapter urls though as yet there is no way to distinguish between the two in the citations. ISSN numbers also commonly have two variations, online formats and print editions. Some sources also have 'dynamic' urls, where the website is consistently updated, and 'static' urls which are not quite an archive but close and where the website has a static, saved form (the Standford Encyclopedia of Philosophy is one of many examples of this). In some cases, the dynamic may be preferred in 'further reading' for the most updated info, while the static may be more preferred for source citing. Regardless, I was wondering if I am either missing a standard convention on Wikipedia or if some tweak to the standard citation variables which might be worth suggesting. Thoughts? KnowTheManyHistories (talk) 08:42, 26 September 2023 (UTC)

Wikipedia:SAYWHEREYOUREADIT applies - we list the edition that have been used as sources.Nigel Ish (talk) 09:08, 26 September 2023 (UTC)

Thanks! KnowTheManyHistories (talk) 01:18, 27 September 2023 (UTC)

User:KnowTheManyHistories, the citation templates are pretty thoroughly documented. For your question about the |format= parameter, see Help:Citation Style 1#External links. As Nigel Ish says directly above, we use the url, isbn, etc. of whichever version of the work we consult for citing. That's the standard convention, and it's ok to have missed it.

Since the citation templates also produce COinS metadata for reuse by data scrapers, the template parameters have pretty strict use cases, and the primary maintainer is still very engaged with the project. If you still have questions after reading WP:SAYWHEREYOUREADIT and Help:Citation Style 1, it's possible your questions may already have been addressed at Help talk:Citation Style 1. This link will let you search its archives. Folly Mox (talk) 17:43, 26 September 2023 (UTC)

Thank you both! After further reading, I'm wondering if maybe it might be worth making some explicit section on the Help:Citation Style 1 stating whatever the current Wikipedia standard for handling such cases on the page and posted my thoughts to the talk page (under "format=" and "chapter" sections). And yes, looking through the Archives, it looks like the chapter-doi was proposed before and then scrapped, as far as I can tell. KnowTheManyHistories (talk) 01:16, 27 September 2023 (UTC)

Selection criteria for lists involving subjective categorization

There is a broad issue with lists that involve subjective categorization being breeding grounds for WP:OR, WP:SYNTH, and WP:UNDUE violations. To address this, I have been work shopping a new section, based on WP:DUE, that would be included at WP:Stand-alone lists, and I am bringing it here for further work shopping:

Selection criteria for lists involving subjective categorization

To comply with core policies on neutrality and original research topics should only be included unqualified in a list involving subjective categorization, such as List of video games considered the best or List of massacres in France, if the view that the categorization applies is the view of the majority, substantiated with references to commonly accepted reference texts. If the view that the categorization applies is held by significant minority then the topic can be included alongside appropriate qualification that makes it clear that its inclusion is not the majority view.

This is particularly important when the category is covered by MOS:PUFFERY or MOS:LABEL.

The intent of if the view that the categorization applies is the view of the majority, substantiated with references to commonly accepted reference texts is to make it clear that WP:DUE applies, but the exact wording to do so likely needs further work and comments on that aspect in particular would be appreciated.

Previous discussions can be found at NPOVN and SAL. BilledMammal (talk) 13:14, 8 August 2023 (UTC)

I'm not sure I understand entirely what this proposal is...er...proposing:

1. By "topics" do you mean articles? If not, then what do you mean?
2. What do you mean by "unqualified"? Are you suggesting that it's okay to include items on a list without reliable sources that support their inclusion?
3. What do you mean by majority, and do you mean to imply that a majority should take precedent over a consensus?
4. In my experience, list articles don't typically include items that then have notes indicating that whether they belong on the list is contested.

DonIago (talk) 13:44, 8 August 2023 (UTC)

1. "Topics" refers to the individual subjects, entries, or items that might be included in a list.
2. "Unqualified" refers to the inclusion of a topic in a list without any accompanying clarifications indicating that its inclusion might be controversial or not universally accepted
3. "Majority" has the same meaning here that it does in WP:DUE; that there is a consensus among reliable sources that the subjective categorization applies.
4. List articles typically don't, but to comply with the requirements of WP:DUE they should; we can't be presenting the view of a minority as if it was the view of the majority.

BilledMammal (talk) 14:03, 8 August 2023 (UTC)

1. Thanks for clarifying!
2. I'll be curious to hear from other editors regarding whether list articles should include items considered contentious.
3. How would we determine whether a majority of reliable sources consider a video game the best or consider an incident in France to be a massacre? There's at least probably video game review aggregators that could be used to say a game was well-reviewed, but "the best"? I have doubts that there's a similar aggregator to say whether most people consider an incident in France to be a massacre.
4. This sounds like your opinion rather than an established consensus?

DonIago (talk) 17:01, 8 August 2023 (UTC)

For #3, it's not a "majority of reliable sources", but "the view of the majority". As for how we determine that, the same way we determine it for every other article; this isn't a new requirement, it already applies to every article, including lists, through WP:NPOV.

For #4, this is established consensus in that it is part of NPOV and non-negotiable; even if there was a consensus against it (ie, a consensus that allows us to present minority viewpoints as if they were on the same level as majority viewpoints) NPOV would require us to reject it.

In general, all I am proposing to do here is make it very clear that NPOV does apply to lists, and provide some structure on how to apply it. BilledMammal (talk) 06:11, 13 August 2023 (UTC)

I think the text should be simplified a bit... someone with English not as their first language could struggle with "unqualified in a list involving subjective categorization" and "the categorization applies is the view of the majority"... heck, I'm struggling myself! Edward-Woodrow :) _[talk] 13:47, 8 August 2023 (UTC)

That's kind of what I was getting at with my earlier comment; I think this is a bit of a word salad, but without knowing what the intentions are it's challenging for me to suggest less complex wording. DonIago (talk) 13:57, 8 August 2023 (UTC)

It definitely needs rewording, though I'm not currently sure how to simplify it but still get the point across. BilledMammal (talk) 14:12, 8 August 2023 (UTC)

"Majority" and "minority" of what? Sources or editors? Schazjmd (talk) 13:58, 8 August 2023 (UTC)

See my reply to Doniago above. BilledMammal (talk) 14:12, 8 August 2023 (UTC)

I think the biggest problem with this proposal is that editors do not have a shared understanding of what it means for something to be subjective. Some editors think that subjective means something like "word that makes me feel like someone disapproves" or "label". Based on recent discussions, I would expect this to be invoked for discussions about List of bank robbers and robberies, not just for List of massacres. (A massacre is no more subjective than the color green. Having a slightly vague definition (vague definition: "killing a lot of defenseless people"; precise definition: "killing 17 or more defenseless people") is not the same thing as being subjective (subjective definition: "If you are the killer, then a massacre means killing 17 or more defenseless people, but if you are one of the people being killed, then killing anyone including you is a massacre". Objective definition: "killing a lot of defenseless people").

See also User:WhatamIdoing/Subjectivity in Wikipedia articles (work in progress). WhatamIdoing (talk) 18:49, 14 August 2023 (UTC)

Nice essay! Do you have any illustrative article examples in mind? – Reidgreg (talk) 12:22, 16 August 2023 (UTC)

Thanks, @Reidgreg. I didn't write it with any article in mind, but nearly every medical article will have some aspect of this (e.g., kids recover quickly from Tonsillectomy, but the same procedure is harder on adults; don't give this drug to kids or pregnant women; preventive healthcare efforts, like checking your cholesterol levels, are kinda pointless if you're already dying of something else). It's probably more challenging to hit the right balance in political areas: China thinks A but the US thinks B; poor people think C but rich people think D; young adults think E and older adults think F, etc. WhatamIdoing (talk) 15:52, 17 August 2023 (UTC)

We can include a definition of subjective categorization; "Subjective categorization" would be any categorization that is not based on measurable and universally accepted criteria.

List of bank robbers and robberies has a measurable and universally accepted criteria, and so is not subjective. List of massacres does not have a universally accepted criteria, and so is subjective. Would that address your concerns? BilledMammal (talk) 16:30, 16 August 2023 (UTC)

I think that you need to move away from the "subjective" language, because it will be misinterpreted. Wikipedia:Policy writing is hard, and one of the ways to do better at it is to avoid words that are not well settled or that mean something different in the real world. We do not need another 20 years of "Yes, well, it might be notable, but it's not WP:Notable", only this time using subjective as the confusing wikijargon word. If you want "measurable and universally accepted criteria", then say that and do not say subjective.

I'm not sure that List of bank robbers and robberies has universally accepted criteria. How many of the events in Cryptocurrency#Loss, theft, and fraud belong in that list? They're banks (i.e., financial institutions accepting deposits from the general public) but not legally regulated banks, and the money (which is real money, but not government-issued money) was stolen. Were those bank robberies? WhatamIdoing (talk) 15:47, 17 August 2023 (UTC)

Wikipedia:Policy writing is hard, and one of the ways to do better at it is to avoid words that are not well settled or that mean something different in the real world. That is the meaning in the real world - I didn't make it up, and when I ran it through ChatGPT as a method of verifying comprehensibility it correctly interpreted every aspect, including that one.

I don't mind considering alternative wording, but I think subjective, as the opposite of objective, is the best word here.

How many of the events in Cryptocurrency#Loss, theft, and fraud belong in that list? Skimming it, none. Bank robbery requires force, violence, or threat of violence, and it appears that none of those thefts involved that. BilledMammal (talk) 16:02, 17 August 2023 (UTC)

You say that this is the meaning in the real world, and yet when I look at https://www.merriam-webster.com/dictionary/subjective and https://dictionary.cambridge.org/dictionary/english/subjective or even wikt:subjective, I do not find either of the words measurable or universal.

According to your notion of bank "robbery", a bank "burglary" does not belong in the List of bank robbers and robberies. The law (int he US) might treat breaking into a bank in the middle of the night to steal money out of the vault yourself as being distinct from threatening to kill someone if they don't take the money out of the vault and give it to you, but I'm not sure that the Wikipedia list makes the same distinction. The incident described at the top of List of bank robbers and robberies#Slovenia would technically be considered a burglary, if it happened in the US. If you go back to this idea that the definition is "universal", then I don't think that the definition of bank robbery is universal. I think the US FBI says that there are robberies (e.g., threatening the teller) and burglaries (e.g., sneaking in at night) and thefts (e.g., computer hacking), and that most people use bank robbery to mean any crime in which depositors' money is stolen from a depository institution. WhatamIdoing (talk) 16:52, 17 August 2023 (UTC)

For bank robbery, I just followed the definition at Bank robbery, but that article may reflect a US perspective rather than an international perspective - if there isn't a universal definition of what a bank robbery is then we would need to follow the sources rather than permitting editors to determine whether items belong in that list based on a universal and measurable criteria and description of the item.

The important thing is that our articles, including our lists, follow WP:NPOV. To hopefully address some of your concerns, I've reworded the proposal:

Selection criteria for lists involving subjective categorization

To comply with core policies on neutrality and original research topics should only be included unqualified in lists without a measurable and universally accepted definition, such as List of video games considered the best or List of massacres in France, if the view that the categorization applies is the view of the majority, substantiated with references to commonly accepted reference texts. If the view that the categorization applies is held by significant minority then the topic can be included alongside appropriate qualification that makes it clear that its inclusion is not the majority view.

This is particularly important when the category is covered by MOS:PUFFERY or MOS:LABEL.

BilledMammal (talk) 08:46, 2 September 2023 (UTC)

I am currently leaning towards taking the reworded proposal to RfC:

Selection criteria for lists involving subjective categorization

To comply with core policies on neutrality and original research topics should only be included unqualified in lists without a measurable and universally accepted definition, such as List of video games considered the best or List of massacres in France, if the view that the categorization applies is the view of the majority, substantiated with references to commonly accepted reference texts. If the view that the categorization applies is held by significant minority then the topic can be included alongside appropriate qualification that makes it clear that its inclusion is not the majority view.

This is particularly important when the category is covered by MOS:PUFFERY or MOS:LABEL.

Any thoughts - in particular, do people think the general concept is a good idea; while there was some support at NPOVN, that aspect hasn't seen much discussion here? I would like to reword phrases like should only be included unqualified in lists to address the above concerns, but I haven't been able to work out how to do so without changing the meaning. BilledMammal (talk) 05:52, 13 September 2023 (UTC)

Do you feel like it's really important to use the (dispute-prone) word subjective in the title?

Also, try pasting that into https://hemingwayapp.com/ and see whether you can figure out how to make it simpler. The first paragraph is 94 words long, and only two sentences. Having more but shorter sentences might help you re-word around that problem.

As for its prospects: I think timing will be key. If there's relevant drama going on, we might marry in haste and repent at leisure. Otherwise, there's a chance that editors will see it as unnecessary. For myself, I'd like to see how you would change half a dozen lists to comply with your proposal. WhatamIdoing (talk) 02:58, 14 September 2023 (UTC)

For myself, I'd like to see how you would change half a dozen lists to comply with your proposal. Do you have a couple of examples that you would like to see this on? BilledMammal (talk) 13:14, 27 September 2023 (UTC)

Portals should be strongly encouraged to organize around sparql

Wikidata has the expressive capability of organizing the knowledge graph on Wikipedia. Where appropriate, portal stewards should topline the sparql which returns of all the content they are interested in. This will have some benefits: portal will gain a clearly defined scope, domain experts will work with wikidata to ensure its expressive enough, portal stewards will likely discover content they were unaware of that was relevant to their scope, and portal users will be able to re-use the queries when portals align with their needs.

Ideally portal stewards will work with wikidata folks to create the queries. Some type of queue page would be useful to track this. Wikiqrdl (talk) 02:03, 25 September 2023 (UTC)

See the above section #Use of Wikidata values in infoboxes for information about how we (mostly don't) use Wikidata.

Also, this isn't the kind of thing that I'd expect someone to pick up in their first month, but a significant fraction of the community would like to see the portals deleted entirely. I'm therefore not sure that making major improvements to them is very pointful. WhatamIdoing (talk) 05:39, 25 September 2023 (UTC)

I'm familiar with this, and the attempt to remove portals was roundly rejected and rightfully so. Portals are largely the children of wikiprojects. You could get rid of Portals, but they'd still find a home somewhere else. Groups of people want to take responsibility for an area of wikipedia, and portals provide them with a place to do this. Wikiqrdl (talk) 02:21, 26 September 2023 (UTC)

Portals are largely the children of wikiprojects.

In my experience, portals are largely the work of a handful of enthusiasts and a handful of editors who needed to be able to claim that they had created "featured content" at their Wikipedia:Requests for adminship (long before we killed the Wikipedia:Featured portals process). I know a fair bit about the larger WikiProjects, and I could not name a single one except Wikipedia:WikiProject Portals itself that actually cares about the portal(s) in related subjects. For example, it looks like Wikipedia:WikiProject Medicine hasn't talked about any portal since 2016. The last comment I see about editing a portal at MILHIST was in 2012, and it was just a single comment. Do you have any actual evidence that WikiProjects care about portals? WhatamIdoing (talk) 02:55, 26 September 2023 (UTC)

Wikiproject pages ARE portals. Maybe what your issue is, is that portals overlap with other content and with each other. Perhaps they should all be renamed to "meta pages", content about the wp content, and then merging functionality should be put in place. When meta pages go dormant / inactive, they should become candidates for redirection to more active meta pages, and at some point simply removed. Regardless of what is done, these meta pages are extremely important. And don't get caught up in traffic #s. There are research papers which get maybe 10 hits a day and yet are some of the most important content in the world. Wikiqrdl (talk) 04:13, 27 September 2023 (UTC)

As an example: this page is my defacto portal to wikipedia science - https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Science

An indeed, the wikiproject template tags are my most important view into wikipedia science pages. Wikiqrdl (talk) 04:24, 27 September 2023 (UTC)

I think there's been a misunderstanding here. On enwiki we have portals in a dedicated namespace, like Portal:Science. They're intended as a navigational aid for readers (whether they're used as such is debateable) and aren't used to coordinate maintenance or any sort of "meta" activity. That's what we understand you're referring to when you say "portal". Per Kusma's comment before, there's perhaps been some confusion because other projects use the portal namespace in the same way that we use WikiProjects on enwiki. So it sounds like what you're suggesting is that WikiProjects should be reorganised around SPARQL queries? What would that gain us, over our existing system of banners and tracking categories? – Joe (talk) 04:36, 27 September 2023 (UTC)

Sure, but it's all largely the same effort - duplicated in many different ways. Outlines, portals, wikiprojects and their template tags, wikidata. It's all an attempt to control and expose the knowledge graph in a sensible and productive manner (which categorylinks most definitely is not and never can be). I will say that I agree that Portals, in their current form, have some issues, but the same could be said about the other namespaces/pages I mentioned. The real underlying issue here is the redundancy, half-hearted efforts that have been inconsistently spread across different surfaces. Wikiqrdl (talk) 09:32, 27 September 2023 (UTC)

The most rational place to centralize all of these efforts would be sparql. By strongly encouraging everyone to use a sparql query as a jumping off point for describing the scope of an area of wikipedia, we force the development and completion of the wikidata vision - which is fullly describing the wikipedia knowledge graph. Things like template tags go away, as well as attempts to create individualized 'category views' which get scattered about in a way that's nearly impossible to track properly. Wikiqrdl (talk) 09:37, 27 September 2023 (UTC)

A Wikipedia:WikiProject is a group of people that want to work together to improve Wikipedia. Sometimes, that group wants to work together around a content subject area, and we end up with a WikiProject like Wikipedia:WikiProject Medicine. However, that group (and the pages they use to coordinate their work), are completely different from Portal:Medicine (and the people who maintain that page).

It may happen that if you want to find most of the articles about medicine, that you could begin your search at Category:Medicine articles by quality, but it (unfortunately) won't be complete, and it's really just a coincidence that the subject area you want overlaps with the subject area that a group of editors chose as their personal interest area. WhatamIdoing (talk) 22:04, 27 September 2023 (UTC)

And yes, wikidata needs improvement for sure. But that's the point - by increasing its use there would be more effort to get it updated. Wikiqrdl (talk) 02:25, 26 September 2023 (UTC)

I see the problem the other way, improving and simplifying wikidata's interface is required before it will find greater adoption. Being able to edit the data from where it is being used and then backflushed to wikidata would also help. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:09, 26 September 2023 (UTC)

Some of the Wikivoyages are already doing this. It mostly gets used for updating the websites and lat/long locations of attractions. WhatamIdoing (talk) 14:50, 26 September 2023 (UTC)

You can't simplify wikidata, simplifying is what creates the problem and all these random / scattered efforts which can't be satisisfied by basic, linear hiearchical categorization. The knowledge graph will always be high dimensional, that is, you can approach it from different perspectives. sparql and wikidata are the best way forward to capture the inherent complexity. Wikiqrdl (talk) 09:45, 27 September 2023 (UTC)

Just because something is highly complex doesn't mean that the interface for it has to be highly complex, unintuitive and difficult to use. Finding simple ways for editors to add value to wikidata should be a key objective. A lot of pushback hangs on undue/unreferenced content, or the inability to change that content without having to enter a completely separate sister project. If Wikipedia editors could add references or make changes to content in a simple way, that would in turn have benefit for wikidata and further wikidata integration. Similarly if Wikipedia editors had simple controls on what was imported it would go a long way in building trust of Wikidata. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 22:25, 27 September 2023 (UTC)

No one WP:OWNS a portal. Also, what, pray, is sparql? Edward-Woodrow • talk 19:37, 25 September 2023 (UTC)

Probably SPARQL. I also learned wikt:topline, The upper curvature of a horse's or dog's withers, back, and loin. Folly Mox (talk) 23:31, 25 September 2023 (UTC)

An interesting proposal. Effectively this is an attempt to define a "portal" in information architecture and semantics terms, which is quite welcome, but is not really what the general public thinks of when they hear "portal". Generally, "portal" pages are works of art not data-defined artefacts. My thinking is that there is CERTAINLY a place for Wikidata SPARQL-defined content sets, but it is not as replacement of the traditional "portal". Trying to think of a good name for such a thing ... maybe "collation"? A portal in the current sense could encompass one or more "collations" of content; likewise a very large "collation" might encompass multiple portals -- albeit, I've not done the queries and comparisons to see how these concepts dovetail ( and doubt I'll have energy to do so, myself .. help from fresh young energetic folk to take this concept forward?? ) --User:Ceyockey (talk to me) 02:53, 26 September 2023 (UTC)

The problem is that wikidata is an extremely ambitious project, trying to develop an ontology for the knowledge graph. It's very hard to do. The template tags on talk pages are handling this problem for now, but at some point wikidata should take over. One way to handle this would be through AI automation with human review. If a portal/project/meta page (ie, content about wp content) wants to organize, they come to a wikidata page and say hey 'what would be good query for this?'. Maybe they try out the query builder first to get the ball rolling. https://query.wikidata.org/querybuilder/?uselang=en This will reveal gaps in wikidata that need to be addressed, with highest priority stuff (content people actually care about at a meta level) getting tackled first Wikiqrdl (talk) 04:31, 27 September 2023 (UTC)

I think this is an interesting idea. I'm one of those who sees portals as a failed experiment, but since enough editors still believe in them that we can't get rid of them, a compromise that improves quality while reducing the maintenance burden is very welcome. I even think you could go further and have entirely automated Wikidata-based portals that select from queries of featured content, most viewed pages, etc. in their scope. It would be nice to see a proof of concept, @Wikiqrdl:, because I can't quite imagine how it would work with the tools we currently have on enwiki.

One thing it probably won't help with, unfortunately, is that very few people actually use portals. But that might help assuage concerns that information from WD is unreliable. – Joe (talk) 12:40, 26 September 2023 (UTC)

@Joe Roe The intention/goal is not so much to make portals gain more traffic. TBH, I've never used or been interested in portals for their content beyond their attempt to categorize. My entire interest lies in the fact that they have made an effort to curate/organize wikipedia pages. Indeed, if you go to google scholar, you will find 1000s of papers and researchers who are also interested in this problem. The Knowledge Graph is very important as it ties together everything we know. Portals, Outlines, WikiProject pages, wikidata itself - they are all trying roughly to do the same thing - create some kind of hierarchical management over all of wikipedia. Larry Sanger created this page back in the day - https://en.wikipedia.org/wiki/Wikipedia:Contents/Outlines Wikiqrdl (talk) 04:50, 27 September 2023 (UTC)

I think if there's one thing that the portals experience on enwiki shows, it's that organisation isn't a sufficient end in itself. If you want to get volunteers to create and maintain something, there has to be a clear benefit to editors and, above all, readers. – Joe (talk) 04:55, 27 September 2023 (UTC)

How can we tell if something has a clear benefit to our readers? Hawkeye7 (discuss) 05:58, 27 September 2023 (UTC)

Whether they look at it is a good first indication. – Joe (talk) 07:28, 27 September 2023 (UTC)

Readers don't seem to care about any of our hierarchical systems much. Portals may have dismal page views, but they are a lot more popular than Outlines (or categories, for that matter). See for example this pageview comparison between Canada and Germany portals, outlines, and categories. —Kusma (talk) 07:59, 27 September 2023 (UTC)

Meta data about wikipedia will never be high traffic. Using traffic as a metric is missing the point entirely. Appeal to popularity is never a great rational argument. And, I think the key part behind this idea is that by centralizing all of the meta data efforts into one place - wikidata - will reduce redundancy and allow for the ability to more with less.Wikiqrdl (talk) 09:48, 27 September 2023 (UTC)

I'm almost entirely certain I'm not understanding, but is the idea to rewrite the Portal system using SPARQL on Wikidata, and then host the Portals there? I think something along those lines might be really interesting for Wikidata, but I'm not sure how it applies to this project.

Also, there are benefits to organising the same information in multiple structures. People think differently and learn differently. We keep having sprawling discussions about whether it's better to have lots of teeny tiny articles about topics we don't have much information about, or fewer large list-style articles that talk about groups of those topics. I'm not sure reducing redundancy is something that's even desirable in this problem space, but I believe whatever your idea entails would be an interesting addition to the current situation. Folly Mox (talk) 17:48, 27 September 2023 (UTC)

Nothing is being rewritten, this is only meant to be suggestive and additive. Infobox like, which holds the query of all the relevant wikipedia pages the portal is scoped over. The query in the infobox links to the query results (necessarily cached). An infobox above the fold and strongly encouraged but not absolutely required. Yes, redundant efforts can be useful, but they rely on at least one of those efforts having a certain level of merit, and ideally there would be a way to merge those efforts once they pass above an accepted bar. Wikiqrdl (talk) 21:19, 27 September 2023 (UTC)

Also, portals/outlines/wikiprojects/category pages should have higher expectations of competence. This helps reduce poorly planned/considered ad-hoc efforts which often end up becoming dormant. This is meta-data about wikipedia and by its nature it is what manages and organizes our efforts. The people creating this meta data are not just domain experts, they are also 'Librarians' of human knowledge. It'd be reasonable to expect that they would try to be familiar or want to be familiar with sparql/wikidata. Not being able to do this is sort of like someone making substantive changes to an advanced mathematics article yet knowing very little about the topic at hand.Wikiqrdl (talk) 21:27, 27 September 2023 (UTC)

User:Wikiqrdl, do you think you could show us or link to a representative SPARQL query run against Wikidata to give us a picture of what it is you're envisioning here? Folly Mox (talk) 22:27, 27 September 2023 (UTC)

I'm working on that. I think there might be a road block in that the wikidata folks have decided they want to entirely ignore/throw out wikipedia categories. I understand the reluctance to engage, but simply ignoring them doesn't seem right to me. Wikiqrdl (talk) 03:39, 28 September 2023 (UTC)

On some Wikipedias (the German one, for example, "portals" are closely associated to a community of editors). Here on enwiki, the portals are a mostly a navigational tool, and the community of editors is called a WikiProject. WikiProjects are less dead than portals are, and already use various forms of automation to find new content, but I am not aware of any project (other than Women in Red, who use Wikidata for lists of missing articles) using Wikidata for this purpose. —Kusma (talk) 13:10, 26 September 2023 (UTC)

Drafting Responsive Vector 2022 RfC

I asked in phab:T291656 about why the responsive mode button not working in preferences on Vector 2022, and I was told that the reason it was not implemented is that some editors despise responsive skins. So I was thinking about how I could format this RfC with the maximum chance of success. I was thinking something along these lines:

• Option 1 - Enable Responsive Vector 2022, enable by default for all readers and editors (opt out in Special:Preferences or maybe via a button saying "switch to desktop")
• Option 2 - Enable Responsive Vector 2022, opt in for all readers and editors via Special:Preferences
• Option 3 - Roll out Vector 2022 on mobile site.
• Option 4 - Do nothing.

A follow up question would be for disabling the mobile front end on the English Wikipedia. This is a long term goal but well worth it as unifying the experience makes it much more consistent for all readers and editors. I don't know how to phrase the question though. Aasim - Herrscher of Wikis ❄️ 14:47, 7 September 2023 (UTC)

Is there somewhere we can try this out? An RFC without a demo is not likely to produce a meaningful result. People will just !vote based on their experiences with other responsive designs, about 90% of which (on the web in general) are based on the assumption that mobile == moron, hence all the hatred. Suffusion of Yellow (talk) 20:27, 7 September 2023 (UTC)

@Suffusion of Yellow: I was told in phab:T319305 and in Wikipedia:Requests_for_comment/Deployment_of_Vector_(2022)#Mobile_screenshots that adding one line of code in the header:

<meta name="viewport" content="width=device-width,initial-scale=1">

would add responsiveness to this skin. I tried it myself and it made the Vector 2022 skin feel a little more fluid and much much easier to interact with on mobile. BTW - Mobile devices don't misbehave, although certain browsers, namely Safari, end up causing lots of headaches.

Courtesy ping @Jdlrobson as they might be able to get a working demo up and running. Aasim - Herrscher of Wikis ❄️ 03:55, 8 September 2023 (UTC)

The word "despise" doesn't appear in that Phabricator ticket; are you thinking of another response elsewhere? From skimming the ticket, I get the sense that it hasn't been made a sufficient priority to achieve, and Jdlrobson response to you of getting an RfC approved would help with (a) elevating the priority and (b) justifying disrupting any users who had checked the preference and left it on, unaware that it might cause a change in future to the skin appearance. isaacl (talk) 21:12, 7 September 2023 (UTC)

I see the response (in essence) in the other ticket you've referenced, phab:T319305. isaacl (talk) 05:22, 8 September 2023 (UTC)

I disagree that unifying the experience... for all readers and editors is desirable at all, much less worth tradeoffs, workflow reconfiguration, drama threads, etc. Why should all readers and editors be forced into the same experience regardless of their device and its restrictions? I certainly wouldn't advocate for making Minerva the default skin on desktop, but it works well for mobile because I seldom have to perform pinch zooms or sidey swipes in order to inteface with the website.

I'm vaguely aware that what I'm responding to above is a followup question, but it's opaque to me what a "responsive skin" entails— even given the phab comment that it has something to do with "optimizing the viewport", which I think I might kinda understand. Folly Mox (talk) 04:29, 8 September 2023 (UTC)

When the first phones were released that could view web pages, web sites hadn't been designed to fit on smaller screens. Thus phones (and now other smaller screen devices) by default render the page as if the screen was bigger, and scale it down to fit. Adding the <meta name="viewport" ...> element shown above tells the phone not to do this, as the web page has been designed to fit on the screen (whatever size it is). A responsive web page design is one that is designed to lay itself out differently based on the size of the display screen, using various techniques to simplify ongoing maintenance. The Vector2022 skin has been designed to be responsive to the display size, but without the appropriate directive, the page is still rendered by the small screen device in the default manner (pretending the screen is larger and then scaling it down). isaacl (talk) 05:21, 8 September 2023 (UTC)

I think I might be fine phrasing question 1 as "Should Vector 2022 be deployed as responsive?", with the options for deployment in the beginning of the RfC. The second question would be "If Vector 2022 is deployed, should the mobile front end be removed?" with the options for removing the mobile front end "remove mobile front end and redirect to main site", "keep mobile front end but deploy Vector 2022 there", and "keep mobile front end and everything as is". Aasim - Herrscher of Wikis ❄️ 11:45, 8 September 2023 (UTC)

If / when this goes to proposal, I think it should be spelled out what effect each option will have on the mobile experience. I'm not particularly technologically illiterate and I appreciate and believe I understand User:isaacl's explanation of "responsive" above; it's worth keeping in mind that as compared to the overall userbase, the population segment active here at the VPs underrepresents mobile users.

Personally I'm rather fond of Minerva, and think it gets more right than not. The screenshots at phab:T319305 demonstrate that a responsive Vector 2022 would e.g. result in a lot of not particularly useful stuff at the top of revision histories (like how to use the page, what all the abbreviations mean, external tools, etc.) that crowd out two or three diffs. This is just one example out of probably dozens of changes to the mobile experience that might be unwanted.

Unless we're prepared to have a bunch of conversations weighing the pros and cons of placement – particularly top placement – of information and elements on non–reader-facing pages, the idea of "unifying the experience" loses us a lot of flexibility to account for user screen real estate. And while I'm not per se against having those conversations, as noted above desktop users are overrepresented in the active editor base, and any consensus decisions on how to present pages seem like they would fail to account adequately for the mobile experience almost perforce.

So I think what I might be arguing is that irrespective of whether or not Vector 2022 can have a responsive mode, removing the mobile frontend entirely seems like a much bigger project, and probably not a great idea given that non-editing readers outnumber us something like a thousand to one. Folly Mox (talk) 16:30, 8 September 2023 (UTC)

non-editing readers outnumber us something like a thousand to one Well, yeah, I think we should focus most of our resources on making sure that the reading experience is perfect, as editing on mobile has almost always sucked, typing on a keyboard that is not physical is not ergonomic. The Mobile Front End IMHO is just a band-aid that made the editing experience on mobile suck less, while really cleaning up the reading experience.

It should also be noted that most of these changes won't happen immediately, but WMF would probably help out a lot in taking steps to implement them to minimize breakage. Aasim - Herrscher of Wikis ❄️ 17:30, 8 September 2023 (UTC)

I agree with Folly Mox that changing the default skin for mobile users has a very different set of considerations, and would be better addressed in a separate request for comments if desired. I also suspect that the majority of non-logged in readers would prefer a skin tailored specifically for reading on mobile devices, but of course this could only be verified through user research. isaacl (talk) 16:43, 8 September 2023 (UTC)

Firstly thanks for starting this! Making Vector 2022 responsive is a relatively straightforward change that can be acted on within 1-4 weeks. I think it would be a very impactful change as it would draw a lot of attention to templates in articles that cause problems to mobile devices and pave the way for future RFCs.

Removing MobileFrontend is much more substantial work and Vector 2022 is not yet a suitable replacement IMO. I think such an RFC would need much more detail about the implementation and impact of the change. Perhaps this RFC could happen at a later date (if the first once passes) as then editors will have experienced the Vector 2022 skin on mobile and had a chance to see and understand those problems firsthand? Jdlrobson (talk) 17:06, 10 September 2023 (UTC)

@Jdlrobson Is the RFC of a good format? Aasim - Herrscher of Wikis ❄️ 15:42, 18 September 2023 (UTC)

On second thoughts - I think this might be a question for a future Vector 2022 consultation RfC. "What are your thoughts on a responsive Vector 2022 skin?" Aasim - Herrscher of Wikis ❄️ 20:49, 2 October 2023 (UTC)

Soft Delete

One of the barriers to dealing with the legacy issue of mass-created articles is that it is difficult to determine at scale whether we should have an article on that topic and some editors oppose removing the content without first making that determination, as it may make it a little harder to create a proper article in the future.

In WP:ARBDEL I briefly raised the possibility of splitting deletion into two forms; "hard deletion" and "soft deletion" as a method to address this; by removing one of the barriers to recreating an article if sources are found it may make the topic less contentious.

Hard deletion
Hard deletion would function as deletion does at the moment, and would be used for content that contain defamatory or other legally suspect material or would otherwise be subject to oversight or revision deletion. This should fulfill the requirements of the WMF to only allow trustworthy individuals access to deleted articles.

As we cannot retroactively determine whether soft deletion or hard deletion should be applied to past deletions, all past deletions would be converted to hard deletions.

Deletion demonstration

Soft deletion

Soft deletion would preserve public access to the history of an article, but restore the status of a page as a red-link; see the mockup to the left.

This will have several advantages:

1. It will ensure that the past content is accessible to all editors, which will:
   1. Make it easier to contest prods after the seven day notice period
   2. Make it easier to identify recreated articles that are eligible for WP:G4
   3. Make it easier to use that content if the topic becomes eligible, or is identified as eligible, for an article
2. It will mean that links to the article are displayed as redlinks, which may:
   1. Increase the chance that someone will create an article on the topic
   2. Increase the chance that a substantial article will exist on the topic, as new articles, particularly on obscure topics, are rarely expanded beyond a microstub if the creator does not do so
3. It will open up the possibility of non-admins being allowed to delete articles through a right similar to page mover

There is a disadvantage, in that it would make it easier for people to recreate articles on topics that the community has rejected. However, that can be handled through the use of salt, and I think it is outweighed by the advantages.

The largest issue with this would be implementation; it would require modification to the MediaWiki software, and whether the WMF would be willing to do those modifications is a difficult question. As such, I'm opening this up as a preliminary discussion of the idea; if there is a belief we should move forward with it or a variation on it we can consider how best to bring it to the WMF.

BilledMammal (talk) 18:28, 3 September 2023 (UTC)

A similar proposal from long, long ago. —Cryptic 18:37, 3 September 2023 (UTC)

That proposal appears to work without work from the WMF, which if still true would significant reduce the practical barriers to implementation, and the method proposed - making blanked pages function in the same way as deleted pages - would naturally implement the third possible benefit of soft deleting.

The biggest issue raised in that discussion is that editors would need to be aware they need to check for copyright violations prior to tagging for deletion. This could, however, be addressed by keeping "hard delete" as the default, and only using "soft delete" when it is explicitly called for, such as by a consensus at AfD when the participants believe it is possible an article could exist on a topic but sources are difficult to find. BilledMammal (talk) 19:01, 3 September 2023 (UTC)

I think this largely makes sense. Would viewing of "soft deleted" pages be restricted to editors, or for readers as well? Especially if it includes readers, we should have some pretty large caveats at the top, like this:

Edward-Woodrow :) _[talk] 20:41, 3 September 2023 (UTC)

My thinking was that it should be viewable to all, but on reflection I'm wondering if it would be better to limit it to editors; I can't see any benefit of non-editors viewing them, and I can see the potential for issues.

The idea of including a warning makes sense, though I would suggest only showing it when the reader is looking at the history, not when they are just looking at the page. BilledMammal (talk) 21:54, 3 September 2023 (UTC)

But who are "non-editors"? Many good (and bad) contributions come from IP addresses, though of course they're not allowed to create articles. Certes (talk) 10:31, 5 September 2023 (UTC)

This seems to overlap a bit with the idea behind draftification, which is to get content not ready for mainspace out of mainspace, and to get it out of Google Search results, without completely erasing it and allowing work to continue on it since it may have potential. Do we think it's a good idea to have another draftification-adjacent process? Also, would this help reduce any backlogs? –Novem Linguae (talk) 21:18, 3 September 2023 (UTC)

I see them being used for similar but different purposes. They both get content that is not ready for mainspace out of mainspace, but soft deletion would preserve the work and keep it readily accessible in the long term for future use, while draftification would provide space for work to continue in the short term.

Also, would this help reduce any backlogs? Aside from the "silent backlog" of mass-created articles, that I believe it will help address by reducing the finality of each result, there is the backlog at various XfD noticeboards (Pppery has a seemingly never-ending stream of them posted at WP:RFCL) that this would likely help to address by broadening the pool of editors technically capable of closing them. BilledMammal (talk) 21:54, 3 September 2023 (UTC)

It will end when there stop being deletion discussions that have been open for more than a month. I think my efforts there to draw attention to them are working, and this proposal wouldn't have any impact as it only applies to articles where as the backlogged venues are RfD and CfD, and the former target of a RfD-ed redirect/contents of a CfD-ed category are already publicly visible (although in the latter case somewhat of a pain to access). * Pppery * _{it has begun...} 21:58, 3 September 2023 (UTC)

Outside of copyvio or other legal/courtesy reasons, "soft deletion" would never need to convert to "hard deletion", because it's already in a deleted state. I.e. the soft deleted article can remain useful to editors in perpetuity. Whereas drafts are not in a deleted state so they likely do need some sort of cleanup mechanism. —siroχo 08:54, 4 September 2023 (UTC)

It seems similar, I agree, but draftification is really more to get the creator to fix whatever issues make it unsuitable for mainspace undisturbed, then hopefully move it back. "Soft deleted" pages (I assume) couldn't be edited, and would not be a working space. Edward-Woodrow :) _[talk] 12:21, 4 September 2023 (UTC)

Unless a page is protected from being created, anyone would be able to re-create it based on the earlier content. isaacl (talk) 16:45, 4 September 2023 (UTC)

As BilledMammal, said, that can be overcome by selective salting. Edward-Woodrow :) _[talk] 17:03, 4 September 2023 (UTC)

Yes, that's what's I said. Perhaps I misread the original proposal; my impression was that the default would be to allow a page to be re-created, contingent on the identification of appropriate sources, and only to block it from re-creation if this were identified as necessary. isaacl (talk) 17:57, 4 September 2023 (UTC)

Ah, perhaps I misunderstood your comment. Edward-Woodrow :) _[talk] 17:59, 4 September 2023 (UTC)

Anyone can recreate a page (at an unsalted title) anyway. A persistent creator of unwanted articles will have the previous wikitext saved at home ready to paste, and there are places to find deleted articles. The proposal just simplifies things for those who aren't wily career spammers. Certes (talk) 10:36, 5 September 2023 (UTC)

Yes, that's what I said regarding re-creation. isaacl (talk) 14:26, 5 September 2023 (UTC)

When I wrote the initial proposal for how drafts would work, I specifically omitted a hard deadline for deleting drafts so that they could be used as a form of soft delete. Several years later, G13 was expanded to enforce a harsh six month deadline for drafts, and it was decided that you can't dratify an article older than 90 days without consensus first. Ultimately I think we could use drafts as a form of low stakes soft delete again if that G13 criteria was repealed, now that we have developed a precedent of using the Village Pump to discuss mass draftfication of old articles. There is no reason we need to "clean up" drafts that readers can't find by hard deleting them. We can afford petabytes of database storage space for drafts, and they aren't visible to search. If that happened, then we could handle things like LUGSTUBS by draftifying them without any legitimate argument that it was a slow drip version of hard deletion. Steven Walling • talk 23:18, 5 September 2023 (UTC)

Personally, I really don't like the fact that drafts contributed to by active editors can be speedy deleted in just 6 months. It feels a bit counter to the spirit of WP:5P3 because it discourages use of a collaborative space for the ultimate Wikipedia backlog -- the "article creation backlog". —siroχo 01:43, 6 September 2023 (UTC)

I had a similar idea a while back, but never shared it. Thanks for getting the ball rolling! Anyway, this can be done without a software change, by creating a new noindexed namespace (let's call it "Archive"). Then a "soft deletion" of BadArticle would be accomplished as follows:

1. Move BadArticle to Archive:BadArticle without leaving a redirect.
2. Blank Archive:BadArticle, and replace the content some boilerplate disclaimer, instructing users that this page might be inaccurate and they should view the history.
3. Fully protect Archive:BadArticle.

Some combination of edit filters and title blacklist could be used to prevent non-admins from performing step 1.

With that said, I think there are certain classes of pages (apart from the obvious ones like copvios and attack pages) that should never be soft deleted. BLPs at least, for privacy reasons. No, not just "BLP violations". Any BLP and anything BLP-adjacent, e.g. "List of people who ....". And probably anything even slightly spammy; yes, these pages will be excluded from search engines, but the spammer might not know that. If they see there's a way to "create a profile on wiki" [sic] that exists in perpetuity, they might be motivated to create more spam.

I'll note that this method excludes the page from our own internal search engine. I cannot decide if that's a bug or a feature. Suffusion of Yellow (talk) 23:03, 4 September 2023 (UTC)

I support the proposal in principle and Suffusion of Yellow's implementation specifically for not requiring software changes (for which we might wait decades). There are many legitimate uses for seeing deleted pages, where not prohibited for good reason (copyvio, libel, etc.) They may have some content worth salvaging, and it's often useful to see a spammer or hoaxer's previous work when identifying sock puppets. Minor details need attention, such as what happens when we soft-delete the same title multiple times, but they are easily resolved (just add to the existing history?). Certes (talk) 10:47, 5 September 2023 (UTC)

what happens when someone wants to revive and improve Archive:BadArticle? Full protection would prevent its being moved to main or Draft: namespace (and we may want to prevent the latter anyway, as it might result in real deletion after six months.) Should an editor wanting to rescue the article copy-paste it with suitable attribution, or is there a better way? Certes (talk) 12:56, 5 September 2023 (UTC)

I guess they can request at WP:RM or WP:REFUND or some new page created for that purpose. We can even have two type of "archiving": "soft archiving" (just request unarchiving, no reason needed) and "hard archiving" (show that the consensus was misinterpreted, or start a new discussion). We can put something in Template:Editnotices/Namespace/Main to warn people if an archived page with same name exists, and direct them to request unarchiving instead of cutting and pasting. Suffusion of Yellow (talk) 20:31, 5 September 2023 (UTC)

I think this is a fair bit better than the "what if we had yet another unsupervised unilateral backdoor deletion method?" undertone of the OP and several supporters, and closer to being a workable proposal. I don't agree with the "make people request unarchiving if they want to make a new article" thing, which sounds closer to a soft salt -- most deleted articles that are recreated are just recreated, sometimes with history restored and sometimes not, and the idea that most of them have to formally request permission comes from the same error of perception that gets RSN making all its calls based on "how would this source be used in an AMPOL article?". I firmly agree that this should absolutely not be an unbundled delete, but rather a more flexible replacement for most deletions. (There are very few failed RfAs of viable candidates in the modern RfA era, but it's striking how many of them reference a more zealous interpretation of deletion or exclusion than the community endorses.) Vaticidalprophet 09:03, 6 September 2023 (UTC)

Re "make people request unarchiving if they want to make a new article": Not if they want to start a new article from scratch. But if they want to base their new article on the old one? We need some method of keeping the history in one place. Yes, a histmerge after the fact is possible, but a hassle. If we want to allow unilateral unarchiving by non-admins, one option would be an edit filter allowing moves but not edits to "soft" archived pages. (I already tried the title blacklist but couldn't get that to work.) Suffusion of Yellow (talk) 00:14, 7 September 2023 (UTC)

• Another disadvantage is that it will make it easier to delete articles without prior discussion or consensus. Given the near-continuous disagreements about draftification (which, as others have noted, is basically a kludged version of this) since it was introduced, I think that could be a significant disadvantage. – Joe (talk) 07:48, 5 September 2023 (UTC)

  I think "archiving" (what I'm going to call this; as noted below "soft deletion" means something else) should be technically restricted to admins, and restricted by policy to pages that could have been deleted under the old system. The idea is that one should not have to go through RFA to read the history of a page unless it is somehow potentially "harmful": e.g. copvios, BLPs, maybe spam. You don't need to be an admin to see content that was removed from a live page, unless it was revdel-worthy. Suffusion of Yellow (talk) 20:39, 5 September 2023 (UTC)

  I'm not opposed to widening access to deleted histories, but FTR it's not the case now that you need to be an admin to see them. You just need to ask an admin, e.g. at WP:REFUND. – Joe (talk) 10:14, 6 September 2023 (UTC)

• Comment (1) the terms hard deletion and soft deletion are already in use at AfD debates, so it would be helpful to explain the differences and clarify the terminologies so we don't end up with confusion and ambiguity.
• Comment (2) I'm grateful someone's looking at the underlying problem of mass-produced articles. The next-level-up problem is "bulk discussions". Wikipedia is very biased towards individual debates about individual articles. As a result, we get a stream of nearly identical AfDs on some topics (e.g. footballers who've appeared in only one match). It's very difficult for an inexperienced editor to know where to find the global debates which decided how these individual debates shoudl be handled. It would be far more efficient to have a global debate, and then carry out the result globally. But the global debates are scattered across project pages, requests-for-comment, archived talk-pages and all over the place. Unless you were involved, you'll never know. A lot of them fizzled out with low participation, leaving us for ever unsure what constitutes a notable rail-accident or bus-stop, and every time an individual bus-stop appears at AfD, we have to go through the whole thing again. Isn't there some way we can (1) draw attention to the bulk debates and make decisions on whole categories at once, with sufficiently broad input that the decision is safe, and (2) form working-parties who just do the job, instead of relying on the articles to trickle through AfD, and hope that at AfD there are sufficient people who know what the decision was to ensure someone tells Liz which way to close it. In effect, this suggestion is a step in the right direction, but we need a whole mechanism for bulk-handling, starting with robust, safe decision-making. AfD isn't ideal for bulk decisions.
• Comment (3) maybe bulk draftification would be safer if there were an option to draftify without the 6-month-delete rule. Elemimele (talk) 12:38, 5 September 2023 (UTC)

  Re comment(1): There is some overlap between this proposal and the existing term "soft deletion", though they do differ in some ways. We should clarify whether we are revising the existing term or creating a new one, to exist in parallel, which should have a different name. Certes (talk) 12:53, 5 September 2023 (UTC)

  The latter, I think. Edward-Woodrow :) _[talk] 20:03, 5 September 2023 (UTC)

  Re (1), I'm going with "archiving" unless someone comes up with a better name. Suffusion of Yellow (talk) 20:40, 5 September 2023 (UTC)

  If the 6-month-deletion-rule is dropped, then articles in draft space should be subject to being prodded or taken to AfD 6 months after creation/draftification. Donald Albury 23:59, 5 September 2023 (UTC)

  Why? Edward-Woodrow :) _[talk] 00:21, 6 September 2023 (UTC)

  If drafts are going to be allowed to stay indefinitely, then they should be subject to the same review processes as articles. Alright, set it to six months after the last substantive edit. If the draft has potential, it can be kept. If it doesn't have potential, why not delete it? Donald Albury 01:55, 6 September 2023 (UTC)

  If drafts are going to be allowed to stay indefinitely, then they should be subject to the same review processes as articles. Why? Drafts aren't visible in search engines (either on Wikipedia or on Google). That means they aren't part of the encyclopedia, just like user pages aren't. If I can have a personal sandbox or subpage that lives on indefinitely, what is the difference between that and a draft? Steven Walling • talk 05:41, 6 September 2023 (UTC)

• I think this proposed solution to the problem "legacy issue of mass-created articles" is quite broad and may not address how some editors feel about the sport stubs. In practice, any good faith editor can ask an administrator to restore an article for review or expansion, and frequently that request is granted. The exception if the article was salted. Second, I think many editors have concerns with any mass action of articles, so a softer form of deletion may not address those concerns. --Enos733 (talk) 04:26, 6 September 2023 (UTC)

This is an interesting proposal. I've thought for a while now that "notability is not temporary", while important in some respects, is problematic in others. You see this repeatedly around current-events articles, where NTEMP means people obsess the moment an article goes up about duking out whether this will be Massively Important Forever or not, because the idea of "Wikipedia is a living document, and whether a standalone article is the best way to cover something can change over time" just refuses to sit in some peoples' minds. Similarly, it results in people overcorrecting to a very high notability standard with a high false negative rate in an attempt to avoid the prevalent "BLP no one can update" problem, because no one is willing to say "well, maybe a standalone article isn't the best way to cover this anymore if someone has had no coverage in the last 20 years and seemingly never will again". People don't internalize NOTPAPER and the idea that "is a dedicated article the best way to handle this?" can change over the course of decades, in both directions, frequently both at different times for the same subject. (In the very long run, just about anything we know today could have a dedicated article, in the same way notability standards are tacitly much lower a century back or further.)

Mass creation is another paradox. While mass creation (here narrowly-defined 'bot-stub' types, to avoid the definition cagematches of WP:ACAS) purports to improve Wikipedia's coverage, it actually worsens it. Because of the commons-burning issue of huge numbers of uninformative articles clogging Special:Random and search engine results, people try to construct notability guidelines in an "if literally everything that this describes had a standalone article suddenly appear for it tomorrow, what would happen" way. This is atrocious logic, the very peak of the ways Wikipedia-at-its-worst falls into both "everything not mandatory is forbidden" and "hard cases make bad law". The resulting standards keep not solving the underlying problem of uninformative articles while preventing the creation or expansion of well-developed, inclusion-worthy articles that fall below a technicality. (Similar sub-problem of "everything not mandatory is forbidden": a lot of people seem to understand "notability" as demarcating the line where something must have an article rather than where it can. This has come up a bit at the NJOURNALS affair, where many people seem not to understand that the choice is between "editorial discretion of articles or lists" or "mandatory lists". The ATA-thumping subset at AfD contributes to this, where a misunderstanding is perpetuated that notability is the only inclusion or exclusion barometer that exists, and no other form of editorial judgement matters.)

Substituting 'archival' for 'deletion' in many cases might help handle this. If we actively move away from an understanding of standalone article inclusion based on "it Existentially Matters whether This Subject can ever appear on Wikipedia!" to "does this way of presenting information serve readers best right now or does some other way?", that could strike significantly at all three issues -- but there's a lot more that would have to be set up for it. I'm currently in the early stages of some research on reader views and understandings of articles and how they match/contradict editor views, which is really understudied throughout the project history. Any serious embarkment on "how do we fix all of this?" needs more data than we have. It also needs to consider things like "people who have articles are people, and we've accidentally hijacked the narrative of who they are forever, and they tend to have strong opinions on this and on things like whether their article exists or not". But...we probably need to stop making bad law. Vaticidalprophet 05:09, 6 September 2023 (UTC)

Yes! To take your final paragraph on a bit of a tangent, regarding If we actively move away from an understanding of standalone article inclusion based on "it Existentially Matters whether This Subject can ever appear on Wikipedia!" to "does this way of presenting information serve readers best right now or does some other way?" This parallels another thought I've been having. Between AfD "delete" and "merge" outcomes there's a gulf we need to fill. I have some raw thoughts in a draft essay about how NORG (a very necessary notability guideline) fails us from time to time User:Siroxo/How to fix NORG AFDs, and how merges aren't working as well as they need to, right now. —siroχo 05:47, 6 September 2023 (UTC)

Your Hush Records and ImpactGenius examples are interesting to me, because 'sources and sourcemakers' are the big thing I think GNG doesn't work for and the place I'm most interested in carving out exceptions to it. (This is as opposed to, say, "GNG works here as well as it does for most things but people want to apply a higher standard", like our major overcorrections around fiction and the ridiculous "but if the sources have the wrong name..." clause of NSONGS.) Record labels with many notable acts are worth having some centralized place for, because readers interested in reading about a specific band are plausibly going to want to know more about how they ended up at a label and how typical they are of its acts; it occurs to me that many editors who would object to "X Records" would not object to a functionally identical "List of bands signed by X Records". (See also: gaming studios with many notable games, film production companies with many notable films, etc.) Things that are themselves sources have the additional factor of "contextualizing Wikipedia content itself", which has been a pretty widespread discussion topic lately, but also serve a function of contextualizing anywhere they may appear and not just mentions in WP articles. Narrowly notability-focused understandings of inclusion and exclusion don't handle these cases well, IMO. Vaticidalprophet 06:43, 6 September 2023 (UTC)

Yeah Vaticidalprophet is on the right tangent. Anything that helps us fight out from under the Tyranny of the Article will go a long way towards allowing us more flexibility in presenting information in more apt ways, rather than the current false dichotomy of standalone article on the one hand and list article (functionally, tabular data) on the other.

I remarked something similar but less insightful at WP:LUGSTUBS2. Meanwhile Infrastructure of the Brill Tramway abides in a middle ground. A deep restructuring of how we deal with borderline notable topics is of course its own journey, but if we've been struggling with the same problems for a decade or more it doesn't seem likely we'll solve them with current methods. Folly Mox (talk) 06:48, 6 September 2023 (UTC)

I agree with the sentiment that there is a class of borderline articles which aren't fit for mainspace but aren't sufficiently bad to warrant removing from public access through hard deletion. There are uncontroversial and verifiable subjects which are not notable, and yet the page history holds some value. For these borderline articles, hard deletion is not in keeping with the open spirit of a wiki. In particular, deleted articles take their talk pages with them - for longstanding articles, these often contain much good-faith and insightful community discussion.

I also agree with other editors who have highlighted the similarity between this proposal and Draftspace. All the proposed advantages are met or nearly met by the use of draftification, so I wonder if it would be helpful to discuss improving use of Draftspace to better meet these goals, rather than pursuing a software change. I think Steve Walling is correct that G13 is the main barrier.

At the moment, Draftspace is purgatory - a temporary stay of execution for failed articles, awaiting their final destination via G13. Repealing G13 and expanding our use of draftification could renew the purpose of Draftspace. Barnards.tar.gz (talk) 11:43, 6 September 2023 (UTC)

Amongst other things, this would require accepting that "draftspace as a way to create articles" is a failed experiment. Meanwhile, enough of the community thinks we should be expanding the degree to which potential articles are forced through draftspace that "what if we just stopped telling people to make articles, at all?" was a proposal that happened and had supporters. It would also (contra the "archival sounds great because then I could unilaterally delete articles that, mysteriously, other people don't agree should be deleted" subset of interpretations of this proposal) mean draftification has to be bundled into adminship, which...I mean, I don't think I'd oppose that, even for draftification as it exists right now, but it'd have some complex consequences. Vaticidalprophet 12:57, 6 September 2023 (UTC)

Was draftspace ever intended to be "a way to create articles"? It functions well in its role as a spam filter; the big problem seems to be excessive bycatch. Folly Mox (talk) 16:32, 6 September 2023 (UTC)

The draft space was created because the other option, which was that articles were deleted, was deemed to WP:BITEy for new users, so AFC and the Draft Space was created to give newbies time to incubate their articles and grow them till they were ready for the main space. Whether this is a) what the process was ever used for or b) could have ever actually been useful in solving the problem is debatable. But that was the purpose. --Jayron32 17:58, 6 September 2023 (UTC)

Yep at the time, brand new accounts could still create articles, but newcomers were being told to use AFC, which was driven using an even uglier set of templates and subpages than the system today. So the thought was that it would be friendlier than AFC or just creating your article directly and then getting nuked by CSD, with no option to keep working on your article text. So the hope was that it could serve both as incubator and a form of soft delete. Steven Walling • talk 19:27, 6 September 2023 (UTC)

I think archiving should work in tandem with draftspace. Here's my view:

• Articles in the "Archive" namespace can only be edited by administrators, by default.
• Draft articles can be edited by anyone unless explicity protected.
• "Archived" articles are articles deleted via PROD or AfD or other consensus that do not have legal or moral issues: "archived" articles should not contain copyvios, libel, harassment, etc. Such articles should be hard deleted.
• Draft articles can be improved by anyone, at anytime. They are a space to work and improve articles. Draftification is an extention of this, it is saying: "your article needs some more work. Let's keep it here where you can safely work on it before moving it back to mainspace". Draftification is not comparable to deletion.
• "Archived" articles are deleted. They can be used as a resource to re-create the article, or for other means with the overall goal of transparency. They are not a working space; they are a public archive of articles rejected by the community, like a garbage bin that anyone can rummage in.

Edward-Woodrow :) _[talk] 19:51, 6 September 2023 (UTC)

User:Edward-Woodrow/archived. Edward-Woodrow :) _[talk] 20:07, 6 September 2023 (UTC)

Basically what you're proposing is to let anyone view deleted article text in some cases. This is something we could do without introducing a different word for it like archived vs. deleted. It would be relatively straightforward to change the permissions such that non-admins could view deleted article revisions unless it was deleted for copyvio or another reason. Steven Walling • talk 20:21, 6 September 2023 (UTC)

It is? Seems like a big technical challenge to me. What approach do you have in mind on the technical side? –Novem Linguae (talk) 20:26, 6 September 2023 (UTC)

Yeah. The only piece of information we have as to whether a deletion was done for copyright infringement is the deletion log. Making currently-deleted revisions world-visible unless their deletion log says they were deleted for copyright infringement is a really bad idea for at least three reasons I can think of off the top of my head:

• Reliably detecting "copyvio" and all its variants and all their misspellings, without allowing any false negatives, is technically nightmarish. All of these are copyvio deletions (though this very similar comment isn't). And those are just what I turned up in five minutes of searching for obvious likely false negatives.
• There's lots of other things that shouldn't be made visible besides copyright infringement. All of their variants and misspellings would have to be detected too. Worse, admins are encouraged to delete material with deliberately innocuous log comments when deleting material prior to oversight (explicitly so for revision deletion, though also a common if undocumented practice for normal deletion), and are encouraged to send stuff along to oversight even if they think it's borderline. Borderline material by definition is going to include pages that don't end up being oversighted (overseen?), but that doesn't mean it's ok for everyone to see; and nobody's going to then undelete the page and redelete it saying "A7: self-identification, birthdate, email address, and street address of someone a year too old to be considered a minor".
• If nobody happens to notice copyright infringement or defamation in a draft before it hits the six-months-unedited mark, the administrators pushing the G13 button hardly ever look for it either. That check gets done at WP:REFUND if and when someone asks for it to be restored. We also used to find a lot of copyright infringement at WP:DRV, after a page had already been deleted for other reasons and was only then getting inspected by a bunch more admin eyes. (I think the main reason that happens less these days is because newer users get pointed at draft and AFC instead.) While "we might accidentally make copyright infringement nobody's ever noticed visible" isn't a particularly good argument, my point is that the deletion log usually isn't explicitly amended in such cases - the pages aren't restored and then redeleted with a "copyvio" log, they're just left saying G13 or WP:AFD/Articlename or whatever.

—Cryptic 22:48, 6 September 2023 (UTC)

Hold on. I thought the consensus was that currently "hard-deleted" articles would not be converted to soft-deleted (archived) pages. Edward-Woodrow :) _[talk] 23:22, 6 September 2023 (UTC)

Oops, I meant to reply to Cryptic. Edward-Woodrow :) _[talk] 23:22, 6 September 2023 (UTC)

The draft space was created because the other option, which was that articles were deleted, was deemed to WP:BITEy for new users – I think you're rewriting history a bit there. Draftspace was intended for new articles, replacing the former practice of storing them as subpages of WP:AFC. As far as I can tell (and I've spent quite a bit of time digging into the history of this), the possibility of using it as an alternative to deletion was barely even discussed, presumably because this was explicitly disallowed by both of its predecessor processes (AfC and WP:INCUBATOR). The practice of moving new pages to draft began a couple of years after draftspace was created, without explicit consensus that it was allowed. – Joe (talk) 06:42, 7 September 2023 (UTC)

As a further note to Jayron32's response: this discussion led to the creation of the draft namespace. The intent was to have a central place for new article drafts, rather than having them as subpages of various pages in the Wikipedia and Wikipedia talk namespaces, as was being done by various tools. isaacl (talk) 18:37, 6 September 2023 (UTC)

Note: Prior to the creation of the Draft namespace, we had “Userfication”. If an article was deemed too problematic for Mainspace - but potentially fixable - an editor would volunteer to “adopt” it and have it moved to a subpage in his/her Userspace. That editor would attempt to fix the problems (sometimes on his/her own, sometimes in collaboration with others), and then return it to Mainspace when they felt it was up to snuff.

That system worked… in part because the “adopter” felt that they had a stake in improving the “draft” that was sitting in “their” Userspace. The down side was that it implied a degree of “ownership”. Blueboar (talk) 19:29, 6 September 2023 (UTC)

I think userfication also worked because there was no deadline. In that discussion, it was sadly prescient when, in response to my idea that draftification would be a good alternative to deletion, Sven Manguard said That will work until the moment that rules are put into place regarding how long a draft can go unedited before it gets speedy deleted. This is why I think instead of introducing a new "soft delete" or archived idea, we just get rid of the rule that all drafts older than six months get nuked. Steven Walling • talk 20:24, 6 September 2023 (UTC)

We still can move articles to a user's space if one volunteers to be responsible for it. It can be an issue, though, when the volunteer's ambitions are too large for their available time. Although the number of editors trawling through draft space is small (although I imagine there are others, I can only think of one, who stopped doing it after a while, and now is deceased), I imagine no one is going through user space drafts unless there's a pointer to a specific page/set of pages from some improvement initiative page. isaacl (talk) 21:29, 6 September 2023 (UTC)

The big difference is that userfication wasn't (and still isn't) allowed without prior consensus at AfD or similar; see WP:USERFY#NO. When draftspace was created, that expectation wasn't inherited by the new namespace, leading to the "long PROD" situation we have today. – Joe (talk) 06:45, 7 September 2023 (UTC)

So if I create an article about a garage band, and you believe that it should not be in the mainspace, then you're allowed to boldly move it to draftspace without saying a word to me or anyone else, but you're not allowed to move it to my userspace, even at my request, without first sending it through AFD or another deletion process? That is not really sensible. WhatamIdoing (talk) 02:40, 10 September 2023 (UTC)

• This idea seems like it would involve a lot of workflow complexity and technical complexity for little payoff. What problem is it trying to solve again? I guess it's trying to make it easier for editors to get WP:REFUNDs? –Novem Linguae (talk) 20:31, 6 September 2023 (UTC)

  The "problem being solved" is that deletion is a blunt instrument. The same tool is being used for the most vile attack pages as for pages like Google Chrome version history. That doesn't make sense; it's just historical inertial. A question:

  1. Article Foo has a section called "Foo in popular culture". One day, by consensus, the whole section is removed as cruft.
  2. Article Bar does not have such a section. Instead, it's on a separate page called Bar in popular culture. One day, by consensus, the whole article is deleted as cruft.

  Can you argue, from first principles, why people who haven't gone through RFA should, without asking an admin for help, be able to view the full history of (1) but not (2)? Why, in short, should information that would have been blanked or reverted but never in a million years revdelled, require special privileges to view, because it happens to have been published on a separate page? Suffusion of Yellow (talk) 23:49, 6 September 2023 (UTC)

  Sure: If the consensus at AFD was to delete, rather than a quick blank-and-redirect outcome, then they presumably had some reason for that. WhatamIdoing (talk) 02:36, 10 September 2023 (UTC)

  Sometimes the reason is that there's no valid redirect target, no? So there could hypothetically arise a situation where a 'redirectable' article can end in a BLAR, preserving page history, but a 'nonredirectable' article of otherwise equal quality can only practically end in a delete. Why shouldn't WP:BLAR and WP:BLANK (or, perhaps more realistically, adding some sort of 'this is a deleted page' warning tag to the article as suggested above) be equally accepted outcomes? Shells-shells (talk) 02:21, 11 September 2023 (UTC)

  That would not be relevant for the examples given, however, which specified that we were deleting Bar in popular culture, which is related to the existing article Bar. WhatamIdoing (talk) 03:10, 14 September 2023 (UTC)

  And if Bar has no "in popular culture" section, and consensus is against including one? Anyway, I just used pop culture as an example of the sort of page that's unlikely to contain subtle libel. It's hardly the only example. And saying "that's what the consensus was" when there has never been an option to do this sort of thing, is kind of like saying "Given a choice between kale ice cream, and tuna ice cream, 95% of people pick kale, so obviously consensus is against chocolate". Suffusion of Yellow (talk) 21:01, 15 September 2023 (UTC)

  For fiction and popular culture? Most of the time, it's "the three people who show up to all those AfDs specifically showed up there, and all voted delete". ATD-R outcomes usually only happen when people specifically mention them, not by default, and that topic area specifically has a strong concentration of both "unanimous deletes that should've been redirects or merges" and "unanimous deletes that probably should've been keeps". Vaticidalprophet 13:59, 11 September 2023 (UTC)

Draft proposal to implement archival

Reviewing this discussion, I'm seeing broad support for some sort of "soft deletion" process; in particular, I'm seeing a preference for moving soft-deleted articles to an archival space; I believe that rather than creating a new space for this it would be better to use draft space. In line with this, I've crafted a proposal for how this would be done; if editors prefer the creation of a new "archival space" the proposal can easily be repurposed for that, and similarly if editors prefer a technical solution similar to either what I originally proposed or was proposed at Wikipedia:Pure wiki deletion system it can be repurposed for that.

In line with Suffusion of Yellow's proposal, I will be using "Archiving" in place of "Soft deletion", to avoid confusion with the existing use of that term.

---

Currently, any article that is deemed to cover a non-notable topic is deleted, unless a suitable redirect target can be found. For such articles should we instead implement a process to archive them, and limit deletion to articles containing content that would be subject to revision deletion, that violate What Wikipedia is not, or that cover living people?

---

If successful, this proposal would repurpose draft space to also be used for archival, and would involve the following changes:

In Wikipedia:Criteria for speedy deletion, G13 Abandoned drafts and Articles for creation submissions is renamed Abandoned BLP drafts and Articles for creation submissions, and This applies to any pages that have not been edited by a human in six months found in: is changed to This applies to any pages covering a living person that have not been edited by a human in six months found in:

In Deletion policy, Proposed deletion is renamed Proposed archival, and the content changed from:

An editor who believes a page obviously and uncontroversially does not belong in an encyclopedia can propose its deletion. Such a page can be deleted by any administrator if, after seven days, no one objects to the proposed deletion. Once there is an objection or a deletion discussion, a page may not be proposed for deletion again. This process only applies to pages in the main namespace (article namespace) and the file namespace. Redirects are not eligible for proposed deletion (for information on deleting redirects, see Wikipedia:Redirect § When should we delete a redirect?).

To:

An editor who believes a page obviously and uncontroversially does not belong in an encyclopedia can propose its archival. Such a page can be archived by any editor if, after seven days, no one objects to the proposed archival. Once there is an objection or a archival discussion, a page may not be proposed for deletion again. This process only applies to pages in the main namespace (article namespace) and the file namespace. Redirects are not eligible for proposed archival (for information on deleting redirects, see Wikipedia:Redirect § When should we delete a redirect?).

In Deletion policy#Processes a new section is added, Restoration from archive. This will read:

Articles that were archived by consensus should only be restored when the reasons the page was deemed unsuitable for mainspace have been addressed. Restoration of pages without addressing those concerns may be reverted by any editor.

In Deletion policy#Alternatives to deletion a new section is added at the top, Archival. This will read:

Articles that are deemed not to meet our standards for notability should be archived; this allows for editors to more readily recreate the article if sources are identified or if the topic becomes notable in the future.

This can be done either through an expired prod, or through consensus either at AfD or another sufficiently prominent location. Archived articles are generally not deleted, but in rare circumstances if the existence of the archive is disruptive they may be deleted through a consensus at MfD.

In Deletion policy, WP:ATD-I is changed from:

Recently created articles that have potential, but that do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement, with the aim of eventually moving them back to the main namespace, optionally via the articles for creation (AfC) process. If drafts are not edited for a period of six months, they are eligible for deletion under criteria for speedy deletion G13. In comparison to user space drafts, the draft namespace makes these proto-articles easier to find and work on collaboratively. Moving to user space is still preferred for templates that seem to serve a single editor's needs, or essays that only reflect a particular editor's viewpoint. Drafts in user space are not subject to G13 deletion unless submitted to AfC.

Incubation must not be used as a "backdoor to deletion". Because abandoned drafts are deleted after six months, moving articles to draft space should generally be done only for newly created articles (typically as part of new page review) or as the result of a deletion discussion. Older articles—as a rule of thumb those older than 90 days—should not be draftified without prior consensus at AfD.

To:

Recently created articles - as a rule of thumb, those younger than 90 days - that have potential but do not yet meet Wikipedia's quality standards, may be moved to the draft namespace ("draftified") for improvement, with the aim of eventually moving them back to the main namespace, optionally via the articles for creation (AfC) process. In comparison to user space drafts, the draft namespace makes these proto-articles easier to find and work on collaboratively. Moving to user space is still preferred for templates that seem to serve a single editor's needs, or essays that only reflect a particular editor's viewpoint.

Articles moved to draft space for the purpose of incubation are not considered archived and may be returned to mainspace at any time.

In Deletion policy#Processes, the section Deletion of drafts is removed:

If an article isn't ready for the main namespace, it can be moved to the draft namespace, and if it sits there without being worked on for six months, it will be eligible for speedy deletion. See Wikipedia:Drafts#Deletion of old drafts.

Deletion policy#Deletion discussion is changed from:

Pages that do not fall in the above three categories may be deleted after community discussion at one of the deletion discussions, the results of which may be reviewed after the fact at Wikipedia:Deletion review (see below). This includes contested speedy or proposed deletions. Here, editors who wish to participate can give their opinions on what should be done with the page.

These processes are not decided through a head count, so participants are each encouraged to explain their opinion and refer to policy. The discussion lasts at least seven full days; afterwards, pages are deleted by an administrator if there is consensus to do so. A nomination that gets little response after the discussion period has ended can be relisted if the closing editor believes that more time would be likely to generate a clearer consensus.

To

Pages that do not fall in the above three categories may be deleted or archived after community discussion at one of the deletion discussions, the results of which may be reviewed after the fact at Wikipedia:Deletion review (see below). This includes contested speedy deletions or proposed archivals. Here, editors who wish to participate can give their opinions on what should be done with the page.

These processes are not decided through a head count, so participants are each encouraged to explain their opinion and refer to policy. The discussion lasts at least seven full days; afterwards, pages are deleted by an administrator or archived by an experienced editor if there is consensus to do so. A nomination that gets little response after the discussion period has ended can be relisted if the closing editor believes that more time would be likely to generate a clearer consensus.

Deletion policy#Deletion review is changed from:

If you believe a page was wrongly deleted, or should have been deleted but wasn't, or a deletion discussion was improperly closed, you should discuss this with the person who performed the deletion, or closed the debate, on their talk page. If this fails to resolve the issue, you may be able to request review of the closure at Wikipedia:Deletion review.

To:

If you believe a deletion discussion was improperly closed you should discuss this with the person who closed the debate on their talk page. If this fails to resolve the issue, you may be able to request review of the closure at Wikipedia:Deletion review.

---

This proposal is very early stage, and likely misses some policies and guidelines that will need modification to accommodate the change.

I limited the scope of this change to be for articles deleted for notability reasons, in order to continue supporting the deletion of articles for reasons such as violating WP:NOTWEBHOST, though further discussion of this may be beneficial; I understand there are some not violations that we may be less concerned with the content being archived, such as violations of WP:NOTDIRECTORY, but I'm not certain we can find a balance between the two.

I also limited the scope to only apply to non-BLP's; given the sensitivity around BLP's and the lack of visibility of draft space I think it is best that such articles continue being deleted; again, further discussion may be beneficial.

I've also included a line permitting the deletion of archived articles at AfD, in circumstances where the existence of the archive becomes disruptive; I think this is necessary to ensure we can protect the encyclopedia, but I imagine use of it would be rare.

It also implicitly expands the number of editors who can close deletion discussions; we may want to explicitly restrict this to administrators? BilledMammal (talk) 03:11, 14 September 2023 (UTC)

I think it's a good start. Some thoughts...

1) Articles that are deemed not to meet our standards for notability should be archived. I wouldn't go so far as to say that such articles should be archived. I think we should just offer archiving as an option that may be arrived at by consensus at an AfD discussion, and we should probably recommend that the option is only used for borderline cases where some potential is identified. I think there will still be plenty of non-BLP articles that are unambiguously non-notable and have no potential.

2) Such a page can be archived by any editor. I believe AfD outcomes are nearly always implemented by administrators and I think if we view archival as a type of AfD outcome, that should continue.

3) The proposal leans on the idea of potential. There is the essay WP:POTENTIAL, but it is currently just an essay. I wonder if a precursor to this proposal might be to put in some work to uplift that essay to a guideline. I can imagine many AfD discussions hinging on what exactly "potential" means.

4) I'm not sold on the term "archival", when it seems here to mean the same thing as draftification (which is itself a comical wikiologism, but at least one which has a clear meaning). In other fields, "archival" has connotations of immutability and long-term preservation, but I don't think we are proposing that. Barnards.tar.gz (talk) 08:18, 14 September 2023 (UTC)

I also think this is a good start, although I expect tweaks will be necessary as discussion clarifies issues, such as those raised by Barnards.tar.gz above. I certainly want to mull this over for a while. Donald Albury 14:28, 14 September 2023 (UTC)

I'm not sure this is quite the thing either Suffusion or I are enthused about, and perhaps rather closer to being the thing we're anti-enthused about. I definitely don't think this should be conflated with draftification, which is either a failed experiment (that we should just shunt out completely) or genuinely a way to create articles (in which case we need to figure out something more complex, separately, to make it actually a way to create articles); the odd half-confession that it's a failed experiment while still broad-grins directing newbies to it is ethically questionable. I remain very unconvinced it would be a good idea to make archival an unbundled ability. I'm more thinking of it as a replacement for most forms of deletion, the way Suff is. Having said that, I like the specific element of replacing prodding with...PA-ing?, which is an obvious step. Vaticidalprophet 17:08, 15 September 2023 (UTC)

A further thought: perhaps a good way of proving the value of this proposal would be to review historical AfDs and WP:REFUND a sample of articles that we believe would have been archived under this new standard. Barnards.tar.gz (talk) 17:36, 15 September 2023 (UTC)

This is not really what I had in mind. "Archiving" would be something clearly different from draftification; to Barndard's point, it really would mean "immutability and long-term preservation". If you want to modify an archived page, either un-archive it ("soft archiving") or get consensus to do so ("hard archiving"). It would be a place to store pages with very low (or even zero) potential, but that don't cause any harm by being publicly visible, just like low-quality but not harmful page revisions are kept publicly visible. Think unused templates. Non-notable fictional characters or long-deceased people or landforms.

This looks more like a proposal to exclude some drafts from G13. That's confusing, and there is great potential for attack pages, copyvios, minor's autobiographies, etc., that should have been deleted to slip by. Suffusion of Yellow (talk) 20:52, 15 September 2023 (UTC)

In fact, it just took me one literal minute to find a blatant attack draft, complete with a photograph of a minor, that had been lurking in draftspace since April. G13 means in would have been deleted in a month or so anyway. Yes, it's technically a BLP, but a bot doesn't know that, so it would not have been tagged until it was reviewed by a human. We really need to keep automatic G13 deletions around for the unreviewed crud. Suffusion of Yellow (talk) 21:19, 15 September 2023 (UTC)

Indeed. After about two minutes of searching I found two attack pages, one promotional page, and one hoax about a person that, based on my searches, doesn't exist. Edward-Woodrow :) _[talk] 21:30, 15 September 2023 (UTC)

• I'd prefer to see page-blanking as described in phab:T5843 serve this arhchival task, rather than 'defining a new concept of archiving and adding a new namespace for it'. Upgrading blanking is easy to implement and less confusing, involving no new tools and relying on the existing history tab. It also allows for the logical combination of archiving and drafts (a blanked draft), which as Steven pointed out should be a more common end state than deleted drafts. – SJ + 16:28, 21 September 2023 (UTC)
• I'm struggling to see what problem this is designed to solve. Stifle (talk) 10:19, 3 October 2023 (UTC)

References

Enwiki-WMF Relationship discussions

For the past month a number of us have been discussing holding a number of discussions on the relationship between the Wikimedia Foundation and the English Wikipedia; these discussions can be found here.

The formal discussions that we are planning to hold are:

1. An RfC at either WP:VPW or WP:VPR, proposing non-binding resolutions that would express the opinion of the English Wikipedia on a number of topics to the Wikimedia Foundation. The draft for this discussion, including the proposed resolutions, can be found here here. The purpose of this discussion will be to inform the WMF of areas that concern us in the hope that they will be willing to consider adjusting their behavior in those areas; given that policy is mostly silent on these questions, to encourage participation the RfC is structured closer to a vote, with separated support and oppose sections, than to our normal RfC structure.
2. An RfC at WP:VPP proposing reducing the privileges accorded to the Wikimedia Foundation under WP:CONEXCEPT, to try to encourage the WMF to see us as a partner and stakeholder rather than a subordinate, and to reflect reality in that the WMF cannot use this power without extreme controversy. The draft RfC for the proposed change can be found here.
3. A discussion at WP:AN, proposing applying general sanctions to WP:VPW in order to address concerns that the WMF has with the level of incivility that is sometimes directed at their employees and encourage them to communicate with us more frequently. The proposed text can be found here.

Before opening these formal discussions I am opening an informal discussion here to discuss the proposed texts and resolutions.

In particular, I am interested in hearing:

1. Whether the text of the proposed resolutions are appropriate; whether some can be merged to reduce the number that need to be considered
2. Whether some of the proposed resolutions should be removed entirely
3. Whether there are other topics that should be addressed in the proposed resolutions that are not, keeping in mind that we don't want to create too many resolutions'
4. Whether it would be better to hold the discussion on the proposed resolution at WP:VPW or WP:VPR
5. Whether the proposed new wording for CONEXCEPT is functional
6. Whether the proposed sanctions wording is functional
7. Whether general sanctions are needed; if we can instead implement just the wording proposed to be added to the top of WP:VPW
8. Any other thoughts that editors may have

BilledMammal (talk) 02:36, 19 September 2023 (UTC)

Initial note, having not yet clicked through to any of the discussions:

Regarding discussion 3, WMF staff typically make announcements at VPM, which I feel like is a matter of their policy, although I have not been able to track it down.

Whenever these conversations are kicked off, consider dropping links at meta:Wikimedia Forum, since good communication runs both ways.

Mild request to host discussion 1 on a dedicated subpage. Seems like it will be a big 'un, and these poor pumps already groan under load. Folly Mox (talk) 05:07, 19 September 2023 (UTC)

The VPM thing is something I had an idea about resolving through a bot—see Wikipedia:Bot_requests#Forward_VPM_MassMessages_to_a_new_MassMessage_list. Best, KevinL (aka L235 · t · c) 18:00, 20 September 2023 (UTC)

That would help; my thought has been to create cross-wiki pages, which would allow editors to interact with the same page without needing to go to a centralized forum. Unfortunately, it would require a radical redesign of Mediawiki, but if it was possible it would be a massive boon in terms of permitting Wikiprojects to work with each and with the WMF. BilledMammal (talk) 14:06, 30 September 2023 (UTC)

Given that VPW doesn't see as much activity, would you have an issue with it being held there or would you still think a subpage would be a better idea? BilledMammal (talk) 12:02, 21 September 2023 (UTC)

As this is only a discussion about potential further discussion, with links to earlier discussion about potential discussion; I think that we need more discussion. I propose an informal discussion about the discussions regarding potential future discussion. Where this discussion takes place should be decided through a formal discussion at a location yet to be determined (we should probably discuss it, though).^[Humour] Edward-Woodrow :) _[talk] 13:45, 19 September 2023 (UTC)

Wikipedia:Discussions for discussion would probably be the appropriate venue. Folly Mox (talk) 13:56, 19 September 2023 (UTC)

Thanks for your great work in a much-needed area. Sincerely, North8000 (talk) 03:08, 19 September 2023 (UTC)

Having now clicked through, I think that resolutions 1–3 are probably unworkable, although I'm only one pessimist. We can certainly request that the Foundation issue more complete financial statements, but have no means of holding them to it. As to getting community consensus for grants, that would be a nightmare likely resulting in no grants ever being issued, and I know the Foundation does have a committee about it that volunteers sit on, although I think I saw the link to that on a talk page in your (User:BilledMammal's) userspace, not meta:Grants:Programs/Wikimedia Community Fund/Committee review process and framework like I thought.

Resolution 4 is obvious, and would benefit other projects as well as en.wp, and I certainly hope it is adopted and followed. Since the broken Graphs extension is mentioned, I thought I might drop a link to mw:Extension talk:Graph/Plans#Update: 15 September.

Things two and three seem fine to go to RfC; no prediction regarding outcome. Folly Mox (talk) 16:29, 20 September 2023 (UTC)

I guess I'd characterise resolutions 1–3 as "presumptuous", like we're looking to control funding, salaries, etc. Seems like it would be nice (for us), but feels a little inappropriate to suggest. JMO, Folly Mox (talk) 16:55, 20 September 2023 (UTC)

I guess I also have a question (apologies for my fragmented thoughts— they're always like this): there's a redlink to Wikipedia:WikiProject WMF Relations. Is this still intended to be a thing / part of this conversation? Folly Mox (talk) 17:23, 20 September 2023 (UTC)

See User_talk:BilledMammal/2023_Wikimedia_RfC#Draft_Wikiproject. There's a lot of discussion/context on that page (though some of it pertains to earlier drafts). — Rhododendrites ^talk \\ 18:12, 20 September 2023 (UTC)

GS for VPW? Have there been many previous ANI discussions, blocks, ArbCom cases, ... indicating that this is indeed needed there? It seems like severe overkill, and reminds me too much of the use of such measures on Meta and Phabricator where they are mainly used to stifle criticism of the WMF and some of their more disastrous projects. I see no reason why that page should get more scrutiny and harsher treatment of infractions than other pages. "To address valid concerns held by the WMF at the incivility that is sometimes directed at its employees" needs examples of some relatively recent incidents at that page. Fram (talk) 17:13, 20 September 2023 (UTC)

• I agree with Fram that there hasn't been the kind of evidence that suggests GS would be useful that we normally have before implementing it. This also feels like us doing something to foundation employees rather than for foundation employees because as far as I know there has been no conversation with them about what would help us acheive our goals, just us trying to figure out what tools we have in our toolbox to try and get what we want based on our understanding of what their problems are. Frankly it reminds me of the ham fisted way certain WMF initiatives happen. Barkeep49 (talk) 20:27, 20 September 2023 (UTC)

  I agree that for a healthy, long-term collaboration, the community is better off working with the WMF on aligning upon common objectives. I know this is difficult to achieve, and many English Wikipedia editors are not interested in being involved on meta-wiki or serving on committees. It's the price that has to be paid, though, to really be involved in decision-making: we need to use our voices during planning to ensure the resulting projects meet our needs. isaacl (talk) 23:19, 20 September 2023 (UTC)

  Personally I think the general sanction idea won't achieve its goal for a different reason. While some WMFers may avoid contributing here for fear of incivility, I think more often they don't contributing here for reasons internal to the WMF. For example, I heard a while back that they had an internal CoC that includes things like that no one except the person assigned to "communications" on a project should communicate about it. And I know that they've had managers who'd stoop to workplace bullying and other such practices to silence or eliminate people who make them look bad. Anomie⚔ 11:36, 21 September 2023 (UTC)

  SSpalding from WMF Legal here. I don't want to butt in too much on lively debate, but I did want to give first hand experience as a staff member. I do honestly think that a meaningful percentage of WMF staff fear (emotionally) to contribute to conversations because of the concern of getting bullied or (unfairly) interrogated. I assume a lot more people from WMF would communicate directly in places like the WMF portion of the Village Pump felt like a "safer space." (I'm trying not to use culturally loaded vernacular but that's probably the best term for it).

  I like contributing and talking to everyone here and on meta because I have relatively think skin. I do think certain "general suspicion about the Foundation as a whole" infects any "specific conversations directly with staff on Wiki about specific projects".

  In any online community, it takes a big jump from going from lurker to contributor. If the water seems too cold or deep (unwelcoming in a general sense), then you are not going to jump then the ocean. If the water is warm and clear but you see sharks in the distance (a handful of specific actors in the community who are on welcoming) you probably also won't jump in the ocean. To take this analogy to its conclusion, most people don't get attacked by sharks. It's a total illusion that shark attacks are common (that it's always going to happen that a staff member will be bullied). But the fear keeps many people out of the ocean regardless.

  I can only speak for myself, but I can -- and do -- post across different Wikis without oversight from any manager. I imagine there are teams who, for coordination purposes, elect to have one speaker. But I also think that teams might elect to have one speaker because that speaker has particularly thick skin for debate.

  This isn't an argument for or against general sanctions or anything else that's being discussed here. But I did think it was useful data to add that fear of being involved in a hostile debate (and being censured about projects or initiatives that the staff member knows nothing about) is real. It is a meaningful issue that I see personally and it's important to me because I'd love to see a world where more staff members could feel comfortable contributing more often. I don't know how to achieve that world though. Thanks for listening! SSpalding (WMF) (talk) 23:39, 23 September 2023 (UTC)

  That sounds like something we can fix. Create a special safe space page, where anyone who doesn't behave in a certain way (details TBD, but make them strict) gets their message deleted and blocked from the page. Then publicize it among WMF employees with the suggestion that they can respond to any question with "Answer posted as [safe space page]". I think a back and forth discussion with everyone being forced to be overly polite would be much preferred to the current silence we get when we ask reasonable questions. --Guy Macon Alternate Account (talk) 02:05, 25 September 2023 (UTC)

  I actually like the idea of creating a safe space for WMF staff to interact without worry of editors holding them accountable for every financial decision and software design choice ever made by their employer, but I wonder if topic bans might be a better tool than pageblocks. A pageblock will cut off Wikipedia Library access, which is remedied by an email to WMF staff.... I guess this detail could be read as a feature rather than a bug (I would choose reversion over deletion for transgressive posts too), but the basic idea of a safe space for communication feels kind, which means something to me anyway. Folly Mox (talk) 04:29, 25 September 2023 (UTC)

  That was the intent behind this proposal, but unfortunately there seems to be a lack of support among the community - although I'm happy to revive it, or a variant on it. BilledMammal (talk) 04:51, 25 September 2023 (UTC)

  Maybe it just needs to be framed as a bespoke remedy instead of using GS. Seems like it should be stricter than GS, from what I understand of sanctions regimes. What looks to be desirable here is an environment that is not necessarily open to "robust debate", and embracing of a higher standard of interaction than just civility. It makes me wonder though if something like this is actually workable here (I do hope so) and if the solution for communication might just require en.wp eeitors to be more active on meta, which doesn't seem unfair. Folly Mox (talk) 18:56, 25 September 2023 (UTC)

  General sanctions is just the category of editing restrictions that apply to all editors, as opposed to an editor-specific restriction. (You might be thinking of community authorization for discretionary sanctions or arbitration committee-designated contentious topics.) isaacl (talk) 00:44, 26 September 2023 (UTC)

  Hi SSpalding (WMF), good to see you posting here. Appreciated.

  On the broader point, BilledMammal, note that there has also been a related discussion at Wikipedia_talk:Wikipedia_Signpost/2023-08-31/In_the_media (in case you were unaware of it).

  Regards, Andreas JN466 15:11, 30 September 2023 (UTC)

  I'll drop that one; there hasn't been much interest in it, and there are number of very valid objections. BilledMammal (talk) 12:01, 21 September 2023 (UTC)

  @BilledMammal: I'd argue this is the most important one, to help encourage ongoing conversations between enwiki and WMF, and hope you do continue pushing this one. @SSpalding (WMF)'s post above is really spot on. Thanks. Mike Peel (talk) 19:21, 24 September 2023 (UTC)

  Yes, I disagree with removing it from the proposal as well. Whether or not your intent was to remove it due to lack of interest, it does send a subtle message that we're not interested in facilitating any civil discussions with WMF. _{Duly signed,} ⛵ WaltClipper -(talk) 13:23, 25 September 2023 (UTC)

  My concern is that we will send the same message, except less subtly, if we do propose it but the community rejects it. I'm happy to put it back in if you disagree, or if you think it has a chance of passing. BilledMammal (talk) 13:36, 25 September 2023 (UTC)

• @Fram: Have there been many previous ANI discussions, blocks, ArbCom cases, ... indicating that this is indeed needed there? There haven't, but I don't consider that indicative; those only come when both of the parties engaged in the dispute decide to continue the dispute. If one just leaves then nothing happens - this is a problem in other hostile editing areas where one "side" is more persistent than the others. BilledMammal (talk) 04:51, 25 September 2023 (UTC)

  If one just leaves then nothing happens This pretty much assumes that every WMF employee "just leaves" and that none of them ever decide to stay and fight, ignore the hostile editors and keep talking to non-hostile editors, or go to ANI or Arbcom asking for help. That seems extremely unlikely and it seems far more probable that the theory is wrong and that if you provide a 100% safe space with zero hostility you will still get silence in response to reasonable questions. Still worth trying though; my guess could be wrong. --Guy Macon Alternate Account (talk) 09:10, 25 September 2023 (UTC)

  It's definitely possible that the WMF just doesn't have an interest in engaging with us. BilledMammal (talk) 09:14, 25 September 2023 (UTC)

  Yeah, what Guy describes as "extremely unlikely," seems extremely likely to me, and very common on Wikipedia. Levivich (talk) 13:37, 25 September 2023 (UTC)

  Really? You find everyone responding to hostility by leaving and nobody ignoring the hostile editor or reporting the hostility or being hostile right back to be common on Wikipedia? Or could it be that I was unclear in what I wrote and you think I said that leaving is uncommon instead of what I actually claimed which is that everyone leaving is uncommon? --Guy Macon Alternate Account (talk) 04:00, 26 September 2023 (UTC)

• The changes to CONEXCEPT are incompatible with the WMF's role as the owner of the site and the steward of the IP. --Guerillero ^{Parlez Moi} 18:50, 20 September 2023 (UTC)

  Perhaps what I need to clarify is that the rest of CONEXCEPT, including Some matters that may seem subject to the consensus of the community at the English-language Wikipedia (en.wikipedia.org) are in a separate domain. In particular, the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and volunteers, and the sister wikis, are largely separate entities. These independent, co-equal communities operate however they deem necessary or appropriate, such as adding, removing, or changing software features (see meta:Limits to configuration changes), or accepting or rejecting some contributions, even if their actions are not endorsed by editors here., will remain intact.

  If it crossed over into that I would agree, but I think it isn't unreasonable for us to have fuller control over the internal workings of our project, rather than allowing the WMF to dictate to us - I feel that will encourage them to see us as a partner rather than a subordinate. BilledMammal (talk) 12:04, 21 September 2023 (UTC)

  I've updated the wording of the CONEXCEPT proposal, to hopefully make the limits of the proposal clearer. BilledMammal (talk) 12:17, 21 September 2023 (UTC)

• I don't necessarily disagree with any of these resolutions on the merits, but it just seems that it'd be a tactical mistake to go down this road. For better or worse, the community only has a certain amount of political capital (for want of a better metaphor) when it comes to WMF issues, and pressing the Foundation on finances and particularly CONEXEMPT strikes me as a way to spend a lot of it in exchange for marginal results at best. The WMF is never going to cede its right to control the servers, and fighting that losing battle only means the relationship will be even more frayed the next time there's a non-hypothetical issue that really matters (e.g. FRAMGATE). And while the financial concerns are valid, they just don't rise to this level for me, especially since more diplomatic alternatives haven't been completely exhausted. I'm certainly not saying we should just step back and let the WMF do whatever it wants, but this approach will be interpreted as adversarial and should only be used as a last resort. You can catch more flies with honey than with vinegar. Extraordinary Writ (talk) 00:35, 21 September 2023 (UTC)

  Balsamic vinegar works even better than honey though. Folly Mox (talk) 02:16, 21 September 2023 (UTC)

  I feel the tactical mistake would be to remain reactive, only using our capital to respond to actions from the WMF, rather than using it to try and shape our relationship with them.

  With that said the intent of the non-binding resolutions is to be a diplomatic effort, to tell the WMF "This concerns our community, please consider changing it"; if the wording still feels too aggressive than we can and should rework it. BilledMammal (talk) 12:09, 21 September 2023 (UTC)

• The ideas behind resolutions 2 and 4 seem important. I don't think you need an RFC for these, but more a canonical place to a) list local priorities needing technical and funding support, and b) list new editing initiatives (funded or otherwise), their organizers, and the equivalent of the "emergency bot shutoff" for an initiative if something's going wrong... perhaps similar to the bot approvals discussions. Both would be useful on other wikis as well.

The inclusion of resolutions 1 and 3 makes the tone a bit unconstructive, and perhaps a tactical mistake. They read like hatrack complaints and draw on assumptions and tropes used to troll the Foundation. The bulk of WMF spending and prioritization is in the main budget, which has extensive + iterative public consultation that would benefit from more organized and specific input from the larger communities.

I'm not a fan of CONEXCEPT but this change doesn't address the problem of its awkward framing, and adds new problems. It is unlikely to get consensus support, leading to much heat without light.

It is noteworthy that your one proposal aiming to reduce friction and improve the quality of communication was quickly struck through without replacement. This is a natural consequence of how this is being framed and discussed; a similar consequence is that any raft of simultaneous resolutions and RFCs will feel adversarial and not taken as a diplomatic way of expressing concerns. – SJ + 02:10, 22 September 2023 (UTC)

I don't think you need an RFC for these, but more a canonical place to a) list local priorities needing technical and funding support, and b) list new editing initiatives (funded or otherwise), their organizers, and the equivalent of the "emergency bot shutoff" for an initiative if something's going wrong... perhaps similar to the bot approvals discussions.

The idea behind the RfC is to show that community consensus is behind the ideas and that it isn't just the position of a few vocal individuals; I think that is necessary if we want there to be any chance of the WMF acting on it.

The inclusion of resolutions 1 and 3 makes the tone a bit unconstructive, and perhaps a tactical mistake.

I think #3 is necessary; while it might "only" be a few million dollars each year, the WMF spending money on things unrelated to Wikimedia Projects is one of the biggest complaints among the community, and was the impetus for this discussion. #1, while I feel it is important, could in my opinion be dropped if editors believe it would be better to do so, although I note that in the preliminary discussion it was seen by some editors as the least controversial.

I'm not a fan of CONEXCEPT but this change doesn't address the problem of its awkward framing, and adds new problems.

Could you suggest an alternative? My aim with this change is to re-balance the policy basis for our relationship with the WMF and make us into a partner rather than a subordinate; the wording I proposed is intended to do that, but it could certainly be improved on.

It is noteworthy that your one proposal aiming to reduce friction and improve the quality of communication was quickly struck through without replacement.

Unfortunately, there seemed to be little appetite on enwiki for it, even if there was a little among the Foundation; I felt that it was better to not ask the question than ask it and have it be inevitably rejected. BilledMammal (talk) 03:07, 22 September 2023 (UTC)

I would want #3 to be on the table if we're considering the rest. Best, KevinL (aka L235 · t · c) 14:29, 22 September 2023 (UTC)

Editors interested in this topic might be interested in this Fundraiding update. Barkeep49 (talk) 14:48, 22 September 2023 (UTC)

Freudian typo? Barnards.tar.gz (talk) 15:29, 22 September 2023 (UTC)

• I appreciate the work that has gone into this. Regarding the first RfC, I think the request to disclose highest-paid employees and independent contractors is a non-starter that is likely to run into difficulties on legal, contractual, and privacy grounds. Personally I would focus on the other resolutions which in my mind could be summed up as "the WMF risks bringing the project into disrepute by spending donor money on initiatives that were not transparent to donors at the time of donation.". Barnards.tar.gz (talk) 15:29, 22 September 2023 (UTC)

  I believe that is part of standard financial disclosures, including those issued by the WMF, but Jayen466 might be able to comment more as he added that line. However, I can see how the community might see that aspect negatively, and see no issue with making the details of the request less specific. BilledMammal (talk) 15:39, 22 September 2023 (UTC)

  @Barnards.tar.gz Such disclosures are a legal requirement for any US nonprofit, and the WMF (unlike the Wikimedia Endowment) annually makes these disclosures in its Form 990. See e.g. its most recent disclosure of top earners here.

  We should hold the Endowment, which is organisationally completely separate from the WMF, to the same standard. In doing so, we should make sure that we ask for no more and no less than the legal Form 990 disclosure requirements the WMF is subject to (for example, no disclosure is required for people and contractors earning less than $100,000 annually.) Andreas JN466 16:09, 22 September 2023 (UTC)

  Perhaps if we phrased it:

  The English Wikipedia community appreciates that transparency in respect to the Endowment has recently improved, but is concerned that the transparency remains lower than that for the Foundation as a whole and by the lack of historic transparency.

  We request that the Foundation publishes financial disclosures for every year that the Endowment has existed in line with the Form 990 requirements that the WMF itself is subject to, and that it continues publishing such statements annually.

  The functional meaning should remain the same, but without the possible negative impression of the current wording. BilledMammal (talk) 16:25, 22 September 2023 (UTC)

  @BilledMammal Agreed (with the caveat that a full, 60-page Form 990-style return is a very significant amount of work – I'd be open to accepting something slightly less cumbersome than that, as long as we can see an annual revenue and expenses breakdown of the sort the WMF publishes in its audited statements, and the WMF discloses any staff and contractors who exceeded $100,000 in any one year). Andreas JN466 15:18, 23 September 2023 (UTC)

  I see. But what is the point of this request if they are legally obliged to disclose the information anyway? Is the point that we are asking them for retrospective disclosures for the years prior to the endowment being a 501(c)(3) public charity? Barnards.tar.gz (talk) 16:32, 22 September 2023 (UTC)

  @Barnards.tar.gz We have had nearly eight years of undocumented expenses, running most recently at $1.78 million per annum according to a file Jimbo uploaded in the course of this discussion.

  In 2022-2023, this included $875,000 of "personnel expense" and over $400,000 for "professional services". Jimbo stopped replying when I asked him who these payments were made to. :/ Andreas JN466 15:12, 23 September 2023 (UTC)

  [5] --Guy Macon Alternate Account (talk) 22:22, 23 September 2023 (UTC)

  The financial statements of the Endowment from 2016-2023 have been published on Governance Wiki. CVirtue (WMF) (talk) 18:02, 28 September 2023 (UTC)

  Wow, the Endowment hasn't even kept up with inflation. I wonder what the money was invested in... Levivich (talk) 19:04, 28 September 2023 (UTC)

  How should one reconcile this financial statement with the "$1.78 million per annum" figure mentioned above? Barnards.tar.gz (talk) 16:03, 29 September 2023 (UTC)

  In the statement, internal fees and other expenses amount to $199,000. On top of that, I think we can add $250,000 in donation processing expenses as it doesn't appear to be accounted for anywhere else, as well as the $1.3 millon grant to WMF as reimbursement for expenses the Foundation incurred serving the Endowment in FY2022-23 as it transitioned to a 501(c)3; this brings us to $1.749 million. We're still $29,000 short, but I think we're close enough that we can consider the figures reasonable - assuming my assumptions are correct. CVirtue, can you confirm that they are? BilledMammal (talk) 16:12, 29 September 2023 (UTC)

  @BilledMammal Thank you for the follow up question. Yes, they are correct. CVirtue (WMF) (talk) 16:14, 2 October 2023 (UTC)

  And a quick follow up note: Your figures are correct, but I wanted to point out that your assumptions combine budgeted and actual amounts. The $250,000 for donation processing was a budgeted amount for FY22-23. The $1.3M figure you mentioned is an actual (rounded) figure.  (The unrounded figure is $1.297M.)  CVirtue (WMF) (talk) 15:29, 3 October 2023 (UTC)

• If a large portion of the Wikimedia Community greatly disagrees with actions of the Wikimedia Foundation to the point where they can't tolerate them anymore, then there is one option and one option only: The right to fork. Even if WP:CONEXEMPT was not policy, it would not change the fact that WMF, who has access to every petabyte of information, deleted or otherwise, in the backend, can still take actions even if they are unpopular. This right to fork puts huge pressure on the WMF to act in the community's best interests where possible. And even if we did fork, WMF would not have trouble finding new editors to continue the project here. People come and go from Wikipedia. Forking is no different from leaving the WMF controlled site. Aasim - Herrscher of Wikis ❄️ 18:32, 25 September 2023 (UTC)

Knowledge Equity Fund community call

Note announcement on the Wikimedia-l mailing list of a community call concerning the upcoming third round of Knowledge Equity Fund grantmaking:

With the announcement of the Knowledge Equity Fund’s round 2 grantees, we’ve seen a lot of questions and feedback about the Knowledge Equity Fund, how the Committee works and how the work of the grantees will contribute to the projects and to the movement. To help answer these questions, the Knowledge Equity Fund Committee will host a community conversation on Friday, October 6, 2023 at 1400 UTC to hear ideas, concerns, and to answer questions. The Committee would also like to hear ideas for how the fund should be used in the upcoming third round of grantmaking.

To register for this conversation, please email us at EquityFund(a)wikimedia.org You can also send us questions beforehand. The call will be held in English and we will have interpretation in Spanish; if you would like interpretation into other languages please let us know. If you’re not able to attend, we will also share notes and a written list of Q&A after the call.

Thanks,

Nadee Gunasena, on behalf of the Equity Fund Committee

--Andreas JN466 16:18, 26 September 2023 (UTC)

I tried registering; unfortunately, the email provided either doesn't exist or I lack the permissions necessary to email it. BilledMammal (talk) 16:49, 26 September 2023 (UTC)

@BilledMammal Sorry about that! We've had several folks test and email that alias without issue, but I'm looking into what the problem could be. In the meantime, if you want to try again and also copy my email directly (ngunasena@) we will make sure to register you. NGunasena (WMF) (talk) 18:33, 26 September 2023 (UTC)

Ugh. Please, no Round 3. Ever. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 10:13, 2 October 2023 (UTC)

General sanctions alternatives

Considering the discussion here, perhaps we should try a middle ground between general sanctions and doing nothing; just propose to place at the top of WP:VPW the following text:

Behaviour on this page: This page is for engaging with and discussing the Wikimedia Foundation. Editors commenting here are required to act with appropriate decorum. While grievances, complaints, or criticism of the foundation are frequently posted here, you are expected to present them without being rude or hostile. Comments that are uncivil may be removed without warning. Personal attacks against other users, including employees of the Wikimedia Foundation, will be met with sanctions.

Thoughts? BilledMammal (talk) 16:56, 26 September 2023 (UTC)

Why? Why single out this page? Why give the impression that the paid employees need to be treated better than volunteers on other pages? Of course no one should be calling WMF employees (or anyone else) names, no hatnote is needed for that. But in the (not-so-distant) past, the only way to get some results has way too often been to drop the "can you please perhaps do this?" and switch to "do this or we will change the interface / add an edit filter / put up our own banners / ..." which is definitely hostile but was the only way (not always, but in too many cases) to actually get the WMF to listen, to act, to understand, instead of them being very polite and civil but completely ignoring the complaints of enwiki (and often other communities as well). Fram (talk) 18:01, 26 September 2023 (UTC)

At least it's been my impression that we often treat WMF employees worse than we treat volunteers - and in any case, the purpose is to encourage them to participate, and this (based on the warnings provided at ARBCOM) seems to be a low-cost way of trying that.

I'll note that it shouldn't prevent criticism of the foundation; if we want to take away their banners again then we can still propose/threaten to do that. BilledMammal (talk) 18:11, 26 September 2023 (UTC)

As an example, take Wikipedia:Village pump (proposals)/Archive 130#Disabling_Gather? (the WMF subpage didn't exist yet back then, I think). I shudder to think how many people would have been blocked under the originally proposed GS or the "sanctions" you suggest here, and how many comments would have been "removed without warning" for being rude or hostile. Of course, the many outright lies from WMF employees in that discussion (but delivered in a civil and non-hostile manner) would not be removed or sanctioned at all. Fram (talk) 18:15, 26 September 2023 (UTC)

Some people claim that the reason The WMF will not engage in any discussion is because of our hostility. Example: [6], which resulted in silence. See how hostile I was there? I am surprised that I didn't get banned for being such an asshole.

I think we can survive a short period on a specific page where we are all forced to be ridiculously polite just to test that theory. I predict that the overly polite questions will also get nothing but silence as a reply, in which case we can throw out the silly politeness rules and respond to all "it's your hostility!" claims with a canned "this has been proven to be false" response. --Guy Macon Alternate Account (talk) 03:19, 27 September 2023 (UTC)

I predict that the overly polite questions will also get nothing but silence as a reply, in which case we can throw out the silly politeness rules and respond to all "it's your hostility!" claims with a canned "this has been proven to be false" response. I'm hoping the result will be increased communication, but I'll also count this result as a success - and either way we would be able to point to it as an example of enwiki trying to work with the WMF. BilledMammal (talk) 13:31, 27 September 2023 (UTC)

Some editors will need to adjust their behavior a little - kinda the point of the entire exercise - but the underlying sentiments in that discussion could still be expressed. BilledMammal (talk) 13:31, 27 September 2023 (UTC)

To balance things out, we could have a place where you can lie, call people names, and just make "facts" up. Oh. Wait. Twitter already exists. Never mind.   :(   --Guy Macon Alternate Account (talk) 19:29, 27 September 2023 (UTC)

Updated proposals

Following the discussion here, I have updated two of the three proposals; the CONEXCEPT RfC has been reworded for clarity, and the proposal for general sanctions has been toned down to behavioral instructions.

At the moment, the non-binding resolutions are unchanged; however, I am wondering if the financial statements published at Governance Wiki are sufficient to allow us to remove the first proposed resolution; personally, I feel that it is, particularly since I have always been concerned at the number of resolutions that need to be discussed and think that reducing them would increase the strength of the consensus generated.

I'll leave this discussion open for a few more days, and if there are no more significant changes open the discussions. BilledMammal (talk) 02:07, 29 September 2023 (UTC)

Agree on the financial statements. I think along with the clarifications on Meta-Wiki, they are pretty much what we were going to ask for, and were released in good faith.

That resolves the issue for me. Thanks for bringing that about. Andreas JN466 05:45, 30 September 2023 (UTC)

Removed, then - I'm gladdened to see the WMF willing to work with us here. Current plan is to open the discussions on 2 October. BilledMammal (talk) 14:01, 30 September 2023 (UTC)

Discussion Hub page

As the final step before opening the discussion I have created a Hub page for the discussion. It contains links to the various discussions taking place as part of this process, and will also be used as the target for the WP:CENT listing, as well as where we ping editors who have been involved in prior discussions about our relationship with the WMF.

Please look it over and ensure it is appropriate for that purpose; unless major changes are needed, to the hub page or elsewhere, I will open the discussions on the 3rd. BilledMammal (talk) 13:30, 1 October 2023 (UTC)

WikiProject Stub improvement

I'm interested in reviving Wikipedia:WikiProject Stub improvement, which really should be one of the core maintenance WikiProjects. I've already added some new content to the project page, but more ideas would be appreciated on how to organize and operate the WikiProject. Thebiguglyalien (talk) 15:47, 27 September 2023 (UTC)

Perhaps try to showcase WP:DYK carrot incentives. Might require more than 3 sources, but getting 5x expansion from a stub is often not much of a challenge. CMD (talk) 16:42, 27 September 2023 (UTC)

Incentivising stub expansion with DYKs is an idea that fits well. In August I did a ~6x expansion to a stub and ended up not going for DYK because I've never been through the process before and I didn't have the space or focus to learn it.

If this carrot is something Wikipedia:WikiProject Stub improvement will be dangling frequently, it might be nice to have someone on the crew who could act as DYK ambassador to help people through the process, up to taking over the paperwork entirely (i.e. all the work except for making further article improvements as required by the reviewer and any applicable QPQ).

Of course, as a DYK ignoramus as indicated above, I may be operating under some misconceptions. Folly Mox (talk) 21:42, 30 September 2023 (UTC)

There is that pesky 1500-character minimum. Edward-Woodrow • talk 22:38, 30 September 2023 (UTC)

How about focusing on stub articles that a WikiProject has rated as 'Top' or 'High' importance? That seems like it would be of greater value and possibly attract more interest. Praemonitus (talk) 13:54, 30 September 2023 (UTC)

Is there a place where all of these stubs can be found, or would they have to be found one WikiProject at a time? Either way, collaboration with other WikiProjects is probably a good way to get some stubs improved. Thebiguglyalien (talk) 16:41, 30 September 2023 (UTC)

The server that helps build the article assessment tables for WikiProjects requires Project as a filter before Priority and Assessment can be added, at least in the UI. I have no idea if the options are less limited if an API can be used instead. Folly Mox (talk) 21:26, 30 September 2023 (UTC)

Oh wait I'm dumb I'm sure there can be a query constructed to search for Talkspace pages containing {{WikiProject banner shell}} and the string "class=Stub|importance=High" or "class=Stub|importance=Top". You might even be able to do it from Special:Search, using the functions hastemplate and insource. Requires more regexery than I remember how to perform. Folly Mox (talk) 23:13, 30 September 2023 (UTC)

According to WP:Content assessment, there are 4,265 top importance stubs, but it doesn't say what they are. According to this search, there are 2,927. But even then, it might be better to do it by subject anyway, because most people would rather edit a stub in their own area of expertise. I actually thought about doing an "important stubs" list for each category of stubs based on pageviews or incoming wikilinks, but that would be a huge pain to keep updated manually, and I don't know where to start with automatic updates. Thebiguglyalien (talk) 23:30, 30 September 2023 (UTC)

The search is inaccurate (no opinion on WP:Content assessment's count). There are false positives because "class=Stub" has become decoupled from "importance=Top", probably because pipes are problematic. The second result from the search linked in the comment above is Talk:Normans, a B-class article according to all five projects that have rated it. Folly Mox (talk) 01:15, 1 October 2023 (UTC)

As to the pageviews thing – which sounds like an excellent idea – Massviews Analysis can probably somehow be used to figure it out. Folly Mox (talk) 01:20, 1 October 2023 (UTC)

I think the best solution would be to do this on a "per event" basis. Maintaining a bot or manually updating a big suggestion page would be a lot of maintenance for relatively little return. It might be worth revisiting if this becomes some major hundreds-of-members project, but otherwise I'd rather have a curated "top stubs relevant to this event" list whenever a themed event takes place. Or maybe even a topic of the week or something like that where a large stub category is chosen. Thebiguglyalien (talk) 15:26, 3 October 2023 (UTC)

As I think about this, I'm feeling more inclined toward a "stub category of the week". That way we could mix up the topics to get different editors engaged each week, prioritize the more critical stub categories, produce a list of "high priority stubs" for the given category, and work with relevant WikiProjects for each one. The main questions would be whether "every week" is too ambitious, and whether people would show up. Pinging Folly Mox since you were interested in this, but I'd love to hear feedback from anyone. Thebiguglyalien (talk) 19:43, 4 October 2023 (UTC)

Well the good news is that Category:Stub-Class articles contains 2008 subcats at time of edit, so I think that a different curated list of high-priority stubs every week is unlikely to feel substantially different to random noise.

I did check out the Massviews Analysis tool on an arbitrary subcategory, and after an initial dumb error I got this result, an ordered list of stubs in Category:Stub-Class women in archaeology articles (158), sorted by pageviews over the past year. The most popular article in the category, Nayanjot Lahiri, averaged over 30 views per day over the past year, and I have no idea what that means.

Long-term, this would be easier to automate, but the upfront cost is learning the API and a bunch of coding. I don't think that working with other WikiProjects is likely feasible, because most are inactive, but if we do have a periodic stub improvement list that affects a WikiProject, we could always spam notify their talkpage about it. The pageviews metric seems more doable than the priority metric, as well as more empirical.

I do like the idea of mixing up the topics each time, so that there's a better chance of something for everyone, and some of the Stub-Class articles subcategories have members in the five digits, so it might make sense to build a query once about them, and rotate in a few articles from that subcategory each new event. The top-listed article from each curated list that goes unimproved while on the event list can be placed in a new category or page like "high priority stubs that didn't get improved during the drive they appeared in", but named better.

The Massviews Analysis query results can be downloaded as a csv or a json, so people who can process those sorts of things can turn them into something workable with. If I had to suggest an initial methodology, I'd suggest something along the lines of

1. Special:RandomInCategory/Stub-Class articles
2. feed into Massviews Analysis with date settings one year, agent setting User, source setting Category, "Use subject page instead of talk page" yes
3. download results and add to spreadsheet
4. repeat n times and until total rows ≥ k
5. order by total pageviews
6. extract top 40??
7. repeat every two weeks until someone has a good idea instead.

Folly Mox (talk) 22:05, 4 October 2023 (UTC)

I'm hesitant to do anything too complicated, especially since we don't know if this is something that will hold the attention of more than two or three editors at a time. If this becomes a thing, it might be good to at least start with a more curated approach, choosing topics where there's already a dedicated editor base to tap into. Then once a category is chosen, Massviews can tell us which articles are most important. We could also do something each week like "whoever de-stubs the most articles this week gets a barnstar", but that would add to the maintenance because we'd have to decide what counted as de-stubbing and then someone would have to check everything every week. Thebiguglyalien (talk) 22:40, 4 October 2023 (UTC)

Also I just found that the Wikipedia:The 50,000 Destubbing Challenge exists as part of Wikipedia:The 100,000 Challenge when I was looking to see how the latter did its events. It's not terribly active and hasn't done any event type thing in a while, but it's another place to list stubs that basically serves the same purpose as the "Showcase" at WP:STIM that would be used to track these. Thebiguglyalien (talk) 22:50, 4 October 2023 (UTC)

Wikipedia:The 50,000 Destubbing Challenge is presently under discussion at Wikipedia:Village pump (proposals)#Random article improvement feature. Maybe you and User:Dr. Blofeld and User:BeanieFan11 could all combine forces and projects to capture the whole article expansion demographic. Folly Mox (talk) 00:41, 5 October 2023 (UTC)

Is there any sort of centralised listing of which maintenance WikiProjects are considered "core"? Or some definition of what this means?

Zooming out one level, this thread and the one directly below it are the same genre, and speak to the problem we have of trying to get volunteers interested in new topic areas or new ways of contributing. It would be nice if we had more methods for this, and discoverability options outside watchlist notices and being listed at Wikipedia:Task center. Folly Mox (talk) 14:20, 30 September 2023 (UTC)

What we might be able to do is look for editors who are already improving stubs but aren't participating in the WikiProject; if we can find such editors and bring them in to a WikiProject that supports the work they are already doing I suspect we will boost editor retention and increase editor efficiency. BilledMammal (talk) 14:49, 30 September 2023 (UTC)

By "core" I just meant "really important in the maintenance process". And the issues like those in the discussion below are a big reason why I wanted to revive this in the first place. If BilledMammal thinks it would be helpful, the structure of WikiProject Stub improvement could be built alongside this effort and similar activity. I'd like de-stubbing drives to become a more common thing. At the very least, anyone involved in destubbing could be encouraged to add their entries at Wikipedia:WikiProject Stub improvement/Showcase, which I created to hopefully provide a small incentive to get more stubs de-stubbed. Regarding ways to discover these, there's the WP:Community portal, but I don't know how widely used it is by heavily active Wikipedians. Thebiguglyalien (talk) 16:47, 30 September 2023 (UTC)

• Comment - For a time I had a passing interest at Wikipedia:WikiProject Reliability#Open tasks. When I first saw that list, it was really confusing that there are so very many Reference-related categories. To wrap my brain around all that, I setup a structure here. Relating this to WP Stub improvement, How to participate section, number "2. Find at least 2–3 good sources about that topic." can be Extremely difficult to do. What I propose is to add on the Project page, some short "Getting started" link(s) for a beginner. Where to find reliable source. This Signpost article is about Wikipedia Signpost/2023-09-16/Serendipity about The Wikipedia Library. Regards, JoeNMLC (talk) 17:36, 3 October 2023 (UTC)