Wikipedia:Village pump (idea lab) (WP:VPI)

In the news has an issue in that the selection process for articles is almost entirely on the basis of editors personal preferences and biases - current editors, in the case of non-recurring stories, and past editors in the case of recurring stories. This has resulted in a systematic bias issue that prioritizes topics of relevance and concern to Wikipedia editors, rather than to the world in general. This can be prominently seen at ITNR. Defined very broadly, 73 of the listed events cover international topics. Of the rest:  23 European (11 British, 1 German, 1 Spanish, 8 generally; 1 per 32 million people) 16 North American (13 American, 2 Canadian, 1 generally; 1 per 36 million people) 6 Asian (3 Indian, 2 Japanese, 1 generally; 1 per 760 million people) 5 Oceanic (4 Australia, 1 New Zealand; 1 per 9 million people) 2 South American (2 generally; 1 per 211 million people) 1 African (1 generally; 1 per 1216 million people)It also violates the core policies of WP:OR and WP:NPOV. By deciding which events are significant enough to publish ITN through our personal criteria we are engaging in original research and placing undue weight on those events that are included based solely on those personal preferences. To fix this we need a more objective criteria for inclusion at ITN, and my initial proposal is for one of the following:  The event has received significant original (not syndicated or from a wire service) coverage in a wide variety of reliable international news sources. The event has received significant original (not syndicated or from a wire service) coverage in a majority of 21 selected reliable international news sources.The second proposal would involve selecting those sources; I expect these would include Agence France-Presse, Associated Press, BBC, Deutsche Welle, The New York Times, Reuters, and The Times of India, while the others would be the subject of considerable discussion. It has the advantage of being more objective and better suited to reducing systematic bias by forcing editors to consider coverage in a wider range of sources, particularly if the list includes non-English language sources, but it may also be harder to get an initial consensus for due to difficulty in creating the list of sources. The current criteria requiring that the article has been updated and that it meets a minimum standard of quality would remain unchanged. Please provide both any thoughts you have on the two proposals listed, and any alternative proposals that you may have. BilledMammal (talk) 15:12, 14 February 2023 (UTC)  I think is a very minor concern.  Most of what doesn't get through ITN or gets through ITN is mostly determined by the quality of the article update.  Which is as it should be, the purpose of the main page is to tell people about Wikipedia articles that are of a high quality.  Everything else is irrelevant.  ITN is not "Tell the world what Wikipedia thinks is important", that's a terrible way to think about it.  Instead, it is "What is something recent that Wikipedia readers may appreciate reading a high quality Wikipedia article about" with an emphasis on the high quality.  I'm far less concerned with playing cultural gatekeeper and making sure that the main page is not sullied by things from certain geographic areas, and I'm pretty much only concerned that Wikipedia articles are improved, and that we let readers know what those articles are.  --Jayron32 15:55, 14 February 2023 (UTC) ITN is not "Tell the world what Wikipedia thinks is important" – The problem is that this is exactly what it's become. Most people !voting on blurbs don't even mention article quality. It's just the personal opinions of editors as to whether they feel it's an important news story or not. If you want ITN to be centered around article quality, then it's going to need considerable reform. Thebiguglyalien (talk) 20:21, 14 February 2023 (UTC) +1, this is my impression of it, too. Levivich (talk) 20:33, 14 February 2023 (UTC) +1, One article that I worked up to GA borderline passed ITN despite it winning the video game equivalent of an Oscar, with the event attracting tens of millions of viewers. If it was based upon article quality, it would have been accepted much more readily, but the main opposition was centered around video games being "not important enough for ITN". The Night Watch (talk) 15:37, 15 February 2023 (UTC) “It's just the personal opinions of editors as to whether they feel it's an important news story or not.” That’s typically how consensus works, and from skimming this discussion it seems to be a lot of the usual suspects on ITN who disagree with the mere idea of consensus because it usually goes against their opinions. The Kip (talk) 16:11, 15 February 2023 (UTC) That's not how it is supposed to work at Wikipedia.  At Wikipedia, we ignore commentary that is not based in a sound footing of Wikipedia policy and guidance.  If people are commenting with rationales that don't align with established principles at Wikipedia, we're supposed to ignore those comments when assessing consensus.  From WP:CONSENSUS, and I quote, "Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy." (bold mine).  ITN has written standards; if people ignore those written standards in their commentary, then their opinion should not be taken into account.  So know, we should not let consensus discussions be overwhelmed by people whose opinions run counter to long-established Wikipedia principles.  --Jayron32 13:36, 16 February 2023 (UTC) The problem of late is that we have stories that bring a lot of "drive by" !votes (editors that are maybe at ITN the first or second time in their history) and vote, such as in death blurbs "very important person" without further explanation. When that happens en masse, the ITN admins in charge of posting seem to not consider the "views through a WP policy lens" and are more or less !vote counting. (The posting of Betty White's death and Carrie Fisher's were examples of that). That also applies to general stories too. Not so much that the recent one on LeBron breaking the scoring record being flooded with such but there were definitely drive-bys that were basically "Support - a key record was broken" without any further explanation.  And that was briefly posted before pulled as the posting admin seems to take those !votes into account when they should have been discounted. That's getting away from this point on importance based on RSes, but it is also tied to it, since I've seen frequent calls on stories that get !votes like "All over front pages" or "leading story on (key sties)", which may indicate importance to news media, but not to an encyclopedia per NOTNEWS (eg the whole mess with the US House's Speaker election). I do believe there are some objective standards that incorporate frequency and type of coverage by RSes to evaluate relative importance to the world body of sources, but it should definitely not be the sole driver (in addition to quality) for consideration. Masem (t) 13:58, 16 February 2023 (UTC) "Not a news ticker" means it isn't our job to tell people what is important, it is our job to highlight quality content only.  It doesn't really matter much whether or not we think something should or shouldn't be "important", we should be showing people quality article content, period.  Any decision making that attempts to assess worthiness is making ITN a news ticker.  Instead, it should be a tool to direct people to high quality articles about current events.  --Jayron32 14:23, 16 February 2023 (UTC) Disagree, as the more blindly include topics based on quality followed by news prevalence without any further consider, the more we mirror what news media believes important, and we become a news ticker to them.  It should be obvious that not every story that gets huge promotion on the news makes for a reasonable topic (first and foremost we rely on enduring coverage and not bursts, which us what the typical story in the news is), so we clearly need a filter to eliminate burst-news coverage. Then we need to add the issue if systematic bias that even with a good selection of worldwide press, we will still find ourselves favoring Western topic, and hence the need to increase the visibility of events in less covered places that our significant (eg the Turkey/Syria quake has been getting less coverage than all the 2024 campaign hijinks or even the Ohio rr srory). That's why blindly following news media makes us more like a news ticker. Masem (t) 14:49, 16 February 2023 (UTC) You can disagree, but your rant about bias is irrelevant here.  You fix bias by making articles about underrepresented topics better.  The idea that we should eliminate bias by making Wikipedia articles on Western topics worse seems like a bad idea.  --Jayron32 15:10, 16 February 2023 (UTC) Far be it from me, a clueless non-admin, to make a judgment about how admin work usually goes at ITN, but I've found that Masem's observations are more or less correct, that the significance of a story is based on who shows up to vote and in what quantity. So any story that provokes an emotional reaction from editors will likely sway the balance because we weigh all of these "significant/not significant" votes equally. This comes down to us not having a clear objective criterion for significance on WP:ITNCRIT, instead going based off of a subjective consensus. I expect that when The Boat Race is nominated for 2023, despite the article being a FA year-after-year (the quality that Jayron32 is looking for), there will be a visceral outpouring of opposition, more than we'd see for any other sporting event, based on the fervor that was accumulated during the discussion calling for its removal from WP:ITN/R. In regards to bias, the difficulty with nominating underrepresented topics is that we are still stuck in a precedent-based mindset of "well, we never posted this before, we shouldn't post it now" or "it's not disastrous enough" or "I've never heard of it". That's the sort of acts that perpetuate systemic bias. Indeed, it's present across all of ITN. These sorts of arguments would never fly in an AfD, so it's a real shame that they can be effectively weaponized in this setting. Moreover, newer contributors who are nominating something for ITN for the first time tend to be driven off by petulant line-towing semi-regulars who scream at them "Of course this isn't notable, SNOW close, why the fuck did you nominate this?" which is most discouraging. It's a big part of why people complain about ITN's atmosphere. I don't agree with Masem on a lot of things. I think during the start of the 2022 Russo-Ukrainian War, he took an incredibly skeptical line in challenging just about everything the reliable sources stated about events such as massacres or missile strikes. But I think he's right on this one. ⛵ WaltClipper -(talk) 13:40, 17 February 2023 (UTC) Are you disagreeing with me that we should make articles on underrepresented topics better?  --Jayron32 13:43, 17 February 2023 (UTC) I disagree with you that our job is to only highlight quality content, because even if that might be our mission, that's not what the criteria states and that's not consistent with our established consensus which calls for identifying a story's significance. I agree with you on making articles on underrepresented topics better, but if our goal is to get it onto ITN and onto the Main Page, I don't believe that improving it to even an FA will be enough to get it posted to ITN. ⛵ WaltClipper -(talk) 13:53, 17 February 2023 (UTC) Let me also hasten to add that I want our job to be highlighting only quality content, just like you do, but I don't think we'll get everybody to drink from that cup. --⛵ WaltClipper -(talk) 13:57, 17 February 2023 (UTC) The larger problem is that I think we (WP overall) have lost sight of why NOTNEWS exist. Newspapers serve one function - to report information as fast and broadly as possible - while an encyclopedia serves a different one - to summarize a topic for posterity. If we put those functions into a Venn Diagram, there would definitely be an overlap in that there are topics that started as news that become clearly important for enduring knowledge. And with covering current events, we generally had been pretty good about being predictive that an event is going to have the long tail that makes for a good encyclopedic topic. But we getting a lot of new current event articles that may be well-backed from newspapers as part of their function, but fail to prove out as long-term events of significance. In other words, we have editors trying to write like a newspaper and thus we get a lot of noise at ITN, particularly from overrepresented areas. I think we do need to tweak how editors approach NOTNEWS and NEVENT, understanding that just a mere burst of coverage is not necessarily quality sourcing for an encyclopedic article. Whereas news stories from underrepresented areas that fit into encyclopedic content, there may be the long-tail of coverage but the number of works covering it will be low, and that's why I think any type of "counting" of story coverage is a problem that feeds, not fights, systematic bias. I'm willing to hear about any system to help improve objectivity and reduce the drive-by voting, and there may be something in source counting, but I don't see an obvious solution that still creates a systematic bias problem. Masem (t) 15:46, 17 February 2023 (UTC) The change proposed runs counter to the stated goal, but that doesn't matter because the premise here is ridiculous. ITN/C aggressively combats bias and engages in affirmative action by applying lower standards to quality and significance for under-represented regions. GreatCaesarsGhost 16:44, 14 February 2023 (UTC)I'd support trying either of these proposals, or pretty much anything that will make ITNC more objective and less subjective. It's always felt bizarre to me that widespread media coverage does not count as "significance" at ITNC, and instead, "significance" is just the sum of subjective opinions of participating editors. As between these two proposals, I'm split; I can see both the upsides and downsides of specifying a number. Other reform ideas: eliminate blurbs altogether and just post the links to articles (so everything would look like ongoing or RD, and we could use the extra space for more pictures, so we could have, e.g. three picture slots and no blurbs); replace ITN with a "most-edited articles" or "most-viewed articles" list; eliminate ITN altogether and rearrange the main page with the remaining elements (FA/FL/FP, DYK, OTD). Levivich (talk) 20:42, 14 February 2023 (UTC) Wikipedia is not a newspaper, and ITN is not a news ticker. We're there on the front page to feature quality articles about recent events that happen to be in the news, not to feature news stories that have quality articles. That's why significance and quality are the key determinants in ITNC discussions. Following the news does not give us the broad range of topics that we want ITN on the Main Page to be. I do think that the "significance" factor has been watered down and/or weakened which started with the whole issue of mass shootings in the US, and there's lots of bitter feelings on that that which has made objective evaluation of significant far more difficult to come to on other topics. Masem (t) 03:45, 15 February 2023 (UTC)I have for a long time thought that this section has departed from its encyclopedic purpose, which is to highlight Wikipedia articles about subjects that are in the news, rather than specially created articles about the news events themselves, which should usually be deleted per WP:NOTNEWS rather than highlighted on our front page. People are given the impression that this is a news site rather than an encyclopedia. Phil Bridger (talk) 20:57, 14 February 2023 (UTC) ITN was established on the basis of how fast the community worked to produce a quality article on 9/11, and type of effort been repeated multiple times since. Now part of the problem is that NOTNEWS and NEVENT ofter go disregarded because nearly every event is claimed to be notable because of a burst of coverage (notable requires more enduring coverage). We really need to be more enforcing on NOTNEWS which should with some of the topic noise at OTN (currently exemplified by the UFO shhotdowns) Masem (t) 21:48, 14 February 2023 (UTC) I know I'm not with general consensus here, but we should really only be covering topics that are covered by secondary sources. Most articles about news events are primary sources. Of course newspapers sometime publish secondary sources, such as reviews of a situation, but the general opinion here seems to be that we should accept lots of primary sources, with some geographical distrubution, as the basis for an article. Phil Bridger (talk) 19:30, 16 February 2023 (UTC) Good idea. I want ITN to reflect what's actually in the news, not what some of us wish got attention. Maybe 21 sources is too high an estimate for a practical mainstream core, but the seven offered above are certainly a good start. InedibleHulk (talk) 21:27, 14 February 2023 (UTC) And yeah, even a perfect score in the coverage department won't allow a crap article posting, quality still matters. InedibleHulk (talk) 21:31, 14 February 2023 (UTC)Will not oppose. Well, we could try one of these, but I don't know what's going to happen. Many of the folks on ITN think it'll just heavily prioritize celebrity news or gossip. But who knows, it might work. I don't think we should do away with our current ITN/R items wholesale based on this new proposal. Just continue to nominate those for addition or removal on a case-by-case basis. ⛵ WaltClipper -(talk) 21:55, 14 February 2023 (UTC)Support something along these lines. I would add a stipulation that topics be in the "world" or "national" news sections of each publication to prevent NOTNEWS pop culture/sports/etc. creeping in. JoelleJay (talk) 23:07, 14 February 2023 (UTC) I think I agree with that, but the wording is a little ambiguous; I assume you mean any event that is classified as either international, related to a country, or related to a continent? BilledMammal (talk) 03:49, 15 February 2023 (UTC) Yeah, news articles that are classified under those sections of the newspaper. Like The Times of India homepage has a ticker menu at the top with "India" and "World", and articles map their directory path back to the parent category (e.g. here where it says NEWS / WORLD NEWS / CHINA NEWS / [article title]). JoelleJay (talk) 20:24, 15 February 2023 (UTC) @JoelleJay, how do you expect your criteria to work for something like the Nobel Prize in Literature, which should be in the Culture section?  What about the election of a pope or patriarch, which should be listed in the Religion section of a newspaper?   WhatamIdoing (talk) 23:52, 21 February 2023 (UTC) If we're going to be using some set number of sources, editors would have to come to a consensus on which sections of each paper qualify for assessing significance. JoelleJay (talk) 01:24, 22 February 2023 (UTC) I don't really expect this model to work.  In addition to the problem of choosing which wire services/newspapers count (nothing from Pakistan, home to 100 million English speakers?  nothing from Nigeria, the third-largest population of native English speakers on Earth?), I think editors will be unhappy with the results.  We'll want the culture section when the Nobel Prize in Literature is announced but not when the next Harry Potter-equivalent is released.  there is a significant fraction of editors who want Wikipedia to feel "serious", and relying on external sources that don't have a bias towards "serious" will not achieve their goals. WhatamIdoing (talk) 02:56, 22 February 2023 (UTC) I would suggest that it is better to collect evidence without changing the process first. It should be possible to, given an ITNC nomination, how many times it appears in the selected list of sources. Or alternatively, figure out a means to determine the top 5 stories of each work each day and count repetition across sources. With, say, a good two weeks or a month of data, it would be far easier to understand the impacts on ITNC without actually changing it.  My gut remains that this type of a approach will overwhelm ITNC with Western and English topic per WP:BIAS, but it would be best to prove that wrong before making any change. --Masem (t) 03:38, 15 February 2023 (UTC) I don't think such a test will work as I don't know what sources the community will chose and the result of this change will depend heavily on that. My overall position is that something has to be done; we can try this, and if after trying it for a few months we discover it doesn't work we can try something else. BilledMammal (talk) 03:49, 15 February 2023 (UTC) Then the first thing is to determine the "jury" of news sources, first and foremost, before even applying that. This has far too many working parts to implement without evidence and other testing beforehand, and could fundamentally break ITN if its not thought out well. Masem (t) 13:17, 15 February 2023 (UTC) My preference would be to start with a limited number of sources and then expand it over time. BilledMammal (talk) 13:47, 17 February 2023 (UTC)We should mainly use English-language sources as this is our working language and it's the international lingua franca.  But there are lots of news sites and channels now which present their content in English even if it's not their domestic language.  For example, see 22 English-language news outlets in Europe to follow and Top European newspapers in English. Andrew🐉(talk) 12:10, 15 February 2023 (UTC) However, there are times when key news happens first in foreign language sources (particularly SE Asia and South America) that using the known RSes from those regions are fine as well. That's another flaw in this system is that not all news breaks first in English. Masem (t) 13:27, 15 February 2023 (UTC)This is a terrible idea. Firstly, because ITN is not, and should not be, purely a news ticker. Secondly because far from avoiding systemic bias, having a special list of 'blessed' sources that determine what is worthy of ITN will deeply entrench that bias. I also don't think we should be reliant on English-language sources, which will also drastically skew our coverage. If a Hindi, or Chinese, or Brazilian Portuguese source is the main source for a significant story, we should reflect that. We had great trouble in this respect with trying to build consensus on the Nagorno-Karabakh blockade story - very few of the sources were even in the Latin alphabet, but that did not mean we should not attempt good, unbiased coverage of it. GenevieveDEon (talk) 13:14, 15 February 2023 (UTC)"Our criteria are too subjective, so let's post less stuff." Yeah, that will work. 2603:3005:42DF:4000:C512:B59A:D574:391A (talk) 17:36, 15 February 2023 (UTC) I think the last thing we should do is have any sort of minimum source requirement. That really isn't the issue we are currently facing. Most are concerned about not enough items being posted. I think a minimum source threshold will only exacerbate preexisting balance issues at ITN, as quite frankly most media coverage nowadays is about what generates more clicks. For example, many nations in Africa suffer from power instability and are subject to military coups, but usually this is just a passing news story for many Western publications. However, a transfer of power (especially one done by force) is clearly more noteworthy and impactful than some of the events we have and will post, such as the Ohio train derailment, which may not get posted but is on the cusp as of right now. DarkSide830 (talk) 18:45, 15 February 2023 (UTC) Somebody has to ask… Given WP:NOTNEWS, why do we even HAVE an “In the news” section on the main page? Blueboar (talk) 15:00, 16 February 2023 (UTC) One, WP:NOTNEWS does not mean we do not cover current events. Two, per WP:ITN, the purpose of the section is: To help readers find and quickly access content they are likely to be searching for because an item is in the news. To showcase quality Wikipedia content on current events. To point readers to subjects they might not have been looking for but nonetheless may interest them. To emphasize Wikipedia as a dynamic resource. --⛵ WaltClipper -(talk) 18:09, 16 February 2023 (UTC) As such, it seems that citing WP:NOTNEWS at WP:ITNC is misguided, when the MP section is literally titled "In the news".—Bagumba (talk) 16:53, 19 February 2023 (UTC) On the contrary, it's probably the most important place to remind editors of that policy. "In the news" exists to showcase Wikipedia articles about topics that are in the news, not to provide a news service. Phil Bridger (talk) 18:02, 19 February 2023 (UTC) I think the difficulty is that "In the news" doesn't make it obvious what the missing word is ("[Wikipedia articles] in the news"), and so most readers see the section as just the news section of Wikipedia, rather than "Articles in the news." :3 F4U (they/it) 19:01, 23 March 2023 (UTC) One of the reforms we should do is to get rid of the "showcase" purpose, as pretty much no article about current events is worth showcasing; there's not enough time to bring them up to GA or FA quality. We flatter ourselves with "showcase". The purpose of ITN is (and should be) to help readers find articles about topics that are in the news. Levivich (talk) 15:38, 20 February 2023 (UTC) The minimum standard is WP:ITNQUALITY, which does not claim to be GA/FA. —Bagumba (talk) 15:51, 20 February 2023 (UTC) Exactly. ITNQUALITY isn't good enough to be worth "showcasing", thus ITN doesn't fulfill the purpose of showcasing quality content, thus we should remove this purported purpose (not to be confused with a purported porpoise) from the list of purposes (not to be confused with the list of porpoises). Levivich (talk) 16:08, 20 February 2023 (UTC) Unless you are proposing the same pruning of article quality that DYK has, this is unworkable. We recognize many articles about news topics that do have encyclopedic purpose can get up to a perceived quality within a day or so, but the process to get through GA or FA is far longer than that, so we'll accept something that we can tell is likely to be of high quality in the short term. Masem (t) 16:10, 20 February 2023 (UTC) The Main Page of WP is to showcase quality articles in their relevant sections.  We can't remove that. We are not expecting GA/FA quality (though clearly will accept them), just as DYK doesn't expect those. The purpose of ITN is to help readers find encyclopedic articles about topics in the news, which means that not all topics in the news will necessarily be featured. Wikinews is better suited for the latter function where there is no encyclopedic requirement. Masem (t) 15:53, 20 February 2023 (UTC) Sometimes I think if I said "we should turn the light on" you would respond with a paragraph explaining that it is dark here. Levivich (talk) 16:10, 20 February 2023 (UTC) You keep introducing a meaning of ITN that is not based on the actual meaning of ITN, instead wanting to turn it into a news ticker. Masem (t) 16:13, 20 February 2023 (UTC) Hahaha yes that's called "change". I keep suggesting change, you keep explaining how things are as if I don't know. But seriously: please stop, it's annoying af. Levivich (talk) 16:16, 20 February 2023 (UTC) Things are as they are for a reason.  The changes you want to make would turn Wikipedia into something it is not meant to be. Blueboar (talk) 16:22, 20 February 2023 (UTC) Oh man, you're not seriously pulling out the "things are as they are for a reason" line? Trust me: that line is a weak argument wherever it's deployed; it's akin to rhetorical surrender, because "a reason" is not necessarily a good reason. Sometimes things are as they are for a bad reason, like in this case: editor vanity, wanting to "showcase" average work. Levivich (talk) 16:28, 20 February 2023 (UTC) I do think we need some change to ITN, because looking through the candidates often makes me often wonder what does "significance" mean? Some sport news are considered significant, some are not. Some mass shootings are significant, some are not. Some deaths are notable, some are not. We need some more clearly defined criteria, otherwise it just becomes heavily subjective. My question about the first proposal is what does "wide variety" mean? Does that mean 5 sources, 10, 15? Natg 19 (talk) 18:04, 21 February 2023 (UTC) You're pretty much on the mark. Although people have their own individual standards for what constitutes a significant story, in the end, overall significance is based on a headcount. That's the dirty word that people around here don't like to say, but I feel it's true in the case of ITN. A !vote that says "it's notable" has just as much weight as one that says "it's not notable". ⛵ WaltClipper -(talk) 17:10, 22 February 2023 (UTC) ITNC is the only page on Wikipedia I can think of where closers seem to never weigh votes; it's pure headcount. Even a vote that says "only significant in one country" gets weighed, despite being against the instructions on the very page. IMO, pretty much all the problems with ITN would be fixed if closers applied our WP:PAGs and weighed votes when closing discussions. If they explicitly stated the kinds of votes that they weren't considering (the kind that are contra PAGs, contra WP:ITN), editors would eventually stop making those kind of votes, and the whole enterprise would improve. But, alas, easier said than done. I'd do it myself if it didn't require running for RFA. Levivich (talk) 17:16, 22 February 2023 (UTC) Ditto on the RFA bit. Can't see myself as having "a need for the tools" if it's just to administer to one area of Wikipedia. ⛵ WaltClipper -(talk) 17:32, 22 February 2023 (UTC) Oh I disagree there; there are many examples of successful RFA candidates who ran specifically to work in just one area (e.g. SPI, DYK, CCI), and I think "main page admin" or "ITN admin" is a perfectly valid reason for someone to run for RFA. I'd never encourage anyone to run for RFA because I think the process is awful, but Walt if you're inclined to do so, I'd say go for it. Unlike me, I think you'd actually pass and ITN could use more admins. (ERRORS, too.) Levivich (talk) 17:43, 22 February 2023 (UTC) I'd only run if three people nominate me in good faith, one of them preferably being another admin. I've long bemoaned the gauntlet, and I also have a ton of skeletons in my closet that would be dredged up from my early editing days. ⛵ WaltClipper -(talk) 17:48, 22 February 2023 (UTC) As a further note, the only "guidelines" ITN has are the article has to be of sufficient quality (WP:ITNQUALITY), have "updated content" and the significance section, which itself states ultimately, there are no rules or guidance beyond two: (1)The event can be described as "current", that is the event is appearing currently in news sources, and/or the event itself occurred within the time frame of ITN. (2)There is consensus to post the event. There is a lot of explainer text following these two "rules", but unfortunately, this process is way too subjective to determine what is significant, so we need something to clarify "significance". Natg 19 (talk) 18:39, 22 February 2023 (UTC) My WP:HOWITNWORKS essay tries to clarify it, although honestly it explains the problem more than it tries to solve it. ⛵ WaltClipper -(talk) 19:12, 22 February 2023 (UTC) We have worked to address the issue of deaths, in that as long as the person has an article, it qualifies for the RD line once quality has been assessed. That might still leave debates over whether the person should get a blurb about their death, but that's not core to this concern. ITNR is also there to make sure a wide variety of recurring world events get covered (again, barring quality issues). One thing that gets us, and why using any type of source based counting causes problems, is that per NOTNEWS, we shouldn't be covering topics that have a burst if coverage but no long tail as its own story. We frequently have the heaviest discussions on such "burst" news coverage, and we need to adherents NOTNEWS better by focusing on topics with long coverage of events. --Masem (t) 18:47, 22 February 2023 (UTC)I disagree with ensuring our news story choices are proportional to the population of the continents, and also whether that is evidence of systemic bias within Wikipedia; our stories are based upon the major news sources in English, if there is bias it's the sources. But regardless of what we do someone will criticise us (whilst not being prepare to volunteer), so let the editors choose based on thier whim, becuase we often have a far wider range of stories than elsewhere. Wakelamp d[@-@]b (talk) 14:50, 20 March 2023 (UTC)   === Alternative - quality only === The issue is that our current assessment of significance is subjective. The alternative to using a less subjective method of determining significance is to remove the significance requirement entirely; change "In the news" to "Good articles on recent events" and have the requirements be that the article meets the good article criteria (with some leeway for stability given the event was recent) and that the event covered is more recent than the oldest currently listed. This does open the possibility of abuse by paid editors to increase the profile of their product so articles likely to be of interest to paid editors would also need to be excluded. BilledMammal (talk) 09:05, 19 February 2023 (UTC)  A less stringent requirement than good article class would be B class, but there have been past objections to using the class system for ITN on the grounds that it is too subjective below good article class. BilledMammal (talk) 09:09, 19 February 2023 (UTC) I'll go over the reasons why this won't work. First, it'll make the systemic bias issue worse than it is now, since topics from underrepresented regions will be harmed by the lack of extensive sources and the lack of people working on those articles to bring them up to the lofty requirements of the B or GA criteria. Second, having the lack of a significance standard will hyper-prioritize minuscule developments in those areas of Wikipedia which are well-developed, such as American politics, sports, celebrity news, business news, gaming, etc., and while that might not sound so bad in theory, you will have a very hard time getting ITN users to buy into that. Finally, it runs contrary to the goal of "[emphasizing] Wikipedia as a dynamic resource", since the increased quality standards would result in a stagnant article base. ⛵ WaltClipper -(talk) 15:58, 19 February 2023 (UTC) I'll second Walt Clip's comments here. And, in the end, do we really have such a colossal issue here that we need to make such a massive change that a lot of editors aren't going to buy into. DarkSide830 (talk) 16:19, 19 February 2023 (UTC) I don't think we'll have enough GAs to fill the pipeline. However, drop that, and it could just be "new articles" or "recently-updated articles" that meet the minimum ITN requirements (like DYK). There's also the possibility of somehow combining DYK and ITN. Levivich (talk) 17:18, 23 February 2023 (UTC) As in, all articles, regardless of significance, as long as they meet the quality requirements? I would support that, so long as we include appropriate protections about it being abused by UPE's. BilledMammal (talk) 01:49, 24 February 2023 (UTC)BilledMammal I think quality-only is the way to go, but I don't think it needs to be restricted to good articles. Any event article that meets basic criteria on quality should be included. WP:Notability (events) should be the "significance" standard. If it doesn't have its own article, then it's probably not worth putting on the main page. And if there's a recent event that you think should be included, just create a high quality article about it. Thebiguglyalien (talk) 18:36, 17 March 2023 (UTC)   === Trending Topics === I believe supplanting with a "trending topics" of some kind is long over-due. We had posted this idea and got some amount of interest, but that thread as with many other ideas died because we did not know where to take it. In some sense the iOS app already does this. Repeating the posting from here Wikipedia_talk:In_the_news/Archive_96#Trending_Topics  Background: We often get comments tying stories and nominations to their potential popularity particularly as measured by page views. However, we all broadly agree that we should not be conflating WP:ITN significance with WP:PAGEVIEWS. Also, we agree that WP:ITN is not a news ticker.Suggestion: I think this might be time to introduce a trending topics section either as a part of the WP:ITN box or outside of that. It does reflect quite poor if our mainpage after all these years is still fairly static in its content refresh capability and is not dynamic i.e. tailored either based on audience interest (trending topics), geographic interest (trending near you), or personalized reccos (tailored for you). Trending topics reflects the lowest level of personalization but is still dynamic, whereas tailored for you is the highest level of personalization, while trending near you is in between. This can either be text-based links or better still, images. Requires some amount of creative thinking and might not be in the remit of this group which is largely in a maintenance and operations mode.Complexity: This is not an easy problem to solve since it requires a technical solution, which might or might not exist within the Wikipedia realm. Furthermore, there will have to be new sets of processes including of reviews and such that might need to be baked in.Next Steps: Would love to get this group's input on the interest for such an idea. More importantly who would be the right group to take this idea forward, if at all.Some good ideas came up there. But, we could not take it further. Good luck. Ktin (talk) 02:27, 23 February 2023 (UTC)  I like this idea (trending topics), and I especially like it if it can be more than "just" WP:PAGEVIEWS (call it "general trending"), such as the examples you gave, "trending near you" (geographic) or "tailored for you" (personalized). Here are my concerns about it: I'm no expert in these things, but I don't think there is a technical impediment, I believe a bot could use Pageviews API to grab page views and then write them to a Wikipedia page, which could be updated periodically (not sure what frequency is possible/desirable). I could be very wrong about this, as I've never tried to do it before. I have no idea if the Pageviews API lets you break it down geographically. I don't think MediaWiki has the capability to deliver personalized suggestions (for logged-in or logged-out users), but I might be wrong about that, too. In theory this is doable, though, as many other websites do it. I'm concerned about "false positives", which could be exploited. See [1]. This happened in January with topviews reporting Index (statistics) (don't know why) and Cleopatra (see [2]). However, we could account for this issue by allowing human editors (admins) to override the bot algorithm and exclude certain pages when appropriate. Human editors could also override the bot to pull listings based on poor quality, if we wanted to do that. It's possible to do this and not have it automated at all, but it would slow down the rate of update. Still, I think it's an idea worth exploring, mostly because it takes the "significance" requirement of ITN out of the subjective hands of editor opinion and puts it into the objective hands of readership statistics. Levivich (talk) 17:16, 23 February 2023 (UTC) Pageviews API is heavily rate limited; I don't think that is a viable solution. However, the WMF does do (daily?) dumps of pageviews, so pulling that file could work as well. Unfortunately, the WMF does not provide view localization, although I am certain that they do have this information and might provide it if requested? MediaWiki does support content localization; we already see this with banners. It will take some work to make it work for page content but I believe this is something we can do and don't require the WMF for. I would generally support a solution like this; we could also use weighted pageviews, to give extra weight to articles whose content has recently been updated. On the topic of false positives, does anyone know why the pageviews of Cat might have spiked by a factor of ten yesterday? BilledMammal (talk) 01:58, 24 February 2023 (UTC) It's probably getting recommended by a virtual assistant, same as Cleopatra. Curbon7 (talk) 02:02, 24 February 2023 (UTC) My cat told me to stop asking questions. Levivich (talk) 06:17, 26 February 2023 (UTC)Question. Who can take this idea forward to see if it has some merit toward implementation? Should I be posting this in some specific group? Thoughts? Ktin (talk) 16:40, 1 March 2023 (UTC) @Ktin: My 2c: a mock-up is what's needed. Levivich (talk) 06:01, 6 March 2023 (UTC) Thanks @Levivich. I wish I knew of a way to share a mockup here. I can draw on powerpoint or a piece of paper and share that as an image. Would that help? Alternately, just replicating what the iOS app has by way of top read articles would be a win. Thoughts? Ktin (talk) 21:57, 10 March 2023 (UTC)  Ktin (talk) 22:18, 10 March 2023 (UTC) @Ktin: I think that looks really good. But my guess is that what'll get people really engaging with the idea is to see a picture of what the main page would look like with "trending topics" (or "top read" or whatever you call it) on it. My guess is an image (as opposed to a coded, functional mock-up) would be fine for discussion purposes. Unfortunately I lack the graphic design skills to create one myself. Levivich (talk) 00:00, 11 March 2023 (UTC)  Have you tried to chat with openAI bot ChatGDP? It is amazing, breathtaking to say the least. But what are the implications for WP? As I realize, ChatGDP has a "training data pool", with info retrieved from WP, among other sites. Whilst I think OpenAI is a great tool for enhancing education and research, I think there are potential dangers. I would like to suggest, we, the WP, suggest to openAI to only include reviewed articles ie Good articles or better. Have you guys discussed OpenAI issues anywhere else in WP? I 'd like to read others perspectives on the issue. Cinadon36 11:13, 28 February 2023 (UTC)  There is some discussions going on in the talk page of Wikipedia:Large language models if you are interested. Vpab15 (talk) 12:26, 28 February 2023 (UTC) I think it is actually better for LLMs to include “junk” in their training input, especially if low-quality articles are clearly distinguished from the Good articles, as this allows the AI to learn what good looks like and what bad looks like. Barnards.tar.gz (talk) 16:04, 1 March 2023 (UTC) Large language models are good at reproducing coherent language, and bad at writing properly referenced encyclopedia articles.  They produce something that at first glance looks like a really good Wikipedia article, but don't (for example) actually read, cite, synthesize, and create coherent articles from source texts.  They can give something that has all of the trappings of a really good Wikipedia article on the surface, but is actually nonsense once you scratch it away.  --Jayron32 20:51, 1 March 2023 (UTC) I feel you are a little harsh here @Jayron32. You are placing the bar too up high. We are at the beginnings here. I have asked chatGDP a couple of questions in my field of expertise and the replies I got were moderate to good. Which is astonishing, especially if you keep in mind that this is a new technology. Yes, I have also noticed the problem with references. Also, I feel there is an element of vagueness and cliches? Maybe, I am not sure. But, it is a project that is still developing. Cinadon36 08:02, 3 March 2023 (UTC) I too can search for common text strings and copy and paste the information in a way that shows no understanding on my end, but I know enough basic English to reproduce reasonable text.  I can even search and replace synonyms and alter sentence structure so that it isn't readily obvious where I got the information from.  It's a more efficient version of that.  --Jayron32 11:46, 3 March 2023 (UTC) @Cinadon36 It's impressive in many ways but, at least as of now, it generates fake sources and doubles down on them, including fake ISBN numbers and Google Books links if you keep pushing, even though the information it provides appears factual. Which is to say, it can answer even complex question with correct data (eg. what were some of the main economic reforms of Reagan's presidency?), but if you ask for where the information came from (eg. cite actual sources) the result will be made up. It can even use actual names of scholars and existing publishers to create a veneer of authenticity. So really dangerous for review process at this point. I have found it to be most useful for creating outlines and organizing existing thoughts into a clear format. Ppt91talk 22:52, 6 March 2023 (UTC) Yes, @Ppt91, I remember my frustration when I asked bot for references and handed me a couple of fake sources. But that was not my point. My suggestion was that we, WP, tell OpenAi to include only good articles of WP or above- just as an advice. As far as I can tell, current version of bot is not adequate to create context for article.Cinadon36 08:17, 7 March 2023 (UTC) @Cinadon36 Thank you for clarifying and I see your point now. I think that this is something worth discussing as OpenAi develops the project. Consider me involved as this conversation is moving forward. :) Ppt91talk 16:40, 7 March 2023 (UTC) I think we need to make template to disclose when ChatGPT or similar tools are used to write an article. Similar to automated machine transition, people need to be warn that they need to check the work before they post it and use that template to allow others to double check. we need to embrace it, similar to how scientific journals do it, see [https://www.infodocket.com/2023/03/09/journal-article-transparency-in-conducting-and-reporting-research-a-survey-of-authors-reviewers-and-editors-across-scholarly-disciplines/] AI is not an author it is a tool similar to Grammarly or MATLAB. 139.143.95.115 (talk) 09:28, 21 March 2023 (UTC) on "I would like to suggest, we, the WP, suggest to openAI to only include reviewed articles ie Good articles or better. " specifically, It's an interesting suggestion, but I think there's a risk this encourages gaming the system.  It's really not something that's within our control anyway, they can use any/all of the articles as they see fit. JeffUK 15:03, 28 March 2023 (UTC) In an RfC, when there are two choices and no consensus can be reached, we are left with no decision. If no consensus generally means we stay with what we had before, then at least we have something, but sometimes there is no established rule to fall back on and we are left with mixed usage. In that case, Wikipedia is inconsistent, looks sloppy, and nobody's happy. However, at that point we could ask another question to see if there is a consensus that either option is better than no decision, then a coin could be flipped or the closer could make a decision based on a majority rather than a consensus.  I proposed this in one case and the answer was that we don't do that here. I've been involved in several such RfCs on matters of style and Wikipedia remains inconsistent. I think either choice is often better than no choice. What think you? Has this been suggested before? Any other ideas? Thank you.  SchreiberBike | ⌨  23:45, 2 March 2023 (UTC)  No.  --Jayron32 13:20, 3 March 2023 (UTC) I cannot imagine why choosing a result that is not supported by consensus makes sense. A perfectly consistent Wikipedia is a mirage that will never exist. Forcing agreement won't help anyone. — Ixtal ( T / C )  ⁂  Non nobis solum.  13:33, 3 March 2023 (UTC) @Ixtal: No hope of forcing agreement or becoming perfectly consistent. Right you are. But we could hope to stop endless arguments between pedants who seem to prefer to argue rather than solve a problem. SchreiberBike | ⌨  23:03, 3 March 2023 (UTC) It is fine for Wikipedia to be inconsistent, because the real world is. WP:ENGVAR is a great example of Wikipedia choosing to be inconsistent over one of the several options. This is a feature, not a bug, as it helps Wikipedia align with the real world. —Kusma (talk) 13:54, 3 March 2023 (UTC) Could you give 2-3 examples of RFCs where you think this would have been a better outcome?  It would help to understand what you are wanting to see. ~ ONUnicorn(Talk|Contribs)problem solving 14:00, 3 March 2023 (UTC) @ONUnicorn: Two I've been involved in were: Should Wikipedia say "the Gambia" or "The Gambia" midsentence. There are good arguments for both. A recent RfC closed as "No consensus", so we have usage in articles and in article titles that goes both ways. For some people, especially some Gambians, this is a very important issue. It's been a low-key edit war for years. Several books worth of writing and editor time has been spent trying to reach agreement on the capitalization of universe in an astronomical context. Again, reasonable arguments can be made both ways and no consensus has been reached. Flipping a coin or picking an odd or even number in some lottery would resolve these and people would stop yammering about them for a while. Maybe people shouldn't care so much, but they do.  SchreiberBike | ⌨  22:12, 3 March 2023 (UTC) I found the RFC for (T/t)he Gambia, but I'm not finding the one for (U/u)niverse.  I can see Gambia being quite contentious.  For (U/u)niverse, however, I would think it would be more context dependent. For example "There are billions of galaxies in the Universe" seems like it's being used as a proper name, thus should be capitalized, whereas in, "Imagine a universe where the laws of physics were different..." it is not being used as a proper name, thus should be lower case.  I think your proposal might help provide clarity in a situation like (T/t)he Gambia, but it could also end up inflaming the situation, especially if Gambians feel strongly about it and do not feel their voices are being heard in whatever decision gets made.  I do not think your proposal would be appropriate for something as context dependent as (U/u)niverse, but I could be misunderstanding the debate there as I have not found the actual RFC. ~ ONUnicorn(Talk|Contribs)problem solving 16:45, 6 March 2023 (UTC) @ONUnicorn: The last one I tried for universe was at Wikipedia talk:Manual of Style/Capital letters/Archive 16#Capitalization of universe - request for comment, eight years ago. Wikipedia talk:Manual of Style/Capital letters/Archive index lists six more. The details you mention were covered and there was general understanding that if universe was to be capitalized, it would only be capitalized in some contexts.A common idea is that a rule is needed if there is disagreement among editors and editor time is being spent arguing about it. SchreiberBike | ⌨  03:45, 7 March 2023 (UTC) The obvious question is, what happens if there is, in turn, no consensus for either option being better than no decision? Gnomingstuff (talk) 16:05, 3 March 2023 (UTC) @Gnomingstuff: Then we are no worse off than we were before, but if there is a consensus that either option is better than continued inconsistency, it's a problem solved and Wikipedia is better, more consistent, more credible. SchreiberBike | ⌨  22:16, 3 March 2023 (UTC) Solution in search of a problem. Papers have actually been written about how our epistemically conservative consensus system is uniquely well-suited to resolving the presentation of conflicts. signed, Rosguill talk 16:19, 3 March 2023 (UTC) @Rosguill: As an example, imagine Wikipedia as a new country with a new transportation system. I doubt we could reach consensus that we should only drive on either the left or the right; would we continue to let people drive as they please with the resulting accidents and inefficiency? Neither right nor left is inherently better. I'm wondering if people are interested in finding a new way to solve long-standing problems that have not been solved by our consensus system, even if that system usually works. SchreiberBike | ⌨  22:25, 3 March 2023 (UTC) The obvious solution is for everyone to slow down enough that it does not matter which side they are driving on… sure it takes longer to get where you want to go, but there are no accidents. Blueboar (talk) 02:13, 26 March 2023 (UTC) The roads analogy is hyperbolic and doesn't really correspond to any situation on Wikipedia. signed, Rosguill talk 22:30, 3 March 2023 (UTC) Of course it's hyperbolic, but the examples I give above of The Gambia and universe correspond closely. We let people edit as they please resulting in argument and inefficiency. It makes Wikipedia look less professional, less consistent and less credible and it wastes our time.  SchreiberBike | ⌨  23:14, 3 March 2023 (UTC) It is a waste of time to attempt to enforce uniformity in stylistic matters that have no real importance. Given how poor our sourcing is in many areas, our credibility is arguably too high already. Note also that WP:ENGVAR, our deliberate inconsistency in using all kinds of different spelling systems does not seem to have caused any real world issues that I am aware of. Making decisions that go one way and possibly violate WP:NPOV is much worse than inconsistency. —Kusma (talk) 10:55, 4 March 2023 (UTC) @Kusma: Yes we have several deliberate inconsistencies (ENGVAR, DATEVAR, ERA and  SERIAL come to mind) and yes those do make English Wikipedia stronger. But we have also set standards in thousands of ways, that's largely what the policies and guidelines are, and those also make Wikipedia stronger. I can't see how having both History of the Gambia and Military history of The Gambia makes us better. (Unless it's good that it keeps people from taking what we write seriously.) SchreiberBike | ⌨  03:49, 7 March 2023 (UTC)There are times when it would be preferable to settle a dispute rather than continue it via no consensus, but they're few and far between. The recent WP:ACAS is a good example, and in that case the closers did basically as you suggest: reduce one of the questions to a pure headcount. My [well-documented at this point] position is that the headcount question was the wrong one -- that we should've come out of that slog with at least a definition of what we mean when we call about "mass creation" or the like instead of a strange, arguably redundant rule applying to an ill-defined concept. What makes it hard in a case like that are the entrenched camps and drama carried over from specific cases/people, coloring an important policy debate. There are specific cases when I feel like it would be a net positive to the community to either grant the closers slightly more leeway than usual to glean important conclusions from an otherwise messy discussion, or to find some other approach like you're describing. I certainly wouldn't support and policy/proposal that included relying on coin flips or headcounts, but there are other possibilities. For example (I tossed this out at the arb motions board), run the same RfC again but don't allow anyone who participated in the first RfC to !vote (talk page only). I think that would be worth a try sometime, despite the inevitable complaints. YMMV. — Rhododendrites talk \\ 23:07, 3 March 2023 (UTC)  @Rhododendrites: There are plenty of problem solving methods we haven't tried yet. What I'm suggesting is that if there is a consensus that people are willing to accept the results of some method besides consensus, we should specifically allow that. SchreiberBike | ⌨  03:52, 7 March 2023 (UTC)Adopt some form of Speaker Denison's rule: when you have no consensus, preserve status quo as much as possible. dwadieff ✉ 17:40, 6 March 2023 (UTC) @David Wadie Fisher-Freberg: Yes, we have a set of rules, which generally do amount to that. This would apply when there is no status quo. SchreiberBike | ⌨  03:54, 7 March 2023 (UTC) [3]. Phil Bridger (talk) 19:46, 6 March 2023 (UTC)I've notified Wikipedia talk:Consensus and Wikipedia talk:Closing discussions of this discussion. Thank you, SchreiberBike | ⌨  04:03, 7 March 2023 (UTC)   === Conclusion === I thought this was a good idea, but it has not gained support here and that's ok. I did find a similar discussion that went nowhere 17 years ago at Wikipedia talk:Manual of Style/Archive 24#Consistency. I still want to explore the idea and I'm considering opening an RfC at the Manual of Style talk page for capitalization asking something like:  Given that we've been unable to reach consensus on the capitalization of universe in many discussions [which I will list], is there a consensus that the results of a coin flip (or similar random choice) would be better than what we have now? Would I be acting in bad faith or forum shopping if I made that proposal there? SchreiberBike | ⌨  18:21, 14 March 2023 (UTC)  I think continue the discussion here, but change the title/create a new topic similar to- What should we do when Consensus cannot be reached when there are strong opinions on small changes? Wakelamp d[@-@]b (talk) 15:00, 27 March 2023 (UTC) In that sort of example, it depends on the question! "Do we capitalise [u/U]niverse in all cases", may get 'no consensus'. "Should we have a consistent capitalization for Universe" may get a strong consensus for 'Yes'.  You can then build on the conversation to define /how/ we determine which to use (i.e. "having agreed we should be consistent, let's use whatever the BBC uses"), and finally let that discussion determine the answer.  If the consensus is 'No' or 'Use the local consensus', 'Use whatever the sources use' etc.  then you also have a consensus. Ultimately,  it sounds like a lot of effort, and we don't require absolute consistency in matters of style anyway! JeffUK 16:00, 28 March 2023 (UTC) Hi! Curious if y'all think there are any aspects of editing where new editors may need more guidance/advice than what our current PAGs and explanatory essays provide, such as RFCs. — Ixtal ( T / C )  ⁂  Non nobis solum.  01:26, 3 March 2023 (UTC)  I'll suggest the opposite: there's too much guidance, and the way it's organized makes it really difficult for new editors to know where to start. Thebiguglyalien (talk) 05:04, 3 March 2023 (UTC) Thebiguglyalien, that's also very useful insight. How do you think we can improve the organization of the guidance? Any particular areas of concern? — Ixtal ( T / C )  ⁂  Non nobis solum.  10:19, 3 March 2023 (UTC) I'll second Thebiguglyalien's comment: too much "stuff", poorly organized. We can expect editors to go through Help:Introduction. But practically no one reads Wikipedia:Contributing to Wikipedia or any of those pages (I certainly didn't). They're both too basic and too verbose, making them pointless, while far less prominent pages, like MILHIST's Academy or userspace essays, are more useful by a mile. Nobody reads a manual before driving their new car; our help pages shouldn't try to address everything, they should focus on frequently asked questions, like how to copy edit (with specific guidance and examples), and how to find high-quality sources (too bad we can't just link out to LibGen/Sci-Hub, but people can still find tons of books/papers for free on the web or archive.org, yet most don't know how to). DFlhb (talk) 11:54, 3 March 2023 (UTC) DFlhb, I personally found the MILHIST academy very useful. Have there been proposals to model the site-wide guides after the MILHIST academy? — Ixtal ( T / C )  ⁂  Non nobis solum.  22:08, 9 March 2023 (UTC) Ixtal, I had the exact same thought, but never acted on it. Feel free to run with it. I added further thoughts on that page I just linked. DFlhb (talk) 22:50, 9 March 2023 (UTC) @DFlhb Maybe we need a new space called history/archive that we move all the old/duplicate stuff to. (I didn't know that the milhist academy exisited. Wow. ) Wakelamp d[@-@]b (talk) 15:14, 27 March 2023 (UTC) The Wikimedia Foundation's Growth team has been providing very brief bits of information.  The Editing team's new WP:Edit check will do more of the same, but right inside the visual editor, based on what the editor has typed. One thing I haven't seen during the last decade is someone sitting down with Special:RecentChanges and figuring out what kinds of edits brand-new registered editors are making.  Are people creating accounts to add paragraphs or to fix typos?  The last time this was done, brand-new accounts could create articles in the mainspace (the Draft: space didn't exist then), and creating a new article was the first edit made by a quarter of accounts. Whatamidoing (WMF) (talk) 16:48, 14 March 2023 (UTC)I'll third Thebiguglyalien's comment and add to and expand on it. "Too much" "not organized" "unvetted" "with no navigation (which for a newbie means  "hidden")".  One suggestion: add a "Getting started at editing"  link lower down on the main page and have it land at a highly vetted / lots of eyes main navigation page for newbies.  And direct links from it only to highly vetted pages.  North8000 (talk) 18:11, 14 March 2023 (UTC) This is an idea related to Wikipedia:Administrators' noticeboard#A plea: Propose a better solution, and before I actually propose it I'd like to workshop it a bit here first to see if it actually has legs and if there is anything obvious I'm missing. I think a small improvement we can make to the community processes around CT/GS, both at AN/ANI and in content discussions is give uninvolved administrators the tools to enforce a formalized discussion structure when they see a need. This could be a benefit in long, drawn out ANI threads that may have been better suited to AE, but have grown too large to move to that venue, or in RFCs and content discussions which are clearly generating heat to prevent them from igniting. Tools to step in and prevent bludgeoning, unconstructive back and forths, and sprawling, unreadable clusterfucks will make it easier to attract uninvolved closers, keep heated discussions focused and on-topic, and keep editors from crossing lines that may lead to sanctions. Hat tip to Tamzin for writing up most of the following legalese, although I've made some changes.  Any uninvolved administrator may take reasonable actions to structure a discussion in any area designated as a contentious topic or under community general sanctions, included but not limited to requiring section based (rather than threaded) discussion, imposing maximum word limits, and closing a discussion that has become unconstructive pending uninvolved closure. Administrators may enforce such restrictions using admin tools if necessary. Decisions can be appealed to the administrators' noticeboard. The administrator could pick and choose how to structure the discussion, and not every remedy would be needed for every discussion. Sometimes just limiting those taking part to 500 or 1000 words would be enough, and there are other times when strictly enforcing sectioned discussion with word limits would help the situation. For an RFC or topic ban discussion, enforcing a structure where only !votes of up to 200 words are allowed under Option A, Option B,  and Option C, and discussion may be threaded, but editors are restricted to 500 words may be enough to keep a dumpster fire from flaring up. Hopefully this would also serve to encourage editors to think carefully about their response, and have their supporting evidence ready at hand when responding. There's also a large benefit in seeing that a discussion is over-cooked, and stopping it at that point, even if you don't have the time to close it yourself at that point. Generally, the longer a discussion is open after it's well done the more acrimonious it becomes, which only serves to harm the community. This is not a large change, and it won't solve all of the problems with CT/GS discussions or ANI, but small changes are easier to implement, and any improvement is an improvement. Any input on this would be appreciated, and if it seems well received I'll make an actual proposal at WP:VPP. ScottishFinnishRadish (talk) 12:34, 6 March 2023 (UTC)  Yes, please. Questions that would need to be answered: User:NoWords4U implements a 200 word / 10 diff limit on a given conversation. User:IHave11Diffs wants to post 11 diffs. Would any admin or just NoWords4U be able to grant said request (i.e., would granting extensions count as modifying a sanction)? Also to be considered: how would !votes on resolutions work? At AE, there is a section for patrolling admin comments; would there be something like this for everyone? For only uninvolved editors? Any of the above, depending on what an admin decides? HouseBlastertalk 15:26, 6 March 2023 (UTC) As far as granting extensions, I don't see a reason why any uninvolved admin wouldn't be able to do so. As far as closing, it would depend on the specific structure implemented by the uninvolved admin, but I don't see most of the discussions needing specific admin closure. The aim isn't to make it exactly like AE, it's to enforce enough structure to keep the discussions constructive and on point. An admin enforcing a structure could say that those responding to the discussion must declare in their section header if they are previously involved. The hope is that it would be a broad toolset so an admin could enforce the structure that best fits the situation. ScottishFinnishRadish (talk) 16:22, 6 March 2023 (UTC) I dislike the idea of implementing word or diff limits; sometimes editors need more space for their statement, and the issue resolves itself because the longer a statement is the more likely it is to be ignored. BilledMammal (talk) 15:45, 6 March 2023 (UTC) Is the idea to propose these as general sanctions so that there would be a presumption against overturning once implemented or to be resolved through the normal ANI/AN method of actions that sometimes get undone (and redone)? Best, Barkeep49 (talk) 15:59, 6 March 2023 (UTC) I'm a bit up in the air about that, but I think it would be more effective as a general sanction, so that if there is an issue with the structure it has to be discussed at AN rather than changing the discussion parameters another time, possibly unnecessarily. ScottishFinnishRadish (talk) 16:25, 6 March 2023 (UTC) I think a change like this should be a community-approved addition to the standard set of page restrictions, and so appealing would require following Wikipedia:Contentious topics#Appeals and amendments. (From an implementation point of view, I think it would be simplest to modify the contentious topic page directly to include this, but if for some reason the arbitration committee objected, it could be added to Wikipedia:General sanctions as a community-approved supplement.) isaacl (talk) 17:33, 6 March 2023 (UTC) It would take an ArbCom motion for the the Contentious Topic standard set of page restrictions to be modified. Best, Barkeep49 (talk) 19:40, 6 March 2023 (UTC) Even if the community places a general sanction that applies to any topics on the CT list? ScottishFinnishRadish (talk) 19:45, 6 March 2023 (UTC) Even if, as the community cannot directly modify the Contentious Topic procedures. So someone could either ask the Committee to do it or it could be done as a community General Sanction. If you're going to ask the Committee to do it after an RfC, I would recommend (and this is me speaking only for myself) making sure that's noted when people participate in the RfC. Historically the committee has been reluctant to take something the community has passed over without some reason for doing so (such as part of a larger case). This reluctance is why the committee has tried to provide the community a way of aligning its GS with the Contentious Topics procedures so that the community could use AE for its GS. But ultimately that remains an option and the community can decide it doesn't want to align with the GS it passes (and so far hasn't chosen to re-align any existing GS). Best, Barkeep49 (talk) 20:09, 6 March 2023 (UTC) There are enough other big conversations in which editors want to engage that I suspect the current status quo (where a clerk already modified the General sanctions page to say "... when the community designates a topic as a contentious topic") will be considered good enough for the near term. isaacl (talk) 22:42, 6 March 2023 (UTC) I think SFR is proposing it be done as a general sanction. That is, we "make a rule" that says something to the effect of "Admins may do [the things outlined in this proposal] to discussions related to topics that are listed here" I believe this would be within the purview of the community, though I definitely agree it would be much easier if ArbCom passed a motion affirming the result of the RfC if it is successful. HouseBlastertalk 23:20, 6 March 2023 (UTC) Yes, I know and I agree. I feel the arbitration committee would see benefits in keeping the standard set of page restrictions in one place, rather than having them split across the Contentious Topics page and the General sanctions page, and thus would be willing to pass a motion, but if it disagrees, then it can be split up. isaacl (talk) 22:35, 6 March 2023 (UTC) I think @ScottishFinnishRadish hit the nail on the head: small changes are easier to implement, and any improvement is an improvement. I am strongly in favor of introducing a more efficient structure, even if it's through trial and error, because the issue is urgent. I've said this in the original thread and I feel strongly about WP:WALLOFTEXT editors at ANI who often don't even edit in GENSEX. We're technically not a bureaucracy but somehow it's precisely the shortcomings and endless complications of certain bureaucratic processes that makes this entire process more challenging for many editors who work on some of the most emotionally and intellectually taxing areas of en-wiki (and many of whom already feel very disenfranchised in the real world). Ppt91talk 19:36, 6 March 2023 (UTC) The administrator could pick and choose how to structure the discussion not a fan of this, also not necessarily a fan in general - I feel this is a bit of a last resort thing. Controlling a discussion aggressively is often equivalent to controlling its outcome. Would far prefer a canned set of solutions chosen to limit this effect, and less invasive constraints like "we won't talk about this for a while". Also do we know what works? And are we sure the community actually needs coercion rather than a good model? Talpedia (talk) 22:09, 6 March 2023 (UTC) Personally, I don't feel choosing a discussion format is equivalent to aggressively controlling a discussion. I appreciate some formats may be less appropriate for certain types of disputes, thus I think it's good that the proposal is providing flexibility for an administrator to decide upon a suitable format. I'm not sure that a canned set of solutions is less invasive than setting a format for discussion, and in particular, a single person deciding that the community won't talk about something for a while feels like a very controlling approach. isaacl (talk) 22:58, 6 March 2023 (UTC) Not equivalent... more potentially enables in the absense of limits. Not talking at least doesn't reach a *conclusion*. I might read up / summarize some literature on influence in meetings for clarity. Talpedia (talk) 10:37, 7 March 2023 (UTC) IMO probably only about 2% of Wikipedians and 5% of admins could successfully execute that role than you describe. IMO unless you could identify the 5% I think this would do more harm than good.  Sincerely, North8000 (talk) 22:51, 6 March 2023 (UTC) This feels to offer quite a lot of control to any individual admin and could be a somewhat de facto change to ANI format for CT topics if used with a significant level of frequency. What would be the mechanism should admin A decide to bring in said rules for a discussion and others (editors or admins) disagree with them? Other qs - the proposal suggests that this will be used for complex/scrawling discussions - would they only apply to comments made post-addition? That could potentially be imbalanced. However, something like rate limitation I could see being of more used than word/diff-count or, more drastically, sectioning. I'd also have zero issue with an obligation to disclose involved status - I think that last one would be a good general AN/ANI rule. Nosebagbear (talk) 00:21, 7 March 2023 (UTC) section based (rather than threaded) discussion Ugh, no. Have you ever tried to go back and read a "discussion" that was held that way? It's nearly impossible to get any idea of what the actual discussion was. It only works for Arb cases because mostly everyone is talking to the Arbs, and the Arbs have their own threaded discussion on private mailing lists, and because few ever read those "discussions" after the fact (the final decision is the important part). imposing maximum word limits Seems like another measure to shut down discussion rather than to encourage better discussion. Which side has more editors, to have a higher word limit? Will we have people going back to delete their old comments to be able to make new ones, further hiding the actual discussion from anyone who hasn't been following it in real time? Anomie⚔ 13:37, 7 March 2023 (UTC)Just on the word count limit thing, and I express no opinion about any other aspect of this proposal -- word counts are meant to keep the matter readable and to ensure that one or two passionate editors don't drown out everyone else with long conversations.  I get that.  But they're a significant barrier for uninvolved people to participate.  My admittedly limited experience with Arbcom is that I don't know how many bloody words I'm going to need and I always want to have some in reserve in case I need to answer other editors anyway.  I find word count and diff limits a significant stressor.  A much better rule would say "be as succinct as possible" and enforce that with clerking by uninvolved sysops.—S Marshall T/C 19:14, 7 March 2023 (UTC) I realize this may sound snarky, but how would clerks enforce succinctness without word count limits? Donald Albury 19:29, 7 March 2023 (UTC) Well, you'd have to read what they typed and form a judgment call.  Isn't that what sysops do?—S Marshall T/C 22:29, 7 March 2023 (UTC) I'm sorry, I don't recall that my access to the tools gives me the power to officially determine who is being succinct and who isn't. (And now, I am being snarky.) Donald Albury 01:26, 8 March 2023 (UTC) Sysops routinely officially determine who's being disruptive and who isn't.  Sysops routinely officially decide when someone's engaged in undisclosed paid editing, and block them despite their denials.  You can find the consensus in an unstructured and undisciplined discussion.  You read text and decide what's fair and what's out of line, and thereby keep the encyclopaedia running smoothly.  If you say to me that you can't read a textual conversation and tell who's being succinct and who isn't, then okay, I believe you.  But *I* can and I don't think it's a difficult thing to do.—S Marshall T/C 08:52, 8 March 2023 (UTC) I don't know, I feel like making it a judgement call would allow too much bias to creep in. This whole discussion was triggered by dysfunction in the GENSEX area, which is an area rife with all kinds of different biases. In the last few ANI cases from that topic area I saw several people go after the accused editor for "bludgeoning their own ANI case". Whether you think that's the truth or not, I strongly believe that's exactly the kind of situation we need to avoid, because it is both an accusation that is really hard to fight back against once you've received it and entirely subjective. A word limit with limited extensions would avoid that pitfall a little more efficiently. Preferably, those extensions would have to be granted based on something other admins can verify.   --Licks-rocks (talk) 09:28, 8 March 2023 (UTC) Well, we're writing an encyclopaedia.  So our job is to read the sources and summarize them.  We explain complex and difficult matters in simple, clear words.  That's an academic discipline, called precis, that I and many other editors my age were taught as part of our English studies in grammar school.   And with all due respect, it's easy to know what's brief, simple and clear and what isn't.  Any fool can tell when people are repeating themselves, and the other aspects of "brief, simple and clear" are objectively measurable with Flesch-Kincaid tests.  There are websites where you can paste disputed text and get the Flesch-Kincaid score as a number.My favourite example of horrible prolixity and slack precis skills in text is our Wikipedia article on Attention deficit hyperactivity disorder.  Its Flesch-Kincaid score suggests an audience of professionals educated to at least college degree level who are fluent at reading technical language.  It's like they designed it to be incomprehensible to ADHD sufferers.Anyway, being brief, simple and clear is a core skill for anyone who edits text and it shouldn't be hard for any encyclopaedist to construct a brief, simple and clear explanation of their position.—S Marshall T/C 08:56, 9 March 2023 (UTC) I think the main skill in arguments is having been in enough discussions to know when arguing more doesn't help your case... unfortunately that can depend on who you are talking. Talpedia (talk) 10:11, 9 March 2023 (UTC) I've only skimmed this proposal, but I'd like point out one advantage of word limits vs clerking; they can't be construed as favoring one side or the other.  In a heated debate, it's good to have strict rules, uniformly applied.  Otherwise, you risk somebody saying, "You let the other guy say more, why won't you let me say more?", and then you're down that rabbit hole.  What arbcom does seems to work: you start with a fixed limit and if you run into that, you can ask a clerk for more.  That still brings human clerking into play, but at least the first barrier is a fixed number. -- RoySmith (talk) 19:34, 7 March 2023 (UTC) I think it's unavoidable that people will (inaccurately) construe CT-enforcing sysops as favouring one side or the other.—S Marshall T/C 22:29, 7 March 2023 (UTC) I think a system like this would need clear rules around when and how it is being/able to be enforced. for example, different tiers of enforcement depending on topic area or subject matter. (e.g. "random vandalist IP #2989 active again" probably doesn't need the same level of structured discussion as a highly controversial topic in the GENSEX area does.), ranging from none at all to the AE like format Billedmammal proposed here. I think under those conditions, this would form a massive improvement to the way things currently work at ANI. I don't think it's a way of shutting people up, I think of it more as enforcing WP:COAL by force. That doesn't sound too bad to me. As for word limits: I think they're fine as long as people get an extension they can use.  ----Licks-rocks (talk) 19:52, 7 March 2023 (UTC) This was my first thought as well. Any reforms or measures that we consider can't be one-size-fits-all. Thebiguglyalien (talk) 01:42, 8 March 2023 (UTC) I can generally support this, as it doesn't propose diff limits. That would be a major failure point.  Much of the back-story of this proposal is that the earlier proposal was to force all GENSEX ANI reports to AE, but AE is poor for establishing long-term patterns of abuse because of AE's diff limits and AE admins' general hostility to evidence that is not brand new (AE is only good for evidencing and stopping recent "flare ups").  — SMcCandlish ☏ ¢ 😼  22:38, 7 March 2023 (UTC) I think one discussion format that may be helpful in some cases is a round-robin discussion phase, where each contributor can make one comment until a moderator decides the next round of comments should start. The moderator would also decide when the round-robin phase ends. This would help prevent rapid escalation of contentious statements, and give everyone a chance to weigh in before the next round of responses. isaacl (talk) 18:18, 8 March 2023 (UTC) The complaint that AN/I is awful, unworkable, untenable, dysfunctional and a terrible stinking mess is one that I've been hearing pretty much the entire 18+ years I've been editing here, and yet AN/I goes right on sanctioning those who need to be sanctioned, not sanctioning those who don't, warning people when they need to be warned, and -- in general -- getting the job done pretty well.  True, it's messy, it's sometimes hit-or-miss, things slip through, and there are aspects of it which are as annoying as all get out, but the same can be said of any semi-democratic process which involves large numbers of people.  It really doesn't need a lot of "fixing", and it certainly doesn't need to be "fixed" in a way that makes it work like AE or any other process.  AE works because -- although anyone can comment -- it's pretty much functionally limited to a smaller population of edits, the admin corps, and in actual fact, to a much smaller group of admins who bother to participate there.  I would oppose any change to AN/I which would involve forcing structured discussion of any kind.  That doesn't mean that I think that there's nothing that can be done to improve AN/I, just that an attempt to force it to be something it isn't seems to be to be a bad idea. Beyond My Ken (talk) 23:56, 11 March 2023 (UTC) The intent isn't to change ANI entirely. For the most part ANI does a find job of handling actual incidents. The intent is to, when the need arises in any discussion, implement some structure to keep a discussion productive. ScottishFinnishRadish (talk) 15:35, 13 March 2023 (UTC) Thanks SFR for splitting this out to discuss. I've gone back and forth on this, but I think ultimately it doesn't really successfully address the issues with ANI, or rather introduces a bunch of unwanted additional issues. Randomly empowering random admins to reformat or structure discussions the way they see fit is going to feel even more arbitrary or random than discretionary sanctions/general sanctions feel now, especially to newer users. I think for it to work, there'd need to be a much clearer and documented process, or something that kicks in automatically. Der Wohltemperierte Fuchs talk 15:29, 13 March 2023 (UTC) I thought about triggers, so that it would kick in in certain circumstances, but that's exceedingly difficult to try and nail down. It's a lot easier to recognize that something has become, or is in the process of becoming, a quagmire, or dumpster fire and trying to head off the likely escalations. All in all, it's a tough situation to deal with because the arbitrary nature is a problem, but so is trying to write up a bunch of if statements to meet the threshold for deciding that unlimited threaded discussion isn't the way to handle a discussion that is quickly going off the rails. ScottishFinnishRadish (talk) 15:34, 13 March 2023 (UTC) No. This is basically to enable Admin-rule on discussions where they have a significant conflict of interest or such a strong point of view they will effectively be given licence to suppress opposition they dont like. Pretty it up how you like, but this conversation (and the discussion at AN) has come about because the "wrong person" ended up sanctioned and some people dont like it. Which is a terrible basis for a change in procedure, a change explicitly to prevent the same thing happening again. Only in death does duty end (talk) 12:15, 15 March 2023 (UTC) Oppose. For the exact reason given by Only in death. The ANI that inspired the idea proposed here is an ANI where an editor considered to be "fighting the good fight" in favor of transgender causes had violated Wikipedia policies and community guidelines more than once, had received warnings, but continued to push the envelope until it could no longer be tolerated. If you read some of the comments in that ANI, editors who supported a topic ban based on the diffs provided, including editors who had a history of dealing with said editor, were accused in general of being "out to get" that editor by some who were comrades of said editor, and the ANI was a weapon being used to prevent this person from contributing to transgender-related articles — because of course, in their eyes this editor was a warrior who could do no wrong. Gensex articles are going to draw contentious editors and contentious editing because they attract too many activist editors with personal agendas. Pyxis Solitary  (yak yak). Ol' homo. 10:46, 20 March 2023 (UTC) I support this and furthermore think it's probably a better solution than the previous two suggestions. I think that being able to "cool down" a discussion like this will do a lot to cool down bad drama-based ANI bans while not having much effect on good ones. Loki (talk) 00:53, 20 March 2023 (UTC) I feel Wikipedia's gotten far too conservative, and there's far too much inertia for anyone trying to make any improvements. Why not try this, or try the suggestion below, for a single CTOP and for a limited duration (a few months), and then reflect? When did we get so risk-averse? We need to restore a culture of experimentation: run trials, analyze, iterate. DFlhb (talk) 16:49, 27 March 2023 (UTC) This, 110%. Our "if it ain't broke..." culture is detrimental to the development of Wikipedia. We do not protect FAs because they are "ain't broke" to prevent them from being "fixed". Sure, FAs may be small-g good articles, but that doesn't mean we shouldn't try to make them even better. Same thing with our PGs/norms/practices: experiment, and see what happens. Things that are commonplace and (I believe) widely seen as Good Things had "there is no problem" opposes. Then the change happened, and Wikipedia was made better. To name a few, in no particular order: de-mopping inactive admins (e.g. opposes 2, 6, 8, 16), introducing rollback (e.g. opposes 79, 88, 115, 120), letting 'crats remove the mop (e.g. opposes 1, 2, 3, 5, 6, 9, 10, most of the others), and ACTRIAL (e.g. the 101 people who supported the linked proposal by Ironholds).Heck, from WP:5P5, "Wikipedia has policies and guidelines, but they are not carved in stone; their content and interpretation can evolve over time". Can we please let them evolve? HouseBlastertalk 19:04, 27 March 2023 (UTC)   === 5Day Limit at ANI === User:Tamzin has asked us for ideas (back at WP:AN) on how to deal with reports at WP:ANI.  I have a proposal that does not involve ANI reform in the usual sense. I suggest that any thread at ANI that involves a contentious topic that is still being discussed after 5 days should be closed and transferred to Arbitration Enforcement.  The ArbCom is intended to adjudicate disputes that the community cannot resolve, because the dispute divides the community.  A contentious topic dispute that is still being discussed (argued about) after nearly a week is a recurrence of disputes that divide the community and have been delegated by ArbCom to Arbitration Enforcement. This doesn't involve reform of WP:ANI in general, and doesn't prevent the community from dealing with trolls, flamers, or other editors in contentious topic areas who are clearly not here to contribute to the encyclopedia.  It would identify cases that have been misfiled and are known to be Arbitration Enforcement cases.  Robert McClenon (talk) 16:29, 17 March 2023 (UTC)  @Robert McClenon: Given that a siteban proposal takes 72 hours (except in SNOW cases), and it usually takes a bit of time to get to the siteban proposal, do you think that this would effectively hinder the ability of the community to siteban bad actors as a community sanction? — Red-tailed hawk (nest) 17:36, 17 March 2023 (UTC) User:Red-tailed hawk - That's an interesting valid concern, and illustrates why brainstorming here is useful.  Perhaps the proposal should be for any thread at ANI that is still being discussed and is not considering a siteban.  After all, my stated intention was not to prevent the community from dealing with trolls, flamers, and similar bad actors, and trolls and flamers are often banned.  The objective is to identify ANI threads that are going nowhere and send them to AE, as opposed to those that the community can handle.  Robert McClenon (talk) 19:06, 17 March 2023 (UTC) 5-day limit? No. Sometimes it takes a few days for an editor to find out there's a discussion at ANI about a problematic editor. Limiting ANI discussions to 5 days will become a way to keep editors who aren't attached at the hip to ANI from participating in discussions they would have otherwise become involved in. Pyxis Solitary  (yak yak). Ol' homo. 14:11, 18 March 2023 (UTC) Making ANI into arbom-light could be a good idea. Some of the same methods used at arbcom could be translated into an ANI version, that is less restrictive. arbcom has time limits, but 5 days is actually more restrictive than arbcom. -- GreenC 14:19, 18 March 2023 (UTC) While I'm not entirely opposed to the idea of a time limit, I think it'd need to be a lot longer than five days. ANI is sort of a double-edge sword: it overreacts to drama stuff without a clear policy violation, but it also is noticeably better at dealing with cases of long term bad behavior without a clear policy violation (like  civil POV pushing)... unless the person in question is just randomly popular, in which case AE is a lot better. The TL;DR of all that is that time or contentiousness alone is not really the concern here. Loki (talk) 00:49, 20 March 2023 (UTC)Again, Oppose any transferring to AE as an means of cutting out community involvement. Only in death does duty end (talk) 15:46, 20 March 2023 (UTC) I may not have been clear that I was only proposing an ANI time limit on discussions that involve a contentious topic.  I was not proposing to close down discussions after 5 days if there is no other forum.  Robert McClenon (talk) 16:17, 21 March 2023 (UTC)I would support such a proposal, although with a longer limit. I'd say 7 days seems a bit less restrictive, and interested editors can still comment at AE. — Ixtal ( T / C )  ⁂  Non nobis solum.  16:52, 21 March 2023 (UTC)Opposed - I don’t have a problem with an admin closing an ANI thread they think is just going in circles or is otherwise unproductive, but I don’t think we need to put a firm time limit on the discussions.  Sometimes it just takes longer for an issue to be resolved. Blueboar (talk) 17:33, 21 March 2023 (UTC) Support. Five days is enough. This does not put a time limit on a discussion. Editors are able to comment at AE. And support modification that there should be no referral to AE if a cban has been proposed during this period; but if the cban discussion resulted in no consensus (not consensus not to ban): yes, refer automatically to AE. —Alalch E. 11:29, 27 March 2023 (UTC) The idea of a "minor edit" in Mediawiki (the software that runs Wikipedia) is a design mistake. Mediawiki should remove it entirely so that all traces of it are gone except for historical purposes. The problems with "minor edit" are manifold:  the distinction between a minor and a non-minor edit is arbitrary and up to the user to decide the user is often unsure themselves how they'd classify their own edit other editors might (and would) often disagree obvious minor edits are often forgotten to be marked as such bigger edits are occasionally marked as minor (eg when an editor initially made a small edit but then went bigger) bigger edits might intentionally be marked as minor eg by vandals it's a bit rude to make people who like to copyedit constantly call their efforts "minor"The idea that users can self-report edits that don't require review is outlandish. If anything, it'd be much smarter to allow users to flag edits that they think require review. But I think that all edits require review so the benefits of simplification of the editing process outweigh the pros of adding such flags. Of course there should be a "bot" flag and possibility others. I'm not saying flags are not needed at all. Just that our current usage of "minor edit" is pointless and needs major reconsideration. Jason Quinn (talk) 02:22, 9 March 2023 (UTC)  For reference, Wikipedia:Village pump (proposals)/Archive 177 § RfC: Disable minor edits on English Wikipedia is I believe the last large discussion on a similar proposal, where it was suggested that only rollbackers, admins, and bots should be able to flag an edit as minor, and by policy only when reverting vandalism. isaacl (talk) 02:39, 9 March 2023 (UTC) I tend to agree with the editors in that RfC who pointed out that, while the minor flag is a weak signal when applied by a new user, it is more helpful when coming from an editor you know and trust. Barnards.tar.gz (talk) 08:41, 9 March 2023 (UTC) Thank you for bring that past RfC to my attention. I have to say that RfC appears to have been poorly made. Literally no rationale was given leaving some to oppose with (meritorious!) "why?" comments. Plus in the absence of an argument to set the focus, many people brought an array of views that perhaps missed the point. It was also perhaps not the best idea to have two somewhat orthogonal concepts mixed together. A dissatisfying RfC for me. And kind of disheartening because it will affects and anchor future discussions like this one forever. Jason Quinn (talk) 14:41, 9 March 2023 (UTC) As per RfC standards, the proposer started it with a neutral question. They then placed the rationale in their support statement. I wouldn't worry too much about long-term after-effects. Editors were commenting on how useful they found the minor edit flag; I think a discussion now or in the future will continue to be based on their experiences up to the point of discussion. isaacl (talk) 17:12, 9 March 2023 (UTC) Some editors find it convenient to filter out long strings of humdrum edits (e.g. dash fixing with AWB) from contribution histories. Additionally at a recentish discussion about disallowing non-autoconfirmed users from marking edits as minor there was significant pushback because some participants felt it made vandals/spammers easier to identify as they often mark all their edits as minor. 74.73.224.126 (talk) 04:34, 9 March 2023 (UTC) I agree with that last part. Maybe even making it an extended confirmed-only function ... Iskandar323 (talk) 07:27, 9 March 2023 (UTC) There should be ways to filter out bot edits. I don't buy the experienced vs inexperienced editor arguments. I've been using the minor edit checkbox now for almost 20 years. I think it does cause editors to skip reviewing some of my edits. But I'd rather they did. My editing is not infallible and I too introduce occasional errors by mistake. I wish more eyeballs would review my edits. Maybe it's best if I don't mark my edits as minor anymore. Jason Quinn (talk) 14:41, 9 March 2023 (UTC) @Jason Quinn both recent changes and watchlist have a built-in hide-bots option already. — xaosflux Talk 14:45, 9 March 2023 (UTC) Hi, xaos. I know. My comment was intended to suggest that some kinds of filtering are valuable and we need to remain able to do it even if we remove the minor edit flag. I didn't mean to imply by "should be" that no such filtering currently exists. Jason Quinn (talk) 15:11, 9 March 2023 (UTC) I would support its removal. I don't find it useful to screen out minor edits from my watchlist because it's too frequently misapplied. If it wasn't available, it would do away with user talk page and drama board kerfuffles about its misuse. From the viewpoint of a new editor, I would think "minor" meant I wasn't making a "major edit", which is the wp-wrong way to interpret it, so that's confusing. I think any perceived benefit to watchlist screening is negated by both unintentional and intentional misuse. Schazjmd (talk) 14:58, 9 March 2023 (UTC) It took until I first ventured out of mainspace for me to realize that "watch page" wasn't the inverse of "minor edit". I also had no confidence in my contributions. So for 10 years I dutifully marked "watch page" for every edit that wasn't trivial c/e in the belief I was alerting "admins" to additions that needed reviewing. I found out even more embarrassingly recently that the star symbol wasn't a "like button". When I finally discovered my watchlist it already had like 800 articles... JoelleJay (talk) 00:40, 29 March 2023 (UTC) I never mark an edit minor for reasons stated. Marking an edit minor is to discourage the need to verify, which contradicts how Wikipedia operates. -- GreenC 14:59, 9 March 2023 (UTC) @GreenC never say never?  I'm assuming you didn't manually click minor - but that is the type of "minor" edit that I think is still useful to filter. — xaosflux Talk 15:33, 9 March 2023 (UTC) I ceased marking edits as minor after being informed I wasn't following the "guidelines". Ah, okay. Why bother? Praemonitus (talk) 15:39, 9 March 2023 (UTC)I find it a useless feature, but apparently others do not.  Useless to me, harmless across the board, and useful to somebody means there's no good reason to get rid of it.  --Jayron32 15:41, 9 March 2023 (UTC) My thoughts are in agreement w/ Jayron. I do mark some edits as minor (e.g. removing unnecessary line breaks), tho. — Ixtal ( T / C )  ⁂  Non nobis solum.  22:06, 9 March 2023 (UTC) There will always be people who think something is useful given a decent size user base. So "'Useful to somebody' implies a feature should be kept" is a very poor standard for software maintenance and development. It would effectively never removes anything and just allows cruft to accumulate. Instead software developers should constantly be asking, "Is this the way it it should be?". Plus, you are neglecting the negative effects of cruft on the rest of users. If a feature is useless to most but useful to a few, that does not mean it is harmless. Every UI element or every step/option in workflow adds complexity and that very complexity affects the usability of software. The minor edit option is something encountered upon first edits and adds yet another reason why a first time editor might get the "I don't know what's going on here" feeling and abandon their try. Plus it takes up space, and clutter is bad. Jason Quinn (talk) 10:25, 11 March 2023 (UTC) I support it being removed.  I don't bother ticking the box myself because I don't see any value.  Likewise, I ignore it when looking at other people's edits.  From my experience at WP:SPI, I see it mostly used by miscreants as an attempt to avoid scrutiny.  -- RoySmith (talk) 17:17, 9 March 2023 (UTC) Perhaps instead the Pareto principle should be applied and we have check boxes for the top 3-4 edit categories? For example: fix spelling/grammar, add/repair link(s), warning tag(s), citation change(s). Praemonitus (talk) 18:14, 9 March 2023 (UTC) This exists on the mobile app: they have "fixed typo, fixed grammar, added links" as buttons. Natg 19 (talk) 04:00, 29 March 2023 (UTC) Misuse seems like something that would be easy to make backfire, at least sometimes. Couldn't we have a bot or somesuch that highlights edits that have a large byte difference but which are flagged as minor?  That seems like a red flag for vandalism. Obviously that won't help when someone flags subtle date vandalism as minor, but it'd still be useful as far as it goes. EDIT: Blueboar has elaborated on this below; but we could automate it to an extent by somehow highlighting large edits that are flagged as minor, since that's a contradiction that bears further scrutiny. --Aquillion (talk) 19:37, 9 March 2023 (UTC) I find it useful - but for reasons that are exactly the opposite of the tags intended use.  So many vandals and SPA editors check it (in an attempt to hide their nefarious/problematic edits) that I have learned to pay extra scrutiny to anything tagged as “minor”.  In short the tag is a great way to identify nefarious/problematic edits. I would hate to lose that. Blueboar (talk) 19:19, 9 March 2023 (UTC)I'll skip over minor edits (by editors I trust) when reviewing a page history or on my watchlist, it saves me time. I flag my own minor edits as minor for the same reason. The list of problems can be summarized as sometimes people make mistakes with minor edits, or sometimes they don't use them as intended, or sometimes these edits start arguments. This is also true for non-minor edits. I don't think we should get rid of either. Levivich (talk) 19:24, 9 March 2023 (UTC) The flag is useful but its name may be confusing.  The definition of minor edit, whilst useful and correct, is not the obvious meaning of that term.  For example, per WP:ME, "reversion of obvious vandalism" is a "minor edit", but I wouldn't class unblanking a page as minor.All registered editors can mark their edits as minor.  Should this be a revocable privilege, issued by default to all (or [auto]confirmed only) but removed from those who abuse it? Certes (talk) 22:04, 9 March 2023 (UTC) That's an interesting idea, about making it a permission. Also, maybe rename it to "routine edit"? Levivich (talk) 04:29, 10 March 2023 (UTC) I would support it being removed. It confuses me when I put in a new edit. And if I am making a lot of minor edits for cleanup purposes, I have to remember to check the box every time, which I don't because it's just another check box I have to check. Born25121642 (talk) 23:09, 9 March 2023 (UTC) I think of the "minor edit" feature as something like an easily accessible edit summary and just as reliable as edit summaries in general. I would support removing all "hide minor edits" features from the default view, as whether an edit is marked as minor says nothing about whether it is minor. Better to rely on software detection than on user self reporting. —Kusma (talk) 10:47, 11 March 2023 (UTC) I think this hits the key point.  If we don't automatically hide minor edits, then none of the concerns of 'people using it to hide vandalism' will apply.  Is there anywhere that we do hide 'minor' edits automatically? JeffUK 22:40, 28 March 2023 (UTC) Agree, It's really pointless other than filtering. (which should really be an automatic thing like if its (+5) or (-5) or done by something like HotCat) It CAN be used for vandalism purposes, most of the time I forget to even flag it. ~With regards, I followed The Username Policy (Message Me) (What I have done on Wikipedia) 20:29, 27 March 2023 (UTC)I don't think that it serves any purpose.  Since you can't trust it, it needs to be reviewed, which removes it's reason for existence. North8000 (talk) 20:30, 9 March 2023 (UTC)  I perform a lot of AWB runs in which I make edits that are really minor (e.g., adding missing spaces after commas or ref tags). I mark these minor by default. I would like to think the software will eventually get to the point where it can natively recognize that an edit is "minor" in this sense without any human choice being involved at all. BD2412 T 21:24, 9 March 2023 (UTC) I'd support removing it. If it were consistently used honestly, it would work, but it is not. I do not double check on editors I trust if they mark an edit as minor, but I don't check a trusted editor even if it not marked as minor. I don't think it provides the information it is intended to provide. SchreiberBike | ⌨  21:45, 9 March 2023 (UTC) Agreed, it's pointless. Its only use is the inverse of what was intended: some people attempt to hide bad edits by calling them minor, so minor deserve extra scrutiny. It also misleads novice editors who are nervous of claiming they're making a big contribution to Wikipedia when all they're doing is adding a new supporting reference, or a single sentence highlighting a new development in their field. They believe these edits are 'minor', which they are in terms of global authorship, but they're factual changes so they're major in Wikipediaworld. And then novice gets cautioned for misusing 'minor', which is scary and off-putting. Elemimele (talk) 17:42, 15 March 2023 (UTC) I agree it's more trouble than it's worth among the general editor population. There are a few valid use cases, though, e.g. allowing people to hide AWB edits in their watchlist and letting bots edit user talk pages without leaving a notification. Certes's permission idea is a good one, although I might make it available on request rather than a default. Extraordinary Writ (talk) 18:11, 20 March 2023 (UTC) "The idea that users can self-report edits that don't require review is outlandish" this statement is only true if you fail to assume good faith.   In most cases, edits marked as minor ARE minor, and can be safely skipped over if trying to understand the content changes brought about by a series of good-faith edits by most editors.  Conversely, a 3,000 byte edit marked as 'minor' is an excellent indicator of something that is more likely to need attention! JeffUK 16:06, 28 March 2023 (UTC) Assuming good faith does not mean that we should assume that every edit is equally beneficial to the encyclopedia. An editor can have all good intentions and still make mistakes, or not be aware of one or another point in our policies and guidelines. And we know from painful experience that some editors do not always edit in good faith. So, assume that an editor is editing in good faith until and unless the evidence shows otherwise, but do not assume that any edit is error-free and does not need to be reviewed. If I had the time, I would review every edit that shows up in my watchlist (I actually did do that for a while), but, as it is, with over 5,000 pages on my watchlist, I tend to skip over edits in mainspace made by editors I recognize. Donald Albury 18:19, 28 March 2023 (UTC) I'm the same, and for those editors who either I recognise, or see making good edits, I tend to trust that their 'minor' tags are appropriate and relevant; making the tag a useful indication of whether or not an edit has added content that may be likely to be challenged. JeffUK 18:36, 28 March 2023 (UTC) But, I think all my edits should be reviewed. I am terrible at proofreading my own work, and it has taken me up to six years to discover errors I have made.[4] Donald Albury 18:55, 28 March 2023 (UTC) And a few minutes ago I saw that an IP had just corrected a couple of capitalization errors I had made eleven years ago. Donald Albury 19:48, 28 March 2023 (UTC) I don't understand how removing the 'Minor' flag, as is proposed here, either helps or hinders that happening in the future. JeffUK 22:38, 28 March 2023 (UTC) I oppose the general removal of the “minor edit” button.  Maybe I am in the minority but I do use it for routine correcting of typos (often my own) and others should have that option if they so choose.  I do like the idea of revoking this button from those who abuse it. Frank Anchor 03:03, 29 March 2023 (UTC) Wikipedia talk page discussions could be in a discord conversation format. So that you don't get a long thread of replies and it's hard to track who has replied to whom. So it could appear to be more like a linear chat. Of course you could still reply to someone with an @. Born25121642 (talk) 23:05, 9 March 2023 (UTC)  Why would we want it to be harder to track who replied to whom? Anomie⚔ 12:56, 10 March 2023 (UTC) oh, my bad. i meant that it is hard to track right now, and the discord idea could help fix that Born25121642 (talk) 06:31, 11 March 2023 (UTC) I find it often difficult to understand who is replying to what in a flat Discord conversation from reading it, while Wikipedia's indent levels at least provide some degree of information. —Kusma (talk) 10:57, 11 March 2023 (UTC) Understood. Here is a wikipedia discussion I am in right now: Talk:Man#What_is_a_man? And you see how it is hard to track the replies. Born25121642 (talk) 20:40, 11 March 2023 (UTC) I don't think this is a particularly difficult example to track replies, compared with much more convoluted cases I've seen. In any case, though, a linear set of posts would be worse for the purposes of tracking replies, requiring the reader to manually backtrack and thread conversations together. (I have in the past pointed out how a linear format makes it easy to catch up on discussions, since all you have to do is find the last post you read and continue from there, which is why it's so popular in places like online bulletin boards. But tracking replies is not one of its selling points over threaded conversations.) isaacl (talk) 21:53, 11 March 2023 (UTC) Personally when I want to catch up on an on-wiki discussion I use the diff view. Anomie⚔ 17:23, 12 March 2023 (UTC) I do most (*) of my viewing of changes in either wikitext view or the beta feature visual diff view, but they have their drawbacks. Wikitext diff view requires you to interpret the source in your mind and has relatively narrow columns. Visual diff view is more friendly for many types of changes. In talk page threads, though, often someone will change one of the list types (that is, change a * to a : or vice versa), and then visual diff view will flag the entire list as having been removed and replaced with the new type. Also, for numbered lists, it always shows the entire list (presumably as a way to preserve item numbering), which can add a lot of unchanged text to scroll through as the list gets longer. With both modes, you're relying on enough context being shown by default to understand the diff (it's generally not a problem with visual diff view; getting more context than needed is more frequently an issue). While of course bulletin boards offer no context by default, since the commenters know this, they will provide quoted context to help understand their response. (This of course leads to a lot of text being quoted repeatedly, and sometimes way more text than necessary.) isaacl (talk) 17:44, 12 March 2023 (UTC) (*) Using diffs to view changes is simplest for pages on my watchlist, since then Wikipedia will track the last seen revision for me. As I don't have high-traffic pages on my watchlist, for those I'll resort to scrolling through the thread, or subscribing to it, which very handily lets you view the current conversation with the new changes highlighted (though you still have to scroll through to find any after the first one). isaacl (talk) 17:56, 12 March 2023 (UTC) Although I'm not a fan of this idea, I do think the fact that the basic structure of talk pages hasn't changed in almost 20 years (wow) is indicative that something might need to be done. (The WMF's various attempts haven't been liked by really anyone, unfortunately.) casualdejekyll 12:34, 16 March 2023 (UTC) Based on the 2019 talk page consultation, the talk pages project was started, which has produced the reply tool, section-based subscription, and the new discussion tool, all of which have been well-received by those who use them (and are easily avoided by those who don't want to use them). For better or worse, there are a lot of editors who are vested in the current format, and so layering tools on top of it seems like the best compromise approach for now. (There are Phabricator tickets open such as phab:T230683 for making wikitext syntax more expressive when writing nested responses, but it wouldn't alter the commenting workflow. It would just enable more types of content to be nested at the desired list level, or make it easier for someone to specify the desired nesting level.) isaacl (talk) 16:17, 16 March 2023 (UTC) I love the reply tool. I also just found out about deindenting. I would support a set of features that optionally make conversations more like on reddit desktop, where vertical lines are shown next to each comment, and if you click the line, it collapses the comment. I believe this makes a threaded conversation overall easier to navigate. Born25121642 (talk) 19:58, 16 March 2023 (UTC) You might like the system of blue lines that the French Wikipedia uses.  You can see an example at this link. Whatamidoing (WMF) (talk) 21:12, 16 March 2023 (UTC) Oh my god-- I'm not the biggest fan as that could be designed better, but that is definitely an improvement :3 F4U (they/it) 19:24, 23 March 2023 (UTC) @Born25121642, I think CD can do this. — Qwerfjkltalk 16:32, 24 March 2023 (UTC) very cool. Born25121642 (talk) 00:27, 25 March 2023 (UTC) I think the blue lines feature might be useful as mentioned above, also Wikipedia should have like a live updating chat page, which would be useful for coordination or very rapid discussions.  ~With regards, I followed The Username Policy (Message Me) (What I have done on Wikipedia) 20:34, 27 March 2023 (UTC) Hello, I think Wikimedia maps (commonly used in Template:Maplink) could benefit from the inclusion of names for some large/notable parks, rivers, etc... Without context, a lot of these areas blur into one color when in fact, there are multiple different parts to them (especially the green color for parks and protected areas). It might look a little like how Google Maps makes their map but with far less named areas and no pinpoints. Thank you for your time and have a great day! DiscoA340 (talk) 18:08, 15 March 2023 (UTC)  I recently noticed the link List of student newspapers in the United States of America in an article's see also section. On clicking it, it redirected to List of student newspapers in the United States, so I fixed it, but I suspect that there are many examples of this phenomenon. There might be a few instances in which the redirect is used intentionally/preferred, but in most I'd think we'd want to correct it. Would someone be interested in creating a semi-automated tool that'd allow you to quickly go through redirects in see also sections and bypass them if needed? Cheers, {{u|Sdkb}} talk 19:42, 15 March 2023 (UTC)  An AWB regexp to replace links by {{subst:Target of|$1}} might do the trick. Certes (talk) 20:22, 15 March 2023 (UTC) @Sdkb, have you ever read WP:NOTBROKEN?  (Hint:  It's not a shortcut for Wikipedia:If it ain't broke, don't fix it.) WhatamIdoing (talk) 20:35, 15 March 2023 (UTC) @WhatamIdoing, this task would seem to me to be compliant with the advice there. It talks about e.g. not changing e.g. [[Franklin Roosevelt]] to [[Franklin D. Roosevelt|Franklin Roosevelt]], which would be a cosmetic task. But changing links in see also sections is not a cosmetic task because they're fully written out. Redirects there seem most analogous to redirects in navigation boxes or on disambiguation pages, which WP:NOTBROKEN specifically lists as instances where it's okay to bypass. Cheers, {{u|Sdkb}} talk 20:46, 15 March 2023 (UTC) Yes, NOTBROKEN is important and we must not replace redirects indiscriminately.  (One LTA I deal with gets blocked for that regularly)  However, See also does seem like a good place to clarify the target article's actual title, assuming that the redirect being bypassed is a near-synonym rather than a subtopic with possibilities. Certes (talk) 21:51, 15 March 2023 (UTC) Why is the ==See also== section "a good place to clarify the target article's actual title"?  How does that comply with NOTBROKEN, which says There is usually nothing wrong with linking to redirects? Maybe the ==See also== section is a good place to link to Lorry instead of Truck, especially if the article that the link is being written in uses British English. Or maybe the redirect in question has potential for expansion, and bypassing the redirect would eventually end up sending people to the wrong article.  The powers that be have rearranged a couple of rare cancers, and the result for us will be that one article needs a new name, and one existing redirect will be repointed to the new name, instead of to its present target (which has been declared to be unrelated).  If you bypass the redirects, people will end up in the wrong place. This feels like the kind of help that isn't actually helpful. WhatamIdoing (talk) 02:44, 16 March 2023 (UTC) Those sorts of examples are why I'm thinking of this as a semi-automated task with a human in the loop rather than a fully-automated bot task. If I saw a link to Lorry, I'd check the article's ENGVAR before changing it. I'd also use my judgement in the broader sense — if it turns out that 9/10 instances are straightforward fixes, great, but if every other instance requires more careful examination or is clearly a valid use of a redirect, I'd drop the task. Best, {{u|Sdkb}} talk 03:05, 16 March 2023 (UTC) I suspect every other instance would require more careful examination.  They're also going to be hard to find.  In theory, Quarry etc. could list the millions of links to redirects, but 95% of those links will be outwith See also and should be left alone.  Some redirects should be bypassed and some should not, with a large grey area in between where good editors will politely disagree, but that's no longer relevant if we can't easily find them. Certes (talk) 10:45, 16 March 2023 (UTC) Honestly just a tool that highlights links that don't match their title in general could be useful in a variety of circumstances outside of See also. :3 F4U (they/it) 14:11, 24 March 2023 (UTC) @Certes, that seems like it'd work to do the fixes, but I'm not sure how I'd generate the initial list. Cheers, {{u|Sdkb}} talk 03:06, 16 March 2023 (UTC) I am confused about your question, as both of these two links you mention are redirects (both List of student newspapers in the United States of America and List of student newspapers in the United States - the article's actual title is List of college and university student newspapers in the United States). Do you mean that you want to link to direct articles instead of using redirects? Natg 19 (talk) 21:57, 15 March 2023 (UTC) Yes, sorry for the confusion. {{u|Sdkb}} talk 22:05, 15 March 2023 (UTC) @Sdkb, Navpopups can do this; just add window.popupFixRedirs = true; with Navpopups installed. — Qwerfjkltalk 16:29, 24 March 2023 (UTC) Ah, cool! {{u|Sdkb}} talk 16:42, 24 March 2023 (UTC)   === Tool for highlighting links that don't match their title === Ooh, Freedom4U, I really like your idea here. Splitting that out into its own subsection so we can give it full consideration. Would anyone be interested in building this as a script? {{u|Sdkb}} talk 14:30, 24 March 2023 (UTC)  As in, possible WP:EASTEREGG finder? There's something like that already, for non-matching interlanguage-links, which generates a report somewhere; I'd have to go look. Mathglot (talk) 22:06, 24 March 2023 (UTC) Yes, exactly that! :3 F4U (they/it) 22:31, 24 March 2023 (UTC) Does "links that don't match their title" mean links to redirects? Certes (talk) 00:46, 25 March 2023 (UTC) I'm talking about redirects and piped links-- maybe they should be highlighted in different colors.... I can think of countless examples where something like that would have helped me out when cleaning up an article. :3 F4U (they/it) 00:48, 25 March 2023 (UTC) @Freedom4U, it won't help with piped links, but you can use the .css for your skin to change the color of redirect links; see User:Schazjmd/vector.css for an example. (The last line in that file turns external URLs in the body hot-pink, which makes it super easy to clean them up.) Schazjmd (talk) 14:35, 25 March 2023 (UTC) Most of the 60 million links to redirects shouldn't be changed, as they are not broken.  Piped links are a different issue.  Clicking the "Random article" link ten times and checking the wikitext revealed 71 explicit piped links, plus an unknown number via various templates.  If those articles are typical, we have about 40 million links that don't match their title.  The good news is that the vast majority of them will already be either better than or at least as good as an unpiped link. Certes (talk) 18:04, 25 March 2023 (UTC) There are a lot that can be fixed wrt redirects from my experience. Just recently I found a link to grilled beef that redirected to carne asada. There's lots of other instances I've seen this too-- I think one of the biggest things it'll help point out is when links aren't capitalized correctly. For example, I recently found an article where Front homosexuel d'action révolutionnaire was miscapitalized as Front Homosexuel d'Action Révolutionnaire. Nothing deal-breaking, just slight improvements. :3 F4U (they/it) 18:15, 25 March 2023 (UTC) Front Homosexuel d'Action Révolutionnaire is an {{R from other capitalisation}}.  If that capitalisation is really incorrect, rather than a valid alternative, it should instead be an {{R from miscapitalisation}}.  That will add its incoming links to the daily Linked miscapitalizations report, which is watched and acted upon regularly.  (I don't help with that task myself, but do follow the similar Linked misspellings report.) Certes (talk) 18:23, 25 March 2023 (UTC) Not a miscapitalization as in outright wrong, but rather its a capitalization in title case, and Wikipedia uses sentence case. :3 F4U (they/it) 18:26, 25 March 2023 (UTC) Topice Was Problem : Problems/Constraints are not specified before ideas  We should agree on the importance of problems by creating a problem list which we can then refer to on ideas/proposals.  Many editors suggest changes/ideas/proposal or are frustrated with various problems. Part of the problem maybe that we jump to ideas and proposals,  and then get stuck on discussing whether it is a problem or pointing out constraints.    If we had a list of priorised problems, then we could focus on evaluating ideas/proposals with the knowledge that there is consensus that the problem needs fixing. If there are constraints that are causing us to stop fixing the problem (resources, WMF policy, WP policy, etc), then these can be looked at in the same way.  For the non IT peoples,  In most organisations  systems , there is a   a set process that all changes goes through (except for emergency system changes or CEO whims) .We skip most of it.    Problems typically go through a process, something like this   Discover  - gathered/elict processes Analyse - the problems using lots of different methods Five_whys to find the causes ... What is the extent? What is the evidence of the problems? What are the benefits? What are the constraints? Can we solve part of the problem? Prioritise.  Is the problem worth fixing? Is there agreement? Is the problem within our control, or can we make it in our control?19/03/2023 Reworded, added an explanation,  and changed title.  Wakelamp d[@-@]b (talk) 03:50, 18 March 2023 (UTC)  This is a good idea. For example, the pending-changes protection for FAs seems to have worked, but no one has RfC'd it, something that imo is a solution that has just been forgotten. At the same time, I am also worried that this would create extra bureaucracy and creep, such as criteria for putting a problem on the list, preventing canvassing of solutions to those problems, and extra bots to manage the page(s). Sungodtemple (talk • contribs) 00:35, 24 March 2023 (UTC) Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article, people decided they wanted semiprotection instead. Anomie⚔ 11:13, 24 March 2023 (UTC) Maybe it would help to do an example using the FA pending changes protection Problem : Should FA articles have pending changes BUT its best to have an issue stated as an issue, so "Reducing vandalism on FA articles" Criteria for putting a problem on the list - Its probably better to have a bug/issue reported than not. But if the issue already exists then merge /redirect it Importance Editors:  Number of readers that click on FA account, Number of reverts on FA account, editor health (# of editors harassed after reverts), evidence provided Strength of evidence - Query # of reverts Priority :Number of editors voting for it, number of proposals/solutions created, Importance Canvassing of solutions - is already covered with current canvassing rules I think. But I think off wiki discussion and brainstorming as long as it is reported would be fine and needed Bots - if we could just ping a page eg (at)problem12345 it would just add a comment to that problem. Wakelamp d[@-@]b (talk) 14:29, 27 March 2023 (UTC) Bugzilla as an issue repository You mentioned maintenance issues - to avoid them I looked for existing open source issue systems that were linked to media wiki.  There are Bugzilla extensions that write to mediawiki software such as (all descriptions below are from the  link). BugSquish Mediawiki Extension This extension checks your Bugzilla installation and adds a strikethrough to interwiki links for closed bugs. Mediawiki Bugzilla Extension This extension allows you to list bugs from Bugzilla in a Wiki page using Bugzilla's REST API. Bugzilla Reports MediaWiki Extension (website) - Generates great looking sliced and diced reports from your Bugzilla instance which you can embed in your MediaWiki pages or any PHP application. Makes reporting on your bugs much easier than through the standard Bugzilla search UI. Wakelamp d[@-@]b (talk) 14:55, 27 March 2023 (UTC) While it isn't clear whether the close of the Vector2022 RfC will stand, I believe it is still beneficial to determine what modifications we want to make to the skin. This would include both modifications that we can make by editing MediaWiki:Vector-2022.css and MediaWiki:Vector-2022.js, and modifications that we would need to ask the WMF to make. I'm opening this discussion to determine the format of that discussion, and to determine which changes should be discussed as part of it. For format I believe a multi-part RfC would be best, with each proposed change a separate question. For the questions I have created an initial list of those I consider worthy of discussion; I have included questions that I would support and questions that I would oppose but expect to have some support among the broader community.  Main menu: Should the main menu be visible by default? Should the choice to expand or collapse the main menu be persistent? Header: Should the mystery meat buttons be replaced with text buttons? Should readers be able to disable the sticky header? Should the sticky header be disabled by default? Which, if any, of the following should be moved out the right hand drop down menu and moved into the header bar?: A: "User talk" B: "User sandbox" C: "User preferences" D: "Beta" E: "User contributions" F: "Log out" Table of contents: Should pages include a table of contents at the top of the article, similar to Vector2010, in addition to the sticky table of contents? Should sub-headings in the floating table of contents start expanded (Collapsed sub-headings, expanded sub-headings)? Other: Should the previous state of the article title bar be restored (Previous state, current state)? This would involve: Moving coordinates to be inline with the slogan "From Wikipedia, the free encyclopedia" Moving icons denoting page protection, featured status, etc for featured article, to be inline with the article title Moving the language selector to the main menu When a user selects "expanded width", the content only expands to use the white space on the left of the page, not the right. Should the white space on the right also be used? (This question may have already been asked, depending on the interpretation of "full width by default")BilledMammal (talk) 14:53, 19 March 2023 (UTC)  Main menu: 1. yes; 2. no. Header: 1. neutral; 2. yes; 3. yes; 4. C, D, F. Table of contents: 1. yes; 2. yes. Other: 1. yes; 2. the page should be expanded by default as it was in V10. Æo (talk) 12:12, 20 March 2023 (UTC) I'd bet almost everyone uses Google here to try and find various sources. For those who haven't noticed, Google has become increasingly unreliable and there seems to be large amounts of information being hidden, whether it's intentional or unintentional For instance, let's say I perform a search on "oranges". A non-political, non hot-topic issue. The search says it has found 16 quadrillion results, but when you start scrolling down the page, it limits the search to 247 results and gives this message (In order to show you the most relevant results, we have omitted some entries very similar to the 247 already displayed.If you like, you can repeat the search with the omitted results included). While you can repeat the search, you are not going to get anywhere near the 16 quadrillion results you are told exist. And as you go further down into the original 247 result search, you start getting news reports about Orange County. This isn't a one-off either as every search is like this and as it gets into political issues, the results clearly become more swayed in various directions. This is a really big problem when it comes to research and resource gathering on this site. While you can deal with the results about oranges being hidden, searches on less known or less popular things are severely impacted. The information is still there, somewhere, but you really have to have to know what you are looking for in order to find it. The issue is not just with google either, as other search engines like Bing are doing this as well.KatoKungLee (talk) 14:55, 19 March 2023 (UTC)  Google limits the results displayed to 1000 and then eliminates duplicates, so you will never see more than 1000 results displayed, and for most subjects a few hundred. As far as I am aware it has always done this. Other search engines behave similarly. Phil Bridger (talk) 15:08, 19 March 2023 (UTC) You can cast a wider net by searching for phrases. If "oranges" doesn't find enough interesting links, try "orange fruit", "orange tree", "orange color", etc. Searching Google Scholar, Google Books, or Google News will give you results that don't turn up in a plain Google search, and which are often more useful for sourcing WP articles than what you find with a plain Google search. Donald Albury 15:39, 19 March 2023 (UTC) Not to mention that there are other search engines.  And most libraries have their catalogs on-line.  Plus a wide variety of commercial databases and archiving services available through WP:LIBRARY. -- RoySmith (talk) 15:51, 19 March 2023 (UTC)  Google used to have options to limit searches, but over time they have become increasingly less functional. Someone more cynical than me might guess that degradation to be due to their business model. Perhaps it's time for an "open search project" that was more concerned with accurate hit lists than with selling eyeballs? I miss Deja News. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:03, 19 March 2023 (UTC) This isn't a reliability or censorship issue. Unless there are good quality sources that Google absolutely will not return results for (like, if they suppressed links from the NYTimes), this seems like a standard approach in search engines to keep the most relevant results for you. Masem (t) 18:13, 19 March 2023 (UTC) I think it is well-known that Google tailors results to what it thinks the person wants to see. BD2412 T 22:29, 19 March 2023 (UTC) I hope it's equally well known that you can get around this by running your searches in an incognito window. -- RoySmith (talk) 22:59, 19 March 2023 (UTC) To a certain extent, but this doesn't help with the throttling of search results to 1000 or so. Gnomingstuff (talk) 23:51, 19 March 2023 (UTC) Is throttling search results to 1000 a problem, though?  I doubt many people would be looking past the 1000th search result even if it were available, and I suspect the proportion of relevant reliable sources coming up at that point would be pretty low.  Editors would be better off developing their search engine skills to effectively find sources than worrying about whether Google will cut them off after 1000 results! Caeciliusinhorto-public (talk) 15:24, 20 March 2023 (UTC) Impossible to know really, just wanted to make the slight correction. Gnomingstuff (talk) 03:44, 21 March 2023 (UTC) yes and no. It still knows your location if you search like that and will tailor your results to your location and language. —TheDJ (talk • contribs) 22:22, 20 March 2023 (UTC) Using search engines is a skill that can be learned. What you need is not to go through more than 1,000 results, you need better search terms instead. For most Wikipedia research, just build a query that goes: site:nytimes.com OR site:... and include all the sites listed at WP:RSP that are relevant to your area (whether culture, technology, video games...), or rely on WikiProject-specific reliable source lists (WP:TV and WP:VG have those, I believe). You wouldn't believe how many results you can surface with this method, that would never come up with "casual" search queries. Remember Google Search is built for the use cases of the masses, not for us. It'll rarely surface old articles, for example. Use your search engine's "date" tool (for example, all results before 2005) for that. DFlhb (talk) 22:00, 20 March 2023 (UTC) If you want to search the NY Times, go to nytimes.com and use their search tool rather than relying on a third-party search engine. -- RoySmith (talk) 22:17, 20 March 2023 (UTC) The point is to be able to search 30+ sites at once; here's an example that I found helpful. DFlhb (talk) 05:13, 21 March 2023 (UTC) Agree with others. If you need to look at > 100 search results, you need more specific search terms, or there are problems with your topic not being notable. Regardless this is not a Wikipedia issue that users here need to deal with. Natg 19 (talk) 23:14, 20 March 2023 (UTC) This SEO type site states that less than 0.63 % of searchers ever look past page 2. Are there better search engines that might be suitable for edits ? With more operators? Or where you can save searches? (The film project has a custom search engine, which I think is based on this [| google tool]. I used to like clusty which did clustered search but it seems to have gone, and I couldn't find any search engine result comparison tools Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 07:56, 28 March 2023 (UTC) As a follow up to my other proposal for improving/reducing discussions on edits... (really hope that first proposal will be picked up someday as it would help SO much) Why don't we show the number of thanks an edit has received in the edit history? It might help show "consensus" with other editors when editing certain pages and avoid edit wars. A user might be less inclined to just revert an edit if he notices that others support it but might be more inclined to start a discussion.  {{u|Gtoffoletto}}  talk 17:23, 21 March 2023 (UTC)  I don't think we currently reveal which edits received thanks, only who thanked whom and when. Certes (talk) 17:27, 21 March 2023 (UTC) Do we have the ability to reveal that? - L'Mainerque - (Talk - Signbook) - 22:36, 21 March 2023 (UTC) Thanks log documentation suggests not: the information is not stored in logging. Certes (talk) 22:49, 21 March 2023 (UTC) Okay, thanks (no pun intended) for letting me know. - L'Mainerque - (Talk - Sign) - 22:52, 21 March 2023 (UTC) I think that if implemented this would pretty soon be gamed by spammers to such an extent that it would be meaningless. I get what seems to me to be a lot of thanks from other editors, and I also give some out. Let's all take private satisfaction in that rather than make this public. Phil Bridger (talk) 23:00, 21 March 2023 (UTC) Now that I think of it, yeah, it would be abused by spammers and people acting in bad faith. - L'Mainerque - (Talk - Sign) - 23:08, 21 March 2023 (UTC) Would it be abused? Thanks are pretty rare at the moment (or is it just me? :-P). If you could see who gave the "thanks" you could then evaluate it. In any case I think @Certes is saying this feature would not be technically doable?  {{u|Gtoffoletto}}  talk 22:46, 22 March 2023 (UTC) Looking at the code (I'm not a coder so forgive me if I'm wrong), it would suggest that Certes is correct in saying that it would not be technically possible at the moment. - L'Mainerque - (Talk - Sign) - 23:04, 22 March 2023 (UTC) I'm saying that the data stored in the obvious place only has thanker, thankee and time; no indication of which edit or even which page was edited.  That information may be stored elsewhere, but I doubt it.  There's a sample extract here. Certes (talk) 23:07, 22 March 2023 (UTC) Actually this can't be right: when I get a notification of a "Thanks" it does show which specific edit received it. So that information is available somewhere.  {{u|Gtoffoletto}}  talk 00:40, 23 March 2023 (UTC) When you send a thank, you do send it for a specific edit or action (e.g. Special:Thanks/1146124820) - that could pass on to notification system and not actually "store" that part though, I haven't read all the code on this. — xaosflux Talk 00:51, 23 March 2023 (UTC) See also phab:T51087 (from 2014) and phab:T324134 for related topics about this. — xaosflux Talk 00:54, 23 March 2023 (UTC) I wasn't involved in that project, but I remember hearing that this was a deliberate decision.  There are privacy implications in publicly revealing that Alice thanked Bob for a particular edit, because that means that Alice was reading a particular page or agreed with a particular contribution, which Alice might not wish to be public information. The Echo/Notifications separately stores all of this information (thanker, thankee, timestamp, and diff).  However, that is temporary (two years or 2,000 notifications, whichever comes first).  The permanent log stores only the thanker, thankee, and the timestamp.  This combination allows admins to check for certain kinds of problems (e.g., interaction bans) but doesn't publicize certain other kinds of problems (e.g., how many times someone got thanked for being rude). Whatamidoing (WMF) (talk) 01:53, 23 March 2023 (UTC) Since you are thinking about Thanks, this might be interesting: This week, the Growth team completed a quick analysis of Thanks usage. In early January, the Comumity Wishlist proposal to Enable Thanks Button by default in Watchlists and Recent Changes was fulfilled. Since the Growth team has been working on a Positive Reinforcement project, we were curious to see if this change increased the number edits that were thanked.  As is often the case, the answer isn't totally clear and seems to vary by wiki. But perhaps more interesting is to see that the ratio of edits Thanked varies considerably by wiki, and seeing the low percentage of newcomer edits that receive Thanks. I'm not necessarily surprised by either finding, but I'm always thinking about ways to ensure newcomers receive the support and encouragement they need to continue to contribute, so feel free to chime in here or on the Positive Reinforcement talk page if you have any ideas. :)   KStoller-WMF (talk) 20:50, 24 March 2023 (UTC) @KStoller-WMF I think the consensus here is that we shouldn't rely on thanks for content disputes. Which I think is a good point. However I think it's great that you are making it easier to give thanks to other users. Another great place would be right here in the discussion page. I have a quick "reply" button but I don't have a quick way to send "Thanks" for your message. I wanted to do that for some of the messages received in this discussion such as yours and I would need to find them in the history log!  {{u|Gtoffoletto}}  talk 15:29, 28 March 2023 (UTC) Yes, I can see how Thanks could get problematic in content disputes if publicly connected to an edit. I would love to see Thanks added to discussion pages!  I know the Editing team was considering that work as part of the DiscussionTools work: T249893.  My understanding is that the Editing team is hoping to shift to another project soon, so I'm not sure if that work will move forward.  KStoller-WMF (talk) 20:50, 28 March 2023 (UTC) Is there a way to "vote" this feature or provide support? It would be very helpful I think.  {{u|Gtoffoletto}}  talk 14:07, 29 March 2023 (UTC) I am happy that thanks are low-key. If we try to use them to resolve content disputes, I expect the collegiate informal nature of them would be lost, and we would start to see things like gaming the system, or creating an expectation/duty to “vote” on edits. It might also encourage users to eschew discussion in favour of just bumping the thank count. We already weigh edit count too highly when judging other editors; we don’t need another high score or anything approaching social media upvote/downvote buttons. Barnards.tar.gz (talk) 21:22, 24 March 2023 (UTC) I totally agree on you there. - L'Mainerque - (Talk - Sign) - 22:29, 24 March 2023 (UTC) Yes, I agree that's a legitimate concern.  {{u|Gtoffoletto}}  talk 15:24, 28 March 2023 (UTC) I think not.  At best this will just be interesting trivia, at worst it could encourage WP:NOTVOTING on edits, "You can't revert my edit because 100 people liked it..."  JeffUK 21:54, 26 March 2023 (UTC) This has been touched on at the Village Pump over the last couple months, but I want to present a specific example for comment this time. 2001 has been updated with the intention of making it more encyclopedic (before and after). Given how much of a massive change it is, I want to get as much input as possible before similar edits take place on other year articles. I'm particularly looking at WP:LAYOUT, WP:PROPORTION, and WP:SUMMARY, but any criticism is helpful. Thebiguglyalien (talk) 03:36, 23 March 2023 (UTC)  Looks solid on all three counts, I'm impressed. I expected WP:PROSELINE to be inevitable, but that article avoids it skillfully. Shame that I missed the prose RfC; this article is a great showcase for the benefits of prose in Year articles. Cleaner, more readable, better organized. DFlhb (talk) 14:54, 23 March 2023 (UTC) I do think the list element is visible in a few spots. The "accidents" section is basically "this happened on this day and killed this many people" repeated several times (and overall the "disasters" section is the one I'm least happy with). It's one of the things I'm hoping to get worked out. Thebiguglyalien (talk) 23:00, 23 March 2023 (UTC) I almost changed skilfully to mostly, but couldn't come up with any specific improvements to make. It'll be a fun challenge anyhow. DFlhb (talk) 23:27, 23 March 2023 (UTC) Looks great! The only criticism I have is the imagemap (is that what it's called?) at the top is a little too US-centric. I don't have specific suggestions, and it is a year where events in the US had massive repercussions around the world. So maybe it makes sense for 2001? But for other years, I hope it's a little more global. 🙢 - Sativa Inflorescence - 🙢 18:05, 23 March 2023 (UTC) Those imagemaps have been the subject of huge disagreements. No one can agree what should go in them or whether they should even be on year articles at all. Thebiguglyalien (talk) 22:54, 23 March 2023 (UTC) @Thebiguglyalien, this is awesome.  I really like what you've done.  I think it makes sense to have a ==Section== for each of the main "2001 in..." articles (e.g., ==Sports== for 2001 in sports). On possible improvements, I offer two ideas: I think it would be a good idea to merge the ==Nobel Prizes== section at the end up into the relevant areas (e.g., culture for the literature prize, etc.) instead of keeping it as a separate section. The births/deaths section, which is empty, could have some simple statistics about world population change, like number of births, number of deaths, and the estimated population at the beginning and end of the year.  Years with unusual mortality (e.g., 1918 influenza pandemic, 2020 COVID-19 pandemic, the world wars) could have a sentence about that. I really like this, and I feel like it gives me a better picture of the year overall, rather than a laundry list of individual items. WhatamIdoing (talk) 19:12, 24 March 2023 (UTC) WhatamIdoing, births/deaths and Nobel Prizes (along with the events timeline) are the remnants of what the article looked like before, so now they kind of exist in a limbo. There's a "health and society" section near the top that kind of touches on population and such, but that's one of the sections that I'm not sure what exactly it should look like or what should go in it (especially since there's no 2001 in health or anything like that). Thebiguglyalien (talk) 02:19, 25 March 2023 (UTC) This is a very nice format. If there isn't prose you could probably move the births/deaths links to the See also, but I agree with WhatamIdoing that putting it in demographics might be good for some years. Perhaps don't use a 2010 flag for the African Union being mentioned in 2001! CMD (talk) 02:39, 25 March 2023 (UTC)   === Should the "Events" timeline remain on year articles after they're destubbed? === Related topic, so I'm adding this as a subsection instead of making a new post. Currently, most year articles are dominated by a timeline that lists a bunch of events from that year. But with 2001, the first half is an article and the second half is a timeline. The way I see it, there are three ways to handle this:  Keep the article and the timeline on the same page. A bit clunky and some redundancy, but all the info is in one place. Allow year articles to develop and then WP:SIZESPLIT the timeline from developed year articles (so an article would be written at 2002 and then the timeline would be moved to Timeline of 2002 or Events of 2002). Going forward, WP:MOVE the timeline to a separate page and then create a new article under the old title. This would have the same end result as the previous approach, with the advantage of preserving the timeline's history.Pinging those that commented above (DFlhb, Sativa Inflorescence, WhatamIdoing, Chipmunkdavis) and those that commented the last time this was discussed at WikiProject Years (Barnards.tar.gz, InvadingInvader, JeffUK, GoodDay) because splits/moves of this scale do not feel like something that should be done without input. Thebiguglyalien (talk) 18:17, 26 March 2023 (UTC)  Keep a timeline on a main year article, but it shouldn't be the only part. Not every important event in a year fits neatly into a prose paragraph, and some people are a bit "data-crunchy" in their reading style. Keeping a timeline in addition to prose on the same article hits two birds with one stone. InvadingInvader (userpage, talk) 18:38, 26 March 2023 (UTC) Keep both prose and timeline on same article - It will minimize the confusion of the general public, and will kill two birds with one stone. - L'Mainerque - (Talk - Sign) - 18:54, 26 March 2023 (UTC) I won't be of much help, going forward. I was quite content with how the Year pages were. GoodDay (talk) 19:09, 26 March 2023 (UTC) It totally depends on the article.  If we remove everything from the timeline that's not mentioned in the prose and we're left with a bunch of trivia, then the timeline doesn't really serve any purpose.  So I think remove them if they don't add anything of value, leave them if they do,  per article based on consensus as usual  JeffUK 21:50, 26 March 2023 (UTC) Depends on the article and the timeline. It's okay to have embedded lists. CMD (talk) 00:33, 27 March 2023 (UTC) I prefer the idea of (eventually) splitting them out, and having the resulting Timeline of 2001 be fairly complete (i.e., not just the things that weren't worth mentioning in prose).   WhatamIdoing (talk) 16:01, 27 March 2023 (UTC) See WP:AFTAGS and Special:Tags for what I'm talking about. "LLM" refers to large language models, aka "AI chatbots". Here are three ideas:  Add a tag for LLM-assisted edits. This makes LLM usage disclosure far more consistent, systematic, and easily searchable than requiring such disclosure in the edit summary. Add a checkbox to the "Publish box" so users can voluntarily apply that tag (in addition to the current checkboxes, "This is a minor edit", and "Watch this page", add something like "This is an LLM-assisted edit"). This can only be proposed on Phabricator, but it needs discussion first. For users that fail to voluntarily tag, the WMF could add an edit filter based on an LLM-detection algorithm, and tags these edits with a second tag: "potentially LLM-assisted". Such detectors aren't great (low sensitivity, but good specificity), but they'll help with RC patrol.DFlhb (talk) 12:39, 23 March 2023 (UTC)  Are we solving an actual problem, a very incidental problem or a theoretical problem ? Put in another way... Why do we not have the same checkbox for "This is edit is a copyright violation", "This is just me storytelling" etc etc...  —TheDJ (talk • contribs) 15:54, 23 March 2023 (UTC) Do you believe LLM use should be disclosed in the edit summary, or do you also think that's pointless? The tag is intended as a better alternative to edit summaries, but if it's pointless in edit summaries, then indeed it's pointless as a tag too. DFlhb (talk) 16:09, 23 March 2023 (UTC) From an edit filters perspective, detecting language models' outputs using regular expressions would be an impossible job. It would have to be done by a bot (Like how ClueBot NG is run). From an editor's perspective, it might just be not worth it to hunt for these kinds of edits. I myself have used ChatGPT to rewrite a section of an article and I don't think it would be a big difference. So I think that LLM use doesn't need to be disclosed, and that doesn't mean we can't catch problematic edits. 0xDeadbeef→∞ (talk to me) 17:29, 23 March 2023 (UTC) True on regex vs bot. And after thinking about it, I agree that the practical benefits of disclosure are minimal, even in edit summaries. At the WT:LLM draft proposal, we came to a weak consensus (low participation, nothing formal) in favor of disclosure, but come to think of it, we've likely overreacted and thrown everything but the kitchen sink into that draft; ChatGPT's been out of months, and the LLMpocalypse hasn't happened. And after checking the long WP:VPP discussion on LLMs, I'm not even sure where we got that "mandatory disclosure" idea from, because I'm not seeing any community consensus for it. DFlhb (talk) 18:34, 23 March 2023 (UTC) I say that disclosure is an unachievable goal. It's like asking people to not raise their kids with the iPad/Youtube, a lofty goal but pointless. —TheDJ (talk • contribs) 14:48, 24 March 2023 (UTC) A few years ago, there was an ad where a cute little girl said, I'm going to make this photo better, then clicked a button and said, there's, it's better.  I think as more sophisticated technology gets deployed more widely into writing assistant tools (and it's already in many photo processing tools), users won't know if specific technology X was used. Plus I don't think it's a scalable approach to have a checkbox for technology X, then Y, then Z, and so forth as new methods are developed. We need to instill a culture in authors of reviewing changes carefully, no matter what tools they used in the process of creating them, and not relying on tools to have automatically created text suitable for Wikipedia. isaacl (talk) 18:16, 23 March 2023 (UTC) This is an interesting idea. EpicPupper (talk) 00:24, 24 March 2023 (UTC)This would be pointless because nobody is going to use it.  See the #Completely remove the idea of a "minor edit" thread a few sections up.  If people aren't putting the "minor edit" tag to good use, what makes you think they'll do anything useful with a LLM tag?  -- RoySmith (talk) 00:36, 24 March 2023 (UTC)I don’t think we care that much whether an LLM was used, as much as whether edits comply with policies and guidelines. If an LLM manages to assist an editor in producing good edits, great. Barnards.tar.gz (talk) 16:50, 24 March 2023 (UTC)It looks like there isn't going to be a consensus to require disclosing LLM-assisted edits either via edit summary or tag. —Alalch E. 19:38, 26 March 2023 (UTC) I think it's too early to assume what consensus would be at this point. isaacl (talk) 20:49, 26 March 2023 (UTC) I think much support isn't of mandatory, but of voluntary disclosure. EpicPupper (talk) 20:51, 26 March 2023 (UTC) I am opposed to Idea #2. This has a good chance of backfiring, as a checkbox saying "Was this written by ChatGPT/similar" is only going to make people think using ChatGPT to edit Wikipedia is encouraged. That's the opposite of what we want, which is somewhere between "Use LLMs responsibly and manually check everything you write" and "Dont use them at all/Avoid using them". Until we get overwhelming consensus that LLM use for editing should be encouraged, a checkbox like this will be a bad idea. Soni (talk)  19:13, 27 March 2023 (UTC) I agree, highly likely to backfire. It would make people aware of the opportunity to use LLMs on Wikipedia even if the idea hadn't crossed their mind. This would, guaranteed, increase usage of LLMs on Wikipedia. —Alalch E. 22:13, 28 March 2023 (UTC) Has there ever been any discussion of the possibility of enabling pending changes for article talk pages? I've noticed an uptick in purely disruptive edits on some talk pages, especially those dealing with contentious subjects where the article is already protected. Currently pending changes is not an option for talk page protection. -Ad Orientem (talk) 14:28, 25 March 2023 (UTC)  @Ad Orientem This actually sounds like something I'd support, but maybe at a different level. I know the Abuse Filter can tag edits for further review, but can it hold edits for review? i.e. the edits are not published until an admin/PCR approves them? That might be a good solution for disruptive edits to talk pages. Some forums like Reddit actually allow for this. Aasim - Herrscher of Wikis ❄️ 05:26, 27 March 2023 (UTC) @Awesome Aasim no, there is no where for the abuse filter to put something pending review, regarding an edit it can TAG an action, it can interrupt an action with a warning, and it can prevent an action. — xaosflux Talk 20:04, 27 March 2023 (UTC) @Ad Orientem One of my interests is analyzing reasons/location/processes for abuse, and trying to find causes to solve and prevent it. Most of disruptive/abuse edits I have seen have been on user talk Can you provide some examples of some contentious topics where this is happening? ( I looked at you user page and your stated interests don't spring to mind as inspiring conflict). And what type of editorWikipedia:IP_users,  experienced , SPA, very new troll, .... etc @Xaosflux Do some abusive/disruptive edits get removed from history? And would the abuse filter tag/stop an issue that is only to do with the edit summary? I ask because I went through a dump of a day's edit summaries, and there weren't as many offensive ones as the comments on village pump and by WMF concerning the toxic culture indicate Wakelamp d[@-@]b (talk) 07:20, 28 March 2023 (UTC) @Wakelamp disruptive edits may be deleted or oversighted. The abuse filter actions can happen alone, or in combination. Abuse filters can trigger on action summaries. An abuse rule that makes a "log" or "tag" does not stop an edit unless it also is set to warn and/or disallow. If an abuse filter is set to private, and it stops an edit it won't be publicly reviewable. You can see all public abuse entries here:Special:Abuselog. — xaosflux Talk 09:37, 28 March 2023 (UTC) @Wakelamp The incidents I typically encounter are a result of reports that show up at WP:AIV as auto-reported by the edit filter. As an admin I try to keep an eye on AIV when I can. IPs are the most common, but sometimes we get newly created accounts that are in most cases socks of already blocked users. In a few cases I've seen some that I was pretty sure were some specie or other of LTA trying to get around the protection on the main article page. Good old-fashioned trolls also pop up now and then. -Ad Orientem (talk) 21:01, 28 March 2023 (UTC)I would prefer not to extend pending-changes to talk pages for two reasons. Talk pages are already much less visible than Article space, so the harm of leaving disruptive content there is far more minimal. And my second reason is user-interface wise, I find pending changes incredibly confusing when there are multiple edits in a row. I never quite fully understand what accepting a change means, if there's disruptive content followed by productive content. An edge case question, do we have Article talk pages that are protected? (I only found User talk pages that were protected), and if so, how are editors supposed to request edits to said Article talk page? {{Edit fully-protected}} can only be transcluded on a talk page for example. ~ 🦝 Shushugah (he/him • talk) 22:24, 28 March 2023 (UTC) do we have Article talk pages that are protected? 129 are semi-protected (see cat, but it includes archives, FAQs, and Wikipedia: namespace pages too), 0 full-protected (cat); mostly happens in WP:CTOPs, mostly very temporary, and: how are editors supposed to request edits, they're not! DFlhb (talk) 22:39, 28 March 2023 (UTC) Relevant bill(s): Text - S.686 - 118th Congress (2023-2024): RESTRICT Act | Congress.gov | Library of Congress and BILLS-118HR1153ih.pdf (house.gov) Relevant analysis by civil liberties organizations: Government Hasn't Justified a TikTok Ban | Electronic Frontier Foundation (eff.org) ACLU Strongly Opposes House Bill that Would Ban TikTok and Threaten First Amendment Rights | American Civil Liberties Union  In short: these bills would allow for US to shut down platforms that it deems to be a risk to national security. There is a lot of coverage about this in the news about a possible ban of TikTok; however, the way the bill is worded can be very very arbitrary, goes beyond TikTok, and can result in serious infringement on the same First Amendment rights that allow Wikipedia to exist in the first place. Wikipedia successfully was able to protest the Stop Online Piracy Act back in 2011, but this may actually be something even bigger. I want to raise this in idea lab before an RfC is made about this. Of course, any RfC to organize a blackout in the United States would require a very strong consensus. We would need to come to consensus on how long the blackout should be and what the blackout message should be. This is relevant because Wikipedia is hosted in the United States and is subjected to US laws, and Wikipedia is committed to rights to freedom of speech. More than 150 million Americans use TikTok, which means that more than 150 million Americans could have their rights to freedom of speech restricted if such a ban was implemented, as well as dozens of small American businesses. As a project, Wikipedia is committed to uncensored, free, open speech. And as such, I believe it is crucial that that right remains open, and that social network platforms used for free speech, even those that may be considered "adverse", are not taken down. That said, I want to figure out what the structure of such hypothetical RfC should be. A blackout should be considered a last measure, but it would be a very effective tool at getting a large number of Americans to understand what is at stake with this legislation. Aasim - Herrscher of Wikis ❄️ 05:23, 27 March 2023 (UTC)  If you want any hope of an RFC getting support, you need to laser focus on how the law would be an existential threat to Wikipedia, written with the same care and sourcing you might bring to a featured article. You're not going to be able to get enough support based on a general "Wikipedia is committed to uncensored, free, open speech" argument to overcome the "no politics ever" faction. Anomie⚔ 11:53, 27 March 2023 (UTC) As a project, Wikipedia is committed to uncensored, free, open speech. - this is... not exactly true. I agree that Wikipedia doesn't care much about "national security", but we certainly exercise censorship of other kinds, for our own reasons. Wikipedia:Hate is disruptive talks about it a bit. 199.208.172.35 (talk) 15:01, 27 March 2023 (UTC) Wikipedia:Free speech is another example of how we don't consider "free speech" when making decisions. Thebiguglyalien (talk) 16:49, 27 March 2023 (UTC) I recommend you all take a look at "EC. 3. ADDRESSING INFORMATION AND COMMUNICATION TECHNOLOGY PRODUCTS AND SERVICES THAT POSE UNDUE OR UNACCEPTABLE RISK." in https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#idfbf26f984311432c8fea2c897ba0c6ba and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#ida5b4cba33bf94543966620a1c4b88d23 and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#ida350534aa5104ba8af5353289a4eff43 and https://www.congress.gov/bill/118th-congress/senate-bill/686/text?s=1&r=15#idfbf26f984311432c8fea2c897ba0c6ba. IANAL, but what I am hearing from TikTok is that this bill, going beyond TikTok, allows for the ban of communications platform that the United States government believes is a risk to national security. This may affect Wikipedia since it (from what I am reading) gives US government power to unilaterally ban Wikipedia if they deem it a threat to national security. I think a lawyer and/or WMF legal should give a proper analysis of this Act to determine whether this actually is a problem for Wikipedia. Even if it isn't, if it could permanently change the notion of freedom of speech in the US, as said in Verge, then it is something that WP should absolutely protest with a blackout. I generally stay out of politics on Wikipedia because Wikipedia:NOTSOAPBOX, but I do wonder if we should follow precedent from the SOPA protest back in 2012 to determine whether we should stage a blackout or not. Aasim - Herrscher of Wikis ❄️ 04:08, 29 March 2023 (UTC) You should also see What experts say a TikTok ban would look like for U.S. users (nbcnews.com) - namely the US has never issued a blanket ban on any app. This does seem like government overreach that is quite concerning. This is going to be a difficult proposal to write, if it is proposed, but it might be something to consider. Aasim - Herrscher of Wikis ❄️ 04:11, 29 March 2023 (UTC) @Thebiguglyalien are you talking about this? Right to free speech just means government can't do anything to block the free flow of information. Private entities like WMF can choose who can speak or not to speak; that is them exercising their right to freedom of speech by letting who they will listen to. Aasim - Herrscher of Wikis ❄️ 04:17, 29 March 2023 (UTC) I'm talking about the fact that Wikipedia's mission is not to babysit free speech in the United States. It is to build an encyclopedia. Unless you have incredibly strong evidence that Wikipedia is going to be imminently banned, I'm going to assume that this is an attempt to disrupt the entire website over a political issue. Thebiguglyalien (talk) 04:53, 29 March 2023 (UTC) Any blackout on its own will be disruptive at some level to readers. The consensus last time there was such a government overreaching potentially free speech violating law (SOPA) was that a blackout would be appropriate. I do think any measure done to protest RESTRICT should be done in a manner that is as least disruptive to the project as possible. That could mean having a full or partial blackout, having a full page banner (which a user could click dismiss to), or running a banner campaign on users in the United States to get people to tell their representatives that RESTRICT can permanently fracture the open Internet. That can certainly be raised in the proposal. As Anomie said, any such proposal has a high chance of success when written with the same rigor as featured articles, otherwise it would be considered a waste of time to most.  Aasim - Herrscher of Wikis ❄️ 12:22, 29 March 2023 (UTC) I support your proposal to protest the banning of online platforms, including TikTok. Even though I detest the despotic regime in China, I think there are other methods to deal with spying than banning foreign media. It's incredible that Congress is considering such authoritarian step, copying behavior of the Soviet Union and Eastern Germany. Thinker78 (talk) 04:24, 29 March 2023 (UTC) I support such a blackout, but freedom of speech really isn't the issue here though. It is still a massive issue for the internet though. It's how this affects the freedom of international communications on the internet. Under this law the US could theoretically enact bans on any internet services affiliated with a country deemed adversarial. While this shouldn't apply to Wikipedia in the most strict reading, neither would SOPA. This law could easily be manipulated by the US government to restrict practically any internet service that it chooses to. It has an incredibly broad scope that could easily affect Wikipedia and the entire internet as a whole. This act is just as big a threat, if not bigger (due to its severe restrictions on foreign communications), to Wikipedia as SOPA was, and I believe that Wikipedia should take similar actions to protest the act as it did with SOPA. Serafart (talk) (contributions) 04:27, 29 March 2023 (UTC) I also endorse such a blackout, for as long as consensus feels is necessary. Loki (talk) 05:35, 29 March 2023 (UTC) There is a discussion taking place at WT:Stand-alone lists regarding whether we should create minimum inclusion criteria for lists involving subjective categorization, to avoid WP:NPOV violations. If interested in contributing, please see the discussion. BilledMammal (talk) 03:45, 29 March 2023 (UTC) Please see the ongoing discussion here]]. BilledMammal (talk) 03:45, 29 March 2023 (UTC)