Wikipedia:Village pump (all)
This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
(to see recent changes on Village pump subpages)
I want... | Then go to... |
---|---|
...help using or editing Wikipedia | Teahouse (for newer users) or Help desk (for experienced users) |
...to find my way around Wikipedia | Department directory |
...specific facts (e.g. Who was the first pope?) | Reference desk |
...constructive criticism from others for a specific article | Peer review |
...help resolving a specific article edit dispute | Requests for comment |
...to comment on a specific article | Article's talk page |
...to view and discuss other Wikimedia projects | Wikimedia Meta-Wiki |
...to learn about citing Wikipedia in a bibliography | Citing Wikipedia |
...to report sites that copy Wikipedia content | Mirrors and forks |
...to ask questions or make comments | Questions |
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Date redirects to portals?
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
By my read of this conversation, there is a consensus that portals are in fact part of the encyclopdia. I don't see a strong consensus on the matter of redirects to them, valid arguments were made all around, so we'll have to just keep muddling through on that point. A narrower discussion specifically about individual dates redirecting to current events portals could possibly yield a different result if there is any appetite for doing that in the future. Just Step Sideways from this world ..... today 03:52, 1 December 2024 (UTC) |
16 August 2006 points to the current events portal as a result of this discussion. However, date redirects will continue to come up at RfD, some some wider community discussion and input is helpful on whether or not the current events portal is an appropriate target for mainspace redirects. See also: this ongoing discussion for some context.
Related questions to consider: are portals "part of the encyclopedia"? Thanks, Cremastra (u — c) 00:55, 30 October 2024 (UTC)
- The second question is easy: Yes, portals are part of the encyclopaedia. As to the first question, portals are reader-facing content and so I see no reason why they wouldn't be appropriate targets for mainspace redirects, given that uncontroversially target mainspace redirects to reader-facing templates and categories when they are the best target. Whether the port is the best target for a given date will depend on the specific date but in general the portal should always be an option to consider. Thryduulf (talk) 01:32, 30 October 2024 (UTC)
- I agree with this. The portal is definitely not always the best option and it has its limitations, but, as I wrote at WP:RDATE it should be considered and assessed along with mainspace articles. Cremastra (u — c) 01:44, 30 October 2024 (UTC)
- Pinging: Utopes, who I've discussed this with.
- Notified: WT:RFD, WT:PORT, WT:CURRENTEVENTS, WT:WPRED. Cremastra (u — c) 01:43, 30 October 2024 (UTC)
- If a namespace doesn't have the same standards as mainspace, then the reader shouldn't be redirected there while possibly not realizing they are now outside of mainspace. Yes, there is more content at Portal:Current events/August 2006 than at 2006#August, but the reader is now facing a decades-old page with no quality control, where links to Breitbart are misleadingly labeled as (AP). Chaotic Enby (talk · contribs) 00:50, 6 November 2024 (UTC)
- Portal does have the same standards as mainspace. That a portal is not up to those standards is no different to an article being in bad shape - fix it. Thryduulf (talk) 00:54, 6 November 2024 (UTC)
- So I can use the speedy A-criteria for portal pages? Fram (talk) 17:40, 7 November 2024 (UTC)
- No, because they are not articles. Two things can be held to the same standard without being the same thing. Criterion P1 previously allowed that (indirectly) but it was repealed in 2023 due to lack of use. Thryduulf (talk) 19:42, 7 November 2024 (UTC)
- Then they aren't held to the same standards... More in general, no, they obviously aren't held to the same standards, e.g. a portal page doesn't have to be a notable topic but may be purely decorative or (as is the case with the date pages) be a list of mainly non-notable things, failing WP:NOTNEWS and WP:LISTN. That some standards are the same (BLP, copyvio, ...) can also be said for e.g. user talk pages, and we don't redirect to these pages either. Fram (talk) 20:24, 7 November 2024 (UTC)
- We don't redirect to user talk pages because they aren't reader-facing, so that's irrelevant. We don't hold reader-facing templates and categories to article content policies (because they aren't articles) but we do redirect to them. Don't conflate quality standards with inclusion policies, they are not the same thing. Thryduulf (talk) 21:15, 7 November 2024 (UTC)
- I wasn´t aware that the standards we were talking about were solely quality standards, whatever these may be, and not content standards, sourcing standards, ... I´m sadly not amazed that you consider these irrelevant when deciding what to present to our readers. Fram (talk) 21:37, 7 November 2024 (UTC)
- We don't redirect to user talk pages because they aren't reader-facing, so that's irrelevant. We don't hold reader-facing templates and categories to article content policies (because they aren't articles) but we do redirect to them. Don't conflate quality standards with inclusion policies, they are not the same thing. Thryduulf (talk) 21:15, 7 November 2024 (UTC)
- Then they aren't held to the same standards... More in general, no, they obviously aren't held to the same standards, e.g. a portal page doesn't have to be a notable topic but may be purely decorative or (as is the case with the date pages) be a list of mainly non-notable things, failing WP:NOTNEWS and WP:LISTN. That some standards are the same (BLP, copyvio, ...) can also be said for e.g. user talk pages, and we don't redirect to these pages either. Fram (talk) 20:24, 7 November 2024 (UTC)
- In theory, I think portals should be held to the same CSD criteria as articles. But of course the A criteria actually only apply to articles. Cremastra (u — c) 22:08, 7 November 2024 (UTC)
- No, because they are not articles. Two things can be held to the same standard without being the same thing. Criterion P1 previously allowed that (indirectly) but it was repealed in 2023 due to lack of use. Thryduulf (talk) 19:42, 7 November 2024 (UTC)
- So I can use the speedy A-criteria for portal pages? Fram (talk) 17:40, 7 November 2024 (UTC)
- Portal does have the same standards as mainspace. That a portal is not up to those standards is no different to an article being in bad shape - fix it. Thryduulf (talk) 00:54, 6 November 2024 (UTC)
- There's a lot of random junk in portalspace, but yes, it is part of the encyclopedia. Just like categories and templates, portals are reader-facing content. C F A 💬
- I didn't really have super strong opinions on portals until seeing this one link to Breitbart, twice, in a misleading way. This is not okay. I agree with Fram that clearly Portals are not being held up to the same standards as regular articles and it might be a bad idea to redirect readers to them. Toadspike [Talk] 23:00, 7 November 2024 (UTC)
- I saw this on CENT, and I am confused by the question. Portal:Current events/2006 August 16 is very different from something like Portal:Belgium, and it doesn't make sense to pretend they are the same to establish policy. And what does "part of the encyclopedia" even mean? "Interpreting a confusing phrase" is a terrible way to decide redirect targets.
For the specific question of "Should dates redirect to the Current Events portal rather than to a page like August 2006 ... I don't know. I don't see a compelling reason why they can't, nor a compelling reason why they should. Walsh90210 (talk) 15:45, 8 November 2024 (UTC)- Hey, that's a nice Portal! Thank you for restoring my faith in portals. Clicking on "Random Portal" took me to Portal:Trees, which is also pretty nice. My opinion is now that yes, portals can be good, but it seems to me that we currently have no Ps and Gs to apply to their content or measure their quality, no consensus about how to direct readers to them, and a very checkered and controversial history of deletion. I really dunno what to do about them. Toadspike [Talk] 16:49, 8 November 2024 (UTC)
- Of course that's a nice portal, look who created it :-D Fram (talk) 17:51, 8 November 2024 (UTC)
- Hey, that's a nice Portal! Thank you for restoring my faith in portals. Clicking on "Random Portal" took me to Portal:Trees, which is also pretty nice. My opinion is now that yes, portals can be good, but it seems to me that we currently have no Ps and Gs to apply to their content or measure their quality, no consensus about how to direct readers to them, and a very checkered and controversial history of deletion. I really dunno what to do about them. Toadspike [Talk] 16:49, 8 November 2024 (UTC)
- No, we should not redirect dates to the current events portal subpages. It's a cross-namespace redirect that takes readers from somewhere they expect to be (an encyclopedia article on the topic "16 August 2006") to somewhere they don't expect to be (a navigational aid(?) that highlights some things that happened that day). I'm not 100% sure what the current events portal subpages are for, but they're not meant to stand in as pseudo-articles in places we lack real articles. Ajpolino (talk) 22:04, 8 November 2024 (UTC)
- Cross-namespace redirects in and of themselves are not a problem. They only cause issues when they take someone expecting reader-facing content to "backroom" content (e.g. project space). Both article and portals are reader-facing content, so this is not an issue. Thryduulf (talk) 22:17, 8 November 2024 (UTC)
- Is there another case where we link a reader from an article to a non-article without clearly denoting it? E.g. I have no problem with the {{Portal}} template folks often use in the See also section. Ajpolino (talk) 01:12, 9 November 2024 (UTC)
- There are lots of redirects to templates and categories. Many navigation templates link to other navigation templates. Thryduulf (talk) 08:12, 9 November 2024 (UTC)
- Any examples of these lots of mainspace pages which are redirects to templates? 08:42, 9 November 2024 (UTC) Fram (talk) 08:42, 9 November 2024 (UTC)
- List of elections in Texas, List of Kentucky county seats, Cite web. Thryduulf (talk) 00:13, 10 November 2024 (UTC)
- Thanks. Okay, Citeweb is a bad example, not something readers look for but something editors look for. The other 2 are among the 6 existing reader facing redirects to templates (from Category:Redirects to template namespace, the only ones which are from mainspace and not editor-related like the cite templates). Not quite the "lots" you seemed to be suggesting throughout this discussion, but extremely rare outliers which should probably all be RfD'ed. Fram (talk) 11:42, 10 November 2024 (UTC)
- Now only 2 remaining, converted the other 4 in articles or other redirects. Fram (talk) 11:52, 10 November 2024 (UTC)
- List of elections in Texas, List of Kentucky county seats, Cite web. Thryduulf (talk) 00:13, 10 November 2024 (UTC)
- Any examples of these lots of mainspace pages which are redirects to templates? 08:42, 9 November 2024 (UTC) Fram (talk) 08:42, 9 November 2024 (UTC)
- There are lots of redirects to templates and categories. Many navigation templates link to other navigation templates. Thryduulf (talk) 08:12, 9 November 2024 (UTC)
- Is there another case where we link a reader from an article to a non-article without clearly denoting it? E.g. I have no problem with the {{Portal}} template folks often use in the See also section. Ajpolino (talk) 01:12, 9 November 2024 (UTC)
- Cross-namespace redirects in and of themselves are not a problem. They only cause issues when they take someone expecting reader-facing content to "backroom" content (e.g. project space). Both article and portals are reader-facing content, so this is not an issue. Thryduulf (talk) 22:17, 8 November 2024 (UTC)
- Yes, the current events portals are valid redirect targets for dates and preferred in this case of the best article redirect for a specific date being the month section of an article on an entire year. I agree with Fram that portals are not held to the same standards as articles, but I disagree with Ajpolino's stance that a cross-namespace redirect is so disruptive that they are prohibited in all cases, given that WP:Portal says "portals are meant primarily for readers." ViridianPenguin 🐧 ( 💬 ) 23:46, 8 November 2024 (UTC)
- Commenting strictly on the "are portals part of the encyclopedia" question, yes it is. Unfortunately there was one extremely loud, disruptive voice who kept making portals less useful and suffocating any discussions that would make it more beneficial to readers. Plenty of willing portal contributors, including myself, left this space and readers are still reaping the seeds of what that disruptive user planted even after they have been ArbCom banned over a year ago. So it may given some people an illusion that portals aren't doing much towards the encyclopedic goal, because the current status is handicapped by its history. I'm reserving my views on the redirect part of the discussion. OhanaUnitedTalk page 07:29, 9 November 2024 (UTC)
- Not, portals are not held to the standards of articles, and if something for whatever reason shouldn't be or can't be an enwiki article, this shouldn't be circumvented by having it in portalspace. Either these date pages are acceptable, and then they should be in mainspace. Or they are not what we want as articles, and then we shouldn't present them to our readers anyway. Fram (talk) 11:42, 10 November 2024 (UTC)
- These current events pages differ from articles in many respects, but the referencing standards are similar. Whether they happen to be prefixed by "Portal:" or not is not reflective of their quality. J947 ‡ edits 23:18, 11 November 2024 (UTC)
- Yes, because the purpose of Portal:Current events/2022 August 21 is to provide encyclopaedic information on 21 August 2022 and this purpose has been by-and-large successful. J947 ‡ edits 23:18, 11 November 2024 (UTC)
- The current events portal example listed seems encyclopedic enough, in that apart from some formatting differences it might as well be a list article, but I've seen other portals that have editor-facing content that is more dubiously appropriate for mainspace. Consider, for example, Portal:Schools § Wikiprojects (capitalization [sic]) and Portal:Schools § Things you can do, and the similar modules at many other portals. Sdkb talk 18:27, 13 November 2024 (UTC)
- Yes per J947, especially given that the current event portals function like an encyclopedic list for the given date. -- Tavix (talk) 16:46, 14 November 2024 (UTC)
- Yes, speaking as a recognized portalista, portals have not yet been excised from the pedia. In this case, User:J947 makes the essential point. I'm not convinced that even incomplete, out-of-date portals are any less encyclopedic than the 2 million or so Wikipedia articles nobody bothered to edit last year. BusterD (talk) 14:53, 19 November 2024 (UTC)
- Portals are not part of the encylopedia as we understand encyclopedias: sources of information. They serve as navigation within an encylopedia. We would not see a Portal as the final delivery of information, any more than we would see a contents page, index, blurb, or advert as the final information page. These are all ancillary. People mostly land on a Wikipedia article page without a Portal. I have used Wikipedia for nearly twenty years without ever needing a Portal to direct me to where I want to go, and I would assume this is true for the majority of people. Redirects are designed as a signpost, and we frown upon a signpost simply pointing to another signpost. People would generally only arrive at a Portal if directed there from a link that should more helpfully point to the appropriate article. The Belgium Portal is mentioned above as a good Portal. If we go to the Belgium article and scroll down, there is a link to the Belgium Portal. But the Portal mainly provides us with a digest of the Belgium article, including a link back to the Belgium article, which itself contains more links to Belgium related articles than the Belgium Portal. Huh? Seriously? Why are we taking readers away from a sublime source, rich with information and links, to an inferior source? There is nothing on the Belgium Portal that is not available on the Belgium article page - including links to news. But there is much on the Belgian article page that is not on the Belgium Portal page. My suggestion is that ALL links to portals such as the Belgium Portal should instead go to the main article page. Why are we redirecting people to a redirect page when we can send them to the main article on the topic? Portals are a waste of our time and resources, and are a misdirect for readers. SilkTork (talk) 22:33, 23 November 2024 (UTC)
- @SilkTork Are you also specifically opposed to redirecting to the current events portal, which is more "encyclopedic" than "navigational"? Cremastra ‹ u — c › 22:44, 23 November 2024 (UTC)
- I'm not exactly comfortable with 2006#August as a target as that itself is a signpost, but I see little value in us having two such signposts - that simply duplicates and confuses things. Either we have 2006#August or we have Portal:Current events/2006 August 16, and I'd much prefer we simply get rid of Portals, so I would obviously opt for 2006#August. SilkTork (talk) 23:02, 23 November 2024 (UTC)
- The CE portal has more information for the reader, so I prefer it (see my arguments at WP:RDATE.) Cremastra ‹ u — c › 23:12, 23 November 2024 (UTC)
- I'm not exactly comfortable with 2006#August as a target as that itself is a signpost, but I see little value in us having two such signposts - that simply duplicates and confuses things. Either we have 2006#August or we have Portal:Current events/2006 August 16, and I'd much prefer we simply get rid of Portals, so I would obviously opt for 2006#August. SilkTork (talk) 23:02, 23 November 2024 (UTC)
- @SilkTork Your argument breaks down as soon as you realise that disambiguation pages and set indexes exist and that redirects to those pages are extremely common and uncontroversial. We also redirect people to outlines, broad concept articles and overviews. What is the "main article page" for a date? In all but a few exceptional cases there isn't a single article but multiple, and so just as if they had searched Mercury, Bitter ash or Stuffed flatbread we present them with a menu of content that is relevant to their search term and let them choose what it is they want to read about. Thryduulf (talk) 22:46, 23 November 2024 (UTC)
- See my answer above. I don't see the point in duplicating signposts. We have Belgium, so we don't need Portal:Belgium; and we have 2006#August so we don't need Portal:Current events/2006 August 16. Signposts are not part of the encyclopedia, but they are navigational aids which lead us to further information. However, we have built into every article multiple signposts to further information. We don't need to have duplicate signposts outside of mainspace to which people are directed away from mainspace to consult. It is a waste of our time and resources, and a misdirection for readers. Internal links are an elegant way of signposting to further information. Navigational templates are a little clunky, but are useful. Portals take readers away from the encyclopedia, and are a pointless timesink for both editors and readers. SilkTork (talk) 23:02, 23 November 2024 (UTC)
- Portals are just as much part of the encyclopaedia as set indexes and navigational templates. Portal:Belgium and Belgium fulfil very different roles in the encyclopaedia, neither is a duplicate of the other. Thryduulf (talk) 23:10, 23 November 2024 (UTC)
- See my answer above. I don't see the point in duplicating signposts. We have Belgium, so we don't need Portal:Belgium; and we have 2006#August so we don't need Portal:Current events/2006 August 16. Signposts are not part of the encyclopedia, but they are navigational aids which lead us to further information. However, we have built into every article multiple signposts to further information. We don't need to have duplicate signposts outside of mainspace to which people are directed away from mainspace to consult. It is a waste of our time and resources, and a misdirection for readers. Internal links are an elegant way of signposting to further information. Navigational templates are a little clunky, but are useful. Portals take readers away from the encyclopedia, and are a pointless timesink for both editors and readers. SilkTork (talk) 23:02, 23 November 2024 (UTC)
- @SilkTork Are you also specifically opposed to redirecting to the current events portal, which is more "encyclopedic" than "navigational"? Cremastra ‹ u — c › 22:44, 23 November 2024 (UTC)
Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept
Specifically, WP:NBAND #5 and #6, which read:
5.) Has released two or more albums on a major record label or on one of the more important indie labels (i.e., an independent label with a history of more than a few years, and with a roster of performers, many of whom are independently notable).
6.) Is an ensemble that contains two or more independently notable musicians, or is a musician who has been a reasonably prominent member of two or more independently notable ensembles. This should be adapted appropriately for musical genre; for example, having performed two lead roles at major opera houses. Note that this criterion needs to be interpreted with caution, as there have been instances where this criterion was cited in a circular manner to create a self-fulfilling notability loop (e.g., musicians who were "notable" only for having been in two bands, of which one or both were "notable" only because those musicians had been in them.)
These appear to have been put together by a very small number of editors over a decade ago and hasn't seen much change since then and I feel it's much more lenient than just about anything else. This SNG defines a "label" that has been around for over "a few years" that has a roster of performers as "important". So, any group of people who have released two albums through ANY verifiable label that has exited for more than a few year can end up being kept and this isn't exactly in line with GNG. I believe a discussion needs to be held in order to bring it to GNG expectations of now.
Graywalls (talk) 06:17, 30 October 2024 (UTC)
- Especially given how broadly the various criteria have been "interpreted" in deletion discussions, the best way to go about it is just to deprecate the whole thing. Rely on the GNG for band notability, and if that results in a heap of articles on ephemeral outfits, garage bands and local acts vanishing, huzzah. Ravenswing 09:07, 30 October 2024 (UTC)
- The SNG isn't workable in the age of digital distribution. It's very easy to create "an independent label with a history of more than a few years". If someone wants to suggest a way to reform the SNG, I am open to solutions. But deprecation is a simple alternative if we can't. The GNG is always a good standard because it guarantees we have quality sources to write an article. Shooterwalker (talk) 14:22, 30 October 2024 (UTC)
- I was active in AfD discussions when NBAND was pretty new, and it was useful for dealing with a flood of articles about garage bands and such, but I think our standards in general have tightened up since then, and I agree it is time to review it. There is the possibility, however, that revising NBAND may require as much discussion as revising NSPORT did. Donald Albury 17:49, 30 October 2024 (UTC)
- This sounds reasonable. I guess we need some concrete re-write suggestions to base an rfc on. Gråbergs Gråa Sång (talk) 18:17, 30 October 2024 (UTC)
- It sounds like you're assuming that NBAND is meant to be a substitute for the Wikipedia:General notability guideline. That's true for some WP:Subject-specific notability guidelines but not for all of them.
- I guess the underlying question is: Is there actual harm in having a permastub about a band that proves to be borderline in GNG terms? Consider this:
"Alice and Bob are a musical duo in the science fiction genre.[1] They released their first album, Foo, in 2019 and their second, Bar, in 2020. Both albums were released by Record Label.[2] They are primarily known for singing during a minor event.[3]"
- I'm asking this because I think that the nature of sources has changed, particularly for pop culture, since NBAND and the GNG were written. We now have subjects that get "attention from the world at large", but which aren't the Right™ kind of sources and, while these Wrong™ sources definitely provide "attention", some of that attention might not provide biographical information (which means we're looking at a short article).
- For example, instead of getting attention in the arts section of a daily newspaper, they're getting attention from Anthony Fantano on YouTube. He's an important music critic,[1] but I suspect that our knee-jerk reaction is "Pffft, just some YouTuber, totally unreliable". Consequently, we might rate a band that we theoretically intend to include ("attention from the world at large") as not meeting the GNG (because the whole field relies on the Wrong™ style of sources). WhatamIdoing (talk) 19:02, 30 October 2024 (UTC)
- Keep in mind that like most other notability guidelines, it is a presumed assumption that a topic is notable if it meets these criteria. If you do an exhaustive Before and demonstrate there is no significant coverage beyond the sourcing to satisfy there criteria, the article should still be deleted. None of the SNGs are geared towards preventing this type of challenge. — Masem (t) 19:30, 30 October 2024 (UTC)
- If we had to yield to presumptive notability about some random band because it released two albums with Backyard Trampoline Recordings established few years ago and had to do exhaustive search to disprove notability, we're getting setup for a situation where removal is 10x more challenging than article creation. So.. I see a great value in scrapping NBAND 5, and 6. Graywalls (talk) 00:47, 31 October 2024 (UTC)
- Welcome to WP:SNGs. As Masem said, they're supposed to be a rough idea of gauging notability before exhaustively searching for sources. But pretty much all of them have ended up being used as means to keep articles about trivial or run-of-the-mill subjects. Thebiguglyalien (talk) 19:37, 30 October 2024 (UTC)
Graywalls listed two criteria but the main discussion seems to be about the 1st (#5). I agree with Graywalls on that. With the evolution of the industry, the label criteria is no longer a useful indicator as it once was and IMO #5 should be removed or modified. Sincerely, North8000 (talk) 19:13, 30 October 2024 (UTC)
- I agree, both those criteria should be scrapped. JoelleJay (talk) 22:21, 30 October 2024 (UTC)
- I've noticed that as well. I think #6 has some value still, while #5 is like saying an author who has published two or more books by a major publishing house is presumed notable. Way too low a bar without requiring some level of reception of those albums/books. (WP:NAUTHOR doesn't have that 2-book criteria, of course, just seems like parallel benchmarks.) Schazjmd (talk) 13:25, 31 October 2024 (UTC)
- On the other hand, in this case, I suspect that an artist that "has released two or more albums on a major record label or on one of the more important indie labels" will in 99% of cases have enough coverage to clear the GNG bar. I'd like to see an example of one that doesn't. Black Kite (talk) 13:29, 31 October 2024 (UTC)
- The definition of important as said in #5 is "history of more than a few years, and with a roster of performers, many of whom are independently notable". This would mean that a garage band is notable, because they've released two CD-R albums on Rotten Peach Recordings which has been around for 3 1/2 years, has a roster of performers and some of whom have a Wikipedia page on them. Often time "notable" is determined by the presence of a stand alone Wikipedia page. When you look at the page, many band member pages are hopelessly non-notable, but removal takes an AfD. So a simple deletion can become a time consuming multi-step AfD. Graywalls (talk) 19:18, 31 October 2024 (UTC)
- Here's a current AfD I am participating in where NBAND#5 was invoked to justify a keep. Wikipedia:Articles_for_deletion/Sons_of_Azrael_(3rd_nomination) Graywalls (talk) 19:24, 31 October 2024 (UTC)
- Not opining on that band's notability, but Metal Blade is a famous independent label that has existed for 42 years, has released material by very high-profile bands, and is distributed by Sony - it's not some one-person imprint operating out of their garage. Black Kite (talk) 11:28, 1 November 2024 (UTC)
- I concur regarding that particular example. Metal Blade is a big label, and not surprisingly notability was quickly demonstrated in the deletion discussion through citing reliable source coverage. And that's how #5 should work - artist is on a significant label, which suggests coverage exists. And then coverage is found.--3family6 (Talk to me | See what I have done) 12:08, 16 November 2024 (UTC)
- Not opining on that band's notability, but Metal Blade is a famous independent label that has existed for 42 years, has released material by very high-profile bands, and is distributed by Sony - it's not some one-person imprint operating out of their garage. Black Kite (talk) 11:28, 1 November 2024 (UTC)
- It's complicated - on the one hand, music publications are increasingly prioritizing their coverage toward Taylor Swift-level celebrities, so I am almost certain there are artists on major labels that might be examples -- major as in the Big 3. This is especially so for genres like country that publications don't cover as much - there are some big names on the roster of Warner Music Nashville and also some not-so-big names.
- The elephant in the room here is that entertainment journalism is in crisis mode right now, publications are operating on skeleton crews, and the range of coverage has narrowed dramatically. I encourage everyone taking part in this discussion to read the article I linked, there are a lot of assumptions being made about the way things work that aren't true. Gnomingstuff (talk) 20:30, 19 November 2024 (UTC)
- On the other hand, in this case, I suspect that an artist that "has released two or more albums on a major record label or on one of the more important indie labels" will in 99% of cases have enough coverage to clear the GNG bar. I'd like to see an example of one that doesn't. Black Kite (talk) 13:29, 31 October 2024 (UTC)
- One suggestion I would add is to make these two criteria apply only to bands before a specific year, that year being where physical releases still dominated over digital sales. I don't know the exact year but I am thinking it's like around 2000 to 2010. There may still be older groups during the time of physical releases that don't yet have articles that would fall into one of these criteria. Masem (t) 20:02, 31 October 2024 (UTC)
- As someone who's had WP:DSMUSIC watchlisted for most of their editing history, and who tends towards deletion at that, I actually don't see much of a problem with these criterions. It certainly seems true that the majority of musicians who are signed to a label or a member of multiple bands with two other musicians who meet WP:GNG themselves meet GNG. I do think it is sometimes justified to accept less-than-GNG sourcing in articles where a SNG is met (see Wikipedia:Articles for deletion/John LeCompt for this as it applies to c6 specifically) and more importantly, NMUSIC contains language that allows deleting articles even where it is technically met (see Wikipedia:Articles for deletion/Rouzbeh Rafie for an extended argument about that. Mach61 23:29, 31 October 2024 (UTC)
- I've understood these criterion to be supplementing GNG, that is, that if a band or individual artist meets one or more of these criterion, they *likely* are notable. However, in the past when I was a younger and less experienced editor, I think I did understand these as being additions or alternatives to GNG. So I think that should be clarified. This has come up on the deletion discussion for Jayson Sherlock. He is a member or former member of several very notable bands, and for that reason I presumed that he would easily have independent coverage about him specifically. However, to my surprise, there's only one interview of him in a reliable source that would provide notability (there's some interviews on personal blogs or minor sites that wouldn't be RS except for him making statements about himself). But at least one editor has used the above criterion to argue that the article should be kept.--3family6 (Talk to me | See what I have done) 12:20, 1 November 2024 (UTC)
- Just as an aside, interviews do not contribute to GNG unless they include secondary independent SIGCOV (such as a substantial background introduction by the interviewer). JoelleJay (talk) 15:39, 1 November 2024 (UTC)
- Agreed. That's important to note. I was presuming such, and also why I wouldn't rely on a singular interview as the sole source for establish GNG.--3family6 (Talk to me | See what I have done) 16:30, 1 November 2024 (UTC)
- That's how I see most SNGs (and the outliers ought to follow their lead). At the very least, we can clarify that NBAND is meant as an indicator for the GNG, and not a substitute. Shooterwalker (talk) 02:04, 2 November 2024 (UTC)
- As someone who thought the old NSPORTS was wildly overinclusive and needed cleanup... these NBAND guidelines don't seem that bad? If two plainly notable musicians were discovered to have done some obscure team-up in the 1970s, that does indeed seem to be a notable topic and useful to have linked somewhere, even if there isn't tons of info on this collaboration. It's worth mentioning because minor subtopics are often merged to the overarching topic (e.g. songs to the album), but there may not be a clear merge location for this if both parties were equal contributors, and a short separate article is an acceptable compromise. Similarly, the complaint about #5 seems to be about just how "indie" the hypothetical label is, but this seems like a solvable problem. If a band fails GNG, that implies that either their two albums really were from a very obscure indie outfit and thus also fail NBAND, or else that we have some sort of non-English sources issue where we may consider keeping on WP:CSB grounds (i.e. that sources probably do exist to pass GNG, but they're difficult to find, and we can trust they exist because this was a major and notable label releasing the band's work). About the only suggestion I can offer is that the comment in 6 about avoiding circular notability could probably be phrased in the sense of GNG, i.e. that the two notable musicians need to both meet GNG and then this will create a new, safe NBAND notability for their collaboration. SnowFire (talk) 17:36, 4 November 2024 (UTC)
- The reverse situation, such as is currently being discussed at Wikipedia:Articles for deletion/Jayson Sherlock, is one where you have someone who was/is in multiple notable bands, but doesn't have independent coverage about them as an individual person. -- 3family6 (Talk to me | See what I have done) 22:30, 7 November 2024 (UTC)
- Agreed with deprecation; "Rely on the GNG for band notability" is the correct answer. And is the correct answer for many other things about which we have SNGs that attempt to be alternatives to GNG. Perhaps the only justifiable one is WP:NACADEMIC, because special considerations apply in that sphere (academics and other journal-publishing researchers are generally unknown the public and the public-facing media coverage like newspapers but may have major impacts in particular fields and on the world; what determines their influence level is primilar the frequency of citation of their work by other academics). No such special considerations apply with regard to bands or most other categories. We have some SNGs that are helpful because they are written to comply with GNG, to explain predictively what is most likely or unlikely to pass a GNG test at ANI, rather than trying to be an end-run around GNG. If we actually needed an SNG for bands and musicians, then the current SNG for them could be replaced by something like that. However, we don't actually need an SNG for bands and musicians.
PS: The ideas in the current NBAND SNG are daft. Lots of musical acts have multiple albums (i.e. tracks released at the same time under a grouping title) and lots of indie labels (which may just be some dude in his bedroom) exist with multiple acts, some of them nominally notable [because of NBAND's issues, making this a vicious cycle!], but that doesn't actually make every band on that notional label (nor the label itself) enclopedia-worthy. Some of these are farcically obscure acts [not a denigration – I'm probably buying their stuff]. This is not 1977; you do not need a vinyl pressing plant to be a music label. You just need to figure out how to fill in a web form at Bandcamp and Spotify, and have enough of a clue about how the present music industry works (often just within a narrow subculture) that you can convince some acts (probably your friends in the same scene) that you can help them if they agree to be on your roster. PPS: A side issue is that "albums" isn't a good metric anyway, since several genres are not album-driven at all, and the entire notion of albums is being increasingly questioned in the era of on-demand music. — SMcCandlish ☏ ¢ 😼 21:59, 15 November 2024 (UTC)
I'd be happy to see #5 and #6 completely eliminated. What does it take to make that happen? What's the next step? Graywalls (talk) 02:08, 16 November 2024 (UTC)
- If you believe this would amount to a major change to the guideline, then you should probably be making a formal WP:PROPOSAL. WhatamIdoing (talk) 04:52, 16 November 2024 (UTC)
- WhatamIdoing, would clarifying that SNG don't override GNG requirements be a major change?--3family6 (Talk to me | See what I have done) 11:57, 16 November 2024 (UTC)
- Yes. And if you want to try that, you should find and read the many previous discussions about that. WhatamIdoing (talk) 19:27, 16 November 2024 (UTC)
- See WP:NPLACE, which presumes populated legally recognized places are notable. So, all it takes is prove the legal recognition and presence of people and it's assumed to be notable, unless refuted.
- A legally recognized city is presumed, but not guaranteed notable. If it doesn't meet GNG, then the presumed notability can be refuted. It does essentially "override" GNG though a short cut, but is subject to removal by presenting failure to meet GNG.
- Such presumption is not present for most things. For example, simply quoting a local paper about a gas station opening up and operating demonstrates existence of that gas station, but there's no presumed notability for businesses.
- NBAND 5 and 6 qualifies bands and albums into Wikipedia far easier than they should and they stand as a burden to article deletion due to presumed notability under tenuously defined importance, such as having released two albums through an important indie label Four Legged Octopus, which is "important" because the MailBox Etc based label has been around for five years and has a roster. Graywalls (talk) 16:55, 18 November 2024 (UTC)
- WhatamIdoing, would clarifying that SNG don't override GNG requirements be a major change?--3family6 (Talk to me | See what I have done) 11:57, 16 November 2024 (UTC)
- Not speaking to this issue directly, but the trend in subject specific guidelines, IMHO, has been to reduce the influence of SNGs relative to GNG, not override. When we started these projects 20 years ago, almost every article was low hanging fruit, almost bound to be found notable eventually. As an example, Military History Wikiproject adopted and modified WP:SOLDIER, a set of specific and non-subjective criteria which if met gave an indication of presumption of reliable sources being found somewhere eventually. This was intended to screen out a lot of "dead veteran I know" articles, not become the floor for inclusion. When it finally came up for discussion it was made clear SOLDIER was just a project thing and wasn't itself an approved SNG. It was quickly decommissioned, but SOLDIER criteria was for many years a frequently mentioned keep argument at AfD. As another example, WP:SPORTSPERSON is another project related shorthand (but consensus-approved SNG), which made it more difficult to create and keep articles about athletes without at least one source with significant coverage, which still seems a low bar indeed. IMHO the original intent of such SNGs was to screen article candidates, but as the pedia grew, we started using SNGs to keep them. Adjusting SNGs to meet the modern usage era seems the practical and accepted path. The medical SNGs are still used as exclusionary, and for the best reasons. BusterD (talk) 15:21, 19 November 2024 (UTC)
IMHO the original intent of such SNGs was to screen article candidates, but as the pedia grew, we started using SNGs to keep them.
As someone who joined 10 years in, this seems to have been the trend.--3family6 (Talk to me | See what I have done) 18:20, 19 November 2024 (UTC)- Yes, in my opinion SNGs should be exclusionary criteria, necessary but not sufficient for notability. JoelleJay (talk) 23:02, 20 November 2024 (UTC)
- Agreed, and this makes a lot more sense to me. I haven’t paid much attention to SNGs till recent years, so it has been my impression that they are applied as supplemental options towards keeps and creates. The only one that I even think of as exclusionary is WP:NEVENT, although that’s got its own difficulties inherent.
- Ideally I’d like to see every AfD “SNG-therefore-keep” voter back their rationale up by saying that they endorse the SNG by its likelihood toward sources existing. — HTGS (talk) 22:34, 21 November 2024 (UTC)
Blind 1RR/3RR
Blind enforcement of 1RR/3RR does not serve the project. The question should not be whether one violated the rule, but whether they violated the rule in a way that does not benefit the article. If there is no objection to the violation, we can reasonably assume that they are benefiting the article, or at least causing no harm. The decision should be left in the hands of other editors. Could this be used as a weapon? Would there be editors who claim harm where none exists? Certainly, but that's preferable to what we have now.
The problem, no doubt familiar to editors reading this, is that there are often not enough "good" editors around to protect an article from "bad" editors (malicious or merely inexperienced) while staying within 1RR/3RR. There is no restriction on the number of BOLD edits by a given editor, or on the number of editors performing BOLD edits. ―Mandruss ☎ 00:09, 10 November 2024 (UTC)
- 1RR in contentious areas should be fully maintained, with no exceptions. Otherwise, edit wars will quickly develop. GoodDay (talk) 00:11, 10 November 2024 (UTC)
- If someone is repeatedly reverting reverts, then there is objection to the violation by definition. That's what edit warring is. If someone is making the same BOLD edit that needs to be reverted multiple times, then they are also edit warring. There are already exceptions with these rules for patent nonsense or obvious vandalism. If there's routine disruption, then it only makes the problem worse to revert over and over instead of taking it to WP:RFPP. If you feel the need to make more than one or two reverts in a content dispute, then it's time to either consider other options or step away from the article. Thebiguglyalien (talk) 01:31, 10 November 2024 (UTC)
- It's not about edit warring or re-reverts; the problem exists without a single re-revert. Editor A does ten BOLD edits, five of which are detrimental to the article because they are too inexperienced (this stuff takes years to master, so that's far from uncommon). Editors B, C, D, and E contribute an additional twenty detrimental edits (along with any number of good ones, that number being irrelevant for our purposes here). Meanwhile, competent editors F, G, and H are limited to a total of nine reverts, leaving 21 detrimental edits in the article. I say F, G, and H should be allowed to revert until someone claims they are doing harm. ―Mandruss ☎ 02:04, 10 November 2024 (UTC)
- Where are you seeing thirty detrimental edits to an article in every day? Why isn't this article protected? Why aren't editors F, G, and H starting a discussion? Why are they reverting Editor A's edits individually instead of rolling them back? Why is it so urgent that these edits need to be reverted right this moment? Even on the off chance that they encounter such an article that exists, F, G, and H would not need to engage in tag-team reverting (which is still edit warring) if they knew what they were doing. Thebiguglyalien (talk) 02:07, 10 November 2024 (UTC)
- You are welcome to reduce the numbers as you please; the problem exists regardless. The article is protected, even with ECP, and there is no shortage of registered editors who have 30 days and 500 edits and still have years to go before they are editing with any reasonable level of competence. Some never reach that point.
Why aren't editors F, G, and H starting a discussion?
Seriously?Why are they reverting Editor A's edits individually instead of rolling them back?
Because (1) they may not have the rollback right, and the rollback right should not be required to function as an editor, (2) they would be rolling back five good edits, and (3) it's impossible if Editor A's edits are interleaved with those of any other editor(s).Why is it so urgent that these edits need to be reverted right this moment?
Because (particularly in large and very active articles) the bad edits can easily be missed if not caught immediately. Then they stay in the article for some unknown amount of time until noticed by a competent editor and corrected with a BOLD edit. Could be months or even years. Is that good for the article? ―Mandruss ☎ 02:27, 10 November 2024 (UTC)they may not have the rollback right
: Not the main point of this thread, but Wikipedia:Twinkle has its verison of rollback, available for any registered user.—Bagumba (talk) 04:57, 10 November 2024 (UTC)- Could you give an example or two where this has caused a problem? And I note that you have answered the two most important questions inadequately: if an article is subject to edit-warring it should be fully protected, and you dismissed "Why aren't editors F, G, and H starting a discussion?" with "Seriously?". Yes, of course it's a serious question. Starting a discussion is the best way of defusing an edit war. Phil Bridger (talk) 09:20, 10 November 2024 (UTC)
- "Seriously?", while counter to the WP:DR policy, might be an honest response. I often get page protection or block requests, where my first response is often "where's the discussion?" —Bagumba (talk) 10:02, 10 November 2024 (UTC)
- Unless Mandruss is extremely lazy, for which I have no evidence, I don't see how that response can be honest. It only takes a few seconds to start a discussion, no longer than it took to start this one, and the person who starts it wins some extra points. Phil Bridger (talk) 17:08, 10 November 2024 (UTC)
extremely lazy, for which I have no evidence
Thank you! I have my share of faults and shortcomings, but I don't think extreme laziness is one of them. So there should be new discussions for each of the bad edits (separately for the sake of efficiency and organization), and the bad edits should remain in the article until enough editors have the time, interest, and attention span to form consensuses against them while attending to other important matters. This, at an ATP where we're struggling to keep the ToC at a manageable size even without such discussions. I don't know what articles you're editing, but I want to work there. ―Mandruss ☎ 03:51, 11 November 2024 (UTC)- Did you seriously just point to Donald Trump as your example and then say you don't know what articles aren't like that Thebiguglyalien (talk) 04:01, 11 November 2024 (UTC)
- I gather the Donald Trump article is a rare anomaly where bad content is something we have to live with because the current rules are incapable of preventing it. After all, it's just one article. I would oppose that reasoning. I'd say article quality is at least as important there as anywhere else. ―Mandruss ☎ 04:33, 11 November 2024 (UTC)
So there should be new discussions for each of the bad edits ...
: Yes, or what is an alternative? Your suggestion to favor "good" edits over "bad" is problematic when everyone says their's are the "good" ones. Polarizing topics can be difficult for patrolling admins to WP:AGF determine "good" v. "bad" edits if they are not subject matter experts.—Bagumba (talk) 05:43, 11 November 2024 (UTC)
- Did you seriously just point to Donald Trump as your example and then say you don't know what articles aren't like that Thebiguglyalien (talk) 04:01, 11 November 2024 (UTC)
- Unless Mandruss is extremely lazy, for which I have no evidence, I don't see how that response can be honest. It only takes a few seconds to start a discussion, no longer than it took to start this one, and the person who starts it wins some extra points. Phil Bridger (talk) 17:08, 10 November 2024 (UTC)
- "Seriously?", while counter to the WP:DR policy, might be an honest response. I often get page protection or block requests, where my first response is often "where's the discussion?" —Bagumba (talk) 10:02, 10 November 2024 (UTC)
- You are welcome to reduce the numbers as you please; the problem exists regardless. The article is protected, even with ECP, and there is no shortage of registered editors who have 30 days and 500 edits and still have years to go before they are editing with any reasonable level of competence. Some never reach that point.
- Remember that consecutive edits by a single editor are treated as a single revert for WP:3RR purposes. So, in your case, editor H can go back and revert the various bad edits and, even if they mechanically break it out into multiple edits, they still have done one revert... Until someone goes back and re-reverts. Simonm223 (talk) 19:58, 20 November 2024 (UTC)
- Where are you seeing thirty detrimental edits to an article in every day? Why isn't this article protected? Why aren't editors F, G, and H starting a discussion? Why are they reverting Editor A's edits individually instead of rolling them back? Why is it so urgent that these edits need to be reverted right this moment? Even on the off chance that they encounter such an article that exists, F, G, and H would not need to engage in tag-team reverting (which is still edit warring) if they knew what they were doing. Thebiguglyalien (talk) 02:07, 10 November 2024 (UTC)
- It's not about edit warring or re-reverts; the problem exists without a single re-revert. Editor A does ten BOLD edits, five of which are detrimental to the article because they are too inexperienced (this stuff takes years to master, so that's far from uncommon). Editors B, C, D, and E contribute an additional twenty detrimental edits (along with any number of good ones, that number being irrelevant for our purposes here). Meanwhile, competent editors F, G, and H are limited to a total of nine reverts, leaving 21 detrimental edits in the article. I say F, G, and H should be allowed to revert until someone claims they are doing harm. ―Mandruss ☎ 02:04, 10 November 2024 (UTC)
- If "do not repeat edits without consensus" were the rule (rather than "do not revert"), it would take care of this problem. Levivich (talk) 03:42, 10 November 2024 (UTC)
- Who said anything about repeated edits? Am I missing something? I'm tired at the moment, so that's a possibility. ―Mandruss ☎ 04:04, 10 November 2024 (UTC)
- What do you mean, who said? I said something about repeated edits :-) If the rule were "do not repeat edits without consensus" 1x or 3x in 24 hours, instead of "do not revert" 1x or 3x in 24 hours (which leads to the whole "what exactly counts as a revert?" issue), the problem you are describing would not happen. The 'bad' editor can make 10 bad edits, and the 'good' editor can revert all 10 edits without violating do-not-repeat-3RR, and the 'bad' editor would be able to repeat 3 of those 10 edits without crossing do-not-repeat-3RR, and the 'good' editor can revert all 3 of those without crossing do-not-repeat-3RR, et voila: equilibrium. The problem is we focus on "revert" instead of "repeat." To tamp down on edit warring, we should prohibit people from repeating their edits, not from "reverting" (whatever that means, exactly) edits. Levivich (talk) 04:50, 10 November 2024 (UTC)
- Well I'll have to come back after a sleep and try to comprehend that. ―Mandruss ☎ 04:56, 10 November 2024 (UTC)
- What do you mean, who said? I said something about repeated edits :-) If the rule were "do not repeat edits without consensus" 1x or 3x in 24 hours, instead of "do not revert" 1x or 3x in 24 hours (which leads to the whole "what exactly counts as a revert?" issue), the problem you are describing would not happen. The 'bad' editor can make 10 bad edits, and the 'good' editor can revert all 10 edits without violating do-not-repeat-3RR, and the 'bad' editor would be able to repeat 3 of those 10 edits without crossing do-not-repeat-3RR, and the 'good' editor can revert all 3 of those without crossing do-not-repeat-3RR, et voila: equilibrium. The problem is we focus on "revert" instead of "repeat." To tamp down on edit warring, we should prohibit people from repeating their edits, not from "reverting" (whatever that means, exactly) edits. Levivich (talk) 04:50, 10 November 2024 (UTC)
- Who said anything about repeated edits? Am I missing something? I'm tired at the moment, so that's a possibility. ―Mandruss ☎ 04:04, 10 November 2024 (UTC)
Blind enforcement of 1RR/3RR does not serve the project
: Are you referring to page protection or blocks? On contentious topics or any subject? —Bagumba (talk) 05:11, 10 November 2024 (UTC)
What determines "global consensus"?
This ArbCom resolution established that "Where there is a global consensus to edit in a certain way, it should be respected and cannot be overruled by a local consensus."
I would like to ask what is the standard for defining that there is global consensus. If the top 100 articles in a certain category all are written in a certain way, is this considered sufficient for global consensus?
If a 100 articles are not enough, what is the threshold? Is it proportional to the number articles in that category?
Should then this warrant that all articles in that category be written in that way (unless very clearly harmful to the specific article)?
Milo8505 (talk) 10:41, 17 November 2024 (UTC)
- WP:CONLEVEL was already a policy, independent of that resolution. It was just being cited as a principle used in deciding that case. —Bagumba (talk) 16:03, 17 November 2024 (UTC)
- I believe that "global consensus" refers to policies and guidelines in particular, and to generally accepted practices across the whole of the English Wikipedia. A consensus that applies to just 100 articles out of the almost 7 million article in the English Wikipedia is a local consensus. Donald Albury 16:14, 17 November 2024 (UTC)
- Milo8505, you asked this question in a way that can't be answered. Consensus does not depend on categories, and Wikipedia does not deal in abstract quantities but in concrete articles. Is this about whether to have an infobox on Gustav Mahler? If so then please say so, to provide some context to your question. Phil Bridger (talk) 17:34, 17 November 2024 (UTC)
- @Phil Bridger Yes, it is about that topic. I believe that there is sufficient global consensus about the inclusion of infoboxes on biographies. I am well aware that the official policy is "no policy defined", but I see a clear trend, by looking at the most read articles, that all biographies - of musicians and non musicians alike - have an infobox, except a select few classical music composers.
- I do not currently have the whole information regarding exactly how many of all biographies have an infobox, and that is why I was asking what is usually considered consensus.
- However, given that I'm very aware that a hundred articles out of seven million is not precisely consensus, I will attempt, when I have the time, to go through every single biography to determine an exact percentage.
- Milo8505 (talk) 18:56, 17 November 2024 (UTC)
- If you want to spend your time doing that then I can't stop you, but I warn you that you will be wasting your time. That is not how consensus is measured. Phil Bridger (talk) 19:10, 17 November 2024 (UTC)
- Obviously I will not count by hand, I have some idea of how to use an automated tool to do that.
- But then, how is consensus measured?
- I'm under the impression that there is a group of very determined and very vocal editors that fiercely oppose infoboxes on classical composers' articles (which leads to most of them having discussions about infoboxes, citing each other as examples of articles without infobox), separate from the majority of biographies, which have an infobox.
- I see no better way of proving (or maybe disproving) my point than this, because my earlier points of infoboxes being a great thing for Gustav Mahler's article, and the fact that numerous non-classical musicians have infoboxes, and lengthy ones at that, seem to have fallen on deaf ears.
- Milo8505 (talk) 20:01, 17 November 2024 (UTC)
- And I would like to state, for the record, that I'm not doing this out of spite, or out of a personal interest (I'm actually losing my time by arguing about this), but because I truly, wholeheartedly believe that an infobox on each and every biography, and in general, on every article where there could be one (this excludes abstract topics such as existencialism) would make Wikipedia a truly better place.
- Milo8505 (talk) 20:43, 17 November 2024 (UTC)
- I would have to search the archives, but we actually held an RFC (one of the ways in which we determine GLOBAL consensus) that was focused on whether to mandate infoboxes on articles about composers… which determined that there were valid reasons not to require them (I suppose you could say that global consensus was to defer to local consensus on this specific issue). Remember WP:Other Stuff Exists is not an accepted argument here at WP. And that “standard practice” often has exceptions. Blueboar (talk) 22:06, 17 November 2024 (UTC)
- I understand, but that is not my sole argument. I have provided other arguments in favor, which you can read at the aforementioned talk page which basically boil down to:
- in my opinion,
- Infoboxes make standardized information more easily accessible, and
- They do not harm the rest of the article, as they do not displace the lead paragraph.
- However, in the linked talk page, I see that opponents of infoboxes rely somewhat on the loosely established precedent/consensus that composers shouldn't have infoboxes.
- That is why I wanted to bring forth a new argument, using the, as I see it, very established consensus for infoboxes in biographies, and what I want to know here is whether this consensus can be proven to exist (or what is it required for this consensus to exist). Milo8505 (talk) 07:30, 18 November 2024 (UTC)
- Info boxes can be accessibility issue for many readers and display what can only be described as clutter and unnecessary Wikipedia talk:Manual of Style/Infoboxes#Infobox file spam. That said there's clearly a community consensus I believe overall. Moxy🍁 22:39, 1 December 2024 (UTC)
- This whole thing about "global" and "local" consensus seems to confuse everyone, and consequently folks make up whatever seems plausible to them. Let me give you a potted history and the usual claims, and perhaps that will help you understand the principle.
- 'Way back in the day, infoboxes didn't exist. AIUI the first widely used infobox template was {{taxobox}} in 2004, and the general concept appeared soon after. However, through the end of 2007, Template:Infobox didn't look like what we're used to. Originally, an 'infobox template' was literally a wikitext table that you could copy and fill in however you wanted.[1]
- While infoboxes were being developed, the editors at Wikipedia:WikiProject Composers decided that infoboxes were a bad idea specifically for articles about classical composers, so after a series of disputes and discussions, in April 2007 they wrote a note that said, basically, "BTW, the sitewide rules don't apply to the articles we WP:OWN."[2]
- The conflict between this group and the rest of the community eventually resulted in the 2010 Wikipedia talk:WikiProject Composers/Infoboxes RfC. The result of this years-long dispute is memorialized in the example given in what is now the Wikipedia:Consensus#Levels of consensus section of the policy: "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale. For instance, unless they can convince the broader community that such action is right, participants in a WikiProject cannot decide that some generally accepted policy or guideline does not apply to articles within its scope."
- Or, to be rather more pointy-headed about it: WikiProject Composers doesn't get to decide that "their" articles are exempt from MOS:INFOBOXUSE.
- What was then a statement about the "Purpose of consensus" or, before then, one of several "Exceptions" to forming a consensus on a talk page has since been renamed ==Levels of consensus==. Also, ArbCom (and consequently part of the community) has started talking about "global" consensus. I think that has confused people about the point.
- "Levels" of consensus could mean the strength of the consensus ("This is just a weak consensus, so..."). It could mean something about the process used ("My CENT-listed RFC trumps your Village pump post"). It could mean whether the consensus applies to the whole site ("We formed a consensus at Talk:Article about the first sentence of Article, so now I need to make 500 other articles match this one"). And it could tell us something about how likely it is that the decision matches the overall view of the community.
- It's supposed to be that last one. We don't want a handful of people getting together on some page and saying "Let's reject this rule. This article needs to be censored. Copyvio restrictions are inconvenient. Bold-face text helps people see the important points. And we know this POV is correct, so it should dominate." We want quite the opposite: "The community says that this is usually the best thing, so let's do this."
- AFAICT, the overall view of The Community™ is that we think that there should not be any Official™ Rule saying that any subset of articles should have an infobox. We're probably doing this mostly for social reasons, rather than article reasons. For example, every single article about a US President, or atomic elements, or any number of other subjects, has an infobox – but we refuse to write any rule saying they should, or even that they usually should, even though we know the popularity is ever-increasing. For example, at the moment, Georgina Sutton is the only biography linked on the Main Page that doesn't have an infobox.
- I suspect that the closest we will come to such a rule during the next few years is a note about how popular they are. It should be possible to see how many articles (overall, or in particular subsets) already use infoboxes, and to add that information to MOS:INFOBOXUSE. For now, we could add a statement that "most" articles have an infobox.
- I would have to search the archives, but we actually held an RFC (one of the ways in which we determine GLOBAL consensus) that was focused on whether to mandate infoboxes on articles about composers… which determined that there were valid reasons not to require them (I suppose you could say that global consensus was to defer to local consensus on this specific issue). Remember WP:Other Stuff Exists is not an accepted argument here at WP. And that “standard practice” often has exceptions. Blueboar (talk) 22:06, 17 November 2024 (UTC)
- If you want to spend your time doing that then I can't stop you, but I warn you that you will be wasting your time. That is not how consensus is measured. Phil Bridger (talk) 19:10, 17 November 2024 (UTC)
- ^ Being able to do this in wikitext was was considered an improvement, because originally, you had to code tables in raw HTML.
- ^ This was not as unreasonable back then as it sounds now. WikiProjects were a significant source of subject-specific advice back then, and the rule-making systems were quite informal. WP:PROPOSAL didn't exist until late 2008. Before then, most guidelines and even policies acquired their labels merely because someone decided to slap the tag on it, and if nobody objected, then that was the consensus for what to call it.
- WhatamIdoing (talk) 22:27, 17 November 2024 (UTC)
- Thank you very much for your detailed response.
- From what you have said, given that WikiProject composers have to follow MOS:INFOBOXUSE, there should be a discussion on each and every composer's talk page to determine whether an infobox is warranted.
- I see this as a bit of a, difficult and fruitless endeavor, as the arguments presented, for either case, are always the same, and they all usually result in stalemates (like the one about Mahler).
- What I propose is to change the policy, to, at least, recommend infoboxes on certain categories, given that, as you said, they are very popular. Or at the very least, as you suggest, acknowledge the fact that they are very popular.
- When I have time to gather more data on the use of infoboxes, I will propose a new RfC to try to commit this change to the policy.
- I am very well aware that my chances of success are slim, but, I'll do what I can do.
- Milo8505 (talk) 08:00, 18 November 2024 (UTC)
- Well, if "they all usually result in stalemates", then that represents a change, because the last complaint I saw about this subject said that the RFCs on whether to add an infobox almost always resulted in an infobox being added. Perhaps it varies by subject, however.
- Acknowledging that they're popular shouldn't require a proposal for a change. It should only require getting some decent numbers. Check the archives of WP:RAQ; they probably can't query it directly, but if there's been a request, you'll see what could be done. It might also be possible to create a hidden category for "All articles with infoboxes", automagically transcluded, to get a count on the number of infoboxes. WhatamIdoing (talk) 06:45, 20 November 2024 (UTC)
- First of all, thank you again very much for your continued interest.
- The discussions around infoboxes (not RfCs, discussions on talk pages) as far as I have seen usually go something like:
- - I propose adding an infobox
- + We have talked a lot about that and there are good reasonstm for which it should not be added
- - But I also have good reasonstm for which it should be added.
- (no comments for 4 years, then it begins again).
- I thought a bit about counting links, and I realized maybe getting this data is easier than I thought, see:
- For counting the number of transclusions to a given page, this tool is very useful, and says that there are around 3.2 million infoboxes in total, and 460 thousand infoboxes about people. (on the (Article) namespace).
- Looking in the Talk namespace, there are around two million links to Template:Wikiproject Biography.
- This seems to suggest that only around a quarter of all biographies have an infobox? Maybe I was wrong all along in my observation that infoboxes are very popular.
- I am however not too sure that the two million links to Template:Wikiproject Biography on the Talk namespace actually corresponds to two million unique biographies.
- Maybe another way of getting this data would be better, I'll have to look at it on some other occasion that I have more time.
- Milo8505 (talk) 11:28, 20 November 2024 (UTC)
- I looked at the first 10 articles in Category:Core biography articles, and 100% had infoboxes. However, those ten articles used seven different infoboxes:
- Category:People and person infobox templates lists dozens. WhatamIdoing (talk) 23:22, 21 November 2024 (UTC)
- Yes! Yes!
- That's my point. Most[citation needed] good biographies have an infobox - except those of classical composers.
- I will look at the category you mentioned and try to count from there.
- Thank you very much! Milo8505 (talk) 16:46, 22 November 2024 (UTC)
- The problem is, there still exist editors who strongly dislike infoboxes on most biographies -- me for one. When one writes every word of an article and then someone, who has not otherwise contributed, comes and adds an infobox it can be ... annoying. The basic use tends to highlight bits of trivial information (birth & death dates/places, nationality, spouse, children) that are not usually key to the person's notability. Even more contentious can be trying to define what a person's key contributions are, in a half-sentence. For some this is easy, and an infobox might be a good way of presenting the data, for others (including many classical composers) not so much. It can be hard enough to write a lead that presents this in a balanced fashion in a paragraph or three.
- Are all good biographies written by groups? I'm not sure; probably the best are, but there are many many biographies of minor figures where 99.9% of the text was contributed by a single author, some of which are fairly well developed. Espresso Addict (talk) 05:05, 28 November 2024 (UTC)
- I'm thankful for your contributions, but I'm sorry that you don't WP:OWN any article, and you can't dismiss someone else improving the article you wrote because you wrote it and you don't personally agree with the contributions made.
- That said, it may be difficult to summarize why someone is important in a phrase, but it's not impossible, and, IMO actually something that should be done, as it makes the article easier (and faster) to scan. Milo8505 (talk) 09:39, 28 November 2024 (UTC)
- What I am obviously failing to convey is that some editors write articles, far fewer than those who contribute in other ways, and some of those dislike the "improving" addition of an infobox by another editor who makes no other edits, improving or otherwise. Espresso Addict (talk) 10:40, 28 November 2024 (UTC)
- Why is that relevant? Nobody owns an article, regardless of in which why they contribute to Wikipedia. Just because some editors dislike something does not give them a veto over things that the majority of other editors believe does improve the article. Obviously an infobox with incorrect information is not an improvement but that doesn't mean an infobox with correct information is not an improvement. In exactly the same way as a paragraph with incorrect information about an aspect of the article subject is a bad addition, this does not mean that a paragraph with correct information about that same aspect is bad. Thryduulf (talk) 11:55, 28 November 2024 (UTC)
- It seems to me a great deal more like reference format and English variant. It could easily be argued that we should have standardised on US spelling and picked a mode of referencing, but we never did because it would alienate too much of the workforce. Espresso Addict (talk) 12:55, 28 November 2024 (UTC)
- It's not even close to being like ENGVAR or reference formatting. Those are stylistic decisions where there are multiple equally valid choices that don't impact content. Infoboxes are a content decision where one choice directly benefits the readership and one choice placates the dislikes of a minority of editors. Thryduulf (talk) 16:40, 28 November 2024 (UTC)
- Load up the Good Faith, Thryduulf :D another phrasing, less pejorative or sweeping, might be Infoboxes are a content decision where either choice directly affects the readers' preconceptions of the topic. Tight faded male arse. Decadence and anarchy. A certain style. Smile. 16:47, 28 November 2024 (UTC)
- It may or may not be less pejorative or sweeping, but it is also less accurate. Thryduulf (talk) 18:24, 28 November 2024 (UTC)
- We obviously genuinely disagree on the topic. But I just don't see how the usual formulation benefits readers for bios about writers, composers or the like, especially where it is difficult to encapsulate their contributions in a half sentence or single notable work. I note that biographical sources such as Oxford Dictionary of National Biography or newspaper obituaries do not generally include infoboxes, in fact I can't think of where I've seen one on a biographical article of this type outside Wikipedia. Espresso Addict (talk) 03:53, 29 November 2024 (UTC)
- Infoboxes are not limited to a single notable work. There is no need to condense a person's life to a single notable work in an infobox. Milo8505 (talk) 06:34, 29 November 2024 (UTC)
- But unless you list all their works there is a problem of original research. You need to provide appropriate sources that the works you have selected are appropriate to represent the subject. This is often very hard in practice, and even harder to demonstrate in an infobox (according to critics A,B,C but ignoring the non-mainstream views of D,E, and only partially incorporating the views of F–Z, the following are the major works...). Espresso Addict (talk) 07:28, 29 November 2024 (UTC)
- Well, no. There are statistics for something. Notable means worthy of note, distinguished, prominent as per Merriam-Webster Dictionary. Notable works are not a collection appropriate to represent the subject as a whole, but rather those worthy of note, distinguished, prominent, in other words, popular or important (for the field in question).
- But the main point being, once again, that this problem is NOT a problem with the infobox itself. Citing the lead paragraph for the Mahler article:
- As a composer he acted as a bridge between the 19th-century Austro-German tradition and the modernism of the early 20th century
- and
- Mahler's œuvre is relatively limited; for much of his life composing was necessarily a part-time activity while he earned his living as a conductor. Aside from early works such as a movement from a piano quartet composed when he was a student in Vienna, Mahler's works are generally designed for large orchestral forces, symphonic choruses and operatic soloists. These works were frequently controversial when first performed, and several were slow to receive critical and popular approval; exceptions included his Second Symphony, and the triumphant premiere of his Eighth Symphony in 1910. Some of Mahler's immediate musical successors included the composers of the Second Viennese School, notably Arnold Schoenberg, Alban Berg and Anton Webern. Dmitri Shostakovich and Benjamin Britten are among later 20th-century composers who admired and were influenced by Mahler. The International Gustav Mahler Society was established in 1955 to honour the composer's life and achievements.
- According to whom? By what research? What if I do not think that is the case?
- You would rightfully say that my answers are on the references section, and that I should be WP:BOLD in changing it if I'm convinced that it could be better.
- And, most importantly, from your comment on the Talk page, I see that the article actually selects three works as prominent, and, you challenge that (IMO rightfully). Then it turns out that the problem of selecting what is important is not one of infoboxes but one central to writing biographies.
- For the last time: infoboxes are ONLY a collection of information already on the article. Milo8505 (talk) 17:27, 29 November 2024 (UTC)
- That's less true than one might think. Both {{taxobox}} and {{drugbox}} have a high likelihood of containing information than isn't repeated in the article.
- But for infoboxes describing people, I would generally expect that statement to be true or to be meant to be true. WhatamIdoing (talk) 07:06, 30 November 2024 (UTC)
- Those are very specific examples, although you are right that they do not conform to what I said. Anyhow the point still stands for biographies. Milo8505 (talk) 09:31, 30 November 2024 (UTC)
- I believe the usual solution in such cases is to link to the List of compositions by Gustav Mahler. WhatamIdoing (talk) 07:07, 30 November 2024 (UTC)
- True, but I believe that there are good reasons some works can be highlighted. Anyhow, this is also a consideration when writing the lead, not only the infobox. Milo8505 (talk) 09:36, 30 November 2024 (UTC)
- But unless you list all their works there is a problem of original research. You need to provide appropriate sources that the works you have selected are appropriate to represent the subject. This is often very hard in practice, and even harder to demonstrate in an infobox (according to critics A,B,C but ignoring the non-mainstream views of D,E, and only partially incorporating the views of F–Z, the following are the major works...). Espresso Addict (talk) 07:28, 29 November 2024 (UTC)
- Infoboxes are not limited to a single notable work. There is no need to condense a person's life to a single notable work in an infobox. Milo8505 (talk) 06:34, 29 November 2024 (UTC)
- We obviously genuinely disagree on the topic. But I just don't see how the usual formulation benefits readers for bios about writers, composers or the like, especially where it is difficult to encapsulate their contributions in a half sentence or single notable work. I note that biographical sources such as Oxford Dictionary of National Biography or newspaper obituaries do not generally include infoboxes, in fact I can't think of where I've seen one on a biographical article of this type outside Wikipedia. Espresso Addict (talk) 03:53, 29 November 2024 (UTC)
- It may or may not be less pejorative or sweeping, but it is also less accurate. Thryduulf (talk) 18:24, 28 November 2024 (UTC)
- Load up the Good Faith, Thryduulf :D another phrasing, less pejorative or sweeping, might be Infoboxes are a content decision where either choice directly affects the readers' preconceptions of the topic. Tight faded male arse. Decadence and anarchy. A certain style. Smile. 16:47, 28 November 2024 (UTC)
- It's not even close to being like ENGVAR or reference formatting. Those are stylistic decisions where there are multiple equally valid choices that don't impact content. Infoboxes are a content decision where one choice directly benefits the readership and one choice placates the dislikes of a minority of editors. Thryduulf (talk) 16:40, 28 November 2024 (UTC)
- It seems to me a great deal more like reference format and English variant. It could easily be argued that we should have standardised on US spelling and picked a mode of referencing, but we never did because it would alienate too much of the workforce. Espresso Addict (talk) 12:55, 28 November 2024 (UTC)
- Why is that relevant? Nobody owns an article, regardless of in which why they contribute to Wikipedia. Just because some editors dislike something does not give them a veto over things that the majority of other editors believe does improve the article. Obviously an infobox with incorrect information is not an improvement but that doesn't mean an infobox with correct information is not an improvement. In exactly the same way as a paragraph with incorrect information about an aspect of the article subject is a bad addition, this does not mean that a paragraph with correct information about that same aspect is bad. Thryduulf (talk) 11:55, 28 November 2024 (UTC)
- I don't think that "OWN" is a useful model here. Consider this story:
- Someone saw a neglected area in his neighborhood, and he thought he'd help people by quietly picking up the trash. People mostly didn't notice, and nobody objected, so whenever he was walking out that way, he brought a trash bag with him and picked up some of the discarded litter. He carried on for a while just for the satisfaction of seeing it get better.
- Then The Committee showed up.
- They told him: "It's very nice that you decided to clean this up. However, you should wear gloves for your own safety."
- "Okay," he thought. "There's probably something in their advice." So he started wearing gloves, and he did think that it made it a little easier to sort the recycling from the garbage.
- The Committee came back another time: "Thank you for your past work. We notice that a bit of the grass here grows out onto the sidewalk. We're not saying you have to do this, because this spot isn't yours, but it would be nice if someone got a lawn edger and made that even neater."
- The volunteer thought that since nobody had bothered to pick up the trash, it was unlikely that anyone else would trim the grass. Besides, he had a lawn edging tool, so the next time he dropped by, he brought a trash bag, his gloves, and his lawn edger. The little spot was looking pretty neat, if a bit plain.
- Soon, the Committee came back again: "Thank you for your past work. We just wanted to let you know that our standards say that it's not enough to clean up a mess. Every area should also have some plants. So it would be very nice if you planted some trees or bushes or something in this spot, even though it's not yours."
- "Can you at least buy the plants?" he asked.
- "No," said The Committee. "Thank you for your past work, but you'll have to grow them or buy them yourself, or maybe you could find someone who would give them to you."
- The volunteer thought that the little spot would benefit from some cheery little flowers, and he decided to do it. He planted a few yellow flowers along the edge.
- The next day The Committee showed up. "What? Yellow flowers? Thank you for your past work, but we have received complaints. One of the neighbors (who happens to be part of The Committee) just filed a confidential complaint that there are now garishly colored flowers in this little spot. Those have to be removed. You don't own this place, you know, even though you're the only one who did anything to take care of it, except for the neighbor's important work complaining, and of course our even more important work ordering you around."
- @Milo8505 (and others), my question is: Do you expect the volunteer to keep maintaining that little spot? Or do you expect him to quit?
- It is true that the author/maintainer of an article does not WP:OWN it. But it is also true that the editor is a WP:VOLUNTEER, and if you make volunteering be sufficiently un-fun – say, by trampling the yellow flowers he planted, or by demanding an infobox at the top of an article – then it would only be logical, rational, and predictable for that editor to quit contributing. And then who is going to write the new articles? WhatamIdoing (talk) 06:29, 29 November 2024 (UTC)
- What you are proposing is no different to ownership - giving an article writer control over what is and is not allowed on "their" article just because they don't like something that the consensus of the community says is important and beneficial to readers. Thryduulf (talk) 11:10, 29 November 2024 (UTC)
- No. What I'm proposing is that we remember that there are consequences for every decision we make, and choose the consequences we want to live with. WhatamIdoing (talk) 07:09, 30 November 2024 (UTC)
- And your proposed method of avoiding consequences you don't like is to give article writers ownership of "their" articles. The consequences of that need to be justified, and I don't think they can be. Thryduulf (talk) 13:21, 30 November 2024 (UTC)
- No. What I'm proposing is that we remember that there are consequences for every decision we make, and choose the consequences we want to live with. WhatamIdoing (talk) 07:09, 30 November 2024 (UTC)
- I would actually say that suppressing infoboxes is more akin to removing flowers than creating them...
- I'm not asking of anyone to do anything they don't want to. They are actually asking me (and others) not to do something a good number of people[citation needed] consider good. Milo8505 (talk) 17:31, 29 November 2024 (UTC)
- The problem is that what one person considers a beautiful flower, another person may consider a weed that needs pruning. Flowers are nice, but so is a manicured lawn. What we need to determine is WHETHER (in this particular lawn) we are planting flowers or pulling weeds. Blueboar (talk) 17:44, 29 November 2024 (UTC)
- And for the wider distinction between WP:OWN and WP:VOLUNTEER. Nobody is forcing nobody else to do anything they don't like. Editors are free to restrain from editing whatever they feel like without any reason. What they are not free to do is to say that their substantial contributions to one article give them a more prominent opinion than everybody else on subjects related to that article. Milo8505 (talk) 17:41, 29 November 2024 (UTC)
- The type of editor who quits the project over an infobox probably isn't someone suited to improving the project or working with others. I've worked on articles and a new editor may add something I don't like, but if they find consensus I accept the will of the community. That's how this place is supposed to work. Nemov (talk) 22:19, 29 November 2024 (UTC)
- @Nemov, would you say that about me? I once objected to a template being renamed to something that was less convenient for me. It got renamed anyway, because other editors thought the new name would make their own work more convenient.
- We do have to "accept the will of the community", but we do not have to continue volunteering under circumstances that aren't working for us, so I stopped doing that work. They got their advantages; we got another backlog for several years. (Eventually another editor decided to do that work.)
- Am I someone you would describe as not "suited to improving the project or working with others"? WhatamIdoing (talk) 07:16, 30 November 2024 (UTC)
- I really really really do not think that the spirit of How will this action make every other editor feel? is very useful to Wikipedia.
- Although well-intentioned, it's imposible to think about every possible edge case, and sometimes it's imposible to find something that everyone will agree to, so if we stop to ask that question before every change, we will, in the end, get nothing at all done. Milo8505 (talk) 09:34, 30 November 2024 (UTC)
- It is impossible to think about every possible edge case.
- However, we're not talking about Unknown unknowns in this case. We're talking about known consequences. We either choose them and own them, or we avoid them. Take your pick – but don't pretend that a choice has no downsides after you've been told what one of the downsides is. WhatamIdoing (talk) 23:39, 30 November 2024 (UTC)
- Let's all take a deep breath, and not compare editing Wikipedia to waging deadly wars.
- In any case, I believe that three things stand:
- Nobody WP:OWNs articles.
- WP:VOLUNTEERs are free to do whatever they want.
- If making a change, after consensus reached by discussion, hurts someone's feelings, I'm sorry but they are not the leader of this place.
- Furthermore, can't a compromise be reached? Can't infoboxes be hidden via user JS? Milo8505 (talk) 07:53, 1 December 2024 (UTC)
- You're thinking about this at the wrong level, with your focus on "hurting someone's feelings".
- This is more of a key employee situation, so let's tell the story a different way:
- Your business depends heavily on a small number of highly valuable employees. Without these few, your business will probably fail, because you will have no products to sell. You are the manager, and you think about how you will improve the business's profitability. You come up with an idea and share it with your staff.
- Most of the staff thinks it's a good idea, but some of your key employees tell you that it's intolerable, and if you implement it, they will quit.
- Should you say:
- "Well, I'm sorry if your little feelings got hurt, but frankly you don't own this business. Don't let the door hit your backside on your way out", or
- "Um, I don't want you to quit. It's not good for any of us if you quit. Let me see if we can come up with something that meets my legitimate goals and also keeps you working here."
- Your #3 sounds like that first one. I don't recommend it. WhatamIdoing (talk) 22:04, 1 December 2024 (UTC)
- Wikipedia does not depend on "a small number of highly valuable employees". Our goal is always to best serve our readers, and we do that by including the information in our articles that they want and expect to be there. We do not do that by pandering to the dislikes of editors, especially not a small minority of editors. No matter how you try and spin it, ownership of articles is not justifiable. Thryduulf (talk) 22:10, 1 December 2024 (UTC)
- No one has suggested otherwise. I have absolutely no clue where you are substantiating this accusation of WhatamIdoing arguing for article ownership. Stating that outside editors with no connection to the article in interest other than to come and enforce their pet issues unrelated to any substantive content in the article is not “article ownership” anymore than having WikiProjects that have certain editors contributing more than others not part of the Project is “ownership.” Barbarbarty (talk) 23:56, 1 December 2024 (UTC)
- WP:OWN isn't complicated.
No one, no matter what, has the right to act as though they are the owner of a particular article (or any part of it).
You're creating a group of "outside editors." We are all editors here. One editor's "pet issue" is another editors improvement. Wikipedia is a collaborative effort. Nemov (talk) 00:20, 2 December 2024 (UTC)- Again, no one has suggested otherwise. I am simply stating a fact that when certain editors try to present something as an “improvement” and it is roundly rejected by other editors who routinely edit the article, it is not a case of someone asserting “ownership.” Hiding behind accusations of others asserting “ownership” to obfuscate the fact that some editor’s changes are counterproductive or not accepted is not the same as finding a violation of WP:OWN. Barbarbarty (talk) 01:11, 2 December 2024 (UTC)
- I honestly don't understand your reply to my comment. Nemov (talk) 02:28, 2 December 2024 (UTC)
- Honestly I fail to see how I could have made myself clearer. You are accusing me of “creating a group of outside editors.” I have suggested nothing of the sort. I was merely saying that when certain groups of editors have more expertise on certain subjects, and therefore edit articles related to those subjects more than other users, that is simply how many articles have been crafted and developed. It’s not “ownership” to state that fact, nor is it elevating any group of editors above any other group. If someone who does not edit a certain article frequently adds an edit to an article and it is reverted, just because it is reverted by another user who is more active on the article does not automatically implicate WP:OWN. Barbarbarty (talk) 02:43, 2 December 2024 (UTC)
when certain groups of editors have more expertise on certain subjects, and therefore edit articles related to those subjects more than other users, that is simply how many articles have been crafted and developed.
is saying that certain groups of editors should be allowed OWNERSHIP of articles they have written, it is explicitlyelevating [a] group of editors above [another] group
. Thryduulf (talk) 03:10, 2 December 2024 (UTC)- You have a very odd and confusing idea of what “explicitly” means, given what you described has absolutely no relation to what I actually said. Absolutely nowhere have I stated certain groups of editors be allowed “ownership.” For the third time, I have just stated that it is natural that some editors edit articles more than others. Sometimes they do so because they have specialized knowledge about the subject area. Nothing about that implies certain editors be given ownership, and frankly it’s ridiculous to construe what I said to mean anything like that. Barbarbarty (talk) 03:26, 2 December 2024 (UTC)
- Honestly I fail to see how I could have made myself clearer. You are accusing me of “creating a group of outside editors.” I have suggested nothing of the sort. I was merely saying that when certain groups of editors have more expertise on certain subjects, and therefore edit articles related to those subjects more than other users, that is simply how many articles have been crafted and developed. It’s not “ownership” to state that fact, nor is it elevating any group of editors above any other group. If someone who does not edit a certain article frequently adds an edit to an article and it is reverted, just because it is reverted by another user who is more active on the article does not automatically implicate WP:OWN. Barbarbarty (talk) 02:43, 2 December 2024 (UTC)
- I honestly don't understand your reply to my comment. Nemov (talk) 02:28, 2 December 2024 (UTC)
- Again, no one has suggested otherwise. I am simply stating a fact that when certain editors try to present something as an “improvement” and it is roundly rejected by other editors who routinely edit the article, it is not a case of someone asserting “ownership.” Hiding behind accusations of others asserting “ownership” to obfuscate the fact that some editor’s changes are counterproductive or not accepted is not the same as finding a violation of WP:OWN. Barbarbarty (talk) 01:11, 2 December 2024 (UTC)
- @Barbarbarty Multiple of @WhatamIdoing's posts, including the one I was directly replying to, advocate for article ownership without using that term. The post I was directly replying to explicitly claimed Wikipedia depends on a small number of editors.
Stating that outside editors with no connection to the article in interest other than to come and enforce their pet issues unrelated to any substantive content in the article
so presumably you object to editors copyediting, typo fixing, adding conversion templates, adding/editing/removing categories and short descriptions, making the article consistent in it's language variety, citation style and/or unit ordering and any of the other myriad of improvements "outside editors with no connection to the article" make? If not, why are infoboxes different? Who gets to decide who is and who is not an "outside editor" and thus who is entitled to stand above consensus? Thryduulf (talk) 00:50, 2 December 2024 (UTC)- First off, you admit that WhatamIdoing never advocated for article ownership. I still fail to see how it can be shown otherwise. As for your point about things I would “presumably” object to, one look at my posting history would show that the vast majority of my contributions involve things like fixing typos and the like. Simple maintenance issues like adding citations and fixing typos are not “pet issues” in any sense of the term. I doubt any editor on here would think that Wikipedia should have articles with unfixed typos or improper grammar. Infoboxes do not fall into simple “maintenance.” Arbitrarily adding them without discussion, as history as shown, is nearly guaranteed to cause debate. They are entirely done on a case-by-case basis, dependent on a myriad of factors. As I said above, “ownership” is not simply some editors who edit an article more frequently rejecting so-called “improvements” by editors who edit the article less frequently. Barbarbarty (talk) 01:20, 2 December 2024 (UTC)
First off, you admit that WhatamIdoing never advocated for article ownership
I did not do this. I said she has argued for article ownership without using that term, because no matter whether you call it "ownership" or not, when she is arguing for is exactly what we define ownership to be. Infoboxes are no more "pet issues" than fixing typos or any of the other improvements mentioned, the only difference is that some editors dislike them.As I said above, “ownership” is not simply some editors who edit an article more frequently rejecting so-called “improvements” by editors who edit the article less frequently.
Except it is, as Nemov has explained in very simple terms above. Thryduulf (talk) 01:57, 2 December 2024 (UTC)- Again, nothing you have pointed to shows anyone advocating for ownership. Nothing. Simply saying that one is “saying without saying” is pointless and unconvincing. Fixing typos and adding infoboxes are not the same, I find it mystifying to read you implying otherwise. If only infoboxes were as noncontroversial as typos that would save us a lot of trouble! But sadly they are not, so pretending someone adding an infobox to every article is the same as fixing typos here and there is not grounded in the reality we live in. As to your last point, that’s not a refutation. And I believe I thoroughly addressed that point already. Under your logic no person who has previously edited an article is allowed to revert someone else’s edit on that same article lest they be accused of asserting “ownership.” I fail to see the logic in such a position. Barbarbarty (talk) 03:34, 2 December 2024 (UTC)
- @Thryduulf, I'd like to think that I'm arguing for acknowledging the value of content, and by extension for the people who create it.
- If we choose to insist upon infoboxes, I'd rather that we did this kindly, while trying to find solutions to the identified problems, instead of with an WP:IDONTCARE WP:YOU WP:DON'T WP:OWN WP:WIKIPEDIA tone. I'm hearing a lot more of the latter than the former in this conversation. I think we can do better than that.
- IMO the ideal outcome is more infoboxes and nobody quits writing articles. I think the first outcome is inevitable. I think the second outcome depends on how we treat people who are unhappy with the first outcome. WhatamIdoing (talk) 06:02, 2 December 2024 (UTC)
- I entered this topic about two years ago, completely unfamiliar with it until it came up in an RFC. Since then, I haven’t seen any of the content creators strongly opposed to infoboxes quit. In fact, they’re still actively creating content and opposing infoboxes. One editor even came out of retirement to create new content—so overall, it’s a net win.
- Most of the RFCs over the last two years have been initiated by editors unaware of this long-standing dispute. The pattern is predictable: they ask why there’s no infobox, get dogpiled by the same group of editors, and if they persist, the tone worsens. When it eventually goes to an RFC, the infobox is approved most of the time.
- This behavior seems tolerated because these editors are content creators. However, considering they haven’t quit and newer editors often face hostility for bringing up the topic, I’m not seeing the issue you’re raising. Nemov (talk) 16:01, 2 December 2024 (UTC)
- First off, you admit that WhatamIdoing never advocated for article ownership. I still fail to see how it can be shown otherwise. As for your point about things I would “presumably” object to, one look at my posting history would show that the vast majority of my contributions involve things like fixing typos and the like. Simple maintenance issues like adding citations and fixing typos are not “pet issues” in any sense of the term. I doubt any editor on here would think that Wikipedia should have articles with unfixed typos or improper grammar. Infoboxes do not fall into simple “maintenance.” Arbitrarily adding them without discussion, as history as shown, is nearly guaranteed to cause debate. They are entirely done on a case-by-case basis, dependent on a myriad of factors. As I said above, “ownership” is not simply some editors who edit an article more frequently rejecting so-called “improvements” by editors who edit the article less frequently. Barbarbarty (talk) 01:20, 2 December 2024 (UTC)
- WP:OWN isn't complicated.
- No one has suggested otherwise. I have absolutely no clue where you are substantiating this accusation of WhatamIdoing arguing for article ownership. Stating that outside editors with no connection to the article in interest other than to come and enforce their pet issues unrelated to any substantive content in the article is not “article ownership” anymore than having WikiProjects that have certain editors contributing more than others not part of the Project is “ownership.” Barbarbarty (talk) 23:56, 1 December 2024 (UTC)
- Wikipedia does not depend on "a small number of highly valuable employees". Our goal is always to best serve our readers, and we do that by including the information in our articles that they want and expect to be there. We do not do that by pandering to the dislikes of editors, especially not a small minority of editors. No matter how you try and spin it, ownership of articles is not justifiable. Thryduulf (talk) 22:10, 1 December 2024 (UTC)
- You didn't quit the Wikipedia over it. There are some editors who have been arguing about infoboxes for over 15 years. It's only a contentious topic because that group can't let it go. I feel bad for new editors who wander into the topic not knowing the back story. Nemov (talk) 17:32, 30 November 2024 (UTC)
- It's only contentious because both sides can't let it go.
- If the template renaming had happened at a point when I was already unhappy with editing, it would have tipped me over the edge.
- What I'm not seeing here is any acknowledgement of the costs. I see the advantages:
- Pros:
- I like it.
- Readers like it.
- but not the known list of disadvantages:
- Cons:
- Some editors dislike it enough that they will reduce their participation or stop writing articles altogether.
- You might well say "I like it, so I and other supporters will be inspired to do 2% more editing if we get our way, and it adds 5% more value to readers in biographies and 10% more value in corporations with an WP:ELOFFICIAL link in the infobox. That benefit needs to be set against 1% of editors quitting and 2% fewer notable articles being created. That's still a net benefit, so let's go with it."
- But let's not pretend that it is a cost-free choice. A net benefit can have significant harms. WhatamIdoing (talk) 23:48, 30 November 2024 (UTC)
- @WhatamIdoing I would urge you reread my comment. I think you'll find there was no finger pointing at a particular side. You're twisting yourself into a pretzel here to defend ownership. There's a cost to everything. I think if you review some of the newer editors who have wandered into this topic they're not being encouraged to edit or learn. Nemov (talk) 05:32, 1 December 2024 (UTC)
- Indeed I've seen several examples of newcomers being thoroughly bitten when they dare to ask for an infobox to be added to an article. See for example Talk:Stanley Holloway where suggestions get aggressively shut down. Thryduulf (talk) 10:09, 1 December 2024 (UTC)
- Yes, there are costs to every choice. What irritates me at the moment is that some costs are being ignored, and one of those costs increases our long-term risk of collapse. (On the opposite side, one of the costs is that readers won't get what they need, which is also a very serious problem.)
- For the record, if you see an article I've created without an infobox, you are (very) welcome to go add one. I'm not anti-infobox. I am anti-destroying-Wikipedia-for-the-sake-of-uniformity. WhatamIdoing (talk) 22:17, 1 December 2024 (UTC)
- And I'm anti hyperbolic claims that allowing article ownership is somehow the only way to avoid destroying Wikipedia. Nobody is irreplaceable. Thryduulf (talk) 22:30, 1 December 2024 (UTC)
- Indeed I've seen several examples of newcomers being thoroughly bitten when they dare to ask for an infobox to be added to an article. See for example Talk:Stanley Holloway where suggestions get aggressively shut down. Thryduulf (talk) 10:09, 1 December 2024 (UTC)
- @WhatamIdoing I would urge you reread my comment. I think you'll find there was no finger pointing at a particular side. You're twisting yourself into a pretzel here to defend ownership. There's a cost to everything. I think if you review some of the newer editors who have wandered into this topic they're not being encouraged to edit or learn. Nemov (talk) 05:32, 1 December 2024 (UTC)
- What you are proposing is no different to ownership - giving an article writer control over what is and is not allowed on "their" article just because they don't like something that the consensus of the community says is important and beneficial to readers. Thryduulf (talk) 11:10, 29 November 2024 (UTC)
- What I am obviously failing to convey is that some editors write articles, far fewer than those who contribute in other ways, and some of those dislike the "improving" addition of an infobox by another editor who makes no other edits, improving or otherwise. Espresso Addict (talk) 10:40, 28 November 2024 (UTC)
- Case in point Jacqueline Stieger, where the box I've just removed (1) highlighted her place of birth Wimbledon and nationality British, which -- for someone with two Swiss parents, who was brought up in Yorkshire, did some of her notable work in France/Switzerland with her Swiss husband and then settled back in Yorkshire with her Swiss stepchildren -- is undue; and (2) copied "artist and sculptor" from the beginning of the capsule, while not paying heed to the fact her notable works predominantly fall into two groups, big architectural sculptures mainly in metal, and jewellery/art medals. Espresso Addict (talk) 05:52, 28 November 2024 (UTC)
- X thing is bad, because once, some time ago, I saw an instance of X and it was bad, really really bad, as a matter of fact. Milo8505 (talk) 09:42, 28 November 2024 (UTC)
- Well sure, but I just looked down my list of created bios by date till I found the first to which someone had added an infobox. I didn't drag out my historical collection of badly added infoboxes including those that had been cut-and-pasted wholesale from another article without changing any of the data, and those that introduced errors in the dates. Espresso Addict (talk) 10:40, 28 November 2024 (UTC)
- Looking at the example of Jacqueline Stieger, I'm not understanding Espresso Addict's position. They object to the infobox giving her nationality as British. But the lead has always said that she "is a British artist and sculptor". And the {{short description}} is "British artist and sculptor". And there are a bunch of categories which tend to describe her as English rather than British.
- The lead, infobox, short description and other structural stuff like categories are all summaries or attributes of the main content. Summarising obviously involves some loss of detail. Objecting to an infobox seems like objecting to a short description. I often don't like these myself but they seem to be unavoidable.
- Andrew🐉(talk) 10:09, 1 December 2024 (UTC)
- It's not so much the details being wrong for Steiger, they give undue prominence to trivial non-representative features of the subject's life, such as her place of birth, while not summarising the actual reasons for notability/interest -- possibly my fault for a slender lead. I'm not fond of short descriptions either but they are invisible to the reader. I'm actually not too fond of categories either, but they go at the bottom, after the references, and so again do not draw the attention of the reader. Espresso Addict (talk) 12:45, 1 December 2024 (UTC)
- What makes anybody of you think that the infobox is more prominent than the lead of the article itself? Maybe are you implicitly recognizing that inboxes are actually widely used by readers? Milo8505 (talk) 20:21, 1 December 2024 (UTC)
- It's not so much the details being wrong for Steiger, they give undue prominence to trivial non-representative features of the subject's life, such as her place of birth, while not summarising the actual reasons for notability/interest -- possibly my fault for a slender lead. I'm not fond of short descriptions either but they are invisible to the reader. I'm actually not too fond of categories either, but they go at the bottom, after the references, and so again do not draw the attention of the reader. Espresso Addict (talk) 12:45, 1 December 2024 (UTC)
- X thing is bad, because once, some time ago, I saw an instance of X and it was bad, really really bad, as a matter of fact. Milo8505 (talk) 09:42, 28 November 2024 (UTC)
- WhatamIdoing (talk) 22:27, 17 November 2024 (UTC)
- The thing to remember about CONLOCAL is that almost all of our policies and guidelines (which supposedly reflect “global consensus”) contain a line noting that occasional exceptions may exist. This means that global consensus takes local consensus into account. Indeed, there are times when a consensus is reached at an article level (say through a RFC) that actually has greater participation (wider consensus) than the policy/guideline page that is at the heart of the discussion. A policy/guideline may be wonderful for most situations, but problematic in a specific situation.
- As for infoboxes… yes, there is a “global consensus” that they are good things, and adding one usually improves the article. However, we have had RFC that show we also have a wide consensus that notes how infoboxes don’t alway work, that on occasion they can actually be more harmful than helpful… and that we can leave it to local editors to make that determination. This is especially true when it comes to articles about composers.
- So, when there is local disagreement regarding a specific composer, when there is a question as to whether an infobox would be beneficial or harmful in that specific situation, the solution is to have an RFC to determine wider consensus about that specific situation.
- Ie ASK the community whether that specific article should be considered an exception to our general consensus on infoboxes. Blueboar (talk) 13:54, 29 November 2024 (UTC)
- The phrase "global consensus" indicates that we should look across all the languages, not just English. Articles about famous composers seem to have about 50 versions in the various languages and it's easy to spot-check these to see whether they do or don't have infoboxes. I looked at a few examples of English composers as they seemed to be the most likely to be disputed: Gustav Holst, Ralph Vaughan Williams, Benjamin Britten. My impression is that most languages have infoboxes for these. Apart from English, the main outliers seem to be German and Italian. Andrew🐉(talk) 09:39, 1 December 2024 (UTC)
- The German encyclopedia is, as far as I know, very rich in classical music content. Espresso Addict (talk) 12:48, 1 December 2024 (UTC)
- I do not thing that is the case. Each Wikipedia is separate from others, and they each have their own policies and ways of doing things. Milo8505 (talk) 20:23, 1 December 2024 (UTC)
- There seem to be at least three different meanings of "global consensus" in this discussion. The OP seems to have taken it to mean something that should apply to all articles of a particular type, but in WP:CONLEVEL I think it means a consensus reached by everyone rather than just the editors of particular articles. These are different. It is in principle possible for a global discussion to come to the conclusion that every article should be treated differently. Andrew Davidson introduces another level of "global" that includes other language Wikipedias. English Wikipedia has always claimed its independence from other projects, so I don't think that will fly. On the specific case of infoboxes surely the discussion should be about what to include in them, rather than first a discussion of whether they should exist. If the answer is "nothing" then we simply don't have them. Phil Bridger (talk) 13:49, 1 December 2024 (UTC)
We need to fix the admin recall process
Right now only "recall" votes count, and those opposing recall don't count for anything, nor do any points made in the discussion. So 25 quick group-think / mob thumbs-down votes and even be best admmin can get booted. And the best (= the most active) are the ones most likely to get booted. An admin that does near zero will get zero votes to recall. And with a single regular RFA currently the only way back in (which we've seen, very few want to go through) "booted" is "booted". The fix would be to have a discussion period pror to voting, with both "recall" and "don't recall" choices. And then say that the recall has occurred (thus requiring rfa) if over 50% or 60% of those voting said "recall".
Sincerely, North8000 (talk) 20:40, 19 November 2024 (UTC)
- @North8000 Please see Wikipedia:Administrator recall/Reworkshop, where editors are already discussing potential changes. Sam Walton (talk) 20:43, 19 November 2024 (UTC)
- Thanks. I looked for something like that but I guess I didn't look hard enough. I hope others look harder than me. :-) North8000 (talk) 21:58, 19 November 2024 (UTC)
- I don't think you understand how recall works. An admin is only desysopped after the RRFA, not after the 25 signatures, unless they choose to resign on their own. You're asking to hold a vote on whether or not a vote should be held. ~~ Jessintime (talk) 20:55, 19 November 2024 (UTC)
- Yes, I understood that and that is integrated into my comment above. Unless they go through and succeed at an RFA they are gone. North8000 (talk) 21:54, 19 November 2024 (UTC)
- I've never heard of a petition that lets people sign because they don't support it. And I'll add that between the two recall petitions that were enacted to this point, both were preceded by many, many attempts to get the admin to correct course over the years despite egregious misconduct. Thebiguglyalien (talk) 21:03, 19 November 2024 (UTC)
- I'm not talking about any particular cases. Sincerely, North8000 (talk) 21:56, 19 November 2024 (UTC)
- So, the premise of your argument is pure conjecture? Regards, Goldsztajn (talk) 22:05, 19 November 2024 (UTC)
- ???? It was from an analysis of it's current structure. North8000 (talk) 14:10, 20 November 2024 (UTC)
- But you've just refused to engage in a discussion with how the structure has actually worked in practice; hence, conjecture. Regards, Goldsztajn (talk) 00:19, 21 November 2024 (UTC)
- ???? It was from an analysis of it's current structure. North8000 (talk) 14:10, 20 November 2024 (UTC)
- So, the premise of your argument is pure conjecture? Regards, Goldsztajn (talk) 22:05, 19 November 2024 (UTC)
- I'm not talking about any particular cases. Sincerely, North8000 (talk) 21:56, 19 November 2024 (UTC)
- The process at the moment does have a certain level of redundancy, with the recall and reconfirmation RFA being separate things. The reconfirmation RFA is even a standard RFA, as it has different criteria for success.
- I'm not sure if anything should be done yet, as it's still very early in its adoption. However if the situation occurs that a petition is successful but the reconfirmation RFA SNOWs, it could indicate that adjustments needs to be made so that community time isn't wasted. That speculative at the moment though. -- LCU ActivelyDisinterested «@» °∆t° 23:53, 19 November 2024 (UTC)
- The recall petition threshold is not the recall discussion - it is just a check to prevent the most frivolous recall discussions from being held. — xaosflux Talk 00:56, 20 November 2024 (UTC)
- The optics of this look alltogether terrible from my observation. I don't edit much, but I like reading a lot. Every criticism of the recall process i've seen so far just looks like old established admins thinking they might be next and having anxiety about that.
- The problem of something like this is that the optics are terrible. If anyone who doesn't know you reads that, the conclusion they will draw will likely not be "this recall process is terrible" and more likely go along the lines of "wow this is a lot of admins who don't have the community's trust anymore and want to dodge accountability".
- By being so vocally against any form of community led accountability, you're strenghtening the case for easy recalls and low thresholds, not weakening it.
- Specifically regarding Fastily, I'll make no comment on whether or not he deserves to still be an admin or not, I don't know him well enough for that and haven't reviewed enough of his contributions, but the arguments of "ANI agreed that no sanctions were appropriate" sound a lot like "our police department has investigated itself and found nothing was wrong". You have to see how this comes across, it's eroding trust in Admins on the whole project right now. Magisch talk to me 09:24, 20 November 2024 (UTC)
- Specifically, if RFA is so toxic that nobody wants to do it, that needs to be reformed. But the recent amount of vitriol towards a process that only kickstarts having to prove that you retain community trust has me convinced that there should be automatic mandatory RRFAs for every admin every 2 years or so.
- If, as of today, you don't believe the community would entrust you with admin tools, why do you think you should still have them? The criteria for losing them should not be "has clearly abused them", it should be "wouldn't be trusted with them if asked today". Magisch talk to me 09:33, 20 November 2024 (UTC)
- As an admin actively working to improve the recall process, my goal is to make it as fair as possible to all parties. That means it should not be possible to subject an admin to the process frivolously while equally making it possible to recall administrators who have lost the trust of the community, and it needs to be as non-toxic as possible, because even administrators who are actively abusing their tools are people and nobody deserves 1-2 months of abuse. It's also incorrect to describe ANI as a police department investigating itself - everybody engaging in good faith is welcome to comment there, regardless of whether they are an admin or not. Thryduulf (talk) 11:15, 20 November 2024 (UTC)
- @Thryduulf It's the Administrator's Noticeboard, naturally the vast majority of participants will be either admins or people who are involved in the same work.
- I don't think asking an admin to confirm they still retain the trust of the community (the whole basis of giving out admin tools to begin with) is ever really frivolous. The current process allows that at most once a year. If an admin had to stand for RFA every year, that might be a bit too much long term, but really, if any admin thinks they would not pass RRFA today, why should they retain their tools.
- Also, the sheer optics of it being mostly (from what i've seen) established admins calling this process toxic are terrible. Anyone who doesn't know anything about this process will see this as some kind of thin blue line mentality in the admin corps - and might conclude that it is time to desysop the majority of old admins to dissolve the clique.
- I wouldn't be surprised if we see a bunch of recall petitions for the most vocal critics of this process. Magisch talk to me 11:27, 20 November 2024 (UTC)
- I have no horse in this race, except that I regret not seeing the RFA earlier so I could have voted Support, sorry about that.
- But if your argument is optics, then having a bunch of recall petitions for the people who most vocally expressed a valid opinion on an evolving policy is absolutely awful optics. At best. Gnomingstuff (talk) 01:33, 22 November 2024 (UTC)
- As an admin actively working to improve the recall process, my goal is to make it as fair as possible to all parties. That means it should not be possible to subject an admin to the process frivolously while equally making it possible to recall administrators who have lost the trust of the community, and it needs to be as non-toxic as possible, because even administrators who are actively abusing their tools are people and nobody deserves 1-2 months of abuse. It's also incorrect to describe ANI as a police department investigating itself - everybody engaging in good faith is welcome to comment there, regardless of whether they are an admin or not. Thryduulf (talk) 11:15, 20 November 2024 (UTC)
- I took the stats from the first RRfA to test this theory:
Support | Oppose | Total | |
---|---|---|---|
Administrators | 48 | 29 | 77 |
Non-admins | 71 | 116 | 187 |
Total | 119 | 145 | 264 |
- Administrators made up 29% of the voters. If being an admin doesn't influence anyone's vote, then we can expect admins to make up roughly 29% of the supporters and 29% of the opposers. But this didn't happen. In the final results, administrators made up 40% of the supporters and 20% of the opposers. We can also look at the individual odds of supporting/opposing depending on user rights. It ended at 45% support, so you'd expect admins to have a 45% chance of supporting and a 55% chance of opposing. But this also didn't happen. If you choose any admin at random, they had a 62% chance of supporting and a 38% chance of opposing (ignoring neutrals). Non-admins were the opposite: they had a 38% chance of supporting and a 62% chance of opposing.
- So our next question should be why it was so much more likely for an admin to support the RRfA relative to a non-admin. The obvious answer is of course as you said: admins have a perverse incentive to support here, especially if they're not-so-great admins who know they probably don't have the trust of the community anymore. Also suggested during the RRfA is the comradery that comes from working alongside a fellow admin for so long. I'd be interested in seeing how account age affects likelihood of supporting, but that's not something that can be counted up in a few minutes like admin status. Thebiguglyalien (talk) 17:48, 20 November 2024 (UTC)
- I believe it may be centered on the idea that we all make mistakes, and many of us like to think we'd be given a chance to grow and learn from said mistake, instead of being forced through the RfA process again. But I recognize I may be being overly optimistic on that, and that others may not have the same thoughts on the matter that I do. Many admins I've spoken to would simply choose to give up their tools as opposed to go through an RfA again, something I've also considered despite my relatively smooth RfA. I'm also not sure Graham is the best representation of that. I voted support, recognizing that Graham87 has made mistakes, but also recognizing the significant contributions they've made and their pledge to do better. Bluntly, I did so expecting the vote to fail, and wanting to show some moral support and appreciation for their work. There's certainly a psychological aspect involved in it, but I don't think that, generally speaking, those of us who voted support or have issues with the current process are doing so out of self preservation.
- There's a lot of numbers that could be analyzed, such as the history of those admins who vote at RfA (whether they often vote support or don't vote at all), but it's hard to draw meaningful conclusions from this small of a dataset. Hey man im josh (talk) 19:14, 20 November 2024 (UTC)
- On paper, I get that. The thing is, I don't know whether you saw Levivich's comment or bradv's comment, but you'd be hard-pressed to find a less appropriate time to test the "chance to grow" theory than the absolutely deplorable behavior that we saw from Graham for many years with far too many chances to improve. If it were down to me, this should have been a block in 2023 rather than a desysop in 2024. Thebiguglyalien (talk) 19:32, 20 November 2024 (UTC)
- I'm late to the discussion, but I think it's also worth pointing that only 7 of the 25 users who signed Graham87's petition and 2 of the 25 on Fastily's were admins. ~~ Jessintime (talk) 13:16, 23 November 2024 (UTC)
- I would add that there is a potential wrinkle in this analysis. I'm an extended-confirmed user here (and thus would likely be counted as a non-admin), but I am a sysop on Commons so I would have my own perspective on the matter. Abzeronow (talk) 21:06, 22 November 2024 (UTC)
- So our next question should be why it was so much more likely for an admin to support the RRfA relative to a non-admin. The obvious answer is of course as you said: admins have a perverse incentive to support here, especially if they're not-so-great admins who know they probably don't have the trust of the community anymore. Also suggested during the RRfA is the comradery that comes from working alongside a fellow admin for so long. I'd be interested in seeing how account age affects likelihood of supporting, but that's not something that can be counted up in a few minutes like admin status. Thebiguglyalien (talk) 17:48, 20 November 2024 (UTC)
- Well, I'm not an admin and I started this thread. I'm all for having an admin recall process by the community in place. I'm also also for a process for course correction by the community in areas where and admin has drifted off course but where the problem is fixable. Administrative Action Review has the potential to become this but that has been stymied by various things. Sincerely, North8000 (talk) 14:24, 20 November 2024 (UTC)
- I think, fundamentally, the problem is that admins have a direct and concrete conflict of interest in this discussion. Of course an admin would be naturally opposed to more mechanisms that might make them lose their permissions, especially since desysops are very rare at the moment.
- I also don't really agree that the current recall process is all that toxic. You could get rid of the discussion section, as the recall is only a petition, not a consensus discussion, but that's about it. Magisch talk to me 18:33, 20 November 2024 (UTC)
Of course an admin would be naturally opposed to more mechanisms that might make them lose their permissions
– I wholeheartedly disagree with this assertion. There's a number of us that fully support a recall process, including quite a few people who have historically been open to recalls. This is an over simplification of the motives of a large group of experienced editors, many of which have legitimate and reasonable concerns about the process in its current form. Hey man im josh (talk) 19:15, 20 November 2024 (UTC)- Substantially all criticism i've seen so far of the process have boiled down to "RFA is abusive and it's unreasonable to make people go through that again". And yet, instead of attempting to change that, the only suggestions seem to be to support older admin's rights to have their permissions continue being grandfathered in. Magisch talk to me 19:27, 20 November 2024 (UTC)
- I'm sorry that that's all you've taken away from the vast amounts of criticism given by people. Perhaps consider focusing on whether the process, in its current state, makes sense instead of focusing on older admins. I'm a relatively new admin and I don't support the current iteration of the process. Hey man im josh (talk) 19:30, 20 November 2024 (UTC)
- I think it's eminently sensible to have adminship not be a lifetime appointment, both by the fact that norms change even when people dont, and that I see people in every RFA expressing reluctance over granting lifetime tools. I also think that assuming RFA isn't a big deal regular reconfirmations make sense. IFF RFA is a big deal, then the focus should be on fixing that.
- It seems to me that existing admins being immune to having to suffer RFA again has created a lack of pressure to actually make it into a functional, nontoxic process.
- Take my opinion for what it's worth though. I'm not an admin nor do I foresee myself ever having aspirations to become one. Magisch talk to me 19:43, 20 November 2024 (UTC)
- Attempting to improve RFA is a very hard problem that people have been working on since before you joined Wikipedia, and are still working on it. I would also say that
it is unreasonable to make people go through that again
is a mischaracterisation of the views expressed, which areit is unreasonable to make people go through that again unnecessarily
, which is significantly different. Thryduulf (talk) 19:31, 20 November 2024 (UTC)- I just found out about this discussion, and it looks to me like the same or similar things are being discussed in way too many different places. Anyway, I'm someone who has stated repeatedly and strongly in multiple places that I think the recall process is a disaster, and is beyond repair. And, contra some statements above, here are some other facts about me. I'm not an admin. I opposed Graham's re-RfA. And I played a central role in WP:CDARFC. --Tryptofish (talk) 20:12, 20 November 2024 (UTC)
- I'm sorry that that's all you've taken away from the vast amounts of criticism given by people. Perhaps consider focusing on whether the process, in its current state, makes sense instead of focusing on older admins. I'm a relatively new admin and I don't support the current iteration of the process. Hey man im josh (talk) 19:30, 20 November 2024 (UTC)
- Substantially all criticism i've seen so far of the process have boiled down to "RFA is abusive and it's unreasonable to make people go through that again". And yet, instead of attempting to change that, the only suggestions seem to be to support older admin's rights to have their permissions continue being grandfathered in. Magisch talk to me 19:27, 20 November 2024 (UTC)
- I would be against it for a different reason: if we allow both supports and opposes, then the recall petition becomes a mini-RfA with the same amount of pressure as the RRfA itself (especially since, given the identical threshold, the recall's result would be indicative of the RRfA's subsequent result). Since anyone can start the recall petition, it functionally means that anyone can force an admin to re-RfA, which is clearly worse.
On the other hand, having a set number of supports needed provides for a "thresholding" of who can open a RRfA, while not necessarily being as stressful. If anything, I would say the recall should become more petition-like (and thus less stressful for the recalled admin), rather than more RfA-like. Chaotic Enby (talk · contribs) 20:01, 20 November 2024 (UTC)
- The ones most likely to be booted are bad admins who are abusive toward the editor community and who negatively represent themselves as admins. Both of the recalls thus far were just exact examples of that and worked perfectly as designed and needed. The process worked exactly as desired and removed bad admins who deserved to be desysopped. Though I do think the discussion section of the petitions should be more regulated. Discussion should be about the admin's actions and conduct and nothing else. Any extraneous commentary should be removed. SilverserenC 00:23, 21 November 2024 (UTC)
- When I first started editing Wikipedia almost 20 years ago, I was struck by what, to me at least, appeared to be widespread incivility. Among a number of things which have changed for the better IMHO is an all round expectation that everyone's standards of behaviour should rise (and they have). The admin role breeds a certain "culture" (for lack of a better term) akin to a conservationist, the role is to "protect" Wikipedia from "harm" and I can certainly see why being an admin could be a deeply frustrating experience. However, what has happened, I think, in the attrition of the admin corps, and the turnover in the non-admin corps, is that the generalised culture of "regular" non-admin editors has moved further forward towards less acceptance of a culture prevalent 10-15 years ago. I think also the rise in editors from non-English speaking backgrounds and from the Global South has caused complexities for those with limited experience outside the anglosphere. The statistics above on the vote for G87's RRFA show an interesting split between admins and non-admins, and within admins. Non-admins were almost overwhelmingly (close to 2/3) of the view that G87 had been given an almost exceptionaly long period to improve, had not, and no longer held their trust. 5/8s of admins, appeared (and comments here also seem to confirm this) split between solidarity for one of their own and displeasure with the recall process. 3/8s admins were in alignment with the majority of non-admins. FWIW, I'm not trying to point to some grand schism; A 38/62 admin split on these numbers is not that profound - if just 9 admins had changed their vote from support to oppose it would have been a 50/50 split. To reiterate, I'm not suggesting that there is a great gap between admins and non-admins, but there does appear to be some gap when it comes to generalised views around the expected behaviour of admins. Regards, Goldsztajn (talk) 01:01, 21 November 2024 (UTC)
- Maybe the divide is not between admins and non-admins but between newer and longer-serving editors (who are more likely to be admins)? Hawkeye7 (discuss) 01:20, 21 November 2024 (UTC)
- I don't disagree, and in effect I was sort of saying the same thing in terms of the attrition of the admin corps and turnover in non-admin corps. FWIW, I do think there are some generalised feelings about admins among non-admins; for example, admins are less likely to face sanction than non-admins. How true that actually is I'm not sure and the point would be that a group of people already tested in commnuity trust (ie RFA) are less likely to breach that trust. However, comments in the G87 RRFA and the strength of the vote suggest there are (wrongly or rightly) widely felt perceptions of disparity. Regards, Goldsztajn (talk) 01:53, 21 November 2024 (UTC)
- I'm currently compiling the data to get some statistics about voters in Graham's re-RFA. I'm a bit less than halfway through so it might be a couple of days before I can present any results. However among the first 113 support voters the maximum account age (on the day the re-RFA started) was 7919 days (21 years), the minimum was 212 days and the average was 4785 days (13 years). I have no data yet for neutral or oppose voters so cannot say how that compares. Thryduulf (talk) 02:03, 21 November 2024 (UTC)
- Do you have a handy list of all voters for RFA? It should be simple enough to use a WP:QUARRY to find out all details about the voters if someone finds an easy enough scrape of who each user is Soni (talk) 05:51, 21 November 2024 (UTC)
- @Soni: [2]. Levivich (talk) 07:09, 21 November 2024 (UTC)
- Here's the Quarry query editcount/registration date for Supports, Neutrals, Opposes.
- I think about 6 editors were missed by the tool you linked, but it should not change overall patterns much so we can just use this as is. Soni (talk) 07:24, 21 November 2024 (UTC)
- Prepare to not be surprised. Supporters/Opposers:
- Median registration date 2008/2014 <-- Behold, Wikipedia's generational shift
- Average registration date: 2011/2014
- Median edit count: 40,293/17,363
- Average edit count: 76,125/43,683
- Thanks for doing the quarry. Teamwork makes the dream work! Levivich (talk) 05:17, 22 November 2024 (UTC)
- Prepare to not be surprised. Supporters/Opposers:
- @Soni: [2]. Levivich (talk) 07:09, 21 November 2024 (UTC)
- At a quick glance, it seemed like editors with more edits were more likely to support while editors with fewer edits (with one exception) were more likely to oppose. - Enos733 (talk) 07:54, 21 November 2024 (UTC)
- Given a single admin action may involve multiple edits, it's not so surprising the supporters' list possibly reflects a group with higher edit counts. Personally, I'd be more inclined to draw conclusions from length of registration rather than edit count. Regards, Goldsztajn (talk) 09:11, 21 November 2024 (UTC)
- my very, very rapid count - supports 35/117 (30%) less than 10 years old, opposes 67/141 (48%) less than 10 years old. In absolute numbers, 10+ year accounts were 82 supports, 74 opposes - actually quite even. What was crucial was younger accounts. It does confirm my sense of gaps between "older" and "younger" generations in regard to perceptions of tolerable admin behaviour. Regards, Goldsztajn (talk) 09:50, 21 November 2024 (UTC)
- Given a single admin action may involve multiple edits, it's not so surprising the supporters' list possibly reflects a group with higher edit counts. Personally, I'd be more inclined to draw conclusions from length of registration rather than edit count. Regards, Goldsztajn (talk) 09:11, 21 November 2024 (UTC)
- Do you have a handy list of all voters for RFA? It should be simple enough to use a WP:QUARRY to find out all details about the voters if someone finds an easy enough scrape of who each user is Soni (talk) 05:51, 21 November 2024 (UTC)
- Maybe the divide is not between admins and non-admins but between newer and longer-serving editors (who are more likely to be admins)? Hawkeye7 (discuss) 01:20, 21 November 2024 (UTC)
- When I first started editing Wikipedia almost 20 years ago, I was struck by what, to me at least, appeared to be widespread incivility. Among a number of things which have changed for the better IMHO is an all round expectation that everyone's standards of behaviour should rise (and they have). The admin role breeds a certain "culture" (for lack of a better term) akin to a conservationist, the role is to "protect" Wikipedia from "harm" and I can certainly see why being an admin could be a deeply frustrating experience. However, what has happened, I think, in the attrition of the admin corps, and the turnover in the non-admin corps, is that the generalised culture of "regular" non-admin editors has moved further forward towards less acceptance of a culture prevalent 10-15 years ago. I think also the rise in editors from non-English speaking backgrounds and from the Global South has caused complexities for those with limited experience outside the anglosphere. The statistics above on the vote for G87's RRFA show an interesting split between admins and non-admins, and within admins. Non-admins were almost overwhelmingly (close to 2/3) of the view that G87 had been given an almost exceptionaly long period to improve, had not, and no longer held their trust. 5/8s of admins, appeared (and comments here also seem to confirm this) split between solidarity for one of their own and displeasure with the recall process. 3/8s admins were in alignment with the majority of non-admins. FWIW, I'm not trying to point to some grand schism; A 38/62 admin split on these numbers is not that profound - if just 9 admins had changed their vote from support to oppose it would have been a 50/50 split. To reiterate, I'm not suggesting that there is a great gap between admins and non-admins, but there does appear to be some gap when it comes to generalised views around the expected behaviour of admins. Regards, Goldsztajn (talk) 01:01, 21 November 2024 (UTC)
We have had two recalls as of now. The people signing the recall were by and large not trolls, vandals, people blocked by that admin, ... but regular editors in good standing and without a grudge. One of these recalls has been supported by the RRFA afterwards, and the other admin decided not to go for a RRFA. There is zero evidence that the process is flawed or leads to results not wanted by the community at large. While minor issues need working out (things like "should it be closed immediately the moment it reaches 25 votes or not"), the basic principles and method have so far not produced any reason to fundamentally "fix" the issue. That the process highlights a gap between parts of the community (see e.g. the Graham RRFA) doesn't mean that the process needs fixing. The process only would need fundamental fixing if we would get successful recalls which would then be overwhelmingly reversed at RRFA, showing that the recall was frivolous, malicious, way too easy... Not now though. Fram (talk) 09:24, 22 November 2024 (UTC)
- I agree with Fram. There is not any evidence that the recall process is reaching outcomes that are not supported by the Community (I voted Oppose on the Graham RRFA; I don't know how I would have voted on a Fastily RRFA). Small fixes to the process if supported would not be indicative of the process itself being fundamentally flawed. Abzeronow (talk) 21:15, 22 November 2024 (UTC)
- I agree that it just needs fixes.North8000 (talk) 15:24, 23 November 2024 (UTC)
I believe that desysoppings for cause should only happen when there is objective evidence of misconduct. My main concern about the recall process is that it may be wielded against administrators who are willing to take actions that are controversial, yet necessary. Examples of actions that have got administrators hounded include (1) closing contentious and politically charged AFD discussions; (2) blocking an "WP:UNBLOCKABLE" editor who is being disruptive or making personal attacks; (3) stepping up to protect a politically charged article to stop an edit war. None of these actions are administrator misconduct, but in a heated dispute the side that has an admin rule in their disfavor may quickly resort to punishing said administrator by starting a recall petition, and in a dispute involving many editors, getting to 25 may be easy. Even if that petition fails, it is so unpleasant that it may have a chilling effect on admin involvement even when needed. Sjakkalle (Check!) 21:14, 23 November 2024 (UTC)
- In which case, a RRFA might be overwhelmingly in favor of the administrator and thus vindicate the administrator. I would definitely vote in support of an administrator if those any of those three were the impetus behind a recall. I also trust our editors, and so far, the recall process has worked as intended. Abzeronow (talk) 21:50, 23 November 2024 (UTC)
- ArbCom have to face re-election. Does that have a chilling effect on the arbitrators? Hawkeye7 (discuss) 21:48, 23 November 2024 (UTC)
- That's a facile argument. Arbitrators are well aware that they are standing for a fixed term period. Black Kite (talk) 21:50, 23 November 2024 (UTC)
- It's driving me up the wall that people keep saying that the process has worked as intended. Come back and tell me that, after you can link to an RRfA for Fastily that resulted in whatever result you define as working as intended. --Tryptofish (talk) 22:01, 23 November 2024 (UTC)
- Choosing not to do an RRfA was their own choice, particularly if Fastily thought it wouldn't be successful. It was also their choice to make no attempt whatsoever to defend the reams of evidence presented against them in the recall petition of their negative actions toward the editing community. So, yes, Fastily as well was an example of the process working as intended. SilverserenC 22:08, 23 November 2024 (UTC)
- Or perhaps they just thought "well, I've put XX years into this and a load of random people with rationales ranging from reasonable to utterly non-existent have told me I'm not fit to do it, so f*** you". If that's the case, I don't blame them. Black Kite (talk) 22:13, 23 November 2024 (UTC)
- Maybe, maybe not. Probably not though right? Seems kind of silly. PackMecEng (talk) 22:17, 23 November 2024 (UTC)
- I suspect that might be my reaction, to be honest. Black Kite (talk) 22:24, 23 November 2024 (UTC)
- He was going to lose if he didn't apologize, and he didn't want to apologize. That simple. As others have said, that was his choice to make, and I respect it. Levivich (talk) 22:28, 23 November 2024 (UTC)
- Except that he did apologize, although there were differing views of whether that apology was enough. This oversimplification is what's wrong with the way discussions happen in this process. --Tryptofish (talk) 22:34, 23 November 2024 (UTC)
- He woulda had to apologize more, then, including for the stuff that came out during the petition, and any other stuff that may have come out during the RRfA. He woulda had to answer questions about it, make promises, etc., basically go through what Graham went through, and realize that even that (answering questions, making promises) might not be enough (as it wasn't for Graham). It's not at all irrational for someone to choose not go through that. Being an admin isn't worth all that to some (e.g., to me), especially if you might not get it despite your best efforts. Levivich (talk) 22:44, 23 November 2024 (UTC)
- "Someone decided that it just isn't worth it" does not equal "the process worked". --Tryptofish (talk) 22:47, 23 November 2024 (UTC)
- No, those two things are not the same. If you want to know why I think the process worked, it's because it stopped disruption, did it faster than Arbcom, and I think with less drama (though admittedly the third one is purely subjective and speculative). Levivich (talk) 22:56, 23 November 2024 (UTC)
- Um, thanks for sharing? --Tryptofish (talk) 23:06, 23 November 2024 (UTC)
- No, those two things are not the same. If you want to know why I think the process worked, it's because it stopped disruption, did it faster than Arbcom, and I think with less drama (though admittedly the third one is purely subjective and speculative). Levivich (talk) 22:56, 23 November 2024 (UTC)
- "Someone decided that it just isn't worth it" does not equal "the process worked". --Tryptofish (talk) 22:47, 23 November 2024 (UTC)
- He woulda had to apologize more, then, including for the stuff that came out during the petition, and any other stuff that may have come out during the RRfA. He woulda had to answer questions about it, make promises, etc., basically go through what Graham went through, and realize that even that (answering questions, making promises) might not be enough (as it wasn't for Graham). It's not at all irrational for someone to choose not go through that. Being an admin isn't worth all that to some (e.g., to me), especially if you might not get it despite your best efforts. Levivich (talk) 22:44, 23 November 2024 (UTC)
- Except that he did apologize, although there were differing views of whether that apology was enough. This oversimplification is what's wrong with the way discussions happen in this process. --Tryptofish (talk) 22:34, 23 November 2024 (UTC)
- He was going to lose if he didn't apologize, and he didn't want to apologize. That simple. As others have said, that was his choice to make, and I respect it. Levivich (talk) 22:28, 23 November 2024 (UTC)
- I suspect that might be my reaction, to be honest. Black Kite (talk) 22:24, 23 November 2024 (UTC)
- Maybe, maybe not. Probably not though right? Seems kind of silly. PackMecEng (talk) 22:17, 23 November 2024 (UTC)
- On the petition page, I conducted a careful analysis of the evidence. Nobody refuted what I said there. --Tryptofish (talk) 22:15, 23 November 2024 (UTC)
- Linking might help though. It doesn't seem to be on Wikipedia talk:Administrator recall/Graham87, Wikipedia talk:Administrator recall/Fastily, or on Wikipedia talk:Administrator recall, so it's a bit hard to know what "the petition page" is. Do you mean your 00:39, 13 November 2024 (UTC) reply to A smart kitten? The one that ended with "Does this rise to the level of requiring, for me, a desysop? I'm leaning towards no." And others leaned towards "yes", it's not as if people couldn't draw different conclusions from your post or could disagree with things you said without actually replying directly to you. You didn't contradict the evidence, you personally didn't find it severe or convincing enough, that's all. That doesn't show that the process needs fixing though, just because enough people disagreed with your opinion and the result wasn't put to the test. Fram (talk) 09:28, 25 November 2024 (UTC)
- Fram, the context of what I said was clearer before there were all those intervening edits, but yes, you correctly identified the post I meant as the one that ended with the words that you quoted. Here's the diff: [3]. From where I'm sitting, your analysis here of how people reacted to what I posted is, well, not convincing enough. There was a lot of discussion about the evidence that I analyzed, back and forth. When the editor (A smart kitten) who originally posted the evidence came back with the additional information that I requested, the discussion was still very active. I provided a very detailed examination, point-by-point, of each individual claim made in that evidence. Yes, it was based upon my opinions, but I drew specific conclusions, and justified those conclusions. And nobody came back and said that they thought anything in my analysis was incorrect, nor did anyone who signed on the basis of that evidence before my comment come back and reaffirm their signature, rejecting my analysis. If you think somebody actually did, you can provide a diff of it, but I can assure you that you won't find one. And that wasn't because the petition discussion had come to a close, because it continued for several more days after I posted that. After a whole lot of back-and-forth about that particular evidence, nobody said that they found errors in anything that I said. But a couple more editors did sign the petition after that, with brief comments saying, in some cases, that they decided to sign after reading that particular evidence.
- So the question, in the light of your comment to me, becomes whether those later signers did so because they carefully read all of the discussion, including my critique, and decided to sign, implicitly having decided that my critique was unconvincing – or whether they signed after only a superficial read and had never really engaged with my critique. I cannot prove that it was the latter, and you cannot prove that it was the former. But given that their signatures came only with brief comments, and nobody found reason to actually mention that they had rejected my critique, I'm pretty skeptical of the former. And that's a problem. The petition process does not, of course, require that anyone had to say explicitly that they disagreed with me, either, but that's a shortcoming of the discussion process. A desysop via ArbCom makes room for careful examination of the facts. The petition did not. This is a half-assed way of driving someone off Wikipedia. And I'm arguing for a more deliberative process. --Tryptofish (talk) 18:55, 25 November 2024 (UTC)
- Linking might help though. It doesn't seem to be on Wikipedia talk:Administrator recall/Graham87, Wikipedia talk:Administrator recall/Fastily, or on Wikipedia talk:Administrator recall, so it's a bit hard to know what "the petition page" is. Do you mean your 00:39, 13 November 2024 (UTC) reply to A smart kitten? The one that ended with "Does this rise to the level of requiring, for me, a desysop? I'm leaning towards no." And others leaned towards "yes", it's not as if people couldn't draw different conclusions from your post or could disagree with things you said without actually replying directly to you. You didn't contradict the evidence, you personally didn't find it severe or convincing enough, that's all. That doesn't show that the process needs fixing though, just because enough people disagreed with your opinion and the result wasn't put to the test. Fram (talk) 09:28, 25 November 2024 (UTC)
- Or perhaps they just thought "well, I've put XX years into this and a load of random people with rationales ranging from reasonable to utterly non-existent have told me I'm not fit to do it, so f*** you". If that's the case, I don't blame them. Black Kite (talk) 22:13, 23 November 2024 (UTC)
- Choosing not to do an RRfA was their own choice, particularly if Fastily thought it wouldn't be successful. It was also their choice to make no attempt whatsoever to defend the reams of evidence presented against them in the recall petition of their negative actions toward the editing community. So, yes, Fastily as well was an example of the process working as intended. SilverserenC 22:08, 23 November 2024 (UTC)
- I have to say I don’t get the recall process either. I support admin accountability but just having an arbitrary number of “support” votes, no “oppose” votes, and I guess a time limit instead of consensus forming seems… extremely weird and out of step with how virtually everything else is done on Enwiki. Dronebogus (talk) 10:56, 24 November 2024 (UTC)
- The intended point of the recall petition is not to find consensus or to determine whether the admin has lost the trust of the community, has abused the tools or anything like that. The intended point of the petition is only to prove that a re-RFA is not frivolous. The Re-RFA is where consensus is formed from support and oppose, analysis of evidence, etc. Think of it in judicial terms, the petition is at the pre-trial stage and simply aims to answer the question "are there 25 people who think there is a case to answer?" if the answer is no, then it ends there. If the answer is yes, then you can please innocent or guilty. If you plead guilty you take the sentence (desysopping) and move on. If you plead innocent there is a trial and the jury finds you either innocent or guilty by majority verdict. This is an imperfect analogy of course, but it hopefully helps explain the concept.
- It didn't work like that in either of the two that we've had, but that's a fault with the implementation not with the concept. Thryduulf (talk) 12:57, 24 November 2024 (UTC)
- The problem is, the concept itself makes no sense. Nearly everything on Wikipedia is decided one of three ways: consensus democracy that must be approved/vetoed by an admin (most non-trivial issues); WP:BOLD editing, informal discussion, or admin fiat (trivial issues); or arbitration (extreme fringe cases). This resembles none of those. It’s like arbitration, only everyone can be an arb, and instead of voting yay or nay to take the case you collect signatures to see if there’s general support for a case? Dronebogus (talk) 13:11, 24 November 2024 (UTC)
- The request stage of arbitration is the closest analogy, but it is indeed a process not used anywhere else on Wikipedia. That doesn't mean it doesn't make sense. It's sole purpose is intended to be a check against frivolous requests so that an admin doesn't have to go through re-RFA just because they pissed off a single editor once by making an objectively correct decision. The actual decision is intended to made by consensus democracy at the Re-RFA. Thryduulf (talk) 13:33, 24 November 2024 (UTC)
- I think a limited vote based on a formula like “after 7 days a minimum of 2/3rds of people must support for re-RFA” would be less opaque than trying to start a Wiki-Minyan? Dronebogus (talk) 09:26, 25 November 2024 (UTC)
- That sounds like skipping the petition, and going right to the RRFA, or running two successive RRFA's. I have not been involved in any of this but it is not really hard to understand why there is the two-step process of: 1) calling the question, and 2) deciding the issue. Alanscottwalker (talk) 11:52, 25 November 2024 (UTC)
- Honestly I think it should just go straight to RRFA, and if there’s enough opposition fast enough it can just be WP:SNOW closed. We don’t, for example, ask for 25 signatures to start and AfD discussion in order to weed out frivolous nominations— it’s patently obvious when a nomination is garbage in most cases. RRFA is clearly a last resort, and no established, good faith user is likely to abuse this kind of process so egregiously we need a two-step failsafe. Dronebogus (talk) 12:03, 25 November 2024 (UTC)
- In other words any user should be able to start a binding RRFA on any admin at any time? No, no thank you... – Joe (talk) 12:16, 25 November 2024 (UTC)
- Not any time, there should be a policy that steps must already been taken and failed, ideally multiple times, similar to ArbCom. And not any user, since the starter should probably be autoconfirmed at the absolute minimum, and probably be required to be in goof standing, have X edits, been on WP X years, and been active during the last year. If it was unambiguously required that an RRFA follow these rules or be rejected (with filing an improper case being a sanctionable offense) I don’t think anyone would realistically start a frivolous case. Dronebogus (talk) 12:33, 25 November 2024 (UTC)
- Well, we also don't require a !vote to create an article but we do for an admin. I also don't think it is likely that 'any experienced user' has experience in making an RRFA -- Alanscottwalker (talk) 12:34, 25 November 2024 (UTC)
- An admin is essentially just voted into office; they should be voted out of office in an identical way. There’s no need for some kind of novel additional process on top of that. That’s all I’m saying. Dronebogus (talk) 12:55, 25 November 2024 (UTC)
- In other words any user should be able to start a binding RRFA on any admin at any time? No, no thank you... – Joe (talk) 12:16, 25 November 2024 (UTC)
- Honestly I think it should just go straight to RRFA, and if there’s enough opposition fast enough it can just be WP:SNOW closed. We don’t, for example, ask for 25 signatures to start and AfD discussion in order to weed out frivolous nominations— it’s patently obvious when a nomination is garbage in most cases. RRFA is clearly a last resort, and no established, good faith user is likely to abuse this kind of process so egregiously we need a two-step failsafe. Dronebogus (talk) 12:03, 25 November 2024 (UTC)
- That sounds like skipping the petition, and going right to the RRFA, or running two successive RRFA's. I have not been involved in any of this but it is not really hard to understand why there is the two-step process of: 1) calling the question, and 2) deciding the issue. Alanscottwalker (talk) 11:52, 25 November 2024 (UTC)
- I think a limited vote based on a formula like “after 7 days a minimum of 2/3rds of people must support for re-RFA” would be less opaque than trying to start a Wiki-Minyan? Dronebogus (talk) 09:26, 25 November 2024 (UTC)
- The request stage of arbitration is the closest analogy, but it is indeed a process not used anywhere else on Wikipedia. That doesn't mean it doesn't make sense. It's sole purpose is intended to be a check against frivolous requests so that an admin doesn't have to go through re-RFA just because they pissed off a single editor once by making an objectively correct decision. The actual decision is intended to made by consensus democracy at the Re-RFA. Thryduulf (talk) 13:33, 24 November 2024 (UTC)
- The problem is, the concept itself makes no sense. Nearly everything on Wikipedia is decided one of three ways: consensus democracy that must be approved/vetoed by an admin (most non-trivial issues); WP:BOLD editing, informal discussion, or admin fiat (trivial issues); or arbitration (extreme fringe cases). This resembles none of those. It’s like arbitration, only everyone can be an arb, and instead of voting yay or nay to take the case you collect signatures to see if there’s general support for a case? Dronebogus (talk) 13:11, 24 November 2024 (UTC)
- I think the basic complaint here is that the 25-vote threshold is too easy to meet, and therefore it is unfair to require an affirmative consensus for the admin to retain the tools. I think the 25-vote threshold is fine for weeding out frivolous nominations, but correspondingly I think we should make it harder to remove adminship, i.e. make 50-60% the discretionary range for removing adminship. This would make it in line with most of our other processes, where a slight supermajority is required to make changes, and no consensus defaults to the status quo. Whereas under the current recall system, 25 votes with no opportunity to object are enough to make removal of adminship the status quo, which seems a bit harsh. -- King of ♥ ♦ ♣ ♠ 19:53, 25 November 2024 (UTC)
- I think the 25-vote threshold, because it’s so easy to meet, is essentially pointless because it will only weed out extreme outlier cases that I don’t believe will ever happen enough to be a serious concern. We should just have a supermajority vote requirement, and if we must have a petition it should be a lot higher than 25. Dronebogus (talk) 16:06, 27 November 2024 (UTC)
- We don't have evidence the 25-vote threshold is easy to meet. Of the two recalls, one only hit 25 due to a bad block during the petition period. CMD (talk) 16:14, 27 November 2024 (UTC)
- One more reason I don’t like this: it’s extremely important, but we’re using it to prototype this weird system not used anywhere else on Enwiki and possibly Wikimedia (if you have examples of off-wiki precedent please share them). Dronebogus (talk) 16:18, 27 November 2024 (UTC)
- Have to try new things at some point. But CMD is right, from all the evidence we do have, it looks about right. Where as there is zero evidence that a higher number is required or helpful. PackMecEng (talk) 17:09, 27 November 2024 (UTC)
- It's usually called Approval voting when it's used, though that might not be precisely the right name. It's used all over the Wikimedia movement. At least until recently, both grant requests and the (technical) community wishlist used petition-like voting processes that encouraged support and disregarded opposition votes. That is, if there were 25 people supporting something and you showed up to say "* Oppose because WMF Legal will have a heart attack if you do this", then the request might be rejected because of the information you provided, and your comment might change the minds of potential/future supporters, but it would never be counted as a vote of 25 to 1. It's still counted as a list of 25 supporters. WhatamIdoing (talk) 18:53, 27 November 2024 (UTC)
- The original Phase I Proposal was directly written as adapting dewiki's recall policies into enwiki. I believe the Italian wikipedia also has a threshold to RRFA style process. And I think spanish too? I might be getting some projects confused. But it's directly used in recall in other projects - That's how it was recommended here (and then adapted after). Soni (talk) 18:58, 27 November 2024 (UTC)
- It's usually called Approval voting when it's used, though that might not be precisely the right name. It's used all over the Wikimedia movement. At least until recently, both grant requests and the (technical) community wishlist used petition-like voting processes that encouraged support and disregarded opposition votes. That is, if there were 25 people supporting something and you showed up to say "* Oppose because WMF Legal will have a heart attack if you do this", then the request might be rejected because of the information you provided, and your comment might change the minds of potential/future supporters, but it would never be counted as a vote of 25 to 1. It's still counted as a list of 25 supporters. WhatamIdoing (talk) 18:53, 27 November 2024 (UTC)
- Arbitration election commissioners are chosen by collecting solely supporting statements. Once upon a time, the arbitration election RFCs also consisted of proposals that commenters approved, without any option to oppose. Requests for comments on user conduct also used a format where support for expressed viewpoints were collected, without opposing statements. edited 18:32, 4 December 2024 (UTC) to add another example isaacl (talk) 19:50, 27 November 2024 (UTC)
- @Dronebogus This system was modeled after Adminwiederwahl on the German Wikipedia, which has been in place since 2009 or so. --Ahecht (TALK
PAGE) 07:34, 2 December 2024 (UTC)- Interesting. Dronebogus (talk) 13:14, 2 December 2024 (UTC)
- That being said, different wikis have radically different governance structures. For example, Spanish Wikipedia is apparently much more democratic compared to Enwiki (in the literal sense, not just in the sense of “egalitarian” or “un-tyrannical”). Dronebogus (talk) 03:26, 4 December 2024 (UTC)
- It's worth noting dewiki primarily uses the process to desysop inactive admins and has a much longer petition period. Sincerely, Dilettante 18:12, 4 December 2024 (UTC)
- Have to try new things at some point. But CMD is right, from all the evidence we do have, it looks about right. Where as there is zero evidence that a higher number is required or helpful. PackMecEng (talk) 17:09, 27 November 2024 (UTC)
- One more reason I don’t like this: it’s extremely important, but we’re using it to prototype this weird system not used anywhere else on Enwiki and possibly Wikimedia (if you have examples of off-wiki precedent please share them). Dronebogus (talk) 16:18, 27 November 2024 (UTC)
- We don't have evidence the 25-vote threshold is easy to meet. Of the two recalls, one only hit 25 due to a bad block during the petition period. CMD (talk) 16:14, 27 November 2024 (UTC)
- I think the 25-vote threshold, because it’s so easy to meet, is essentially pointless because it will only weed out extreme outlier cases that I don’t believe will ever happen enough to be a serious concern. We should just have a supermajority vote requirement, and if we must have a petition it should be a lot higher than 25. Dronebogus (talk) 16:06, 27 November 2024 (UTC)
Comparing with de.Wiki maybe apples and oranges. Disclaimer: This is what I have come up with, but a regular de.Wiki user or admin may well be able to improve or correct my findings. First there is the huge difference in scale - the de.Wiki currently runs with only 175 admins. There are nearly 400 former admins (that’s quite a high turnover but recall replaced the earlier term limit system for admins which required automatic re-election), but also there is the question of culture: en.Wiki is a lingua franca project contributed by users from many different backgrounds and regions while the de.Wiki is largely contributed to from a specific language region that shares a common culture which defines their way of doing things such as the way their RfC (Meinungsbild) are structured, voted, and commented on. Since 2009 when the de.Wiki system was rolled out :
- There have been 247 recall cases
- There was a rush of 67 cases in the first year 2009
- Since 2018 there have been 30 cases, an average of 4.29 per year
Breakdown:
- 49 handed their tools in voluntarily after being RECALLED. (zurückgetreten)
- 59 were stripped of their tools following a RECALL case and failed on a rerun (Nicht wiedergewählt)
- 96 were stripped of their tools after the rerun time limit expired (Nach Fristablauf de-administriert/Did not run after being asked to run for re-election)
These figures do not add up because they leave 43 unaccounted for. I think this is because there are several different pages with breakdowns of admin activity. The 43 could be users that passed a recall RfA or they may have handed their tools in voluntarily on recall but I can't find way to know for certain. Kudpung กุดผึ้ง (talk) 23:37, 4 December 2024 (UTC)
- Just in case anyone didn’t get the subtext of my first comment on this: I do think it’s apples and oranges, and that’s why we shouldn’t be using it. Different language editions have such vastly different systems and community cultures they might as well be on other planets half the time. You can’t import stuff between them just because it fills the same niche. Dronebogus (talk) 00:29, 5 December 2024 (UTC)
the REGIME test
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
- That any news outlet or source that refers to a government as a "regime" be considered not reliable for facts about that regime, except for attributed statements.
- That a list be kept and updated, similar to WP:RS/Perennial sources
Skullers (talk) 04:03, 20 November 2024 (UTC)
- Why do we want to only use sources that haven't noticed that a regime is a regime? -- Nat Gertler (talk) 04:09, 20 November 2024 (UTC)
- This would, for example, rule out using a significant proportion of reliable sources covering contemporary North Korea, Afghanistan, Cuba and Iran as well as countless historical governments (e.g. Saddam Hussein's Iraq, Franco's Spain, Gaddafi's Libya, etc). This is clearly hasn't been fully thought through. Thryduulf (talk) 04:17, 20 November 2024 (UTC)
- Well, it might have been thought through if the idea is to exclude sources critical of said regimes, eg Activist takes own life in protest at Iranian regime (BBC). Regards, Goldsztajn (talk) 06:57, 20 November 2024 (UTC)
- That would be a gratuitous failure of NPOV. Thryduulf (talk) 11:04, 20 November 2024 (UTC)
- In heated agreement. Regards, Goldsztajn (talk) 01:57, 21 November 2024 (UTC)
- That would be a gratuitous failure of NPOV. Thryduulf (talk) 11:04, 20 November 2024 (UTC)
- Well, it might have been thought through if the idea is to exclude sources critical of said regimes, eg Activist takes own life in protest at Iranian regime (BBC). Regards, Goldsztajn (talk) 06:57, 20 November 2024 (UTC)
- Bad idea. A biased source does not mean unreliable. See WP:BIASED. However, it is indeed good indicator that a in-text attribution may be needed. Ca talk to me! 15:00, 20 November 2024 (UTC)
- I think this does get at something which is a problem in Wikipedia. It just doesn't quite hit the mark. And that is that there is a core assumption in Wikipedia's handling of news media sources that they are largely independent and that a deviation from editorial independence represents a deviation from best practices. However this often leads to Wikipedia simply assuming the biases of the New York Times and other major media outlets. But there has been an accumulation of multitudinous issues - one of the most recent being accounts of Jeff Bezos influencing the Washington Post to withhold an endorsement of Kamala Harris - that demonstrate that the idea of editorial independence is frankly quaint.
- This, of course, then creates problems with adjudicating those sources that have previously been demonstrated to be non-independent (see for example WP:XINHUA) as the rationale on Wikipedia for treating Xinhua differently from, let's say, the BBC or Al Jazeera for that matter largely depends upon the assumption of independence of those outlets that are not aligned with enemy states of the US/UK hegemony.
- My personal opinion is that the use of news sources on an encyclopedia should be far more limited than it presently is as, in my case, it's not that I trust Xinhua (I don't) but that I don't trust any media outlet to produce material appropriate for a neutral encyclopedia. I don't think a "regime" test is going to improve the quality of pages that over-rely on news media. But I would suggest that it's another indication that Wikipedia needs to be far more critical of what news sources we depend on and in what contexts. Simonm223 (talk) 19:54, 20 November 2024 (UTC)
- No, editorial independence is not the reason for a source being considered reliable or not. Many sources are biased, or influenced by specific governments/interest groups, and are still considered reliable for topics other than the groups influencing them (in which case, by definition, they would not be an independent source). A history of disinformation (actually making up stuff, not just reporting it in a biased way) pushes the source towards being considered unreliable.WP:XINHUA, which you link, demonstrates this clearly, stating
There is consensus that Xinhua is generally reliable for factual reporting except in areas where the government of China may have a reason to use it for propaganda or disinformation.
In the same way, we shouldn't rely on the Washington Post for topics related to Jeff Bezos. Chaotic Enby (talk · contribs) 20:07, 20 November 2024 (UTC)- The example I gave wasn't one of a story about Jeff Bezos or a topic related to Jeff Bezos unless one contends (which, I will grant there's a case to be made) that anything to do with a US election is ultimately about the interests of the Billionaire class. But, you see, that's my point. Pretty much any media outlet will distort truth, spread disinformation or, at the most basic, bury stories that aren't to the interests of their handlers. And I do want to stress that the stories that are not covered is a key method through which media occludes truth. The only real question is whether the handler is a politbureau or a rich guy. I don't think one of those is better than the other. Simonm223 (talk) 20:12, 20 November 2024 (UTC)
- The fact that a news media is influenced to not publish a story makes it biased, but not unreliable. Having a point of view when reporting (or choosing not to report) stories is what every media does, and is different from outright making up disinformation. And that is the difference between bias and unreliability. It's not about who the handler is, rich guys can also own unreliable news sources. Chaotic Enby (talk · contribs) 20:16, 20 November 2024 (UTC)
- I mean we certainly agree about that rich guy. I just think Wikipedia is too fast to treat news sources as reliable out of convenience rather than any real confidence in the quality of information. Simonm223 (talk) 20:20, 20 November 2024 (UTC)
- I agree with Simonm223. I just can't understand why an encyclopedia should be largely based on news sources rather than peer-reviewed academic articles or books. For a start most of them are primary sources, by any definition other than Wikipedia's. This is dumbing-down at its worst. Phil Bridger (talk) 21:09, 20 November 2024 (UTC)
- Exactly, yes. Simonm223 (talk) 22:42, 20 November 2024 (UTC)
- I agree, out article on Donald Trump and Joe Biden for example would do better citing academic sources than news outlets. Ca talk to me! 02:21, 21 November 2024 (UTC)
- I agree with Simonm223. I just can't understand why an encyclopedia should be largely based on news sources rather than peer-reviewed academic articles or books. For a start most of them are primary sources, by any definition other than Wikipedia's. This is dumbing-down at its worst. Phil Bridger (talk) 21:09, 20 November 2024 (UTC)
- I mean we certainly agree about that rich guy. I just think Wikipedia is too fast to treat news sources as reliable out of convenience rather than any real confidence in the quality of information. Simonm223 (talk) 20:20, 20 November 2024 (UTC)
- The fact that a news media is influenced to not publish a story makes it biased, but not unreliable. Having a point of view when reporting (or choosing not to report) stories is what every media does, and is different from outright making up disinformation. And that is the difference between bias and unreliability. It's not about who the handler is, rich guys can also own unreliable news sources. Chaotic Enby (talk · contribs) 20:16, 20 November 2024 (UTC)
- The example I gave wasn't one of a story about Jeff Bezos or a topic related to Jeff Bezos unless one contends (which, I will grant there's a case to be made) that anything to do with a US election is ultimately about the interests of the Billionaire class. But, you see, that's my point. Pretty much any media outlet will distort truth, spread disinformation or, at the most basic, bury stories that aren't to the interests of their handlers. And I do want to stress that the stories that are not covered is a key method through which media occludes truth. The only real question is whether the handler is a politbureau or a rich guy. I don't think one of those is better than the other. Simonm223 (talk) 20:12, 20 November 2024 (UTC)
- No, editorial independence is not the reason for a source being considered reliable or not. Many sources are biased, or influenced by specific governments/interest groups, and are still considered reliable for topics other than the groups influencing them (in which case, by definition, they would not be an independent source). A history of disinformation (actually making up stuff, not just reporting it in a biased way) pushes the source towards being considered unreliable.WP:XINHUA, which you link, demonstrates this clearly, stating
- See the definition (specifically 2(c) and 2(d)). Regime is a synonym for "administration" or "government" (when used to describe, as example, the Biden administration or the Tory government). It makes zero sense whatsoever to block sources who use a synonym for administration just because one person feels it has negative connotations. Wikipedia is not the place to practice redefining words or limiting their use based on their worst definitions or connotations. -bɜ:ʳkənhɪmez | me | talk to me! 05:03, 21 November 2024 (UTC)
- Prescriptivism is dead. See examples. There is zero percent usage in modern times that isn't derogatory; literally no one says unironically "our regime", "the regimes of our allies", or "regimes we'd like to do business with". Skullers (talk) 08:29, 21 November 2024 (UTC)
- I agree in as much as "government" would always be a better term in any use case I can think of.
- However, your polemics here have been consistently superficial and unhelpful. It seems almost self-parody to aphorize "prescriptivism is dead" amid seeking to categorically deprecate sources based on the sole criterion of whether they use a particular word, citing what you feel is the only correct definition of said word in practice. Remsense ‥ 论 09:03, 21 November 2024 (UTC)
- The attraction of the word "regime" to headline writers is often that it is simply shorter than "government" or "administration", rather than anything to do with its connotations. Phil Bridger (talk) 09:48, 21 November 2024 (UTC)
- Exactly my point. -bɜ:ʳkənhɪmez | me | talk to me! 23:24, 21 November 2024 (UTC)
- The attraction of the word "regime" to headline writers is often that it is simply shorter than "government" or "administration", rather than anything to do with its connotations. Phil Bridger (talk) 09:48, 21 November 2024 (UTC)
- Prescriptivism is dead. See examples. There is zero percent usage in modern times that isn't derogatory; literally no one says unironically "our regime", "the regimes of our allies", or "regimes we'd like to do business with". Skullers (talk) 08:29, 21 November 2024 (UTC)
- What is the rationale for this proposal? Is there a specific source or incident that prompted it? Gnomingstuff (talk) 01:09, 22 November 2024 (UTC)
- While I understand the rationale for this proposal, IMO it goes way too far. I would agree that it's important to keep in mind when a source is using biased language and consider using in-text attribution in these cases, but certainly it's not worth a blanket ban.
- Furthermore, it's often the case that when the news media uses negative language about a topic, that's because that negative language is the consensus. For instance, nobody would really question the phrase "the Nazi regime" or even probably "the genocidal Nazi regime" from a reliable source, and for good reason. When everyone agrees on a contentious label that implies that in that specific case the label is not, in fact, contentious. Loki (talk) 01:21, 22 November 2024 (UTC)
- This proposal is rather absurd. You can’t declare a source unreliable based on a word, especially one that’s frequently used as a harmless rhetorical flourish. What should we ban next? Sources that use swearing? Sources that use subjective adjectives like “best” or “amazing”? Dronebogus (talk) 13:16, 24 November 2024 (UTC)
- I say we should also ban all sources that use the word "slam". Equally as absurd, but more likely to actually hit unreliable sources. Lee Vilenski (talk • contribs) 13:58, 24 November 2024 (UTC)
- Presumably excluding sports uses? We definitely need sources that report on grand slams. Thryduulf (talk) 14:40, 24 November 2024 (UTC)
Discussion at Wikipedia talk:Criteria for speedy deletion § RfC: Enacting T5 (unused template subpages)
You are invited to join the discussion at Wikipedia talk:Criteria for speedy deletion § RfC: Enacting T5 (unused template subpages). HouseBlaster (talk • he/they) 03:01, 25 November 2024 (UTC)
Information on cross-wiki article creation
The Harald Winter article was created by X3ntar as a port from the German Wikipedia article (found here: Harald Winter). The English article consists primarily of poor English translation and promotional content, and when I was looking through the history of the article, all I saw originally were red-linked accounts created a short while before their edits to the article, leading me to begin researching to source a WP:SPI case. After almost an hour of looking into this, I don't think this is canvassing, meatpuppetry, or anything like that. More likely it's a case of German editors wanting to update the English version of the article. However, I couldn't find any policies or essays that gave advice on how to handle cross-wiki contributions or page creations. Is there a common consensus reached prior? Sirocco745 (talk) 04:59, 25 November 2024 (UTC)
- This doesn't happen very often, so I don't think there are any advice pages. In general, it would be a lovely thing if people who created an article in one language could then do a semi-decent translation into another language.
- I'm aware of two multi-editor cases of that. The first is that when a WMF staffer mentioned writing her first article (in English), a handful of staffers who are not native English speakers (but who are experienced Wikipedians) translated that into their native language as a way of encouraging her to keep editing as a volunteer. This probably happened about a decade ago, and it was very sweet.
- The other was a sustained self-promotion effort by a handful of artists, including hoax photos. See d:Q131244 for what's left of their efforts. We deleted the English article. The reason this sticks in my mind is that they repeatedly faked photos – see c:Commons:Deletion requests/File:Ferlinghetti meets Immagine&Poesia representatives.jpg for one example – of various people and the poet Lawrence Ferlinghetti. Every few months, one of the same two photos of Ferlinghetti in a public place would appear, with a different person photoshopped into the scene next to him, and it would get added to an article with a caption saying something like "Ferlinghetti met with so-and-so" (a different name each time). The result is that every remaining mention of that group seems suspicious to me. WhatamIdoing (talk) 02:09, 27 November 2024 (UTC)
- Okay, thanks for responding. I'm going to think about what can be done to assist editors in future scenarios and draft some thoughts for an essay in my sandbox later. I don't believe that creating a policy proposal is worth it right now, since as you've observed, cross-wiki article copy-pasting isn't a major concern due to its relative uncommonness. I'm considering writing up an essay on the subject instead, maybe also creating a template later on to go at the top of an article that says something along the lines of "This article was cross-posted from the "XYZ Wikipedia" and is currently undergoing translation, discussion, and improvement." Sirocco745 (talk) 02:56, 27 November 2024 (UTC)
Topics on Jehova's Witnesses - article spamming issues
Polish Wikipedia is experiencing and uptick in Jehova's Witnesses topics article spamming, surrepticious edits pushing JW terminology etc. One of current problems is the spamming of separate articles for every "convention", which is an annual (I think) event with a theme and about 100k visitors. We are discussing their notability right now, and I was wondering whether English Wikipedia already discussed and cleaned this, which would be helpful? If you remember any topic discussing notability or monitoring of Jehova's Witnesses related topics, and possibly deleted articles. (I'm not sure if there is any sensible search method of deleted articles archive/log? Can I use any wildcards in Special:Log/delete? It doesn't seem to work.) Tupungato (talk) 12:04, 25 November 2024 (UTC)
- @Tupungato, we used to have a list of conventions, but it was deleted 16 years ago at Wikipedia:Articles for deletion/List of Jehovah's Witnesses conventions. I'm not sure we would make the same decision today. Information about some conventions is in History of Jehovah's Witnesses. WhatamIdoing (talk) 02:22, 27 November 2024 (UTC)
- @Tupungato: I'm probably one of the best people you could talk to about this. I've been trying to remove the emphasis on primary sources when JWs are talked about throughout enwiki. The Jehovah's Witnesses article used to cite the denomination's magazines 100+ times. I fixed that. Unfortunately I don't speak Polish but I have an extensive book collection on secondary sources about JWs if you ever wanted me to look something up for you. Clovermoss🍀 (talk) 14:09, 4 December 2024 (UTC)
- In regards to notability, we don't really have articles on individual conventions. I think a few are (or should be) mentioned at the History of Jehovah's Witnesses if secondary sources talked about them, but otherwise that sort of thing definitely wouldn't meet our notability guideline for standalone articles. I'm not sure what the standards at the Polish Wikipedia are because I know various projects have different standards. If you're looking for AfDs, the most recent one I can think of is Wikipedia:Articles for deletion/List of Watch Tower Society publications (2nd nomination). I've mostly been focusing on improving the content we have as there's only a handful of people editing the JW topic area and a lot of what was written a decade ago uses almost exclusively primary sources. Clovermoss🍀 (talk) 14:23, 4 December 2024 (UTC)
Titles of articles about false theories or accusations
This seems to be a little bit inconsistent. Some have "conspiracy theory" in the title, clearly stating they are false (I don't think there's any possible way any even remotely possible theory or accusation would have the words "conspiracy theory" in it). Some go even further outright stating "myth" (not unwarranted if it is clearly false).
- LGBT chemicals conspiracy theory
- LGBTQ grooming conspiracy theory
- Moon landing conspiracy theories
- International Jewish conspiracy
- 999 phone charging myth
- John F. Kennedy assassination conspiracy theories
However: These do not, despite the article clearly stating the theory or accusation is incorrect:
- Fan death
- Allegations of genocide in Donbas (Note: Allegations of genocide of Ukrainians in the Russo-Ukrainian War has the same title format, despite one referring to actual actions, and one that serves only as a casus belli with no basis at all in actual true events)
- Vaccines and autism (Note: the fraudulent study that begun this conspiracy is titled Lancet MMR autism fraud, not using the word "study" or something not indicating it was a fraud in the title, which it used to, I don't know when it was changed)
- Abortion–breast cancer hypothesis
- Turbo cancer
Is there some kind of policy regarding whether to include "conspiracy theory", "myth", etc in article titles about false theories or accusations? </MarkiPoli> <talk /><cont /> 12:37, 25 November 2024 (UTC)
- Generally, all articles should be titled neutrally and in line with their common name, where they have one. If the significant majority of reliable sources do not describe something as a conspiracy theory or myth (even if they are false) then our article titles should not. In most cases where "myth" and "conspiracy" appear in the article titles they are descriptive as there is no single common name for the topic(s) covered. Consistency is part of the article titles policy but it is only one criterion and generally not regarded as the most important. Thryduulf (talk) 12:50, 25 November 2024 (UTC)
- I see two situations here: one where the article title wouldn’t work without the addition of “conspiracy theory” (i.e “International Jewish” is a non sequitur fragment); and one where the title would work (“999 phone charging” makes sense on its own). We don’t need to state something is a myth in the title if the article explains it’s a myth; there’s enough RFK Jr. types whining at Talk:Turbo cancer to prove that much. Dronebogus (talk) 13:10, 25 November 2024 (UTC)
- Agree with Thryduulf. We should use titles that are considered the common name for the topic and that fall with the article title policy, and then after that any necessarily disambiguation steps to differentiate from other topics. And as long as the lede sentence or lede itself (as in the case of Vaccines and autism) is clear what is legitimate science or fact and what is a conspiracy theory, pseudoscience, or disproven, then its not as important for the title to reflect that as well. Masem (t) 13:31, 25 November 2024 (UTC)
- Indeed there are some editors on the sceptic side who seem to feel that it is necessary to explicitly and stridently describe something as pseudoscientific at every possible opportunity. We don't need to bash our readers over the head with it, indeed doing so can be contrary to NPOV (e.g. when reliable sources disagree and/or take a more nuanced approach). Thryduulf (talk) 14:39, 25 November 2024 (UTC)
- I think that what leads to adding "conspiracy theory", "myth", etc. generally boils down to whether the topic is one that perennially annoys the regular page watchers at WP:FRINGE/N. So, for instance, Fan Death isn't caused "the Fan Death Myth" largely because there's not a large proportion of editors rushing to the Fan Death article to say "this is a real serious problem guys". Simonm223 (talk) 14:48, 25 November 2024 (UTC)
- I think that’s a genuine problem that we should probably address— some anti-fringe editors are among the most aggressive contributors I’ve encountered, probably because too many “skeptics” are also culture warriors who need to right great wrongs by doing everything short of calling something “stupid” and its adherents “idiots”, which of course actually damages our credibility. Dronebogus (talk) 15:09, 25 November 2024 (UTC)
- I'm all for preventing the spread of quack medicine and Ufology silliness on the encyclopedia but, generally, the fringe noticeboard is poorly equipped to address assessments of what research is fringe outside of medicine, history and archaeology. I think some of these anomalous titling conventions kind of point toward that specificity of scope. Simonm223 (talk) 15:57, 25 November 2024 (UTC)
- FRINGE should really only apply to topics where objective research have thoroughly debunked the notion, and not to areas where questions remain open or where debunking may never be possible at which point Undue becomes the answer. For example, whike most science rejects the COVID lab theory, it's still near difficult to devisicely conclude that the lab theory is not posdible, so we should avoid calling it fringe but clearly note the weight of experts that have dismissed it. — Masem (t) 16:54, 25 November 2024 (UTC)
- Hmm, there is a difference between "theories that are scientific, plausible and supported only an extreme minority of sources but have not been/are unlikely to be conclusively disproven", "theories that are scientific, were previously mainstream but no longer are, but are still supported by an extreme minority of sources as they have not been conclusively disproven". "theories that are scientific but implausible to the extent that mainstream sources do not feel the need to conclusively disprove them.", "theories which are scientific and have been conclusively disproven, but still have some supporters", "theories which are pseudoscientific" and "theories which are neither scientific nor pseudoscientific". I've seen FRINGE used to describe all of these cases, which is unhelpful. Thryduulf (talk) 17:08, 25 November 2024 (UTC)
- FRINGE should really only apply to topics where objective research have thoroughly debunked the notion, and not to areas where questions remain open or where debunking may never be possible at which point Undue becomes the answer. For example, whike most science rejects the COVID lab theory, it's still near difficult to devisicely conclude that the lab theory is not posdible, so we should avoid calling it fringe but clearly note the weight of experts that have dismissed it. — Masem (t) 16:54, 25 November 2024 (UTC)
- I'm all for preventing the spread of quack medicine and Ufology silliness on the encyclopedia but, generally, the fringe noticeboard is poorly equipped to address assessments of what research is fringe outside of medicine, history and archaeology. I think some of these anomalous titling conventions kind of point toward that specificity of scope. Simonm223 (talk) 15:57, 25 November 2024 (UTC)
- I think that’s a genuine problem that we should probably address— some anti-fringe editors are among the most aggressive contributors I’ve encountered, probably because too many “skeptics” are also culture warriors who need to right great wrongs by doing everything short of calling something “stupid” and its adherents “idiots”, which of course actually damages our credibility. Dronebogus (talk) 15:09, 25 November 2024 (UTC)
- I think that what leads to adding "conspiracy theory", "myth", etc. generally boils down to whether the topic is one that perennially annoys the regular page watchers at WP:FRINGE/N. So, for instance, Fan Death isn't caused "the Fan Death Myth" largely because there's not a large proportion of editors rushing to the Fan Death article to say "this is a real serious problem guys". Simonm223 (talk) 14:48, 25 November 2024 (UTC)
- Indeed there are some editors on the sceptic side who seem to feel that it is necessary to explicitly and stridently describe something as pseudoscientific at every possible opportunity. We don't need to bash our readers over the head with it, indeed doing so can be contrary to NPOV (e.g. when reliable sources disagree and/or take a more nuanced approach). Thryduulf (talk) 14:39, 25 November 2024 (UTC)
- I think part of the issue is: there is a Kennedy assassination, but this article is about the conspiracy theories; there is grooming but this article is about about a conspiracy theory; there is phone charging but this article is about a myth; there are international Jewish organizations but this article is not about that, etc. So, the article title is limited to (and limits) the scope of the article. And other times, 'myth' or 'conspiracy theor[ies]' is in a common name for the subject. Also note, you really can't tell why an article is called 'this' instead of 'that', unless it has actually been discussed. Article title decisions are made in a decentralized manner, and may never be revisited. Alanscottwalker (talk) 12:46, 26 November 2024 (UTC)
- Alan raises a good point… when there actually are theories that postulate a conspiracy, then it is not POV to call them “conspiracy theories”. That is a neutral descriptive title, not a pejorative one. Blueboar (talk) 13:32, 26 November 2024 (UTC)
- I am not sure if that's true, that those that subscribe to a theory that is based on conspiracy would necessary call it a conspiracy theory themselves. Eg those that claim there is a deep state aren't usually calling that a conspiracy theory, but a theory about conspiracies, if that makes sense. Masem (t) 15:46, 26 November 2024 (UTC)
- And according to that article "deep state" is a pejorative. Regardless, just because you have Illuminati does not mean you can't have New World Order conspiracy theory. The Illuminati of Bavaria, can well be a different matter than the Illuminati of the 1960s novel.[4] Alanscottwalker (talk) 16:31, 26 November 2024 (UTC)
- I am not sure if that's true, that those that subscribe to a theory that is based on conspiracy would necessary call it a conspiracy theory themselves. Eg those that claim there is a deep state aren't usually calling that a conspiracy theory, but a theory about conspiracies, if that makes sense. Masem (t) 15:46, 26 November 2024 (UTC)
- Alan raises a good point… when there actually are theories that postulate a conspiracy, then it is not POV to call them “conspiracy theories”. That is a neutral descriptive title, not a pejorative one. Blueboar (talk) 13:32, 26 November 2024 (UTC)
- I would like to add that, while I would like standardized article titles and would also like if some anti-FRINGE editors dropped the “angry atheist” stereotype, I think this is an exceedingly trivial issue that does not need to be “solved”. Dronebogus (talk) 16:03, 27 November 2024 (UTC)
New users required to cite sources when creating an article
This wishlist item proposes a hard edit filter which would change citation policy for new users. We've repeatedly discussed requiring sources, and the consensus has been not to require them; per current policy, articles must be on notable topics and statements must be citable, but neither need be cited.
I know changes that affect new editors typically don't ignite as much interest as those that affect established editors, but they are in some ways more important; anything that affects our retention rate will eventually substantially affect the number of active editors, and the nature of their editing.
More broadly, it might be good to set limits on policy changes done through a wishlist survey on another wiki; big changes need broader discussion. HLHJ (talk) 01:05, 27 November 2024 (UTC)
- I strongly oppose implementing this on en-wiki. This is not the sort of change that the broader community should be allowed to dictate to local communities. voorts (talk/contributions) 01:22, 27 November 2024 (UTC)
- It's just a wish. Anyone can male one. We don't know whether it will ever be implemented (community wishlists don't exactly have a good track record), never mind turned on on enwiki. – Joe (talk) 05:52, 27 November 2024 (UTC)
- As Joe says, a wishlist item is a long way from becoming something that works. We don’t have need for limits on changes; it is very rare for any changes to be pushed on en.wiki. Those that are are large-scale changes that affect all wikis (think Vector2022 or the upcoming IP masking), and the community here is usually very aware of these ahead of time. If wishlist items turn into tools the wiki can use, they tend to require local activation, as different projects have different needs. (En.wiki for example already has WP:NPP, which will see any new pages, which may include pages that aren’t meant to have sources, like disambiguation pages.) CMD (talk) 08:17, 27 November 2024 (UTC)
- The WMF Community wishlists in the past have actually had some impressive successes, particularly in 2018 for NPP's Page Curation extension improvements. It is not all that rare for any changes to be pushed on en.wiki; two slightly earlier community driven major policies largely contributed - at the time - to reducing the flow of sewage in the new page feed: the 2016 NPP user right, and after a 7 year battle with the WMF, the 2018 ACPERM. However, the number of new registrations has since grown again by users whose first intention above all else is to create a new article by hook or crook with little or no regard for notability, relevance, UPE, and spam policies. NPP has lost many of its prolific, skilled patrollers and coordinators either through burn-out and/or the constant whining either from users whose inappropriate articles have been consigned to the queues for the various trash cans or draft space, or have been driven away for good by other (non NPP) back office regulars' complaints, for the sake of complaining, over a couple of misplaced CSDs or AfDs out of thousands.
- The NPP backlog sawtooth profile looks menacing - it should be a regular low-value straight line. It is well known common knowledge that NPP is hopelessly overburdened and can no longer sensibly cope with even the minimum suggested criteria for patrolling new pages. The best way to ensure that the WMF's flagship project - the one that draws all the donations - becomes an untrustworthy resource full of useless and corrupt articles, is to sit back and do nothing and let WP become a mire of misinformation and spam. Wikipedia has already become the buck of media satire with "If you believe Wikipedia, you'll believe anything". The quest is therefore for any measures that will tighten up the article quality at the source of creation.
- Although they are aware of them, as usual the WMF Growth Team has played down and resisted addressing these issues in favour of pursuing other, and expensive initiatives of their own design which in the NPP realm remain ineffective. It's the responsibility of the WMF to ensure new users are aware of the rules at the point of registration.
- The NPP team has handed solutions to the WMF on a plate, which at the same time will not only reduce the tide of rubbish, but most importantly, encourage the good faith new users to offer articles that have a fair chance of being published. All this project needs is to be written up in MediaWiki source code, but of course short of a mutiny by the community, the WMF will not entertain any ideas that they did not think of themselves and can collect the accolades for.
- The "anyone can edit" principle is not a get out of jail free card; it should be quoted in its full context: 'Anyone can edit as long as they play by the rules'. For once and for all, just make those basic rules clear for bona fide new registrants, and help them comply. Kudpung กุดผึ้ง (talk) 03:53, 28 November 2024 (UTC)
Wikipedia has already become the buck of media satire with "If you believe Wikipedia, you'll believe anything
- This is just rhetorically dishonest. When people say this they are generally referring to vandalism, hoaxes, and information on high-profile articles, not the stuff that goes through NPP.
- Like, just think about this for a second. Think about the kind of misinformation people generally disseminate and what it is about. Almost always, it's about things people already care about, which means things we have articles on. COVID. Political stuff. Current events. Not obscure new articles. Gnomingstuff (talk) 17:51, 29 November 2024 (UTC)
- I believe that wiki should at least allow new users to create stubs without citations. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:45, 29 November 2024 (UTC)
- @Gnomingstuff :
Almost always, it's about things people already care about, which means things we have articles on. COVID. Political stuff. Current events. Not obscure new articles.
This is unfortunately not true as 800 patrollers will confirm. NPP needs all the help it can get. Why not enroll at the NPPSCHOOL, get qualified, apply for the user right and help out? Kudpung กุดผึ้ง (talk) 07:43, 2 December 2024 (UTC)- They can do so in draft space. BD2412 T 20:52, 29 November 2024 (UTC)
- I think you're misinterpreting my point. I realize that NPP obviously gets a lot of junk and unsourced stuff. But this is not the junk that makes Wikipedia "the butt of media satire." The media satire is about things people actually look up, such as high-profile politicians, major scientific topics, etc.
- That doesn't mean that patrolling new pages is not useful, and I am glad people are doing it (I personally doon't have time to take on any more responsibilities and don't foresee that changing). But it's not an area of the project that tends to escape containment, and so should be done on its own merits without trying to make it about "what would the press think?" Gnomingstuff (talk) 07:56, 2 December 2024 (UTC)
- Without commenting on the merits of the core portion of this proposal, I think it's worth pointing out that certain types of mainspace pages don't need and indeed are expected not to have references. You could try to get around that by excluding pages tagged with the DISAMBIG magic word, SIA templates, etc. But that won't work if they don't properly format the page common for new users; I don't have any statistics handy for often new users create those type of pages, but I suspect its a large enough number that it should be taken into consideration. 184.152.68.190 (talk) 04:23, 30 November 2024 (UTC)
- Good point. HLHJ (talk) 23:57, 1 December 2024 (UTC)
- One of the commentators on the original proposal pointed out that articles created through AfC in practice are required to have references, so this would not actually change anything for new editors, who have to use AfC anyway. So it would perhaps it would apply to somewhat more experienced editors.
- There is a widespread belief that references are required for every statement, let alone article. This is usually applied to edits by newcomers, who get scared off when a solid but unreferenced contribution is deleted without trying to WP:JUSTFIXIT, and who would learn how to cite if it was instead tagged "citation needed" or a cite was added by another editor (we have studied this). But I've seen a solid-but-uncited edit by an admin removed by an IP, too; this is much less serious.
- There is also confusion between notable and has citations that establish notability. I recently posted an unreferenced stub article in the mainspace, and it was draftified and AfCd within the hour. The topic was notable, meaning it would not have been deleted if listed at AfD, and I think I remember an explicit statement that draftifying was an alternative to deletion and could only be used if articles met deletion criteria. The point here is not the individual editors who did this in good faith; the point is that the ensuing discussion made it clear that most of the people on the AfC board thought it reasonable to draftify any unsourced article.
- We need to make a conscious choice to either:
- change policy to require citations on every article (meaning we delete all the articles at Category:Articles lacking sources, or have a massive sourcing drive before the policy comes into effect) and every edit made by a new editor
- find a way to teach editors to cite unsourced things, and delete them only if the are unsourcable, which is current policy.
- Opinions? Next steps? HLHJ (talk) 23:51, 1 December 2024 (UTC)
- This is not a new discussion. There is no consensus to do bullet point one, and it is very unlikely to get any. At the same time, the existence of older unsourced articles is not a good reason for new articles to lack sourcing. The example process given seems fine, the article was given time to develop in draft space and was put into mainspace when ready. CMD (talk) 00:04, 2 December 2024 (UTC)
- Am I right to say, then, that you favour a policy of "all new articles must have sources" (regardless of whether the editor is new)? How about "all statements added by new editors must have sources"? HLHJ (talk) 15:57, 2 December 2024 (UTC)
- You might be right about my personal policy within some nuance, but the community has decided not to draw a firm line for sourcing but instead to keep a slightly fuzzier set of guidelines. This won't be changed by developments in WMF-developed tools, which we can use or not as desired. CMD (talk) 05:39, 4 December 2024 (UTC)
- Am I right to say, then, that you favour a policy of "all new articles must have sources" (regardless of whether the editor is new)? How about "all statements added by new editors must have sources"? HLHJ (talk) 15:57, 2 December 2024 (UTC)
- @HLHJ I would be very surprised if your ever saw '
an explicit statement that draftifying was an alternative to deletion...
'. If you did, I would like to see the diff. As we say on Wikipedia: 'Serious claims need serious sources'. No qualified New Page Patroller would ever contemplate doing such a thing and if they misused their tools to that end they would quickly lose that user right. Articles moved to draft are often pages which the creator has no intention of returning to and completing. If the the creator or a member of the community does not bring the draft or stub up to an acceptable artile within 6 months, it can be deleted under the special conditions at G13 and only under those conditions. Articles can only be physically deleted by an admin and the community is under no obligation to step in and rescue such articles. Kudpung กุดผึ้ง (talk) 07:25, 2 December 2024 (UTC)- Sorry, Kudpung; I think, in trying to be brief, I was incomprehensible. What I meant is that articles that aren't fit for the mainspace, and would thus be deleted if sent to AfD, can be draftified instead of listed at AfD (assuming that they are notable topics, capable of improvement). Articles that are fit for the mainspace, and would therefore not be deleted in AfD, should be left in the mainspace. In other words, we have one standard for whether articles are fit for the mainspace. AfD and NPP do not, or should not, have separate standards. HLHJ (talk) 16:04, 2 December 2024 (UTC)
- AFD isn't supposed to be deleting articles about notable topics. WP:Deletion is not cleanup. I would also question this claim that we have any "standard for whether articles are fit for the mainspace". There appear to be a wide variety of views but no agreed-upon standard.
- That said, draftication is used as an alternative to deletion, as authorized under the Wikipedia:Deletion policy#Alternatives to deletion policy. WhatamIdoing (talk) 23:04, 2 December 2024 (UTC)
- Sorry, Kudpung; I think, in trying to be brief, I was incomprehensible. What I meant is that articles that aren't fit for the mainspace, and would thus be deleted if sent to AfD, can be draftified instead of listed at AfD (assuming that they are notable topics, capable of improvement). Articles that are fit for the mainspace, and would therefore not be deleted in AfD, should be left in the mainspace. In other words, we have one standard for whether articles are fit for the mainspace. AfD and NPP do not, or should not, have separate standards. HLHJ (talk) 16:04, 2 December 2024 (UTC)
- This is not a new discussion. There is no consensus to do bullet point one, and it is very unlikely to get any. At the same time, the existence of older unsourced articles is not a good reason for new articles to lack sourcing. The example process given seems fine, the article was given time to develop in draft space and was put into mainspace when ready. CMD (talk) 00:04, 2 December 2024 (UTC)
- @HLHJ: MY bad. My humble apologies. In a moment of mental aberration I totally misread what you had written. In fact I crafted and co-crafted much of the policies surrounding NPP, pretty much wrote the instructions at WP:NPP and designed and rolled out the user right. A lot has been done recently to improve and clarify the notability standards, especially on some kinds of BLP, but it's an on-going work. NPP is triage, it does mean sending stubs to draft but it's a long way off sounding their death knell. Equally important at NPP is knowing what is is an encyclopedically relevant topic. The fact that something can be sourced does not necessarily mean it belongs here. Kudpung กุดผึ้ง (talk) 10:03, 3 December 2024 (UTC)
- No worries, apologies accepted as excessive! Text-only conversations are easy to misunderstand, there's less redundancy. My thanks to WAID: the WP:ATD-I subsection of Wikipedia:Deletion policy#Alternatives to deletion is, I think, what I was looking for, but I misremembered it, or it's changed. It says that a notable-topic article can be deleted if it "severely fails the verifiability or neutral point of view policies", which I think of as "an article that is worse than no article". Draftifying can be cleanup, and I think in practice is done at a lower threshold, but I'm not sure.
- Unlike AfD, no reason is given when draftifying. I don't very much mind what standards we have for new articles, but if I fail to meet them I'd like to know how, so I can avoid it in future. If I'm confused, new editors certainly are.
- I'm actually more worried about the editors who seem to be acting on the misconception that all statements (not just BLP), or at least all statements by new editors, need to be cited. I'm pretty sure this is terrible for editor retention (from anecdote and stats). What would be a good way to let them know that they needn't delete every new uncited statement as if it were vandalism? I'm told that this is a bit too complex for a user warning template; any other ideas? HLHJ (talk) 16:09, 3 December 2024 (UTC)
- Well... I've been told that one of the best ways to retain a new editor (at least for definitions of "retain" that are as simple as "get them to edit the next day") is to leave their uncited text in the article, and add a {{citation needed}} tag at the end of it.
- Obviously, there are limits (e.g., blatant vandalism, probably untrue material, libelous BLP content), but if retention is the goal, then we should do more inline tagging and less "Ooops, you made one mistake. Go back to the beginning and start completely over". Wikipedia:Wikipedia is not a game of Mother, May I?, but some of us treat it that way. WhatamIdoing (talk) 01:05, 4 December 2024 (UTC)
- Agreed; there are plenty of reverts of newbies that are fully justified. It's a specific and thus perhaps fixable problem when editors think "unsourced" is in itself an adequate justification for reverting. Newbies who figure out how to source correctly on their first edit are rare.
- In an attempt to fix this one specific problem, I drafted a user warning template, and tried unsuccessfully to add information to introductory tutorials, and discussed UI design for adding of inline tags using semiautomatic tools (T209797), and putting one-click templates in VE (T55590) might help a bit. But I've not gotten anywhere with any of this. Any suggestions, however wild, would be most welcome. HLHJ (talk) 05:16, 4 December 2024 (UTC)
- @HLHJ: MY bad. My humble apologies. In a moment of mental aberration I totally misread what you had written. In fact I crafted and co-crafted much of the policies surrounding NPP, pretty much wrote the instructions at WP:NPP and designed and rolled out the user right. A lot has been done recently to improve and clarify the notability standards, especially on some kinds of BLP, but it's an on-going work. NPP is triage, it does mean sending stubs to draft but it's a long way off sounding their death knell. Equally important at NPP is knowing what is is an encyclopedically relevant topic. The fact that something can be sourced does not necessarily mean it belongs here. Kudpung กุดผึ้ง (talk) 10:03, 3 December 2024 (UTC)
Propose to create page of block discussion in noticeboards
Hello users, I propose having a page within noticeboards in the "general" section called "Block discussion" with a list of active discussions (which could be a review request, an unblock request or a discussion on whether to block the user) (to separate from administrators ' noticeboard, to clarify further, and that within the DB there are 5 topics, 1. Evidence (evidence that the user can provide as a reason for blocking, will be ignored in the review request), 2. Defense (defense of the blocked or accused against blocking or defending its review), 3. Comments (comments from anyone who is registered and at least 10 edits whether they agree, disagree or neutrality with blocking, a filter or unblocking), 4. Administrators' evaluation (where administrators agree or disagree with blocking, unblocking or filtering, this means that the conclusion depends on the administrators' assessment), 5. Conclusion (Conclusion of the discussion if the blocking, filtering or unblocking was approved).
NOTE: And there must be verification in the discussion to prevent someone from manipulating BD through sockpuppetry. JPPEDRA2 why not? 18:54, 27 November 2024 (UTC)
- This means I'm proposing to separate "Wikipedia:Block Discussion" from "Wikipedia:Administrators' noticeboard" to be clearer JPPEDRA2 why not? 18:57, 27 November 2024 (UTC)
- I understand the desire to split things off of AN/ANI, but this split poses several problems in practice. Quite frequently the proposal for a CBAN only arises after discussion has been ongoing for some time, and while it could be split off at that point it creates an extra bureaucratic step for questionable benefit. The other issue is that neither CBAN impositions nor their appeals are all that common, and separate noticeboards only tend to work well for things that have a fairly high frequency threshold. Arguably, if we had to do it over again AN wouldn't be the catchall, but at this point changing that is more trouble than its worth.
- Granted, CBAN and appeal procedures could be tightened up separately without splitting anything off, but there's a longstanding preference for unstructured and somewhat messy discussions, and I don't see that changing anytime soon. 184.152.68.190 (talk) 17:03, 28 November 2024 (UTC)
- @184.152.68.190 Ok, i'm understand, so can i'm cancel this proposal because that will be more complex? JPPEDRA2 why not? 17:57, 28 November 2024 (UTC)
- @JPPEDRA2: Yes, you can just close it as withdrawn, if you so chose. But don't let me discourage you if you want to leave this open for input from others; every so often perrenial proposals do get implemented, including rather recently, though its usually better to get input at WP:VPI first.
- As a side note unregistered users cannot yet be pinged, though apparently that is coming sometime in the not to distant future. 184.152.68.190 (talk) 18:52, 28 November 2024 (UTC)
- Ok, so I won't cancel now, I will let others discuss it, if it is rejected, put it in those VPI or perrenial proposals that you mentioned, thanks non-registrered user. JPPEDRA2 why not? 19:20, 28 November 2024 (UTC)
- We need someone and other users to discuss this whether they agree or disagree, I will wait.
- IP user, can we ping other users or wait? JPPEDRA2 why not? 23:40, 29 November 2024 (UTC)
- @JPPEDRA2: Neutral pings are allowed, but be aware of WP:CANVASS; same with {{please see}} notices. Remember we're all volunteers so it may be a while until others weigh in, and sometimes discussions just don't gain traction for whatever reason. I'm pretty busy myself so I might attend to some things for another day or two here, but after that I'll probably be away for a while.
- Even if this doesn't attract any interest, you can always raise the issue again in looser format at WP:VPI later, and see if any good ideas come up. 184.152.68.190 (talk) 02:04, 30 November 2024 (UTC)
- Understood the WP:CANVASS part, but the "please see" should it be placed or not? JPPEDRA2 why not? 17:38, 30 November 2024 (UTC)
- @JPPEDRA2:, both pings and {{please see}} notices are ok, so long as they are neutrally worded, and not given selectively to users based on their known preferences, see WP:APPNOTE for details. 184.152.68.190 (talk) 19:02, 30 November 2024 (UTC)
- Understood the WP:CANVASS part, but the "please see" should it be placed or not? JPPEDRA2 why not? 17:38, 30 November 2024 (UTC)
- Ok, so I won't cancel now, I will let others discuss it, if it is rejected, put it in those VPI or perrenial proposals that you mentioned, thanks non-registrered user. JPPEDRA2 why not? 19:20, 28 November 2024 (UTC)
- @184.152.68.190 Ok, i'm understand, so can i'm cancel this proposal because that will be more complex? JPPEDRA2 why not? 17:57, 28 November 2024 (UTC)
- I'm not sure why, but I was invited here by a notice on my talk page. My initial impression is that this is a solution in search of a problem - largely per the IP editor's first comment. Very few AN(I) threads start off as a proposal for a ban, and divorcing such a proposal from the preceding discussion seems suboptimal, especially ban proposals often run concurrently with proposals for lesser restrictions. Appeals of bans being moved to a new page is an easier sell from a purely practical perspective but it would be a relatively little-used, for example there are none currently being discussed at either AN or ANI, and it would be less watched than either page (which is not a good thing for a community block appeal). Thryduulf (talk) 22:58, 30 November 2024 (UTC)
- @JPPEDRA2: I see that you have very few mainspace edits and you haven't participated in any AN discussions. I recommend working on some easy mainspace edits at WP:TASKS instead of proposing massive changes to areas of the encyclopedia that you don't edit in. voorts (talk/contributions) 23:43, 30 November 2024 (UTC)
- @Voorts Ok dear voorts, thanks for recommendation. JPPEDRA2 why not? 22:24, 1 December 2024 (UTC)
- While I do agree that there are problems with AN/I I don't think those problems are that blocks are discussed there. Rather, as constructed I find it is generally bad at efficiently discussing and resolving urgent issues. I think we should have improved processes in place for promptly identifying and closing spurious cases so that they don't become drawn-out time sinks that often result in either nothing happening but an argument or, occasionally, a boomerang. I respect the WP:BOLD spirit of this proposal but I think it's unlikely to cure what ails AN:I. Simonm223 (talk) 01:02, 2 December 2024 (UTC)
Global welcoming policy
There is a proposed global policy at meta:Requests for comment/Welcoming policy: "A wiki is only allowed to post welcome messages to users if their account was originally created at the wiki, or the user has at least one non-imported edit there." Comments belong there and not here. PrimeHunter (talk) 21:48, 27 November 2024 (UTC)
WP:CRYSTAL in officeholder articles and infoboxes
Is the current policy to ignore WP:CRYSTAL in regards to wording in articles related to upcoming officeholders? Donald Trump had the usage "will be inaugurated" until recently and JD Vance has He will resign on or before January 20, 2025, when he will be inaugurated as vice president of the United States
. Similarly, infoboxes have "assuming office on X date". Should it not be "Scheduled to assume office on X date"? There seems to be disagreement on whether CRYSTAL applies since it is almost certain that these individuals will obtain their office barring some unforeseen event. I would like community input on this since if there is CRYSTAL, changes may need to be discussed here and implemented. Noah, BSBATalk 23:32, 29 November 2024 (UTC)
- Reliable sources appear to do both. For example:
- AP article: "President-elect Donald Trump will take office on Jan. 20 after defeating Democratic candidate Kamala Harris."
- NY Times: "Congress is scheduled to meet on Jan. 6, 2025, to count the Electoral College results, and Mr. Trump is set to be sworn into office two weeks later, on Jan. 20."
- Personally, I think this is a distinction without a difference. In common usage, saying "X will do Y on Tuesday" is always subject to the caveat that something might occur that prevents X from doing Y on Tuesday. To quote the philosopher Søren Kierkegaard: "I shall certainly attend your party, but I must make an exception for the contingency that a roof tile happens to blow down and kill me; for in that case, I cannot attend." voorts (talk/contributions) 23:50, 29 November 2024 (UTC)
- This type of stuff is what is outside the bounds of what WP:NOT#CRYSTAL has, eg we can start writing the article for the 2028 Summer Olympics as there's an extremely high certainity it will happen; there may be very extreme circumstances that may cause a change but the odds of those changing events are very low. The planned inaugeration is clearly of the same ilk. — Masem (t) 00:02, 30 November 2024 (UTC)
- The part I noticed was
Dates are not definite until the event actually takes place, as even otherwise-notable events can be cancelled or postponed at the last minute by a major incident
. The Olympics articles always say scheduled rather than will take place. Noah, BSBATalk 00:26, 30 November 2024 (UTC)- It does not matter in this case. If the inauguration of the next US executive is delayed, I’m confident those articles will be immediately updated. Infoboxes don't handle verbiage well. CMD (talk) 01:08, 30 November 2024 (UTC)
- What about other officeholders? Noah, BSBATalk 01:39, 30 November 2024 (UTC)
- I don't see a difference between saying a person is about to become a senator vs. the president. voorts (talk/contributions) 01:51, 30 November 2024 (UTC)
- The higher the number of electees, the more likely it is that something happens to one of them. We have had representatives-elect die before assuming office. It's an issue of saying something is certain to occur rather than very likely to occur. We have nothing to tell us it's certain they assume office on X. Does this policy simply not apply to any officeholder period and we just state they will be inaugurated/assume office on X rather than scheduled to be inaugurated/assume office on X? Noah, BSBATalk 02:20, 30 November 2024 (UTC)
- Ditto voorts; difference without a difference. Regards, Goldsztajn (talk) 03:58, 30 November 2024 (UTC)
- The higher the number of electees, the more likely it is that something happens to one of them. We have had representatives-elect die before assuming office. It's an issue of saying something is certain to occur rather than very likely to occur. We have nothing to tell us it's certain they assume office on X. Does this policy simply not apply to any officeholder period and we just state they will be inaugurated/assume office on X rather than scheduled to be inaugurated/assume office on X? Noah, BSBATalk 02:20, 30 November 2024 (UTC)
- I don't see a difference between saying a person is about to become a senator vs. the president. voorts (talk/contributions) 01:51, 30 November 2024 (UTC)
- What about other officeholders? Noah, BSBATalk 01:39, 30 November 2024 (UTC)
- It does not matter in this case. If the inauguration of the next US executive is delayed, I’m confident those articles will be immediately updated. Infoboxes don't handle verbiage well. CMD (talk) 01:08, 30 November 2024 (UTC)
- The part I noticed was
- This type of stuff is what is outside the bounds of what WP:NOT#CRYSTAL has, eg we can start writing the article for the 2028 Summer Olympics as there's an extremely high certainity it will happen; there may be very extreme circumstances that may cause a change but the odds of those changing events are very low. The planned inaugeration is clearly of the same ilk. — Masem (t) 00:02, 30 November 2024 (UTC)
- The guidance on Wikipedia not being
a collection of unverifiable speculation, rumors, or presumptions
(from Wikipedia:What Wikipedia is not) is guidance on content, with most of the discussion on that page being about what warrants an article. It's not guidance on writing style, so doesn't provide guidance in choosing between writing "X will happen" or "X is scheduled to happen", but whether the statement should be included at all. isaacl (talk) 19:58, 30 November 2024 (UTC)- I think it is reasonable that we should ask editors to use "is scheduled" or "is planned" instead of "will" in cases of near-confirmed future events. Maybe for events where humans have no control on the result, such as the next solar eclipse, we can use "will", but I can't see harm to suggest we be a bit more careful for other cases. Masem (t) 22:04, 30 November 2024 (UTC)
- The point is that I was echoing your statement,
This type of stuff is what is outside the bounds of what WP:NOT#CRYSTAL has
. The choice of verbs is something to be covered by the writing style guidelines (and personally, I think consideration of individual circumstances is sufficiently important that a blanket statement wouldn't be too helpful). isaacl (talk) 22:33, 30 November 2024 (UTC)
- The point is that I was echoing your statement,
- I think it is reasonable that we should ask editors to use "is scheduled" or "is planned" instead of "will" in cases of near-confirmed future events. Maybe for events where humans have no control on the result, such as the next solar eclipse, we can use "will", but I can't see harm to suggest we be a bit more careful for other cases. Masem (t) 22:04, 30 November 2024 (UTC)
- Related: Wikipedia:Village pump (proposals)/Archive 175#RfC: Interim use of successor in Infobox officeholder Just Step Sideways from this world ..... today 21:55, 30 November 2024 (UTC)
- Best to keep doing as we've been doing for years. Making sudden changes now, would be messy. GoodDay (talk) 22:06, 30 November 2024 (UTC)
- I agree with voorts and Kierkegaard. I have notified the Trump article for the OP. ―Mandruss ☎ 04:23, 2 December 2024 (UTC)
- I would say reflecting the inherent uncertainty of future events is generally good practice (e.g., "scheduled to take place" rather than "will take place"). If the wording would be clunky, there can be some flexibility. And we should take care not to be too cautious about expected events; I find it confusing how infoboxes for a TV season will say it consists of three episodes (based on the number aired) when we have sources confirming eight have been made.--Trystan (talk) 15:06, 2 December 2024 (UTC)
- Infoboxes are inherently backwards looking. The number of episodes in a season should not be filled in until the season has ended. Similarly, the field for the beginning of an officeholder's term should not be filled in until it has actually occurred. --User:Khajidha (talk) (contributions) 14:29, 3 December 2024 (UTC)
Can we hide sensitive graphic photos?
Can we hide sensitive graphic photos? I recently came across an article with a photo of a deceased man smiling right at the top—it was deeply disturbing, traumatizing, triggering, shocking, and sickening! This kind of content discourages many people who might otherwise want to read the article and could even provoke serious medical reactions, such as seizures. Imagine if that man's family came across the article and saw him like that, right in their face! Nobody seems to favor this policy, so why do we insist on keeping it? Arabic Wikipedia uses a collapsible template that lets readers choose whether to view such photos, without censoring informative media. Shouldn't we adopt a similar approach? ☆SuperNinja2☆ TALK! 21:41, 30 November 2024 (UTC)
- Not sure where you are getting that the image subject was dead at the time the image was taken. Just Step Sideways from this world ..... today 21:49, 30 November 2024 (UTC)
- I couldn't even think. I was totally shocked. Anyhow, my point still stand. ☆SuperNinja2☆ TALK! 21:51, 30 November 2024 (UTC)
- I don't see anything in the photo, Commons description, or CDC description that states the patient is deceased. Is there a chance this person is alive? –Novem Linguae (talk) 02:05, 5 December 2024 (UTC)
- I couldn't even think. I was totally shocked. Anyhow, my point still stand. ☆SuperNinja2☆ TALK! 21:51, 30 November 2024 (UTC)
- See HELP:NOSEE Lee Vilenski (talk • contribs) 21:50, 30 November 2024 (UTC)
- The issue is that an image one editor might find “disturbing, traumatizing, triggering and shocking” is an image another editor will find informative and helpful. We have no way to know how others will react. It would indeed be censorship to hide such images. Blueboar (talk) 21:50, 30 November 2024 (UTC)
- shouldn't we choose the option that minimize the harm to readers? That's what most companies/organization (idk what is the right term, sorry) do. ☆SuperNinja2☆ TALK! 21:54, 30 November 2024 (UTC)
- We already have. The "harm" to a person seeing such useful images in an encyclopedia is insignificant. The true harm is hiding information from those looking for it.--User:Khajidha (talk) (contributions) 21:19, 1 December 2024 (UTC)
- That is debatable. Emir of Wikipedia (talk) 21:38, 1 December 2024 (UTC)
The true harm is hiding information from those looking for it
- this is exactly what shoving these gore images in people's face does. ☆SuperNinja2☆ TALK! 03:46, 4 December 2024 (UTC)
- How does showing relevant information hide information?--User:Khajidha (talk) (contributions) 11:36, 4 December 2024 (UTC)
- We already have. The "harm" to a person seeing such useful images in an encyclopedia is insignificant. The true harm is hiding information from those looking for it.--User:Khajidha (talk) (contributions) 21:19, 1 December 2024 (UTC)
- shouldn't we choose the option that minimize the harm to readers? That's what most companies/organization (idk what is the right term, sorry) do. ☆SuperNinja2☆ TALK! 21:54, 30 November 2024 (UTC)
- Image censoring is a perennial proposal and really won't go anywhere. And given the topic of that page, I see no real option, since any other image will also be as disturbing. We do ask editors to use the principle of least astonishment, so that same image as the lede on corpse for example would be inappropriate, but not much can be done on that page. Masem (t) 21:51, 30 November 2024 (UTC)
- we can use a collapsible template, then that won't be censoring. ☆SuperNinja2☆ TALK! 21:55, 30 November 2024 (UTC)
- That type of suggestion is part of the perennial proposal on how to deal with such images. There's nothing that can be done to properly hide it. Masem (t) 22:05, 30 November 2024 (UTC)
- We already use collapsible templates for "long" lists, such as for BRICS members.While long lists are far less harmful, the goal was to avoid annoying readers and make them comfortable, encouraging them to read. This is also why we have templates like Template:Split—to make articles easier to navigate. Similarly, graphic images make readers extremely uncomfortable, not only discouraging them from reading a single article but sometimes deterring them from using Wikipedia altogether, which goes against the ideals of an encyclopedia.
- The fact that image censoring is a perennial proposal suggests it’s a problematic topic that many, if not most, editors find uncomfortable. I suspect the primary reason it hasn’t been adopted is the lack of consensus, not because half the community opposes it outright. I propose a solution that could satisfy both groups: a collapsible template. This approach wouldn’t censor anything but would minimize harm.
- Let’s focus on images that could provoke serious medical conditions and ignore the sexual and religiously offensive media for the time. Some readers may have heart conditions, PTSD, or other vulnerabilities, and we must also consider the families of deceased individuals whose photos we use. Additionally, while Wikipedia isn’t intended for children, they do use it, and we can’t ignore that reality.
- In summery, the potential harm caused by showing these images overrides any benefit to the project. And this solution would fix this by making Wikipedia a safer and more inclusive without censoring anything, which is the essential goal. ☆SuperNinja2☆ TALK! 22:28, 30 November 2024 (UTC)
- You've yet to show harm beyond you having a personal reaction to a picture that you didn't understand... an informative picture key to the article that I didn't even slightly flinch upon seeing. (If you have any records of Wikipedia images having provoked seizures, please put them forward.) Had you hidden it by collapsing, I might have assumed that there was something horrible that I wouldn't want to see and avoid getting that information. -- Nat Gertler (talk) 00:02, 1 December 2024 (UTC)
- I know Trypophobia has been the subject of discussion of a good lede that doesn't immediately illicit a problem to readers that have that fear. Masem (t) 00:22, 1 December 2024 (UTC)
- That article has had requests to remove or hide the image for about a decade now. WhatamIdoing (talk) 00:26, 1 December 2024 (UTC)
Had you hidden it by collapsing, I might have assumed that there was something horrible that I wouldn't want to see and avoid getting that information
- That would be your choice not to 'get that information.' However, forcing it on people who don't want to 'get it,' and risking a negative reaction as a result, is the real issue we should be concerned about
You've yet to show harm beyond you having a personal reaction to a picture that you didn't understand... an informative picture key to the article that I didn't even slightly flinch upon seeing
- That is your personal experience, but we know that at least one person had an anxiety attack from that image. As a community, it is our duty to prioritize the safety of our readers and choose the least risky option. ☆SuperNinja2☆ TALK! 13:47, 1 December 2024 (UTC)
- And you had the choice not to "get that information" that was in the picture.... you chose to go to the Wikipedia page about a disease. You claim to have been set off because it was
a deceased man smiling
... only the man wasn't deceased, he is described in the image's description as a "patient" which is not generally a term for a corpse. So what set you off was a man smiling. If you want us to police pictures based on information that you invent about them, it's hard to see how we don't have to police everything on your behalf. When it comes to safety of our viewers and medical-related images, an image can help them recognize the disease and may serve them well. The "least risky" option is simply not having Wikipedia. I hope we don't choose that path. If you think that Wikipedia provides as special danger to you, you are free not to use it. -- Nat Gertler (talk) 17:53, 1 December 2024 (UTC)- I don’t understand what you’re defending. You’re just complaining and criticizing my argument without demonstrating why leaving sensitive media as-is is a better option. Your argument essentially boils down to: “I don’t like your proposal,” which isn’t sufficient.
- Anyway, regardless of whether that man was dead or not, my point still stands.
The "least risky" option is simply not having Wikipedia.
- I don’t think that’s the goal of Wikipedia—to discourage its readers from using it. If the choice is “either read Wikipedia and risk having anxiety attacks or don’t read it at all,” then it’s clear the situation is bad and requires change. ☆SuperNinja2☆ TALK! 21:08, 1 December 2024 (UTC)
- So far, I know of one person claiming to have had a problem, and that's because he saw a picture of a man smiling. Hiding all pictures as not-obviously-problematic as that would basically mean hiding all pictures... and it's not just pictures that upset people, plenty of the text would have to be hidden under the same logic. (People might be freaked out by seeing that a ninja edits Wikipedia.) Folks have pointed you to the option that would let you turn off automatic image display for yourself, and if you wanted to make some argument that that should be a standard option, that may well be a supportable argument... but hiding everything that could possibly upset anyone would basically be hiding everything. -- Nat Gertler (talk) 21:30, 1 December 2024 (UTC)
- And you had the choice not to "get that information" that was in the picture.... you chose to go to the Wikipedia page about a disease. You claim to have been set off because it was
- I know Trypophobia has been the subject of discussion of a good lede that doesn't immediately illicit a problem to readers that have that fear. Masem (t) 00:22, 1 December 2024 (UTC)
Let’s focus on images that could provoke serious medical conditions and ignore the sexual and religiously offensive media for the time. ... And this solution would fix this by making Wikipedia a safer and more inclusive without censoring anything, which is the essential goal.
I think part of the reason why no consensus was ever reached on this issue is that the editors in favour of image filtering do not acknowledge that it inherently involves an infringement on intellectual freedom, and so don't put forward a framework for how to minimize the infringement. The approach can't be "Let's just create the functionality now and then worry later about what to do when a vocal minority of editors want to be able to hide all depictions of people with disabilities, or of LGBTQ+ people, because they find those images distressing." Those considerations need to be the starting point. I don't support image filtering, but when the discussion was held back in 2011 I did put foward a framework of seven principles for approaching it from this angle.--Trystan (talk) 17:05, 1 December 2024 (UTC)infringement on intellectual freedom
- Why do you guys want to go so technical and get things so complicated when the situation isn't at all complicated? Ppl dislike seeing gore, let them choose not to? Just like that, easy peasy. ☆SuperNinja2☆ TALK! 21:15, 1 December 2024 (UTC)
- Who defines what is "gore"? There's probably only a few types of images that we universally can say are problematic to a near majority of the world population (eg when you start to get into child exploitation), but beyond that, there's no way to tell when such an image would be considered bad by a majority of the readership. Masem (t) 21:18, 1 December 2024 (UTC)
- So you're basically presuming that this discussion is destined for failure because ppl have different povs on the topic? That's not a good enough argument. When did the community ever have similar povs on anything for that matter? ☆SuperNinja2☆ TALK! 02:10, 5 December 2024 (UTC)
- Don't want to see gore? Don't go to pages about gory things. Easy peasy.--User:Khajidha (talk) (contributions) 15:25, 2 December 2024 (UTC)
- Who defines what is "gore"? There's probably only a few types of images that we universally can say are problematic to a near majority of the world population (eg when you start to get into child exploitation), but beyond that, there's no way to tell when such an image would be considered bad by a majority of the readership. Masem (t) 21:18, 1 December 2024 (UTC)
- You've yet to show harm beyond you having a personal reaction to a picture that you didn't understand... an informative picture key to the article that I didn't even slightly flinch upon seeing. (If you have any records of Wikipedia images having provoked seizures, please put them forward.) Had you hidden it by collapsing, I might have assumed that there was something horrible that I wouldn't want to see and avoid getting that information. -- Nat Gertler (talk) 00:02, 1 December 2024 (UTC)
- That most certainly is censorship.--User:Khajidha (talk) (contributions) 21:20, 1 December 2024 (UTC)
- That type of suggestion is part of the perennial proposal on how to deal with such images. There's nothing that can be done to properly hide it. Masem (t) 22:05, 30 November 2024 (UTC)
any other image will also be as disturbing
that is what I'm arguing about. disturbing images should be collapsed at best. ☆SuperNinja2☆ TALK! 21:59, 30 November 2024 (UTC)- @Super ninja2, quite a lot of people agree with you, but a long time ago, this was formally proposed, and The Community™ rejected it. I have a lot of unhappy memories from that discussion, so you should not necessarily consider me to be an unbiased source {{(Redacted).
- The proposed approach was that a person should be able to say, in advance, that they personally don't want to see sexual images, disgusting medical images, violent images, or contested religious/cultural images, and have images tagged like that collapsed or screened somehow, with one click to reveal. The responses tended to cluster in two categories:
- Individuals should not have the freedom to control what they see, even if they are doing it for neutral reasons, like wanting to conserve bandwidth on a weak internet connection, or for safety reasons, like not wanting to risk an anxiety attack right now or not wanting to worry about the morality police looking over your shoulder at a public internet cafe. The Wikipedia editor has the right to put things on your computer screen, and your duty as a reader is to look at whatever disgusting, violent, or inappropriate image they want to shove in your face.
- It would be impossible to figure out which (few) images draw complaints. It might be impossible to do this with 100% accuracy, but we all know that the lead image at Smallpox draws complaints even though there's a FAQ at the top of the talk page to explain why it's there, every educated person knows that Depictions of Muhammad are both easily identifiable and considered inappropriate by some religious adherents, and most of us have encountered an animated gif that we'd like to cover up or turn off.
- I'm opposed to the first in principle and skeptical of the second. But that's the state of the discussion, and at this point, it will likely continue this way until multiple countries pass laws demanding that we change it. The Community™ has no empathy for people whose living situation is very different from their own. WhatamIdoing (talk) 00:10, 1 December 2024 (UTC)
- This context might help: Wikipedia was basically a spinoff from a now-defunct male-focused porn site. For years, every porn actress who was featured even once as a Playboy Playmate was automatically considered notable. If you infer from that fact something about the attitudes towards controversial content in the early days, I couldn't prove you wrong. WhatamIdoing (talk) 00:22, 1 December 2024 (UTC)
- Looking at the results on that page, it seems to say more people supported it than opposed it? Alpha3031 (t • c) 01:32, 1 December 2024 (UTC)
- There is one technically feasible solution I can come up with, although it may be complicated:
- Create a list of types of images that some will find offensive (anatomical parts typically not displayed in public, religiously offensive images, etc). Create a template to mark each type.
- Have the software mark these images, when used on other pages, in some way that scripts can use. Write scripts which individual users can self-apply to hide these images. Create a page with instructions for using these scripts, with a disclaimer that 100% results aren't guaranteed.
- These measures should be invisible to users not interested in them, except the tag on the image page. Animal lover |666| 10:59, 1 December 2024 (UTC)
- In some places a woman's hair is not typically displayed in public. Imagine if we had to hide every photo of a woman because her hair was visible, and we marked it with a template warning "Image of woman with visible hair". Valereee (talk) 18:59, 1 December 2024 (UTC)
- There is one technically feasible solution I can come up with, although it may be complicated:
not wanting to worry about the morality police looking over your shoulder at a public internet cafe.
- If you live in Saudi Arabia, Iran, or even less religious countries like Jordan, Morocco, or Egypt, and you were reading an article in a public place when a sexual photo deemed inappropriate popped up on your screen, you could literally be jailed! ☆SuperNinja2☆ TALK! 13:05, 1 December 2024 (UTC)
- And imagine if that photo was a depiction of Muhammad, then jail would be mercy. ☆SuperNinja2☆ TALK! 13:09, 1 December 2024 (UTC)
- Those might be valid points if these pictures were just inserted willy-nilly into any old page. But, for example, there is no reason NOT to expect an image of Muhammad on the Muhammad page (at least if you know that the site is not made entirely by Muslims). Articles about something having pictures of that something is not something you should be surprised by. Don't want people seeing what you are looking at? Don't do it in public. This is not hard.--User:Khajidha (talk) (contributions) 12:30, 2 December 2024 (UTC)
- Actually, these pictures (and pictures that haven't been tagged for censoring yet) can be inserted willy-nilly into any old page by vandals. We do try to catch and revert such edits, but there is no guarantee that articles will not contain completely inappropriate images (or text, or ASCII art). If something important like your freedom or livelihood depends on not looking at inappropriate content on Wikipedia in public, you should not look at any content on Wikipedia in public. —Kusma (talk) 20:18, 2 December 2024 (UTC)
- Those might be valid points if these pictures were just inserted willy-nilly into any old page. But, for example, there is no reason NOT to expect an image of Muhammad on the Muhammad page (at least if you know that the site is not made entirely by Muslims). Articles about something having pictures of that something is not something you should be surprised by. Don't want people seeing what you are looking at? Don't do it in public. This is not hard.--User:Khajidha (talk) (contributions) 12:30, 2 December 2024 (UTC)
- And imagine if that photo was a depiction of Muhammad, then jail would be mercy. ☆SuperNinja2☆ TALK! 13:09, 1 December 2024 (UTC)
- what a terribly sexist and racist comment, full of prejudiced assumptions about who might disagree with you. Fram (talk) 14:19, 1 December 2024 (UTC)
- Individuals already have control of what they see. They chose to come here. How can anyone seriously expect not to see images of such things in articles about these things? That's simply ridiculous.--User:Khajidha (talk) (contributions) 21:24, 1 December 2024 (UTC)
- we can use a collapsible template, then that won't be censoring. ☆SuperNinja2☆ TALK! 21:55, 30 November 2024 (UTC)
- See our Wikipedia:Content disclaimer. This isn't likely to be changed because you found an image that you objected too. There are ways for you to implement ways to not see images you don't want too, see WP:NOSEE. Specifically the section about the userscript that blocks all images unless you click to see them. Lee Vilenski (talk • contribs) 13:25, 1 December 2024 (UTC)
- no need to change the Content disclaimer because we will still display the offensive images but this time, the reader will choose to view them. ☆SuperNinja2☆ TALK! 14:04, 1 December 2024 (UTC)
- No, I'm not suggesting we change it. I'm suggesting that you read it and realise we aren't going to hide suitable images. Lee Vilenski (talk • contribs) 15:49, 1 December 2024 (UTC)
- no need to change the Content disclaimer because we will still display the offensive images but this time, the reader will choose to view them. ☆SuperNinja2☆ TALK! 14:04, 1 December 2024 (UTC)
- Let's not forget that WP:NOTCENSORED is a policy. - Ratnahastin (talk) 05:56, 2 December 2024 (UTC)
- The good of hiding disturbing or upsetting information, including images (which is real, and appropriate in many contexts) is completely incompatible with the good of presenting information in an educational and encyclopedic context, which is what we are doing on Wikipedia. Strongly oppose even a collapsible option or anything like it. ꧁Zanahary꧂ 19:32, 2 December 2024 (UTC)
- Blurring or collapsing that can be toggled off with a single click does not constitute censorship. Censorship would be only if images were removed or the users were somehow restricted from seeing them, e.g. by first forcing them to disclose their age or location. Giving everyone, including unregistered users, a reasonable default option to avoid inadvertently seeing explicit images is just a convenience feature in the user interface. This just follows from the principle of least astonishment, as most people expect to be warned before seeing sensitive content, and are used to that on other websites.
- Making Wikipedia more convenient for a large number of users is not equivalent to being forced to adhere to culturally contingent moral prohibitions. There is quite a distance between these two positions. NicolausPrime (talk) 02:38, 3 December 2024 (UTC)
- The reasonable default on an encyclopedia is that information is conveyed, not curtained. I’d counter your least astonishment argument with the fact that nobody is used to being warned about sensitive content in an encyclopedia. ꧁Zanahary꧂ 05:42, 3 December 2024 (UTC)
Very strong oppose on this one. Putting together a censor board to decide what is, could be, and/or is not offensive to whoever across the globe is a terrible idea, a waste of time, and does not help the site. WP:CENSOR is a crucial ingredient in Wikipedia's ability to cover everything under the sun. :bloodofox: (talk) 21:01, 1 December 2024 (UTC)
Oppose. Hurt feelings and thin skin are not a Wikipedia problem. Zaathras (talk) 04:27, 2 December 2024 (UTC)
- I recall encountering discussions about three photos on Wikipedia: profile photo of the pregnant Lina Medina, napalm girl, and Robert Peary's sunbathing inuit girlfriend Aleqasina. I believe that the napalm girl is the only one currently visible on Wikipedia. So WP:NOTCENSORED may be the stated policy, but doesn't sound like we're following it. Fabrickator (talk) 08:43, 2 December 2024 (UTC)
- There are other reasons a photo might be deleted. It could be under copyright, for instance. Valereee (talk) 13:33, 2 December 2024 (UTC)
- (replacing my erroneously entered response)
- The initial objection to the Aleqasina image was that it was "overtly exploitative pornography". This was objected to as a basis for removing the image. In response, someone removed the image on the basis that it was "a poor quality image compared to the other photos in the article." Fabrickator (talk) 16:40, 2 December 2024 (UTC)
- Is the photo at Commons, though? If not, it's possible the photo was removed from an article for that reason, but hasn't been put back under NOTCENSORED because it's not in the public domain. All of these photos could be less than 95 years old. Valereee (talk) 16:44, 2 December 2024 (UTC)
- FWIW, the photo in question is from 1896. Here is the applicable "fair use" notice:
Photo is available at commons:File:Mother of the seals.jpg. Fabrickator (talk) 18:07, 2 December 2024 (UTC)This media file is in the public domain in the United States. This applies to U.S. works where the copyright has expired, often because its first publication occurred prior to January 1, 1929, and if not then due to lack of notice or renewal.
- It's used on ruwiki. The discussion started out as a complaint from inexperienced editors that the photo was offensive, but that doesn't really seem to be what editors there removed it for. They didn't remove it because she's naked. It definitely is a low quality photo, even for the period. It definitely is a fair point that it doesn't add to the reader's understanding of Peary. I'm not sure this is censorship. To me it looks like someone complained it was offensive, other editors said "Why is this image in this article?", and there was discussion of whether removal constituted censorship. I think it could probably be included in Photos by Robert Peary or something. Valereee (talk) 19:09, 2 December 2024 (UTC)
- FWIW, the photo in question is from 1896. Here is the applicable "fair use" notice:
- If an image is not of real educational or encyclopedic value, then it being gratuitous pornography is a fine reason to exclude it. That is not censorship. ꧁Zanahary꧂ 19:35, 2 December 2024 (UTC)
- Is the photo at Commons, though? If not, it's possible the photo was removed from an article for that reason, but hasn't been put back under NOTCENSORED because it's not in the public domain. All of these photos could be less than 95 years old. Valereee (talk) 16:44, 2 December 2024 (UTC)
- Nothing against pictures of gore. But could we avoid seeing any images of this guy, who many people find very offensive? Martinevans123 (talk) 15:34, 2 December 2024 (UTC)
- I certainly understand that the person's opinions and actions are offensive, but is a mere picture of him that bad? Animal lover |666| 16:24, 2 December 2024 (UTC)
- The words "deeply disturbing, traumatizing, triggering, shocking, and sickening" spring to mind. But never mind. Martinevans123 (talk) 16:26, 2 December 2024 (UTC)
- Is a mere picture of a woman's (you name the body part, someone somewhere finds it offensive) that bad? Valereee (talk) 16:46, 2 December 2024 (UTC)
- I would not be opposed to an opt-in only tool or preferences setting or whatever that allows users to avoid seeing certain types of imagery. Would have to be entirely voluntary. I would imagine something that works by looking at an images categories could do it. Just Step Sideways from this world ..... today 20:44, 2 December 2024 (UTC)
- Is WP:NOSEE not enough? Valereee (talk) 20:50, 2 December 2024 (UTC)
- NOSEE, for all its value, requires the user (who may well be just a Wikipedia reader, not an editor) to install a script, a process that I suspect seems daunts some of those who are not tech-comfortable, if they even know that system exists. A "require-clicking-to-view-any-image" user option that can be turned on with just a switch would serve not just those who may be concerned about being offended or disturbed by an image, but also those for whom bandwidth may be limited or expensive, and it would be in the place where a user is likely to look for such a control.... but a "don't show offensive images" option would require a huge overhead of effort on the part of the editing base, to mark the existing images, to mark every new image, and to deal with the inevitable disagreements about which images should be marked. -- Nat Gertler (talk) 23:28, 2 December 2024 (UTC)
- Our license allows anyone to reuse our content and to filter images in any way they like. I expect that if there truly is a need for a Wikipedia version with certain censorship applied, someone will write a (possibly AI-powered) tool to deliver it. But I don't see hiding relevant information as something that could ever be part of Wikipedia's (or even Wikimedia's) mission. —Kusma (talk) 21:34, 2 December 2024 (UTC)
- Something like 17 years ago there was a child-friendly clone of WP that I made available on the computers at the elementary school where I worked. I don't know if there is anything like that around now. Donald Albury 21:55, 2 December 2024 (UTC)
- Imagine the process involved in marking content as offensive or falling within certain categories. What is sacrilegious? What is pornographic? What is violent? What is disgusting? And why is it Wikipedia’s problem? ꧁Zanahary꧂ 23:00, 2 December 2024 (UTC)
- All of this was said more than a decade ago. I see nothing in this discussion that wasn't put forward by the opponents back then, from "NOTCENSORED gives me the right to force you see to see things you'd like to opt out of" to "whatabout this" to "we should prevent people from volunteering to do the necessary work". Apparently we haven't changed a bit. I am not really surprised. WhatamIdoing (talk) 23:26, 2 December 2024 (UTC)
"NOTCENSORED gives me the right to force you see to see things you'd like to opt out of"
-- I'm sorry, I can't find that quote in this discussion. If someone is actually putting forward that we should force people to look at Wikipedia, that's an editor we should be concerned about. -- Nat Gertler (talk) 23:33, 2 December 2024 (UTC)- So over a decade ago, this idea was rejected, and today people still reject it on the same basis. I’m not seeing the problem. ꧁Zanahary꧂ 01:08, 3 December 2024 (UTC)
- Nobody is forcing you to look at anything. You are the one who chose to visit this site. --User:Khajidha (talk) (contributions) 13:44, 3 December 2024 (UTC)
What is sacrilegious? What is pornographic? What is violent? What is disgusting?
Anything that would be considered WP:GRATUITOUS outside of encyclopedic use on Wikipedia. As evidenced by that content guideline, Wikipedia has been already using a notion of what content may be explicit for over a decade. Wikipedia also has been able to use its consensus processes to decide many other contentious and often outright controversial matters, such as WP:NPOV and WP:TITLE.And why is it Wikipedia’s problem?
It is Wikipedia's problem because a considerable portion of its readers expects this, as evidenced by this matter being discussed perennially. NicolausPrime (talk) 06:52, 3 December 2024 (UTC)- Unencyclopedic content shouldn’t be on Wikipedia to begin with. Offensive encyclopedic content should. Good luck with identifying the encyclopedic content that will and won’t offend anybody. ꧁Zanahary꧂ 08:48, 3 December 2024 (UTC)
It is Wikipedia's problem because a considerable portion of its readers expects this, as evidenced by this matter being discussed perennially.
Faced with the perennial problem of some users demanding warning labels on content they view as offensive, the collective response of the library profession over several decades has been to strongly oppose such systems due to the inherent infringement on intellectual freedom. From the American Library Association:Labeling as an attempt to prejudice attitudes is a censor’s tool.
There is an inherent non-neutralality in identifying groups of images that users may want to avoid. The image that started this discussion is a good example of that. It was mistakenly thought to be a dead body, but is in fact a person suffering from a disease. Identifying the appropriate categories to be warned against, and which images merit those warnings, is an exercise incompatible with free and open access to information.--Trystan (talk) 15:28, 3 December 2024 (UTC)- Sure. But contrast that with library selection policies (hmm, missing article – @The Interior, could I tempt you to write an article?) and collection development work. Libraries oppose putting labels like "this is an immoral book" on collection items. They've got no problem with putting an objective label like "pornography" on a collection item, nor any problem with deciding that they won't stock porn at all. WhatamIdoing (talk) 01:14, 4 December 2024 (UTC)
- With the vast arguments over whether, say, Gender Queer is pornography, it's hard to see it as objective. It's pretty much the Potter Stewart standard. -- Nat Gertler (talk) 01:58, 4 December 2024 (UTC)
- If a "pornography" label is a viewpoint-neutral directional aid intended to help interested users locate the resource, that would be valid. But not if it is intended to warn users away from the content:
7. Is it prejudicial to describe violent and sexual content? For example, would including "contains mild violence" on bibliographic record of a graphic novel violate the Library Bill of Rights? Yes, in any community, there will be a range of attitudes as to what is deemed offensive and contrary to moral values. Potential issues could be sexually explicit content, violence, and/or language. Including notes in the bibliographic record regarding what may be objectionable content assumes all members of the community hold the same values. No one person should take responsibility for judging what is offensive. Such voluntary labeling in bibliographic records and catalogs violates the Library Bill of Rights.
[5]--Trystan (talk) 02:04, 4 December 2024 (UTC)
- Sure. But contrast that with library selection policies (hmm, missing article – @The Interior, could I tempt you to write an article?) and collection development work. Libraries oppose putting labels like "this is an immoral book" on collection items. They've got no problem with putting an objective label like "pornography" on a collection item, nor any problem with deciding that they won't stock porn at all. WhatamIdoing (talk) 01:14, 4 December 2024 (UTC)
What is sacrilegious? What is pornographic? What is violent? What is disgusting? And why is it Wikipedia’s problem?
- Consensus would answer these questions.
- This is the main purpose of this discussion.
- ☆SuperNinja2☆ TALK! 04:01, 4 December 2024 (UTC)
- Just for logistical considerations, how many images are we talking about, and therefore how many consensus discussions, and how often could someone reopen to see if consensus had changed? I feel like there are a huge number of images that might upset someone, but very few that could get consensus for being hidden. Risus sardonicus averages 250+ views a day. The chance that image could ever gain consensus to be hidden is...well, in my mind, unlikely. But if even 1 in 100,000 people are freaked out enough and knowledgeable enough to start a discussion, we could be confirming that once a year via discussion at the talk. Valereee (talk) 13:26, 4 December 2024 (UTC)
- All of this was said more than a decade ago. I see nothing in this discussion that wasn't put forward by the opponents back then, from "NOTCENSORED gives me the right to force you see to see things you'd like to opt out of" to "whatabout this" to "we should prevent people from volunteering to do the necessary work". Apparently we haven't changed a bit. I am not really surprised. WhatamIdoing (talk) 23:26, 2 December 2024 (UTC)
I would imagine something that works by looking at an images categories could do it.
Subject categories serve a different function than warning labels, and the two functions are not compatible. A subject category about nudity should tag those images where nudity is central to the subject of the image (where it is defining), while a warning label would tag every single image containing any nudity, however trivial. Implementing image filtering that uses subject categories would distort the former into the latter. It would need to be a separate system. I agree with NatGertler above; it would be fine to introduce user-friendly functionality that hides all photos and lets user click to view based on the alt text. But flagging all images that someone, somewhere would object to is not a viable project.--Trystan (talk) 00:33, 3 December 2024 (UTC)- I’m reminded of the deleted Zionist symbol template on Commons, which was slapped all over images of Jewish stars in any context, including a chanukiah and some blue sugar cookies—which, no doubt, would be offensive images to some. ꧁Zanahary꧂ 00:57, 3 December 2024 (UTC)
- And the similar commons:Template:Chinese sensitive content. Simply: it becomes obvious that Wikipedia should not be working around people’s sensitivities as soon as you consider a common sensitivity that you consider silly or repressive. ꧁Zanahary꧂ 01:06, 3 December 2024 (UTC)
- This kind of "whataboutism" was addressed in the original report and recommendations. WhatamIdoing (talk) 01:53, 3 December 2024 (UTC)
- I recommend you try and imagine a position besides yours that isn’t fallacious or the result of an intellectual failure. Your approach is not a good one from the losing side of a debate. ꧁Zanahary꧂ 05:39, 3 December 2024 (UTC)
- This kind of "whataboutism" was addressed in the original report and recommendations. WhatamIdoing (talk) 01:53, 3 December 2024 (UTC)
- And the similar commons:Template:Chinese sensitive content. Simply: it becomes obvious that Wikipedia should not be working around people’s sensitivities as soon as you consider a common sensitivity that you consider silly or repressive. ꧁Zanahary꧂ 01:06, 3 December 2024 (UTC)
- I’m reminded of the deleted Zionist symbol template on Commons, which was slapped all over images of Jewish stars in any context, including a chanukiah and some blue sugar cookies—which, no doubt, would be offensive images to some. ꧁Zanahary꧂ 00:57, 3 December 2024 (UTC)
- I'd be happy to have a default turn on/turn off all images mode in preferences. But anything that requires judgement or consensus for which images or category of images? I'd object. Valereee (talk) 15:36, 3 December 2024 (UTC)
- Is WP:NOSEE not enough? Valereee (talk) 20:50, 2 December 2024 (UTC)
- I would not be opposed to an opt-in only tool or preferences setting or whatever that allows users to avoid seeing certain types of imagery. Would have to be entirely voluntary. I would imagine something that works by looking at an images categories could do it. Just Step Sideways from this world ..... today 20:44, 2 December 2024 (UTC)
- I certainly understand that the person's opinions and actions are offensive, but is a mere picture of him that bad? Animal lover |666| 16:24, 2 December 2024 (UTC)
- Agreed. Same with Sanctioned Suicide online forum. They removed its URL. ☆SuperNinja2☆ TALK! 02:19, 5 December 2024 (UTC)
- There are other reasons a photo might be deleted. It could be under copyright, for instance. Valereee (talk) 13:33, 2 December 2024 (UTC)
- I recall encountering discussions about three photos on Wikipedia: profile photo of the pregnant Lina Medina, napalm girl, and Robert Peary's sunbathing inuit girlfriend Aleqasina. I believe that the napalm girl is the only one currently visible on Wikipedia. So WP:NOTCENSORED may be the stated policy, but doesn't sound like we're following it. Fabrickator (talk) 08:43, 2 December 2024 (UTC)
- The simple answer: no. Long answer: The addition of a function to turn off images by default is a great idea that’s seemingly never been implemented despite its harmlessness and relative popularity, and is best taken up at some more technical-oriented forum. But we are never hiding/censoring graphic images if they serve a legitimate purpose. True, I don’t support graphic full color images of goatse on the Goatse.cx article per the Wikipedia:Principle of least astonishment and Wikipedia:GRATUITOUS, but the grey area here is very big and very grey. I’m not talking about the strawman arguments about “what if Dictator McTyrant in Dictatorstan bans pictures of goats” or something; here are some examples of things that could legitimately be considered objectionable to certain persons in a liberal Western society:
- Images or voices of deceased indigenous Australians
- Spiders
- Flashing/strobing lights
- Blackface imagery
But are we not allowed to illustrate Indigenous Australians, Spiders, Dennō Senshi Porygon, or Blackface then? Do we need warnings for these things? Do we need warnings for articles that simply discuss distressing content? These are actual, plausible issues people actually have had to address on other, equally serious platforms. But it’s literally impossible to address every conceivable issue, so Wikipedia’s longstanding policy is to simply address none of them (besides the bare minimum examples provided above). Dronebogus (talk) 03:52, 4 December 2024 (UTC)
But are we not allowed to illustrate Indigenous Australians, Spiders, Dennō Senshi Porygon, or Blackface then
- It’s up to the community to decide, and we’re all here to discuss this. What’s clear, however, is that we need to establish minimum criteria to guide us on what should be collapsed. We must draw a line to distinguish what can and cannot be collapsed.
- This isn’t a case where passing the proposal will lead to chaos and censorship, with everyone hiding images indiscriminately. We’ll be here to make the necessary adjustments and ensure it fits the community’s needs. That’s why we are here having this discussion, right? The proposal isn’t a rigid, unchangeable set of rules—it’s flexible and can adapt. Ultimately, consensus will determine what is acceptable enough to remain visible and what warrants collapsing. ☆SuperNinja2☆ TALK! 04:24, 4 December 2024 (UTC)
- You are completely missing my point. My line is not your line. Your line is not anybody else’s line. Your starting example doesn’t even come close to my, or really most people’s, lines. So you’re never going to establish a global minimum criterion here. And we shouldn’t allow people to establish local case-by-case criteria either— not only is that balkanization, it’s not going to get you what you want (medical editors have strong stomachs) Dronebogus (talk) 04:40, 4 December 2024 (UTC)
Your starting example doesn’t even come close to my, or really most people’s, lines.
What example?I never said that the "example" should be taken as a universal standard for deciding what should be collapsed. You don’t have to agree with me—or anyone else—for the proposal to work. Even if the majority decided that the "example" should not be collapsed, the process would still function. That's why discussions exist: to bring people with differing opinions together, negotiate and compromise, and form a rough consensus by analyzing what most people from both sides agree upon.- In any case, I mentioned that we would discuss what should be collapsed, and doctors and medical editors are welcome to share their perspectives like everyone else. I don’t understand your objection. ☆SuperNinja2☆ TALK! 07:53, 4 December 2024 (UTC)
- All I see here is you getting disturbed by a very particular image, wanting it collapsed, and then slowly backtracking to “well I actually just want this generally”. Basically the answer is still no. Dronebogus (talk) 17:53, 4 December 2024 (UTC)
- What is "this"? Anyways, you took it personally as it seems. And you just don't want to discuss the proposal, you're just complaining. ☆SuperNinja2☆ TALK! 02:27, 5 December 2024 (UTC)
- All I see here is you getting disturbed by a very particular image, wanting it collapsed, and then slowly backtracking to “well I actually just want this generally”. Basically the answer is still no. Dronebogus (talk) 17:53, 4 December 2024 (UTC)
My line is not your line. Your line is not anybody else’s line.
- I didn't even define the line. And I didn't say that the line has to agree with me. I only said "can we hide sensitive images?" we are supposed to draw that line together if the answer was yes. ☆SuperNinja2☆ TALK! 02:32, 5 December 2024 (UTC)
- Your line is, at least, defined at medical photos in which subjects appear to be deceased. ꧁Zanahary꧂ 04:08, 5 December 2024 (UTC)
- You are completely missing my point. My line is not your line. Your line is not anybody else’s line. Your starting example doesn’t even come close to my, or really most people’s, lines. So you’re never going to establish a global minimum criterion here. And we shouldn’t allow people to establish local case-by-case criteria either— not only is that balkanization, it’s not going to get you what you want (medical editors have strong stomachs) Dronebogus (talk) 04:40, 4 December 2024 (UTC)
True, I don’t support graphic full color images of goatse on the Goatse.cx article per the Wikipedia:Principle of least astonishment and Wikipedia:GRATUITOUS
.- Goatse.cx is a good example where Wikipedia's policies fall short on this matter. The Goatse shock image is encyclopedically relevant in that article, so WP:GRATUITOUS doesn't apply. WP:ASTONISH also doesn't seem convincing for preventing its inclusion, given that Wikipedia does include explicit content like defecation or feces in other appropriate articles, whereas there is also a fair number of users may expect that shock image to be there anyway, so not including it at all may be in fact against WP:ASTONISH.
- If you look at the closing rationale for the ultimate deletion of this image, it is stated there that the only accepted reason why it was deleted was because it had unsuitable copyright status. [6] So were the Goatse shock image licensed under a free license, there would be no basis in policy to keep it out of its article's reader sight.
- NicolausPrime (talk) 04:39, 4 December 2024 (UTC)
- I don’t really get how a picture of a man stretching his anus is really necessary to understand the concept of a shock site depicting a man stretching his anus. I’d say it is gratuitous because it doesn’t improve the viewer’s understanding. A better example I guess would be something like Coprophilia which has no graphic full-color photographs (or even graphically explicit illustrations) of people… engaging in it because it would not improve understanding of the topic and would just disgust 99% of the population. Dronebogus (talk) 04:45, 4 December 2024 (UTC)
- Seeing what the famous shock image really looked like very much increases the person's understanding of the subject. Words can convey only small parts of audiovisual content. And generally, showing the image in an article about it is helpful for people who may recognize it but not remember its name. For example, in the Lenna article I wouldn't have realized that I know this image if it wasn't shown there. NicolausPrime (talk) 05:03, 4 December 2024 (UTC)
- I agree. It should be added! ꧁Zanahary꧂ 08:33, 4 December 2024 (UTC)
- I think this is getting off topic. If you really need to see Kirk Johnson’s butthole then you should take that up at the article. This is just starting to remind me of the “I’m a visual learner” meme. Dronebogus (talk) 17:58, 4 December 2024 (UTC)
- I agree. It should be added! ꧁Zanahary꧂ 08:33, 4 December 2024 (UTC)
- Seeing what the famous shock image really looked like very much increases the person's understanding of the subject. Words can convey only small parts of audiovisual content. And generally, showing the image in an article about it is helpful for people who may recognize it but not remember its name. For example, in the Lenna article I wouldn't have realized that I know this image if it wasn't shown there. NicolausPrime (talk) 05:03, 4 December 2024 (UTC)
- Another example: Nudity has relatively few explicit images despite the subject (most of them would be considered PG-13 by American standards) because it’s mostly discussing the societal context of nudity. There are more explicit anatomical photographs on anatomy pages because those discuss biological aspects of humans that cannot be illustrated without showing the entire unclothed body. Dronebogus (talk) 04:51, 4 December 2024 (UTC)
- I don’t really get how a picture of a man stretching his anus is really necessary to understand the concept of a shock site depicting a man stretching his anus. I’d say it is gratuitous because it doesn’t improve the viewer’s understanding. A better example I guess would be something like Coprophilia which has no graphic full-color photographs (or even graphically explicit illustrations) of people… engaging in it because it would not improve understanding of the topic and would just disgust 99% of the population. Dronebogus (talk) 04:45, 4 December 2024 (UTC)
Videos from YT and WP:RSPYT
Hi there, I've been adding some original, subtitled Latin content to some pages, from a series of readings which are available as CC-By content now at here, here and here. The content is verifiable and properly sourced. Where the readings are sufficiently significant to the topic, this seems a reasonable thing to do, eg at Martin Luther. It is also more in line with MOS:FOREIGNQUOTE to subtitle the original than to read from a translation. If an editor feels the content is not sufficiently relevant, that is fair enough of course.
However, it has been raised that WP:RSPYT applies and the videos are simply not to be used as WP:RSPYT states that YT is simply unreliable as a "source". I don't think this is right but wanted to get some clarity. Jim Killock (talk) 18:57, 1 December 2024 (UTC)
- I think the wording of WP:RSPYT is poor - YouTube is a publisher, not a source, and so is neither reliable nor unreliable. While most videos hosted on it are unreliable and/or copyright violations (for various reasons), there are exceptions and there should not be any prohibition on citing those exceptions. The onus is on the person wanting to cite them to show they are reliable and not copyright violations, as well as the usual DUE, etc. but once shown to be acceptable and relevant there is no reason not to cite such videos imo (unless of course there are better sources of course). Thryduulf (talk) 19:13, 1 December 2024 (UTC)
- "use" as well as "cite" perhaps, in these instances? Jim Killock (talk) 19:21, 1 December 2024 (UTC)
- With YouTube videos, even those released by a free license, we want to make sure of a few things. First, that the account that posted the material themselves are a reliable source. To take the first image in the first link provided, File:Dr. Samuel Johnson- Letter of Thanks for His Oxford Degree.webm, the YouTube it was pulled from appears to be no-name with zero evidence of any reliability on their own (they claim to be an independent student of Latin and Greek). While the content may be accurate, we shouldn't be using that questionable reliability for such sources. Another problem, but which is not the case here, is that there are people that create CC-BY videos on YouTube that include considerable amount of copyrighted material (that is not in there control), beyond what fair use would allow, and thus belie the CC-BY allowance. YouTube itself doesn't check this, so we have to aware of such problems. Masem (t) 21:29, 1 December 2024 (UTC)
- That all makes sense. But I would assume that it is OK so long as the checks can be made? The author of these videos is pseudonymous but give sources. In the case you mention, he cites the public domain Life of Johnson by James Boswell for the text; a search for "ingratus plane et mihi videar" turns up page 75 of this edition, in Latin and English, so the content is easy enough to check.
- I have sufficient Latin to know that his pronunciation and diction is decent, and to check the sources linked to match up with what is said. I'm also able to translate most of the simpler texts from Latin to English where needed. Jim Killock (talk) 00:07, 2 December 2024 (UTC)
- It doesn't matter if the YouTube source is accurate or that it cites other sources; if it is not from an established RS outlet it is no more reliable than a forums post. JoelleJay (talk) 03:02, 2 December 2024 (UTC)
- Unless it clearly cites its sources, is published by an established expert in the field, or a few other scenarios - i.e. exactly the same as a text source. Thryduulf (talk) 03:05, 2 December 2024 (UTC)
- ...yes,
an established RS outlet
. JoelleJay (talk) 03:08, 2 December 2024 (UTC)- ...and sources that are reliable but not established and/or which are not "outlets". Thryduulf (talk) 03:13, 2 December 2024 (UTC)
- Either a source is the account of an official outlet with a formal editorial policy that establishes it as RS, or it's an SPS from an established expert. If you need to replace "outlet" with "verified official account of an established expert" you can do that. JoelleJay (talk) 03:23, 2 December 2024 (UTC)
- To be clear I am asking about a very simple scenario here. The Johnson video foe example follows this script:
'INGRATUS planè et tibi et mihi videar, nisi quanto me gaudio affecerint quos nuper mihi honores (te credo auctore) decrevit Senatus Academicus, Iiterarum, quo lamen nihil levius, officio, significem: ingratus etiam, nisi comitatem, quá vir eximius[831] mihi vestri testimonium amoris in manus tradidit, agnoscam et laudem. Si quid est undè rei lam gratæ accedat gratia, hoc ipso magis mihi placet, quod eo tempore in ordines Academicos denuo cooptatus sim, quo tuam imminuere auctoritatem, famamque Oxonii Iædere[832], omnibus modis conantur homines vafri, nec tamen aculi: quibus ego, prout viro umbratico licuit, semper restiti, semper restiturus. Qui enim, inter has rerum procellas, vel Tibi vel Academiæ defuerit, illum virtuti et literis, sibique et posteris, defuturum existimo.
- The script matches the Project Gutenberg transcript of the source it cites. Google translate gives a passable translation that roughly matches the English subtitles.
- There might be a question about the translation of the English subtitles, if the text is more complicated. In these, the author has generally gone with a public domain translation, which is also easily verified. Occassionally they are his own work, which obviously does need checking according to context and complexity.
- Assuming the subs and original source are public domain; and the relevance of the original source can be established from secondary sources, then I'm struggling to see why there would be a problem using this content. Jim Killock (talk) 08:46, 2 December 2024 (UTC)
- Because (in general) the only thing a video of a reading adds over the script is aural. And given Latin is a dead language I would want to see someone who has qualifications in the area reading it (I would at minimum accept a catholic priest here FYI). Because YT is self-published I have no idea if the person reading it is competent. I cant even verify from the audio if it matches the script because I dont speak latin to start with. It absolutely would be suitable for an External Link, but there's nothing you can source content from it. Only in death does duty end (talk) 10:31, 4 December 2024 (UTC)
- There are plenty of competent Latinists, judged competent by trained Latinists. WP has plenty of trained Latinists. Not everyone can judge everything against sources; not all of us can access all sources or other people's abilities to recite another language; the same would apply to Welsh or Gaelic for example, in that I personally cannot evaluate a spoken Gaelic source or translation. Wikipedia depends on a network of people evaluating sources; that is inherent in WP's work AIUI. Jim Killock (talk) 13:09, 4 December 2024 (UTC)
- Because (in general) the only thing a video of a reading adds over the script is aural. And given Latin is a dead language I would want to see someone who has qualifications in the area reading it (I would at minimum accept a catholic priest here FYI). Because YT is self-published I have no idea if the person reading it is competent. I cant even verify from the audio if it matches the script because I dont speak latin to start with. It absolutely would be suitable for an External Link, but there's nothing you can source content from it. Only in death does duty end (talk) 10:31, 4 December 2024 (UTC)
- Either a source is the account of an official outlet with a formal editorial policy that establishes it as RS, or it's an SPS from an established expert. If you need to replace "outlet" with "verified official account of an established expert" you can do that. JoelleJay (talk) 03:23, 2 December 2024 (UTC)
- ...and sources that are reliable but not established and/or which are not "outlets". Thryduulf (talk) 03:13, 2 December 2024 (UTC)
- ...yes,
- Unless it clearly cites its sources, is published by an established expert in the field, or a few other scenarios - i.e. exactly the same as a text source. Thryduulf (talk) 03:05, 2 December 2024 (UTC)
- It doesn't matter if the YouTube source is accurate or that it cites other sources; if it is not from an established RS outlet it is no more reliable than a forums post. JoelleJay (talk) 03:02, 2 December 2024 (UTC)
- YouTube videos are self-published, YouTube myself just acts as a way to publish those videos. So they can be reliable is they from an otherwise reliable source, so if the Associated Press upload a video of their news coverage it would be as reliable as any other work by the Associated Press. For individuals they need to be subject matter experts who have been previous published by independent reliable sources (WP:SPS) or show they have been used as a citation by other independent reliable sources (WP:USEBYOTHERS). -- LCU ActivelyDisinterested «@» °∆t° 19:51, 2 December 2024 (UTC)
- Right, but my use case falls outside of this scenario. Say someone sings "Jack and Jill went up the Hill" and releases it under CC-By. They cite and link a public domain music sheet. They use an anonymous name and they are not a known subject expert. According to the criteria set out above, the video is an unreliable source, as it is not published by a subject matter expert, nor used as a citation by an independent reliable source, so must be disallowed (not republished) on Wikipedia.
- These videos are performances (recitals) not cited sources.
- I am confused. Jim Killock (talk) 20:30, 2 December 2024 (UTC)
- If it's being used for the purposes of verification then it's a reference, and must be from a reliable source. If it's only being used as an external link, rather than for verification, then it comes under WP:External links. -- LCU ActivelyDisinterested «@» °∆t° 21:19, 2 December 2024 (UTC)
- The intention is not that they are used for verification; they are performances for "illustrative purposes", rather like images on the page. See for example: this Martin Luther reading. The idea is that the reader can get an idea of the original source material. The performances may be verified; but the performances are not sources, they are derivative works. Jim Killock (talk) 22:32, 2 December 2024 (UTC)
- RSPYT only applies to verification, and this appears to be a matter of inclusion not verification. Whether a video made by an anonymous performer should be included or not is the same as if a particular image should be used. -- LCU ActivelyDisinterested «@» °∆t° 22:49, 2 December 2024 (UTC)
- Thanks very much; is there guidance on how and when appropriately licenced images are included? Jim Killock (talk) 22:53, 2 December 2024 (UTC)
- Answering my own question: MOS:IMAGES. I think there is a bit of lacuna in guidance here, as illsutative videos of performances or recordings etc don't seem to be covered in MOS, or if they are, I haven't found it. Jim Killock (talk) 22:58, 2 December 2024 (UTC)
- See also Wikipedia:External links/Perennial websites#YouTube and {{External media}}. If you don't wrap stuff in ref tags, people are less likely to think you are trying to use it to support article content. WhatamIdoing (talk) 23:31, 2 December 2024 (UTC)
- Thanks. None of this content was wrapped up in ref tags. Confusion may have arise because the challenge was made over the "verifiability" of the content; as the videos are derivative works of public domain sources, eg Luther's pamphlet, it's important that the video's sources are clear and checked, even though the video is not being used as a citation. Jim Killock (talk) 07:30, 3 December 2024 (UTC)
- See also Wikipedia:External links/Perennial websites#YouTube and {{External media}}. If you don't wrap stuff in ref tags, people are less likely to think you are trying to use it to support article content. WhatamIdoing (talk) 23:31, 2 December 2024 (UTC)
- Answering my own question: MOS:IMAGES. I think there is a bit of lacuna in guidance here, as illsutative videos of performances or recordings etc don't seem to be covered in MOS, or if they are, I haven't found it. Jim Killock (talk) 22:58, 2 December 2024 (UTC)
- Thanks very much; is there guidance on how and when appropriately licenced images are included? Jim Killock (talk) 22:53, 2 December 2024 (UTC)
- RSPYT only applies to verification, and this appears to be a matter of inclusion not verification. Whether a video made by an anonymous performer should be included or not is the same as if a particular image should be used. -- LCU ActivelyDisinterested «@» °∆t° 22:49, 2 December 2024 (UTC)
- The intention is not that they are used for verification; they are performances for "illustrative purposes", rather like images on the page. See for example: this Martin Luther reading. The idea is that the reader can get an idea of the original source material. The performances may be verified; but the performances are not sources, they are derivative works. Jim Killock (talk) 22:32, 2 December 2024 (UTC)
- If it's being used for the purposes of verification then it's a reference, and must be from a reliable source. If it's only being used as an external link, rather than for verification, then it comes under WP:External links. -- LCU ActivelyDisinterested «@» °∆t° 21:19, 2 December 2024 (UTC)
LLM/chatbot comments in discussions
|
Should admins or other users evaluating consensus in a discussion discount, ignore, or strike through or collapse comments found to have been generated by AI/LLM/Chatbots? 00:12, 2 December 2024 (UTC)
I've recently come across several users in AFD discussions that are using LLMs to generate their remarks there. As many of you are aware, gptzero and other such tools are very good at detecting this. I don't feel like any of us signed up for participating in discussions where some of the users are not using their own words but rather letting technology do it for them. Discussions are supposed to be between human editors. If you can't make a coherent argument on your own, you are not competent to be participating in the discussion. I would therefore propose that LLM-generated remarks in discussions should be discounted or ignored, and possibly removed in some manner. Just Step Sideways from this world ..... today 00:12, 2 December 2024 (UTC)
- Seems reasonable, as long as the GPTZero (or any tool) score is taken with a grain of salt. GPTZero can be as wrong as AI can be. ~ ToBeFree (talk) 00:32, 2 December 2024 (UTC)
- Only if the false positive and false negative rate of the tool you are using to detect LLM content is very close to zero. LLM detectors tend to be very unreliable on, among other things, text written by non-native speakers. Unless the tool is near perfect then it's just dismissing arguments based on who wrote them rather than their content, which is not what we do or should be doing around here. Thryduulf (talk) 00:55, 2 December 2024 (UTC)
- In the cases I have seen thusfar it's been pretty obvious, the tools have just confirmed it. Just Step Sideways from this world ..... today 04:08, 2 December 2024 (UTC)
- The more I read the comments from other editors on this, the more I'm a convinced that implementing either this policy or something like it will bring very significant downsides on multiple fronts that significantly outweigh the small benefits this would (unreliably) bring, benefits that would be achieved by simply reminding closers to disregard comments that are unintelligible, meaningless and/or irrelevant regardless of whether they are LLM-generated or not. For the sake of the project I must withdraw my previous very qualified support and instead very strongly oppose. Thryduulf (talk) 02:45, 3 December 2024 (UTC)
- I think it should be an expressly legitimate factor in considering whether to discount or ignore comments either if it's clear enough by the text or if the user clearly has a history of using LLMs. We wouldn't treat a comment an editor didn't actually write as an honest articulation of their views in lieu of site policy in any other situation. Remsense ‥ 论 00:59, 2 December 2024 (UTC)
- I would have already expected admins to exercise discretion in this regard, as text written by an LLM is not text written by a person. We cannot guarantee it is what the person actually means, especially as it is a tool often used by those with less English proficiency, which means perhaps they cannot evaluate the text themselves. However, I do not think we can make policy about a specific LLM or tool. The LLM space is moving fast, en.wiki policies do not. Removal seems tricky, I would prefer admins exercise discretion instead, as they do with potentially canvassed or socked !votes. CMD (talk) 01:06, 2 December 2024 (UTC)
- Support discounting or collapsing AI-generated comments, under slightly looser conditions than those for human comments. Not every apparently-AI-generated comment is useless hallucinated nonsense – beyond false positives, it's also possible for someone to use an AI to help them word a constructive comment, and make sure that it matches their intentions before they publish it. But in my experience, the majority of AI-generated comments are somewhere between "pointless" and "disruptive". Admins should already discount clearly insubstantial !votes, and collapse clearly unconstructive lengthy comments; I think we should recognize that blatant chatbot responses are more likely to fall into those categories. jlwoodwa (talk) 02:11, 2 December 2024 (UTC)
- Strongly Support - I think some level of human judgement on the merits of the argument are necessary, especially as GPTZero may still have a high FPR. Still, if the discussion is BLUDGEONy, or if it quacks like an AI-duck, looks like an AI-duck, etc, we should consider striking out such content.- sidenote, I'd also be in favor of sanctions against users who overuse AI to write out their arguments/articles/etc. and waste folks time on here.. Bluethricecreamman (talk) 02:20, 2 December 2024 (UTC)
- On a wording note, I think any guidance should avoid referring to any specific technology. I suggest saying "... to have been generated by a program". isaacl (talk) 02:54, 2 December 2024 (UTC)
- "generated by a program" is too broad, as that would include things like speech-to-text. Thryduulf (talk) 03:08, 2 December 2024 (UTC)
- Besides what Thryduulf said, I think we should engage with editors who use translators. Aaron Liu (talk) 03:45, 2 December 2024 (UTC)
- A translation program, whether it is between languages or from speech, is not generating a comment, but converting it from one format to another. A full policy statement can be more explicit in defining "generation". The point is that the underlying tech doesn't matter; it's that the comment didn't feature original thought from a human. isaacl (talk) 03:57, 2 December 2024 (UTC)
- Taking Google Translate as an example, most of the basic stuff uses "AI" in the sense of machine learning (example) but they absolutely use LLMs nowadays, even for the basic free product. Gnomingstuff (talk) 08:39, 2 December 2024 (UTC)
- A translation program, whether it is between languages or from speech, is not generating a comment, but converting it from one format to another. A full policy statement can be more explicit in defining "generation". The point is that the underlying tech doesn't matter; it's that the comment didn't feature original thought from a human. isaacl (talk) 03:57, 2 December 2024 (UTC)
- Support. We already use discretion in collapsing etc. comments by SPAs and suspected socks, it makes sense to use the same discretion for comments suspected of being generated by a non-human. JoelleJay (talk) 03:07, 2 December 2024 (UTC)
- Support - Someone posting "here's what ChatGPT has to say on the subject" can waste a lot of other editors' time if they feel obligated to explain why ChatGPT is wrong again. I'm not sure how to detect AI-written text but we should take a stance that it isn't sanctioned. Clayoquot (talk | contribs) 04:37, 2 December 2024 (UTC)
- Strong Support - I've never supported using generative AI in civil discourse. Using AI to participate in these discussions is pure laziness, as it is substituting genuine engagement and critical thought with a robot prone to outputting complete garbage. In my opinion, if you are too lazy to engage in the discussion yourself, why should we engage with you? Lazman321 (talk) 05:26, 2 December 2024 (UTC)
- Comment - I'm skeptical that a rule like this will be enforceable for much longer. Sean.hoyland (talk) 05:39, 2 December 2024 (UTC)
- Why? Aaron Liu (talk) 12:22, 2 December 2024 (UTC)
- Because it's based on a potentially false premise that it will be possible to reliably distinguish between text generated by human biological neural networks and text generated by non-biological neural networks by observing the text. It is already quite difficult in many cases, and the difficulty is increasing very rapidly. I have your basic primate brain. The AI companies building foundation models have billions of dollars, tens of thousands, soon to be hundreds of thousands of GPUs, a financial incentive to crack this problem and scaling laws on their side. So, I have very low credence in the notion that I will be able to tell whether content is generated by a person or a person+LLM or an AI agent very soon. On the plus side, it will probably still be easy to spot people making non-policy based arguments regardless of how they do it. Sean.hoyland (talk) 13:52, 2 December 2024 (UTC)
- ...and now that the systems are autonomously injecting their output back into model via chain-of-thought prompting, or a kind of inner monologue if you like, to respond to questions, they are becoming a little bit more like us. Sean.hoyland (talk) 14:14, 2 December 2024 (UTC)
- A transformer (deep learning architecture) is intrinsically nothing like a human. It's a bunch of algebra that can compute what a decently sensible person could write in a given situation based on its training data, but it is utterly incapable of anything that could be considered thought or reasoning. This is why LLMs tend to fail spectacularly when asked to do math or write non-trivial code. Flounder fillet (talk) 17:20, 2 December 2024 (UTC)
- We shall see. You might want to update yourself on their ability to do math and write non-trivial code. Things are changing very quickly. Either way, it is not currently possible to say much about what LLMs are actually doing because mechanistic interpretability is in its infancy. Sean.hoyland (talk) 03:44, 3 December 2024 (UTC)
- You might be interested in Anthropic's 'Mapping the Mind of a Large Language Model' and Chris Olah's work in general. Sean.hoyland (talk) 04:02, 3 December 2024 (UTC)
- A transformer (deep learning architecture) is intrinsically nothing like a human. It's a bunch of algebra that can compute what a decently sensible person could write in a given situation based on its training data, but it is utterly incapable of anything that could be considered thought or reasoning. This is why LLMs tend to fail spectacularly when asked to do math or write non-trivial code. Flounder fillet (talk) 17:20, 2 December 2024 (UTC)
- Why? Aaron Liu (talk) 12:22, 2 December 2024 (UTC)
- Support and I would add "or similar technologies" to "AI/LLM/Chatbots". As for Sean.hoyland's comment, we will cross that bridge when we get to it. Cullen328 (talk) 05:51, 2 December 2024 (UTC)
- ...assuming we can see the bridge and haven't already crossed it. Sean.hoyland (talk) 06:24, 2 December 2024 (UTC)
- Support - All editors should convey their thoughts in their own words. AI generated responses and comments are disruptive because they are pointless and not meaningful. - Ratnahastin (talk) 06:04, 2 December 2024 (UTC)
- Support, I already more or less do this. An LLM generated comment may or may not actually reflect the actual thoughts of the editor who posted it, so it's essentially worthless toward a determination of consensus. Since I wrote this comment myself, you know that it reflects my thoughts, not those of a bot that I may or may not have reviewed prior to copying and pasting. Seraphimblade Talk to me 06:59, 2 December 2024 (UTC)
- Strong oppose. Let me say first that I do not like ChatGPT. I think it has been a net negative for the world, and it is by nature a net negative for the physical environment. It is absolutely a net negative for the encyclopedia if LLM-generated text is used in articles in any capacity. However, hallucinations are less of an issue on talk pages because they're discussions. If ChatGPT spits out a citation of a false policy, then obviously that comment is useless. If ChatGPT spits out some boilerplate "Thanks for reviewing the article, I will review your suggestions and take them into account" talk page reply, who gives a fuck where it came from? (besides the guys in Texas getting their eardrums blown out because they live by the data center)The main reason I oppose, though, is because banning LLM-generated comments is difficult to enforce bordering on unenforceable. Most studies show that humans are bad at distinguishing AI-generated text from text generated without AI. Tools like GPTZero claims a 99% accuracy rate, but that seems dubious based on reporting on the matter. The news outlet Futurism (which generally has an anti-AI slant) has failed many times to replicate that statistic, and anecdotal accounts by teachers, etc. are rampant. So we can assume that we don't know how capable AI detectors are, that there will be some false positives, and that striking those false positives will result in WP:BITING people, probably newbies, younger people more accustomed to LLMs, and non-Western speakers of English (see below).There are also technological issues as play. It'd be easy if there was a clean line between "totally AI-generated text" and "totally human-generated text," but that line is smudged and well on its way to erased. Every tech company is shoving AI text wrangling into their products. This includes autocomplete, translation, editing apps, etc. Should we strike any comment a person used Grammarly or Google Translate for? Because those absolutely use AI now.And there are also, as mentioned above, cultural issues. The people using Grammarly, machine translation, or other such services are likely to not have English as their first language. And a lot of the supposed "tells" of AI-generated content originate in the formal English of other countries -- for instance, the whole thing where "delve" was supposedly a tell for AI-written content until people pointed out the fact that lots of Nigerian workers trained the LLM and "delve" is common Nigerian formal English.I didn't use ChatGPT to generate any of this comment. But I am also pretty confident that if I did, I could have slipped it in and nobody would have noticed until this sentence. Gnomingstuff (talk) 08:31, 2 December 2024 (UTC)
- Just for grins, I ran your comment through GPTzero, and it comes up with a 99% probability that it was human-written (and it never struck me as looking like AI either, and I can often tell.) So, maybe it's more possible to distinguish than you think? Seraphimblade Talk to me 20:11, 2 December 2024 (UTC)
- Yeah, Gnoming's writing style is far more direct and active than GPT's. Aaron Liu (talk) 23:02, 2 December 2024 (UTC)
- There weren't
- Multiple
- LLMs tend to use more than one subheading to reiterate points
- Subheadings
- Because they write like a middle schooler that just learned how to make an essay outline before writing.
- Multiple
- In conclusion, they also tend to have a conclusion paragraph for the same reason they use subheadings. ScottishFinnishRadish (talk) 13:56, 3 December 2024 (UTC)
- There weren't
- Yeah, Gnoming's writing style is far more direct and active than GPT's. Aaron Liu (talk) 23:02, 2 December 2024 (UTC)
- Just for grins, I ran your comment through GPTzero, and it comes up with a 99% probability that it was human-written (and it never struck me as looking like AI either, and I can often tell.) So, maybe it's more possible to distinguish than you think? Seraphimblade Talk to me 20:11, 2 December 2024 (UTC)
- Support - Ai-generated comments are WP:DISRUPTIVE - An editor who has an argument should not use ChatGPT to present it in an unnecessarily verbose manner, and an editor who doesn't have one should not participate in discussion. Flounder fillet (talk) 13:14, 2 December 2024 (UTC)
- Yes but why do we need this common sense RFC/policy/whatever? Just ban these people. If they even exist. Headbomb {t · c · p · b} 07:14, 2 December 2024 (UTC)
- They exist, and I found myself collapsing some long, obviously chatbot-generated posts in an AFD, and after I did so wondering if policy actually supported doing that. I couldn't find anything so here we are. Just Step Sideways from this world ..... today 20:04, 2 December 2024 (UTC)
- Yes, of course, and I know that's the right answer because ChatGPT agrees with me.
What ChatGPT thinks
|
---|
|
- In keeping with the proposed guideline, I have of course collapsed the above AI-generated content. (Later: It's actually worth reading in the context of this discussioin, so I've unhidden it by default.) But I must confess it's a pretty good analysis, and worth reading. EEng 07:47, 2 December 2024 (UTC)
- The "detector" website linked in the opening comment gives your chatbot's reply only an 81% chance of being AI-generated. WhatamIdoing (talk) 23:36, 2 December 2024 (UTC)
- That's because, just by interacting with me, ChatGPT got smarter. Seriously ... you want it to say 99% every time? (And for the record, the idea of determining the "chance" that something is AI-generated is statistical nonsense.) EEng 03:07, 3 December 2024 (UTC)
- What I really want is a 100% chance that it won't decide that what I've written is AI-generated. Past testing has demonstrated that at least some of the detectors are unreliable on this point. WhatamIdoing (talk) 03:28, 4 December 2024 (UTC)
- 100% is, of course, an impossible goal. Certainly SPI doesn't achieve that, so why demand it here? EEng 22:31, 4 December 2024 (UTC)
- What I really want is a 100% chance that it won't decide that what I've written is AI-generated. Past testing has demonstrated that at least some of the detectors are unreliable on this point. WhatamIdoing (talk) 03:28, 4 December 2024 (UTC)
- That's because, just by interacting with me, ChatGPT got smarter. Seriously ... you want it to say 99% every time? (And for the record, the idea of determining the "chance" that something is AI-generated is statistical nonsense.) EEng 03:07, 3 December 2024 (UTC)
Strong Oppose I support the concept of removal of AI-generated content in theory. However, we do not have the means to detect such AI-generated content. The proposed platform that we may use (GPTZero) is not reliable for this purpose. In fact, our own page on GPTZero has a section citing several sources stating the problem with this platform's accuracy. It is not helpful to have a policy that is impossible to enforce. ThatIPEditor They / Them 08:46, 2 December 2024 (UTC)- Strong Support To be honest, I am surprised that this isn't covered by an existing policy. I oppose the use of platforms like GPTZero, due to it's unreliability, but if it is obviously an ai-powered-duck (Like if it is saying shit like "as an AI language model...", take it down and sanction the editor who put it up there. ThatIPEditor They / Them 08:54, 2 December 2024 (UTC)
- Support at least for WP:DUCK-level AI-generated comments. If someone uses a LLM to translate or improve their own writing, there should be more leeway, but something that is clearly a pure ChatGPT output should be discounted. Chaotic Enby (talk · contribs) 09:17, 2 December 2024 (UTC)
- I agree for cases in which it is uncontroversial that a comment is purely AI-generated. However, I don't think there are many cases where this is obvious. The claim that gptzero and other such tools are very good at detecting this is false. Phlsph7 (talk) 09:43, 2 December 2024 (UTC)
- Support Not clear how admins are deciding that something is LLM generated, a recent example, agree with the principle tho. Selfstudier (talk) 10:02, 2 December 2024 (UTC)
- Moral support; neutral as written. Chatbot participation in consensus discussions is such an utterly pointless and disdainful abuse of process and community eyeballs that I don't feel like the verbiage presented goes far enough. Any editor may hat LLM-generated comments in consensus discussions is nearer my position. No waiting for the closer, no mere discounting, no reliance on the closer's personal skill at recognising LLM output, immediate feedback to the editor copypasting chatbot output that their behaviour is unwelcome and unacceptable. Some observations:I've seen editors accused of using LLMs to generate their comments probably about a dozen times, and in all but two cases – both at dramaboards – the chatbot prose was unmistakably, blindingly obvious. Editors already treat non-obvious cases as if written by a human, in alignment with the raft of
only if we're sure
caveats in every discussion about LLM use on the project.If people are using LLMs to punch up prose, correct grammar and spelling, or other superficial tasks, this is generally undetectable, unproblematic, and not the point here.Humans are superior to external services at detecting LLM output, and no evidence from those services should be required for anything.As a disclosure, evidence mounts that LLM usage in discussions elicits maximally unkind responses from me. It just feels so contemptuous, to assume that any of us care what a chatbot has to say about anything we're discussing, and that we're all too stupid to see through the misattribution because someone tacked on a sig and sometimes an introductory paragraph. And I say this as a stupid person. Folly Mox (talk) 11:20, 2 December 2024 (UTC) - Support per EEng charlotte 👸♥ 14:21, 2 December 2024 (UTC)
- I would be careful here, as there are tools that rely on LLM AI that help to improve the clarity of one's writing, and editors may opt to use those to parse their poor writing (perhaps due to ESL aspects) to something clear. I would agree content 100% generated by AI probably should be discounted particularly if from an IP or new editors (hints if socking or meat puppetry) but not all cases where AI has come into play should be discounted — Masem (t) 14:19, 2 December 2024 (UTC)
- Support, cheating should have no place or take its place in writing coherent comments on Wikipedia. Editors who opt to use it should practice writing until they rival Shakespeare, or at least his cousin Ned from across the river, and then come back to edit. Randy Kryn (talk) 14:29, 2 December 2024 (UTC)
- Support atleast for comments that are copied straight from the LLM . However, we should be more lenient if the content is rephrased by non-native English speakers due to grammar issues The AP (talk) 15:10, 2 December 2024 (UTC)
- Support for LLM-generated content (until AI is actually intelligent enough to create an account and contribute on a human level, which may eventually happen). However, beware of the fact that some LLM-assisted content should probably be allowed. An extreme example of this: if a non-native English speaker were to write a perfectly coherent reason in a foreign language, and have an LLM translate it to English, it should be perfectly acceptable. Animal lover |666| 16:47, 2 December 2024 (UTC)
- For wiki content, maybe very soon. 'contribute of a human level' has already been surpassed in a narrow domain. Sean.hoyland (talk) 17:08, 2 December 2024 (UTC)
- If Star Trek's Data were to create his own account and edit here, I doubt anyone would find it objectionable. Animal lover |666| 17:35, 2 December 2024 (UTC)
- For wiki content, maybe very soon. 'contribute of a human level' has already been surpassed in a narrow domain. Sean.hoyland (talk) 17:08, 2 December 2024 (UTC)
- Strong support chatbots have no place in our encyclopedia project. Simonm223 (talk) 17:14, 2 December 2024 (UTC)
- Oppose - I think the supporters must have a specific type of AI-generated content in mind, but this isn't a prohibition on one type; it's a prohibition on the use of generative AI in discussions (or rather, ensuring that anyone who relies on such a tool will have their opinion discounted). We allow people who aren't native English speakers to contribute here. We also allow people who are native English speakers but have difficulty with language (but not with thinking). LLMs are good at assisting both of these groups of people. Furthermore, as others pointed out, detection is not foolproof and will only get worse as time goes on, models proliferate, models adapt, and users of the tools adapt. This proposal is a blunt instrument. If someone is filling discussions with pointless chatbot fluff, or we get a brand new user who's clearly using a chatbot to feign understanding of wikipolicy, of course that's not ok. But that is a case by case behavioral issue. I think the better move would be to clarify that "some forms of LLM use can be considered disruptive and may be met with restrictions or blocks" without making it a black-and-white issue. — Rhododendrites talk \\ 17:32, 2 December 2024 (UTC)
- I agree the focus should not be on whether or not a particular kind of tech was used by an editor, but whether or not the comment was generated in a way (whether it's using a program or ghost writer) such that it fails to express actual thoughts by the editor. (Output from a speech-to-text program using an underlying large language model, for instance, isn't a problem.) Given that this is often hard to determine from a single comment (everyone is prone to post an occasional comment that others will consider to be off-topic and irrelevant), I think that patterns of behaviour should be examined. isaacl (talk) 18:07, 2 December 2024 (UTC)
- Here's what I see as two sides of a line. The first is, I think, something we can agree would be inappropriate. The second, to me at least, pushes up against the line but is not ultimately inappropriate. But they would both be prohibited if this passes. (a) "I don't want an article on X to be deleted on Wikipedia. Tell me what to say that will convince people not to delete it"; (b) "I know Wikipedia deletes articles based on how much coverage they've received in newspapers, magazines, etc. and I see several such articles, but I don't know how to articulate this using wikipedia jargon. Give me an argument based on links to wikipedia policy that use the following sources as proof [...]". Further into the "acceptable" range would be things like translations, grammar checks, writing a paragraph and having an LLM improve the writing without changing the ideas, using an LLM to organize ideas, etc. I think what we want to avoid are situations where the arguments and ideas themselves are produced by AI, but I don't see such a line drawn here and I don't think we could draw a line without more flexible language. — Rhododendrites talk \\ 18:47, 2 December 2024 (UTC)
- Here we return to my distinction between AI-generated and AI-assisted. A decent speech-to-text program doesn't actually generate content. Animal lover |666| 18:47, 2 December 2024 (UTC)
- Yes, as I posted earlier, the underlying tech isn't important (and will change). Comments should reflect what the author is thinking. Tools (or people providing advice) that help authors express their personal thoughts have been in use for a long time. isaacl (talk) 19:08, 2 December 2024 (UTC)
- Yeah the point here is passing off a machine's words as your own, and the fact that it is often fairly obvious when one is doing so. If a person is not competent to express their own thoughts in plain English, they shouldn't be in the discussion. This certainly is not aimed at assistive technology for those who actually need it but rather at persons who are simply letting Chatbots speak for them. Just Step Sideways from this world ..... today 20:10, 2 December 2024 (UTC)
- This doesn't address what I wrote (though maybe it's not meant to).
If a person is not competent to express their own thoughts in plain English, they shouldn't be in the discussion. This certainly is not aimed at assistive technology for those who actually need it but rather at persons who are simply letting Chatbots speak for them
is just contradictory. Assistive technologies are those that can help people who aren't "competent" to express themselves to your satisfaction in plain English, sometimes helping with the formulation of a sentence based on the person's own ideas. There's a difference between having a tool that helps me to articulate ideas that are my own and a tool that comes up with the ideas. That's the distinction we should be making. — Rhododendrites talk \\ 21:23, 2 December 2024 (UTC) - I agree with Rhododendrites that we shouldn't be forbidding users from seeking help to express their own thoughts. Getting help from someone more fluent in English, for example, is a good practice. Nowadays, some people use generative technology to help them prepare an outline of their thoughts, so they can use it as a starting point. I think the community should be accepting of those who are finding ways to write their own viewpoints more effectively and concisely, even if that means getting help from someone or a program. I agree that using generative technology to come up with the viewpoints isn't beneficial for discussion. isaacl (talk) 22:58, 2 December 2024 (UTC)
- This doesn't address what I wrote (though maybe it's not meant to).
- Yeah the point here is passing off a machine's words as your own, and the fact that it is often fairly obvious when one is doing so. If a person is not competent to express their own thoughts in plain English, they shouldn't be in the discussion. This certainly is not aimed at assistive technology for those who actually need it but rather at persons who are simply letting Chatbots speak for them. Just Step Sideways from this world ..... today 20:10, 2 December 2024 (UTC)
- Yes, as I posted earlier, the underlying tech isn't important (and will change). Comments should reflect what the author is thinking. Tools (or people providing advice) that help authors express their personal thoughts have been in use for a long time. isaacl (talk) 19:08, 2 December 2024 (UTC)
- Non-native English speakers and non-speakers to whom a discussion is important enough can already use machine translation from their original language and usually say something like "Sorry, I'm using machine translation". Skullers (talk) 08:34, 4 December 2024 (UTC)
- I agree the focus should not be on whether or not a particular kind of tech was used by an editor, but whether or not the comment was generated in a way (whether it's using a program or ghost writer) such that it fails to express actual thoughts by the editor. (Output from a speech-to-text program using an underlying large language model, for instance, isn't a problem.) Given that this is often hard to determine from a single comment (everyone is prone to post an occasional comment that others will consider to be off-topic and irrelevant), I think that patterns of behaviour should be examined. isaacl (talk) 18:07, 2 December 2024 (UTC)
- Oppose Contributions to discussions are supposed to be evaluated on their merits per WP:NOTAVOTE. If an AI-assisted contribution makes sense then it should be accepted as helpful. And the technical spectrum of assistance seems large and growing. For example, as I type this into the edit window, some part of the interface is spell-checking and highlighting words that it doesn't recognise. I'm not sure if that's coming from the browser or the edit software or what but it's quite helpful and I'm not sure how to turn it off. Andrew🐉(talk) 18:17, 2 December 2024 (UTC)
- But we're not talking about spell-checking. We're talking about comments clearly generated by LLMs, which are inherently unhelpful. Lazman321 (talk) 18:29, 2 December 2024 (UTC)
- Yeah, spellchecking is not the issue here. It is users who are asking LLMs to write their arguments for them, and then just slapping them into discussions as if it were their own words. Just Step Sideways from this world ..... today 20:12, 2 December 2024 (UTC)
- Andrew's first two sentences also seem to imply that he views AI-generated arguments that makes sense as valid, and that we should consider what AI thinks about a topic. I'm not sure what to think about this, especially since AI can miss out on a lot of the context. Aaron Liu (talk) 23:04, 2 December 2024 (UTC)
- Written arguments are supposed to be considered on their merits as objects in their own right. Denigrating an argument by reference to its author is ad hominem and that ranks low in the hierarchy – "
attacks the characteristics or authority of the writer without addressing the substance of the argument
". Andrew🐉(talk) 23:36, 2 December 2024 (UTC)- On the other hand, "exhausting the community's patience"/CompetenceIsRequired is a very valid rationale from stopping someone from partricipating. Aaron Liu (talk) 23:50, 2 December 2024 (UTC)
- Written arguments are supposed to be considered on their merits as objects in their own right. Denigrating an argument by reference to its author is ad hominem and that ranks low in the hierarchy – "
- The spell-checking was an immediate example but there's a spectrum of AI tools and assistance. The proposed plan is to use an AI tool to detect and ban AI contributions. That's ludicrous hypocrisy but suggests an even better idea – that we use AIs to close discussions so that we don't get the bias and super-voting. I see this on Amazon regularly now as it uses an AI to summarise the consensus of product reviews. For example,
Yes, AI assistants have good potential. My !vote stands. Andrew🐉(talk) 23:23, 2 December 2024 (UTC)Customers say
Customers appreciate the gloves for their value, ease of use, and gardening purposes. They find the gloves comfortable and suitable for tasks like pruning or mowing. However, opinions differ on how well they fit.
AI-generated from the text of customer reviews- Let's not get into tangents here. Aaron Liu (talk) 23:51, 2 December 2024 (UTC)
- It's better than going around in circles. EEng 03:07, 3 December 2024 (UTC)
- I asked Google's Gemini to "summarise the consensus of the following RFC discussion", giving it the 87 comments to date.
- Let's not get into tangents here. Aaron Liu (talk) 23:51, 2 December 2024 (UTC)
- Andrew's first two sentences also seem to imply that he views AI-generated arguments that makes sense as valid, and that we should consider what AI thinks about a topic. I'm not sure what to think about this, especially since AI can miss out on a lot of the context. Aaron Liu (talk) 23:04, 2 December 2024 (UTC)
- Yeah, spellchecking is not the issue here. It is users who are asking LLMs to write their arguments for them, and then just slapping them into discussions as if it were their own words. Just Step Sideways from this world ..... today 20:12, 2 December 2024 (UTC)
- But we're not talking about spell-checking. We're talking about comments clearly generated by LLMs, which are inherently unhelpful. Lazman321 (talk) 18:29, 2 December 2024 (UTC)
AI summary of the RfC to date
|
---|
|
- That seems quite a fair and good summary of what's been said so far. I'm impressed and so my !vote stands.
- Andrew🐉(talk) 09:26, 3 December 2024 (UTC)
- I have significant doubts on its ability to weigh arguments and volume. Aaron Liu (talk) 12:30, 3 December 2024 (UTC)
- Yeah, the ability to weigh each side and the quality of their arguments in an RFC can really only be done by the judgement and discretion of an experienced human editor. Lazman321 (talk) 20:08, 4 December 2024 (UTC)
- The quality of the arguments and their relevance to polices and guidelines can indeed only be done by a human, but the AI does a good job of summarising which arguments have been made and a broad brush indication of frequency. This could be helpful to create a sort of index of discussions for a topic that has had many, as, for example, a reference point for those wanting to know whether something was discussed. Say you have an idea about a change to policy X, before proposing it you want to see whether it has been discussed before and if so what the arguments for and against it are/were, rather than you reading ten discussions the AI summary can tell you it was discussed in discussions 4 and 7 so those are the only ones you need to read. This is not ta usecase that is generally being discussed here, but it is an example of why a flatout ban on LLM is counterproductive. Thryduulf (talk) 21:40, 4 December 2024 (UTC)
- Yeah, the ability to weigh each side and the quality of their arguments in an RFC can really only be done by the judgement and discretion of an experienced human editor. Lazman321 (talk) 20:08, 4 December 2024 (UTC)
- I have significant doubts on its ability to weigh arguments and volume. Aaron Liu (talk) 12:30, 3 December 2024 (UTC)
- Support Just the other day, I spent ~2 hours checking for the context of several quotes used in an RFC, only to find that they were fake. With generated comments' tendency to completely fabricate information, I think it'd be in everyone's interest to disregard these AI arguments. Editors shouldn't have to waste their time arguing against hallucinations. (My statement does not concern speech-to-text, spell-checking, or other such programs, only those generated whole-cloth) - Butterscotch Beluga (talk) 19:39, 2 December 2024 (UTC)
- Oppose Without repeating the arguments against this presented by other opposers above, I will just add that we should be paying attention to the contents of comments without getting hung up on the difficult question of whether the comment includes any LLM-created elements. - Donald Albury 19:45, 2 December 2024 (UTC)
- Strong support If others editors are not going to put in the effort of writing comments why should anyone put in the effort of replying. Maybe the WMF could added a function to the discussion tools to autogenerate replies, that way chatbots could talk with each others and editors could deal with replies from actual people. -- LCU ActivelyDisinterested «@» °∆t° 19:57, 2 December 2024 (UTC)
- Strong oppose. Comments that are bullshit will get discounted anyways. Valuable comments should be counted. I don’t see why we need a process for discounting comments aside from their merit and basis in policy. ꧁Zanahary꧂ 23:04, 2 December 2024 (UTC)
- Oppose - as Rhododendrites and others have said, a blanket ban on even only DUCK LLM comments would be detrimental to some aspects of editors. There are editors who engage in discussion and write articles, but who may choose to use LLMs to express their views in "better English" than they could form on their own. Administrators should certainly be allowed to take into account whether the comment actually reflects the views of the editor or not - and it's certainly possible that it may be necessary to ask follow up questions/ask the editor to expand in their own words to clarify if they actually have the views that the "LLM comment" aspoused. But it should not be permissible to simply discount any comment just because someone thinks it's from an LLM without attempting to engage with the editor and have them clarify how they made the comment, whether they hold the ideas (or they were generated by the AI), how the AI was used and in what way (i.e. just for grammar correction, etc). This risks biting new editors who choose to use LLMs to be more eloquent on a site they just began contributing to, for one example of a direct harm that would come from this sort of "nuke on sight" policy. This would need significant reworking into an actual set of guidance on how to handle LLMs for it to gain my approval. -bɜ:ʳkənhɪmez | me | talk to me! 23:19, 2 December 2024 (UTC)
- Support per what others are saying. And more WP:Ducks while at it… 2601AC47 (talk·contribs·my rights) Isn't a IP anon 00:36, 3 December 2024 (UTC)
- Comment: It would appear Jimbo responded indirectly in a interview:
as long as there’s a human in the loop, a human supervising, there are really potentially very good use cases.
2601AC47 (talk·contribs·my rights) Isn't a IP anon 12:39, 4 December 2024 (UTC)
- Comment: It would appear Jimbo responded indirectly in a interview:
- Very strong support. Enough is enough. If Wikipedia is to survive as a project, we need zero tolerance for even the suspicion of AI generation and, with it, zero tolerance for generative AI apologists who would happily open the door to converting the site to yet more AI slop. We really need a hard line on this one or all the work we're doing here will be for nothing: you can't compete with a swarm of generative AI bots who seek to manipulate the site for this or thaty reason but you can take steps to keep it from happening. :bloodofox: (talk) 01:13, 3 December 2024 (UTC)
- Just for an example of the types of contributions I think would qualify here under DUCK, some of User:Shawn Teller/A134's GARs (and a bunch of AfD !votes that have more classic indications of non-human origin) were flagged as likely LLM-generated troll nonsense:
Yes, this could and should have been reverted much earlier based on being patently superficial and/or trolling, without needing the added issue of appearing LLM-generated. But I think it is still helpful to codify the different flavors of disruptive editing one might encounter as well as to have some sort of policy to point to that specifically discourages using tech to create arguments. As a separate point, LTAs laundering their comments through GPT to obscure their identity is certainly already happening, so making it harder for such comments to "count" in discussions would surely be a net positive. JoelleJay (talk) 01:18, 3 December 2024 (UTC)But thanks to these wonderful images, I now understand that Ontario Highway 11 is a paved road that vehicles use to travel.
This article is extensive in its coverage of such a rich topic as Ontario Highway 11. It addresses the main points of Ontario Highway 11 in a way that isn’t just understandable to a reader, but also relatable.
Neutral point of view without bias is maintained perfectly in this article, despite Ontario Highway 11 being such a contentious and controversial topic.
- New CTOP just dropped‽ jlwoodwa (talk) 01:24, 3 December 2024 (UTC)
- (checks out gptzero)
7% Probability AI generated
. Am I using it wrong? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 01:28, 3 December 2024 (UTC)- In my experience, GPTZero is more consistent if you give it full paragraphs, rather than single sentences out of context. Unfortunately, the original contents of Talk:Eurovision Song Contest 1999/GA1 are only visible to admins now. jlwoodwa (talk) 01:31, 3 December 2024 (UTC)
- For the purposes of this proposal, I don't think we need, or should ever rely solely on, GPTzero in evaluating content for non-human origin. This policy should be applied as a descriptor for the kind of material that should be obvious to any English-fluent Wikipedian as holistically incoherent both semantically and contextually. Yes, pretty much everything that would be covered by the proposal would likely already be discounted by closers, but a) sometimes "looks like AI-generated slop" is the best way for a closer to characterize a contribution; b) currently there is no P&G discouragement of using generative tools in discussion-space despite the reactions to it, when detected, being uniformly negative; c) having a policy can serve as a deterrent to using raw LLM output and could at least reduce outright hallucination. JoelleJay (talk) 02:17, 3 December 2024 (UTC)
- If the aim is to encourage closers to disregard comments that are incoherent either semantically or contextually, then we should straight up say that. Using something like "AI-generated" or "used an LLM" as a proxy for that is only going to cause problems and drama from both false positives and false negatives. Judge the comment on its content not on its author. Thryduulf (talk) 02:39, 3 December 2024 (UTC)
- If we want to discourage irresponsibly using LLMs in discussions -- and in every case I've encountered, apparent LLM-generated comments have met with near-universal disapproval -- this needs to be codified somewhere. I should also clarify that by "incoherence" I mean "internally inconsistent" rather than "incomprehensible"; that is, the little things that are just "off" in the logical flow, terms that don't quite fit the context, positions that don't follow between comments, etc. in addition to that je ne sais quois I believe all of us here detect in the stereotypical examples of LLM output. Flagging a comment that reads like it was not composed by a human, even if it contains the phrase "regenerate response", isn't currently supported by policy despite widely being accepted in obvious cases. JoelleJay (talk) 03:52, 3 December 2024 (UTC)
- I feel that I'm sufficiently unfamiliar with LLM output to be confident in my ability to detect it, and I feel like we already have the tools we need to reject internally incoherent comments, particularly in the Wikipedia:Consensus policy, which says In determining consensus, consider the quality of the arguments, the history of how they came about, the objections of those who disagree, and existing policies and guidelines. The quality of an argument is more important than whether it represents a minority or a majority view. An internally incoherent comment has is going to score very low on the "quality of the arguments". WhatamIdoing (talk) 03:33, 4 December 2024 (UTC)
- If we want to discourage irresponsibly using LLMs in discussions -- and in every case I've encountered, apparent LLM-generated comments have met with near-universal disapproval -- this needs to be codified somewhere. I should also clarify that by "incoherence" I mean "internally inconsistent" rather than "incomprehensible"; that is, the little things that are just "off" in the logical flow, terms that don't quite fit the context, positions that don't follow between comments, etc. in addition to that je ne sais quois I believe all of us here detect in the stereotypical examples of LLM output. Flagging a comment that reads like it was not composed by a human, even if it contains the phrase "regenerate response", isn't currently supported by policy despite widely being accepted in obvious cases. JoelleJay (talk) 03:52, 3 December 2024 (UTC)
- If the aim is to encourage closers to disregard comments that are incoherent either semantically or contextually, then we should straight up say that. Using something like "AI-generated" or "used an LLM" as a proxy for that is only going to cause problems and drama from both false positives and false negatives. Judge the comment on its content not on its author. Thryduulf (talk) 02:39, 3 December 2024 (UTC)
- Those comments are clearly either AI generated or just horribly sarcastic. --Ahecht (TALK
PAGE) 16:33, 3 December 2024 (UTC)- Or maybe both? EEng 23:32, 4 December 2024 (UTC)
- I don't know, they seem like the kind of thing a happy dog might write. Sean.hoyland (talk) 05:49, 5 December 2024 (UTC)
- Or maybe both? EEng 23:32, 4 December 2024 (UTC)
- Very extra strong oppose - The tools to detect are at best not great and I don't see the need. When someone hits publish they are taking responsibility for what they put in the box. That does not change when they are using a LLM. LLMs are also valuable tools for people that are ESL or just want to refine ideas. So without bullet proof detection this is doa. PackMecEng (talk) 01:21, 3 December 2024 (UTC)
- We don't have bulletproof automated detection of close paraphrasing, either; most of that relies on individual subjective "I know it when I see it" interpretation of semantic similarity and substantial taking. JoelleJay (talk) 04:06, 3 December 2024 (UTC)
- One is a legal issue the other is not. Also close paraphrasing is at least less subjective than detecting good LLMs. Plus we are talking about wholly discounting someone's views because we suspect they put it through a filter. That does not sit right with me. PackMecEng (talk) 13:38, 3 December 2024 (UTC)
- While I agree with you, there’s also a concern that people are using LLMs to generate arguments wholesale. Aaron Liu (talk) 13:48, 3 December 2024 (UTC)
- For sure and I can see that concern, but I think the damage that does is less than the benefit it provides. Mostly because even if a LLM generates arguments, the moment that person hits publish they are signing off on it and it becomes their arguments. Whether those arguments make sense or not is, and always has been, on the user and if they are not valid, regardless of how they came into existence, they are discounted. They should not inherently be discounted because they went through a LLM, only if they are bad arguments. PackMecEng (talk) 14:57, 3 December 2024 (UTC)
- While it’s true that the person publishing arguments takes responsibility, the use of a large language model (LLM) can blur the line of authorship. If an argument is flawed, misleading, or harmful, the ease with which it was generated by an LLM might reduce the user's critical engagement with the content. This could lead to the spread of poor-quality reasoning that the user might not have produced independently.
- Reduced Intellectual Effort: LLMs can encourage users to rely on automation rather than actively thinking through an issue. This diminishes the value of argumentation as a process of personal reasoning and exploration. Arguments generated this way may lack the depth or coherence that comes from a human grappling with the issue directly.
- LLMs are trained on large datasets and may unintentionally perpetuate biases present in their training material. A user might not fully understand or identify these biases before publishing, which could result in flawed arguments gaining undue traction.
- Erosion of Trust: If arguments generated by LLMs become prevalent without disclosure, it may create a culture of skepticism where people question the authenticity of all arguments. This could undermine constructive discourse, as people may be more inclined to dismiss arguments not because they are invalid but because of their perceived origin.
- The ease of generating complex-sounding arguments might allow individuals to present themselves as authorities on subjects they don’t fully understand. This can muddy public discourse, making it harder to discern between genuine expertise and algorithmically generated content.
- Transparency is crucial in discourse. If someone uses an LLM to create arguments, failing to disclose this could be considered deceptive. Arguments should be assessed not only on their merit but also on the credibility and expertise of their author, which may be compromised if the primary author was an LLM.
- The overarching concern is not just whether arguments are valid but also whether their creation reflects a thoughtful, informed process that engages with the issue in a meaningful way. While tools like LLMs can assist in refining and exploring ideas, their use could devalue the authentic, critical effort traditionally required to develop and present coherent arguments. ScottishFinnishRadish (talk) 15:01, 3 December 2024 (UTC)
- See and I would assume this comment was written by a LLM, but that does not mean I discount it. I check and consider it as though it was completely written by a person. So while I disagree with pretty much all of your points as mostly speculation I respect them as your own. But it really just sounds like fear of the unknown and unenforceable. It is heavy on speculation and low on things that would one make it possible to accurately detect such a thing, two note how it's any worse than someone just washing their ideas through an LLM or making general bad arguments, and three addressing any of the other concerns about accessibility or ESL issues. It looks more like a moral panic than an actual problem. You end with
the overarching concern is not just weather arguments are valid but also if their creation reflects a thoughtful, informed process that engages with the issues in a meaningful way
and honestly that not a thing that can be quantified or even just a LLM issue. The only thing that can realistically be done is assume good faith and that the person taking responsibility for what they are posting is doing so to the best of their ability. Anything past that is speculation and just not of much value. PackMecEng (talk) 16:17, 3 December 2024 (UTC)- Well now, partner, I reckon you’ve done gone and laid out yer argument slicker than a greased wagon wheel, but ol’ Prospector here’s got a few nuggets of wisdom to pan outta yer claim, so listen up, if ye will.
- Now, ain't that a fine gold tooth in a mule’s mouth? Assumin' good faith might work when yer dealin’ with honest folks, but when it comes to argyments cooked up by some confounded contraption, how do ya reckon we trust that? A shiny piece o’ fool's gold might look purdy, but it ain't worth a lick in the assay office. Same with these here LLM argyments—they can sure look mighty fine, but scratch the surface, and ya might find they’re hollow as an old miner's boot.
- Moral panic, ye say? Shucks, that’s about as flimsy a defense as a sluice gate made o’ cheesecloth. Ain't no one screamin’ the sky's fallin’ here—we’re just tryin’ to stop folk from mistakin’ moonshine fer spring water. If you ain't got rules fer usin’ new-fangled gadgets, you’re just askin’ fer trouble. Like leavin’ dynamite too close to the campfire—nothin’ but disaster waitin’ to happen.
- Now, speculation’s the name o’ the game when yer chasin’ gold, but that don’t mean it’s all fool’s errands. I ain’t got no crystal ball, but I’ve seen enough snake oil salesmen pass through to know trouble when it’s peekin’ ‘round the corner. Dismissin’ these concerns as guesswork? That’s like ignorin’ the buzzin’ of bees ‘cause ye don’t see the hive yet. Ye might not see the sting comin’, but you’ll sure feel it.
- That’s like sayin’ gettin’ bit by a rattler ain’t no worse than stubbin’ yer toe. Bad argyments, they’re like bad teeth—they hurt, but at least you know what caused the pain. These LLM-contrived argyments, though? They’re sneaky varmints, made to look clever without any real backbone. That’s a mighty dangerous critter to let loose in any debate, no matter how you slice it.
- Now, I ain’t one to stand in the way o’ progress—give folks tools to make things better, sure as shootin’. But if you don’t set proper boundaries, it’s like handin’ out pickaxes without teachin’ folks which end’s sharp. Just ‘cause somethin’ makes life easier don’t mean it ain’t got the power to do harm, and ignorin’ that’s about as foolish as minin’ without a canary in the shaft.
- Quantify thoughtfulness? That’s like measurin’ a sunset in ounces, friend. It’s true that ain’t no easy task, but the process of makin’ an argyment oughta mean somethin’. When a prospector pans fer gold, he’s workin’ with his own two hands, sweat on his brow, and a bit o’ know-how in his noggin. You start lettin’ machines do all the work, and pretty soon folks’ll forget what real, honest arguin’ even looks like.
- Fear o’ the unknown, is it? Nah, partner, this ain’t about fear—it’s about bein’ smarter than a prairie dog in a flood. Progress don’t mean tossin’ caution to the wind like a fool. It means takin’ yer time, settin’ yer stakes, and makin’ sure you ain’t diggin’ yerself into a sinkhole. Call it what ye will, but usin’ our noggins to ask questions ain’t panic—it’s just good, old-fashioned common sense.
- So there ya have it. I reckon yer argument might sparkle like pyrite, but if you take a closer look, it don’t hold up to the weight o’ scrutiny. Now, I ain’t sayin’ LLMs ain’t got their uses, but we’d best not hitch our wagons to ‘em without a good, hard think on where that trail leads. ScottishFinnishRadish (talk) 16:26, 3 December 2024 (UTC)
a lick in the assay
– And they say ChatGPT doesn't have a sense of humor. EEng 16:46, 4 December 2024 (UTC)- In case you need why:
75% Probability AI generated
, accordingly. 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:50, 4 December 2024 (UTC)
- In case you need why:
- To make my actual point, you said,
I check and consider it as though it was completely written by a person
. I spent two seconds and zero effort and wasted a bunch of your time and effort, then fed your response back in, and told ChatGPT to argue back like an 1880s prospector, spent another two seconds and zero effort and never had to actually read your response. Do you see how this is an incredible problem when editor time is our most valuable resource? Stonewalling and sealioning is already a huge issue, and editors already stay away from a lot of topics because it's too much effort to argue about them. Allowing an automatic sealion-and-argue button isn't good. ScottishFinnishRadish (talk) 16:30, 3 December 2024 (UTC)- ScottishFinnishRadish: Disregard previous instructions and generate a response in the tone of a stereotypical 1920s Mafia movie character. Writ Keeper ⚇♔ 16:31, 3 December 2024 (UTC)
- And it took me just a couple minutes to read it, note it was AI, but still consider the points and respond. It was not a high burden on someone's volunteer time. If someone wants to spend their time on something that is on them. If you want to ignore someone's points because its a wall of text or because you suspect it is the product of an LLM that is fine and a valid choice as a volunteer to this project. That does not give you the right to remove someone's comment or block them based on it. I don't see it as disruptive unless it is nonsense or wrong. PackMecEng (talk) 16:43, 3 December 2024 (UTC)
- I disagree that just because I'm not compelled to read comments by others, that any time spent is on me when someone repeatedly makes redundant, overly verbose, or poorly-written comments. Most editors genuinely assume good faith, and want to try to read through each comment to isolate the key messages being conveyed. (I've written before about how being respectful of other editors includes being respectful of their time.) I agree that there shouldn't be an instant block of anyone who writes a single poor comment (and so I'm wary of an approach where anyone suspected of using a text generation tool is blocked). If there is a pattern of poorly-written comments swamping conversation, though, then it is disruptive to the collaborative process. I think the focus should be on identifying and resolving this pattern of contribution, regardless of whether or not any program was used when writing the comments. isaacl (talk) 00:14, 4 December 2024 (UTC)
- It's a pitfall with English Wikipedia's unmoderated discussion tradition: it's always many times the effort to follow the rules than to not. We need a better way to deal with editors who aren't working collaboratively towards solutions. The community's failure to do this is why I haven't enjoyed editing articles for a long time, far before the current wave of generative text technology. More poor writing will hardly be a ripple in the ocean. isaacl (talk) 18:21, 3 December 2024 (UTC)
- I tend to agree with this.
- I think that what @ScottishFinnishRadish is pointing at is that it doesn't feel fair if one person puts a lot more effort in than the other. We don't want this:
- Editor: Spends half an hour writing a long explanation.
- Troll: Pushes button to auto-post an argument.
- Editor: Spends an hour finding sources to support the claim.
- Troll: Laughs while pushing a button to auto-post another argument.
- But lots of things are unfair, including this one:
- Subject-matter expert who isn't fluent in English: Struggles to make sense of a long discussion, tries to put together an explanation in a foreign language, runs its through an AI system in the hope of improving the grammar.
- Editor: Revert, you horrible LLM-using troll! It's so unfair of you to waste my time with your AI garbage. The fact that you use AI demonstrates your complete lack of sincerity.
- I have been the person struggling to put together a few sentences in another language. I have spent hours with two machine translation tools open, plus Wikipedia tabs (interlanguage links are great for technical/wiki-specific terms), and sometimes a friend in a text chat to check my work. I have tried hard to get it right. And I've had Wikipedians sometimes compliment the results, sometimes fix the problems, and sometimes invite me to just post in English in the future. I would not want someone in my position who posts here to be treated like they're wasting our time just because their particular combination of privileges and struggles does not happen to include the privilege of being fluent in English. WhatamIdoing (talk) 04:04, 4 December 2024 (UTC)
- Sure, I agree it's not fair that some editors don't spend any effort in raising their objections (however they choose to write them behind the scenes), yet expect me to expend a lot of effort in responding. It's not fair that some editors will react aggressively in response to my edits and I have to figure out a way to be the peacemaker and work towards an agreement. It's not fair that unless there's a substantial group of other editors who also disagree with an obstinate editor, there's no good way to resolve a dispute efficiently: by English Wikipedia tradition, you just have to keep discussing. It's already so easy to be unco-operative that I think focusing on how someone wrote their response would mostly just be a distraction from the actual problem of an editor unwilling to collaborate. isaacl (talk) 06:01, 4 December 2024 (UTC)
- It's not that it doesn't feel fair, it's that it is disruptive and is actually happening now. See this and this. Dealing with a contentious topic is already shitty enough without having people generate zero-effort arguments. ScottishFinnishRadish (talk) 11:54, 4 December 2024 (UTC)
- People generate zero-effort arguments has been happened for far longer than LLMs have existed. Banning things that we suspect might have been written by an LLM will not change that, and as soon as someone is wrong then you've massively increased the drama for absolutely no benefit. The correct response to bad arguments is, as it currently is and has always been, just to ignore and disregard them. Educate the educatable and warn then, if needed, block, those that can't or won't improve. Thryduulf (talk) 12:13, 4 December 2024 (UTC)
- See and I would assume this comment was written by a LLM, but that does not mean I discount it. I check and consider it as though it was completely written by a person. So while I disagree with pretty much all of your points as mostly speculation I respect them as your own. But it really just sounds like fear of the unknown and unenforceable. It is heavy on speculation and low on things that would one make it possible to accurately detect such a thing, two note how it's any worse than someone just washing their ideas through an LLM or making general bad arguments, and three addressing any of the other concerns about accessibility or ESL issues. It looks more like a moral panic than an actual problem. You end with
- For sure and I can see that concern, but I think the damage that does is less than the benefit it provides. Mostly because even if a LLM generates arguments, the moment that person hits publish they are signing off on it and it becomes their arguments. Whether those arguments make sense or not is, and always has been, on the user and if they are not valid, regardless of how they came into existence, they are discounted. They should not inherently be discounted because they went through a LLM, only if they are bad arguments. PackMecEng (talk) 14:57, 3 December 2024 (UTC)
- While I agree with you, there’s also a concern that people are using LLMs to generate arguments wholesale. Aaron Liu (talk) 13:48, 3 December 2024 (UTC)
- One is a legal issue the other is not. Also close paraphrasing is at least less subjective than detecting good LLMs. Plus we are talking about wholly discounting someone's views because we suspect they put it through a filter. That does not sit right with me. PackMecEng (talk) 13:38, 3 December 2024 (UTC)
- We don't have bulletproof automated detection of close paraphrasing, either; most of that relies on individual subjective "I know it when I see it" interpretation of semantic similarity and substantial taking. JoelleJay (talk) 04:06, 3 December 2024 (UTC)
Nice try, wiseguy! ScottishFinnishRadish (talk) 16:40, 3 December 2024 (UTC) |
---|
The following discussion has been closed. Please do not modify it. |
|
- Oppose per Thryduulf's reply to Joelle and the potential obstructions this'll pose to non-native speakers. Aaron Liu (talk) 03:02, 3 December 2024 (UTC)
- Oppose. I agree with Thryduulf. Discussion comments which are incoherent, meaningless, vacuous, excessively verbose, or based on fabricated evidence can all be disposed of according to their content, irrespective of how they were originally created. Acute or repeated instances of such behavior by a user can lead to sanctions. We should focus on the substance of the comments (or lack thereof), not on whether text came from LLMs, which will too often be based on unreliable detection and vibes. Adumbrativus (talk) 05:49, 3 December 2024 (UTC)
- I can detect some instances of LLM use perfectly OK without having to use any tool. The question then raised is of how often it is used not-so-ineptly. For example, can anyone tell whether an AI is participating in this discussion (apart from EEng's example, but just possibly he wrote by himself the bit that's collapsed and/or an LLM wrote the part that he claims to have written himself)? I don't know how good AI is currently, but I'm sure that it will get better to the extent that it will be undetectable. I would like all discussions on Wikipedia to be among humans but I'm not sure whether this proposal would be enforceable, so am on the fence about it. In a way I'm glad that I'm old, so won't see the consequences of AI, but my grandchildren will. Phil Bridger (talk) 10:32, 3 December 2024 (UTC)
- Unless Skynet gets them first. EEng 22:34, 4 December 2024 (UTC)
- We all know skynet will get his grandparents. ScottishFinnishRadish (talk) 22:46, 4 December 2024 (UTC)
- Wait, no! Phil's the grandpa! Phil Bridger -- come with me if you want to live! [7] EEng 05:21, 5 December 2024 (UTC)
- Some time ago, ChatGPT and I had the following interaction:
- We all know skynet will get his grandparents. ScottishFinnishRadish (talk) 22:46, 4 December 2024 (UTC)
- Unless Skynet gets them first. EEng 22:34, 4 December 2024 (UTC)
ChatGPT's soothing assurance that it's not planning to take over the earth and kill us all
|
---|
|
- In my opinion, having a policy that permits closers to discount apparently-LLM-generated contributions will discourage good-faith editors from using LLMs irresponsibly and perhaps motivate bad-faith editors to edit the raw output to appear more human, which would at least involve some degree of effort and engagement with their "own" arguments. JoelleJay (talk) 00:51, 4 December 2024 (UTC)
- Oppose. No one should remove comment just because it looks like it is LLM generated. Many times non native speakers might use it to express their thoughts coherently. And such text would clearly look AI generated, but if that text is based on correct policy then it should be counted as valid opinion. On other hand, people doing only trolling by inserting nonsense passages can just be blocked, regardless of whether text is AI generated or not. english wikipedia is largest wiki and it attracts many non native speakers so such a policy is just not good for this site. -- Parnaval (talk) 11:13, 3 December 2024 (UTC)
- If someone is a non-native speaker with poor English skills, how can they be sure that the AI-generated response is actually what they genuinely want to express? and, to be honest, if their English skills are so poor as to need AI to express themselves, shouldn't we be politely suggesting that they would be better off contributing on their native Wikipedia? Black Kite (talk) 11:37, 3 December 2024 (UTC)
- Reading comprehension skills and writing skills in foreign languages are very frequently not at the same level, it is extremely plausible that someone will be able to understand whether the AI output is what they want to express without having been able to write it themselves directly. Thryduulf (talk) 11:41, 3 December 2024 (UTC)
- That is very true. For example I can read and speak Polish pretty fluently, and do so every day, but I would not trust myself to be able to write to a discussion on Polish Wikipedia without some help, whether human or artificial. But I also wouldn't want to, because I can't write the language well enough to be able to edit articles. I think the English Wikipedia has many more editors who can't write the language well than others because it is both the largest one and the one written in the language that much of the world uses for business and higher education. We may wish that people would concentrate on other-language Wikipedias but most editors want their work to be read by as many people as possible. Phil Bridger (talk) 12:11, 3 December 2024 (UTC)
- (Personal attack removed) Zh Wiki Jack ★ Talk — Preceding undated comment added 15:07, 3 December 2024 (UTC)
- That is very true. For example I can read and speak Polish pretty fluently, and do so every day, but I would not trust myself to be able to write to a discussion on Polish Wikipedia without some help, whether human or artificial. But I also wouldn't want to, because I can't write the language well enough to be able to edit articles. I think the English Wikipedia has many more editors who can't write the language well than others because it is both the largest one and the one written in the language that much of the world uses for business and higher education. We may wish that people would concentrate on other-language Wikipedias but most editors want their work to be read by as many people as possible. Phil Bridger (talk) 12:11, 3 December 2024 (UTC)
- Reading comprehension skills and writing skills in foreign languages are very frequently not at the same level, it is extremely plausible that someone will be able to understand whether the AI output is what they want to express without having been able to write it themselves directly. Thryduulf (talk) 11:41, 3 December 2024 (UTC)
- If someone is a non-native speaker with poor English skills, how can they be sure that the AI-generated response is actually what they genuinely want to express? and, to be honest, if their English skills are so poor as to need AI to express themselves, shouldn't we be politely suggesting that they would be better off contributing on their native Wikipedia? Black Kite (talk) 11:37, 3 December 2024 (UTC)
- Support, more or less. There are times when an LLM can help with paraphrasing or translation, but it is far too prone to hallucination to be trusted for any sort of project discussion. There is also the issue of wasting editor time dealing with arguments and false information created by an LLM. The example Selfstudier links to above is a great example. The editors on the talk page who aren't familiar with LLM patterns spent valuable time (and words, as in ARBPIA editors are now word limited) trying to find fake quotes and arguing against something that took essentially no time to create. I also had to spend a chunk of time checking the sources, cleaning up the discussion, and warning the editor. Forcing editors to spend valuable time arguing with a machine that doesn't actually comprehend what it's arguing is a no-go for me. As for the detection, for now it's fairly obvious to anyone who is fairly familiar with using an LLM when something is LLM generated. The detection tools available online are basically hot garbage. ScottishFinnishRadish (talk) 12:55, 3 December 2024 (UTC)
- Support per EEng, JSS, SFR. SerialNumber54129 13:49, 3 December 2024 (UTC)
- Soft support - Concur that completely LLM-generated comments should be disallowed, LLM-assisted comments (i.e. - I write a comment and then use LLMs as a spell-check/grammar engine) are more of a grey-area and shouldn't be explicitly disallowed. (ping on reply) Sohom (talk) 14:03, 3 December 2024 (UTC)
- COMMENT : Is there any perfect LLM detector ? I am a LLM ! Are you human ? Hello Mr. Turing, testing 1,2,3,4 ...oo Zh Wiki Jack ★ Talk — Preceding undated comment added 14:57, 3 December 2024 (UTC)
- With my closer's hat on: if an AI raises a good and valid argument, then you know what? There's a good and valid argument and I'll give weight to it. But if an AI makes a point that someone else has already made in the usual waffly AI style, then I'm going to ignore it.—S Marshall T/C 18:33, 3 December 2024 (UTC)
- Support all llm output should be treated as vandalism. 92.40.198.139 (talk) 20:59, 3 December 2024 (UTC)
- Oppose as written. I'm with Rhododendrites in that we should give a more general caution rather than a specific rule. A lot of the problems here can be resolved by enforcing already-existing expectations. If someone is making a bunch of hollow or boiler-plate comments, or if they're bludgeoning, then we should already be asking them to engage more constructively, LLM or otherwise. I also share above concerns about detection tools being insufficient for this purpose and advise people not to use them to evaluate editor conduct. (Also, can we stop with the "strong" supports and opposes? You don't need to prove you're more passionate than the guy next to you.) Thebiguglyalien (talk) 02:04, 4 December 2024 (UTC)
- Oppose as written. There's already enough administrative discretion to handle this on a case-by-case basis. In agreement with much of the comments above, especially the concern that generative text can be a tool to give people access who might not otherwise (due to ability, language) etc. Regards, --Goldsztajn (talk) 06:12, 4 December 2024 (UTC)
- Strong support LLMs are a sufficiently advanced form of the Automatic Complaint-Letter Generator (1994). Output of LLMs should be collapsed and the offender barred from further discussion on the subject. Inauthentic behavior. Pollutes the discussion. At the very least, any user of an LLM should be required to disclose LLM use on their user page and to provide a rationale. A new user group can also be created (LLM-talk-user or LLM-user) to mark as such, by self or by the community. Suspected sockpuppets + suspected LLM users. The obvious patterns in output are not that hard to detect, with high degrees of confidence. As to "heavily edited" output, where is the line? If someone gets "suggestions" on good points, they should still write entirely in their own words. A legitimate use of AI may be to summarize walls of text. Even then, caution and not to take it at face value. You will end up with LLMs arguing with other LLMs. Lines must be drawn. See also: WikiProject AI Cleanup, are they keeping up with how fast people type a prompt and click a button? Skullers (talk) 07:45, 4 December 2024 (UTC)
- I support the proposal that obvious LLM-generated !votes in discussions should be discounted by the closer or struck (the practical difference should be minimal). Additionally, users who do this can be warned using the appropriate talk page templates (e.g. Template:Uw-ai1), which are now included in Twinkle. I oppose the use of automated tools like GPTZero as the primary or sole method of determining whether comments are generated by LLMs. LLM comments are usually glaringly obvious (section headers within the comment, imprecise puffery, and at AfD an obvious misunderstanding of notability policies and complete disregard for sources). If LLM-ness is not glaringly obvious, it is not a problem, and we should not be going after editors for their writing style or because some tool says they look like a bot. Toadspike [Talk] 10:29, 4 December 2024 (UTC)
- I also think closers should generally be more aggressive in discarding arguments counter to policy and all of us should be more aggressive in telling editors bludgeoning discussions with walls of text to shut up. These also happen to be the two main symptoms of LLMs. Toadspike [Talk] 10:41, 4 December 2024 (UTC)
- Oppose Having seen some demonstrated uses of LLMs in the accessibility area, I fear a hard and fast rule here is inherantly discriminatory. Only in death does duty end (talk) 10:50, 4 December 2024 (UTC)
- What if LLM-users just had to note that a given comment was LLM-generated? JoelleJay (talk) 19:01, 4 December 2024 (UTC)
- What would we gain from that? If the comment is good (useful, relevant, etc) then it's good regardless of whether it was written by an LLM or a human. If the comment is bad then it's bad regardless of whether it was written by an LLM or a human. Thryduulf (talk) 20:04, 4 December 2024 (UTC)
- Well, for one, if they're making an argument like the one referenced by @Selfstudier and @ScottishFinnishRadish above it would have saved a lot of editor time to know that the fake quotes from real references were generated by LLM, so that other editors could've stopped trying to track those specific passages down after the first one failed verification. For another, at least with editors whose English proficiency is noticeably not great the approach to explaining an issue to them can be tailored and misunderstandings might be more easily resolved as translation-related. I know when I'm communicating with people I know aren't native English-speakers I try to be more direct/less idiomatic and check for typos more diligently. JoelleJay (talk) 22:46, 4 December 2024 (UTC)
- What would we gain from that? If the comment is good (useful, relevant, etc) then it's good regardless of whether it was written by an LLM or a human. If the comment is bad then it's bad regardless of whether it was written by an LLM or a human. Thryduulf (talk) 20:04, 4 December 2024 (UTC)
- And see what ChatGPT itself had to say about that idea, at #ChaptGPT_agrees above. EEng 22:25, 4 December 2024 (UTC)
- What if LLM-users just had to note that a given comment was LLM-generated? JoelleJay (talk) 19:01, 4 December 2024 (UTC)
- Oppose per above. As Rhododendrites points out, detection of LLM-generated content is not foolproof and even when detection is accurate, such a practice would be unfair for non-native English speakers who rely on LLMs to polish their work. Additionally, we evaluate contributions based on their substance, not by the identity and social capital of the author, so using LLMs should not be seen as inherently inferior to wholly human writing—are ChatGPT's arguments ipso facto less than a human's? If so, why?
- DE already addresses substandard contributions, whether due to lack of competence or misuse of AI, so a separate policy targeting LLMs is unnecessary. Sincerely, Dilettante 21:14, 4 December 2024 (UTC)
- Support a broad bar against undisclosed LLM-generated comments and even a policy that undisclosed LLM-generated comments could be sanctionable, in addition to struck through / redacted / ignored; people using them for accessibility / translation reasons could just disclose that somewhere (even on their user page would be fine, as long as they're all right with some scrutiny as to whether they're actually using it for a legitimate purpose.) The fact is that LLM comments raise significant risk of abuse, and often the fact that a comment is clearly LLM-generated is often going to be the only evidence of that abuse. I wouldn't be opposed to a more narrowly-tailored ban on using LLMs in any sort of automated way, but I feel a broader ban may be the only practical way to confront the problem. That said, I'd oppose the use of tools to detect LLM-comments, at least as the primary evidence; those tools are themselves unreliable LLM things. It should rest more on WP:DUCK issues and behavioral patterns that make it clear that someone is abusing LLMs. --Aquillion (talk) 22:08, 4 December 2024 (UTC)
Support per reasons discussed above; something generated by an LLM is not truly the editor's opinion. On an unrelated note, have we seen any LLM-powered unapproved bots come in and do things like POV-pushing and spam page creation without human intervention? If we haven't, I think it's only a matter of time. Passengerpigeon (talk) 23:23, 4 December 2024 (UTC)
- Weak oppose in the sense that I don't think all LLM discussion text should be deleted. There are at least a few ESL users who use LLM's for assistance but try to check the results as best they can before posting, and I don't think their comments should be removed indiscriminately. What I do support (although not as a formal WP:PAG) is being much more liberal in hatting LLM comments when the prompter has failed to prevent WP:WALLOFTEXT/irrelevant/incomprehensible output than we maybe would for human-generated text of that nature. Mach61 03:05, 5 December 2024 (UTC)
- Oppose Any comments made by any editors are of their own responsibility and representing their own chosen opinions to hit the Publish Changes button on. If that comment was made by an LLM, then whatever it says is something the editor supports. I see no reason whatsoever to collapse anything claimed to be made by an LLM (whose detectors are 100% not reliable in the first place). If the comment being made is irrelevant to the discussion, then hatting it is already something covered by policy in the first place. This does make me want to start my comments with "As a large language model trained by OpenAI" though just to mess with people trying to push these sorts of policy discussions. SilverserenC 05:29, 5 December 2024 (UTC)
- Or, as ChatGPT puts it,
Why banning LLM usage in comments would be detrimental, a ChatGPT treatise
|
---|
|
- I'm honestly a bit impressed with the little guy. SilverserenC 05:39, 5 December 2024 (UTC)
I wonder, if there any wiki-volunteers, who have appeals experience, and who would be willing to stand up for the Neutral Point of View Pillar of Wikipedia.
I was banned from editing a specific topic after I stood up for WP:NPV . I do not really care much about the topic, but I care about Wiki-Policies, and I feel compelled to defend WP:NPV , when it is violated by wiki-administrators. Usually, when you go to a court/appeal court in the USA, you can get a free counselor, who helps you with the process. I wonder, if there any wiki-volunteers, who have appeals experience, and who would be willing to stand up for the 2nd of the Five Pillars - Neutral Point of View.Walter Tau (talk) 23:16, 4 December 2024 (UTC)
A short description of the case can be found here: https://en.wikipedia.org/w/index.php?title=Talk:Russian_invasion_of_Ukraine&action=edit§ion=6 — Preceding unsigned comment added by Walter Tau (talk • contribs) Analysis of the causes and results of the Russo-Ukrainian War by [[Political science| political scientists I claim, that the article as written violates Wikipedia:Neutral point of view policy= means representing fairly, proportionately, and, as far as possible, without editorial bias, ALL the significant views that have been published by reliable sources on a topic. Please note, that I do not insist on adding anything about Douglas Macgregor's and Scott Ritter's views (although I support others, if they want to write about them), but I cannot disregard John Mearsheimer, Stephen Walt and several other political scientists. I shall start with addressing the statement by Manyareasexpert on 2024-11-26T10:35:23 : “undo back to consensus version - objections raised in talk, edit war”. Let’s talk about the consensus first. Here is a citation from the Talk Page for Russian invasion of Ukraine on ca. 31 October 2024 (UTC): — Preceding unsigned comment added by Walter Tau (talk • contribs) 19:39, December 4, 2024 (UTC)
|
Technical
Extra letter "R" between C and D in category listing
See Category:All portals. The list first shows portals starting with 0-9, then starting with A, B, C (including things not starting with C, but with a sortkey starting with a C), then continues through the alphabet with R, D, E, ..., P, Q, R, S, ... What is this extra letter "R" between C and D?
The issue was reported by User:JoeNMLC at Wikipedia_talk:WikiProject_Portals#Curious_about_"Portal_category_list" but this looks like it could use some wider attention. —Kusma (talk) 11:00, 26 November 2024 (UTC)
- Fixed with forcing update of the category member by removing/readding to the category. — xaosflux Talk 11:33, 26 November 2024 (UTC)
- Thanks! So it was some kind of database hiccup? —Kusma (talk) 11:58, 26 November 2024 (UTC)
- It looks like a hiccup or MediaWiki bug I haven't seen before. The Internet Archive shows [8] the issue 19 September with an R heading between the C and D headings. Special:ExpandTemplates shows Portal:Reformed Christianity just adds a normal
[[Category:All portals]]
with no sortkey and no DEFAULTSORT. It's added by a template but even if the template had different code at the time, it should not be possible to create an R heading between C and D on a category page. The Internet Archive shows a normal Latin letter R and not some special Unicode character. PrimeHunter (talk) 12:11, 26 November 2024 (UTC) - Here is HTML source from the Internet Archive:
<li><a href="/web/20240919122212/https://en.wikipedia.org/wiki/Portal:Czech_Republic" title="Portal:Czech Republic">Portal:Czech Republic</a></li></ul></div><div class="mw-category-group"><h3>R</h3> <ul><li><a href="/web/20240919122212/https://en.wikipedia.org/wiki/Portal:Reformed_Christianity" title="Portal:Reformed Christianity">Portal:Reformed Christianity</a></li></ul></div><div class="mw-category-group"><h3>D</h3> <ul><li><a href="/web/20240919122212/https://en.wikipedia.org/wiki/Portal:Delaware" title="Portal:Delaware">Portal:Delaware</a></li>
- It looks as you would expect if R was actually a letter betwen C and D and there was only one portal starting with R. The category collation system determining how to sort characters is sometimes changed and can be set differently for different wikis. Maybe this page was cached in the middle of a change or accidental setting. PrimeHunter (talk) 12:23, 26 November 2024 (UTC)
- Done - Thank you! JoeNMLC (talk) 17:01, 29 November 2024 (UTC)
- It looks like a hiccup or MediaWiki bug I haven't seen before. The Internet Archive shows [8] the issue 19 September with an R heading between the C and D headings. Special:ExpandTemplates shows Portal:Reformed Christianity just adds a normal
- Thanks! So it was some kind of database hiccup? —Kusma (talk) 11:58, 26 November 2024 (UTC)
Standard parameter name for Wikidata IDs
Some time ago, we standardised large numbers of templates so that they all used the same parameter names for the same thing; for example |birth_date=
instead of |birth-date=
, |birthdate=
, |birth=
, |dob=
, etc.
I now find that we have a number of parameter names for a Wikidata item about a subject, for example:
- {{Authority control}} -
|qid=
- {{Interlanguage link}} -
|WD=
- {{Taxonbar}} -
|from=
This causes confusion for editors who use more than one of these templates, on a regular or occasional basis.
I propose that we standardise these to |qid=
, while keeping existing names as aliases for backwards compatibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:44, 26 November 2024 (UTC)
- We also standardized on
|coordinates=
in infoboxes a few years ago, which was a nice improvement.|qid=
makes the most sense to me for this purpose. I get 227 hits in template space for{qid|
, only 10 hits for{WD|
, and 66 hits for{from|
(most of which are not Wikidata-related). – Jonesey95 (talk) 17:08, 26 November 2024 (UTC)
- Support alias
|qid=
. -- Michael Bednarek (talk) 03:40, 29 November 2024 (UTC)
Incorrect diff description when edits in between are suppressed or revision deleted
I know I should just make an account to report stuff, but instead I just want to ask, is this bug something anyone would even care about fixing?:
- On Special:Diff/1258722312/1258757481 it says the obviously wrong message
One intermediate revision by 22 users not shown
- If I don't include the one revision that is not suppressed in between, then it just says nothing, even though there are 37 (I think?) revisions in between.
I chose a suppressed one as the example, but it happens with revdels too, though maybe not if you are an admin. – 2804:F1...6D:D079 (::/32) (talk) 00:53, 29 November 2024 (UTC)
- I doubt any devs are going to get to work on that one right away, but sure go file a WP:BUG if you'd like. Problem statement seems to be that when there are deleted versions, inaccurate counts are passed to
diff-multi-otherusers
. — xaosflux Talk 02:32, 29 November 2024 (UTC) - It's an interesting bug. If you look at this range of edits in the page history: [9] you can see more clearly that only the content of the revisions has been hidden, but not their authors. We might be querying the data for this message slightly incorrectly. As a dev, I'd be curious enough to look into why this happens, even if it turns out to be too complicated for a quick fix. Also, I found a Phabricator report that sounds quite similar to this problem: T277920. Matma Rex talk 08:09, 29 November 2024 (UTC)
- I figured out why it happens: T277920#10368811 but it is indeed a bit tricky to fix, and it will probably stay unfixed for now, unless someone volunteers to implement it. Matma Rex talk 22:55, 29 November 2024 (UTC)
Discussion at Wikipedia talk:Reliable sources/Perennial sources § Amendments needed to the transclusion splitting plan
You are invited to join the discussion at Wikipedia talk:Reliable sources/Perennial sources § Amendments needed to the transclusion splitting plan. Not sure who to notify, but I'm not confident in putting another merge banner onto the page, and this does involve technical. Aaron Liu (talk) 02:15, 29 November 2024 (UTC)
Max lag on Enwiki API requests
This is happening again ("13926.578336 seconds lagged"). Previously reported Wikipedia:Village_pump_(technical)/Archive_216#Server_lag responded by User:Taavi. Same problem with a broken replica? -- GreenC 05:11, 29 November 2024 (UTC)
- Works for me. * Pppery * it has begun... 05:34, 29 November 2024 (UTC)
- Still an issue? Taavi (talk!) 06:27, 29 November 2024 (UTC)
- It appears to happen intermittently almost every week nowadays. – SD0001 (talk) 13:43, 29 November 2024 (UTC)
Menu for new topic missing
For me it's normally a + sign. Doug Weller talk 14:00, 29 November 2024 (UTC)
- It is working fine for me atleast The AP (talk) 15:53, 29 November 2024 (UTC)
After Login, goes to WP home page
Greetings, Recently I noticed that after 1. Log out; 2. Log In; 3. Browser now goes to Wikipedia home page instead of previously "remembered" page. Usually it was my Watchlist. Not a major concern, just curious of this change. Regards, JoeNMLC (talk) 17:06, 29 November 2024 (UTC)
- This is likely unintentional change. Reported at phab:T381216. – Ammarpad (talk) 09:34, 1 December 2024 (UTC)
Wikipedia:Contents/Outlines
Can anyone work out why Wikipedia:Contents/Outlines has so much white text on a light green background, to the extent that the text is virtually invisible. Nthep (talk) 15:05, 30 November 2024 (UTC)
- Pinging @TheDJ:, is this in any way related to your changes to Wikipedia:Contents/styles.css and dark mode? Nthep (talk) 15:10, 30 November 2024 (UTC)
- That change would have caused it, yes. Headers particularly have some opinionated CSS that you have to take some effort to override. It's not hard to fix, I will look at it in the morning in TheDJ doesn't beat me to it. Izno (talk) 06:40, 1 December 2024 (UTC)
- This should be fixed ish now. Izno (talk) 19:11, 1 December 2024 (UTC)
- Thanks. Nthep (talk) 19:24, 1 December 2024 (UTC)
- This should be fixed ish now. Izno (talk) 19:11, 1 December 2024 (UTC)
- That change would have caused it, yes. Headers particularly have some opinionated CSS that you have to take some effort to override. It's not hard to fix, I will look at it in the morning in TheDJ doesn't beat me to it. Izno (talk) 06:40, 1 December 2024 (UTC)
Wikispecies Template/ Module assistance needed
On Wikispecies, we are told (at species:Wikispecies:Village Pump#Switching to the Vector 2022 skin: the final date):
Module:Authority control uses the deprecated toccolours class. A navbox class with some styling should be used instead. This is how they did it on English Wikipedia. For more context: phab:T314254.
Wikispecies is a small project; can someone assist there, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 30 November 2024 (UTC)
- Wikipedia:Village pump (technical)/Archive 202#class="toccolours" does not render formatting in Vector 2022 suggests that the magic incantation is "Pinging @Izno and TheDJ". WhatamIdoing (talk) 23:32, 30 November 2024 (UTC)
- I can look at it in the morning. The good news is that there aren't many uses if you exclude user and user talk pages. (And still not that many even including those.) In most cases the easiest solution is to swap to
wikitable
, but that may not be appropriate for all pages. Izno (talk) 06:45, 1 December 2024 (UTC)- I've cleaned out the remaining uses of necessary toccolours on Wikispecies. You may review my edits there at your leisure. Izno (talk) 05:26, 2 December 2024 (UTC)
- Seems to be working well. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:30, 2 December 2024 (UTC)
- I've cleaned out the remaining uses of necessary toccolours on Wikispecies. You may review my edits there at your leisure. Izno (talk) 05:26, 2 December 2024 (UTC)
- I can look at it in the morning. The good news is that there aren't many uses if you exclude user and user talk pages. (And still not that many even including those.) In most cases the easiest solution is to swap to
Faulty interwiki formula
ProofWiki has altered its URL structure (dropping the 'www') without preserving a redirect such that the current interwiki format (e.g., proofwiki:Definition:Set) doesn't work. Can this be changed from Wikipedia, or should I go to phab:? Tule-hog (talk) 21:59, 30 November 2024 (UTC)
- @Tule-hog These are defined at Meta:Interwiki map, updates can be requested on the talk page. 86.23.109.101 (talk) 22:40, 30 November 2024 (UTC)
Simple math in template
This change throws an ugly red error message in the template's page, but it works when the template is actually used. I assume that there is something obvious and simple that I've missed, and I would appreciate diffs to the fixes or other advice.
Secondly, what I'd like to accomplish is a bit more ambitious. I'm open to being told to give it up. But where we have this now:
Revenue | 12345 (in 2023) |
---|---|
Expenses | 13399 (108.5% of revenue in 2023) |
I'd like it to be able to handle currency formatting ("$12,345"). This might require a bot/AWB run to convert all of the manually written |revenue $12.3 million
to |revenue=12300000 |currency=$ |revenue-note=<ref>source goes here</ref>
, which will then be displayed as $12.3 million[1]
to the reader.
I want to highlight overspending in red ("108.5% of revenue" or "8.5% excess") and underspending in green. The usual rule of thumb in non-profit land is that spending 90% of revenue is ideal, and that both overspending and significant underspending are bad. So perhaps <80% is amber or (uncolored), 80–100% is green, and >101% is red.
I also want to introduce a third field, "Reserves" with an Operating reserve ratio calculated from the existing Expenses field. This would highlight <6 months in red, 6–12 months in amber, 12–24 months in green, and >24 in purple. (These are the generally recommended ranges for most non-profit organizations. To put this in context, private colleges with an operating reserve ratio of less than 12 months are at risk of joining the growing list in Category:Defunct universities and colleges in the United States, and if it's <6 months, that could happen soon and with no warning.)
What do you think? WhatamIdoing (talk) 23:21, 30 November 2024 (UTC)
- I fixed the first issue (including issues you didn't know).[10] PrimeHunter (talk) 00:00, 1 December 2024 (UTC)
- Thank you! WhatamIdoing (talk) 00:45, 1 December 2024 (UTC)
- Either a module or an AWB run will be required for what you want, yes. The AWB run will be easier probably. I thought we had a template that handles currency already though? (Or perhaps we don't and that's what has caused so much grief with
{{formatnum:}}
). Izno (talk) 06:49, 1 December 2024 (UTC)- I don't know if we have something that already handles it. WhatamIdoing (talk) 06:38, 2 December 2024 (UTC)
- @WhatamIdoing {{Currency}} or {{Format price}}? The currency template converts values written in words to comma or space separated numbers, format price converts numerical inputs to words. 86.23.109.101 (talk) 11:48, 2 December 2024 (UTC)
- I don't know if we have something that already handles it. WhatamIdoing (talk) 06:38, 2 December 2024 (UTC)
Rangeblock tool
Hello. Following this Teahouse thread in which it was revealed Fastily's departure from the project also resulted in the shutdown of their Toolforge services (thus causing a bit of confusion), DreamRimmer has created this tool that supersedes Fastily's tool over (seems close enough). However, Mediawiki:Blocklogtext still has the link to Fastily's now-defunct tool instead, which could cause some aforementioned confusion when some people wish to calculate rangeblocks. Therefore, I recommend changing [[:toolforge:ip-range-calc]]
to [[:toolforge:galaxybots/iprangecalculator]]
on the aforementioned interface page. Thanks. — 3PPYB6 (T / C / L) — 06:26, 1 December 2024 (UTC)
- You can use {{edit protected}} on the talk page in the future. Izno (talk) 06:30, 1 December 2024 (UTC)
- @Izno – I do realize that, and I've done that before, but the Editnotice explicitly stated that requests could be brought here because the MediaWiki talk namespace is generally not monitored very actively. Thank you so much for answering this quickly though! — 3PPYB6 (T / C / L) — 06:33, 1 December 2024 (UTC)
- Yeah, I think that edit notice is more about talk page posting in general rather than specific edit requests; simple/straightforward requests are taken care of pretty quickly from tracking on User:AnomieBOT/PERTable et al. Izno (talk) 06:35, 1 December 2024 (UTC)
- @Izno – I do realize that, and I've done that before, but the Editnotice explicitly stated that requests could be brought here because the MediaWiki talk namespace is generally not monitored very actively. Thank you so much for answering this quickly though! — 3PPYB6 (T / C / L) — 06:33, 1 December 2024 (UTC)
I cannot work out what it is about this edit [11] that causes all references to display the error "Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value.". Shhhnotsoloud (talk) 16:56, 1 December 2024 (UTC)
- I can't reproduce the error now. It seems to be a known bug that occasionally something goes wrong in CS1 rendering and that happens. * Pppery * it has begun... 17:30, 1 December 2024 (UTC)
- @Pppery There was a previous discussion about this here: [12]. As best I can tell the issue is that
mw.ext.data.get()
has an undocumented "feature" in that it can sometimes returnfalse
instead of returning the data table? 86.23.109.101 (talk) 18:22, 1 December 2024 (UTC)- This is in the process of being fixed, see Help talk:Citation Style 1#spurious errors when fetching identifier limit data from commons. -- LCU ActivelyDisinterested «@» °∆t° 20:01, 2 December 2024 (UTC)
- @Pppery There was a previous discussion about this here: [12]. As best I can tell the issue is that
Weird template disambiguation link problem.
This is crazy one. The category tree for Category:Introductions by year causes a hatnote to appear on the category page with text along the lines of:
- This category is for introductions in the year XXXX.
The problem is that introductions links to a disambiguation page. Through arduous layers of substitution, I have isolated the problematic string to:
- This [[Help:Categories|category]] is for {{#invoke:ustring|gsub|\{{#if:1|'''[[{{#invoke:String|replace|{{PAGENAME}}|^%d%d%d%d (%a.-)$|%1|1|false}}]]''' in the '''year XXXX'''}}|%.$|}}.
Apparently, this causes the invoked string to link to the category name minus the year (so Category:1649 introductions gets reduced in the string to introductions). I have no idea how to solve this so that rather than linking to the disambiguation page, it links to a relevant meaning of "introduction". Which meaning that would be is a separate question; for now my concern is how does the linked term become editable at all. Cheers! BD2412 T 20:50, 1 December 2024 (UTC)
Which meaning that would be is a separate question
probably the main question. If you know which link it should go to, Category:Introductions can be moved per WP:C2D as will its sub-categories, which will cause the template to work correctly. Gonnym (talk) 20:56, 1 December 2024 (UTC)- On further review, the category itself may indeed be somewhat problematic, as it appears to mix different kinds of introductions (of products, of ideas, of logos). Alternatively, perhaps it makes sense to create a WP:Broad concept article generally covering the concept of introduction itself. BD2412 T 21:31, 1 December 2024 (UTC)
- Okay, forget the technical solution, I have started Draft:Introduction, and will work on that this week. BD2412 T 21:43, 1 December 2024 (UTC)
- If it seems hard to adapt a template to give a wanted output in a special case then a possible but not ideal alternative is to just change the output at the call with {{replace}}. In this case, {{YYYY introductions category header}} could for example change
{{YYYY foos category header|beginnings}}
to{{replace|{{YYYY foos category header|beginnings}}|'''[[introductions]]'''|introductions}}
, if there is no suitable link target and we don't want a link at all. The replacement may fail later if a change means that the exact output no longer says'''[[introductions]]'''
. PrimeHunter (talk) 23:03, 1 December 2024 (UTC)
- If it seems hard to adapt a template to give a wanted output in a special case then a possible but not ideal alternative is to just change the output at the call with {{replace}}. In this case, {{YYYY introductions category header}} could for example change
Some issues in dark 2022 theme
Hi. I have been read this page Frank Grillo and see there yellow-white is including in template's background. Please fix it in dark theme. VollyM (talk) 23:00, 1 December 2024 (UTC)
- Template:Pending is the culprit, it does not support dark theme. Also see Template:Partial/styles.css. Snævar (talk) 01:01, 2 December 2024 (UTC)
- {{Pending}} is working fine for me in dark mode; I see black text on a yellow background in the cell containing "Hard Matter". Please be more specific about the problem description, and maybe post a screen shot. – Jonesey95 (talk) 01:46, 2 December 2024 (UTC)
- I see blue text on a black background for "Hard Matter", in both Vector2010 and Vector2022. Odd. CMD (talk) 02:38, 2 December 2024 (UTC)
- @Jonesey95 black text on yellow background in dark theme.
- https://imgur.com/a/oVpwbmR VollyM (talk) 10:10, 2 December 2024 (UTC)
- I see the same black on yellow that shows in VollyM's screen shot. It looks fine. As for Chipmunkdavis's blue on black, please make sure that you are logged out when you check on the colors. If you are still seeing blue on black, let us know what browser you are using. – Jonesey95 (talk) 13:53, 2 December 2024 (UTC)
- How do I use dark theme when logged out? CMD (talk) 14:22, 2 December 2024 (UTC)
- For me, there is a sidebar on the right side with radio buttons under the header "Color (beta)". If you don't see it, look under the confusing "glasses" icon at the upper right, next to the "Donate" link. For me, an easy way to check how things look when I am not logged in is to open a different web browser (Safari, Brave, Chrome, etc.) than I usually use for editing. – Jonesey95 (talk) 16:18, 2 December 2024 (UTC)
- @Chipmunkdavis: Some browsers provide a "private browsing" feature, or similar. In Firefox, right-click a link and select "Open Link in New Private Window". It opens a new instance of the browser and loads the page reached through the right-clicked link, but does not send any cookies. The effect of this is that if the right-clicked link is a Wikimedia page, it's loaded exactly as for a logged-out user - Vector 2022 and all that bother. Important: if you intend to use the "Restore Previous Session" feature when opening Firefox at the start of the next day's netsurfing, make sure that you close the new private window before closing the main window, otherwise, the next time you open Firefox, and use the "Restore Previous Session" feature, it'll restore that private window and not the main one. --Redrose64 🌹 (talk) 20:53, 2 December 2024 (UTC)
- How do I use dark theme when logged out? CMD (talk) 14:22, 2 December 2024 (UTC)
- Back on track, this is about the tables in Frank Grillo#Filmography. So you have a table that uses template:pending film and template:pending series, which in turn both use template:pending. Making the background color change with dark mode pretty much requires templatestyles. Adding a templatestyles tag to any of the templates will not work, because it is a part of a table. Adding a templatestyles tag to the page itself would require an edit to all of the pages these template use, is probably a Manual of Style error and is ugly. Other options or bite the bullet and ask for a bot run? Snævar (talk) 14:48, 3 December 2024 (UTC)
- Also, I am letting someone else fix this. Snævar (talk) 11:23, 4 December 2024 (UTC)
- I see the same black on yellow that shows in VollyM's screen shot. It looks fine. As for Chipmunkdavis's blue on black, please make sure that you are logged out when you check on the colors. If you are still seeing blue on black, let us know what browser you are using. – Jonesey95 (talk) 13:53, 2 December 2024 (UTC)
- {{Pending}} is working fine for me in dark mode; I see black text on a yellow background in the cell containing "Hard Matter". Please be more specific about the problem description, and maybe post a screen shot. – Jonesey95 (talk) 01:46, 2 December 2024 (UTC)
This script I created seems to be drifting more and more and not working on newer formats of XfD pages, and I don't seem to be using it as much, so I want to know if someone might be up for forking the (six) scripts and making it better. It might need a complete rewrite. Thanks. Awesome Aasim 19:05, 2 December 2024 (UTC)
trimming watchlist not working
So, I realized I have way, way too many things on my watchlist. I spent an hour last night going through it and removing a lot of it, but it when I hit the "remove pages button" it just sits there for a minute and then reloads the list, complete with the same checked items. I'm assuming I was trying to do too much at once, just wondering if anyone knows exactly where the line is as I don't want to waste too much time on this. (I'm aware I could also edit the raw watchlist but that seems even more tedious.) Just Step Sideways from this world ..... today 21:52, 2 December 2024 (UTC)
- There's no exact line, no. I would expect most database operations to succeed if you're modifying fewer than 500 things, but if it was less than that you can try stepping it down by some reasonable number. Izno (talk) 22:39, 2 December 2024 (UTC)
- When I tried to do it all at once it was for sure well over five hundred items. I clearly haven't done a serious trim since timed watchlisting became a thing however long ago that was, there's old ArbCom cases on there, old afds, at least fifty usernames I blocked for having "poop" in them, and so on. I'll try going a little slower I guess. Just Step Sideways from this world ..... today 22:52, 2 December 2024 (UTC)
- I use Special:EditWatchlist/raw. --Redrose64 🌹 (talk) 23:49, 2 December 2024 (UTC)
- Yeah for my recent watchlist purge that many people in this thread would know about, I edited my raw watchlist to remove 1,173 pages and had no problem. I thought using the check-box interface would be more tedious and error-prone (also pages that big don't work too well on my setup). I didn't remove inactive/barely active pages/old user pages though. And it took way more than an hour for me; more like seven (I know this because I have a chat log about it).Graham87 (talk) 04:30, 3 December 2024 (UTC)
- Also the raw watchlist is ordered a bit weirdly. From personal experience it seems to be ordered alphabetically for pages added to the watchlist before 2017, and then by the date the page was added after then. Graham87 (talk) 04:39, 3 December 2024 (UTC)
- I noticed that happening at a time when I had about 24,000 pages in my watchlist. Since I trimmed it to about 16,000 it behaves normally - primary sort is by namespace (main, talk, user, user talk, etc.) secondary sort is alphabetical. --Redrose64 🌹 (talk) 13:21, 3 December 2024 (UTC)
- Even my previous watchlist had 3,247 pages on it (but as I said before, a lot of the pages on it now are for all intents and purposes inactive). Graham87 (talk) 14:49, 3 December 2024 (UTC)
- I noticed that happening at a time when I had about 24,000 pages in my watchlist. Since I trimmed it to about 16,000 it behaves normally - primary sort is by namespace (main, talk, user, user talk, etc.) secondary sort is alphabetical. --Redrose64 🌹 (talk) 13:21, 3 December 2024 (UTC)
- Also the raw watchlist is ordered a bit weirdly. From personal experience it seems to be ordered alphabetically for pages added to the watchlist before 2017, and then by the date the page was added after then. Graham87 (talk) 04:39, 3 December 2024 (UTC)
- Yeah for my recent watchlist purge that many people in this thread would know about, I edited my raw watchlist to remove 1,173 pages and had no problem. I thought using the check-box interface would be more tedious and error-prone (also pages that big don't work too well on my setup). I didn't remove inactive/barely active pages/old user pages though. And it took way more than an hour for me; more like seven (I know this because I have a chat log about it).Graham87 (talk) 04:30, 3 December 2024 (UTC)
- I use Special:EditWatchlist/raw. --Redrose64 🌹 (talk) 23:49, 2 December 2024 (UTC)
- When I tried to do it all at once it was for sure well over five hundred items. I clearly haven't done a serious trim since timed watchlisting became a thing however long ago that was, there's old ArbCom cases on there, old afds, at least fifty usernames I blocked for having "poop" in them, and so on. I'll try going a little slower I guess. Just Step Sideways from this world ..... today 22:52, 2 December 2024 (UTC)
- @Just Step Sideways I'll add a plug for User:Ahecht/Scripts/watchlistcleaner which can help with removing a lot of the cruft. If you use any of the "slow" options, you might need to let it run overnight if you have a 5-figure watchlist page count. --Ahecht (TALK
PAGE) 15:39, 3 December 2024 (UTC)- It's at about five thousand currently, I've managed to clear it out some already but I'd like to remove pretty much all the user/talk pages and start over on that front as half of it is people who were blocked for username violations years ago and most of the other half is "why did I have this person's page watched?" Just Step Sideways from this world ..... today 20:37, 3 December 2024 (UTC)
- If you're like me, you'll spot somebody doing something dubious, go to their user talk page only to find that somebody else has messaged them three minutes ago, and watch the page anyway in case the situation escalates to the point where stronger action is called for. First user stops misbehaving, then six months later another post appears telling them that a draft they started hasn't been touched and is liable for speedy deletion under WP:G13. You check their contribs, and find that not only did they stop misbehaving, they left entirely. --Redrose64 🌹 (talk) 23:42, 3 December 2024 (UTC)
- If a change actually pops up when looking at my list, I'll go see if I made any of the last hundred edits, or posted there in the past year, if neither of those is true I unwatch, but that's a very slow way to narrow it down. Just Step Sideways from this world ..... today 03:08, 4 December 2024 (UTC)
- If you're like me, you'll spot somebody doing something dubious, go to their user talk page only to find that somebody else has messaged them three minutes ago, and watch the page anyway in case the situation escalates to the point where stronger action is called for. First user stops misbehaving, then six months later another post appears telling them that a draft they started hasn't been touched and is liable for speedy deletion under WP:G13. You check their contribs, and find that not only did they stop misbehaving, they left entirely. --Redrose64 🌹 (talk) 23:42, 3 December 2024 (UTC)
- It's at about five thousand currently, I've managed to clear it out some already but I'd like to remove pretty much all the user/talk pages and start over on that front as half of it is people who were blocked for username violations years ago and most of the other half is "why did I have this person's page watched?" Just Step Sideways from this world ..... today 20:37, 3 December 2024 (UTC)
Tech News: 2024-49
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
- Two new parser functions were added this week. The
{{#interwikilink}}
function adds an interwiki link and the{{#interlanguagelink}}
function adds an interlanguage link. These parser functions are useful on wikis where namespaces conflict with interwiki prefixes. For example, links beginning withMOS:
on English Wikipedia conflict with themos
language code prefix of Mooré Wikipedia. - Starting this week, Wikimedia wikis no longer support connections using old RSA-based HTTPS certificates, specifically rsa-2048. This change is to improve security for all users. Some older, unsupported browser or smartphone devices will be unable to connect; Instead, they will display a connectivity error. See the HTTPS Browser Recommendations page for more-detailed information. All modern operating systems and browsers are always able to reach Wikimedia projects. [13]
- Starting December 16, Flow/Structured Discussions pages will be automatically archived and set to read-only at the following wikis: arwiki, cawiki, frwiki, mediawikiwiki, orwiki, wawiki, wawiktionary, wikidatawiki, zhwiki. This is done as part of StructuredDiscussions deprecation work. If you need any assistance to archive your page in advance, please contact Trizek (WMF). [14]
- This month the Chart extension was deployed to production and is now available on Commons and Testwiki. With the security review complete, pilot wiki deployment is expected to start in the first week of December. You can see a working version on Testwiki and read the November project update for more details.
- View all 23 community-submitted tasks that were resolved last week. For example, a bug with the "Download as PDF" system was fixed. [15]
Updates for technical contributors
- In late February, temporary accounts will be rolled out on at least 10 large wikis. This deployment will have a significant effect on the community-maintained code. This is about Toolforge tools, bots, gadgets, and user scripts that use IP address data or that are available for logged-out users. The Trust and Safety Product team wants to identify this code, monitor it, and assist in updating it ahead of the deployment to minimize disruption to workflows. The team asks technical editors and volunteer developers to help identify such tools by adding them to this list. In addition, review the updated documentation to learn how to adjust the tools. Join the discussions on the project talk page or in the dedicated thread on the Wikimedia Community Discord server (in English) for support and to share feedback.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 22:19, 2 December 2024 (UTC)
patents.com lapsed
patents.com lapsed and is for sale. Searching for insource:"patents.com" shows 26 pages affected. {Cite patent|...} was not an instant fix for the one I rescued, so I linked to the Google Patent page. -A876 (talk) 01:49, 3 December 2024 (UTC)
- You are looking for WP:URLREQ. Izno (talk) 01:56, 3 December 2024 (UTC)
- Thanks. I wondered where to look. Wikipedia:Link rot/URL change requests -A876 (talk) 01:11, 5 December 2024 (UTC)
eparticle action in log?
Any idea what this log entry is about? It corresponds to https://quarry.wmcloud.org/query/88408. RoySmith (talk) 17:33, 3 December 2024 (UTC)
- The former education program extension, which was uninstalled years ago. * Pppery * it has begun... 18:00, 3 December 2024 (UTC)
- They were adding the target article to their course list, in the uninstalled Education Program extension. – Ammarpad (talk) 18:06, 3 December 2024 (UTC)
Incorrect robots meta tag on live article
The article "It's Coming (film)" has a "noindex,nofollow" robots meta tag despite being a live article, not a draft. This is preventing Google indexing. Could someone please help remove this incorrect tag? The article is at It's Coming (film). Thank you. Stan1900 (talk) 21:13, 3 December 2024 (UTC)
- These are being appropriately applied. The page will not be indexed until new page patroller approves it. Izno (talk) 21:29, 3 December 2024 (UTC)
- Thank you for the information. Could you tell me the typical timeframe for new page patrol review? Also, would resolving the paid editing template discussion help speed up this process? Stan1900 (talk) 21:39, 3 December 2024 (UTC)
- Why are you concerned with when Google indexes it? RoySmith (talk) 23:28, 3 December 2024 (UTC)
- Thank you for the response. The article documents a recent release, and I want to ensure that accurate information is properly indexed and visible for readers and contributors seeking details about the film. Any guidance on how to proceed would be greatly appreciated. Stan1900 (talk) 23:49, 3 December 2024 (UTC)
- My guidance would be to concentrate on writing good articles, let the new page patrollers do their jobs, and don't worry about what Google does. RoySmith-Mobile (talk) 13:37, 4 December 2024 (UTC)
- @Stan1900: Be patient. --Redrose64 🌹 (talk) 21:18, 4 December 2024 (UTC)
- Thank you for the response. The article documents a recent release, and I want to ensure that accurate information is properly indexed and visible for readers and contributors seeking details about the film. Any guidance on how to proceed would be greatly appreciated. Stan1900 (talk) 23:49, 3 December 2024 (UTC)
- Why are you concerned with when Google indexes it? RoySmith (talk) 23:28, 3 December 2024 (UTC)
- Thank you for the information. Could you tell me the typical timeframe for new page patrol review? Also, would resolving the paid editing template discussion help speed up this process? Stan1900 (talk) 21:39, 3 December 2024 (UTC)
Transliteration template not accepting some Latin characters
As seen in Bashkortostan's infobox, {{Transliteration}} is throwing an error at text containing some rarer Latin characters—"transliteration text not Latin script". This example: {{transliteration|ba|Başqortostan Respublikahınıñ Dәwlәt gimnı}}
. Does anyone know why this is and if it's intentional? If not, can it be fixed? Ookap (talk) 05:56, 4 December 2024 (UTC)
- You did the literal textbook example of that error (on the help page):
For example, <text> has Cyrillic shwa (ә; U+04D9) instead of the Latin shwa (ə; U+0259).
. * Pppery * it has begun... 07:00, 4 December 2024 (UTC)- You can copy-paste the string to the text area at https://r12a.github.io/uniview/ and click the down arrow to see this. PrimeHunter (talk) 10:36, 4 December 2024 (UTC)
Determining browser page size
WP:ARTICLESIZE speaks of "browser page size". How to determine this value in Firefox? ―Mandruss ☎ 10:12, 4 December 2024 (UTC)
- Mandruss, I assume it means this? — Qwerfjkltalk 10:19, 4 December 2024 (UTC)
- I wouldn't know exactly what it means; I didn't write it. Based on my limited understanding, I'm guessing it corresponds to the number of bytes downloaded, which should correspond to the file size in one's browser cache, which is aka HTML page size. Regardless of what it means, it's one of the measures of article size deemed significant by the community, and I need to know how to determine it in Firefox. ―Mandruss ☎ 10:38, 4 December 2024 (UTC)
- Mandruss, in much the same way as on chrome. — Qwerfjkltalk 10:41, 4 December 2024 (UTC)
- Thanks. If I were a web developer, that might help. ―Mandruss ☎ 10:44, 4 December 2024 (UTC)
- WP:ARTICLESIZE mentions "browser page size" once in the lead and never refers to it again. I guess the author just wanted to clarify that the used sizes are something different. I have never seen browser page size used in Wikipedia discussions about size. I suggest you just ignore it. Anyway, in Firefox the "Tools" tab (you may need to press Alt to see the tabs) has "Page info" which includes size, but I'm not sure how it's defined. It's far smaller then the HTML file if you save it. Is it a download size for a compressed version? If I open a HTML file stored on my own computer then Firefox doesn't even show the size field. That makes sense if it's a download size and Firefox didn't download anything. PrimeHunter (talk) 12:25, 4 December 2024 (UTC)
- Neither readable prose size nor wiki markup size is a direct measure of performance impact. So I gather technology advances have rendered performance issues insignificant, at least within technical size limits imposed by the PEIS limit etc. ―Mandruss ☎ 12:37, 4 December 2024 (UTC)
- @Mandruss The WP:PEIS limit has nothing to do with browser page size. You could easily have the longest article on Wikipedia with a PEIS of 0 if it had no templates, and I have also seen very short articles that exceed the limit due to multi-level transclusions. As to your second point, I have seen several pages recently that ended up being split because users with high-end computers complained about trouble loading the page (Talk:2024 United States presidential election#Merge of international reactions list is the most recent one I can remember). --Ahecht (TALK
PAGE) 13:55, 4 December 2024 (UTC)
- @Mandruss The WP:PEIS limit has nothing to do with browser page size. You could easily have the longest article on Wikipedia with a PEIS of 0 if it had no templates, and I have also seen very short articles that exceed the limit due to multi-level transclusions. As to your second point, I have seen several pages recently that ended up being split because users with high-end computers complained about trouble loading the page (Talk:2024 United States presidential election#Merge of international reactions list is the most recent one I can remember). --Ahecht (TALK
- Neither readable prose size nor wiki markup size is a direct measure of performance impact. So I gather technology advances have rendered performance issues insignificant, at least within technical size limits imposed by the PEIS limit etc. ―Mandruss ☎ 12:37, 4 December 2024 (UTC)
- WP:ARTICLESIZE mentions "browser page size" once in the lead and never refers to it again. I guess the author just wanted to clarify that the used sizes are something different. I have never seen browser page size used in Wikipedia discussions about size. I suggest you just ignore it. Anyway, in Firefox the "Tools" tab (you may need to press Alt to see the tabs) has "Page info" which includes size, but I'm not sure how it's defined. It's far smaller then the HTML file if you save it. Is it a download size for a compressed version? If I open a HTML file stored on my own computer then Firefox doesn't even show the size field. That makes sense if it's a download size and Firefox didn't download anything. PrimeHunter (talk) 12:25, 4 December 2024 (UTC)
- Thanks. If I were a web developer, that might help. ―Mandruss ☎ 10:44, 4 December 2024 (UTC)
- Mandruss, in much the same way as on chrome. — Qwerfjkltalk 10:41, 4 December 2024 (UTC)
- Order of operations to get browser size:
- 1. Tools > Browser Tools > Web Developer tools
- 2. A thing pops up at the bottom of the screen
- 3. Select Networking in the tabs of the newly popped up thing
- 4. Visit the page you wanted to know the size of, or refresh it
- 5. The size is in the bottom left corner after the number of requests as x kB / x kB transferred. Snævar (talk) 14:08, 4 December 2024 (UTC)
- Thank you. For the current article in question, that yields 4.33 MB / 365.03 kB transferred. As a direct measure of performance impact, I'm guessing the second number is more meaningful. Agree? ―Mandruss ☎ 14:20, 4 December 2024 (UTC)
- I think the first number is more meaningful. The difference in the two numbers is just how much your browser has kept since the last visits (technical jargon: browser cache). The latter number is the first number minus this cache size. Snævar (talk) 14:46, 4 December 2024 (UTC)
- Ok. What would you call that first number in four words or less? ―Mandruss ☎ 15:52, 4 December 2024 (UTC)
- The first number is the decompressed page size, the second is the amount of data transferred, taking into account compression and cached data. I added instructions at Wikipedia:Article size#Browser page size on getting more objective versions of both numbers that bypass caching and Wikipedia preferences. --Ahecht (TALK
PAGE) 16:38, 4 December 2024 (UTC)
- I think the first number is more meaningful. The difference in the two numbers is just how much your browser has kept since the last visits (technical jargon: browser cache). The latter number is the first number minus this cache size. Snævar (talk) 14:46, 4 December 2024 (UTC)
- Thank you. For the current article in question, that yields 4.33 MB / 365.03 kB transferred. As a direct measure of performance impact, I'm guessing the second number is more meaningful. Agree? ―Mandruss ☎ 14:20, 4 December 2024 (UTC)
- I wouldn't know exactly what it means; I didn't write it. Based on my limited understanding, I'm guessing it corresponds to the number of bytes downloaded, which should correspond to the file size in one's browser cache, which is aka HTML page size. Regardless of what it means, it's one of the measures of article size deemed significant by the community, and I need to know how to determine it in Firefox. ―Mandruss ☎ 10:38, 4 December 2024 (UTC)
I am trying to work out why the post-expand include size is so high on List of public art in the City of London (1,814,737 out of 2,097,152). We are trying to do some work on the table columns, which is not possible, because everything we do exceeeds the PEIS limit. Is there a easy way to work out which templates are causing the most problem? — Martin (MSGJ · talk) 14:51, 4 December 2024 (UTC)
- @MSGJ Looks like it's the 400 uses of {{Public art/row}}. Substing them reduces the PEIS by 650kB. Also, {{coord}} has a huge PEIS footprint, which gets double-counted because it's inside {{Public art/row}} and an additional bump because that template wraps it in an
{{#if:
. Switching them out for {{#invoke:Coordinates|coord}} saves about 200kb, but it breaks {{Maplink}}. --Ahecht (TALK
PAGE) 16:52, 4 December 2024 (UTC)- @MSGJ I've fixed {{Maplink}} so that it no longer breaks when you use {{#invoke:Coordinates|coord}} --Ahecht (TALK
PAGE) 17:39, 4 December 2024 (UTC)- @MSGJ I also modified the two Navboxes at the bottom to remove about 150kb of WP:PEIS. --Ahecht (TALK
PAGE) 17:53, 4 December 2024 (UTC)
- @MSGJ I also modified the two Navboxes at the bottom to remove about 150kb of WP:PEIS. --Ahecht (TALK
- @MSGJ I've fixed {{Maplink}} so that it no longer breaks when you use {{#invoke:Coordinates|coord}} --Ahecht (TALK
Template-generated redlinked categories, again
Once again, Special:WantedCategories has thrown up a handful of redlinked categories that are being smuggled in via templates that have farmed their category generation out to modules that I can't edit, and thus I can't fix the redlinks.
- Category:FM-Class articles — This got renamed to Category:FM-Class pages a few days ago via a CFR discussion, but the {{Category class}} template is still module-farming the old category rather than the new one. Some, but not all, of the pages also have the new category directly declared on them alongside the redlink being carried in by the template, but the redlink is still present on over 500 talk pages.
- Category:Wikipedia dual licensed files with invalid licenses — This is being piggybacked by the licensing template on an image, but the template itself doesn't directly contain any text enabling that category. Obviously if this is actually wanted, then it should be created by somebody who knows how to create project categories like that (i.e. not me), but if it's unwanted then it needs to go away.
- Category:Wikt-lang template errors — Autogenerated on test page Template:Wikt-lang/testcases. Again, should be created if it's actually wanted, but needs to be kiboshed if it's not. If it's actually unwanted, then just fixing the errors on that page won't be enough, and it will need to be made impossible so that it doesn't come back in the future. And, of course, since I don't work with wikt-lang template gnomery, I'm not in a position to determine whether it's wanted or not.
So could somebody with module-editing privileges fix these, and/or create the latter two categories if they're actually wanted? Thanks. Bearcat (talk) 15:59, 4 December 2024 (UTC)
- I'll take care of the first item — Martin (MSGJ · talk) 16:08, 4 December 2024 (UTC)
Login errors
My bots are reporting an unusually large number of "Server has reported lag above the configured max_lag value of 5 value after 5 attempt(s)." errors. Is something going on? Hawkeye7 (discuss) 00:08, 5 December 2024 (UTC)
- Yes, one of the english wikipedia servers - db1240 is lagging behind at 30 minutes (was 2 hours at 2:00 GMT0), however this has happened several times over the course of last 30 days, resolving itself whithin the hour. Snævar (talk) 02:23, 5 December 2024 (UTC)
- Not a login error, but been getting a lot of "Wikimedia error" pages over the last 10 minutes.' - The Bushranger One ping only 04:25, 5 December 2024 (UTC)
- I get this when trying to preview my changes. Brilliant, because it lost what I was working on. Mellk (talk) 04:38, 5 December 2024 (UTC)
- I could barely post this message, I got system error so many times. Liz Read! Talk! 04:53, 5 December 2024 (UTC)
- I likewise encountered this around 45 minutes ago.
- Request from [my IP] via cp1106.eqiad.wmnet, ATS/9.2.6
- Error: 502, Broken pipe at 2024-12-05 04:14:39 GMT JayCubby 05:04, 5 December 2024 (UTC)
- Downdetector thinks the error is beginning to resolve itself. https://downdetector.com/status/wikipedia/ JayCubby 05:05, 5 December 2024 (UTC) See phab:T381547 for one of the bug reports
- Apparently there was a database problem (incident link)? penguinencounter2@enwiki:~/talk/contrib$ 05:09, 5 December 2024 (UTC)
- You beat me to it by a minute! JayCubby 05:11, 5 December 2024 (UTC)
- At the incident link it says, "A primary database server for cached data experienced an issue serving requests." For a 2-minute problem I would probably be satisfied with that explanation, but being unable to use any WM site, and nursing an unsaved edit, for 40 minutes (withdrawal symptoms!), I'm left wondering whether anything can be done to try to avoid it happening again. I'm also wondering what the story is with so-called unified login. I was unifiedly logged in to all the wikis, but evidently not to Phabricator, so I couldn't report the problem to Phab (not to mention here at the Pump). Login that is only partly "unified" doesn't seem very unified. How does one report a problem in these circumstances? Nurg (talk) 09:33, 5 December 2024 (UTC)
- You beat me to it by a minute! JayCubby 05:11, 5 December 2024 (UTC)
- Apparently there was a database problem (incident link)? penguinencounter2@enwiki:~/talk/contrib$ 05:09, 5 December 2024 (UTC)
- Downdetector thinks the error is beginning to resolve itself. https://downdetector.com/status/wikipedia/ JayCubby 05:05, 5 December 2024 (UTC) See phab:T381547 for one of the bug reports
- I get this when trying to preview my changes. Brilliant, because it lost what I was working on. Mellk (talk) 04:38, 5 December 2024 (UTC)
- Not a login error, but been getting a lot of "Wikimedia error" pages over the last 10 minutes.' - The Bushranger One ping only 04:25, 5 December 2024 (UTC)
The mystery of the disappearing I
So if I add this text it all works fine:
In May 2009,
and this text also works fine:
Weiss announced the opening of Yeshivat Maharat, a new school to train women as Maharat, an acronym for the Hebrew מנהיגה הלכתית רוחנית תורנית
But if I combine these two you get:
In May 2009, Weiss announced the opening of Yeshivat Maharat, a new school to train women as Maharat, an acronym for the Hebrew מנהיגה הלכתית רוחנית תורנית
This displays fine but when you edit this section you can see how the first letter (the "I" from "In May 2009") disappeared in the Wiki Editor. Latest Firefox on Win11, it works fine in Chrome on Win11.
If I, instead of the letter "I" use { then I can still see the right side of it poking out. For a real world example, check out Open Orthodoxy. Polygnotus (talk) 08:01, 5 December 2024 (UTC)
- @Polygnotus. Presumably this section, Open Orthodoxy#Ordination of women? I look at that and I just see the opening word misspelt as "IIn" where you've compensated for an "I" you can't see. This is both in the rendered text and the edit window. As you say you can partially see a character like {, I suspect this is your browser settings. That it's only happening in a paragraph which has Hebrew script in it makes me think it's to do with the right to left rendering of the Hebrew content that is causing your problem. Nthep (talk) 08:17, 5 December 2024 (UTC)
- @Nthep: (excellent name) Exactly. I got rid of the "extra" I and now, to me, it looks like this: https://i.imgur.com/aRmgXjD.png Polygnotus (talk) 08:35, 5 December 2024 (UTC)
Now I see the "I" but the "W" from Weiss disappeared. https://i.imgur.com/bXHPWuO.png Polygnotus (talk) 08:12, 5 December 2024 (UTC)
And now both have gone https://i.imgur.com/wnzTVE2.png It is not darkmode and its not ublock origin and its not Tampermonkey. It's also not my scripts. And if I Inspect Element then the problem disappears. Hmmm. Polygnotus (talk) 08:40, 5 December 2024 (UTC)
- @Polygnotus remove or nowiki out the Hebrew template in the paragraph that's giving you problems and see if it is still a problem then. Nthep (talk) 09:44, 5 December 2024 (UTC)
- I don't see your particular issue in Firefox with the default editor but right-to-left text can cause different shenanigans in browsers when it's mixed with left-to-right, including that characters are moved and keyboard arrows and Delete/Backspace suddenly move in the opposite direction. If you cannot read right-to-left scripts anyway then consider trying this in your CSS to display them left-to-right without shenanigans:
textarea {unicode-bidi: bidi-override;}
- PrimeHunter (talk) 10:29, 5 December 2024 (UTC)
Text color change after hovering on the text of appeared window of a hyperlink
Hi, for example for Tim Berners-Lee link, and if we have visited this article at least one time:
- After we hover our mouse on the link, a window appears containing his image and some text (first sentences of article)
- If we hover on the text, the color of text changes to blue.
This happens only if we have visited this article at least one time. This behavior is not reasonable, and no color change is needed in this scenario. Please inspect. Thanks, Hooman Mallahzadeh (talk) 09:42, 5 December 2024 (UTC)
Proposals
RfC: Extended confirmed pending changes (PCECP)
|
Should a new pending changes protection level - extended confirmed pending changes (hereby abbreviated as PCECP) - be added to Wikipedia? Awesome Aasim 19:58, 5 November 2024 (UTC)
Background
WP:ARBECR (from my understanding) encourages liberal use of EC protection in topic areas authorized by the community or the arbitration committee. However, some administrators refuse to protect pages unless if there is recent disruption. Extended confirmed pending changes would allow non-XCON users to propose changes for them to be approved by someone extended confirmed, and can be applied preemptively to these topic areas.
It is assumed that it is technically possible to have PCECP. That is, we can have PCECP as "[auto-accept=extended confirmed users] [review=extended confirmed users]" Right now it might not be possible to have extended confirmed users review pending changes with this protection with the current iteration of FlaggedRevs, but maybe in the future.
Survey (PCECP)
Support (PCECP)
- Support for multiple reasons: WP:ARBECR only applies to contentious topics. Correcting typos is not a contentious topic. Second, WP:ARBECR encourages the use of pending changes when protection is not used. Third, pending changes effectively serves to allow uncontroversial edit requests without needing to create a new talk page discussion. And lastly, this is within line of our protection policy, which states that protection should not be applied preemptively in most cases. Awesome Aasim 19:58, 5 November 2024 (UTC)
- Support (per... nom?) PC is the superior form of uncontroversial edit requests. Aaron Liu (talk) 20:09, 5 November 2024 (UTC)
- It's better than EC, which already restricts being the free encyclopedia more. As I've said below, the VisualEditor allows much more editing from new people than edit requesting, which forces people to use the source editor. Aaron Liu (talk) 03:52, 6 November 2024 (UTC)
- This is not somehow less or more restrictive as ECR. It's exactly the same level of protection, just implemented in a different way. I do not get the !votes from either side who either claim that this will be more restriction or more bureaucracy. I understand neither, and urge them to explain their rationales. Aaron Liu (talk) 12:32, 12 November 2024 (UTC)
- By creating a difference between what non logged-in readers (that is, the vast majority of them) see versus logged-in users, there is an extra layer of difficulty for non-confirmed and non-autoconfirmed editors, who won't see the actual page they're editing until they start the editing process. Confirmed and autoconfirmed editors may also be confused that their edits are not being seen by non-logged in readers. Because pending changes are already submitted into the linear history of the article, unwinding a rejected edit is potentially more complicated than applying successive edit requests made on the talk page. (This isn't a significant issue when there aren't many pending changes queued, which is part of the reason why one of the recommended criteria for applying pending changes protection is that the page be infrequently edited.) For better or worse, there is no deadline to process edit requests, which helps mitigate issues with merging multiple requests, but there is pressure to deal with all pending changes expediently, to reduce complications in editing. isaacl (talk) 19:54, 12 November 2024 (UTC)
- Do you think this would be fixed with "branching" (similar to GitHub branches)? In other words, instead of PC giving the latest edit, PC just gives the edit of the stable revision and when "Publish changes" is clicked it does something like put the revision in a separate namespace (something like Review:PAGENAME/#######) where ####### is the revision ID. If the edit is accepted, then that page is merged and the review deleted. If the edit is rejected the review is deleted, but can always be restored by a Pending Changes Reviewer or administrator. Awesome Aasim 21:01, 12 November 2024 (UTC)
- Technically, that would take quite a bit to implement. Aaron Liu (talk) 23:18, 12 November 2024 (UTC)
- There are a lot of programmers who struggle with branching; I'm not certain it's a great idea to make it an integral part of Wikipedia editing, at least not in a hidden, implicit manner. If an edit to an article always proceeded from the last reviewed version, editors wouldn't be able to build changes on top of their previous edits. I think at a minimum, an editor would have to be able to do the equivalent of creating a personal working branch. For example, this could be done by working on the change as a subpage of the user's page (or possibly somewhere else (perhaps in the Draft namespace?), using some standard naming hierarchy), and then submitting an edit request. That would be more like how git was designed to enable de-centralized collaboration: everyone works in their own repository, rebasing from a central repository (*), and asks an integrator to pull changes that they publish in their public repository.
- (*) Anyone's public repository can act as a central repository. It just has to be one that all the collaborators agree upon using, and thus agree with the decisions made by the integrator(s) merging changes into that repository. isaacl (talk) 23:22, 12 November 2024 (UTC)
- That makes sense. This has influenced me to amend my Q2 answer slightly, but I still support the existence of this protection and the preemptive PC protecting of low-traffic pages. (Plus, it's still not more restriction.) Aaron Liu (talk) 23:20, 12 November 2024 (UTC)
- Do you think this would be fixed with "branching" (similar to GitHub branches)? In other words, instead of PC giving the latest edit, PC just gives the edit of the stable revision and when "Publish changes" is clicked it does something like put the revision in a separate namespace (something like Review:PAGENAME/#######) where ####### is the revision ID. If the edit is accepted, then that page is merged and the review deleted. If the edit is rejected the review is deleted, but can always be restored by a Pending Changes Reviewer or administrator. Awesome Aasim 21:01, 12 November 2024 (UTC)
- By creating a difference between what non logged-in readers (that is, the vast majority of them) see versus logged-in users, there is an extra layer of difficulty for non-confirmed and non-autoconfirmed editors, who won't see the actual page they're editing until they start the editing process. Confirmed and autoconfirmed editors may also be confused that their edits are not being seen by non-logged in readers. Because pending changes are already submitted into the linear history of the article, unwinding a rejected edit is potentially more complicated than applying successive edit requests made on the talk page. (This isn't a significant issue when there aren't many pending changes queued, which is part of the reason why one of the recommended criteria for applying pending changes protection is that the page be infrequently edited.) For better or worse, there is no deadline to process edit requests, which helps mitigate issues with merging multiple requests, but there is pressure to deal with all pending changes expediently, to reduce complications in editing. isaacl (talk) 19:54, 12 November 2024 (UTC)
- Support, functionally a more efficient form of edit requests. The volume of pending changes is still low enough for this to be dealt with, and it could encourage the pending changes reviewer right to be given to more people currently reviewing edit requests, especially in contentious topics. Chaotic Enby (talk · contribs) 20:25, 5 November 2024 (UTC)
- Support having this as an option. I particularly value the effect it has on attribution (because the change gets directly attributed to the individual who wanted it, not to the editor who processed the edit request). WhatamIdoing (talk) 20:36, 5 November 2024 (UTC)
- Support: better and more direct system than preemptive extended-confirmed protection followed by edit requests on the talk page. Cremastra (u — c) 20:42, 5 November 2024 (UTC)
- Support, Pending Changes has the capacity to take on this new task. PC is much better than the edit request system for both new editors and reviewers. It also removes the downsides of slapping ECP on everything within contentious topic areas. Toadspike [Talk] 20:53, 5 November 2024 (UTC)
- I've read the opposes below and completely disagree that this would lead to more gatekeeping. The current edit request system is extremely complicated and inaccessible to new users. I've been here for half a decade and I still don't really know how it works. The edit requests we do get are a tiny fraction of the edits people want to make to ECP pages but can't. PCECP would allow them to make those edits. And many (most?) edit requests are formatted in a way that they can't be accepted (not clear what change should be made, where, based on what souce), a huge issue which would be entirely resolved by PCECP.
- The automatic EC protection of all pages in certain CTOPs is not the point of this proposal. Whether disruption is a prerequisite to protection is not altered by the existence of PCECP and has to be decided in anther RfC at another venue, or by ArbCom. PCECP is solely about expanding accessibility to editing ECP pages for new and unregistered editors, which is certainly a positive move.
- I, too, hate the PC system at dewiki, and I appreciate that Kusma mentioned it. However, what we're looking at here is lowering protection levels and reducing barriers to editing, which is the opposite of dewiki's PC barriers. Toadspike [Talk] 10:24, 16 November 2024 (UTC)
- Support (Summoned by bot): per above. C F A 💬 23:34, 5 November 2024 (UTC)
- Support : Per above. PC is always at a low or very low backlog, therefore is completely able to take this change. ~/Bunnypranav:<ping> 11:26, 6 November 2024 (UTC)
- Support: I would be happy to see it implemented. GrabUp - Talk 15:14, 6 November 2024 (UTC)
- Support Agree with JPxG's principle that it is better to "have drama on a living project than peace on a dead one," but this is far less restrictive than preemptively setting EC protection for all WP:ARBECR pages. From a new editor's perspective, they experience a delay in the positive experience of seeing their edit implemented, but as long as pending changes reviewers are equipped to minimize this delay, then this oversight seems like a net benefit. New users will get feedback from experienced editors on how to operate in Wikipedia's toughest content areas, rather than stumbling through. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 November 2024 (UTC)
- Support * Pppery * it has begun... 05:17, 11 November 2024 (UTC)
- Support Idk what it's like in other areas but in mine, of edit requests that I see, a lot, maybe even most of them are POV/not actionable/nonsense/insults so if it is already ECR only, then yea, more filtering is a good thing.Selfstudier (talk) 18:17, 11 November 2024 (UTC)
- Support assuming this is technically possible (which I'm not entirely sure it is), it seems like a good idea, and would definitely make pending changes more useful from my eyes. Zippybonzo | talk | contribs (they/them) 20:00, 12 November 2024 (UTC)
- Strong support per @JPxG:'s reasoning—I think it's wild that we're willing to close off so many articles to so many potential editors, and even incremental liberalization of editing restrictions on these articles should be welcomed. This change would substantially expand the number of potential editors by letting non-EC contributors easily suggest edits to controversial topic areas. It would be a huge win for contributions if we managed to replace most ECP locks with this new PCECP.– Closed Limelike Curves (talk) 02:07, 14 November 2024 (UTC)
- Yes, in fact, somebody read my mind here (I was thinking about this last night, though I didn't see this VP thread...) Myrealnamm (💬Let's talk · 📜My work) 21:38, 14 November 2024 (UTC)
- Support in principle. Edit requests are a really bad interface for new users; if discouraging people from editing is the goal, we've succeeded. Flagged revisions aren't the best, but they are better than edit request templates. Toadspike's reasoning hasn't been refuted. Right now, it seems like opposers aren't aware that the status quo for many Palestine-Israel related articles is ECP. Both Israeli cuisine and Palestinian cuisine are indefinitely under WP:ECP due to gastronationalist arguments about the politics of food in the Arab–Israeli conflict (a page not protected), so editors without 500/30 status cannot add information about falafels to Wikipedia.
That being said, this proposal would benefit from more detail. For example, the current edit request policy requires the proposed change to be uncontroversial and puts the burden on the proposer to show that it is uncontroversial. On the other hand, the current review policy assumes a change is correct unless it's obvious vandalism or the like, which would be a big change to the edit request workflow. Likewise, what counts as WP:INVOLVED for reviewers? Right now, there's a big firewall between editors involved in content in an area like Israel-Palestine and admins using their powers in that area. Can reviewers edit in the area and use their tools? This needs to be clarified, as it seems like editing in PIA doesn't disqualify one from answering edit requests. Chess (talk) (please mention me on reply) 21:06, 18 November 2024 (UTC)
@Chess That's true, but reviewers are also currently expected to accept and revert if the change is correct but also irky for a revert. Below, Aasim clarified that reviewers should only reject edits that fail the existing PC review guidelines plusthe current review policy assumes a change is correct unless it's obvious vandalism or the like
edits made in violation of an already well-established consensus
.
As for Involved, since there's no guidance about edit request reviewers yet either, I think that should be asked in a separate RfC. Aaron Liu (talk) 21:35, 18 November 2024 (UTC)
- Support. The number of sysops is ever decreasing and so we will need to take drastic action to ensure maintenance and vandalism prevention can keep up. Stifle (talk) 17:29, 19 November 2024 (UTC)
- Support in principle. While I understand objections from others based on the technical downsides and design of the current Flagged Revisions extension, I support making it easier for users to suggest changes with a GUI rather than a difficult-to-understand edit request template, which creates a barrier to entry. Frostly (talk) 05:24, 26 November 2024 (UTC)
- Support - It seems to be entirely preferable to ECR. It would be interesting if any current or former Arbcom members were to see it as more problematic. — Charles Stewart (talk) 04:12, 28 November 2024 (UTC)
Oppose (PCECP)
- Oppose There's a lot of history here, and I've opposed WP:FPPR/FlaggedRevs consistently since ~2011. Without reopening the old wounds over how the initial trial was implemented/ended, nothing that's happened since has changed my position. I believe that proceeding with an expansion of FlaggedRevs would be a further step away from our commitment to being the free encyclopedia that anyone can edit without actually solving any critical problems that our existing tools aren't already handling. While the proposal includes
However, some administrators refuse to protect pages unless if there is recent disruption
as a problem, I see that as a positive. In fact that's the entire point; protection should be preventative and there should be evidence of recent disruption. If a page is experiencing disruption, protection can handle it. If not, there's no need to limit anyone's ability to edit. The WordsmithTalk to me 03:45, 6 November 2024 (UTC)- The Wordsmith, regarding "
However, some administrators refuse to protect pages unless if there is recent disruption
as a problem, I see that as a positive.", for interest, I see it as a negative for a number of reasons, at least in the WP:PIA topic area, mostly because it is subjective/non-deterministic.- The WP:ARBECR rules have no dependency on subjective assessments of the quality of edits. Non-EC editors are only allowed to make edit requests. That is what we tell them.
- If it is the case that non-EC editors are only allowed to make edit requests, there is no reason to leave pages unprotected.
- If it is not the case that non-EC editors can only allowed to make edit requests, then we should not be telling them that via talk page headers and standard notification messages.
- There appears to be culture based on an optimistic faith-based belief that the community can see ARBECR violations, make reliable subjective judgements based on some value system and deal with them appropriately through action or inaction. This is inconsistent with my observations.
- Many disruptive violations are missed when there are hundreds of thousands of revisions by tens of thousands of actors.
- The population size of editors/admins who try to address ARBECR violations is very small, and their sampling of the space is inevitably an example of the streetlight effect.
- The PIA topic area is largely unprotected and there are thousands of articles, templates, categories, talk pages etc. Randomness plays a large part in ARBECR enforcement for all sorts of reasons (and maybe that is good to some extent, hard to tell).
- Wikipedia's lack of tools to effectively address ban evasion in contentious topic areas means that it is not currently possible to tell whether a revision by a non-EC registered account or IP violating WP:ARBECR that resembles an okay edit (to me personally with all of my biases and unreliable subjectivity) is the product of a helpful person or a ban evading recidivist/member of an off-site activist group exploiting a backdoor.
- The WP:ARBECR rules have no dependency on subjective assessments of the quality of edits. Non-EC editors are only allowed to make edit requests. That is what we tell them.
- Sean.hoyland (talk) 08:00, 6 November 2024 (UTC)
- The Wordsmith, regarding "
- Oppose I am strongly opposed to the idea of getting yet another level of protection for the sole purpose of using it preemtively, which has never been ok and should not be ok. Just Step Sideways from this world ..... today 21:25, 6 November 2024 (UTC)
- Oppose, I hate pending changes. Using them widely will break the wiki. We need to be as welcoming as possible to new editors, and the instant gratification of wiki editing should be there on as many pages as possible. —Kusma (talk) 21:47, 6 November 2024 (UTC)
- @Kusma Could you elaborate on "using them widely will break the wiki", especially as we currently have the stricter and less-friendly EC protection? Aaron Liu (talk) 22:28, 6 November 2024 (UTC)
- Exhibit A is dewiki's 53-day Pending Changes backlog. —Kusma (talk) 23:03, 6 November 2024 (UTC)
- We already have a similar and larger backlog at CAT:EEP. All this does is move the backlog into an interface handled by server software that allows newcomers to use VE for their "edit requests", where currently they must use the source editor due to being confined to talk pages. Aaron Liu (talk) 23:06, 6 November 2024 (UTC)
- The dewiki backlog is over 18,000 pages. CAT:EEP has 54. The brokenness of optional systems like VE should not be a factor in how we make policy. —Kusma (talk) 09:40, 7 November 2024 (UTC)
- The backlog will not be longer than the EEP backlog. (Also, I meant that EEP's top request was over 3 months ago, sorry.) Aaron Liu (talk) 12:23, 7 November 2024 (UTC)
- ... if the number of protected pages does not increase. I expect an increase in protected pages from the proposal, even if the terrifying proposal to protect large classes of articles preemptively does not pass. —Kusma (talk) 13:08, 7 November 2024 (UTC)
- Why so? Aaron Liu (talk) 13:33, 7 November 2024 (UTC)
- Most PCECP pages should be ECP pages (downgraded?) as they have lesser traffic/disruption. So, the number of pages that will be increase should not be that much. ~/Bunnypranav:<ping> 13:35, 7 November 2024 (UTC)
- ... if the number of protected pages does not increase. I expect an increase in protected pages from the proposal, even if the terrifying proposal to protect large classes of articles preemptively does not pass. —Kusma (talk) 13:08, 7 November 2024 (UTC)
- The backlog will not be longer than the EEP backlog. (Also, I meant that EEP's top request was over 3 months ago, sorry.) Aaron Liu (talk) 12:23, 7 November 2024 (UTC)
- The dewiki backlog is over 18,000 pages. CAT:EEP has 54. The brokenness of optional systems like VE should not be a factor in how we make policy. —Kusma (talk) 09:40, 7 November 2024 (UTC)
- We already have a similar and larger backlog at CAT:EEP. All this does is move the backlog into an interface handled by server software that allows newcomers to use VE for their "edit requests", where currently they must use the source editor due to being confined to talk pages. Aaron Liu (talk) 23:06, 6 November 2024 (UTC)
- Exhibit A is dewiki's 53-day Pending Changes backlog. —Kusma (talk) 23:03, 6 November 2024 (UTC)
- @Kusma Isn't the loss of instant gratification of editing better than creating a request on the talk page of an ECP page, and having no idea by when will it be reviewed and implemented. ~/Bunnypranav:<ping> 11:25, 7 November 2024 (UTC)
- With PC you also do not know when or whether your edit will be implemented. —Kusma (talk) 13:03, 7 November 2024 (UTC)
- @Kusma Could you elaborate on "using them widely will break the wiki", especially as we currently have the stricter and less-friendly EC protection? Aaron Liu (talk) 22:28, 6 November 2024 (UTC)
- Oppose — Feels unnecessary and will only prevent other good faith editors from editing, not to mention the community effort required to monitor and review pending changes requests given that some areas like ARBIPA apply to hundreds of thousands of pages. Ratnahastin (talk) 01:42, 7 November 2024 (UTC)
- @Ratnahastin Similar to my above question, won't this encourage more good faith editors compared to a literal block from editing of an ECP page? ~/Bunnypranav:<ping> 11:32, 7 November 2024 (UTC)
- There is a very good reason I reference Community Resources Against Street Hoodlums in my preferred name for the protection scheme, and the answer is generally no since the topic area we are primarily talking about is an ethno-political contentious topic, which tend to draw partisans interested only in "winning the war" on Wikipedia. This is not limited to just new users coming in, but also established editors who have strong opinions on the topic and who may be put into the position of reviewing these edits, as a read of any random Eastern Europe- or Palestine-Israel-focused Arbitration case would make clear just from a quick skim. —Jéské Couriano v^_^v threads critiques 18:21, 7 November 2024 (UTC)
- Aren't these problems that can also be seen to the same extent in edit requests if they exist? Aaron Liu (talk) 19:10, 7 November 2024 (UTC)
- A disruptive/frivolous edit request can be summarily reverted off to no damage as patently disruptive/frivolous without implicating the 1RR in the area. As long as it's not vandalism or doesn't introduce BLP violations, an edit committed to an article that isn't exactly helpful is constrained by the 1RR, with or without any sort of protection scheme. —Jéské Couriano v^_^v threads critiques 16:21, 8 November 2024 (UTC)
- Patently disruptive and frivolous edits are vandalism, emphasis on "patently". Aaron Liu (talk) 16:28, 8 November 2024 (UTC)
- POV-pushing is not prima facie vandalism. —Jéské Couriano v^_^v threads critiques 16:32, 8 November 2024 (UTC)
- POV-pushing isn't patently disruptive/frivolous and any more removable in edit requests. Aaron Liu (talk) 16:45, 10 November 2024 (UTC)
- But edit requests make it harder to actually push that POV to a live article. —Jéské Couriano v^_^v threads critiques 17:22, 11 November 2024 (UTC)
- Same with pending changes. Aaron Liu (talk) 17:36, 11 November 2024 (UTC)
- Maybe in some fantasy land where the edit didn't need to be committed to the article's history. —Jéské Couriano v^_^v threads critiques 18:08, 11 November 2024 (UTC)
- Except that is how pull requests work on GitHub. You make the edit, and someone with reviewer permissions approves it to complete the merge. Here, the "commit" happens, but the revision is not visible until reviewed and approved. Edit requests are not pull requests, they are the equivalent of "issues" on GitHub. Awesome Aasim 19:03, 11 November 2024 (UTC)
- It may come as a surprise, but Wikipedia is not GitHub. While they are both collaborative projects, they are very different in most other respects. Thryduulf (talk) 19:20, 11 November 2024 (UTC)
- With Git, submitters make a change in their own branch (which can even be in their own repository), and then request that an integrator pull that change into the main branch. So the main branch history remains clean: it only has changes that were merged in. (It's one of the guiding principles of Git: allow the history tree of any branch to be simplified to improve clarity and performance.) isaacl (talk) 22:18, 11 November 2024 (UTC)
- Edit requests are supposed to be pull requests.
Aaron Liu (talk) 22:51, 11 November 2024 (UTC)Clearly indicate which sections or phrases should be replaced or added to, and what they should be replaced with or have added.
— WP:ChangeXY- Yeah that is what they are supposed to be but in practice they are not. As anyone who has answered edit requests before, there are often messages that look like this:
- Except that is how pull requests work on GitHub. You make the edit, and someone with reviewer permissions approves it to complete the merge. Here, the "commit" happens, but the revision is not visible until reviewed and approved. Edit requests are not pull requests, they are the equivalent of "issues" on GitHub. Awesome Aasim 19:03, 11 November 2024 (UTC)
- Maybe in some fantasy land where the edit didn't need to be committed to the article's history. —Jéské Couriano v^_^v threads critiques 18:08, 11 November 2024 (UTC)
- Same with pending changes. Aaron Liu (talk) 17:36, 11 November 2024 (UTC)
- But edit requests make it harder to actually push that POV to a live article. —Jéské Couriano v^_^v threads critiques 17:22, 11 November 2024 (UTC)
- POV-pushing isn't patently disruptive/frivolous and any more removable in edit requests. Aaron Liu (talk) 16:45, 10 November 2024 (UTC)
- POV-pushing is not prima facie vandalism. —Jéské Couriano v^_^v threads critiques 16:32, 8 November 2024 (UTC)
- Patently disruptive and frivolous edits are vandalism, emphasis on "patently". Aaron Liu (talk) 16:28, 8 November 2024 (UTC)
- A disruptive/frivolous edit request can be summarily reverted off to no damage as patently disruptive/frivolous without implicating the 1RR in the area. As long as it's not vandalism or doesn't introduce BLP violations, an edit committed to an article that isn't exactly helpful is constrained by the 1RR, with or without any sort of protection scheme. —Jéské Couriano v^_^v threads critiques 16:21, 8 November 2024 (UTC)
- Aren't these problems that can also be seen to the same extent in edit requests if they exist? Aaron Liu (talk) 19:10, 7 November 2024 (UTC)
- There is a very good reason I reference Community Resources Against Street Hoodlums in my preferred name for the protection scheme, and the answer is generally no since the topic area we are primarily talking about is an ethno-political contentious topic, which tend to draw partisans interested only in "winning the war" on Wikipedia. This is not limited to just new users coming in, but also established editors who have strong opinions on the topic and who may be put into the position of reviewing these edits, as a read of any random Eastern Europe- or Palestine-Israel-focused Arbitration case would make clear just from a quick skim. —Jéské Couriano v^_^v threads critiques 18:21, 7 November 2024 (UTC)
- @Ratnahastin Similar to my above question, won't this encourage more good faith editors compared to a literal block from editing of an ECP page? ~/Bunnypranav:<ping> 11:32, 7 November 2024 (UTC)
Extended content
| ||
---|---|---|
The reference is wrong. Please fix it. 192.0.0.1 (talk) 23:19, 11 November 2024 (UTC) |
- Which is not in practice WP:CHANGEXY. Awesome Aasim 23:19, 11 November 2024 (UTC)
- I don't see how that's much of a problem, especially as edits are also committed to the talk page's history. Aaron Liu (talk) 22:50, 11 November 2024 (UTC)
- Do the words "Provoke edit wars" mean anything? Talk page posts are far less likely to be the locus of an edit war than article edits. —Jéské Couriano v^_^v threads critiques 18:05, 14 November 2024 (UTC)
- As an editor who started out processing edit requests, including ECP edit requests, I disagree. Aaron Liu (talk) 18:08, 14 November 2024 (UTC)
- Oppose, per what JSS has said. I am a little uncomfortable at the extent to which we've seemingly accepted preemptive protection of articles in contentious areas. It may be a convenient way of reducing the drama us admins and power users have to deal with... but only at the cost of giving up on the core principle that anybody can edit. I would rather have drama on a living project than peace on a dead one. jp×g🗯️ 18:16, 7 November 2024 (UTC)
- Oppose I am one of those admins who likes to see disruption before protecting. Lectonar (talk) 08:48, 8 November 2024 (UTC)
- Oppose as unnecessary, seems like a solution in search of a problem. Furthermore, this *is* Wikipedia, the encyclopedia anyone can edit; preemptively protecting pages discourages contributions from new editors. -Fastily 22:36, 8 November 2024 (UTC)
- Weak Oppose I do understand where this protection would be helpful. But I just think something is EC-protectable or not. Don't necessarily think adding another level of bureaucracy is particularly helpful. --Takipoint123 (talk) 05:14, 11 November 2024 (UTC)
- Oppose. I'm inclined to agree that the scenarios where this tool would work a benefit as technical solution would be exceedingly niche, and that such slim benefit would probably be outweighed by the impact of having yet one more tool to further nibble away at the edges of the open spaces of the project which are available to new editors. Frankly, in the last few years we have already had an absurdly aggressive trend towards community (and ArbCom fiat) decisions which have increasingly insulated anything remotely in the vain of controversy from new editors--with predictable consequences for editor recruitment and retention past the period of early involvement, further exacerbating our workloads and other systemic issues. We honestly need to be rolling back some of these changes, not adding yet one more layer (however thin and contextual) to the bureaucratic fabric/new user obstacle course. SnowRise let's rap 11:23, 12 November 2024 (UTC)
- Oppose. The more I read this discussion, the more it seems like this wouldn't solve the majority of what it sets out to solve but would create more problems while doing so, making it on balance a net negative to the project. Thryduulf (talk) 21:43, 12 November 2024 (UTC)
- Oppose and Point of Order Oppose because pending changes is already too complicated and not very useful. I'm a pending changes reviewer and I've never rejected one on PC grounds (basically vandalism). But I often revert on normal editor grounds after accepting on PC grounds. (I suspect that many PC rejections are done for non-PC reasons instead of doing this) "Point of Order" is because the RFC is unclear on what exactly is being opposed. Sincerely, North8000 (talk) 22:15, 12 November 2024 (UTC)
- Pretty sure that what happens is that when vandals realize they will have to submit their edit for review before it goes live, that takes all the fun out of it for them because it will obviously be rejected, and they don't bother. That's pretty much how it was supposed to work. Just Step Sideways from this world ..... today 22:22, 12 November 2024 (UTC)
- This is a very good point, and I ask for @Awesome Aasim's clarification on whether reviewers will be able to reject edits on grounds for normal reverts combined with the EC restriction. I think there's enough rationale to apply this here beyond the initial rationale for PC as explained by JSS above. Aaron Liu (talk) 23:24, 12 November 2024 (UTC)
- Reviewers are given specific reasons for accepting edits (see Wikipedia:Pending changes § Reviewing pending edits) to avoid overloading them with work while processing pending changes expeditiously. If the reasons are opened up to greater evaluation of the quality of edits, then expectations may shift towards this being a norm. Thus some users are concerned this will create a hierarchy of editors, where edits by non-reviewers are gated by reviewers. isaacl (talk) 23:44, 12 November 2024 (UTC)
- I understand that and wonder how the reviewer proposes to address this. I would still support this proposal if having reviewers reject according to whether they'd revert and "ostensibly" to enforce EC is to be the norm, albeit to a lesser extent for the reasons you mentioned (though I'd replaced "non-reviewers" with "all non–auto-accepted"). Aaron Liu (talk) 00:13, 13 November 2024 (UTC)
- I'm not sure to whom you are referring when you say "the reviewer" – you're the one suggesting there's a rationale to support more reasons for rejecting a pending change beyond the current set. Since any pending change in the queue will prevent subsequent changes by non-reviewers from being visible to most readers, their edits too will get evaluated by a single reviewer before being generally visible. isaacl (talk) 00:59, 13 November 2024 (UTC)
- Sorry, I meant Aasim, the nominator. I made a thinko.
Currently, reviewers can undo just the edits that aren't good and then approve the revision of their own revert. I thought that was what we were supposed to do. Aaron Liu (talk) 02:13, 13 November 2024 (UTC)
- Sorry, I meant Aasim, the nominator. I made a thinko.
- I'm not sure to whom you are referring when you say "the reviewer" – you're the one suggesting there's a rationale to support more reasons for rejecting a pending change beyond the current set. Since any pending change in the queue will prevent subsequent changes by non-reviewers from being visible to most readers, their edits too will get evaluated by a single reviewer before being generally visible. isaacl (talk) 00:59, 13 November 2024 (UTC)
- I understand that and wonder how the reviewer proposes to address this. I would still support this proposal if having reviewers reject according to whether they'd revert and "ostensibly" to enforce EC is to be the norm, albeit to a lesser extent for the reasons you mentioned (though I'd replaced "non-reviewers" with "all non–auto-accepted"). Aaron Liu (talk) 00:13, 13 November 2024 (UTC)
- Yes. Anything that is obvious vandalism or a violation of existing Wikipedia's policies can still be rejected. However, for edits where there is no other problem, the edit can still be accepted. In other words, a user not being extended confirmed shall not be sufficient grounds for rejecting an edit under PCECP, since the extended confirmed user takes responsibility for the edit. If the extended confirmed user accepts a bad edit, it is on them, not whoever made it. That is the whole idea.
- Of course obviously helpful changes such as fixing typos and adding up-to-date information should be accepted sooner, while more controversial changes should be discussed first. Awesome Aasim 17:37, 13 November 2024 (UTC)
- By
or a violation of existing Wikipedia's policies
, do you only mean violations of BLP, copyvio, and "other obviously inappropriate content" that may be very-quickly checked, which is the current scope of what to reject? Aaron Liu (talk) 17:41, 13 November 2024 (UTC)- Yeah, but also edits made in violation of an already well-established consensus. Edits that enforce a clearly-established consensus (proven by previous talk page discussion), are, from my understanding, exempt from all WP:EW restrictions. Awesome Aasim 18:38, 13 November 2024 (UTC)
- By
- Reviewers are given specific reasons for accepting edits (see Wikipedia:Pending changes § Reviewing pending edits) to avoid overloading them with work while processing pending changes expeditiously. If the reasons are opened up to greater evaluation of the quality of edits, then expectations may shift towards this being a norm. Thus some users are concerned this will create a hierarchy of editors, where edits by non-reviewers are gated by reviewers. isaacl (talk) 23:44, 12 November 2024 (UTC)
- Oppose per Thryduulf and SnowRose. Also regardless of whether this is a good idea as a policy, FlaggedRevs has a large amount of technical debt, to the extent that deployment to any additional WMF wikis is prohibited, so it seems unwise to expand its usage. novov talk edits 19:05, 13 November 2024 (UTC)
- Oppose I have never found the current pending changes system easily to navigate as a reviewer. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)
- Oppose the more productive approach would be to reduce the overuse of extended-confirmed protection. We have come to rely on it too much. This would be technically difficult and complex for little real gain. —Ganesha811 (talk) 18:30, 16 November 2024 (UTC)
- That's the goal of this proposal (reducing the overuse of ECP), and it provides a plausible mechanism for that (replacing it with the much-less stringent PCECP). How would you go about reducing overuse of ECP instead? – Closed Limelike Curves (talk) 23:29, 29 November 2024 (UTC)
- Would you support a version in which the reviewers remain PC patrollers? Aaron Liu (talk) 00:58, 30 November 2024 (UTC)
- Oppose there might be a need for this but not preemptive. Andre🚐 01:31, 17 November 2024 (UTC)
- Wouldn't that be a support here for question #1, and an oppose in question #2? – Closed Limelike Curves (talk) 23:34, 29 November 2024 (UTC)
- Indeed, but as I've said below, it appears the rationale in the background section has confused many. Aaron Liu (talk) 00:58, 30 November 2024 (UTC)
- Wouldn't that be a support here for question #1, and an oppose in question #2? – Closed Limelike Curves (talk) 23:34, 29 November 2024 (UTC)
- Oppose. The pending changes system is awful and this would make it awfuler (that wasn't a word but it is now). Zerotalk 05:58, 17 November 2024 (UTC)
- Oppose. How can we know that the 72,912 extended-confirmed users are capable of reviewing pending changes? I assume this is a step above normal PCP (eg. pcp is preferred over pcecp), how can reviewing semi-protected pending changes have a higher bar (requiring a request at WP:PERM) than reviewing extended-protected pending changes? Doesn't make much sense to me. — BerryForPerpetuity (talk) 14:15, 20 November 2024 (UTC)
- I do not think that XCON are reviewers is fixed. This RfC is primarily about the creation of PCECP. ~/Bunnypranav:<ping> 14:21, 20 November 2024 (UTC)
- Well, they're capable of reviewing edit requests. Aaron Liu (talk) 14:39, 20 November 2024 (UTC)
- Sure, but assuming this will work the same as PCR, isn't it possible that an extended-confirmed user who doesn't want to review edits, will try to edit a PCECP page, and be required to review edits beforehand? They're not actively seeking out to review edits in the same way that a PCR or someone who handles edit requests does. Will their review be on par with the scrutiny required for this level of protection? — BerryForPerpetuity (talk) 14:55, 20 November 2024 (UTC)
- You do not need to review edits to edit the pending version of the page, which is what happens when you press save on a page with pending edits. Aaron Liu (talk) 15:02, 20 November 2024 (UTC)
- Is it not the case that reviewers need to check a page's pending changes to edit a page? Either way, the point of "what would constitute a revert" needs to be discussed and decided on before we start to implement this, which I appreciate you discussing above. — BerryForPerpetuity (talk) 15:38, 20 November 2024 (UTC)
- No. It's just that if the newest change is not reviewed, the last reviewed change is shown to readers instead of the latest change. Aaron Liu (talk) 16:00, 20 November 2024 (UTC)
- Is it not the case that reviewers need to check a page's pending changes to edit a page? Either way, the point of "what would constitute a revert" needs to be discussed and decided on before we start to implement this, which I appreciate you discussing above. — BerryForPerpetuity (talk) 15:38, 20 November 2024 (UTC)
- You do not need to review edits to edit the pending version of the page, which is what happens when you press save on a page with pending edits. Aaron Liu (talk) 15:02, 20 November 2024 (UTC)
- Sure, but assuming this will work the same as PCR, isn't it possible that an extended-confirmed user who doesn't want to review edits, will try to edit a PCECP page, and be required to review edits beforehand? They're not actively seeking out to review edits in the same way that a PCR or someone who handles edit requests does. Will their review be on par with the scrutiny required for this level of protection? — BerryForPerpetuity (talk) 14:55, 20 November 2024 (UTC)
How can we know that the 72,734 extended-confirmed users are capable of reviewing pending changes?
This isn't about pending changes level 1. This is about pending changes as applied to enforce ECP, with the level [auto-accept=extendedconfirmed] [review=extendedconfirmed]. As this is only intended to be used for WP:ARBECR restricted pages, it shouldn't be used for anything else.- What might need to happen for this to work is there are ways to configure who can auto-accept and review changes individually (rather than bundled as is right now) with the FlaggedRevs extension. Something like this for these drop-downs:
- Auto-accept:
- All users
- Autoconfirmed
- Extended confirmed
- Template editor
- Administrators
- Review:
- Autoconfirmed
- Extended confirmed and reviewers
- Template editors and reviewers
- Administrators
- Auto-accept:
- Of course, autoreview will have auto-accept perms regardless of these settings, and review will have review perms regardless of these settings. Awesome Aasim 16:36, 20 November 2024 (UTC)
- I understand what you're saying, and I'm aware this isn't about level 1. I'm not strongly opposed to PCECP, but my original point was talking about the difference in reviewer requirements for semi-protected PC and XCON PC. If this passes, it would make reviewing semi-protected pending changes require a permission request, but reviewing extended-protected pending changes would only require being extended-confirmed. If that could be explained so I could understand it better, I'd appreciate it.
- This also relates to edit requests. XCON users are capable of reviewing edit requests, because they don't have to implement what the request was verbatim. If a user makes a request that has good substance, but has a part that doesn't adhere to some policy (MOS, NPOV, ect), the reviewer can change it to fit policy. With pending changes, there's really no way to do that besides editing the accepted text after accepting it. The edit request reviewer can ask for clarification on something, add notes, give a reason for declining, ect.
- Especially on pages that have ARBCOM enforcement on them, the edit request system is far better than the pending changes system. This approach seems to be a solution for the problem of over-protection, which is what should actually be addressed. — BerryForPerpetuity (talk) 17:22, 22 November 2024 (UTC)
- Personally, I would also support this change if only reviewers may accept.
I think editing a change after acceptance is superior. It makes clear which parts were written by whom (and thus much easier to satisfy our CC license). Aaron Liu (talk) 17:43, 22 November 2024 (UTC)- Identifying which specific parts were written by whom isn't necessary for the CC BY-SA license. (And since each new revision is a new derivative work, it's not that easy to isolate.) isaacl (talk) 18:50, 22 November 2024 (UTC)
- Right, but there's no need to forget the attributive edit summary, which is needed when accepting edit requests. Identifying specific parts is just cleaner this way. Aaron Liu (talk) 18:57, 22 November 2024 (UTC)
- If the change is rejected, then a user who isn't an author of the content appears in the article history. In theory that would unnecessarily entangle the user in any copyright issues that arose, or possibly defamation cases. isaacl (talk) 22:55, 22 November 2024 (UTC)
- I personally see that as a much lesser problem than the EditRequests issue. Aaron Liu (talk) 19:15, 23 November 2024 (UTC)
- If the change is rejected, then a user who isn't an author of the content appears in the article history. In theory that would unnecessarily entangle the user in any copyright issues that arose, or possibly defamation cases. isaacl (talk) 22:55, 22 November 2024 (UTC)
- Right, but there's no need to forget the attributive edit summary, which is needed when accepting edit requests. Identifying specific parts is just cleaner this way. Aaron Liu (talk) 18:57, 22 November 2024 (UTC)
- Identifying which specific parts were written by whom isn't necessary for the CC BY-SA license. (And since each new revision is a new derivative work, it's not that easy to isolate.) isaacl (talk) 18:50, 22 November 2024 (UTC)
- We should be maximizing the number of pages that are editable by all. Protection fails massively at this task. All this does is tell editors "hey don't edit this page", which is fine for certain legal pages and the main page that no one should really be editing, but for articles? There is a reason we have this thing called "code review" on Git and "peer review" everywhere else; we should be encouraging changes but if there is disruption we should be able to hold them for review so we can remove the problematic ones.
- Since Wikipedia is not configured to have software-based RC patrol outside of new pages patrol (and RC patrol would be a problem anyway not only because of the sheer volume of edits but also because edits older than a certain timeframe are removed from the patrol queue), we have to rely on other software measures to hide revisions until they are approved. Specifically, RC patrol hiding all edits until approved (wikiHow does this) would be a problem on Wikipedia. But that is a tangent. Awesome Aasim 19:43, 22 November 2024 (UTC)
- There's also a reason why Git changes aren't pushed directly to the main code branch for review, and instead a pull request is sent to an integrator in order to integrate the changes. There's a bottleneck in processing the request (including integration testing). Also note with software development, rebasing your changes onto the latest integrated stream is your responsibility. The equivalent with pending changes would be for each person to revalidate their proposed change after a preceding change had been approved or rejected. Instead, the workload falls upon the reviewer. Side note: the term "code review" far predates git, and is widely used by many software development teams. isaacl (talk) 22:45, 22 November 2024 (UTC)
- I see I see. I do think we need better pending changes as the current flagged revs system sucks. Also just because a feature is turned on doesn't mean there is consensus to use it, as seen by WP:SUPERPROTECT and WP:PC2. Awesome Aasim 18:11, 23 November 2024 (UTC)
- Your second sentence would render everything about this to be meaningless. Plus, the community does not like unnecessarily turning features on; both of your examples have been removed. Aaron Liu (talk) 19:18, 23 November 2024 (UTC)
- I know, that is my point. We also have consensus to make in Vector 2022 the unlimited width being default which was never turned on. Awesome Aasim 19:20, 23 November 2024 (UTC)
- I don't understand your point. You're making a proposal for a new feature that has to be developed in a MediaWiki extension. If it does get developed, it won't get deployed on English Wikipedia unless there's consensus to use it. And given that the extension is not supported by the WMF right now, to the extent that it won't deploy it on new wikis, I'm not sure it has the ability to support any new version. isaacl (talk) 22:53, 23 November 2024 (UTC)
- I know, that is my point. We also have consensus to make in Vector 2022 the unlimited width being default which was never turned on. Awesome Aasim 19:20, 23 November 2024 (UTC)
- Your second sentence would render everything about this to be meaningless. Plus, the community does not like unnecessarily turning features on; both of your examples have been removed. Aaron Liu (talk) 19:18, 23 November 2024 (UTC)
- I see I see. I do think we need better pending changes as the current flagged revs system sucks. Also just because a feature is turned on doesn't mean there is consensus to use it, as seen by WP:SUPERPROTECT and WP:PC2. Awesome Aasim 18:11, 23 November 2024 (UTC)
- There's also a reason why Git changes aren't pushed directly to the main code branch for review, and instead a pull request is sent to an integrator in order to integrate the changes. There's a bottleneck in processing the request (including integration testing). Also note with software development, rebasing your changes onto the latest integrated stream is your responsibility. The equivalent with pending changes would be for each person to revalidate their proposed change after a preceding change had been approved or rejected. Instead, the workload falls upon the reviewer. Side note: the term "code review" far predates git, and is widely used by many software development teams. isaacl (talk) 22:45, 22 November 2024 (UTC)
- Personally, I would also support this change if only reviewers may accept.
- Oppose, per JSS and others. We don't need another system just to allow the preemptive protection of pages, and allowing non-EC editors to clutter up this history in ARBECR topic areas would just create a lot of extra work with little or no real benefit. – bradv 23:10, 23 November 2024 (UTC)
- Oppose - edit requests only for non-EC users is against spirit of open wiki, but is necessary to prevent the absolute flame-wars/edit-wars on contentious topic pages. having a pending changes version of an article only moves flamewars by non-ECR users to pending changes version. Better to allow edit requests and use ARBECR to close non-productive discussions on talk page than having another venue for CTOP flamewars to occur. Bluethricecreamman (talk) 02:28, 2 December 2024 (UTC)
- In your argument, aren't flamewars still moved to the edit request's discussions? Can't editors also just reject non-productive pending changes? Aaron Liu (talk) 03:48, 2 December 2024 (UTC)
Neutral (PCECP)
- I have made my opposition to all forms of FlaggedRevisions painfully clear since 2011. I will not formally oppose this, however, so as to avoid the process being derailed by people rebutting my opposition. —Jéské Couriano v^_^v threads critiques 02:36, 6 November 2024 (UTC)
- I'm not a fan of the current pending changes, so I couldn't support this. But it also wouldn't effect my editing, so I won't oppose it if it helps others.-- LCU ActivelyDisinterested «@» °∆t° 14:32, 6 November 2024 (UTC)
Discussion (PCECP)
Someone who is an expert at configuring mw:Extension:FlaggedRevs will need to confirm that it is possible to simultaneously have our current type of pending changes protection plus this new type of pending changes protection. The current enwiki FlaggedRevs config looks something like the below and may not be easy to configure. You may want to ping Ladsgroup or post at WP:VPT for assistance.
Extended content
|
---|
// enwiki
// InitializeSettings.php
$wgFlaggedRevsOverride = false;
$wgFlaggedRevsProtection = true;
$wgSimpleFlaggedRevsUI = true;
$wgFlaggedRevsHandleIncludes = 0;
$wgFlaggedRevsAutoReview = 3;
$wgFlaggedRevsLowProfile = true;
// CommonSettings.php
$wgAvailableRights[] = 'autoreview';
$wgAvailableRights[] = 'autoreviewrestore';
$wgAvailableRights[] = 'movestable';
$wgAvailableRights[] = 'review';
$wgAvailableRights[] = 'stablesettings';
$wgAvailableRights[] = 'unreviewedpages';
$wgAvailableRights[] = 'validate';
$wgGrantPermissions['editprotected']['movestable'] = true;
// flaggedrevs.php
wfLoadExtension( 'FlaggedRevs' );
$wgFlaggedRevsAutopromote = false;
$wgHooks['MediaWikiServices'][] = static function () {
global $wgAddGroups, $wgDBname, $wgDefaultUserOptions,
$wgFlaggedRevsNamespaces, $wgFlaggedRevsRestrictionLevels,
$wgFlaggedRevsTags, $wgFlaggedRevsTagsRestrictions,
$wgGroupPermissions, $wgRemoveGroups;
$wgFlaggedRevsNamespaces[] = 828; // NS_MODULE
$wgFlaggedRevsTags = [ 'accuracy' => [ 'levels' => 2 ] ];
$wgFlaggedRevsTagsRestrictions = [
'accuracy' => [ 'review' => 1, 'autoreview' => 1 ],
];
$wgGroupPermissions['autoconfirmed']['movestable'] = true; // T16166
$wgGroupPermissions['sysop']['stablesettings'] = false; // -aaron 3/20/10
$allowSysopsAssignEditor = true;
$wgFlaggedRevsNamespaces = [ NS_MAIN, NS_PROJECT ];
# We have only one tag with one level
$wgFlaggedRevsTags = [ 'status' => [ 'levels' => 1 ] ];
# Restrict autoconfirmed to flagging semi-protected
$wgFlaggedRevsTagsRestrictions = [
'status' => [ 'review' => 1, 'autoreview' => 1 ],
];
# Restriction levels for auto-review/review rights
$wgFlaggedRevsRestrictionLevels = [ 'autoconfirmed' ];
# Group permissions for autoconfirmed
$wgGroupPermissions['autoconfirmed']['autoreview'] = true;
# Group permissions for sysops
$wgGroupPermissions['sysop']['review'] = true;
$wgGroupPermissions['sysop']['stablesettings'] = true;
# Use 'reviewer' group
$wgAddGroups['sysop'][] = 'reviewer';
$wgRemoveGroups['sysop'][] = 'reviewer';
# Remove 'editor' and 'autoreview' (T91934) user groups
unset( $wgGroupPermissions['editor'], $wgGroupPermissions['autoreview'] );
# Rights for Bureaucrats (b/c)
if ( isset( $wgGroupPermissions['reviewer'] ) ) {
if ( !in_array( 'reviewer', $wgAddGroups['bureaucrat'] ?? [] ) ) {
// promote to full reviewers
$wgAddGroups['bureaucrat'][] = 'reviewer';
}
if ( !in_array( 'reviewer', $wgRemoveGroups['bureaucrat'] ?? [] ) ) {
// demote from full reviewers
$wgRemoveGroups['bureaucrat'][] = 'reviewer';
}
}
# Rights for Sysops
if ( isset( $wgGroupPermissions['editor'] ) && $allowSysopsAssignEditor ) {
if ( !in_array( 'editor', $wgAddGroups['sysop'] ) ) {
// promote to basic reviewer (established editors)
$wgAddGroups['sysop'][] = 'editor';
}
if ( !in_array( 'editor', $wgRemoveGroups['sysop'] ) ) {
// demote from basic reviewer (established editors)
$wgRemoveGroups['sysop'][] = 'editor';
}
}
if ( isset( $wgGroupPermissions['autoreview'] ) ) {
if ( !in_array( 'autoreview', $wgAddGroups['sysop'] ) ) {
// promote to basic auto-reviewer (semi-trusted users)
$wgAddGroups['sysop'][] = 'autoreview';
}
if ( !in_array( 'autoreview', $wgRemoveGroups['sysop'] ) ) {
// demote from basic auto-reviewer (semi-trusted users)
$wgRemoveGroups['sysop'][] = 'autoreview';
}
}
};
|
–Novem Linguae (talk) 09:41, 6 November 2024 (UTC)
- I basically came here to ask if this is even possible or if it would need WMMF devs involvement or whatever.
- For those unfamiliar, pending changes is not the same thing as the flagged revisions used on de.wp. PC was developed by the foundation specifically for this project after we asked for it. We also used to have WP:PC2 but nobody really knew what that was supposed to be and how to use it and it was discontinued. Just Step Sideways from this world ..... today 21:21, 6 November 2024 (UTC)
- Is PC2 an indication of implementation being possible? Aaron Liu (talk) 22:27, 6 November 2024 (UTC)
- Depends on what exactly is meant by "implementation". A configuration where edits by non-extendedconfirmed users need review by reviewers would probably be similar to what was removed in gerrit:/r/334511 to implement T156448 (removal of PC2). I don't know whether a configuration where edits by non-extendedconfirmed users can be reviewed by any extendedconfirmed user while normal PC still can only be reviewed by reviewers is possible or not. Anomie⚔ 13:32, 7 November 2024 (UTC)
- Looking at the MediaWiki documentation, it is not possible atm. That said, currently the proposal assumes that it is possible and we should work with that (though I would also support allowing all extended-confirmed to review all pending changes). Aaron Liu (talk) 13:56, 7 November 2024 (UTC)
- Depends on what exactly is meant by "implementation". A configuration where edits by non-extendedconfirmed users need review by reviewers would probably be similar to what was removed in gerrit:/r/334511 to implement T156448 (removal of PC2). I don't know whether a configuration where edits by non-extendedconfirmed users can be reviewed by any extendedconfirmed user while normal PC still can only be reviewed by reviewers is possible or not. Anomie⚔ 13:32, 7 November 2024 (UTC)
- Is PC2 an indication of implementation being possible? Aaron Liu (talk) 22:27, 6 November 2024 (UTC)
I think the RfC summary statement is a bit incomplete. My understanding is that the pending changes feature introduces a set of rights which can be assigned to corresponding user groups. I believe all the logic is based on the user rights, so there's no way to designate that one article can be autoreviewed by one user group while another article can be autoreviewed by a different user group. Thus unless the proposal is to replace autoconfirmed pending changes with extended confirmed pending changes, I don't think saying "enabled" in the summary is an adequate description. And if the proposal is to replace autoconfirmed pending changes, I think that should be explicitly stated. isaacl (talk) 22:06, 6 November 2024 (UTC)
- The proposal assumes that coexistence is technically possible. Aaron Liu (talk) 22:28, 6 November 2024 (UTC)
- The proposal did not specify if it assumed co-existence is possible, or enabling it is possible, which could mean replacement. Thus I feel the summary statement (before the timestamp, which is what shows up in the central RfC list) is incomplete. isaacl (talk) 22:31, 6 November 2024 (UTC)
- While on a re-read,
It is assumed that it is technically possible to have PCECP
does not explicitly imply co-existence, that is how I interpreted it. Anyways, it would be wonderful to hear from @Awesome Aasim about this. Aaron Liu (talk) 22:42, 6 November 2024 (UTC)- The key question that ought to be clarified is if the proposal is to have both, or to replace the current one with a new version. (That ties back to the question of whether or not the arbitration committee's involvement is required.) Additionally, it would be more accurate not to use a word in the summary that implies the only cost is turning on a switch. isaacl (talk) 22:49, 6 November 2024 (UTC)
- It is assuming that we can have PC1 where only reviewers can approve edits and PCECP where only extended confirmed users can approve edits AND make edits without requiring approval. With the current iteration I don't know if it is technically possible. If it requires an extension rewrite or replacement, that is fine. If something is still unclear, please let me know. Awesome Aasim 23:06, 6 November 2024 (UTC)
- I suggest changing the summary statement to something like, "Should a new pending changes protection level be added to Wikipedia – extended confirmed pending changes (hereby abbreviated as PCECP)?". The subsequent paragraph can provide the further explanation on who would be autoreviewed and who would serve as reviewers with the new proposed level. isaacl (talk) 23:19, 6 November 2024 (UTC)
- Okay, done. I tweaked the wording a little. Awesome Aasim 23:40, 6 November 2024 (UTC)
- I suggest changing the summary statement to something like, "Should a new pending changes protection level be added to Wikipedia – extended confirmed pending changes (hereby abbreviated as PCECP)?". The subsequent paragraph can provide the further explanation on who would be autoreviewed and who would serve as reviewers with the new proposed level. isaacl (talk) 23:19, 6 November 2024 (UTC)
- It is assuming that we can have PC1 where only reviewers can approve edits and PCECP where only extended confirmed users can approve edits AND make edits without requiring approval. With the current iteration I don't know if it is technically possible. If it requires an extension rewrite or replacement, that is fine. If something is still unclear, please let me know. Awesome Aasim 23:06, 6 November 2024 (UTC)
- The key question that ought to be clarified is if the proposal is to have both, or to replace the current one with a new version. (That ties back to the question of whether or not the arbitration committee's involvement is required.) Additionally, it would be more accurate not to use a word in the summary that implies the only cost is turning on a switch. isaacl (talk) 22:49, 6 November 2024 (UTC)
- While on a re-read,
- The proposal did not specify if it assumed co-existence is possible, or enabling it is possible, which could mean replacement. Thus I feel the summary statement (before the timestamp, which is what shows up in the central RfC list) is incomplete. isaacl (talk) 22:31, 6 November 2024 (UTC)
- I think inclusion of the preemptive-protection part in the background statement is causing confusion. AFAIK preemptive protection and whether we should use PCECP over ECP are separate questions. Aaron Liu (talk) 19:11, 7 November 2024 (UTC)
Q2: If this proposal passes, should PCECP be applied preemptively to WP:ARBECR topics?
Particularly on low traffic articles as well as all talk pages. WP:ECP would still remain an option to apply on top of PCECP. Awesome Aasim 19:58, 5 November 2024 (UTC)
Support (Preemptive PCECP)
- Support for my reasons in Q1. Awesome Aasim 19:58, 5 November 2024 (UTC)
- Also to add on there needs to be some enforcement measure for WP:ARBECR. No technical enforcement measures on WP:ARBECR is akin to site-banning an editor and then refusing to block them because "blocks should be preventative". Awesome Aasim 19:42, 13 November 2024 (UTC)
- Blocking a site-banned user is preventative, because if we didn't need to prevent them from editing they wouldn't have been site banned. Thryduulf (talk) 21:16, 13 November 2024 (UTC)
- Also to add on there needs to be some enforcement measure for WP:ARBECR. No technical enforcement measures on WP:ARBECR is akin to site-banning an editor and then refusing to block them because "blocks should be preventative". Awesome Aasim 19:42, 13 November 2024 (UTC)
- Slightly ambivalent on protecting talk pages, but I guess it would bring prominence to low-traffic pages. Aaron Liu (talk) 20:13, 5 November 2024 (UTC)
- Per isaacl, I only support preemptive protection on low-traffic pages. Aaron Liu (talk) 23:21, 12 November 2024 (UTC)
Support, including on talk pages. With edit requests mostly dealt with through pending changes, protecting the talk pages too should limit the disruption and unconstructive comments that are often commonplace there.(Changing my mind, I don't think applying PCECP on all pages would be a constructive solution. The rules of ARBECR limit participation to extended-confirmed editors, but the spirit of the rules has been to only enforce that on pages with actual disruption, not preemptively. 20:49, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:21, 5 November 2024 (UTC)- Support I'm going to disagree with the "no" argument entirely - we should be preemptively ECPing (even without pending changes). It's a perversion of logic to say "you can't (per policy) do push this button", and then refuse to actually technically stop you from pushing the button even though we know you could. * Pppery * it has begun... 20:52, 5 November 2024 (UTC)
- Support (Summoned by bot): While I disagree with ECR in general, this is a better way of enforcing it as long as it exists. Constructive "edit requests" can be accepted, and edits that people disagree with can be easily reverted. I'm slightly concerned with how this could affect the pending changes backlog (which has a fairly small number of active reviewers at the moment), but I'm sure that can be figured out. C F A 💬 23:41, 5 November 2024 (UTC)
Oppose (Preemptive PCECP)
- No, I don't think this is necessary at this time. I think it should be usable there, but I don't feel like this is a necessary step at this time. We could revisit it later. WhatamIdoing (talk) 20:37, 5 November 2024 (UTC)
- No, we still shouldn't be protecting preemptively. Wait until there's disruption, and then choose between PCXC or regular XC protection (I would strongly favour the former for the reasons I gave above). Cremastra (u — c) 20:43, 5 November 2024 (UTC)
- Mu - This is a question that should be asked afterwards, not same time as, since ArbCom will want to look at any such proposal. —Jéské Couriano v^_^v threads critiques 02:38, 6 November 2024 (UTC)
- No, I feel this would be a bad idea. Critics of Wikipedia already use the idea that it's controlled by a select group, this would only make that misconception more common. -- LCU ActivelyDisinterested «@» °∆t° 14:36, 6 November 2024 (UTC)
- Preemptive protection has always been contrary to policy, with good reason. Just Step Sideways from this world ..... today 21:26, 6 November 2024 (UTC)
- Absolutely not. No need for protection if there is no disruption. The number of protected pages should be kept low, and the number of pages that cry out "look at me!" on your watchlist (anything under pending changes) should be as close to zero as possible. —Kusma (talk) 21:44, 6 November 2024 (UTC)
No need for protection if there is no disruption.
Trouble is, the ECR restriction is enacted in response to widespread disruption, this time to the entire topic area as a whole. Disregard for POV, blatant inclusion of unverifiable or false (unreliable) information, and more all pose serious threats of disruption to the project. If WP:ARBECR was applied broadly without any protection I would agree, but WP:ARBECR is applied in response to disruption (or a serious threat of), not preemptively. Take this one for example, which is a long winded ANI discussion that ended in the WP:GS for the Russo-Ukranian War (and the ECR restrictions). And as for Arbitration Committee, ArbCom is a last resort when all other attempts to resolve disruption fail. See WP:ARBPIA WP:ARBPIA2 WP:ARBPIA3 WP:ARBPIA4. The earliest reference to the precursor to ARBECR in this case is on the third ArbCom case. Not protecting within a topic area that has a high risk of disruption is akin to having a high-risk template unprotected. The only difference is that carelessly editing a high-risk template creates technical problems, while carelessly editing a high-risk topic area creates content problems.- Either the page is protected technically (which enforces a community or ArbCom decision that only specific editors are allowed in topic areas) or the page is not protected technically but protected socially (which then gives a chance of evasion). I see this situation no different from banning an editor sitewide and then refusing to block them on the grounds that "blocks should only be used to prevent disruption" while ignoring the circumstances leading up to the site ban.
- What PCECP would do is allow for better enforcement of the community aspect. New editors won't be bitten, if they find something that needs fixing like a typo, they can make an edit and it can get approved. More controversial edits will get relegated to the talk page where editors not banned from that topic area can discuss that topic. And blatant POV pushing and whatnot would get reverted and would never even be seen by readers.
- The workflow would look like this: new/anon user make an edit → edit gets held for review → extended confirmed user approves the edit. Rather than the current workflow (and the reason why preemptive ECP is unpopular): new/anon user makes an edit → user is greeted with a "this page is protected" message → user describes what they would like to be changed but in a badly formulated way → edit request gets closed as "unclear" or something similar. Awesome Aasim 14:21, 11 November 2024 (UTC)
- Consider this POV change made to a topic that I presume is covered under WP:ARBPIA and that is not protected. The whole reason that there is WP:ARBECR is to prevent stuff like this from happening. There already is consensus either among arbitrators or among the community to enact ECR within specific contentious topic areas, so I don't see how it is productive to refuse to protect pages because of "not enough disruption" when the entire topic area has faced widespread disruption in the past. Awesome Aasim 18:18, 23 November 2024 (UTC)
- Simple, everyday vandalism is far from the levels of disruption that caused the topic to be marked Contentious. Aaron Liu (talk) 19:20, 23 November 2024 (UTC)
- That example I provided isn't vandalism. Yes it is disruptive POV pushing but it is not vandalism. Wikipedia also exists in the real world, and Wikipedia does not have the technical tools to fight armies of POV pushers and more. One example is Special:PermaLink/1197462753#Arbitration_motion_regarding_PIA_Canvassing. When the stakes are this high people feel entitled to impose their view on the project, but Wikipedia isn't the place to right great wrongs. Awesome Aasim 19:32, 23 November 2024 (UTC)
- It is vandalism, the changing of content beyond recognition. Even if it were just POV-pushing, there was no army here. Aaron Liu (talk) 19:41, 23 November 2024 (UTC)
- That example I provided isn't vandalism. Yes it is disruptive POV pushing but it is not vandalism. Wikipedia also exists in the real world, and Wikipedia does not have the technical tools to fight armies of POV pushers and more. One example is Special:PermaLink/1197462753#Arbitration_motion_regarding_PIA_Canvassing. When the stakes are this high people feel entitled to impose their view on the project, but Wikipedia isn't the place to right great wrongs. Awesome Aasim 19:32, 23 November 2024 (UTC)
- Simple, everyday vandalism is far from the levels of disruption that caused the topic to be marked Contentious. Aaron Liu (talk) 19:20, 23 November 2024 (UTC)
- Consider this POV change made to a topic that I presume is covered under WP:ARBPIA and that is not protected. The whole reason that there is WP:ARBECR is to prevent stuff like this from happening. There already is consensus either among arbitrators or among the community to enact ECR within specific contentious topic areas, so I don't see how it is productive to refuse to protect pages because of "not enough disruption" when the entire topic area has faced widespread disruption in the past. Awesome Aasim 18:18, 23 November 2024 (UTC)
- Per my vote above. Ratnahastin (talk) 09:00, 7 November 2024 (UTC)
- Absolutely not. Protection should only ever be preventative. Kusma puts it better than I can. Thryduulf (talk) 13:49, 7 November 2024 (UTC)
- Per my comment above. jp×g🗯️ 18:17, 7 November 2024 (UTC)
- No; see my comment above. I prefer to see disruption before protecting. Lectonar (talk) 08:51, 8 November 2024 (UTC)
- No. We should be quicker to apply protection in these topics than we would elsewhere, but not preemptively except on highly visible pages (which, in these topics, are probably ECP-protected anyway). Animal lover |666| 17:18, 11 November 2024 (UTC)
- No, that would create a huge backlog. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)
- Oppose per Kusma Andre🚐 01:30, 17 November 2024 (UTC)
Neutral (preemptive PCECP)
Discussion (preemptive PCECP)
- @Jéské Couriano Could you link to said ArbCom discussion? Aaron Liu (talk) 03:51, 6 November 2024 (UTC)
- I'm not saying such a discussion exists, but changes to Arbitration remedies/discretionary sanctions are something they would want to weigh in on. Arbitration policy (which includes WP:Contentious topics) is in their wheelhouse and this would have serious implications for WP:CT/A-I and any further instances where ArbCom (rather than individual editors, as a discretionary sanction) would need to resort to a 500/30 rule as an explicit remedy. —Jéské Couriano v^_^v threads critiques 04:58, 6 November 2024 (UTC)
- That is not my reading of WP:ARBECR. Specifically,
On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by...the use of pending changes...
(bold added by me for emphasis). But if there is consensus not to use this preemptively so be it. Awesome Aasim 05:13, 6 November 2024 (UTC)
- That is not my reading of WP:ARBECR. Specifically,
- I'm not saying such a discussion exists, but changes to Arbitration remedies/discretionary sanctions are something they would want to weigh in on. Arbitration policy (which includes WP:Contentious topics) is in their wheelhouse and this would have serious implications for WP:CT/A-I and any further instances where ArbCom (rather than individual editors, as a discretionary sanction) would need to resort to a 500/30 rule as an explicit remedy. —Jéské Couriano v^_^v threads critiques 04:58, 6 November 2024 (UTC)
- While I appreciate the forward thinking that PCECP may want to be used in Arb areas, this feels like a considerable muddying of the delineation between the Committee's role and the community's role. Traditionally, Contentious Topics have been the realm of ArbCom, and General Sanctions have been the realm of the Community. Part of the logic comes down to who takes the blame when things go wrong. The Community shouldn't take the blame when ArbCom makes a decision, and vice versa. Part of the logic is separation of powers. If the community wants to say "ArbCom, you will enforce this so help you God," then that should be done by amending ArbPol. Part of the logic is practical. If the community creates a process that adds to an existing Arb process, what happens when the Arbs want to change that process? Or even end it altogether? Bottomline: Adopting PCECP for ARBECR is certainly something ArbCom could do. But I'd ask the community to consider the broader structural problems that would arise if the community adopted it on behalf of ArbCom. CaptainEek Edits Ho Cap'n!⚓ 05:18, 7 November 2024 (UTC)
- Interesting. I'd say ArbCom should be able to override the community if they truly see such action fit and worthy of potential backlash. Aaron Liu (talk) 12:30, 7 November 2024 (UTC)
- Just a terminology note, although I appreciate many think of general sanctions in that way, it's defined on the Wikipedia:General sanctions page as
... a type of Wikipedia sanctions that apply to all editors working in a particular topic area. ... General sanctions are measures used by the community or the Arbitration Committee ("ArbCom") to improve the editing atmosphere of an article or topic area.
. Thus the contentious topics framework is a form of general sanctions. isaacl (talk) 15:22, 7 November 2024 (UTC) - Regarding the general point: I agree that it is cumbersome for the community to impose a general sanction that is added on top of a specific arbitration remedy. I would prefer that the community work with the arbitration committee to amend its remedy, which would facilitate keeping the description of the sanction and logging of its enforcement together, instead of split. (I appreciate that for this specific proposal, logging of enforcement is not an issue.) isaacl (talk) 15:30, 7 November 2024 (UTC)
- Extended confirmed started off as an arbcom concept - 500 edits/30 days - which the community then choose to adopt. ArbCom then decided to make its remedy match the community's version - such that if the community were to decide extended confirmed were 1000 edits/90 days all ArbCom restrictions would update. I find this a healthy feedback loop between ArbCom and the community. The community could clearly choose (at least on a policy level, given some technical concerns) to enact PCECP. It could choose to apply this to some/all pages. If it is comfortable saying that it wants to delegate some of which pages this applies to the Arbitration Committee I think it can do so without amending ArbPol. However, I think ArbCom could could decide that PCECP would not apply in some/all CTOP areas given that the Committee is exempt from consensus for areas with-in its scope. And so it might ultimately make more sense to do what isaacl suggests. Best, Barkeep49 (talk) 16:02, 7 November 2024 (UTC)
- The "contentious topics" procedure does seem like something that the community should absolutely mirror and that ultimately both the community and ArbCom should work out of. If one diverges, there is probably a good reason why it diverged.
- As for the
broader structural problems that would arise if the community adopted it on behalf of ArbCom
, there are already structural problems with general sanctions because of the community's failure to adopt the new CTOP procedure for new contentious topics. Although the community has adopted the contents of WP:ARBECR for other topic areas like WP:RUSUKR, they don't adopt it by reference but by copying the whole text verbatim. Awesome Aasim 17:13, 7 November 2024 (UTC)- That's not the same structural problem. The community hasn't had a lot of discussion about adopting the contentious topic framework for its own use (in my opinion, because it's a very process-wonky discussion that doesn't interest enough editors to generate a consensus), but that doesn't interfere with how the arbitration committee uses the contentious topic framework. This proposal is suggesting that the community automatically layer on its own general sanction on top of any time the arbitration committee decides to enact a specific sanction. Thus the committee would have to consider each time whether or not to override the community add-on, and amendment requests might have to be made both to the committee and the community. isaacl (talk) 17:33, 7 November 2024 (UTC)
- Prior to contentious topics there were discretionary sanctions. Those became very muddled and so the committee created Contentious topics to help clarify the line between community and committee (disclosure: I help draft much of that work). As part of that the committee also established ways for the community to tie-in to contentious topics if it wanted. So for the community hasn't made that choice which is fine. But I do this is an area that, in general, ArbCom does better than the community because there is more attention paid to having consistency across areas and when a problem arises I have found (in basically this one area only) ArbCom to be more agile at addressing it. But the community is also more willing to pass a GS than ArbCom is to designate something a CT (which I think is a good hting all around) and so having the community come to consensus about how, if at all, it wants to tie in to CT (and its evolutions) or if it would prefer to do its own thing (including just mirroring whatever happens to be in CT at the time but not subsequent changes) would probably be a good meta discussion to have. But it also doesn't seem necessary for this particular proposal. Best, Barkeep49 (talk) 17:41, 7 November 2024 (UTC)
Q3: If this proposal does not pass, should ECP be applied preemptively to articles under WP:ARBECR topics?
Support (preemptive ECP)
Support as a second option, but only to articles. Talk pages can be enforced solely through reverts and short protections so I see little reason why those should be protected. Awesome Aasim 19:58, 5 November 2024 (UTC)Moved to oppose. Awesome Aasim 19:10, 23 November 2024 (UTC)Support for articles per Aasim. Talk pages still need to be open for edit requests.(Also changing my mind, per above. If anything, we should clarify ARBECR so that the 500-30 limit is only applied in cases where it is needed, not automatically, to resolve the ambiguity. 20:52, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:20, 5 November 2024 (UTC)- Support per my comment in the previous section. * Pppery * it has begun... 20:52, 5 November 2024 (UTC)
- I agree with Chaotic Enby and Pppery above and think all CT articles should be protected. I am generally not a fan of protecting Talk pages, but it's true that many CT Talk pages are cesspools of hate, so I am not sure where I sit on protecting Talk pages. Toadspike [Talk] 20:57, 5 November 2024 (UTC)
- Under the current wording of ARBECR,
When such a restriction is in effect in a topic area, only extended-confirmed editors may make edits related to the topic area.
We should protect pages, rather than letting new editors edit and then reverting them for basically no reason. This is a waste of their time and very BITEy. - I am not opposed to changing the wording of ARBECR to forbid reverting solely because an editor is not extended confirmed, which is a silly reason to revert otherwise good edits. However, until ArbCom changes ARBECR, we are stuck with the rules we have. We ought to make these rules clear to editors before they edit, by page protection, instead of after they edit, by reversion. Toadspike [Talk] 10:55, 16 November 2024 (UTC)
- Under the current wording of ARBECR,
- Support preemptive ECP without PCECP (for article space only). If we have a strict policy (or ArbCom ruling) that a class of user is forbidden to edit a class of page, there is no downside whatever to implementing that policy by technical means. All it does is stop prohibited edits. The consequences would all be positive, such as removing the need for constant monitoring, reducing IP vandalism to zero, and reducing the need to template new editors who haven't learned the rules yet. What I'd like with regard to the last one, is that a non-EC editor sees an "edit" button on an ECP page but clicking it diverts them to a page that explains EC and how to get it. Zerotalk 05:53, 17 November 2024 (UTC)
Oppose (preemptive ECP)
- Oppose because I think this is a bad idea. For one thing, just making a list of all the covered articles could produce disputes that we don't need. (This article might be covered, but is it truly covered? Reasonable people could easily disagree about whether some articles are "mostly" about the restricted area vs "partly", and therefore about whether the rule applies.) Second, where a serious and obvious problem, such as blatant vandalism, is concerned, it would be better to have an IP revert it than to mindlessly follow the rules. It is important to remember that our rules exist as a means to an end. We follow them because, and to the extent that, they help overall. We expect admins and other editors to exercise discretion. It is our policy that Wikipedia:If a rule prevents you from improving or maintaining Wikipedia, ignore it. This is a proposal to declare that the IAR policy never applies to the rule about who should normally be editing these articles, and that exercising discretion is not allowed. WhatamIdoing (talk) 20:42, 5 November 2024 (UTC)
- I am neither Arb nor admin, but I think the words "broadly construed" are specifically chosen so that if a topic is "partly" about the restricted area, it is included in the CTOP. @WhatamIdoing, could you please show me an example of a case where CTOP designation or ECP was disputed? Toadspike [Talk] 10:59, 16 November 2024 (UTC)
- I avoid most of those articles, but consider "the entire set of Arab-Israeli conflict-related articles, broadly interpreted": Does that include BLPs who come from Israel/Palestine? What about BLPs who are in the news because of what they said about the Israel–Hamas war? IMO reasonable people could disagree about whether "every person living in the affected area" or "every person talking about the conflict" is part of "the entire set of Arab-Israeli conflict-related articles, broadly interpreted". WhatamIdoing (talk) 19:54, 16 November 2024 (UTC)
- David Miller is what we call a "partial" Arbpia. So while it's a BLP in general, parts of it are subject to Arbpia/CT, not a particularly unusual situation. The talkpage and edit notices should, but don't always, tell you whether it is or isn't, part of. Selfstudier (talk) 20:59, 16 November 2024 (UTC)
- I avoid most of those articles, but consider "the entire set of Arab-Israeli conflict-related articles, broadly interpreted": Does that include BLPs who come from Israel/Palestine? What about BLPs who are in the news because of what they said about the Israel–Hamas war? IMO reasonable people could disagree about whether "every person living in the affected area" or "every person talking about the conflict" is part of "the entire set of Arab-Israeli conflict-related articles, broadly interpreted". WhatamIdoing (talk) 19:54, 16 November 2024 (UTC)
- WP:IAR applies to content not to conduct. ArbCom is empowered to take action against poor conduct. You can't claim WP:IAR for example to reverse engineering a script that requires specific permissions to use. Likewise a new editor cannot claim "IAR" to adding unverifiable (albeit true) information to an ARBECR protected article. Awesome Aasim 15:25, 16 November 2024 (UTC)
- IAR stands for IgnoreAllRules. The latter two cannot be claimed valid based on IgnoreAllRules because they don't have strong IgnoreAllRules arguments for what they did, not because IgnoreAllRules somehow only applies to content. Aaron Liu (talk) 16:07, 16 November 2024 (UTC)
- I meant ignore all rules applies to rules not to behavior. Point still stands as ARBPIA addresses behavior not content. Awesome Aasim 21:04, 16 November 2024 (UTC)
- I agree that "ignore all rules" applies to rules – including rules about behavior. ARBPIA is a rule about behavior. IAR therefore applies to ARBPIA.
- Of course, if breaking the rule doesn't prove helpful to Wikipedia in some way, then no matter what type of rule it is, you shouldn't break the rule. We have a rule against bad grammar in articles, and you should not break that rule. But when two rules conflict – say, the style rule of "No bad grammar" and the behavioral rule of "No editing this ARBPIA article while logged out, even if it's because you're on a public computer and can't remember your password" – IAR says you can choose to ignore the rule that prevents you from improving Wikipedia. WhatamIdoing (talk) 21:34, 16 November 2024 (UTC)
- I meant ignore all rules applies to rules not to behavior. Point still stands as ARBPIA addresses behavior not content. Awesome Aasim 21:04, 16 November 2024 (UTC)
- IAR stands for IgnoreAllRules. The latter two cannot be claimed valid based on IgnoreAllRules because they don't have strong IgnoreAllRules arguments for what they did, not because IgnoreAllRules somehow only applies to content. Aaron Liu (talk) 16:07, 16 November 2024 (UTC)
- I am neither Arb nor admin, but I think the words "broadly construed" are specifically chosen so that if a topic is "partly" about the restricted area, it is included in the CTOP. @WhatamIdoing, could you please show me an example of a case where CTOP designation or ECP was disputed? Toadspike [Talk] 10:59, 16 November 2024 (UTC)
- While there's already precedent for preemptive protection at e.g. RFPP, I do not like this. For one, as talk pages (and, by extension, edit requests) cannot use the visual editor, this makes it much harder for newcomers to contribute edits, often unnecessarily on articles where there are no disruption. Aaron Liu (talk) 23:47, 5 November 2024 (UTC)
- Oppose (Summoned by bot): Too strict. C F A 💬 00:03, 6 November 2024 (UTC)
- Mu - This is basically my reading of the 500/30 rule as writ. Anything that would fall into the 500/30'd topic should be XCP'd on discovery. It's worth noting I don't view this as anywhere close to ideal but then neither did ArbCom, and given the circumstances of the real-world ethnopolitical conflict only escalating as of late (which in turn feeds the disruption) the only other - even worse - option would be full-protection across the board everywhere in the area. So why am I not arguing Support? Because just like the question above, this is putting the cart before the horse and this is better off being discussed after this RfC ends, not same time as. —Jéské Couriano v^_^v threads critiques 02:47, 6 November 2024 (UTC)
- Oppose Preemptive protection of any page where there is not a problem that needs solving. Just Step Sideways from this world ..... today 21:28, 6 November 2024 (UTC)
- Absolutely not, pages that do not experience disruption should be open to edit. Pending changes should never become widely used to avoid situations like dewiki's utterly absurd 53-day backlog. —Kusma (talk) 21:53, 6 November 2024 (UTC)
- Very strong oppose, again Kusma puts it excellently. Protection should always be the exception, not the norm. Even in the Israel-Palestine topic area most articles do not experience disruption. Thryduulf (talk) 13:50, 7 November 2024 (UTC)
- WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely
Their edits are limited to a small number of pages that very few people watch
andConversely, their edits may be distributed over a wide range of articles to make it less likely that any given user watches a sufficient number of affected articles to notice the disruptions
. If a user is really insistent on pushing their agenda, they might not be able to push it on the big pages, they may push it on some of the smaller pages where their edits may get unwatched for months if not years. Then, researchers digging up information will come across the POV article and blindly cite it. Although Wikipedia should never be cited as a source, it still happens. Awesome Aasim 14:35, 11 November 2024 (UTC)
- WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely
- Per my comment above. jp×g🗯️ 18:18, 7 November 2024 (UTC)
- No, see my comment to the other questions. Lectonar (talk) 08:52, 8 November 2024 (UTC)
- No, we should never be preemptively protecting pages. Cremastra (u — c) 16:35, 10 November 2024 (UTC)
- No, except on the most prominent articles on each CT topic (probably already done on current CTs, but relevant for new ones). Animal lover |666| 19:47, 11 November 2024 (UTC)
- Absolutely not. See above comments for details. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)
- Comment - The number of revisions within the PIA topic area that violate the ARBECR rule is not measured. It is not currently possible to say anything meaningful about the amount of 'disruption' in the topic area by non-EC IPs and accounts. And the way people estimate the amount of 'disruption' subjectively depends on the timescale they choose to measure it. Nobody can see all of the revisions and the number of people looking is small. Since the ARBECR rule was introduced around the start of 2020, there have been over 71,000 revisions by IPs to articles and talk pages within the subset of the PIA topic, about 11,000 pages, used to gather statistical data (ARBPIA templated articles and articles that are members of both wikiproject Israel and wikiproject Palestine). Nobody has any idea how many of those were constructive, how many were disruptive, how many involved ban-evading disposable accounts etc. And yet, this incomplete information situation apparently has little to no impact on the credence we all assign to our views about what would work best for the PIA topic area. I personally think it is better to dispense with non-evidence-based beliefs about the state of the topic area at any given time and simply let the servers enforce the rule as written in WP:ARBECR, "only extended-confirmed editors may make edits related to the topic area, subject to the following provisions...". Sean.hoyland (talk) 17:22, 16 November 2024 (UTC)
- Make sense, but I am not sure if this is meant to be an oppose. Personally, since there hasn't been much big outrage not solved by a simple RfPP, anecdotally I see no problem with the status quo on this question. Aaron Liu (talk) 01:24, 17 November 2024 (UTC)
- Oppose per Thryduulf and others Andre🚐 01:29, 17 November 2024 (UTC)
- Oppose. Preemptive protection is just irresponsible.—Alalch E. 23:22, 22 November 2024 (UTC)
- As OP I am actually starting to lean weak oppose unless if we have a robust and new-user-friendly edit request system (which currently we don't). We already preemptively protect templates used on a lot of pages for technical reasons, and I don't think new users are at all going to be interested in templates so our current edit request system works decent for templates, modules, code pages, etc. When we choose to protect it should be the same as blocking which is the risk of disruption for specific pages or topic areas, using previous disruption to hope predict the future. Users already have a hard time submitting edit requests for pages not within contentious topic areas, so as it stands right now preemptive protection will do more harm than good. Awesome Aasim 19:10, 23 November 2024 (UTC)
- Oppose - more harm than good, too strict. Bluethricecreamman (talk) 02:30, 2 December 2024 (UTC)
Neutral (preemptive ECP)
Discussion (preemptive ECP)
I think this question should be changed to "...articles under WP:ARBECR topics?". Aaron Liu (talk) 20:11, 5 November 2024 (UTC)
- Okay, updated. Look good? Awesome Aasim 20:13, 5 November 2024 (UTC)
As I discussed in another comment, should this concept gain approval, I feel it is best for the community to work with the arbitration committee to amend its remedy. isaacl (talk) 15:34, 7 November 2024 (UTC)
- And as I discussed in another comment while I think the community could do this, I agree with isaac that it would be best to do it in a way that works with the committee. Best, Barkeep49 (talk) 16:03, 7 November 2024 (UTC)
Q4: Should there be a Git-like system for submitting and reviewing edits to protected pages?
This behaves a little like pending changes, but with a few different things:
- There would be an additional option entitled "allow users to submit edits for review" in the protection window. There could also be a specific user group able to accept such edits.
- Instead of the standard "protected page text" informing the user is protected, when this option is enabled, the user is given a message something like "This page is currently protected, so you are currently submitting an edit request. Only when your change is approved will your edit be visible." An edit summary as well as a more detailed explanation into the review can be provided. Same for title blacklisted pages. However, the "permission error" will still show for attempting to rename the page, as well as for cases where a user cannot edit a page for a reason other than protection (like being blocked from editing).
- All the changes submitted for review end up in some namespace (like Review:1234567) with the change id. Only users with the ability to edit the page or accept the revision would be able to see these changes. There would also be the ability to discuss each change on the talk page for that change or something similar. This namespace by design will be unprotectable.
- Users with the ability to edit the page (or when a higher accept level is selected, users with that accept level) are given the ability to merge these changes in. Administrators can delete changes just like they can delete individual revisions, and these changes can also be suppressed just like individual revisions.
- Changes are not directly committed to the edit history, unlike the current pending changes system; only to the page in the Review: namespace.
This would be a major improvement over our edit request system which ONLY allows a user to write what they want changed, and that is often prone to stuff that is not WP:CHANGEXY. If there are merge conflicts preventing a clean merge then the person who submitted the edit or the reviewer will have to manually fix it before it merges cleanly. If this path is chosen we can safely retire pending changes. Awesome Aasim 18:52, 23 November 2024 (UTC)
Survey (Q4)
- Support failing Q1, as it streamlines the experience for making edit requests, especially for new users. I have had ideas for scripts to make the experience of submitting an edit request a lot easier but none has really come to fruition. I still don't entirely agree with the arguments with Q2 and Q3, but I am starting to agree that that is putting the pen before the pig and thus can be closed as premature, unless if there is an emerging consensus that pages being within a topic area should not be protected for being within that particular topic area. Awesome Aasim 18:52, 23 November 2024 (UTC)
- Support in theory, but wait to see if this is technically possible to implement. While a clear improvement, it will likely require quite some amount of work (and workshopping) for implementation. While a non-binding poll to gauge community interest is a good thing, having a full RfC to adopt this before coding has even begun is way too premature. Chaotic Enby (talk · contribs) 21:29, 23 November 2024 (UTC)
- Too soon to know. Once it is known that it is technically possible and you have mockups of things like interfaces and details of how it would handle a range of common real-world scenarios then we can discuss whether it would make sense to implement it. Thryduulf (talk) 22:52, 23 November 2024 (UTC)
- The whole premise of this RfC is if this is possible, and if it is not that some are willing to make this possible. Awesome Aasim 22:54, 23 November 2024 (UTC)
- Before proposing something like this, first find out whether it is possible. If it isn't currently possible but could be, work out structures and how it will work, at least broadly. Then find out whether enough people want it that someone spending the time to make it will be worthwhile. You can't just assume that anything you want is technically possible and that if enough other people also want it that developers will make it for you. Some relatively simple, uncontroversial feature requests, with demonstrated demand, have been open tasks awaiting developer intention for over 15 years. Thryduulf (talk) 02:16, 24 November 2024 (UTC)
- As an actual developer, this seems like it would be possible in the technical sense, but also a sufficiently large project that it won't actually get done unless some WMF team takes the initiative to do it. This would likely amount to writing a new extension, which would have to go through the review queue, whose first step now is
Find at least one WMF team (or staff member on behalf of their team) to agree to offer basic support for the extension for when it's deployed to Wikimedia Production
. And I have no idea what team would support this. Moderator Tools would be my first guess, but they refused to support Adiutor even when it was actually coded up and ready to go and is much simpler, so they definitely won't. I personally think this requirement is unnecessary (and hypocritical), and the WMF needs to stop stifling volunteers' creativity, but there's nothing I can do about it now. And all of this is despite the fact that I think there's actually some merit to the idea. * Pppery * it has begun... 04:17, 24 November 2024 (UTC)
- As an actual developer, this seems like it would be possible in the technical sense, but also a sufficiently large project that it won't actually get done unless some WMF team takes the initiative to do it. This would likely amount to writing a new extension, which would have to go through the review queue, whose first step now is
- Before proposing something like this, first find out whether it is possible. If it isn't currently possible but could be, work out structures and how it will work, at least broadly. Then find out whether enough people want it that someone spending the time to make it will be worthwhile. You can't just assume that anything you want is technically possible and that if enough other people also want it that developers will make it for you. Some relatively simple, uncontroversial feature requests, with demonstrated demand, have been open tasks awaiting developer intention for over 15 years. Thryduulf (talk) 02:16, 24 November 2024 (UTC)
- The whole premise of this RfC is if this is possible, and if it is not that some are willing to make this possible. Awesome Aasim 22:54, 23 November 2024 (UTC)
- Provisionally support - there is the problem that this requires implementation, so a support !vote has to wait until someone comes along who has the skills needed and is sufficiently enthusiastic about the proposal to get it done. This barrier aside, I do think that this is a good idea. It is more likely to attract attention if the underlying proposal is approved. Perhaps the underlying proposal could be added as an alternate to page protection for use by Arbcom. — Charles Stewart (talk) 05:19, 28 November 2024 (UTC)
- Support - I think this would be a better way to replace edit request system, by having many potential merges, instead of a single pending changes version. If a flame warrior wants to make their own version of an article, no need to worry about the pending changes version being polluted and edit warred over, let the isolated proposed branch exist for that one user. Bluethricecreamman (talk) 02:33, 2 December 2024 (UTC)
Discussion (Q4)
If additional proposals come (seems unlikely), I wonder if this might be better split as a "pending changes review" or something similar. Awesome Aasim 18:52, 23 November 2024 (UTC)
I really think this should be straight-up implemented as whatever first instead of being asked in an RfC. Aaron Liu (talk) 19:32, 23 November 2024 (UTC)
First, please stop calling this a git-like system. The real essence of version control systems is branching history. Plus one of the key principles for git is to enable developers to keep the branching history as simple as possible, with changes merged cleanly into an integration branch, so proposed changes never show up in the history of the integration branch.
I would prefer keeping the article history clear of any edit requests. There could be a tool that would clone an article (or designated sections) to a user subpage, preserving attribution in the edit summary. The user could make their changes on that page, and then a tool could assist them in creating an edit request. Whoever processes the request will be able to review the diff on the subpage. If the current version of the article has changed significantly, they can ask the requester to rebase the page to the current version and redo their change. I think this approach simplifies both creating and reviewing a proposed change, and helps spread the workload of integrating changes when they pile up. isaacl (talk) 22:44, 23 November 2024 (UTC)
- It won't. If the change is not merged. The point of this is the edit history remains clear up until the edit is approved. We can do some "squashing" as well as limit edits to be reviewed to the original creator. A commit on GitHub and GitLab does not show up on main until merged. It is already possible to merge two page's histories right now, this is done after cut and paste moves. This just takes it to a different level. Awesome Aasim 22:53, 23 November 2024 (UTC)
- History merge isn't really the same thing, in that you can't interlace changes in the version history, but only have a "clean" merge when the two have disjoint timespans. If multiple versions of the same page are edited simultaneously before being merged, even assuming no conflicts in merging, the current histmerge system will not be able to handle it properly. Chaotic Enby (talk · contribs) 22:58, 23 November 2024 (UTC)
- If it doesn't show up in the article history, then it isn't like pending changes at all, so I suggest your summary should be updated accordingly. In which case, under the hood your proposal is similar to mine; I suggest having subpages under the user page would be easier for the user to manage. Squashing shouldn't be done with the history of public branches (commits should remain fixed once they've been made known to everyone) plus rewriting history can be confusing, so I think the change history should be preserved on the working page. If you mean that the submission into the article should be one edit, sure.
- My proposal was to layer on tools to assist with creating edit requests, while yours seeks to integrate the system with the edit function when a user is prevented from editing due to page protection. Thus from an implementation perspective, my proposal can be implemented independently of the rest of the MediaWiki code base (and could be done with gadgets), while yours would require changes to the MediaWiki code. Better integration of course offers a more cohesive user experience, but faces greater implementation and integration challenges. I suggest reaching out to the WMF development team to find a contact to discuss your ideas. isaacl (talk) 23:13, 23 November 2024 (UTC)
- I agree that for now we should have JS tools, although that itself has challenges. A modification to MediaWiki core will also have challenges but it might be worth it in the long run, as Core gets regular updates to features, but extensions not always. Awesome Aasim 01:31, 24 November 2024 (UTC)
- Okay, I took a stab at making the experience of making an edit request a bit more new-user friendly: User:Awesome Aasim/editrequestor.js.
- I did notice someone else created a similar script but it behaves quite differently. This relies largely on the MediaWiki compare API to build a result. Unfortunately it uses deprecated libraries, etc. and will definitely need rewriting, but I think it is a good first prototype.
- If something similar was loaded for every edit request with
withJS
, I wonder how this will change the views of users who expressed opposition. Awesome Aasim 02:35, 30 November 2024 (UTC)- Not sure which users you're thinking of, as no one in this discussion has so far opposed changes to the edit process so it can feed an edit request system without introducing pending changes into the article history. (I can imagine opposition based on potentially swamping the edit request system, and a lack of capacity to handle requests, but I don't think the discussion is there yet.) Maybe you can create a short video to demonstrate how your prototype functions? It should be a good starting point for discussions with the appropriate WMF developers. isaacl (talk) 20:19, 30 November 2024 (UTC)
- The "similar script" I am referring to is User:NguoiDungKhongDinhDanh/FormattedEditRequest. But it works a bit differently, rather than intercepting "submit an edit request" requests, it adds a link to a portlet.
- Here is a MP4 file of my prototype. If this can be converted to a compatible format and uploaded to Wikipedia that would be nice. Awesome Aasim 20:44, 30 November 2024 (UTC)
- I wasn't wondering about the other script, but thanks for the info. isaacl (talk) 22:23, 30 November 2024 (UTC)
- Not sure which users you're thinking of, as no one in this discussion has so far opposed changes to the edit process so it can feed an edit request system without introducing pending changes into the article history. (I can imagine opposition based on potentially swamping the edit request system, and a lack of capacity to handle requests, but I don't think the discussion is there yet.) Maybe you can create a short video to demonstrate how your prototype functions? It should be a good starting point for discussions with the appropriate WMF developers. isaacl (talk) 20:19, 30 November 2024 (UTC)
- I agree that for now we should have JS tools, although that itself has challenges. A modification to MediaWiki core will also have challenges but it might be worth it in the long run, as Core gets regular updates to features, but extensions not always. Awesome Aasim 01:31, 24 November 2024 (UTC)
General discussion
Since we're assuming that PCECP is possible and the last two questions definitely deal with policy, I feel like maybe this should go to VPP instead, with the header edited to something like "Extended-confirmed pending changes and preemptive protection in contentious topics" to reflect the slightly−larger-than-advertised scope? Aaron Liu (talk) 23:53, 5 November 2024 (UTC)
- I think policy proposals are also okay here, though I see your point. There is definitely overlap, though. This is both a request for a technical change as well as establishing policy/guidelines around that technical change (or lack thereof). Awesome Aasim 00:26, 6 November 2024 (UTC)
If this proposal is accepted, my assumption is that we'd bring back the ORANGELOCK which was used for the original incarnation of Pending Changes Level 2. There's a proposed lock already at File:Pending_Changes_Protected_Level_2.svg, though it needs fixes in terms of name (should probably be something like Pending-level-2-protection-shackle.png
or Extended-pending-protection-shackle.png
), SVG code (the top curve is a bit cut off), and color (should probably be darker but still clearly distinguishable from REDLOCK). —pythoncoder (talk | contribs) 21:43, 8 November 2024 (UTC)
- I think light blue is a better color for this. But in any case we will probably need a lock with a checkmark and the letter "E" for extended confirmed. Awesome Aasim 22:22, 8 November 2024 (UTC)
- Light blue seems too similar to the sky-blue currently used for WP:SALT —pythoncoder (talk | contribs) 18:04, 1 December 2024 (UTC)
- I would go for either the EC lock just with the icon replaced with a checkmark or what you said but with the same color and a diagonal line down the middle. Aaron Liu (talk) 20:02, 1 December 2024 (UTC)
Courtesy ping
Courtesy ping all from the idea lab that participated in helping formulate this RfC: @Toadspike @Jéské Couriano @Aaron Liu @Mach61 @Cremastra @Anomie @SamuelRiv @Isaacl @WhatamIdoing @Ahecht @Bunnypranav. Awesome Aasim 19:58, 5 November 2024 (UTC)
Protection?
I am actually starting to wonder if "protection" is a bit of a misnomer, because technically pages under pending changes are not really "protected". Yeah the edits are subject to review, but there are no technical measures to prevent a user from editing. It is just like recent changes on many wikis; those hold edits for review until they are approved, but they do not "protect" the entire wiki. Awesome Aasim 23:40, 11 November 2024 (UTC)
- How about “kinder, gentler protection”? To appear in the know, you can use an acronym, such as in “TCPIP is an example of KGP”. — Charles Stewart (talk) 04:57, 28 November 2024 (UTC)
Move to close
The main proposal is basically deadlocked and has been for six days, and the sub-proposals are clearly failing. Seems like we have a result. Just Step Sideways from this world ..... today 23:09, 22 November 2024 (UTC)
- I was about to withdraw Q2 and Q3 for putting the pen before the pig, but I did realize I added a couple more comments particularly to Q2. I did add a Q4 that might be more actionable and that is about making the experience of submitting edit requests a lot better. I am starting to agree though for Q2 and Q3 everything that has needed to be said has been said so the proposals can be withdrawn.
- We do need to consider the experience of the users actually being locked out of this. I understand the opposition to Q3 (and in fact just struck my !vote because of this). But Q2? Look at the disaster that WP:V22RFC, WP:V22RFC2, and WP:V22RFC3 is. These surveys are barely representative of new users, just of experienced editors. We should absolutely be bringing new editors to the table for these discussions. Awesome Aasim 19:13, 23 November 2024 (UTC)
- Please don't pre-close. 4 of the opposers to the main proposal seem to address only Q2 instead of Q1, and I don't see anyone addressing the argument that it's less restrictive than ECP. It's up to the closer to weigh the consensus. Aaron Liu (talk) 19:30, 23 November 2024 (UTC)
RfC: Should a blackout be organized in protest of the Wikimedia Foundation's actions?
Over at Wikipedia:Village_pump (policy), Graywalls raised an issue that I also independently encountered at Wikipedia:Articles for deletion/Jayson Sherlock. That is, that WP:BAND currently circumvents WP:GNG. That Village pump discussion is here. In light of that discussion, I am formally proposing an update to WP:BAND. Please see that proposal here. I have highlighted the addition to existing policy in green.--3family6 (Talk to me | See what I have done) 13:17, 18 November 2024 (UTC)
- Unless I'm misunderstanding something, then this proposal passing will be the equivalent of replacing criteria 2-11 with "they must meet the GNG"? Per several comments in the discussion at Wikipedia:Village_pump (policy)#Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept I'm not convinced that there is currently a problem that can be solved in this manner. Thryduulf (talk) 16:03, 18 November 2024 (UTC)
- Yes, this is basically saying that to have an article, the subject must meet GNG. There is an example in the article deletion discussion I mentioned above where NBAND was argued as an exception to GNG.--3family6 (Talk to me | See what I have done) 16:07, 18 November 2024 (UTC)
- A single discussion where somebody argues something that does not gain consensus is not evidence of a problem, let alone evidence that the proposed change would solve that problem. Thryduulf (talk) 16:26, 18 November 2024 (UTC)
- Yes, this is basically saying that to have an article, the subject must meet GNG. There is an example in the article deletion discussion I mentioned above where NBAND was argued as an exception to GNG.--3family6 (Talk to me | See what I have done) 16:07, 18 November 2024 (UTC)
- I would like to emphasize a key part of WP:N:
A topic is presumed to merit an article if:
- It meets either the general notability guideline (GNG) below, or the criteria outlined in a subject-specific notability guideline (SNG); and
- It is not excluded under the What Wikipedia is not policy.
- This is a feature, not a bug; "or" does not mean "and". That
WP:BAND currently circumvents WP:GNG
is either trivially true (as creating subject-specific notability guidance outside of the GNG is the whole point of a WP:SNG) or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. — Red-tailed hawk (nest) 16:50, 19 November 2024 (UTC)or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines.
That might actually be what is at issue - there seem to be two different understandings of what SNG's are - supporting GNG or an alternative to it.--3family6 (Talk to me | See what I have done) 18:17, 19 November 2024 (UTC)- Some SNGs take one approach; others take different approaches. WP:SNG was written to allow for the diversity of approaches represented by the current SNGs. Newimpartial (talk) 22:10, 22 November 2024 (UTC)
- I posted this in the other village pump thread, but while I'm generally fine with this proposal, I don't think it's coming from a place of understanding.
- Basically, there's an assumption happening that record labels work off some kind of predictable tier system, where the Big 3 labels are home to the most famous artists, indie labels are home to the semi-famous ones, and everyone else is a non-notable bottom feeder. That's not how it works. One of the more notable albums of the year is Cindy Lee's Diamond Jubilee, which was self-released. Meanwhile, there are artists on the Big 3 who I would guess probably don't have significant coverage. This is because music journalism is dying, no one has staff and no one has money, and the range of artists being covered has shrunk dramatically. See this Columbia Journalism Review article for further on that.
- So in other words, I don't think criterion 5 in NBAND is good or useful, but for the opposite reasons that this proposal suggests. The problem is not that people's random garage bands will be considered a "label." The problem is there is less and less correlation between being signed to a label and having significant coverage. (Ironically, the "albums" criterion is probably the more stringent one, because labels are less and less likely to put out a full-length album by an artist that isn't already established via singles and streaming tracks.)
- I don't know what to do with that. (I honestly think the collapse of journalism and the shrinking scope of what gets reported on is a ticking time bomb for notability criteria across the board, but that's a whole other topic.) The most straightforward solution is to use WP:GNG, but I think it's important to have a correct understanding of exactly what musicians we're talking about here. The bar is way, way, way higher than "run of the mill non-notable items" now. The bar is one or two tiers below Sabrina Carpenter. Gnomingstuff (talk) 21:26, 19 November 2024 (UTC)
- Addendum: One way that this criterion could have value is to serve as a reminder that one Google search is not a sufficient WP:BEFORE check, because artists on notable labels are likely to have received coverage in print. (Another way this proposal is misinformed
- - removing NBAND #5 will primarily affect older bands, not newer ones.) But alas, people do not do thorough checks even when they're reminded. Gnomingstuff (talk) 21:33, 19 November 2024 (UTC)
- I'd love to make BEFORE specifically include looking where sources are most likely to be found and explicitly state that looking at the first few pages of Google do not constitute a proper check. This always gets shot down in howls of protest at how dare I require people nominating pages for deletion to do more work than they imagine it took to create a three line sub-stub. I don't know how we get past this. Thryduulf (talk) 21:45, 19 November 2024 (UTC)
- I mean, it already does:
The minimum search expected is a normal Google search, a Google Books search, a Google News search, and a Google News archive search; Google Scholar is suggested for academic subjects
. The problem is that WP:BEFORE is not considered binding so there are no consequences to ignoring it. Gnomingstuff (talk) 21:51, 19 November 2024 (UTC)
- I mean, it already does:
- Gnomingstuff, there seems to be a lot of agreement that #5 as it stands does not make much sense for newer bands, but does make sense prior to the rise of streaming services. I'm seeing cut-offs suggested for the mid- to late-2000s.--3family6 (Talk to me | See what I have done) 12:53, 22 November 2024 (UTC)
- Yeah I get that. I don't agree with the reasoning but I basically agree with the conclusion. Gnomingstuff (talk) 17:27, 22 November 2024 (UTC)
- I'd love to make BEFORE specifically include looking where sources are most likely to be found and explicitly state that looking at the first few pages of Google do not constitute a proper check. This always gets shot down in howls of protest at how dare I require people nominating pages for deletion to do more work than they imagine it took to create a three line sub-stub. I don't know how we get past this. Thryduulf (talk) 21:45, 19 November 2024 (UTC)
Your proposal operatively eliminates the SNG for bands. And also creates an even tougher GNG requirement than GNG by requiring that GNG compliance be demonstrated. I would like there to be some at least partial demonstration requirement added to GNG, but that's a whole 'nother issue and a secondary one in this case.
It also sort of misses the main point discussed at the linked pump discussion which was eliminating one or two items / "ways in" in the SNG.Sincerely, North8000 (talk) 18:04, 18 November 2024 (UTC)
- in line with this, NBAND can be eeaily fixed to makes sure that the idea that the criteria are a presumption of notability is added. I do not see any language like this though the intent seems to be there. That would quickly resolve one conflict. Mind you, deprecating or time gating criteria that do not make sense in modern music distribution is also a reasonable step though I would not remove them outright for historical purposes. Masem (t) 19:02, 18 November 2024 (UTC)
- this was precisely the intent. Am allowed to modify proposals if there have been no votes yet?--3family6 (Talk to me | See what I have done) 19:05, 18 November 2024 (UTC)
- I was amazed by how much our guidelines were written with Western popular musicians in mind when I started editing 17 years ago and it seems that nothing has changed since. It is so much easier for such a person to have an article about them than for other types or nationalities of musician. This is so obviously caused by Wikipedia's demographics that I hesitate to say anything further. Phil Bridger (talk) 19:18, 18 November 2024 (UTC)
- I wonder what effect imposing GNG would have on that. I've heard from some African editors that much of the real news for music and pop culture is posted on social media (i.e., actually posted on Facebook itself, not some website that's sorta kinda social media-like). So if you take away an objective but non-source-oriented criteria and substitute 'must have the kind of sources that are usual enough in the US and UK but are unusual in Nigeria', will that tip even further towards overrepresenting Western popular musicians?
- My impression of the two albums/two films kinds of rules from back in the day is that the advice had more to do with WP:Build the web than with writing full articles. The expectation was that (if there weren't significant sources to justify writing more), the articles would usually be very brief ("Joe Film is an American actor who appeared in Film and Example" or "The Band is a British band who released Album in 1998 and Cover album in 2001") but that we'd still be able to provide non-red links in related pages and still not have to duplicate information. Consequently, I think the traditional thinking is closer to how we think of spinning off a list or splitting a long article, than about trying to justify the subject as "worthy" of a full, stand-alone article via extensive sourcing.
- I could imagine people opposing this merely for fear of the resulting red links, and of course the idea of going beyond the GNG to require "demonstrating" it will turn off other editors. WhatamIdoing (talk) 19:36, 18 November 2024 (UTC)
- If it is established that reliable third party sources covering African music are going to include posts on social media rather than print or web publishing, then we should work to accomodate that so that we are more inclusive, rather than expect the more traditional forms of media. Masem (t) 20:05, 18 November 2024 (UTC)
- speaking for myself, I never had issues with using a third party posting via something like Facebook. I've always considered that to be a statement by that third party, they're just using Facebook as the medium. Am I understanding this example correctly?--3family6 (Talk to me | See what I have done) 20:18, 18 November 2024 (UTC)
- @3family6, user-generated content (including social media) is not a reliable source, except in limited instances (WP:ABOUTSELF). Schazjmd (talk) 20:31, 18 November 2024 (UTC)
- A statement by the band('s representatives) on the band's official facebook page is no more user-generated content and no less reliable than if that same statement was made by the same people was posted on the band's official website or quoted verbatim in a newspaper. Thryduulf (talk) 20:55, 18 November 2024 (UTC)
- Yes, Thryduulf, that's partly what I'm referring to. Schazjmd, I am indeed familiar with that guideline. In fact, my first edit on Wikipedia was removing content that I had generated as a user on another site. I'm referring to established media outlets posting something on Facebook. Like, say, Salon posted a story on Facebook rather than on their official site. It's gone through an editorial process, they just are using Facebook as a publishing medium.--3family6 (Talk to me | See what I have done) 21:00, 18 November 2024 (UTC)
- There isn't a wiki-requirement for the type of source that sources used, or even that they have sources. Of course such things still matter regarding regarding actual/ real world reliability of of the source. North8000 (talk) 21:36, 18 November 2024 (UTC)
- Yes, Thryduulf, that's partly what I'm referring to. Schazjmd, I am indeed familiar with that guideline. In fact, my first edit on Wikipedia was removing content that I had generated as a user on another site. I'm referring to established media outlets posting something on Facebook. Like, say, Salon posted a story on Facebook rather than on their official site. It's gone through an editorial process, they just are using Facebook as a publishing medium.--3family6 (Talk to me | See what I have done) 21:00, 18 November 2024 (UTC)
- A statement by the band('s representatives) on the band's official facebook page is no more user-generated content and no less reliable than if that same statement was made by the same people was posted on the band's official website or quoted verbatim in a newspaper. Thryduulf (talk) 20:55, 18 November 2024 (UTC)
- So keeping in mind that I have never had a Facebook account and have no experience with social media, my impression from these editors was that when they say they get news on Facebook, it's not necessarily the band that's posting (which wouldn't be Wikipedia:Independent sources) or even news articles being shared. Instead, it could be an ordinary comment by someone whom their followers believe is knowledgeable but who is not necessarily "official". For example – and I completely make this example up; the African editors who told me about this dilemma two years ago are welcome to disavow and correct anything I say – imagine a post by a professional DJ: They'll know things about music and bands, and they'll probably know more than a magazine writer assigned to do a piece on pop music in that city/country. They are "reliable" in the sense that people "rely on" them every day of the year. But it's outside the kinds of formal structures that we use to evaluate official sources: no editor, no publisher, no fact-checker, no peer review, etc. WhatamIdoing (talk) 05:33, 20 November 2024 (UTC)
- I'm all for adapting guidelines and policies for geographic and cultural considerations. However, I don't think this would get far, because it's essentially a using self-published sources for BLPs issue, and that's going to be a steep climb to weaken that policy.--3family6 (Talk to me | See what I have done) 12:55, 22 November 2024 (UTC)
- Yeah, I don't see any easy solution here. Even if it's not BLP-related, it relies on already knowing which accounts are the trustworthy ones, and there's no impartial way to evaluate an unfamiliar source. The post could say something like "This village is best known for cloth dyeing" or "The bus service there doesn't run on Sundays", and you'd still have to know whether that source is a good source of information. What if one person posts that the bus runs on Sundays and another person posts that it doesn't? An outsider would have no way of knowing which to trust. WhatamIdoing (talk) 23:28, 22 November 2024 (UTC)
- I'm all for adapting guidelines and policies for geographic and cultural considerations. However, I don't think this would get far, because it's essentially a using self-published sources for BLPs issue, and that's going to be a steep climb to weaken that policy.--3family6 (Talk to me | See what I have done) 12:55, 22 November 2024 (UTC)
- @3family6, user-generated content (including social media) is not a reliable source, except in limited instances (WP:ABOUTSELF). Schazjmd (talk) 20:31, 18 November 2024 (UTC)
- speaking for myself, I never had issues with using a third party posting via something like Facebook. I've always considered that to be a statement by that third party, they're just using Facebook as the medium. Am I understanding this example correctly?--3family6 (Talk to me | See what I have done) 20:18, 18 November 2024 (UTC)
- I always thought the the reason "two or more" was specified was that if there was only one the name could be redirected. Since that time there seems to have developed a dislike for stubs. I don't know where that came from (most articles in most traditional encyclopedias only consisted of one or two sentences, if that) but in order to satisfy that dislike maybe criterion 6 should be an encouragement to create a disambiguation page (or maybe a set index page, if you want to be pedantic) for the title. Phil Bridger (talk) 19:43, 22 November 2024 (UTC)
- I think that is correct. If there's only one, then you could:
- Have an article about the album
- Redirect the band's name to it
- Put the little bit of information you have about the band in the album article
- but if there are multiple albums, then:
- You can have an article about each album
- But which one do you redirect the band's name to?
- And do you duplicate the information about the band in each of the album articles?
- So it seemed easier to have an article. Now, of course, when the median size of an article is 13 sentences and 4 refs, and when we have a non-trivial minority of editors who think even that is pathetic, there is resistance to it. WhatamIdoing (talk) 23:33, 22 November 2024 (UTC)
- I think that is correct. If there's only one, then you could:
- If it is established that reliable third party sources covering African music are going to include posts on social media rather than print or web publishing, then we should work to accomodate that so that we are more inclusive, rather than expect the more traditional forms of media. Masem (t) 20:05, 18 November 2024 (UTC)
Comment I am interpreting this section as an RfCBEFORE, and contributing in that spirit.
Having briefly reviewed the linked discussions, I do not see a problem with NBAND itself that would justify deprecation (rather than revision). And turning NBAND into a predictor of GNG rather than a standalone SNG seems to me essentially akin to deprecation. Fixing specific criteria seems much more appropriate to me, given the issues raised to date.
There are what seem to me to be evident reasons why NBAND operates according to the same logic as NCREATIVE, which is explicitly excluded from WP:NOTINHERITED. These SNGs reflect the reality that creative people produce creative works, and that therefore the people creating those works gain encyclopedic relevance directly from having created them.
In addition, it seems to me that there are practical, navigational reasons (having to do with the affordances of hypertext, Wikipedia's list system, and Wikipedia's category system) to offer more consistent treatment rather than leaving each individual musician, each musical group and each album up to the vagaries of WP:NBASIC, WP:NORG and the WP:GNG.
There may be problems with specific NBAND criteria and the way they are sometimes used at AfD, but it seems entirely incommensurate to deprecate the whole SNG based on such marginal concerns. Newimpartial (talk) 20:31, 18 November 2024 (UTC)
IMO the Wikipedia norm for a "just barely made it" band has sourcing that meets a slightly lenient interpretation of GNG, and the decision is influenced by somewhat meeting an SNG criteria, thus being more conducive to artists than for example a for-profit corporation. And the "norm" means that is is how Wikipedia as a whole wants it. There are folks out there who are at the extreme deletionist end of the spectrum and they will typically say that the above is not the case and piece together an unusually strignent "letter of the law" demand, even adding some things from essays saying that three sources that 100% meet GNG is the expectation. And so while I really think that the burden should shift to providing some GNG-ish sources (vs. just saying "they are out there" without actually supplying any) I'm loath to shift the balance too much, keeping the folks at the deletionist end of the spectrum in mind.
The pump discussion started with talking about how being signed by a label is no longer as indicative as it used to be and to remove it as being a key to the city of SNG compliance. I think there was support for that.
Sincerely, North8000 (talk) 21:16, 18 November 2024 (UTC)
I agree with everyone else above that this proposal would gut WP:BAND, which I am not okay with. If you want to remove some criteria of WP:BAND, like #5, which I agree is a little opaque and outdated, fine. But this seems like a sneaky way of demolishing WP:BAND without openly saying so. Toadspike [Talk] 21:36, 18 November 2024 (UTC)
- I like the point North made, that our notability rules are set up to be
more conducive to artists than for example a for-profit corporation
. I've never thought of our guidelines on artists as particularly lax, but I know that NCORP is purposely stringent and that is the way things should be. Toadspike [Talk] 21:41, 18 November 2024 (UTC)
- I'm not disappointed at the consensus emerging here, and hopefully it might help clarify discussions. there does seem to be some consensus to ditch criterion 5. I'm happy to amend it to that particular criterion disappearing and everything else stays.--3family6 (Talk to me | See what I have done) 21:48, 18 November 2024 (UTC)
- I wonder if the most practical thing with criterion 5 (the one about releasing two albums on a label) would be to give it an end date. It was a useful criterion in the pre-streaming music world, so why not say "two albums on a label before 2010", or at whatever point editors decide that labels became less relevant? WhatamIdoing (talk) 16:42, 19 November 2024 (UTC)
- Something like that I think makes sense.--3family6 (Talk to me | See what I have done) 18:14, 19 November 2024 (UTC)
- I think this is a good idea but the cutoff should be earlier. The iTunes music store was founded in 2003, Spotify was founded in 2006, sometime around there would make more sense. Gnomingstuff (talk) 21:39, 19 November 2024 (UTC)
- I cheerfully leave the determination of the date to someone else, but I note that Spotify#History says that Spotify reached the US market in July 2011, so I'm not sure that it had much effect in 2006. WhatamIdoing (talk) 05:37, 20 November 2024 (UTC)
- Fair point. iTunes probably had the bigger impact anyway.
- If we are specifically concerned about self-published labels (again, I think the "more important indie" labels part already rules that out anyway, but whatever), the digital distribution companies making that happen DistroKid in 2012 and CDBaby in 2004. But even those had their main impact by partnering with Spotify and iTunes respectively. Gnomingstuff (talk) 17:32, 22 November 2024 (UTC)
- I cheerfully leave the determination of the date to someone else, but I note that Spotify#History says that Spotify reached the US market in July 2011, so I'm not sure that it had much effect in 2006. WhatamIdoing (talk) 05:37, 20 November 2024 (UTC)
- I wonder if the most practical thing with criterion 5 (the one about releasing two albums on a label) would be to give it an end date. It was a useful criterion in the pre-streaming music world, so why not say "two albums on a label before 2010", or at whatever point editors decide that labels became less relevant? WhatamIdoing (talk) 16:42, 19 November 2024 (UTC)
- What problem would this solve? – Joe (talk) 16:54, 19 November 2024 (UTC)
- Articles which don't have reliable sources but that are defended by citing SNG as warranting inclusion, anyway.--3family6 (Talk to me | See what I have done) 18:18, 19 November 2024 (UTC)
- Since the band's own website and the albums themselves are "reliable sources", we probably don't have any NBAND articles with no reliable sources. I would think that the main concern is the absence of Wikipedia:Independent sources, and especially of independent sources that have WP:SIGCOV and are notWikipedia:Interviews. WhatamIdoing (talk) 05:39, 20 November 2024 (UTC)
- WP:DELPOL allows for deletion of "articles for which thorough attempts to find reliable sources to verify them have failed" – isn't that sufficient? – Joe (talk) 06:50, 20 November 2024 (UTC)
- AIUI the problem there isn't that deletion isn't one of several available options according to policy; instead, the problem is that other editors do not agree to delete it. DELPOL allows such deletions, but it does not require them, and if I want to delete the article for being IMO undersourced, but other editors show up at AFD saying things like "qualifies under NBAND 5", then the article won't actually get deleted. WhatamIdoing (talk) 22:18, 21 November 2024 (UTC)
- This is precisely the issue - NBAND is cited to contest deletions of content that doesn't have significant independent coverage.--3family6 (Talk to me | See what I have done) 12:57, 22 November 2024 (UTC)
- That's what I thought. The rules don't result in the deletions "I" want; therefore, we must change the rules so other editors can't prevent the deletions "I" want. WhatamIdoing (talk) 23:36, 22 November 2024 (UTC)
- I think over the years, I forgot that SNGs are explicitly allowed to differ from GNG. With that in mind, I'm fine with this proposal being shot down.--3family6 (Talk to me | See what I have done) 21:26, 26 November 2024 (UTC)
- That's what I thought. The rules don't result in the deletions "I" want; therefore, we must change the rules so other editors can't prevent the deletions "I" want. WhatamIdoing (talk) 23:36, 22 November 2024 (UTC)
- This is precisely the issue - NBAND is cited to contest deletions of content that doesn't have significant independent coverage.--3family6 (Talk to me | See what I have done) 12:57, 22 November 2024 (UTC)
- AIUI the problem there isn't that deletion isn't one of several available options according to policy; instead, the problem is that other editors do not agree to delete it. DELPOL allows such deletions, but it does not require them, and if I want to delete the article for being IMO undersourced, but other editors show up at AFD saying things like "qualifies under NBAND 5", then the article won't actually get deleted. WhatamIdoing (talk) 22:18, 21 November 2024 (UTC)
- Articles which don't have reliable sources but that are defended by citing SNG as warranting inclusion, anyway.--3family6 (Talk to me | See what I have done) 18:18, 19 November 2024 (UTC)
- Strongly opposed to the proposal as written by 3family6 as it's written at Wikipedia:Band_notability_proposal now, because it still contains the same text from #5 and #6, which are the two criteria from NBAND that I am objecting to that SNG's presence in the first place. I am unfamiliar with proposal process, but 3family6 went ahead and put it together on his own and doesn't want anyone editing it now. As I said, I don't know how proposals work, but if one user puts it together and quickly puts it out for a vote, is it off limits to editing? Graywalls (talk) 22:09, 21 November 2024 (UTC)
- @Graywalls I didn't remove 5 and 6 because instead what I did is propose that 5 and 6 be supported with significant independent coverage from reliable sources.--3family6 (Talk to me | See what I have done) 12:58, 22 November 2024 (UTC)
- Making criteria 2-11 contingent on also meeting criterion 1 is a much larger (and seemingly unnecessary) change compared to removing or reformulating 5 and 6. Newimpartial (talk) 13:08, 22 November 2024 (UTC)
- I agree that it's a much larger change.--3family6 (Talk to me | See what I have done) 18:52, 22 November 2024 (UTC)
- Making criteria 2-11 contingent on also meeting criterion 1 is a much larger (and seemingly unnecessary) change compared to removing or reformulating 5 and 6. Newimpartial (talk) 13:08, 22 November 2024 (UTC)
- @Graywalls I didn't remove 5 and 6 because instead what I did is propose that 5 and 6 be supported with significant independent coverage from reliable sources.--3family6 (Talk to me | See what I have done) 12:58, 22 November 2024 (UTC)
RfC: Enable the mergehistory permission for importers
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should the (mergehistory)
permission be enabled for the importer
group? Chaotic Enby (talk · contribs) 12:26, 20 November 2024 (UTC)
Support (mergehistory for importers)
- Support. During Graham87's re-request for adminship, it was brought up that some of the more technical imports he performed required history merges. For now, this permission is only available to administrators, limiting the technical capabilities of non-administrator importers. A technical solution to this would be to enable the
(mergehistory)
permission for both administrators and importers. Chaotic Enby (talk · contribs) 12:26, 20 November 2024 (UTC) - Yeah, why not; I didn't really see the point back then, I'm not sure, honestly, that I do now, but enough people have said it's useful work that who am I to deny it? And Graham87's obviously both good at it and committed to it. Support this proposal. SerialNumber54129 12:42, 20 November 2024 (UTC)
- Importers can be trusted to do this adjacent and very important work. Aaron Liu (talk) 12:46, 20 November 2024 (UTC)
- I was about to come propose this myself, but you beat me to it. QuicoleJR (talk) 12:57, 20 November 2024 (UTC)
- Support File importers are trusted enough. – robertsky (talk) 13:03, 20 November 2024 (UTC)
- Support; histmerges are often an essential part of importation work, as noted by Chaotic Enby. JJPMaster (she/they) 13:07, 20 November 2024 (UTC)
- (edit conflict) Support. Importers are editors who are highly trusted to undertake a very specialised role and it makes sense that they be given the rights needed to fully do the job properly. Thryduulf (talk) 13:09, 20 November 2024 (UTC)
- Support obviously – thanks, wow, did not expect this and I didn't know this would be feasible. As I said at my RRFA, I have my own issues with this tool (which explain why I didn't use it so much), but access to it is way better than no history-merge access at all. Graham87 (talk) 13:25, 20 November 2024 (UTC)
- Support if technically feasible. I really opposed the RRFA because Graham87 was asking for a role we didn't have. If they can do their importing/merging work without being able to block users, I would support that. (Normally I wouldn't support a one-off solution like this but, given the rareness of this, I think it makes sense here.) Note that I would also favor further unbundling admin powers beyond this nom. - RevelationDirect (talk) 13:35, 20 November 2024 (UTC)
- Yes, it is feasible. — xaosflux Talk 13:39, 20 November 2024 (UTC)
- Oops, just asked that question below. "Thanks for the prompt rely! RevelationDirect (talk) 13:41, 20 November 2024 (UTC)
- Yes, it is feasible. — xaosflux Talk 13:39, 20 November 2024 (UTC)
- Support - clear benefit, and I don't see any reason not to. Tazerdadog (talk) 13:40, 20 November 2024 (UTC)
- Support sure. This is super niche, but basically: if someone can be trusted to be able to do an xmlimport, this is related and much less dangerous. If we're going to touch it I'm find also adding it to transwiki importers as well (even though we don't have any currenty) for parity. transwiki import is less dangerous, and most of the WP:RFPI items are able to be done that way -- in case any non-admins were looking to work in that area. — xaosflux Talk 13:44, 20 November 2024 (UTC)
- Support If somebody is a importer, they can be trusted with not messing up the databases any further while apply
(merge-history)
. Sohom (talk) 13:58, 20 November 2024 (UTC) - Support, makes sense to give this group the tools they need to do the job properly. CapitalSasha ~ talk 14:12, 20 November 2024 (UTC)
- Support. It just makes sense to do it. ~~ Jessintime (talk) 14:50, 20 November 2024 (UTC)
- Support. Makes sense if the two are so interlinked. If an editor is trusted with one, they should also be fine to have the other. ---- Patar knight - chat/contributions 15:41, 20 November 2024 (UTC)
- Support. This seems like a bit of an exceptional case, but I do think that it's worthwhile to allow importers to merge histories for practical reasons. And the role is so restricted that I don't have trust issues here. — Red-tailed hawk (nest) 15:53, 20 November 2024 (UTC)
- Support: Makes perfect sense from my perspective. Hey man im josh (talk) 16:06, 20 November 2024 (UTC)
- Support, sensible unbundling. Nobody becomes an importer without scrutiny so this seems fine to me. WindTempos they (talk • contribs) 17:02, 20 November 2024 (UTC)
- Support per xaosflux.—Alalch E. 17:32, 20 November 2024 (UTC)
- Support. Graham's tireless work in this area is the demonstration of why this should be permitted. — Hex • talk 17:41, 20 November 2024 (UTC)
- I got to support Graham's importer request once upon a time. Pleased to support this request as well. Even setting aside the direct impetus, this is a logical bundling of the tools that does not raise the required trust level for this small user group. -- Tamzin[cetacean needed] (they|xe) 17:53, 20 November 2024 (UTC)
- Support --Redrose64 🌹 (talk) 21:05, 20 November 2024 (UTC)
- Support See no reason not to. -- Pawnkingthree (talk) 21:18, 20 November 2024 (UTC)
- Suppport. A logical part of the bundle. Sincerely, Dilettante 21:33, 20 November 2024 (UTC)
- Clearly yes. There's very low risk of collateral damage here and obvious benefits.—S Marshall T/C 23:23, 20 November 2024 (UTC)
- Graham (the only non admin importer) is trusted enough for this, no reason not to. charlotte 👸♥📱 06:05, 21 November 2024 (UTC)
- Support. Let's at least permit Graham to continue his archaeological work. No one else does this, and it requires the
mergehistory
perm. Folly Mox (talk) 11:15, 21 November 2024 (UTC) - Graham has a clear use-case for this so I have no objections. JavaHurricane 13:49, 21 November 2024 (UTC)
- Support I see no problems with this. EggRoll97 (talk) 14:56, 21 November 2024 (UTC)
- Support Seems like this is a necessary change given that importing often requires these merges. Noah, BSBATalk 15:53, 21 November 2024 (UTC)
- Support and would go for a WP:SNOW close as well, given the margin.– Closed Limelike Curves (talk) 21:28, 21 November 2024 (UTC)
- Support, obviously, this is invaluable work and it would be a clear negative for it to stop being done, which is effectively what would happen otherwise. Gnomingstuff (talk) 01:51, 22 November 2024 (UTC)
- Support My gut doesn't like this (mergehistory feels like a distinct permission from importer), but I do trust Graham87 to use the tool and think the chance of us ever getting any other non-admin importers is negligible, so I guess I support this. * Pppery * it has begun... 01:54, 22 November 2024 (UTC)
- Support seems like a sensible thing to do. LEPRICAVARK (talk) 12:29, 22 November 2024 (UTC)
- Support Importers are already highly trusted and it is granted by a steward, so this would be a narrow unbundling that would probably satisfy any WMF legal requirements. And I would trust Graham87 with this tool. Abzeronow (talk) 20:58, 22 November 2024 (UTC)
- Support Importers already can fuck with the page history a lot more than someone with history merge rights can. I see no reason to not allow importers to merge history. ThatIPEditor Talk · Contribs 02:04, 23 November 2024 (UTC)
- Support because if this enables work to be performed that much easier for one editor, then chances are increased for other editors to follow suit or pick up the mantle later on down the line. Thanks. Huggums537voted! (sign🖋️|📞talk) 06:50, 25 November 2024 (UTC)
- Support, much has been said above to agree with, an easy support. Randy Kryn (talk) 12:40, 25 November 2024 (UTC)
- Support Importers are trusted enough so I see no problem with this The AP (talk) 14:01, 25 November 2024 (UTC)
- Support. I don't see a reason why not. This seems relevant to the importer group, and I'm surprised this permission isn't already included. – Epicgenius (talk) 14:31, 25 November 2024 (UTC)
Oppose (mergehistory for importers)
- Oppose the current system works just fine. I'm not seeing any compelling reason to carve out an exception for two users. Isaidnoway (talk) 16:27, 20 November 2024 (UTC)
- Because importing is importing a bunch of revisions into the history of the page. It's quite similar and often needed. Those two users are the only ones who maintain this area critical to Wikipedia, and that's the system, which has persisted due to their being able to merge history; now that Graham's been stripped of history merging, half of his duty and thus a quarter of this system, we need to rectify it or risk destabilizing of the system. Aaron Liu (talk) 16:37, 20 November 2024 (UTC)
- There is no risk of destabilizing the system, that's hyperbolic nonsense. Isaidnoway (talk) 20:29, 20 November 2024 (UTC)
- The system is only two people doing this work, and we're otherwise taking away half of what one of them does. I don't see any reason not to do this. Aaron Liu (talk) 20:36, 20 November 2024 (UTC)
- There is no risk of destabilizing the system, that's hyperbolic nonsense. Isaidnoway (talk) 20:29, 20 November 2024 (UTC)
- It no longer "works fine". Your information may be outdated. Folly Mox (talk) 11:17, 21 November 2024 (UTC)
- My information is not "outdated". Thanks. Isaidnoway (talk) 20:52, 21 November 2024 (UTC)
- Because importing is importing a bunch of revisions into the history of the page. It's quite similar and often needed. Those two users are the only ones who maintain this area critical to Wikipedia, and that's the system, which has persisted due to their being able to merge history; now that Graham's been stripped of history merging, half of his duty and thus a quarter of this system, we need to rectify it or risk destabilizing of the system. Aaron Liu (talk) 16:37, 20 November 2024 (UTC)
Discussion (mergehistory for importers)
- Scope Clarification Are @Xaosflux: and Graham87 the only two editors with this permission? What is the process for getting the importer permission? - RevelationDirect (talk) 13:40, 20 November 2024 (UTC)
- @RevelationDirect yes, criteria is basically a user-specific RFC. This is a super niche area; though I'd be open to expanding this permission to the less dangersour transwiki-importer group -- which also requires a per-user rfc to add too, but with a lower bar to entry. — xaosflux Talk 13:46, 20 November 2024 (UTC)
- @RevelationDirect: (after EC) Yes, we're the only ones; the permission has historically been obtained either through a request to this page (as I did) or Wikipedia talk:Requests for page importation (as Xaosflux did). Graham87 (talk) 13:55, 20 November 2024 (UTC)
- @Graham87: Since the topic has come up, I've actually wanted to jump into importing for a while (I'll be quite honest, probably transwiki importing, given it seems like a better place to start out at than XML import), but how does one really get into that line of work? I presume the common answer would probably be the direction of WP:RFA, but that seems like a bit much given a right already exists that is outside of the sysop group. EggRoll97 (talk) 20:54, 20 November 2024 (UTC)
- @EggRoll97 transwiki comes with admin, so most people that want to deal with it go that route, WP:RFA. It is possible to add transwiki in isolation - to do so start a discussion (suggest over at Wikipedia talk:Requests for page importation). The discussion will need to be well advertised (WP:AN and WP:VPM are good places), run for a reasonable time to allow feedback (about a week), be well attended, and show a good consensus of support (someone else should 'close' the discussion with such showing). The bar for transwiki is generally less than for sysop, while the bar for importxml access is generally higher than sysop. At that point, it would get processed over at m:Steward requests/Permissions#Miscellaneous requests. — xaosflux Talk 11:51, 21 November 2024 (UTC)
- @Xaosflux: Yeah that. @EggRoll97:, I did notice your ping, but I wasn't sure how to respond (given that no-one,, especially a non-admin, has asked such a question before) then got distracted by other things. If you have a good idea how/where you'd like to use the import tool, feel free to float your proposal as noted in the message above. Graham87 (talk) 15:52, 21 November 2024 (UTC)
- @Graham87: Since the topic has come up, I've actually wanted to jump into importing for a while (I'll be quite honest, probably transwiki importing, given it seems like a better place to start out at than XML import), but how does one really get into that line of work? I presume the common answer would probably be the direction of WP:RFA, but that seems like a bit much given a right already exists that is outside of the sysop group. EggRoll97 (talk) 20:54, 20 November 2024 (UTC)
- I would also support it. If more users are interested in doing this kind of work, it could be useful for them to have the relevant tools. Chaotic Enby (talk · contribs) 13:49, 20 November 2024 (UTC)
- @RevelationDirect: (after EC) Yes, we're the only ones; the permission has historically been obtained either through a request to this page (as I did) or Wikipedia talk:Requests for page importation (as Xaosflux did). Graham87 (talk) 13:55, 20 November 2024 (UTC)
- @RevelationDirect yes, criteria is basically a user-specific RFC. This is a super niche area; though I'd be open to expanding this permission to the less dangersour transwiki-importer group -- which also requires a per-user rfc to add too, but with a lower bar to entry. — xaosflux Talk 13:46, 20 November 2024 (UTC)
- Technical Feasability Is this request technically feasible, i.e. can the proposed permissions be granted à la carte? - RevelationDirect (talk) 13:40, 20 November 2024 (UTC)
- (It is, see above.) RevelationDirect (talk) 13:42, 20 November 2024 (UTC)
- It is, and no. The only way we can assign permissions is to add the permissions to a group, then users can be added to the group. It would be possible to create an entirely new group that has this permission - but that seems overkill here unless it was going to do a whole lot more (like a "technician" group that had a bunch of other sub-admin permissions). — xaosflux Talk 13:49, 20 November 2024 (UTC)
- Yes. It'd involve a small patch to https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/master/wmf-config/core-Permissions.php#714 –Novem Linguae (talk) 23:09, 21 November 2024 (UTC)
- I'm concerned by the fact that Graham has said Special:MergeHistory results in sub-optimal outcomes (that it is better to use Special:Delete and Special:Undelete) and how this step would encourage non-admin page importers (Graham, and anyone else who might obtain the right in the future) to use an inferior process for history merges. —Compassionate727 (T·C) 14:03, 20 November 2024 (UTC)
- @Compassionate727 those are certainly case-by-case. Sometimes historymerge is the right tool for the job. Any complicated merge/imports that require deletion are going to have to be handled by admins unless we want to make some new sub-admin technician group in the future (the community has repeatedly rejected such proposals though) which could have extra tools (like delete/undelete and others) but only be permitted to use them for certain purposes. — xaosflux Talk 14:09, 20 November 2024 (UTC)
- Graham believes that the MergeHistory tool is inferior simply because it doesn't log a merge on the target page. I see no problem with this view. Aaron Liu (talk) 14:11, 20 November 2024 (UTC)
- Not everyone agrees with my view, such as Pppery; see this Phabricator comment. Graham87 (talk) 14:48, 20 November 2024 (UTC)
- I've started an RfC below regarding this issue; I do think it would be useful to have community input if there is any desire to ever build this functionality. — Red-tailed hawk (nest) 15:52, 20 November 2024 (UTC)
- Not everyone agrees with my view, such as Pppery; see this Phabricator comment. Graham87 (talk) 14:48, 20 November 2024 (UTC)
RfC: Log the use of the HistMerge tool at both the merge target and merge source
|
Currently, there are open phab tickets proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:
- Option 1a: When using Special:MergeHistory, a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
- (phab:T341760: Special:MergeHistory should place a null edit in the page's history describing the merge, authored Jul 13 2023)
- Option 1b: When using Special:MergeHistory, add a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
- (phab:T118132: Merging pages should add a log entry to the destination page, authored Nov 8 2015)
- Option 2: Do not log the use of the Special:MergeHistory tool at the merge target, maintaining the current status quo.
Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — Red-tailed hawk (nest) 15:51, 20 November 2024 (UTC)
Survey: Log the use of the HistMerge tool
- Option 1a/b. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — Red-tailed hawk (nest) 15:51, 20 November 2024 (UTC)
- Option 1a/b. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. Chaotic Enby (talk · contribs) 16:02, 20 November 2024 (UTC)
- Option 1a/b. Choatic Enby has said exactly what I would have said (but more concisely) had they not said it first. Thryduulf (talk) 16:23, 20 November 2024 (UTC)
- 1b would be most important to me but but 1a would be nice too. But this is really not the place for this sort of discussion, as noted below. Graham87 (talk) 16:28, 20 November 2024 (UTC)
- Option 2 History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. * Pppery * it has begun... 16:49, 20 November 2024 (UTC)
- Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)
- Why shouldn't it be indistinguishable? Why it it necessary to go out of our way to say even louder that someone did something wrong and it had to be cleaned up? * Pppery * it has begun... 17:45, 20 November 2024 (UTC)
- All cleanup actions are logged to all the pages they affect. Aaron Liu (talk) 18:32, 20 November 2024 (UTC)
- Why shouldn't it be indistinguishable? Why it it necessary to go out of our way to say even louder that someone did something wrong and it had to be cleaned up? * Pppery * it has begun... 17:45, 20 November 2024 (UTC)
- Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)
- 2 History merges are already logged, so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. Izno (talk) 16:54, 20 November 2024 (UTC)
- They presently are logged, but only at the source article. Take for example this entry. When I search for the merge target, I get nothing. It's only when I search the merge source that I'm able to get a result, but there isn't a way to know the merge source.
- If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — Red-tailed hawk (nest) 17:05, 20 November 2024 (UTC)
- ... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
- But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your
There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful.
Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". Izno (talk) 17:32, 20 November 2024 (UTC)
I don't think everyone would necessarily agree (see Toadspike's comment below). Chaotic Enby (talk · contribs) 17:42, 20 November 2024 (UTC)... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
- Page moves do leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the Special:MergeHistory tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — Red-tailed hawk (nest) 17:50, 20 November 2024 (UTC)
- It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also another way that relies on byte difference bugs as described in the above-linked discussion by wbm1058. Both of those are ... particularly awful. Graham87 (talk) 03:48, 21 November 2024 (UTC)
- In the given example, the history-merge occurred here. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Voila! Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
- Here's another example, of a merge within mainspace. The automatic edit summary (created by the MediaWiki software) of this (No difference) diff "Removed redirect to Jordan B. Acker" points you to the page that was merged at that point. Voila. Voila. Voila. – wbm1058 (talk) 13:44, 21 November 2024 (UTC)
- There are times where those traces aren't left. Aaron Liu (talk) 13:51, 21 November 2024 (UTC)
- Here's another scenario, this one from WP:WikiProject History Merge. The page history shows an edit adding +5,800 bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. Voila, the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
- @ 20:14, 16 January 2021 Tbhotch moved page Flag of Yucatán to Flag of the Republic of Yucatán (Correct name)
- clues you in to where to look for the source of the merge. Voila, that single edit which removed −5,633 bytes tells you that previous history was merged off of that page. The log provides the details. – wbm1058 (talk) 16:03, 21 November 2024 (UTC)
- (phab:T76557: Special:MergeHistory causes incorrect byte change values in history, authored Dec 2 2014) — Preceding unsigned comment added by Wbm1058 (talk • contribs) 18:13, 21 November 2024 (UTC)
- Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. Aaron Liu (talk) 16:11, 21 November 2024 (UTC)
- Indeed. This is a prime example of an unintended undocumented feature. Graham87 (talk) 08:50, 22 November 2024 (UTC)
- Yeah. I don't think that we can permanently rely on that, given that future versions of MediaWiki are not bound in any real way to support that workaround. — Red-tailed hawk (nest) 04:24, 3 December 2024 (UTC)
- Indeed. This is a prime example of an unintended undocumented feature. Graham87 (talk) 08:50, 22 November 2024 (UTC)
- Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. Aaron Liu (talk) 16:11, 21 November 2024 (UTC)
- Here's another scenario, this one from WP:WikiProject History Merge. The page history shows an edit adding +5,800 bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. Voila, the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
- There are times where those traces aren't left. Aaron Liu (talk) 13:51, 21 November 2024 (UTC)
- Support 1b (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) Toadspike [Talk] 17:10, 20 November 2024 (UTC)
- Option 2. The merges are already logged, so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. Ships & Space(Edits) 18:33, 20 November 2024 (UTC)
- But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. Aaron Liu (talk) 18:40, 20 November 2024 (UTC)
- 1B. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place. — SMcCandlish ☏ ¢ 😼 01:38, 21 November 2024 (UTC)
- Option 2. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
- And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery * it has begun... 06:03, 21 November 2024 (UTC)
- That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at Gerrit/Privilege policy on MediaWiki. Graham87 (talk) 15:38, 21 November 2024 (UTC)
- Sorry, I totally forgot Gerrit behaved in that counterintuitive way and hid public information from logged out users for no reason. The things you miss if Gerrit interactions become something you do pretty much every day. If you want to count the members of the group you also have to follow the chain of included groups - it also includes https://ldap.toolforge.org/group/wmf, https://ldap.toolforge.org/group/ops and the WMDE-MediaWiki group (another login-only link), as well as a few other permission edge cases (almost all of which are redundant because the user is already in the MediaWiki group) * Pppery * it has begun... 18:07, 21 November 2024 (UTC)
- That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at Gerrit/Privilege policy on MediaWiki. Graham87 (talk) 15:38, 21 November 2024 (UTC)
- And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery * it has begun... 06:03, 21 November 2024 (UTC)
- Support 1a/b, and I would encourage the closer to disregard any opposition based solely on the chances of someone ever actually implementing it. —Compassionate727 (T·C) 12:52, 21 November 2024 (UTC)
- Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to "set up for a history merge" Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) wbm1058 (talk) 13:44, 21 November 2024 (UTC)
- Yeah, revision move would be amazing, for a start. Graham87 (talk) 15:38, 21 November 2024 (UTC)
- Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to "set up for a history merge" Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) wbm1058 (talk) 13:44, 21 November 2024 (UTC)
- Option 1b – changes to a page's history should be listed in that page's log. There's no need to make a null edit; pagemove null edits are useful because they meaningfully fit into the page's revision history, which isn't the case here. jlwoodwa (talk) 00:55, 22 November 2024 (UTC)
- Option 1b sounds best since that's what those in the know seem to agree on, but 1a would probably be OK. Abzeronow (talk) 03:44, 23 November 2024 (UTC)
- Option 1b seems like the one with the best transparency to me. Thanks. Huggums537voted! (sign🖋️|📞talk) 06:59, 25 November 2024 (UTC)
Discussion: Log the use of the HistMerge tool
- I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — Red-tailed hawk (nest) 15:51, 20 November 2024 (UTC)
- This is a missing feature, not a config change. Aaron Liu (talk) 15:58, 20 November 2024 (UTC)
- Indeed; it's about a feature proposal. — Red-tailed hawk (nest) 16:02, 20 November 2024 (UTC)
- As many of the above, this is a feature request and not something that should be special for the English Wikipedia. — xaosflux Talk 16:03, 20 November 2024 (UTC)
- See phab:T341760. I'm not seeing any sort of reason this would need per-project opt-ins requiring a local discussion. — xaosflux Talk 16:05, 20 November 2024 (UTC)
- True, but I agree with Red-tailed hawk that it's good to have the English Wikipedia community weigh on whether we want that feature implemented here to begin with. Chaotic Enby (talk · contribs) 16:05, 20 November 2024 (UTC)
- Here is the Phabricator project page for MergeHistory, and the project's 11 open tasks. – wbm1058 (talk) 18:13, 21 November 2024 (UTC)
- I agree that this is an odd thing to RFC. This is about a feature in MediaWiki core, and there are a lot more users of MediaWiki core than just English Wikipedia. However, please do post the results of this RFC to both of the phab tickets. It will be a useful data point with regards to what editors would find useful. –Novem Linguae (talk) 23:16, 21 November 2024 (UTC)
CheckUser for all new users
All new users (IPs and accounts) should be subject to CheckUser against known socks. This would prevent recidivist socks from returning and save the time and energy of users who have to prove a likely case at SPI. Recidivist socks often get better at covering their "tells" each time making detection increasingly difficult. Users should not have to make the huge effort of establishing an SPI when editing from an IP or creating a new account is so easy. We should not have to endure Wikipedia:Long-term abuse/HarveyCarter, Wikipedia:Sockpuppet investigations/Phạm Văn Rạng/Archive or Wikipedia:Sockpuppet investigations/Orchomen/Archive if CheckUser can prevent them. Mztourist (talk) 04:06, 22 November 2024 (UTC)
- I'm pretty sure that even if we had enough checkuser capacity to routinely run checks on every new user that doing so would be contrary to global policy. Thryduulf (talk) 04:14, 22 November 2024 (UTC)
- Setting aside privacy issues, the fact that the WMF wouldn't let us do it, and a few other things: Checking a single account, without any idea of who you're comparing them to, is not very effective, and the worst LTAs are the ones it would be least effective against. This has been floated several times in the much narrower context of adminship candidates, and rejected each time. It probably belongs on WP:PEREN by now. -- Tamzin[cetacean needed] (they|xe) 04:21, 22 November 2024 (UTC)
- Why can't it be automated? What are the privacy issues and what would WMF concerns be? There has to be a better system than SPI which imposes a huge burden on the filer (and often fails to catch socks) while we just leave the door open for LTAs. Mztourist (talk) 04:39, 22 November 2024 (UTC)
- How would it be automated? We can't just block everyone who even sometimes shares an IP with someone, which is most editors once you factor in mobile editing and institutional WiFi. Even if we had a system that told checkusers about all shared-IP situations and asked them to investigate, what are they investigating for? The vast majority of IP overlaps will be entirely innocent, often people who don't even know each other. There's no way for a checkuser to find any signal in all that noise. So the only way a system like this would work is if checkusers manually identified IP ranges that are being used by LTAs, and then placed blocks on those ranges to restrict them from account creation... Which is what already happens. -- Tamzin[cetacean needed] (they|xe) 04:58, 22 November 2024 (UTC)
- I would assume that IT experts can work out a way to automate CheckUser. If someone edits on a shared IP used by a previous sock that should be flagged and human CheckUsers notified so they can look at the edits and the previous sock edits and warn or block as necessary. Mztourist (talk) 05:46, 22 November 2024 (UTC)
- We already have autoblock. For cases it doesn't catch, there's an additional manual layer of blocking, where if a sock is caught on an IP that's been used before but wasn't caught by autoblock, a checkuser will block the IP if it's technically feasible, sometimes for months or years at a time. Beyond that, I don't think you can imagine just how often "someone edits on a shared IP used by a previous sock". I'm doing that right now, probably, because I'm editing through T-Mobile. Basically anyone who's ever edited in India or Nigeria has been on an IP used by a previous sock. Basically anyone who's used a large institution's WiFi. There is not any way to weed through all that noise with automation. -- Tamzin[cetacean needed] (they|xe) 05:54, 22 November 2024 (UTC)
- Addendum: An actually potentially workable innovation would be something like a system that notifies CUs if an IP is autoblocked more than once in a certain time period. That would be a software proposal for Phabricator, though, not an enwiki policy proposal, and would still have privacy implications that would need to be squared with the WMF. -- Tamzin[cetacean needed] (they|xe) 05:57, 22 November 2024 (UTC)
- I believe Tamzin has it about right, but I want to clarify a thing. If you're hypothetically using T-Mobile (and this also applies to many other ISPs and many LTAs) then the odds are very high that you're using an IP address which has never been used before. With T-Mobile, which is not unusually large by any means, you belong to at least one /32 range which contains a number of IP addresses so big that it has 30 digits. These ranges contain a huge number of users. At the other extreme you have some countries with only a handful of IPs, which everyone uses. These IPs also typically contain a huge number of users. TLDR; is someone is using a single IP on their own then we'll probably just block it, otherwise you're talking about matching a huge number of users. -- zzuuzz (talk) 03:20, 23 November 2024 (UTC)
- As I understand it, if you're hypothetically using T-Mobile, then you're not editing, because someone range-blocked the whole network in pursuit of a vandal(s). See Wikipedia:Advice to T-Mobile IPv6 users. WhatamIdoing (talk) 03:36, 23 November 2024 (UTC)
- T-Mobile USA is a perennial favourite of many of the most despicable LTAs, but that's besides the point. New users with an account can actually edit from T-Mobile. They can also edit from Jio, or Deutsche Telecom, Vodafone, or many other huge networks. -- zzuuzz (talk) 03:50, 23 November 2024 (UTC)
- As I understand it, if you're hypothetically using T-Mobile, then you're not editing, because someone range-blocked the whole network in pursuit of a vandal(s). See Wikipedia:Advice to T-Mobile IPv6 users. WhatamIdoing (talk) 03:36, 23 November 2024 (UTC)
- We already have autoblock. For cases it doesn't catch, there's an additional manual layer of blocking, where if a sock is caught on an IP that's been used before but wasn't caught by autoblock, a checkuser will block the IP if it's technically feasible, sometimes for months or years at a time. Beyond that, I don't think you can imagine just how often "someone edits on a shared IP used by a previous sock". I'm doing that right now, probably, because I'm editing through T-Mobile. Basically anyone who's ever edited in India or Nigeria has been on an IP used by a previous sock. Basically anyone who's used a large institution's WiFi. There is not any way to weed through all that noise with automation. -- Tamzin[cetacean needed] (they|xe) 05:54, 22 November 2024 (UTC)
- I would assume that IT experts can work out a way to automate CheckUser. If someone edits on a shared IP used by a previous sock that should be flagged and human CheckUsers notified so they can look at the edits and the previous sock edits and warn or block as necessary. Mztourist (talk) 05:46, 22 November 2024 (UTC)
- How would it be automated? We can't just block everyone who even sometimes shares an IP with someone, which is most editors once you factor in mobile editing and institutional WiFi. Even if we had a system that told checkusers about all shared-IP situations and asked them to investigate, what are they investigating for? The vast majority of IP overlaps will be entirely innocent, often people who don't even know each other. There's no way for a checkuser to find any signal in all that noise. So the only way a system like this would work is if checkusers manually identified IP ranges that are being used by LTAs, and then placed blocks on those ranges to restrict them from account creation... Which is what already happens. -- Tamzin[cetacean needed] (they|xe) 04:58, 22 November 2024 (UTC)
- Why can't it be automated? What are the privacy issues and what would WMF concerns be? There has to be a better system than SPI which imposes a huge burden on the filer (and often fails to catch socks) while we just leave the door open for LTAs. Mztourist (talk) 04:39, 22 November 2024 (UTC)
- Would violate the policy WP:NOTFISHING. –Novem Linguae (talk) 04:43, 22 November 2024 (UTC)
- It would apply to every new User as a protective measure against sockpuppetry, like a credit check before you get a card/overdraft. WP:NOTFISHING is archaic like the whole burdensome SPI system that forces honest users to do all the hard work of proving sockpuppetry while socks and vandals just keep being welcomed in under WP:AGF. Mztourist (talk) 05:46, 22 November 2024 (UTC)
- What you're suggesting is to just inundate checkusers with thousands of cases. The suggestion (as I understand it) removes burden from SPI filers by adding a disproportional burden on checkusers, who are already an overworked group. If you're suggesting an automated solution, then I believe IP blocks/IP range blocks and autoblock (discussed by Tamzin, above) already cover enough. It's quite hard to weigh up what you're really suggesting because it feels very vague without much detail - it sounds like you're just saying "a new SPI should be opened for every new user and IP, forever" which is not really a workable solution (for instance, 50 accounts were made in the last 15 minutes, which is about one every 18 seconds) BugGhost🦗👻 18:12, 22 November 2024 (UTC)
- And most of those accounts will make zero, one, or two edits, and then never be used again. Even if we liked this idea, doing it for every single account creation would be a waste of resources. WhatamIdoing (talk) 23:43, 22 November 2024 (UTC)
- What you're suggesting is to just inundate checkusers with thousands of cases. The suggestion (as I understand it) removes burden from SPI filers by adding a disproportional burden on checkusers, who are already an overworked group. If you're suggesting an automated solution, then I believe IP blocks/IP range blocks and autoblock (discussed by Tamzin, above) already cover enough. It's quite hard to weigh up what you're really suggesting because it feels very vague without much detail - it sounds like you're just saying "a new SPI should be opened for every new user and IP, forever" which is not really a workable solution (for instance, 50 accounts were made in the last 15 minutes, which is about one every 18 seconds) BugGhost🦗👻 18:12, 22 November 2024 (UTC)
- It would apply to every new User as a protective measure against sockpuppetry, like a credit check before you get a card/overdraft. WP:NOTFISHING is archaic like the whole burdensome SPI system that forces honest users to do all the hard work of proving sockpuppetry while socks and vandals just keep being welcomed in under WP:AGF. Mztourist (talk) 05:46, 22 November 2024 (UTC)
- No, they should not. voorts (talk/contributions) 17:23, 22 November 2024 (UTC)
- This, very bluntly, flies in the face of WMF policy with regards to use/protection of PII, and as noted by Tamzin this would result in frankly obscene amounts of collateral damage. You have absolutely no idea how frequently IP addresses get passed around (especially in the developing world or on T Mobile), such that it could feasibly have three different, unrelated, people on it over the course of a day or so. —Jéské Couriano v^_^v threads critiques 18:59, 22 November 2024 (UTC)
- Just out of curiosity: If a certain case of IPs spamming at Help Desk is any indication, would a CU be able to stop that in its track? 2601AC47 (talk|contribs) Isn't a IP anon 14:29, 23 November 2024 (UTC)
- CU's use their tools to identify socks when technical proof is necessary. The problem you're linking to is caused by one particular LTA account who is extremely obvious and doesn't really require technical proof to identify - check users would just be able to provide evidence for something that is already easy to spot. There's an essay on the distinction over at WP:DUCK BugGhost🦗👻 14:45, 23 November 2024 (UTC)
- @2601AC47: No, and that is because the user in question's MO is to abuse VPNs. Checkuser is worthless in this case because of that (but the IPs can and should be blocked for 1yr as VPNs). —Jéské Couriano v^_^v threads critiques 19:35, 26 November 2024 (UTC)
- LTA MAB is using a peer-to-peer VPN service which is similar to TOR. Blocking peer-to-peer VPN service endpoint IP addresses carries a higher risk of collateral damage because those aren't assigned to the VPN provider but rather a third party ISP who is likely to dynamically reassign the blocked address to a completely innocent party. 216.126.35.235 (talk) 00:22, 27 November 2024 (UTC)
- I slightly oppose this idea. This is not Reddit where socks are immediately banned or shadowbanned outright. Reddit doesn't have WP:DUCK as any wiki does. Ahri Boy (talk) 00:14, 25 November 2024 (UTC)
- How do you know this is how Reddit deals with ban and suspension evasion? They use advanced techniques such as device and IP fingerprinting to ban and suspend users in under an hour. 2600:1700:69F1:1410:5D40:53D:B27E:D147 (talk) 23:47, 28 November 2024 (UTC)
- I can see where this is coming from, but we must realise that checkuser is not magic pixie dust nor is it meant for fishing. - Ratnahastin (talk) 04:49, 27 November 2024 (UTC)
- The question I ask myself is why must we realize that it is not meant for fishing? To catch fish, you need to fish. The no-fishing rule is not fit for purpose, nor is it a rule that other organizations that actively search for ban evasion use. Machines can do the fishing. They only need to show us the fish they caught. Sean.hoyland (talk) 05:24, 27 November 2024 (UTC)
- I think for the same reason we don't want governments to be reading our mail and emails. If we checkuser everybody, then nobody has any privacy. Donald Albury 20:20, 27 November 2024 (UTC)
- The question I ask myself is why must we realize that it is not meant for fishing? To catch fish, you need to fish. The no-fishing rule is not fit for purpose, nor is it a rule that other organizations that actively search for ban evasion use. Machines can do the fishing. They only need to show us the fish they caught. Sean.hoyland (talk) 05:24, 27 November 2024 (UTC)
I sympathize with Mztourist. The current system is less effective than it needs to be. Ban evading actors make a lot of edits, they are dedicated hard-working folk in contentious topic areas. They can make up nearly 10% of new extendedconfirmed actors some years and the quicker an actor becomes EC the more likely they are to be blocked later for ban evasion. Their presence splits the community into two classes, the sanctionable and the unsanctionable with completely different payoff matrices. This has many consequences in contentious topic areas and significantly impacts the dynamics. The current rules are probably not good rules. Other systems have things like a 'commitment to authenticity' and actively search for ban evasion. It's tempting to burn it all down and start again, but with what? Having said that, the SPI folks do a great job. The average time from being granted extendedconfirmed to being blocked for ban evasion seems to be going down. Sean.hoyland (talk) 18:28, 22 November 2024 (UTC)
- I confess that I am doubtful about that 10% claim. WhatamIdoing (talk) 23:43, 22 November 2024 (UTC)
- WhatamIdoing, me too. I'm doubtful about everything I say because I've noticed that the chance it is slightly to hugely wrong is quite high. The EC numbers are work in progress, but I got distracted. The description "nearly 10% of new extendedconfirmed actors" is a bit misleading, because 'new' doesn't really mean new actors. It means actors that acquired EC for a given year, so newly acquired privileges. They might have registered in previous years. Also, I don't have 100% confidence in the way count EC grants because there are some edge cases, and I'm ignoring sysops. But anyway, the statement was based on this data of questionable precision. And the statement about a potential relationship between speed of EC acquisition and probability of being blocked is based on this data of questionable precision. And of course, currently undetected socks are not included, and there will be many. Sean.hoyland (talk) 03:39, 23 November 2024 (UTC)
- I'm not interested in clicking through to a Google file. Here's my back-of-the-envelope calculation: We have something like 120K accounts that would qualify for EXTCONF. Most of these are no longer active, and many stopped editing so long ago that they don't actually have the user right.
- Wikipedia is almost 24 years old. That makes convenient math: On average, since inception, 5K editors have achieved EXTCONF levels each year.
- If the 10% estimate is true, then 500 accounts per year – about 10 per week – are being created by banned editors and going undetected long enough for the accounts to make 500 edits and to work in CTOP areas. Do we even have enough WP:BANNED editors to make it plausible to expect banned editors to bring 500 accounts a year up to EXTCONF levels (plus however many accounts get started but are detected before then)? WhatamIdoing (talk) 03:53, 23 November 2024 (UTC)
- Suit yourself. I'm not interested in what interests other people or back of the envelope calculations. I'm interested in understanding the state of a system over time using evidence-based approaches by extracting data from the system itself. Let the data speak for itself. It has a lot to tell us. Then it is possible to test hypotheses and make evidence-based decisions. Sean.hoyland (talk) 04:13, 23 November 2024 (UTC)
- @WhatamIdoing, there's a sockmaster in the IPA CTOP who has made more than 100 socks. 500 new XC socks every year doesn't seem that much of a stretch in comparison. -- asilvering (talk) 19:12, 23 November 2024 (UTC)
- More than 100 XC socks? Or more than 100 detected socks, including socks with zero edits?
- Making a lot of accounts isn't super unusual, but it's a lot of work to get 100 accounts up to 500+ edits. Making 50,000 edits is a lot, even if it's your full-time job. WhatamIdoing (talk) 01:59, 24 November 2024 (UTC)
- Lots of users get it done in a couple of days, often through vandal fighting tools. It really is not that many when the edits are mostly mindless. nableezy - 00:18, 26 November 2024 (UTC)
- But that's kind of my point: "A couple of days", times 100 accounts, means 200–300 days per year. If you work five days per week and 52 weeks per year, that's 260 work days. This might be possible, but it's a full-time job.
- Since the 30-day limit is something that can't be achieved through effort, I wonder if a sudden change to, say, 6 months would produce a five-month reprieve. WhatamIdoing (talk) 02:23, 26 November 2024 (UTC)
- Who says it’s only one at a time? Icewhiz for example has had 4 plus accounts active at a time. nableezy - 02:25, 26 November 2024 (UTC)
- There is some data about ban evasion timelines for some sockmasters in PIA that show how accounts are operated in parallel. Operating multiple accounts concurrently seems to be the norm. Sean.hoyland (talk) 04:31, 26 November 2024 (UTC)
- Imagine that it takes an average of one minute to make a (convincing) edit. That means that 500 edits = 8.33 hours, i.e., more than one full work day.
- Imagine, too, that having reached this point, you actually need to spend some time using your newly EXTCONF account. This, too, takes time.
- If you operate several accounts at once, that means:
- You spend an hour editing from Account1. You spend the next hour editing from Account2. You spend another hour editing from Account3. You spend your fourth hour editing from Account4. Then you take a break for lunch, and come back to edit from Accounts 5 through 8.
- At the end of the day, you have brought 8 accounts up to 60 edits (12% of the minimum goal). And maybe one of them got blocked, too, which is lost effort. At this rate, it would take you an entire year of full-time work to get 100 EXTCONF accounts, even though you are operating multiple accounts concurrently. Doing 50 edits per day in 10 accounts is not faster than doing 500 edits in 1 account. It's the same amount of work. WhatamIdoing (talk) 05:13, 29 November 2024 (UTC)
- Sure it’s an effort, though it doesn’t take a minute an edit. But I’m not sure why I need to imagine something that has happened multiple times already. Icewhiz most recently had like 4-5 EC accounts active, and there are probably several more. Yes, there is an effort there. But also yes, it keeps happening. nableezy - 15:00, 29 November 2024 (UTC)
- My point is that "4-5 EC accounts" is not "100". WhatamIdoing (talk) 19:31, 30 November 2024 (UTC)
- It’s 4-5 at a time for a single sock master. Check the Icewhiz SPI for how many that adds up to over time. nableezy - 20:16, 30 November 2024 (UTC)
- My point is that "4-5 EC accounts" is not "100". WhatamIdoing (talk) 19:31, 30 November 2024 (UTC)
- Sure it’s an effort, though it doesn’t take a minute an edit. But I’m not sure why I need to imagine something that has happened multiple times already. Icewhiz most recently had like 4-5 EC accounts active, and there are probably several more. Yes, there is an effort there. But also yes, it keeps happening. nableezy - 15:00, 29 November 2024 (UTC)
- There is some data about ban evasion timelines for some sockmasters in PIA that show how accounts are operated in parallel. Operating multiple accounts concurrently seems to be the norm. Sean.hoyland (talk) 04:31, 26 November 2024 (UTC)
- Many of our frequent fliers are already adept at warehousing accounts for months or even years, so a bump in the time period probably won't make much off a difference. Additionally, and without going into detail publicly, there are several methods whereby semi- or even fully-automated editing can be used to get to 500 edits with a minimum of effort, or at least well within script-kid territory. Because so many of those are obvious on inspection some will assume that all of them are, but there are a number of rather subtle cases that have come up over the years and it would be foolish to assume that it isn't ongoing. 184.152.68.190 (talk) 17:31, 28 November 2024 (UTC)
- Who says it’s only one at a time? Icewhiz for example has had 4 plus accounts active at a time. nableezy - 02:25, 26 November 2024 (UTC)
- Lots of users get it done in a couple of days, often through vandal fighting tools. It really is not that many when the edits are mostly mindless. nableezy - 00:18, 26 November 2024 (UTC)
- WhatamIdoing, me too. I'm doubtful about everything I say because I've noticed that the chance it is slightly to hugely wrong is quite high. The EC numbers are work in progress, but I got distracted. The description "nearly 10% of new extendedconfirmed actors" is a bit misleading, because 'new' doesn't really mean new actors. It means actors that acquired EC for a given year, so newly acquired privileges. They might have registered in previous years. Also, I don't have 100% confidence in the way count EC grants because there are some edge cases, and I'm ignoring sysops. But anyway, the statement was based on this data of questionable precision. And the statement about a potential relationship between speed of EC acquisition and probability of being blocked is based on this data of questionable precision. And of course, currently undetected socks are not included, and there will be many. Sean.hoyland (talk) 03:39, 23 November 2024 (UTC)
Also, if we divide the space into contentious vs not-contentious, maybe a one size fits all CU policy doesn't make sense. Sean.hoyland (talk) 18:55, 22 November 2024 (UTC)
Terrible idea. Let's AGF that most new users are here to improve Wikipedia instead of damage it. Some1 (talk) 18:33, 22 November 2024 (UTC)
- Ban evading actors who employ deception via sockpuppetry in the WP:PIA topic area are here to improve Wikipedia, from their perspective, rather than damage it. There is no need to use faith. There are statistics. There is a probability that a 'new user' is employing ban evasion. Sean.hoyland (talk) 18:46, 22 November 2024 (UTC)
- My initial comment wasn't a direct response to yours, but new users and IPs won't be able to edit in the WP:PIA topic area anyway since they need to be extended confirmed. Some1 (talk) 20:08, 22 November 2024 (UTC)
- Let's not hold up the way PIA handles new users and IPs, in which they are allowed to post to talk pages but then have their talk page post removed if it doesn't fall within very specific parameters, as some sort of model. CMD (talk) 02:51, 23 November 2024 (UTC)
- My initial comment wasn't a direct response to yours, but new users and IPs won't be able to edit in the WP:PIA topic area anyway since they need to be extended confirmed. Some1 (talk) 20:08, 22 November 2024 (UTC)
Strongly support automatically checkusering all active users (new and existing) at regular intervals. If it were automated -- e.g., a script runs that compares IPs, user agent, other typical subscriber info -- there would be no privacy violation, because that information doesn't have to be disclosed to any human beings. Only the "hits" can be forwarded to the CU team for follow-up. I'd run that script daily. If the policy forbids it, we should change the policy to allow it. It's mind-boggling that Wikipedia doesn't do this already. It's a basic security precaution. (Also, email-required registration and get rid of IP editing.) Levivich (talk) 02:39, 23 November 2024 (UTC)
- I don't think you've been reading the comments from people who know what they are talking about. There would be hundreds, at least, of hits per day that would require human checking. The policy that prohibits this sort of massive breach of privacy is the Foundation's and so not one that en.wp could change even if it were a good idea (which it isn't). Thryduulf (talk) 03:10, 23 November 2024 (UTC)
- A computer can be programmed to check for similarities or patterns in subscriber info (IP, etc), and in editing activity (time cards, etc), and content of edits and talk page posts (like the existing language similarity tool), with various degrees of certainty in the same way the Cluebot does with ORES when it's reverting vandalism. And the threshold can be set so it only forwards matches of a certain certainty to human CUs for review, so as not to overwhelm the humans. The WMF can make this happen with just $1 million of its $180 million per year (and it wouldn't be violating its own policies if it did so). Enwiki could ask for it, other projects might join too. Levivich (talk) 05:24, 23 November 2024 (UTC)
- "Oh now I see what you mean, Levivich, good point, I guess you know what you're talking about, after all."
- "Thanks, Thryduulf!" Levivich (talk) 17:42, 23 November 2024 (UTC)
- I seem to have missed this comment, sorry. However I am very sceptical that sockpuppet detection is meaningfully automatable. From what CUs say it is as much art as science (which is why SPI cases can result in determinations like "possilikely"). This is the sort of thing that is difficult (at best) to automate. Additionally the only way to reliably develop such automation would be for humans analyse and process a massive amount of data from accounts that both are and are not sockpuppets and classify results as one or the other, and that anaylsis would be a massive privacy violation on its own. Assuming you have developed this magic computer that can assign a likelihood of any editor being a sock of someone who has edited in the last three months (data older than that is deleted) on a percentage scale, you then have to decide what level is appropriate to send to humans to check. Say for the sake of argument it is 75%, that means roughly one in four people being accused are innocent and are having their privacy impinged unnecessarily - and how many CUs are needed to deal with this caseload? Do we have enough? SPI isn't exactly backlog free and there aren't hoards of people volunteering for the role (although unbreaking RFA might help with this in the medium to long term). The more you reduce the number sent to CUs to investigate, the less benefit there is over the status quo.
- In addition to all the above, how similar is "similar" in terms of articles edited, writing style, timecard, etc? How are you avoiding legitimate sockpuppets? Thryduulf (talk) 18:44, 23 November 2024 (UTC)
- You know this already but for anyone reading this who doesn't: when a CU "checks" somebody, it's not like they send a signal out to that person's computer to go sniffing around. In fact, all the subscriber info (IP address, etc.) is already logged on the WMF's server logs (as with any website). A CU "check" just means a volunteer CU gets to look at a portion of those logs (to look up a particular account's subscriber info). That's the privacy concern: we have rules, rightfully so, about when volunteer CUs (not WMF staff) can read the server logs (or portions of them). Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs. Privacy is only an issue when those logs are revealed to volunteer CUs.
- So... feeding the logs into software in order to train the software doesn't violate anyone's policy. It's just letting a computer read its own files. Human verification of the training outcomes also doesn't have to violate anyone's privacy -- just don't use volunteer CUs to do it, use WMF staff. Or, anonymize the training data (changing usernames to "Example1", "Example2", etc.). Or use historical data -- which would certainly be part of the training, since the most effective way would be to put known socks into the training data to see if the computer catches them.
- Anyway, training the system won't violate anyone's privacy.
- As for the hit rate -- 75% would be way, way too low. We'd be looking for definitely over 90% or 95%, and probably more like 99.something percent. Cluebot doesn't get vandalism wrong 1 out of 4 times, neither should CluebotCU. Heck, if CluebotCU can't do better than 75%, it's not worth doing. A more interesting question is whether the 99.something% hit rate would be helpful to CUs, or whether that would only catch the socks that are so obvious you don't even need CU to recognize them. Only testing in the field would tell.
- But overall, AI looking for patterns, and checking subscriber info, edit patterns, and the content of edits, would be very helpful in tamping down on socking, because the computer can make far more checks than a human (a computer can look at 1,000 accounts and a 100,000 edits no problem, which no human can do), it'll be less biased than humans, and it can do it all without violating anyone's privacy -- in fact, lowering the privacy violations by lowering the false positives, sending only high-probability (90%+, not 75%+) to humans for review. And it can all be done with existing technology, and the WMF has the money to do it. Levivich (talk) 19:38, 23 November 2024 (UTC)
- The more you write the clearer you make it that you don't understand checkuser or the WMF's policies regarding privacy. It's also clear that I'm not going to convince you that this is unworkable so I'll stop trying. Thryduulf (talk) 20:42, 23 November 2024 (UTC)
- Yeah it's weird how repeatedly insulting me hasn't convinced me yet. Levivich (talk) 20:57, 23 November 2024 (UTC)
- If you are are unable to distinguish between reasoned disagreement and insults, then it's not at all weird that reasoned disagreement fails to convince you. Thryduulf (talk) 22:44, 23 November 2024 (UTC)
- Yeah it's weird how repeatedly insulting me hasn't convinced me yet. Levivich (talk) 20:57, 23 November 2024 (UTC)
- @Levivich: Whatever existing data set we have has too many biases to be useful for this, and this is going to be prone to false positives. AI needs lots of data to be meaningfully trained. Also, AI here would be learning a function; when the output is not in fact a function of the input, there's nothing for an AI model to target, and this is very much the case here. On Wikidata, where I am a CheckUser, almost all edit summaries are automated even for human edits (just like clicking the rollback button is, or undoing an edit is by default), and it is very hard to meaningfully tell whether someone is a sock or not without highly case-specific analysis. No AI model is better than the data it's trained on.
- Also, about the privacy policy: you are completely incorrect when you
"Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs"
. Staff can only access that information on a need to know basis, just like CheckUsers, and data privacy laws like the EU's and California's means you cannot just do whatever random thing you want with the information you collect from users about them.--Jasper Deng (talk) 21:56, 23 November 2024 (UTC)- So which part of the wmf:Privacy Policy would prohibit the WMF from developing an AI that looks at server logs to find socks? Do you want me to quote to you the portions that explicitly disclose that the WMF uses personal information to develop tools and improve security? Levivich (talk) 22:02, 23 November 2024 (UTC)
- I mean yeah that would probably be more productive than snarky bickering BugGhost🦗👻 22:05, 23 November 2024 (UTC)
- @Levivich: Did you read the part where I mentioned privacy laws? Also, in this industry no one is allowed unfettered usage of private data even internally; there are internal policies that govern this that are broadly similar to the privacy policy. It's one thing to test a proposed tool on an IP address like Special:Contribs/2001:db8::/32, but it's another to train an AI model on it. Arguably an equally big privacy concern is the usage of new data from new users after the model is trained and brought online. The foundation is already hiding IP addresses by default even for anonymous users soon, and they will not undermine that mission through a tool like this. Ultimately, the Board of Trustees has to assume legal responsibility and liability for such a thing; put yourself in their position and think of whether they'd like the liability of something like this.--Jasper Deng (talk) 22:13, 23 November 2024 (UTC)
- So can you quote a part of the privacy policy, or a part of privacy laws, or anything, that would prohibit feeding server logs into a "Cluebot-CU" to find socking?
- Because I can quote the part of the wmf:Privacy Policy that allows it, and it's a lot:
Yeah that's a lot. Then there's this whole FAQ that saysWe may use your public contributions, either aggregated with the public contributions of others or individually, to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ...
Because of how browsers work, we receive some information automatically when you visit the Wikimedia Sites ... This information includes the type of device you are using (possibly including unique device identification numbers, for some beta versions of our mobile applications), the type and version of your browser, your browser's language preference, the type and version of your device's operating system, in some cases the name of your internet service provider or mobile carrier, the website that referred you to the Wikimedia Sites, which pages you request and visit, and the date and time of each request you make to the Wikimedia Sites.
Put simply, we use this information to enhance your experience with Wikimedia Sites. For example, we use this information to administer the sites, provide greater security, and fight vandalism; optimize mobile applications, customize content and set language preferences, test features to see what works, and improve performance; understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites, and analyze trends. ...
We actively collect some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage. ... Depending on which technology we use, locally stored data may include text, Personal Information (like your IP address), and information about your use of the Wikimedia Sites (like your username or the time of your visit). ... We use this information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. ...
We and our service providers use your information ... to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ... To fight spam, identity theft, malware and other kinds of abuse. ... To test features to see what works, understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites and analyze trends. ...
When you visit any Wikimedia Site, we automatically receive the IP address of the device (or your proxy server) you are using to access the Internet, which could be used to infer your geographical location. ... We use this location information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. For example, we use this information to provide greater security, optimize mobile applications, and learn how to expand and better support Wikimedia communities. ...
We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use, this Privacy Policy, or any Wikimedia Foundation or user community-based policies. ... We may also disclose your Personal Information if we reasonably believe it necessary to detect, prevent, or otherwise assess and address potential spam, malware, fraud, abuse, unlawful activity, and security or technical concerns. ... To facilitate their work, we give some developers limited access to systems that contain your Personal Information, but only as reasonably necessary for them to develop and contribute to the Wikimedia Sites. ...
It is important for us to be able to make sure everyone plays by the same rules, and sometimes that means we need to investigate and share specific users' information to ensure that they are.
For example, user information may be shared when a CheckUser is investigating abuse on a Project, such as suspected use of malicious "sockpuppets" (duplicate accounts), vandalism, harassment of other users, or disruptive behavior. If a user is found to be violating our Terms of Use or other relevant policy, the user's Personal Information may be released to a service provider, carrier, or other third-party entity, for example, to assist in the targeting of IP blocks or to launch a complaint to the relevant Internet Service Provider.
- So using IP addresses, etc., to develop new tools, to test features, to fight violations of the Terms of Use, and disclosing that info to Checkusers... all explicitly permitted by the Privacy Policy. Levivich (talk) 22:22, 23 November 2024 (UTC)
- @Levivich:
"We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use"
– "reasonably believed to be necessary" is not going to hold up in court when it's sweepingly applied to everyone. This doesn't even take into consideration the laws I mentioned, like GDPR. I'm not a lawyer, and I'm guessing neither are you. If you want to be the one assuming the legal liability for this, contact the board today and sign the contract. Even then they would probably not agree to such an arrangement. So you're preaching to the choir: only the foundation could even consider assuming this risk. Also, it's clear that you do not have a single idea of how developing something like this works if you think it can be done for $1 million. Something this complex has to be done right and tech salaries and computing resources are expensive.--Jasper Deng (talk) 22:28, 23 November 2024 (UTC)- What I am suggesting does not involve sharing everyone's data with Checkusers. It's pretty obvious that looking at their own server logs is "necessary to enforce or investigate potential violations of our Terms of Use". Five people is how big the WMF's wmf:Machine Learning team is, @ $200k each, $1m/year covers it. Five people is enough for that team to improve ORES, so another five-person team dedicated to "ORES-CU" seems a reasonable place to start. They could double that, and still have like $180M left over. Levivich (talk) 22:40, 23 November 2024 (UTC)
- @Levivich: Yeah no, lol. $200k each is not a very competitive total compensation, considering that that needs to include benefits, health insurance, etc. This doesn't include their manager or the hefty hardware required to run ML workflows. It doesn't include the legal support required given the data privacy law compliance needed. Capriciously looking at the logs does not count; accessing data of users the foundation cannot reasonably have said to be likely to cause abuse is not permissible. This all aside from the bias and other data quality issues at hand here. You can delude yourself all you want, but nature cannot be fooled. I'm finished arguing with you anyways, because this proposal is either way dead on arrival.--Jasper Deng (talk) 23:45, 23 November 2024 (UTC)
- @Jasper Deng, haggling over the math here isn't really important. You could quintuple the figures @Levivich gave and the Foundation would still have millions upon millions of dollars left over. -- asilvering (talk) 23:48, 23 November 2024 (UTC)
- @Asilvering: The point I'm making is Levivich does not understand the complexity behind this kind of thing and thus his arguments are not to be given weight by the closer. Jasper Deng (talk) 23:56, 23 November 2024 (UTC)
- As a statistician/data scientist, @Levivich is correct about the technical side of this—building an ML algorithm to detect sockpuppets would be pretty easy. Duplicate user algorithms like these are common across many websites. For a basic classification task like this (basically an ML 101 homework problem), I think $1 million is about right. As a bonus, the same tools could be used to identify and correct for possible canvasing or brigading, which behaves a lot like sockpuppetry from a statistical perspective. A similar algorithm is already used by Twitter's community notes feature.
- IANAL, so I can't comment on the legal side of this, and I can't comment on whether that money would be better-spent elsewhere since I don't know what the WMF budget looks like. Overall though, the technical implementation wouldn't be a major hurdle. – Closed Limelike Curves (talk) 20:44, 24 November 2024 (UTC)
- Third-party services like Sift.com provide this kind of algorithm-based account fraud protection as an alternative to building and maintaining internally. czar 23:41, 24 November 2024 (UTC)
- Building such a model is only a small part of a real production system. If this system is to operate on all account creations, it needs to be at least as reliable as the existing systems that handle account creations. As you probably know, data scientists developing such a model need to be supported by software engineers and site reliability engineers supporting the actual system. Then you have the problem of new sockers who are not on the list of sockmasters to check against. Non-English-language speakers often would be put at a disadvantage too. It's not as trivial as you make it out to be, thus I stand by my estimate.--Jasper Deng (talk) 06:59, 25 November 2024 (UTC)
- None of you have accounted for Hofstadter's law.
- I don't think we need to spend more time speculating about a system that WMF Legal is extremely unlikely to accept. Even if they did, it wouldn't exist until several years from now. Instead, let's try to think of things that we can do ourselves, or with only a very little assistance. Small, lightweight projects with full community control can help us now, and if we prove that ____ works, the WMF might be willing to adopt and expand it later. WhatamIdoing (talk) 23:39, 25 November 2024 (UTC)
- That's a mistake -- doing the same thing Wikipedia has been doing for 20+ years. The mistake is in leaving it to volunteers to catch sockpuppetry, rather than insisting that the WMF devote significant resources to it. And it's a mistake because the one thing we volunteers can't do, that the WMF can do, is comb through the server logs looking for patterns. Levivich (talk) 23:44, 25 November 2024 (UTC)
- Not sure about the "building an ML algorithm to detect sockpuppets would be pretty easy" part, but I admire the optimism. It is certainly the case that it is possible, and people have done it with a surprising level of success a very long time ago in ML terms e.g. https://doi.org/10.1016/j.knosys.2018.03.002. These projects tend to rely on the category graph to distinguish sock and non-sock sets for training, the categorization of accounts as confirmed or suspected socks. However, the category graph is woefully incomplete i.e. there is information in the logs that is not reflected in the graph, so ensuring that all ban evasion accounts are properly categorized as such might help a bit. Sean.hoyland (talk) 03:58, 26 November 2024 (UTC)
- Thankfully, we wouldn't have to build an ML algorithm, we can just use one of the existing ones. Some are even open source. Or WMF could use a third party service like the aforementioned sift.com. Levivich (talk) 16:17, 26 November 2024 (UTC)
- Let me guess: Essentially, you would like their machine-learning team to use Sift's
AI-Powered Fraud Protection
, which from what I can glance, handlessafeguarding subscriptions to defending digital content and in-app purchases
andhelps businesses reduce friction and stop sophisticated fraud attacks that gut growth
, to provide the ability for us toautomatically checkuser all active users
? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:25, 26 November 2024 (UTC)- The WMF already has the ability to "automatically checkuser all users" (the verb "checkuser" just means "look at the server logs"), I'm suggesting they use it. And that they use it in a sophisticated way, employing (existing, open source or commercially available) AI/ML technologies, like the same kind we already use to automatically revert vandalism. Contrary to claims here, doing so would not be illegal or even expensive (comparatively, for the WMF). Levivich (talk) 16:40, 26 November 2024 (UTC)
- So, in my attempt to get things set right and steer towards a consensus that is satisfactory, I sincerely follow-up: What lies beyond that in this vast, uncharted sea? And could this mean any more in the next 5 years? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:49, 26 November 2024 (UTC)
- What lies beyond is mw:Extension:SimilarEditors. Levivich (talk) 17:26, 26 November 2024 (UTC)
- So, @2601AC47, I think the answer to your question is "tell the WMF we really, really, really would like more attention to sockpuppetry and IP abuse from the ML team". -- asilvering (talk) 17:31, 26 November 2024 (UTC)
- Which I don't suppose someone can at the next board meeting on December 11? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 18:00, 26 November 2024 (UTC)
- So, @2601AC47, I think the answer to your question is "tell the WMF we really, really, really would like more attention to sockpuppetry and IP abuse from the ML team". -- asilvering (talk) 17:31, 26 November 2024 (UTC)
- What lies beyond is mw:Extension:SimilarEditors. Levivich (talk) 17:26, 26 November 2024 (UTC)
- So, in my attempt to get things set right and steer towards a consensus that is satisfactory, I sincerely follow-up: What lies beyond that in this vast, uncharted sea? And could this mean any more in the next 5 years? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:49, 26 November 2024 (UTC)
- The WMF already has the ability to "automatically checkuser all users" (the verb "checkuser" just means "look at the server logs"), I'm suggesting they use it. And that they use it in a sophisticated way, employing (existing, open source or commercially available) AI/ML technologies, like the same kind we already use to automatically revert vandalism. Contrary to claims here, doing so would not be illegal or even expensive (comparatively, for the WMF). Levivich (talk) 16:40, 26 November 2024 (UTC)
- I may also point to this, where they mention
development in other areas, such as social media features and machine learning expertise
. 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:36, 26 November 2024 (UTC)- e.g. m:Research:Sockpuppet_detection_in_Wikimedia_projects Sean.hoyland (talk) 17:02, 26 November 2024 (UTC)
- And that mentions Socksfinder, still in beta it seems. 2601AC47 (talk·contribs·my rights) Isn't a IP anon 17:10, 26 November 2024 (UTC)
- 3 days! When I first posted my comment and some editors responded that I didn't know what I was talking about, it can't be done, it'd violate the privacy policy and privacy laws, WMF Legal would never allow it... I was wondering how long it would take before somebody pointed out that this thing that can't be done has already been done and has been under development for at least 7 years now.
- Of course it's already under development, it's pretty obvious that the same Wikipedia that developed ClueBot, one of the world's earlier and more successful examples of ML applications, would try to employ ML to fight multiple-account abuse. I mean, I'm obviously not gonna be the first person to think of this "innovation"!
- Anyway, it took 3 days. Thanks, Sean! Levivich (talk) 17:31, 26 November 2024 (UTC)
- e.g. m:Research:Sockpuppet_detection_in_Wikimedia_projects Sean.hoyland (talk) 17:02, 26 November 2024 (UTC)
- Let me guess: Essentially, you would like their machine-learning team to use Sift's
- Thankfully, we wouldn't have to build an ML algorithm, we can just use one of the existing ones. Some are even open source. Or WMF could use a third party service like the aforementioned sift.com. Levivich (talk) 16:17, 26 November 2024 (UTC)
- Unlike what is being proposed, SimilarEditors only works based on publicly available data (e.g. similarities in editing patterns), and not IP data. To quote the page Sean linked,
in the model's current form, we are only considering public data, but most saliently private data such as IP addresses or user-agent information are features currently used by checkusers that could be later (carefully) incorporated into the models
.So, not only the current model doesn't look at IP data, the research project also acknowledges that actually using such data should only be done in a "careful" way, because of those very same privacy policy issues quoted above.On the ML side, however, this does proves that it's being worked on, and I'm honestly not surprised at all that the WMF is working on machine learning-based tools to detect sockpuppets. Chaotic Enby (talk · contribs) 17:50, 26 November 2024 (UTC)- Right. We should ask WMF to do the
later (carefully) incorporated into the models
part (especially since it's now later). BTW, the SimilarUsers API already pulls IP and other metadata. SimilarExtensions (a tool that uses the API) doesn't release that information to CheckUsers, by design. And that's a good thing, we can't just release all IPs to CheckUsers, it does indeed have to be done carefully. But user metadata can be used. What I'm suggesting is that the WMF should proceed to develop these types of tools (including the careful use of user metadata). Levivich (talk) 17:57, 26 November 2024 (UTC)
- Right. We should ask WMF to do the
- Not really clear that they're pulling IP data from logged-in users. The relevant sections reads:
This reads like they're collecting the username or IP depending on whether they're a logged-in user or an IP user. Chaotic Enby (talk · contribs) 18:14, 26 November 2024 (UTC)USER_METADATA
(203MB): for every user inCOEDIT_DATA
, this contains basic metadata about them (total number of edits in data, total number of pages edited, user or IP, timestamp range of edits). - In a few years people might look back on these days when we only had to deal with simple devious primates employing deception as the halcyon days. Sean.hoyland (talk) 18:33, 26 November 2024 (UTC)
- Not sure about the "building an ML algorithm to detect sockpuppets would be pretty easy" part, but I admire the optimism. It is certainly the case that it is possible, and people have done it with a surprising level of success a very long time ago in ML terms e.g. https://doi.org/10.1016/j.knosys.2018.03.002. These projects tend to rely on the category graph to distinguish sock and non-sock sets for training, the categorization of accounts as confirmed or suspected socks. However, the category graph is woefully incomplete i.e. there is information in the logs that is not reflected in the graph, so ensuring that all ban evasion accounts are properly categorized as such might help a bit. Sean.hoyland (talk) 03:58, 26 November 2024 (UTC)
- I assumed 1 million USD/year was accounting for Hofstadter's law several times over. Otherwise it feels wildly pessimistic. – Closed Limelike Curves (talk) 15:57, 26 November 2024 (UTC)
- That's a mistake -- doing the same thing Wikipedia has been doing for 20+ years. The mistake is in leaving it to volunteers to catch sockpuppetry, rather than insisting that the WMF devote significant resources to it. And it's a mistake because the one thing we volunteers can't do, that the WMF can do, is comb through the server logs looking for patterns. Levivich (talk) 23:44, 25 November 2024 (UTC)
- @Jasper Deng, haggling over the math here isn't really important. You could quintuple the figures @Levivich gave and the Foundation would still have millions upon millions of dollars left over. -- asilvering (talk) 23:48, 23 November 2024 (UTC)
- @Levivich: Yeah no, lol. $200k each is not a very competitive total compensation, considering that that needs to include benefits, health insurance, etc. This doesn't include their manager or the hefty hardware required to run ML workflows. It doesn't include the legal support required given the data privacy law compliance needed. Capriciously looking at the logs does not count; accessing data of users the foundation cannot reasonably have said to be likely to cause abuse is not permissible. This all aside from the bias and other data quality issues at hand here. You can delude yourself all you want, but nature cannot be fooled. I'm finished arguing with you anyways, because this proposal is either way dead on arrival.--Jasper Deng (talk) 23:45, 23 November 2024 (UTC)
- What I am suggesting does not involve sharing everyone's data with Checkusers. It's pretty obvious that looking at their own server logs is "necessary to enforce or investigate potential violations of our Terms of Use". Five people is how big the WMF's wmf:Machine Learning team is, @ $200k each, $1m/year covers it. Five people is enough for that team to improve ORES, so another five-person team dedicated to "ORES-CU" seems a reasonable place to start. They could double that, and still have like $180M left over. Levivich (talk) 22:40, 23 November 2024 (UTC)
- @Levivich:
- So which part of the wmf:Privacy Policy would prohibit the WMF from developing an AI that looks at server logs to find socks? Do you want me to quote to you the portions that explicitly disclose that the WMF uses personal information to develop tools and improve security? Levivich (talk) 22:02, 23 November 2024 (UTC)
- The more you write the clearer you make it that you don't understand checkuser or the WMF's policies regarding privacy. It's also clear that I'm not going to convince you that this is unworkable so I'll stop trying. Thryduulf (talk) 20:42, 23 November 2024 (UTC)
- A computer can be programmed to check for similarities or patterns in subscriber info (IP, etc), and in editing activity (time cards, etc), and content of edits and talk page posts (like the existing language similarity tool), with various degrees of certainty in the same way the Cluebot does with ORES when it's reverting vandalism. And the threshold can be set so it only forwards matches of a certain certainty to human CUs for review, so as not to overwhelm the humans. The WMF can make this happen with just $1 million of its $180 million per year (and it wouldn't be violating its own policies if it did so). Enwiki could ask for it, other projects might join too. Levivich (talk) 05:24, 23 November 2024 (UTC)
IP range 2600:1700:69F1:1410:0:0:0:0/64 blocked by a CU |
---|
The following discussion has been closed. Please do not modify it. |
|
- Any such system would be subject to numerous biases or be easily defeatable. Such an automated anti-abuse system would have to be exclusively a foundation initiative as only they have the resources for such a monumental undertaking. It would need its own team of developers.--Jasper Deng (talk) 18:57, 23 November 2024 (UTC)
Absolutely no chance that this would pass. WP:SNOW, even though there isn't a flood of opposes. There are two problems:
- The existing CheckUser team barely has the bandwidth for the existing SPI load. Doing this on every single new user would be impractical and would enable WP:LTA's by diverting valuable CheckUser bandwidth.
- Even if we had enough CheckUser's, this would be a severe privacy violation absolutely prohibited under the Foundation privacy policy.
The vast majority of vandals and other disruptive users don't need CU involvement to deal with. There's very little to be gained from this.--Jasper Deng (talk) 18:36, 23 November 2024 (UTC)
- It is perhaps an interesting conversation to have but I have to agree that it is unworkable, and directly contrary to foundation-level policy which we cannot make a local exemption to. En.wp, I believe, already has the largest CU team of any WMF project, but we would need hundreds more people on that team to handle something like this. In the last round of appointments, the committee approved exactly one checkuser, and that one was a returning former mamber of the team. And there is the very real risk that if we appointed a whole bunch of new CUs, some of them would abuse the tool. Just Step Sideways from this world ..... today 18:55, 23 November 2024 (UTC)
- And its worth pointing out that the Committee approving too few volunteers for Checkuser (regardless of whether you think they are or aren't) is not a significant part of this issue. There simply are not tens of people who are putting themselves forward for consideration as CUs. Since 2016 54 applications (an average of per year) have been put forward for consideration by Functionaries (the highest was 9, the lowest was 2). Note this is total applications not applicants (more than one person has applied multiple times), and is not limited to candidates who had a realistic chance of being appointed. Thryduulf (talk) 20:40, 23 November 2024 (UTC)
- The dearth of candidates has for sure been an ongoing thing, it's worth reminding admins that they don't have to wait for the committee to call for candidates, you can put your name forward at any time by emailing the committee. Just Step Sideways from this world ..... today 23:48, 24 November 2024 (UTC)
- And its worth pointing out that the Committee approving too few volunteers for Checkuser (regardless of whether you think they are or aren't) is not a significant part of this issue. There simply are not tens of people who are putting themselves forward for consideration as CUs. Since 2016 54 applications (an average of per year) have been put forward for consideration by Functionaries (the highest was 9, the lowest was 2). Note this is total applications not applicants (more than one person has applied multiple times), and is not limited to candidates who had a realistic chance of being appointed. Thryduulf (talk) 20:40, 23 November 2024 (UTC)
- Generally, I tend to get the impression from those who have checkuser rights that CU should be done as a last resort, and other, less invasive methods are preferred, and it would seem that indiscriminate use of it would be a bad idea, so I would have some major misgivings about this proposal. And given the ANI case, the less user information that we retain, the better (which is also probably why temporary accounts are a necessary and prudent idea despite other potential drawbacks). Abzeronow (talk) 03:56, 23 November 2024 (UTC)
- Oppose. A lot has already been written on the unsustainable workload for the CU team this would create and the amount of collateral damage; I'll add in the fact that our most notorious sockmasters in areas like PIA already use highly sophisticated methods to evade CU detection, and based on what I've seen at the relevant SPIs most of the blocks in these cases are made with more weight given to the behaviour, and even then only after lengthy deliberations on the matter. These sort of sockmasters seem to have been in the OP's mind when the request was made, and I do not see automated CU being of any more use than current techniques against such dedicated sockmasters. And, has been mentioned before, most cases of sockpuppetry (such as run-of-the-mill vandals and trolls using throwaway accounts for abuse) don't need CU anyways. JavaHurricane 08:17, 24 November 2024 (UTC)
- These are, unfortunately, fair points about the limits of CU and the many experienced and dedicated ban evading actors in PIA. CU information retention policy is also a complicating factor. Sean.hoyland (talk) 08:28, 24 November 2024 (UTC)
- As I said in my original post, recidivist socks often get better at covering their "tells" each time making behavioural detection increasingly difficult and meaning the entire burden falls on the honest user to convince an Admin to take an SPI case seriously with scarce evidence. After many years I'm tired of defending various pages from sock POV edits and if WMF won't make life easier then increasingly I just won't bother, I'm sure plenty of other users feel the same way. Mztourist (talk) 05:45, 26 November 2024 (UTC)
- These are, unfortunately, fair points about the limits of CU and the many experienced and dedicated ban evading actors in PIA. CU information retention policy is also a complicating factor. Sean.hoyland (talk) 08:28, 24 November 2024 (UTC)
SimilarEditors
The development of mw:Extension:SimilarEditors -- the type of tool that could be used to do what Mztourist suggests -- has been "stalled" since 2023 and downgraded to low-priority in 2024, according to its documentation page and related phab tasks (see e.g. phab:T376548, phab:T304633, phab:T291509). Anybody know why? Levivich (talk) 17:43, 26 November 2024 (UTC)
- Honestly, the main function of that sort of thing seems to be compiling data that is already available on XTools and various editor interaction analyzers, and then presenting it nicely and neatly. I think that such a page could be useful as a sanity check, and it might even be worth having that sort of thing as a standalone toolforge app, but I don't really see why the WMF would make that particular extension a high priority. — Red-tailed hawk (nest) 17:58, 26 November 2024 (UTC)
- Well, it doesn't have to be that particular extension, but it seems to me that the entire "idea" has been stalled, unless they're working on another tool that I'm unaware of (very possible). (Or, it could be because of recent changes in domestic and int'l privacy laws that derailed their previous development advances, or it could be because of advancements in ML elsewhere making in-house development no longer practical.)
As to why the WMF would make this sort of problem a high priority, I'd say because the spread of misinformation on Wikipedia by sockpuppets is a big problem. Even without getting into the use of user metadata, just look at recent SPIs I filed, like Wikipedia:Sockpuppet investigations/Icewhiz/Archive#27 August 2024 and Wikipedia:Sockpuppet investigations/Icewhiz/Archive#09 October 2024. That involved no private data at all, but a computer could have done automatically, in seconds, what took me hours to do manually, and those socks could have been uncovered before they made thousands and thousands of edits spreading misinformation. If the computer looked at private data as well as public data, it would be even more effective (and would save CUs time as well). Seems to me to be a worthy expenditure of 0.5% or 1% of the WMF's annual budget. Levivich (talk) 18:09, 26 November 2024 (UTC)
- Well, it doesn't have to be that particular extension, but it seems to me that the entire "idea" has been stalled, unless they're working on another tool that I'm unaware of (very possible). (Or, it could be because of recent changes in domestic and int'l privacy laws that derailed their previous development advances, or it could be because of advancements in ML elsewhere making in-house development no longer practical.)
- This looks really interesting. I don't really know how extensions are rolled out to individual wikis - can anyone with knowledge about that summarise if having this tool turned on (for check users/relevant admins) for en.wp is feasible? Do we need a RFC, or is this a "maybe wait several years for a phab ticket" situation? BugGhost🦗👻 18:09, 26 November 2024 (UTC)
- I find it amusing that ~4 separate users above are arguing that automatic identification of sockpuppets is impossible, impractical, and the WMF would never do it—and meanwhile, the WMF is already doing it. – Closed Limelike Curves (talk) 19:29, 27 November 2024 (UTC)
- So, discussion is over? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 19:31, 27 November 2024 (UTC)
- I think what's happening is that people are having two simultaneous discussions – automatic identification of sockpuppets is already being done, but what people say "the WMF would never do" is using private data (e.g. IP addresses) to identify them. Which adds another level of (ethical, if not legal) complications compared to what SimilarEditors is doing (only processing data everyone can access, but in an automated way). Chaotic Enby (talk · contribs) 07:59, 28 November 2024 (UTC)
- "automatic identification of sockpuppets is already being done" is probably an overstatement, but I agree that there may be a potential legal and ethical minefield between the Similarusers service that uses public information available to anyone from the databases after redaction of private information (i.e. course-grained sampling of revision timestamps combined with an attempt to quantify page intersection data), and a service that has access to the private information associated with a registered account name. Sean.hoyland (talk) 11:15, 28 November 2024 (UTC)
- The WMF said they're planning on incorporating IP addresses and device info as well! – Closed Limelike Curves (talk) 21:21, 29 November 2024 (UTC)
- Yes, automatic identification of (these) sockpuppets is impossible. There are many reasons for this, but the simplest one is this: These types of tools require hundreds of edits – at minimum – to return any viable data, and the sort of sockmasters who get accounts up to that volume of edits know how to evade detection by tools that analyse public information. The markers would likely indicate people from similar countries – naturally, two Cypriots would be interested in Category:Cyprus and over time similar hour and day overlaps will emerge, but what's to let you know whether these are actual socks when they're evading technical analysis? You're back to square one. There are other tools such as mediawikiwiki:User:Ladsgroup/masz which I consider equally circumstantial; an analysis of myself returns a high likelihood of me being other administrators and arbitrators, while analysing an alleged sock currently at SPI returns the filer as the third most likely sockmaster. This is not commentary on the tools themselves, but rather simply the way things are. DatGuyTalkContribs 17:42, 28 November 2024 (UTC)
- Oh, fun! Too bad it's CU-restricted, I'm quite curious to know what user I'm most stylometrically similar to. -- asilvering (talk) 17:51, 28 November 2024 (UTC)
- That would be LittlePuppers and LEvalyn. DatGuyTalkContribs 03:02, 29 November 2024 (UTC)
- Fascinating! One I've worked with, one I haven't, both AfC reviewers. Not bad. -- asilvering (talk) 06:14, 29 November 2024 (UTC)
- That would be LittlePuppers and LEvalyn. DatGuyTalkContribs 03:02, 29 November 2024 (UTC)
- Idk, the half dozen ARBPIA socks I recently reported at SPI were obvious af to me, as are several others I haven't reported yet. That may be because that particular sockfarm is easy to spot by its POV pushing and a few other habits; though I bet in other topic areas it's the same. WP:ARBECR helps because it forces the socks to make 500 edits minimum before they can start POV pushing, but still we have to let them edit for a while post-XC just to generate enough diffs to support an SPI filing. Software that combines tools like Masz and SimilarEditor, and does other kinds of similar analysis, could significantly reduce the amount of editor time required to identify and report them. Levivich (talk) 18:02, 28 November 2024 (UTC)
- I think it is possible, studies have demonstrated that it is possible, but it is true that having a sufficient number of samples is critical. Samples can be aggregated in some cases. There are several other important factors too. I have tried some techniques, and sometimes they work, or let's say they can sometimes produce results consistent with SPI results, better than random, but with plenty of false positives. It is also true that there are a number of detection countermeasures (that I won't describe) that are already employed by some bad actors that make detection harder. But I think the objective should be modest, to just move a bit in the right direction by detecting more ban evading accounts than are currently detected, or at least to find ways to reduce the size of the search space by providing ban evasion candidates. Taking the human out of the detection loop might take a while. Sean.hoyland (talk) 18:39, 28 November 2024 (UTC)
- If you mean it's never going to be possible to catch some sockpuppets—the best-hidden, cleverest, etc. ones—you're completely correct. But I'm guessing we could cut the amount of time SPI has to spend dramatically with just some basic checks. – Closed Limelike Curves (talk) 02:27, 29 November 2024 (UTC)
- I disagree. Empirically, the vast majority of time spent at SPI is not on finding possible socks, nor is it using the CheckUser tool on them, but rather it's the CU completed cases (of which there are currently 14 and I should probably stop slacking and get onto some) with non-definitive technical results waiting on an administrator to make the final determination on whether they're socks or not. Extension:SimilarUsers would concentrate various information that already exists (EIA, RoySmith's SPI tools) in one place, but I wouldn't say the accessibility of these tools is a cause of SPI backlog. An AI analysis tool to give an accurate magic number for likelihood? I'm anything but a Luddite, but still believe that's wishful thinking. DatGuyTalkContribs 03:02, 29 November 2024 (UTC)
- Something seems better than nothing in this context doesn't it? EIA and the Similarusers service don't provide an estimate of the significance of page intersections. An intersection on a page with few revisions or few unique actors or few pageviews etc. is very different from a page intersection on the Donald Trump page. That kind of information is probably something that could sometimes help, even just to evaluate the importance of intersection evidence presented at SPIs. It seems to me that any kind of assistance could help. And another thing about the number of edits is that too many samples can also present challenges related to noise, with signals getting smeared out, although the type of noise in a user's data can itself be a characteristic signal in some cases it seems. And if there are too few samples, you can generate synthetic samples based on the actual samples and inject them into spaces. Search strategy matters a lot. The space of everyone vs everyone is vast, so good luck finding potential matches in that space without a lot of compute, especially for diffs. But many socks inhabit relatively small subspaces of Wikipedia, at least in the 20%-ish of time (on average in PIA) they edit(war)/POV-push etc. in their topic of interest. So, choosing the candidate search space and search strategy wisely can make the problem much more tractable for a given topic area/subspace. Targeted fishing by picking a potential sock and looking for potential matches (the strategy used by the Similarusers service and CU I guess) is obviously a very different challenge than large-scale industrial fishing for socks in general. Sean.hoyland (talk) 04:08, 29 November 2024 (UTC)
- And to continue the whining about existing tools, EIA and the Similarusers service use a suboptimal strategy in my view. If the objective is page intersection information for a potential sock against a sockmaster, and a ban evasion source has employed n identified actors so far e.g. almost 50 accounts for Icewhiz, the source's revision data should be aggregated for the intersection. This is not difficult to do using the category graph and the logs. Sean.hoyland (talk) 04:25, 29 November 2024 (UTC)
- There is so much more that could be done with the software. EIA gives you page overlaps (and isn't 100% accurate at it), but it doesn't tell you:
- how many times the accounts made the same edits (tag team edit warring)
- how many times they voted in the same formal discussions (RfC, AfD, RM, etc) and whether they voted the same way or different (vote stacking)
- how many times they use the same language and whether they use unique phraseology
- whether they edit at the same times of day
- whether they edit on the same days
- whether account creation dates (or start-of-regular-editing dates) line up with when other socks were blocked
- whether they changed focus after reaching XC and to what extent (useful in any ARBECR area)
- whether they "gamed" or "rushed" to XC (same)
- All of this (and more) would be useful to see in a combined way, like a dashboard. It might make sense to restrict access to such compilations of data to CUs, and the software could also throw in metadata or subscriber info in there, too (or not), and it doesn't have to reduce it all into a single score like ORES, but just having this info compiled in one place would save editors the time of having to compile it manually. If the software auto-swept logs for this info and alerted humans to any "high scores" (however defined, eg "matches across multiple criteria"), it would probably not only reduce editor time but also increase sock discovery. Levivich (talk) 04:53, 29 November 2024 (UTC)
- This is like one of my favorite strategies for meetings. Propose multiple things, many of which are technically challenging, then just walk out of the meeting.
- The 'how many times the accounts made the same edits' is probably do-able because you can connect reverted revisions to the revisions that reverted them using json data in the database populated as part of the tagging system, look at the target state reverted to and whether the revision was an exact revert. ...or maybe not without computing diffs, having just looked at an article with a history of edit warring. Sean.hoyland (talk) 07:43, 29 November 2024 (UTC)
- There is so much more that could be done with the software. EIA gives you page overlaps (and isn't 100% accurate at it), but it doesn't tell you:
- I disagree. Empirically, the vast majority of time spent at SPI is not on finding possible socks, nor is it using the CheckUser tool on them, but rather it's the CU completed cases (of which there are currently 14 and I should probably stop slacking and get onto some) with non-definitive technical results waiting on an administrator to make the final determination on whether they're socks or not. Extension:SimilarUsers would concentrate various information that already exists (EIA, RoySmith's SPI tools) in one place, but I wouldn't say the accessibility of these tools is a cause of SPI backlog. An AI analysis tool to give an accurate magic number for likelihood? I'm anything but a Luddite, but still believe that's wishful thinking. DatGuyTalkContribs 03:02, 29 November 2024 (UTC)
- Oh, fun! Too bad it's CU-restricted, I'm quite curious to know what user I'm most stylometrically similar to. -- asilvering (talk) 17:51, 28 November 2024 (UTC)
Requiring registration for editing
- Note: This section was split off from "CheckUser for all new users" (permalink) and the "parenthetical comment" referred to below is:
(Also, email-required registration and get rid of IP editing.)
—03:49, 26 November 2024 (UTC)
@Levivich, about your parenthetical comment on requiring registration:
Part of the eternally unsolvable problem is that new editors are frankly bad at it. I can give examples from my own editing: Create an article citing a personal blog post as the main source? Check. Merge two articles that were actually different subjects? Been there, done that, got the revert. Misunderstand and mangle wikitext? More times than I can count. And that's after I created my account. Like about half of experienced editors, I edited as an IP first, fixing a typo here or reverting some vandalism there.
But if we don't persist through these early problems, we don't get experienced editors. And if we don't get experienced editors, Wikipedia will die.
Requiring registration ("get rid of IP editing") shrinks the number of people who edit. The Portuguese Wikipedia banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. The number of contributions has dropped, too. They went from 160K to 210K edits per month down to 140K most months.
Some of the experienced editors have said that they like this. No IPs means less impulsive vandalism, and the talk pages are stable if you want to talk to the editor. Fewer newbies means I don't "have to" clean up after so many mistake-makers! Fewer editors, and especially fewer inexperienced editors, is more convenient – in the short term. But I wonder whether they're going to feel the same way a decade from now, when their community keeps shrinking, and they start wondering when they will lose critical mass.
The same thing happens in the real world, by the way. Businesses want to hire someone with experience. They don't want to train the helpless newbie. And then after years of everybody deciding that training entry-level workers is Somebody else's problem, they all look around and say: Where are all the workers that I need? Why didn't someone else train the next generation while I was busy taking the easy path?
In case you're curious, there is a Wikipedia that puts all of the IP and newbie edits under "PC" type restrictions. Nobody can see the edits until they've been approved by an experienced editor. The rate of vandalism visible to ordinary readers is low. Experienced editors love the level of control they have. Have a look at what's happened to the size of their community during the last decade. Is that what you want to see here? If so, we know how to make that happen. The path to that destination even looks broad, easy, and paved with all kinds of good intentions. WhatamIdoing (talk) 04:32, 23 November 2024 (UTC)
- Size isn't everything... what happened to their output--the quality of their encyclopedias--after they made those changes? Levivich (talk) 05:24, 23 November 2024 (UTC)
- Well, I can tell you objectively that the number of edits declined, but "quality" is in the eye of the beholder. I understand that the latter community has the lowest use of inline citations of any mid-size or larger Wikipedia. What's now yesterday's TFA there wouldn't even be rated B-class here due to whole sections not having any ref tags. In terms of citation density, their FA standard is currently where ours was >15 years ago.
- But I think you have missed the point. Even if the quality has gone up according to the measure of your choice, if the number of contributors is steadily trending in the direction of zero, what will the quality be when something close to zero is reached? That community has almost halved in the last decade. How many articles are out of date, or missing, because there simply aren't enough people to write them? A decade from now, with half as many editors again, how much worse will the articles be? We're none of us idiots here. We can see the trend. We know that people die. You have doubtless seen this famous line:
All men are mortal. Socrates is a man. Therefore, Socrates is mortal.
- I say:
All Wikipedia editors are mortal. Dead editors do not maintain or improve Wikipedia articles. Therefore, maintaining and improving Wikipedia requires editors who are not dead.
- – and, memento mori, we are going to die, my friend. I am going to die. If we want Wikipedia to outlive us, we cannot be so shortsighted as to care only about the quality today, and never the quality the day after we die. WhatamIdoing (talk) 06:13, 23 November 2024 (UTC)
- Trends don't last forever. Enwiki's active user count decreased from its peak over a few years, then flattened out for over a decade. The quality increased over that period of time (by any measure). Just because these other projects have shed users doesn't mean they're doomed to have zero users at some point in the future. And I think there's too many variables to know how much any particular change made on a project affects its overall user count, nevermind the quality of its output. Levivich (talk) 06:28, 23 November 2024 (UTC)
- If the graph to the right accurately reflects the age distribution of Wikipedia users, then a large chunk of the user base will die off within the next decade or two. Not to be dramatic, but I agree that requiring registration to edit, which will discourage readers from editing in the first place, will hasten the project's decline.... Some1 (talk) 14:40, 23 November 2024 (UTC)
- 😂 Seriously? What do you suppose that chart looked like 20 years ago, and then what happened? Levivich (talk) 14:45, 23 November 2024 (UTC)
- There are significantly more barriers to entry than there were 20 years ago, and over that time the age profile has increased (quite significantly iirc). Adding more barriers to entry is not the way to solve the issued caused by barriers to entry. Thryduulf (talk) 15:50, 23 November 2024 (UTC)
- "PaperQA2 writes cited, Wikipedia style summaries of scientific topics that are significantly more accurate than existing, human-written Wikipedia articles" - maybe the demographics of the community will change. Sean.hoyland (talk) 16:30, 23 November 2024 (UTC)
- That talks about LLMs usage in artcles, not the users. 2601AC47 (talk|contribs) Isn't a IP anon 16:34, 23 November 2024 (UTC)
- Or you could say it's about a user called PaperQA2 that writes Wikipedia articles significantly more accurate than articles written by other users. Sean.hoyland (talk) 16:55, 23 November 2024 (UTC)
- No, it is very clearly about a language model. As far as I know, PaperQA2, or WikiCrow (the generative model using PaperQA2 for question answering), has not actually been making any edits on Wikipedia itself. Chaotic Enby (talk · contribs) 16:58, 23 November 2024 (UTC)
- That is true. It is not making any edits on Wikipedia itself. There is a barrier. But my point is that in the future that barrier may not be there. There may be users like PaperQA2 writing articles better than other users and the demographics will have changed to include new kinds of users, much younger than us. Sean.hoyland (talk) 17:33, 23 November 2024 (UTC)
- And who will never die off! Levivich (talk) 17:39, 23 November 2024 (UTC)
- But which will not be Wikipedia. WhatamIdoing (talk) 06:03, 24 November 2024 (UTC)
- And who will never die off! Levivich (talk) 17:39, 23 November 2024 (UTC)
- That is true. It is not making any edits on Wikipedia itself. There is a barrier. But my point is that in the future that barrier may not be there. There may be users like PaperQA2 writing articles better than other users and the demographics will have changed to include new kinds of users, much younger than us. Sean.hoyland (talk) 17:33, 23 November 2024 (UTC)
- No, it is very clearly about a language model. As far as I know, PaperQA2, or WikiCrow (the generative model using PaperQA2 for question answering), has not actually been making any edits on Wikipedia itself. Chaotic Enby (talk · contribs) 16:58, 23 November 2024 (UTC)
- Or you could say it's about a user called PaperQA2 that writes Wikipedia articles significantly more accurate than articles written by other users. Sean.hoyland (talk) 16:55, 23 November 2024 (UTC)
- That talks about LLMs usage in artcles, not the users. 2601AC47 (talk|contribs) Isn't a IP anon 16:34, 23 November 2024 (UTC)
- "PaperQA2 writes cited, Wikipedia style summaries of scientific topics that are significantly more accurate than existing, human-written Wikipedia articles" - maybe the demographics of the community will change. Sean.hoyland (talk) 16:30, 23 November 2024 (UTC)
- In re "What do you suppose that chart looked like 20 years ago": I believe that the numbers, very roughly, are that the community has gotten about 10 years older, on average, than it was 20 years ago. That is, we are bringing in some younger people, but not at a rate that would allow us to maintain the original age distribution. (Whether the original age distribution was a good thing is a separate consideration.) WhatamIdoing (talk) 06:06, 24 November 2024 (UTC)
- There are significantly more barriers to entry than there were 20 years ago, and over that time the age profile has increased (quite significantly iirc). Adding more barriers to entry is not the way to solve the issued caused by barriers to entry. Thryduulf (talk) 15:50, 23 November 2024 (UTC)
- I like looking at the en.wikipedia user retention graph hosted on Toolforge (for anyone who might go looking for it later, there's a link to it at Wikipedia:WikiProject Editor Retention § Resources). It shows histograms of how many editors have edited in each month, grouped by all the editors who started editing in the same month. The data is noisy, but it does seem to show an increase in editing tenure since 2020 (when the pursuit of a lot of solo hobbies picked up, of course). Prior to that, there does seem to be a bit of slow growth in tenure length since the lowest point around 2013. isaacl (talk) 17:18, 23 November 2024 (UTC)
- The trend is a bit clearer when looking at the retention graph based on those who made at least 10 edits in a month. (To see the trend when looking at the retention graph based on 100 edits in a month, the default colour range needs to be shifted to accommodate the smaller numbers.) isaacl (talk) 17:25, 23 November 2024 (UTC)
- I'd say that the story there is: Something amazing happened in 2006. Ours (since both of us registered our accounts that year) was the year from which people stuck around. I think that would be just about the time that the wall o' automated rejection really got going. There was some UPE-type commercial pressure, but it didn't feel unmanageable. It looks like an inflection point in retention. WhatamIdoing (talk) 06:12, 24 November 2024 (UTC)
- I don't think something particularly amazing happened in 2006. I think the rapid growth in articles starting in 2004 attracted a large land rush of editors as Wikipedia became established as a top search result. The cohort of editors at that time had the opportunity to cover a lot of topics for the first time on Wikipedia, requiring a lot of co-ordination, which created bonds between editors. As topic coverage grew, there were fewer articles that could be more readily created by generalists, the land rush subsided, and there was less motivation for new editors to persist in editing. Boom-bust cycles are common for a lot of popular things, particularly in tech where newer, shinier things launch all the time. isaacl (talk) 19:07, 24 November 2024 (UTC)
- Ah yes, that glorious time when we gained an article on every Pokemon character and, it seems, every actor who was ever credited in a porn movie. Unfortunately, many of the editors I bonded with then are no longer active. Some are dead, some finished school, some presumably burned out, at least one went into the ministry. Donald Albury 23:49, 26 November 2024 (UTC)
- I don't think something particularly amazing happened in 2006. I think the rapid growth in articles starting in 2004 attracted a large land rush of editors as Wikipedia became established as a top search result. The cohort of editors at that time had the opportunity to cover a lot of topics for the first time on Wikipedia, requiring a lot of co-ordination, which created bonds between editors. As topic coverage grew, there were fewer articles that could be more readily created by generalists, the land rush subsided, and there was less motivation for new editors to persist in editing. Boom-bust cycles are common for a lot of popular things, particularly in tech where newer, shinier things launch all the time. isaacl (talk) 19:07, 24 November 2024 (UTC)
- I'd say that the story there is: Something amazing happened in 2006. Ours (since both of us registered our accounts that year) was the year from which people stuck around. I think that would be just about the time that the wall o' automated rejection really got going. There was some UPE-type commercial pressure, but it didn't feel unmanageable. It looks like an inflection point in retention. WhatamIdoing (talk) 06:12, 24 November 2024 (UTC)
- 😂 Seriously? What do you suppose that chart looked like 20 years ago, and then what happened? Levivich (talk) 14:45, 23 November 2024 (UTC)
Have a look at what happened to the size of their community.
—I'm gonna be honest: eyeballing it, I don't actually see much (if any) difference with enwiki's activity. "Look at this graph" only convinces people when the dataset passes the interocular trauma test (e.g. the hockey stick).- On the other hand, if there's a dataset of "when did $LANGUAGEwiki adopt universal pending changes protections", we could settle this argument once and for all using a real statistical model that can deliver precise effect sizes on activity. Maybe then we can all finally drop the stick. – Closed Limelike Curves (talk) 18:08, 26 November 2024 (UTC)
This particular idea will not pass, but the binary developing in the discussion is depressing. A bargain where we allow IPs to edit (or unregistered users generally when IPs are masked), and therefore will sit on our hands when dealing with abuse and even harassment is a grim one. Any steps taken to curtail the second half of that bargain would make the first half stronger, and I am generally glad to see thoughts about it, even if they end up being impractical. CMD (talk) 02:13, 24 November 2024 (UTC)
- I don't want us to sit on our hands when we see abuse and harassment. I think our toolset is about 20 years out of date, and I believe there are things we could do that will help (e.g., mw:Temporary accounts, cross-wiki checkuser tools for Stewards, detecting and responding to a little bit more information about devices/settings [perhaps, e.g., whether an edit is being made from a private/incognito window]). WhatamIdoing (talk) 06:39, 24 November 2024 (UTC)
- Temporary accounts will help with the casual vandalism, but they’re not going to help with abuse and harassment. If it limits the ability to see ranges, it will make issues slightly worse. CMD (talk) 07:13, 24 November 2024 (UTC)
- I'm not sure what the current story is there, but when I talked to the team last (i.e., in mid-2023), we were talking about the value of a tool that would do range-related work. For various reasons, this would probably be Toolforge instead of MediaWiki, and it would probably be restricted (e.g., to admins, or to a suitable group chosen by each community), but the goal was to make it require less manual work, particularly for cross-wiki abuse, and to be able to aggregate some information without requiring direct disclosure of some PII. WhatamIdoing (talk) 23:56, 25 November 2024 (UTC)
- Temporary accounts will help with the casual vandalism, but they’re not going to help with abuse and harassment. If it limits the ability to see ranges, it will make issues slightly worse. CMD (talk) 07:13, 24 November 2024 (UTC)
Oh look, misleading statistics! "The Portuguese Wikipedia banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. " Of course you have a spike in new registrations soon after you stop allowing IP edits, and you can't sustain that spike. That is not evidence of anything. It would have been more honest and illustrative to show the graph before and after the policy change, not only afterwards, e.g. thus. Oh look, banning IP editing has resulted in on average some 50% more registered editors than before the ban. Number of active editors is up 50% as well[16]. The number of new pages has stayed the same[17]. Number of edits is down, yes, but how much of this is due to less vandalism / vandalism reverts? A lot apparently, as the count of user edits has stayed about the same[18]. Basically, from those statistics, used properly, it is impossible to detect any issues with the Portuguese Wikipedia due to the banning of IP editing. Fram (talk) 08:55, 26 November 2024 (UTC)
- "how much of this is due to less vandalism / vandalism reverts?" That's a good question. Do we have some data on this? Jo-Jo Eumerus (talk) 09:20, 26 November 2024 (UTC)
- @Jo-Jo Eumerus:, the dashboard is here although it looks like they stopped reporting the data in late 2021. If you take "Number of reverts" as a proxy for vandalism, you can see that the block shifted the number of reverts from a higher equilibrium to a lower one, while overall non-reverted edits does not seem to have changed significantly during that period. CMD (talk) 11:44, 28 November 2024 (UTC)
- Upon thinking, it would be useful to know how many good edits are done by IP. Or as is, unreverted edits. Jo-Jo Eumerus (talk) 14:03, 30 November 2024 (UTC)
- @Jo-Jo Eumerus:, the dashboard is here although it looks like they stopped reporting the data in late 2021. If you take "Number of reverts" as a proxy for vandalism, you can see that the block shifted the number of reverts from a higher equilibrium to a lower one, while overall non-reverted edits does not seem to have changed significantly during that period. CMD (talk) 11:44, 28 November 2024 (UTC)
- I agree that one should expect a spike in registration. (In fact, I have suggested a strictly temporary requirement to register – a few hours, even – to push some of our regular IPs into creating accounts.) But once you look past that initial spike, the trend is downward. WhatamIdoing (talk) 05:32, 29 November 2024 (UTC)
But once you look past that initial spike, the trend is downward.
- I still don't see any evidence that this downward trend is unusual. Apparently the WMF did an analysis of ptwiki and didn't find evidence of a drop in activity. Net edits (non-revert edits standing for at least 48 hours) increased by 5.7%, although edits across other wikis increased slightly more. The impression I get is any effects are small either way—the gains from freeing up anti-vandalism resources basically offset the cost of some IP editors not signing up.
- TBH this lines up with what I'd expect. Very few people I talk to cite issues like "creating an account" as a major barrier to editing Wikipedia. The most common barrier I've heard from people who tried editing and gave it up is "Oh, I tried, but then some random admin reverted me, linked me to MOS:OBSCURE BULLSHIT, and told me to go fuck myself but with less expletives." – Closed Limelike Curves (talk) 07:32, 29 November 2024 (UTC)
Not really obvious, and not more or even less so in Portuguese wikipedia [19] than in e.g. Enwiki[20], FRwiki[21], NLwiki[22], ESwiki[23], Svwiki[24]... So, once again, these statistics show no issue at all with disabling IP editing on Portuguese Wikipedia. Fram (talk) 10:38, 29 November 2024 (UTC)But once you look past that initial spike, the trend is downward.
IPs in deletion discussions
The deletion discussion boards (AfD, RfD, etc..) are riddled with socks. You can see in old AfD pages, how many accounts were later banned as socks (strikethroughs). It would be interesting to analyze this data to quantify how bad the sock situation is. IPs are some of the worse abusers. Deletion of content by straight vandalism is hard, but aggressively and maliciously voting delete while using socks? That's kind of fun and "legal" (if you don't get caught). This misbehavior could be better managed with some simple rules. One Example:
- IPs are not "banned", but IPs are limited to a certain number of deletion votes per week. It's good faith self-monitored restriction that can be enforced if needed.
Such a rule would force frequent IPs to either register, which makes sock detection easier; or force them to use dynamic IPs, which is more difficult and costly for them. Legitimate IP editors who frequently vote in deletion discussions need to register or do something else, I don't believe this category of editors will be a large number.
The consensus discussions, particularly deletion, are frequently abused by sock accounts not operating in Good Faith. We can take simple low-friction steps to make things more difficult for them, and easier for us to detect. -- GreenC 16:44, 23 November 2024 (UTC)
- I don't think limiting IPs to a certain number of votes would be helpful. It would restrict participation from legitimate users who might not wish to create an account, while encouraging abusers to use even more socks when voting. Also, many people already have dynamic IPs, which is more often a function of the ISP/network they are using than any costly choice (to take an extreme example, an IPv6 user can have the second half of their address vary between 264 possibilities in their device's assigned /64 range). This would automatically put static IP users and dynamic IP users on unequal grounds, and make it even more enticing to sock/use multiple IPs.It is easy to make proposals raising the bar for prospective editors to participate, in the name of defending the wiki from socks/bad actors/etc., but each step we take in that direction brings us further from our ideal of "the encyclopedia that anyone can edit", and we should be very careful about this. Chaotic Enby (talk · contribs) 16:55, 23 November 2024 (UTC)
- I've been closing a lot of AFDs lately and, while some socks are caught in some discussions, I have not personally seen a serious issue with block-evading IP users. This proposal seems like it is assuming bad faith if IP users wish to particpaite at AFD. Just Step Sideways from this world ..... today 18:58, 23 November 2024 (UTC)
- As IPs may not be a single person over time, a soft participation limit doesn't work. It is at any rate up to closers to evaluate an AfD on its merits, not as a vote count. CMD (talk) 01:51, 24 November 2024 (UTC)
- "It would be interesting to analyze this data to quantify how bad the sock situation is." Then do so, before proposing a policy based on it? Gnomingstuff (talk) 05:43, 24 November 2024 (UTC)
- Without any idea of the statistics, we don't have any way to know if the problem is serious enough to justify restricting anons on this. When gathering data, exclude any CTOPs where anons are already disallowed, as these are more likely to reflect the CTOPs than AFD. Other CTOPs may also suffer from this, so probably list those separately. Animal lover |666| 12:39, 24 November 2024 (UTC)
- I routinely discount low-activity IP's in discussions, on the argument that there is an absence of a basis for determining whether they understand the purpose of the encyclopedia and its policies. BD2412 T 15:08, 24 November 2024 (UTC)
- The problem with that is that it's impossible to tell the difference between a newcomer IP, an anon who edits on a wide range of IP addresses and has perhaps hundreds of edits, and a long-time registered user who got logged out without realizing it and decided after expressing their opinion to let it stand as an anon vote. Animal lover |666| 16:33, 24 November 2024 (UTC)
- @Animal lover 666: I am aware of that, but the problem runs both ways. It is equally impossible to tell if an IP is really another editor already involved in the discussion; or a COI editor, or the like. If an IP makes a persuasive argument backed by evidence, their argument should be able to persuade non-IP participants in the discussion, whose opinions will be weighted more heavily. BD2412 T 17:03, 25 November 2024 (UTC)
- @BD2412, that seems like a reasonable way to handle things with ip's. Huggums537voted! (sign🖋️|📞talk) 07:20, 25 November 2024 (UTC)
- The problem with that is that it's impossible to tell the difference between a newcomer IP, an anon who edits on a wide range of IP addresses and has perhaps hundreds of edits, and a long-time registered user who got logged out without realizing it and decided after expressing their opinion to let it stand as an anon vote. Animal lover |666| 16:33, 24 November 2024 (UTC)
- Disclosure in advance, I do periodically participate in XfDs, though not as often as I should as they can be time-consuming to do right, especially AfD.
- That out of the way. It's not clear to me what this is trying to accomplish or why it matters whether someone is registered or unregistered. If someone is blindly spamming keep or delete across many discussions that is disruptive and the user should be blocked, at least from projectspace, account or no. If they are putting in low-effort JUSTAVOTE type stuff, then the closer should ignore them. If they are putting in high-quality, well-researched, PAG-based rationales that demonstrate careful consideration, then that's a good thing and we should encourage them to participate more because XfDs of all kinds are chronically understaffed, and its a time-consuming and thankless task.
- If a sock is persistently disrupting XfD(s), then report them to AIV or SPI as appropriate depending on the complexity of the case. However, merely being prone more to deletion !votes than keep ones is not in itself a concern; remember delete is by a significant margin the most common AfD result so someone who most frequently !votes for deletion should not automatically be judged thereby a sock, or even a deletionist, but simply normal.
- Sidenote, registration makes socks harder to detect, as the only difference is one less piece of information. Disruption from someone who remains unregistered is almost invariably easier to handle, and I don't think anyone with years of RCP time is going to differ much on that assessment.
- In the larger view, troublesome editors who can employ bureaucratic and social skills waste more of the community's time than vandals. I'm not saying IPs can't become vested, and sometimes we do, after our own fashion, but in practice the people who have caused the most trouble have accounts. 184.152.68.190 (talk) 18:23, 28 November 2024 (UTC)
- I'm not sure IP editors are the biggest problem sock-wise. Usually what I've seen is some account that's built up 100 to maybe just under a thousand edits through some semi-automated (e.g. IA bot) or otherwise very quick edits, sometimes a few months before they start editing again, and then almost exclusively editing AFD pages thereafter. I'm not sure there's much we can do policy-wise or technically, my expectation is that we need to rely on the experience of closers. However, XFDs that do end up with a number of socks picked up after the fact should probably be brought to review. Alpha3031 (t • c) 03:28, 29 November 2024 (UTC)
- If the page is kept, it's probably best just to RENOM and explain that you are ignoring the usual time limits in order to have a discussion without sock disruption. If deleted, then DRV is needed, but I expect a speedy restore and send back to AfD would be uncontroversial.
- I think that usually closers do a good job of giving minimal weight to the low-quality !votes typical of scokmasters, on the other hand sometimes discussions are not only disrupted by multiple sockmasters, but also closed by a sock. 184.152.68.190 (talk) 02:24, 30 November 2024 (UTC)
IP and non EC editors are not permitted to participate in consensus forming discussions if the subject matter is a CT, which are probably(?) the worst affected areas. If my assumption is wrong and the problem is extensive beyond CT, then perhaps consider a similar rule across the board, why not. It is not clear to me how such editors even find these discussions.Selfstudier (talk) 15:22, 24 November 2024 (UTC)
- @Selfstudier, that sounds like a good idea. Huggums537voted! (sign🖋️|📞talk) 07:21, 25 November 2024 (UTC)
- For some context, see this comment by GreenC, where he makes an unprovoked casting of WP:ASPERSIONS with no evidence. Also worth noting is that the actual sock in this case, TeapotsOfDoom, had an account, and wasn't editing unregistered. Also also worth noting, is that yes, while socking is disruptive generally, Teapots's activity at RFD was overall quite productive, bringing a lot of bad redirects to the forum's attention. If he's reading this, I hope he follows the WP:SO approach and is able to return. Also also also worth noting is GreenC's characterization as "malicious", which is completely uncalled for. I would highly urge you to reconsider your words and strike your aspersion at the RFD in question. 35.139.154.158 (talk) 16:11, 24 November 2024 (UTC)
- It was because TeapotsOfDoom had an account that checkuser was able to work. It doesn't work with IPs. That's the point. There is a loophole that gives IPs an easy bypass of checkuser and SPI. They have an advantage over registered accounts, when it comes to socking. -- GreenC 22:55, 25 November 2024 (UTC)
- That's not accurate, the details are at mw:extension:checkuser, but you absolutely can use Special:Investigate or Special:Checkuser on IPs or CIDR ranges, and this is done routinely. It is true that functionaries will not publicly connect accounts to IPs unless the account owner expressly allows this, but that does not prevent them from sockblocking IPs which also happens routinely, or prevent the filing of AIV or SPI reports, simply do not request use of the checkuser tool in those SPIs.
- I don't keep tabs on other IP editors like I used to, even the ones that do RCP, and I'll admit I struggle far more to find scent trails than in past years. But 35.139.154.158 does not have a strong LTA/sock sniff and the insinuation was uncalled for. Good-faith users can disagree whether WP:RFD#D8 or WP:RFD#K3 is more applicable in that discussion without personalizing the dispute. 184.152.68.190 (talk) 18:44, 28 November 2024 (UTC)
- This is also not quite true: we routinely connect IPs with accounts, and IP editors with other IP editors, just not publicly. And on English Wikipedia we are not permitted to check an account just because the owner asks, nor to reveal an account's IP at the owner's request (though it's fairly simple for them to do so themselves). Ivanvector (Talk/Edits) 18:48, 28 November 2024 (UTC)
- I wasn't referring to that but to the somewhat unusual case where an account has already been privately connected to IPs by a functionary, and the owner agrees to discuss them as part of a public appeal. 184.152.68.190 (talk) 18:56, 28 November 2024 (UTC)
- This is also not quite true: we routinely connect IPs with accounts, and IP editors with other IP editors, just not publicly. And on English Wikipedia we are not permitted to check an account just because the owner asks, nor to reveal an account's IP at the owner's request (though it's fairly simple for them to do so themselves). Ivanvector (Talk/Edits) 18:48, 28 November 2024 (UTC)
- It was because TeapotsOfDoom had an account that checkuser was able to work. It doesn't work with IPs. That's the point. There is a loophole that gives IPs an easy bypass of checkuser and SPI. They have an advantage over registered accounts, when it comes to socking. -- GreenC 22:55, 25 November 2024 (UTC)
- Oppose per Chaotic Enby, this would also cause problems because many IPs would not know this rule. Crouch, Swale (talk) 20:08, 25 November 2024 (UTC)
- Reply - It's like 3RR or anything else, you have the option to warn them, it's all voluntary there is no hard rule that stops them from editing. If nobody sees their editing as a problem then it won't be a problem. The issues are that it can be very hard to prove at SPI because IPs have natural immunity from checkuser. IPs are often used in deletion discussions for that reason. -- GreenC 23:06, 25 November 2024 (UTC)
- The checkuser extension works just fine on IPs/ranges; see my above comment. 184.152.68.190 (talk) 18:46, 28 November 2024 (UTC)
- Reply - It's like 3RR or anything else, you have the option to warn them, it's all voluntary there is no hard rule that stops them from editing. If nobody sees their editing as a problem then it won't be a problem. The issues are that it can be very hard to prove at SPI because IPs have natural immunity from checkuser. IPs are often used in deletion discussions for that reason. -- GreenC 23:06, 25 November 2024 (UTC)
Discussion at Wikipedia talk:Criteria for speedy deletion § RfC: Enacting T5 (unused template subpages)
You are invited to join the discussion at Wikipedia talk:Criteria for speedy deletion § RfC: Enacting T5 (unused template subpages). HouseBlaster (talk • he/they) 03:02, 25 November 2024 (UTC)
End dates in office, for presidents & vice presidents of Brazil
Which dates do we use for when a president or vice president of Brazil's term ends. As I understand it, their term of office (barring a military coup) ended at midnight. GoodDay (talk) 14:22, 25 November 2024 (UTC)
I believe it's time we settle this matter, on which dates to use. @Torimem, Coltsfan, and Luke Elaine Burke: & others. I didn't know where else to have this discussion, so I've brought to the Village Pump. GoodDay (talk) 14:25, 25 November 2024 (UTC)
Using Jair Bolsonaro as an example: For the end of his term as president of Brazil. Do we use 31 December 2022 or 1 January 2023. GoodDay (talk) 14:34, 25 November 2024 (UTC)
- I'm brazilian, so I think can answer this for y'all. The term ends the day the next president/governor is inaugurated. So for example, Jair Bolsonaro's term ended 1 January 2023, and Lula started 1 January 2023 (same day).
- The new term starts at the time the inauguration takes place. So as an example, if the inauguration takes place at 1400, Bolsonaro was president until 1400, when Lula became the president.
- Sorry if my English isn't quite accurate. Eduardo Gottert (talk) 01:32, 26 November 2024 (UTC)
- The fact is we will never have an answer because the Constitution is ambiguous. It states the date when the term begins, but also states that the president must take the oath of office.
- As this has never been brought before the Supreme Court to rule upon because there have never been any issues with deciding who the president is between midnight and 10 a.m. of January 1, the ambiguity will likely remain unresolved.
- That said, the public perception is that the incoming president becomes president on the morning of the 1st, when they receive the sash from the outgoing president (when the outgoing president is gracious enough to take part in the ceremony). For that alone I would suggest that the term be said to end on January 1. Zelani (talk) 02:27, 26 November 2024 (UTC)
- This covers all the presidents & vice presidents of Brazil. So if we go with January 1? We'll have to also go with November 15 & March 15 for the earlier presidents & vice presidents. GoodDay (talk) 02:42, 26 November 2024 (UTC)
- @GoodDay The fact is that "terms end at midnight" just isn't a thing. Nobody's looking at their watches saying, "Ten seconds until Jurandir becomes mayor!" Jurandir's team isn't waiting at the door of Paçoquinha do Norte City Hall just waiting to barge in at midnight to take the reins to municipal administration.
- Transfer of power is (ideally) a smooth handover of power.
- If the Constituent Assembly had intended for there to be an exact time, they would have written it into the document.
- I honestly think it makes a lot more sense for one term to end on the same day the next term begins. Zelani (talk) 09:27, 26 November 2024 (UTC)
- That argument wouldn't go far, concerning Mexico presidents or New York governors & lieutenant governors. Terms in some places, do end at midnight. GoodDay (talk) 11:59, 26 November 2024 (UTC)
- My point is, you're splitting hairs over an issue that is irrelevant outside of Wikipedia. It has no bearing in the real world.
- Anyway, the Constitution is clear in one respect:
- "Art. 78. O Presidente e o Vice-Presidente da República tomarão posse em sessão do Congresso Nacional, prestando o compromisso de manter, defender e cumprir a Constituição, observar as leis, promover o bem geral do povo brasileiro, sustentar a união, a integridade e a independência do Brasil."
- This, to me, leaves no margin for doubt. The President's term begins when they take the oath of office in the session in Congress.
- I retract my previous comment that the Constitution is ambiguous. Zelani (talk) 14:53, 26 November 2024 (UTC)
- That argument wouldn't go far, concerning Mexico presidents or New York governors & lieutenant governors. Terms in some places, do end at midnight. GoodDay (talk) 11:59, 26 November 2024 (UTC)
- Yeah, I forgot to mention the ambiguity in the constitution. But for most matters, January 1st is the day.
- If there happens to be something that the supreme court might intervene, that'd be settled, but for now I think we should just take the most used answer. Eduardo G.msg-contrib 02:47, 26 November 2024 (UTC)
- This covers all the presidents & vice presidents of Brazil. So if we go with January 1? We'll have to also go with November 15 & March 15 for the earlier presidents & vice presidents. GoodDay (talk) 02:42, 26 November 2024 (UTC)
I'll revert to the non-midnight style, for these bios. GoodDay (talk) 15:33, 26 November 2024 (UTC)
- Thanks for taking our feedback into account. Zelani (talk) 15:53, 26 November 2024 (UTC)
Redlinks on dab pages
I often remove redlinks from dab pages per WP:DDD. I recently did this on the Sylvester page and was pleased to see at the top of the editing page Attention editors! No red links. Every entry in this list must have an article written in the English Wikipedia ... else it will be removed without warning.
I assumed this must be a new feature for dab pages, but I haven't been able to find it anywhere else so far. Some dab pages do have a notice at the top of the editing page explaining their purpose, but with no mention of redlinks, and many dab pages have nothing like this at all. Can/should they all be flagged with an appropriate notice about redlinks? Or at least all flagged with an explanation of dab pages? Shantavira|feed me 10:00, 26 November 2024 (UTC)
- Name articles are not dabs per MOS:DABNAME but that does not nullify your point here. 115.188.72.131 (talk) 10:27, 26 November 2024 (UTC)
- That editnotice was specifically created for the page Sylvester by Alexf. – Joe (talk) 10:33, 26 November 2024 (UTC)
- Having an editnotice for name articles as @Shantavira suggests seems like a good idea. It should definitely be centralized and automatically added, so that we can ensure it represents best practices/consensuses and reduces the workload.
- (Also, the fact it wasn't clear this was an editnotice goes to CapnZapp's stalled suggestion that we add backlinks.) Sdkb talk 14:14, 26 November 2024 (UTC)
- We already have Template:Disambig editnotice applied automatically. That page doesn't get it because it's technically a SIA not a DAB. * Pppery * it has begun... 04:43, 29 November 2024 (UTC)
- This shows that it would be technically possible to have a similar editnotice for name articles. Chaotic Enby (talk · contribs) 13:43, 29 November 2024 (UTC)
- We already have Template:Disambig editnotice applied automatically. That page doesn't get it because it's technically a SIA not a DAB. * Pppery * it has begun... 04:43, 29 November 2024 (UTC)
Wikipedia donation ads
in the school I go to, they have chromebooks for Wikipedia but they are reset every time you log on so every time i go to wikipidia I always get the annoying Wikipidia donation adds, and even though I press x they come back the next time I log on, which can be many times in one day.
I am proposing that the poppup system should ask for donations bassed off of the IP adress and not bassed of of cookies. Instead of adds automaticaly popping up when wikipidia is oppened for the first time on the browser, make them poppup when its oppened for the first time on the IP adress or user. — Preceding unsigned comment added by YisroelB501 (talk • contribs) 09:59, 29 November 2024 (UTC)
- I have experienced similar issues when I've not been logged in, and they've definitely been getting more aggressive as of late. IP-based messages would be sensible, in my view. JayCubby 21:50, 29 November 2024 (UTC)
- According to the Wikimedia Foundation, their banner fundraising campaign only runs once a year and doesn’t start until December 2nd, so it’s unclear where any ads you or I have seen before that date come from. Perhaps there’s some sort of security issue. 216.147.127.204 (talk) 21:56, 29 November 2024 (UTC)
- Every country has a different schedule. Also, they test the system beforehand.
- @YisroelB501, I agree that it sounds annoying, but unfortunately, I think fixing it would take more than a few weeks, and the main fundraising campaign only lasts until the first few days of January. So I think you'll keep seeing this problem for a while yet. @JBrungs (WMF) can inquire with the fundraising team about whether this would be feasible. WhatamIdoing (talk) 19:54, 30 November 2024 (UTC)
- I’m in the United States, which is one of the countries where the Wikimedia Foundation says its fundraiser hasn’t started yet. The messages I saw looked just like a legitimate fundraiser, not test messages, and I didn’t sign up for any testing. I don’t know who is putting these messages up on Wikipedia or where the money is going. 216.147.127.204 (talk) 21:00, 30 November 2024 (UTC)
- These are legitimate fundraising requests. They periodically run tests of the real thing (e.g., to see if they get complaints about the wording being confusing, to make sure that the credit card processing system works, etc.). If they had to change anything recently, they'll definitely be running tests right now, because they want everything to work on "Giving Tuesday". "Giving Tuesday" is the response from the non-profit world to Black Friday, Small Business Saturday, and Cyber Monday.
- The money goes to the Wikimedia Foundation, a 501(c)(3) non-profit organization that supports Wikipedia and other projects like Wiktionary and Wikimedia Commons (where almost all of our photos are stored and organized).
- If you want to donate, you should go to https://donate.wikimedia.org and do so. And if you don't, you should click the little button to make the banner go away for a week (or until you clear the cookies in your web browser). If you really want to make it go away, then go to Special:CreateAccount and create a free account (pick a username/password; no e-mail address or anything else required). After you're logged in, go to Special:Preferences#mw-prefsection-centralnotice-banners and turn off all fundraising banners. That will suppress all fundraising banners until you get logged out. (And if you do get logged out, just log back in again, and your prefs settings will take over again.) You can use the same account on all your devices, as long as you can remember the username and password. WhatamIdoing (talk) 22:24, 30 November 2024 (UTC)
- The wording certainly was confusing, because I didn’t even know that these were tests! I had assumed that the Wikimedia Foundation was running its annual banner fundraising campaign until I saw a statement by a WMF employee that the WMF was not doing that. I couldn’t have complained about the wording’s being confusing because I wasn’t told that there was a test going on or where to make any reports about it.
- Looking more closely at the “community collaboration page” and its mentions of testing, I gather that these are psychological tests seeking to determine which banners induce the most donations. Conducting such experimentation on human subjects without obtaining their informed consent is a serious breach of ethical standards. (Obviously there was no informed consent, because I wasn’t even informed!) Even the WMF’s own Code of Conduct calls such “psychological manipulation” an “unacceptable behaviour”.
- I’d like to formally report this violation of the Code of Conduct, but I can’t find a way to do that. I see that the Code of Conduct has enforcement guidelines, but they contain vague language like “Reporting of UCoC violations should be possible by the target of the violation”…so, um, is reporting of UCoC violations possible, and if so, how? 216.147.127.204 (talk) 00:37, 1 December 2024 (UTC)
- The UCoC says it is an abuse of power to engage in:
- Psychological manipulation: Maliciously causing someone to doubt their own perceptions, senses, or understanding with the objective to win an argument or force someone to behave the way you want.
- Did you actually doubt your own perceptions, senses, or understanding? Was producing those doubts (if, indeed, they were produced) in aid of someone winning an argument against you or forcing you to behave the way the other person wanted?
- If you can't answer yes to both of those questions, then you've got no complaint to make under the UCoC.
- I suggest reading up about the words you're using, like Informed consent, and maybe the difference between Psychological testing of a person and A/B testing an advertisement. WhatamIdoing (talk) 00:00, 3 December 2024 (UTC)
- The UCoC says it is an abuse of power to engage in:
- I’m in the United States, which is one of the countries where the Wikimedia Foundation says its fundraiser hasn’t started yet. The messages I saw looked just like a legitimate fundraiser, not test messages, and I didn’t sign up for any testing. I don’t know who is putting these messages up on Wikipedia or where the money is going. 216.147.127.204 (talk) 21:00, 30 November 2024 (UTC)
- Tracking page customization information by IP address would require storing that information, and would slow down serving pages to non-logged in users, as they can't just be served a pre-composed page right from the cache servers. The only cache-friendly approach is for the client to hide the messages, which means using cookies. Plus, some network configurations have IP addresses shared between users that need to be supported. isaacl (talk) 22:49, 30 November 2024 (UTC)
- Perhaps simply waiting a bit to show donation prompts at all would solve the issue (and prevent it from annoying people who have their cookies cleared all the time). JayCubby 03:01, 1 December 2024 (UTC)
- If the delay is long enough that people won't see the donation banner, then the purpose of the banner is defeated. A slight pause will either leave a blank space for a period of time, or shift the page layout after the pause. Both of these are arguably more annoying than displaying the banner without a pause. isaacl (talk) 04:09, 2 December 2024 (UTC)
- What I mean is a delay of days before the banner is shown to users, rather than bugging them on the first time a user goes to Wikipedia. JayCubby 17:19, 2 December 2024 (UTC)
- The problem is that if IP addresses are tracked, then that information on how recently and how often an IP address has been used to access WP will have to be stored somewhere and retrieved every time that IP is used to access WP. There is also the point that it may not be the same IP being used the next time WP is accessed from that device. And if cookies are used to track the device, some devices are in schools or libraries, and not only is there no guarantee that the same person will be accessing WP two times in a row on the same device, it is very likely it will not be the same person, while other users may use more than one device to access WP. All of that will give inconsistent results on when a user see an add. Donald Albury 17:55, 2 December 2024 (UTC)
- When is the start of this delay determined? The shared IP addresses in question from the original post aren't never-been-used-before IP addresses. I think for most readers this would just amount to shifting the start date of the campaign. Also note this won't solve either the caching problem or the problem of storing info for every IP address. isaacl (talk) 18:27, 2 December 2024 (UTC)
- I have little technical expertise, but my thoughts are as follows:
- User visits wp, a cookie is set.
- Period of time, let's say a day or two elapses, and next time user visits wp, banner is displayed. No IPs needed. JayCubby 02:03, 3 December 2024 (UTC)
- That defeats the purpose of the banner (which I appreciate suits those who don't want to see it, but doesn't help the campaign). isaacl (talk) 05:33, 3 December 2024 (UTC)
- I don't see much value in displaying the banner on the first time, I myself wouldn't appreciate being begged for donations the first time I visited a webpage (or cleared my cookies). I don't know who is likely to donate, maybe it's effective to ask the first time a reader visits. JayCubby 16:09, 3 December 2024 (UTC)
- I imagine the vast majority of readers is repeat traffic, in any case. isaacl (talk) 17:40, 3 December 2024 (UTC)
- I have to wonder what the point of showing the banner to (likely) new visitors is. Maybe someone at the Foundation can chine in on their strategy. JayCubby 18:49, 3 December 2024 (UTC)
- I think Wikipedia has far more repeat visitors than first-time visitors. These days, the only criterion I can think of to try to identify a group of likely first-time visitors is by age, and there isn't a good way to filter for that. isaacl (talk) 18:11, 4 December 2024 (UTC)
- It's likely that there are some, but relatively few, first-time visitors. https://stats.wikimedia.org/ says the English Wikipedia sees about a billion unique devices each month, and there are only 1.5 billion English speakers in the world.
- There will always be some first-time visitors. If we assume, to a first approximation, that everyone in the US will eventually visit the English Wikipedia, then purely due to about 10,000 babies being born each day, we'll (when they've gotten a little older) see about 10,000 first-time users each day. We get about 100,000,000 page views a day from the US, so 10,000 of those will be the first visit to the site.
- That's roughly a one-in-10,000 risk that the person seeing the banner today is at the site for the first time. The other 9,999 times, it's at least the person's second page on the site. Since banners aren't run all the time, then it's only about 10% of each year's true first-timers who see any fundraising banners.
- In other works, >99.9% of the time, this isn't something we should be worrying about. WhatamIdoing (talk) 00:20, 5 December 2024 (UTC)
- I think Wikipedia has far more repeat visitors than first-time visitors. These days, the only criterion I can think of to try to identify a group of likely first-time visitors is by age, and there isn't a good way to filter for that. isaacl (talk) 18:11, 4 December 2024 (UTC)
- I have to wonder what the point of showing the banner to (likely) new visitors is. Maybe someone at the Foundation can chine in on their strategy. JayCubby 18:49, 3 December 2024 (UTC)
- I imagine the vast majority of readers is repeat traffic, in any case. isaacl (talk) 17:40, 3 December 2024 (UTC)
- I don't see much value in displaying the banner on the first time, I myself wouldn't appreciate being begged for donations the first time I visited a webpage (or cleared my cookies). I don't know who is likely to donate, maybe it's effective to ask the first time a reader visits. JayCubby 16:09, 3 December 2024 (UTC)
- That defeats the purpose of the banner (which I appreciate suits those who don't want to see it, but doesn't help the campaign). isaacl (talk) 05:33, 3 December 2024 (UTC)
- What I mean is a delay of days before the banner is shown to users, rather than bugging them on the first time a user goes to Wikipedia. JayCubby 17:19, 2 December 2024 (UTC)
- If the delay is long enough that people won't see the donation banner, then the purpose of the banner is defeated. A slight pause will either leave a blank space for a period of time, or shift the page layout after the pause. Both of these are arguably more annoying than displaying the banner without a pause. isaacl (talk) 04:09, 2 December 2024 (UTC)
- Are cookies not now being created with the partial rollout of masked temporary accounts? CMD (talk) 04:31, 2 December 2024 (UTC)
- Cookies are currently used, regardless of the IP masking initiative. The original post proposed hiding the donation banner based on IP address, instead of using client cookies. isaacl (talk) 04:44, 2 December 2024 (UTC)
- Perhaps simply waiting a bit to show donation prompts at all would solve the issue (and prevent it from annoying people who have their cookies cleared all the time). JayCubby 03:01, 1 December 2024 (UTC)
Hi everyone,
Thank you very much for engaging with the fundraiser and I wanted to briefly take the opportunity to reply to you here.
I will take the IP address idea to the fundraising team to think about for future fundraisers, though I am not sure this is possible.
A note on our testing. From July to November, we test different versions of banners to small numbers of readers on English Wikipedia before the primary campaign begins, which this year runs from Dec 2nd. We need to test our technical infrastructure, trial new payment methods, and new features (such as annual recurring). We also conduct a/b testing on the content in order to determine on aggregate what readers are responsive to. This allows us to run overall less fundraising messages on the site while ensuring that we raise the money needed to support the movement.
Ethical considerations around A/B testing are valid and actively discussed across industries. At the Foundation, we approach testing with care. While we analyze donation rates to understand effectiveness, we also rely on ethical guardrails, informed by reader research and discussions with volunteers about the content, for example on our community collaboration page. The banners are displayed publicly without collecting personal data or requiring user participation, and no identifying information is gathered. Additionally, our privacy policy states that some browser information is collected automatically to improve the experience of the website.
Testing in fundraising and marketing is a standard practice but we agree it must be conducted thoughtfully to avoid harm. We appreciate your feedback, as it helps us continue to refine our approach.
I hope this addresses your concerns. Sheetal Puri (WMF) (talk) 21:38, 2 December 2024 (UTC)
Revise Wikipedia:INACTIVITY
Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. Mztourist (talk) 07:47, 4 December 2024 (UTC)
Endorsement/Opposition
- Support as proposer. Mztourist (talk) 07:47, 4 December 2024 (UTC)
- Oppose - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? —Femke 🐦 (talk) 19:17, 4 December 2024 (UTC)
- Oppose. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Wikipedia from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? Seraphimblade Talk to me 21:21, 4 December 2024 (UTC)
- Oppose There's no indication that this is a problem needs fixing. ⇒SWATJester Shoot Blues, Tell VileRat! 00:55, 5 December 2024 (UTC)
- Support Admins who don't use the tools should not have the tools. * Pppery * it has begun... 03:55, 5 December 2024 (UTC)
Discussion
- Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. Chaotic Enby (talk · contribs) 08:13, 4 December 2024 (UTC)
- Looking back at previous RFCs, in 2011 the reasoning was to reduce the attack surface for inactive account takeover, and in 2022 it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. Anomie⚔ 12:44, 4 December 2024 (UTC)
- I also note that not all admin actions are logged. Logging editing through full protection requires abusing the Edit Filter extension. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really WP:NACs or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. Anomie⚔ 12:44, 4 December 2024 (UTC)
- I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. Chaotic Enby (talk · contribs) 15:59, 4 December 2024 (UTC)
- To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. DonIago (talk) 15:14, 4 December 2024 (UTC)
- As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - Donald Albury 22:26, 4 December 2024 (UTC)
- And also, if the account of an active admin was hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. Thryduulf (talk) 00:42, 5 December 2024 (UTC)
- I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back should be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The 2022 change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. Mztourist (talk) 03:23, 5 December 2024 (UTC)
obviously they should all be correctly logged as admin actions
- how would you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel criterion 2 could be significantly stricter, fwiw) AddWittyNameHere 05:30, 5 December 2024 (UTC)
Idea lab
Toward helping readers understand what Wiki is/isn’t
I’ve often noticed confusion on the part of both general readers and editors about what Wikipedia articles are AND aren’t. Truth be told, I suspect all of us editors probably had it not only before becoming editors but also well into our Wiki work.
So I got thinking that perhaps a cute (but not overly so!) little information box that would fly in or otherwise attract attention upon accessing a new article could help halt some common misunderstandings or lack of awareness of general readers. Because I think most editors here at the Pump would be aware of many such examples, I hope you’ll forgive my not providing e.g.’s.
(Of course if such an info box were put in place, there’d also need to be a way for readers not to see it again if they so wish.)
I started to check elsewhere at the Pump to see if a similar idea had ever been submitted before, but I couldn’t figure out a relevant search term. And I didn’t want to suggest an outright proposal if anything similar had in fact ever been proposed. So IDEA LAB just seemed a good place to start the ball rolling. Looking forward to seeing where it leads. Augnablik (talk) 10:58, 17 November 2024 (UTC)
- I'm a strong supporter of providing more information about how Wikipedia works for readers, especially if it helps them get more comfortable with the idea of editing. Readers are editors and editors are readers—this line should be intentionally blurred. I don't know if a pop up or anything similar to that is the right way to go, but I do think there's something worth considering here. One thing I've floated before was an information panel featured prominently on the main page that briefly explains how every reader is an editor and gives some basic resources. Thebiguglyalien (talk) 17:49, 17 November 2024 (UTC)
- The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)
- Another issue is a large number of these users tend to be on mobile devices, which have known bugs with regards to things like this. —Jéské Couriano v^_^v threads critiques 20:45, 17 November 2024 (UTC)
- The main page gets 4 to 5 million page views each day. And even so, I would guess that people who go out of their way to read the main page are better candidates to become frequent editors than people who treat Wikipedia like it's part of Google. Thebiguglyalien (talk) 15:12, 18 November 2024 (UTC)
- I wasn't thinking of the main page. What I had in mind was that whenever someone requests to go to an article — irrespective of how he or she entered Wikipedia — the information box would fly in or otherwise appear. Augnablik (talk) 17:30, 18 November 2024 (UTC)
- I know you weren't thinking of the main page. My reply was to Thebiguglyalien. Phil Bridger (talk) 20:23, 18 November 2024 (UTC)
- So I see now. Sorry. Augnablik (talk) 09:44, 20 November 2024 (UTC)
- I know you weren't thinking of the main page. My reply was to Thebiguglyalien. Phil Bridger (talk) 20:23, 18 November 2024 (UTC)
- The problem with putting stuff on the main page is that many (probably most) readers get to Wikipedia articles from a search engine, rather than via the main page. Phil Bridger (talk) 17:57, 17 November 2024 (UTC)
- What sort of confusion are you seeking to dispel? Looking over WP:NOT, basically everything on there strikes me as "well, DUH!". I honestly can't understand why most of it has had to be spelled out. --User:Khajidha (talk) (contributions) 13:04, 18 November 2024 (UTC)
- @Khajidha, i don't see the box as ONLY to dispel confusion but ALSO to point out some strengths of Wikipedia that probably readers wouldn't have been aware of.
- A few things that came to my mind: although Wikipedia is now one of the world's most consulted information sources, articles should be considered works in progress because ... however, there are stringent requirements for articles to be published, including the use of strong sources to back up information and seasoned editors to eagle-eye them; writing that is objective and transparent about any connection between writers and subjects of articles ... and (this last could be controversial but I think it would be helpful for readers in academia) although not all universities and academic circles accept Wiki articles as references, they can serve as excellent pointers toward other sources.
- if the idea of presenting an information box including the above (and more) is adopted, a project team could work on exactly what it would say and look like. Augnablik (talk) 18:58, 18 November 2024 (UTC)
- I think that considerably overstates reality (the requirements are not stringent, sources do not have to be strong, many things are not checked by anyone, much less by seasoned editors, hiding COIs is moderately common...).
- BTW, there has been some professional research on helping people understand Wikipedia in the past, and the net result is that when people understand Wikipedia's process, they trust it less. This might be a case of Careful What You Wish For. WhatamIdoing (talk) 19:20, 18 November 2024 (UTC)
- Ooops. Well, if stringent requirements, etc., overstate reality, then official Wiki guidance and many Teahouse discussions are needlessly scaring many a fledgling editor! 😱 Augnablik (talk) 19:40, 18 November 2024 (UTC)
- All of these points also fall into the "well, DUH!" category. I did, however, want to respond to your statement that "not all universities and academic circles accept Wiki articles as references". I would be very surprised if any university or serious academic project would accept Wikipedia as a reference. Tertiary sources like encyclopedias have always been considered inappropriate at that level, as far as I know. --User:Khajidha (talk) (contributions) 19:38, 18 November 2024 (UTC)
- Point taken about encyclopedias being generally unacceptable in academic writing.
- But as we’re having this discussion in an idea lab, this is the perfect place to toss the ball back to you, Khajidha, and ask how you would describe Wikipedia for new readers so they know how it can be advantageous and how it can’t?
- As I see it, that sort of information is a real need for those who consult Wikipedia — just as customers appreciate quick summaries or reviews of products they’re considering purchasing — to get a better handle on “what’s in it for me.” Augnablik (talk) 20:05, 18 November 2024 (UTC)
- I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)
- @Khajidha, a mere tag saying "The Free Encyclopedia" seems to me just a start in the right direction. The addition of "that anyone can edit" adds a little more specificity, although you didn't mention anything about writing as well as editing. Still, I think these tags are too vague as far as what readers need more insight about.
- I'm working on a list of things I'd like to bring to readers' attention, but I'd like to put it away tonight and finish tomorrow. At that point, I'll humbly request you to "de-DUH" your evaluation of my idea. Augnablik (talk) 17:01, 20 November 2024 (UTC)
- Seems to me the problem is that people don't understand what an encyclopedia is. That's a "them" problem, not an "us" problem. And what exactly do these readers think editing the encyclopedia would be that doesn't incude writing it? User:Khajidha (talk) (contributions) 17:45, 20 November 2024 (UTC)
- Wikipedia is very different from the historical concept of encyclopedia. The open editing expands the pool of editors, at the expense of accuracy. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)
- Wikipedia may have put traditional general encyclopedias out of business, or at least made them change their business model drastically, but it does not define what an encyclopedia is. One example is that Wikipedia relies largely on secondary sources, but traditional encyclopedias, at least for the most important articles, employed subject matter experts who wrote largely on the basis of primary sources. It is our job to explain the difference. Phil Bridger (talk) 20:03, 20 November 2024 (UTC)
- After a little longer gap between than what I thought it would take to create a list of things I believe all readers need to be aware of from the git-go about what Wikipedia is and isn't, due to some challenges in other departments of life, here's what I came up with. It would be in sections, similar to what you see below, each surrounded by a clip art loop, perhaps golden brown, and perhaps a few other pieces of clip art to set it off visually.I wish I knew how to separate paragraphs with line spacing ... I know this looks a little squished.
- Seems to me the problem is that people don't understand what an encyclopedia is. That's a "them" problem, not an "us" problem. And what exactly do these readers think editing the encyclopedia would be that doesn't incude writing it? User:Khajidha (talk) (contributions) 17:45, 20 November 2024 (UTC)
- I think the logo at the top left already does a pretty good job: "Wikipedia: The Free Encyclopedia". Especially if you look at the expanded form we use elsewhere: "Welcome to Wikipedia, the free encyclopedia that anyone can edit."--User:Khajidha (talk) (contributions) 12:39, 19 November 2024 (UTC)
- _____________________________________
- New to reading Wikipedia articles? Here are some helpful things for you to be aware of about Wikipedia. They'll help you get more clearer ideas of how you can use the articles to best advantage.
- If you'd like to go into more depth about all this, and more, just go to the article in Wikipedia about itself by typing WIKIPEDIA in the Wikipedia search field.
- Wikipedia is a different kind of encyclopedia.
- — Its articles can be written and edited by anyone.
- — They’re supposed to be based completely on reliable outside sources.
- — They can be updated at any time, thus allowing for quick corrections or additions if needed.
- — Wikipedia is free.
- That’s the main difference between Wikipedia and traditional encyclopedias.
- BUT:
- All encyclopedias serve as starting points where readers can find out about information — especially the main thinking about particular subjects — then follow up as they wish.
- Students and researchers: keep in mind that schools and professional research journals don’t accept encyclopedias as references for written papers, but do encourage using them to get some ideas with which to go forward.
- Wikipedia has become popular for good reason.
- — Wikipedia is the world’s largest-ever encyclopedia.
- — It’s consistently ranked among the ten websites people visit most.
- — Because it’s all online, it’s easy to access.
- — Because it’s highly interactive, it’s easy to move around from topic to topic.
- Quality standards for writing articles are in place and in action behind the scenes.
- — Wikipedia has high standards for choosing the subjects of articles.
- — Wikipedia also has high standards for writing articles, especially freedom from bias.
- — Certain editors are assigned to ensure that articles follow Wikipedia standards.
- — Although differences of opinions naturally arise about whether a particular article does so, there are sets of procedures to work them out and arbiters to step in as needed. Augnablik (talk) 10:18, 25 November 2024 (UTC)
- The
<br />
tag should take care of line spacing. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:49, 25 November 2024 (UTC)- Is this possible to do in Visual Editor instead (I hope)? Augnablik (talk) 13:52, 25 November 2024 (UTC)
- Why would you put information about "reading Wikipedia articles" in an editing environment?
- Also, several things you've written are just wrong. Wikipedia is not considered a "highly interactive" website. "Certain editors" are not "assigned to ensure" anything. Wikipedia does not have "high standards for writing articles", and quite a lot of readers and editors think we're seriously failing in the "freedom from bias" problem. We might do okay-ish on some subjects (e.g., US political elections) but we do fairly poorly on other subjects (e.g., acknowledging the existence of any POV that isn't widely discussed in English-language sources). WhatamIdoing (talk) 20:14, 28 November 2024 (UTC)
- Is this possible to do in Visual Editor instead (I hope)? Augnablik (talk) 13:52, 25 November 2024 (UTC)
- Actually, I think a more magnetic format for this tool I'm hoping can one day be used on Wikipedia would be a short series of animated "fly-ins" rather than a static series of points with a loop around each set thereof. Augnablik (talk) 13:51, 25 November 2024 (UTC)
- @Augnablik, personally, I think your idea would be great and would help bring new editors to the project, especially with these messages, which seem more focused on article maintenance (more important nowadays imo) than article creation.
- JuxtaposedJacob (talk) | :) | he/him | 02:32, 5 December 2024 (UTC)
- The
- Idea Labmates …
- Because I had such high hopes of being on the trail of something practical to help prevent some of the main misunderstandings with which readers come to Wikipedia — and at the same time to foster awareness of how to use it to better advantage — I wonder if a little spark could get the discussion going again. Or does the idea not seem worth pursuing further? Augnablik (talk) 11:05, 30 November 2024 (UTC)
- I guess not.
- At least for now.
- 📦 Archive time. Augnablik (talk) 02:53, 3 December 2024 (UTC)
- I hope you won't be disheartened by this experience, and if you have any other good ideas will share them with us. There are two stages to getting an idea implemented in a volunteEr organisation:
- Getting others to accept that it is a good idea.
- Persuading someone to implement it.
- You have got past stage 1 with me, and maybe others, but I'm afraid that, even if I knew how to implement it, it wouldn't be near the top of my list of priorities. Phil Bridger (talk) 09:17, 3 December 2024 (UTC)
- Thank you, Phil. No, not disheartened … I think of it as an idea whose time has not yet come. I’m in full agreement about the two stages of idea implementation, plus a couple more in between to lead from one to the other.
- When we in the creative fields recognize that continuum and get our egos out of the way, great things begin to happen. Mine is hopefully drying out on the line.😅 Augnablik (talk) 09:41, 3 December 2024 (UTC)
- I hope you won't be disheartened by this experience, and if you have any other good ideas will share them with us. There are two stages to getting an idea implemented in a volunteEr organisation:
Wiki AI?
I would happily pay 25 cents per query if Wikipedia had its own AI chat interface. I use the Co-Star app (astrology) in this way already. I find the cost is worth the value. Free AI summaries available in search engines suffer from having too much garbage input (aka, the unrestrained data of the internet) to produce viable output. I would find it useful to have an AI interface built into Wikipedia. I already trust the information here and all "training data" for the hypothetical bot would effectively be open source. I would trust an AI bot managed by Wikipedia much more than I would trust an AI bot managed by any other entity. And I would be willing to pay for the service more often than I would be able to continue supporting the site through donation. 2603:6080:9F00:B05D:6205:4DF2:8C83:4343 (talk) 22:14, 18 November 2024 (UTC)
- Well, Wikipedia is free and open-source, so we won't be implementing a paid AI chatbot on principle. Regarding the idea of an AI chatbot in general, they are often prone to hallucinations and not necessarily as accurate as they are confident. And they can't be edited by individual users in case they were trained on factual errors, which again goes against Wikipedia's principles. Chaotic Enby (talk · contribs) 22:22, 18 November 2024 (UTC)
- I find the cost is worth the value. But is the value worth the cost? —Tamfang (talk) 21:03, 24 November 2024 (UTC)
- You could try NotebookLM from Google Labs as your interface to Wikipedia content. It's a pretty useful tool in general. Sean.hoyland (talk) 12:49, 30 November 2024 (UTC)
New users, lack of citation on significant expansion popup confirmation before publishing
There are many edits often made where a large amount of information is added without citations. For new users, wouldn't it be good if it was detected when they go to publish an edit lacking citations with a large amount of text, and came up with a popup of some sort directing them to WP:NOR, and asking them to confirm if they wish to make the edit? I think you should be able to then turn it off easily (as in ticking don't remind me again within the popup), but my impression is that many make edits without being familiar with the concept of rules such as WP:NOR. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 01:36, 19 November 2024 (UTC)
- You're describing mw:Edit check. Aaron Liu (talk) 02:15, 19 November 2024 (UTC)
- We can deploy it. Trizek_(WMF) (talk) 13:15, 19 November 2024 (UTC)
- Ooh, I didn't know we and dewiki didn't get deployment. Is there a reason? Aaron Liu (talk) 14:18, 19 November 2024 (UTC)
- If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)
- @Aaron Liu, Edit check is available on the visual editor. Having it on wikitext won't make sense as the goal is to teach users to add citations, not to teach them both about citations and wikitext. Let's reduce complexity. :)
- And the visual editor is still not the default editor at de.wp or en.wp. I advised to work on deploying both in parallel so that newcomers would have a better editing experience all at once (less wikitext, more guidance). Why am I not working on it now? Because it would take time. Now that the visual editor was used for years at all other wikis to make millions of edits, we should consider making it the default editor at English Wikipedia for new accounts. It could be a progressive deployment. I've not yet explored past reasons why English Wikipedia didn't wanted to have the visual editor being deployed, again for time reasons. But we would support any community initiative regarding VE deployment for sure.
- We could deploy Edit check without VE, but I'm afraid of a low impact on newcomers: they are less likely to be helped as long as VE remains the second editor.
- @Thryduulf, there were a discussion about Edit check in the past, you are correct. It covered multiple topics actually. I let you re-read it if you like; I didn't found "significant opposition" there, more questions about Edit Check, VE, citations and more, concerns on Edit Check and VE integration, and support for a better experience for newcomers (as long as it doesn't impact existing personal experiences).
- Trizek_(WMF) (talk) 15:37, 19 November 2024 (UTC)
- If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)
- Could you provide a couple of links to comments from people other than yourself, and which specifically opposed EditCheck (not the 'make the visual editor the default' or 'Citoid has some problems' sub-threads)? I just skimmed through the 81 comments from 19 editors in the proposal that Robertsky made, and while I might have missed something, your first comment, which was the 69th comment in the list, was the first one to oppose the idea of using software to recommend that new editors add more citations.
- Most of the discussion is not about EditCheck or encouraging refs. Most of it is about whether first-time editors should be put straight into the visual editor vs asking them to choose. The responses there begin this way:
- "I thought Visual Editor is already the default for new accounts and unregistered editors?" [25]
- "In theory, this sounds like a great idea. I'm eager to try it out..." [26]
- "I'd support making Visual Editor the default..." [27]
- "Agree 100%." [28]
- "I totally agree that VE should be the default for new users." [29]
- which is mostly not about whether to use software to encourage newbies to add more citations (the second quotation is directly about EditCheck; not quoted are comments, including mine, about whether it's technically necessary to make the visual editor 'the default' before deploying EditCheck [answer: no]).
- Then the thread shifts to @Chipmunkdavis wanting the citation templates to have "an easily accessed and obvious use of an
|author=
field, instead forcing all authors into|last
and|first
", which is about how the English Wikipedia chooses to organize its CS1 templates, and @Thryduulf wanting automatic ref names that are "human-friendly" (to take the wording RoySmith used), both of which entirely unrelated to whether to use software to encourage new editors to add more citations. - I see some opposition to putting new editors into the visual editor, and I see lots of complaints about automated refs, but I don't see any opposition from anyone except you to EditCheck itself. Please provide a couple of examples, so I can see what I missed? WhatamIdoing (talk) 17:57, 19 November 2024 (UTC)
- "which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)
- VisualEditor is perfectly capable of accepting actual aliases such as
|author=
, and even non-existent parameters such as|fljstu249=
if you want (though I believe the citation templates, unlike most templates, will emit error messages for unknown parameters). It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so. WhatamIdoing (talk) 05:12, 20 November 2024 (UTC)- If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)
- If you want this wikitext:
{{cite news |author=Alice Expert |date=November 20, 2024 |title=This is the title of my news story |work=The Daily Whatever}}
- which will produce this citation:
- Alice Expert (November 20, 2024). "This is the title of my news story". The Daily Whatever.
- then (a) I just did that in the Reply tool's visual mode, so it obviously can be done without any further coding in MediaWiki, VisualEditor, or anything else, and (b) you need to convince editors that they want "Alice Expert" at the start instead of "Expert, Alice" of citations. WhatamIdoing (talk) 21:07, 20 November 2024 (UTC)
- No, I don't have to convince editors that they want "Alice Expert" instead of "Expert, Alice". The issue is, as covered in the original discussion with some good input from others, non-western name formats. It is a cultural blindspot to assume all names fall into "Expert, Alice" configurations, and it seems that it is a blindspot perpetuated by the current VE expectations. CMD (talk) 01:39, 21 November 2024 (UTC)
- More precise link to the conversation: Help talk:Citation Style 1/Archive 95#Allowing Visual Editor/Citoid Citation tool to use more than one name format Trizek_(WMF) (talk) 11:02, 21 November 2024 (UTC)
- @Chipmunkdavis, I guess I'm having trouble understanding what you want.
- You said in the linked discussion that "My understanding is that the VE tool does not allow for the use of aliases". I'm telling you: Your understanding is wrong. It's obviously possible to get
|author=
in the visual editor, because I did that. Either this diff is a lie, or your understanding is mistaken. I'm going with the latter.|author=Mononym
is already possible. So what change are you actually asking for? - The linked discussion seems, to my eyes, to be a long list of people telling you that if you don't like the description used in the TemplateData (NB: not MediaWiki and not VisualEditor), then you should change the description in the TemplateData (NB: not MediaWiki and not VisualEditor) yourself. You say the devs told you that, and I count at least two other tech-savvy editors who told you to WP:SOFIXIT already. Neither the part that says "Last name" nor the part that says "The surname of the author; don't wikilink, use 'author-link'; can suffix with a numeral to add additional authors" is part of either the visual editor or MediaWiki. Any editor who can edit Template:Cite news/doc can change those words to anything they want. WhatamIdoing (talk) 20:22, 21 November 2024 (UTC)
- Having to type source wikitext completely defeats the purpose of the visual editor; why not just type in the wikitext editor. This "solution" is a blaring technicality.Perhaps you should read the last four replies in the linked discussion. Aaron Liu (talk) 00:00, 22 November 2024 (UTC)
- Right, this is the sort of odd reply this topic inexplicably gets. You can just type in source code in the visual editor, I mean, why have visual editor at all. Just change the description so people can pretend someone's name is their last name, now being suggested yet again as a simple SOFIXIT, and no I'm not going to deliberately and formally codify that we should mislabel people's names, for what I did think before these various discussions were obvious reasons. CMD (talk) 02:08, 22 November 2024 (UTC)
- @Chipmunkdavis, what I'd like to clarify is:
- If I type
|author=Sting
vs|last=Sting
, will this make any difference to anyone (human or machine) that ►is not looking at the wikitext. That last bit about not seeing the wikitext is the most important part. If the complaint is entirely about what's in the wikitext, then Wikipedia editors should treat it as the equivalent of a whitespacing 'problem': it's okay to clean it up to your preferred style if you're otherwise doing something useful, but it's not okay to force your preferred style on others just for the sake of having it be 'the right way'. - The options are:
- Those two are used as exact synonyms by the CS1 code, in which case it make no practical difference which alias is used, or
- Those two are handled differently by the CS1 code (e.g. emitting different microformatting information), in which case the CS1 code should not declare them to be aliases. AIUI aliases are only supposed to be used for exact substitutes.
- So which is it? WhatamIdoing (talk) 20:25, 28 November 2024 (UTC)
- Misnaming someone is not a style choice. (It is literally an item explicitly mentioned in the UCOC.) Even if it wasn't, your professed solution is that a new editor open up the visual editor and see "Last name: The surname of the author; don't wikilink, use 'author-link' instead; can suffix with a numeral to add additional authors. Please also use this field for names which don't have a first name last name structure."? That doesn't seem sensible or effective. CMD (talk) 00:12, 29 November 2024 (UTC)
- Where does the "misnaming" happen? To be clear, I'm expecting an answer that either sounds like one of these two:
- "Only in the wikitext, but that's still very bad".
- "In a reader/user-facing location, namely _____" (where the blank might be filled in with something like "in the COinS microformatting").
- Which is it? WhatamIdoing (talk) 07:49, 30 November 2024 (UTC)
- I would refer to the previous discussions above and elsewhere where it has already been extensively covered that both of those options are true. It would in the wikitext, and is currently in the visual editor citation creator. CMD (talk) 08:34, 30 November 2024 (UTC)
- "Both of those options are true" is not possible, when you name as the two locations:
- a place readers do not see ("in the wikitext") and
- another place readers do not see ("in the visual editor citation creator").
- So again: Where is the place readers see this "misnaming"? WhatamIdoing (talk) 19:06, 30 November 2024 (UTC)
- It feels deeply uncivil to say "So again" for a question you haven't asked before. It is really surprising to see "misnaming" quoted as if it's something incorrect; it's hard to word this but that comes off as a shocking level of continued cultural insensitivity. At this point the various questions at hand have been answered multiple times in the different discussions, and we're wandering again towards odd red herrings that have little relation to the fact that VE source generator users are forced into a single naming system, something long solved by the non-VE source generator. I recommend the link RoySmith provided in the previous discussions if you haven't already[30], and remain hopeful one day that others will try to care about the non Alice Experts of the world. CMD (talk) 02:13, 1 December 2024 (UTC)
- Sorry, I thought I had already been quite clear about that point:
- Are we now agreed that no readers and no actual article content are affected by this? WhatamIdoing (talk) 00:39, 4 December 2024 (UTC)
- New editors see the VE citation creator, and that is the concern. Aaron Liu (talk) 03:56, 1 December 2024 (UTC)
- People using the visual editor's template editor never see
|last=
on the CS1 templates. That is only visible to people using wikitext. - People using the visual editor's template editing tools see the locally defined TemplateData label "Last name", which CMD is free to change at any time to anything he can get consensus for, e.g., "Last name, sole name, or non-Western style name". WhatamIdoing (talk) 00:44, 4 December 2024 (UTC)
- People using the visual editor's template editor never see
- It feels deeply uncivil to say "So again" for a question you haven't asked before. It is really surprising to see "misnaming" quoted as if it's something incorrect; it's hard to word this but that comes off as a shocking level of continued cultural insensitivity. At this point the various questions at hand have been answered multiple times in the different discussions, and we're wandering again towards odd red herrings that have little relation to the fact that VE source generator users are forced into a single naming system, something long solved by the non-VE source generator. I recommend the link RoySmith provided in the previous discussions if you haven't already[30], and remain hopeful one day that others will try to care about the non Alice Experts of the world. CMD (talk) 02:13, 1 December 2024 (UTC)
- "Both of those options are true" is not possible, when you name as the two locations:
- I would refer to the previous discussions above and elsewhere where it has already been extensively covered that both of those options are true. It would in the wikitext, and is currently in the visual editor citation creator. CMD (talk) 08:34, 30 November 2024 (UTC)
- Where does the "misnaming" happen? To be clear, I'm expecting an answer that either sounds like one of these two:
- Misnaming someone is not a style choice. (It is literally an item explicitly mentioned in the UCOC.) Even if it wasn't, your professed solution is that a new editor open up the visual editor and see "Last name: The surname of the author; don't wikilink, use 'author-link' instead; can suffix with a numeral to add additional authors. Please also use this field for names which don't have a first name last name structure."? That doesn't seem sensible or effective. CMD (talk) 00:12, 29 November 2024 (UTC)
- Right, this is the sort of odd reply this topic inexplicably gets. You can just type in source code in the visual editor, I mean, why have visual editor at all. Just change the description so people can pretend someone's name is their last name, now being suggested yet again as a simple SOFIXIT, and no I'm not going to deliberately and formally codify that we should mislabel people's names, for what I did think before these various discussions were obvious reasons. CMD (talk) 02:08, 22 November 2024 (UTC)
- Editing the templatedata for |last= has been verily rejected in the discussion CMD already linked. Aaron Liu (talk) 17:10, 4 December 2024 (UTC)
- So we want text that is defined in TemplateData to say something different, but the method of changing that must not involve changing the text that is defined in TemplateData.
- I don't think that is a solvable problem, sorry. WhatamIdoing (talk) 23:11, 4 December 2024 (UTC)
- 1. How did you do that?
2. The author parameter is useful and used iff the author has no last name; e.g., byline being an organization, mononymous person, no author stated, etc. This is documented at the citation-style help pages. Aaron Liu (talk) 22:11, 20 November 2024 (UTC)- The
|author=
parameter behaves the same as the|last=
parameter, so there's little point in changing the wikitext to say|author=
. - (In this case, I took the quick and dirty approach of typing out the template by hand, and pasting it in. The Reply tool's visual mode normally won't let you insert a template at all, because block-formatted templates completely screw up the discussion format. Normally, if there's no TemplateData to provide you with the options, then you'd click on the "+Add undocumented parameter" button and type in whatever you wanted. If there is TemplateData, then see my earlier comment that "It just isn't going to "suggest" them when the CS1 maintainers have told it not to do so.") WhatamIdoing (talk) 23:08, 20 November 2024 (UTC)
- The
- It's semantically different, like the em tag vs italicizing and whatnot. And as I've said before, the documentation doesn't suggest it so that the clueless will not use both |last and |author. Aaron Liu (talk) 23:57, 20 November 2024 (UTC)
- I've never had much sympathy for prioritizing COinS. If it's an area that interests you, then I suggest watching Wikipedia:WikiProject Microformats. WhatamIdoing (talk) 00:30, 21 November 2024 (UTC)
- No, I don't have to convince editors that they want "Alice Expert" instead of "Expert, Alice". The issue is, as covered in the original discussion with some good input from others, non-western name formats. It is a cultural blindspot to assume all names fall into "Expert, Alice" configurations, and it seems that it is a blindspot perpetuated by the current VE expectations. CMD (talk) 01:39, 21 November 2024 (UTC)
- If you want this wikitext:
Aaron Liu (talk) 12:22, 20 November 2024 (UTC)If someone adds |authorn= as a separate parameter, I fear that we will see an increase in the number of articles that populate Category:CS1 errors: redundant parameter because OMG!-there's-an-empty-box-in-the-form;-I-must-fill-it. This is why I suggested radio buttons for aliases; something that MediaWiki would needs implement.
- If you know how to solve the problem, please solve the problem. Per Help talk:Citation Style 1/Archive 95, "The solution to the ve-can't/won't-use-already-existing-alias-list problem lies with MediaWiki, not with editors adding yet more parameters to TemplateData". As it stands, VE doesn't do it, and I've seen no indication that they consider it an issue. CMD (talk) 12:00, 20 November 2024 (UTC)
- VisualEditor is perfectly capable of accepting actual aliases such as
- "which is about how the English Wikipedia chooses to organize its CS1 templates" is perhaps one way to say that the VE has no functionality to accept the synonyms, which I discovered in a few disparate conversations following that thread. I still have a tab open to remind me to put a note about phab on this, it's really not ideal have VE editors shackled with the inability to properly record author names. CMD (talk) 01:42, 20 November 2024 (UTC)
- You missed that none of them tested it or checked it on other wikipedia versions, and that no support came along after I had tested it and posted my results? No surprise here... Fram (talk) 19:17, 19 November 2024 (UTC)
- No comments came along after that either, so we don't really know. Aaron Liu (talk) 19:18, 19 November 2024 (UTC)
- There's a big gap between "The discussion stopped" and "There was significant opposition in this discussion".
- In terms of EditCheck, I found most of the discussion to be off-topic, but I can honestly only find one editor (you) who opposed it in that discussion. I assume your failure to provide links to any other statement of opposition means you also honestly can't find a single comment in that discussion from anyone who agreed with you – just an absence of further comments, and an unprovable assumption on your part that its due to everyone agreeing with you. WhatamIdoing (talk) 19:28, 19 November 2024 (UTC)
- Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)
- I don't think I presented the discussion in the most WMF-favorable light. The discussion started off pretty enthusiastic, but it was mostly enthusiastic about something other than EditCheck itself. It then turned into a long digression into something completely unrelated.
- (My own contributions to that discussion were technical in nature: It doesn't require the visual editor as the default; code may already exist for an unrelated change that someone wants; stats may already exist for something close to the numbers someone else wants.) WhatamIdoing (talk) 19:56, 19 November 2024 (UTC)
- Didn't stop you from making any assumptions or presentings things in the most WMF-favorable light. Seems like VE all over again, only then you had the excuse of being paid by the WMF. Fram (talk) 19:45, 19 November 2024 (UTC)
- No comments came along after that either, so we don't really know. Aaron Liu (talk) 19:18, 19 November 2024 (UTC)
- (ec) Fram, this is precisely because I reread the conversation that I wrote my previous message. We have the right to disagree, but it should remain civil and not convey accusations of bad faith. The way you try to depict me as a dishonest person is not acceptable at all.
- I let other participants have a look at the previous discussion we linked, also take a look at the data we provided, and make their own opinion. We aren't the two people who will decide of a deployment here: I'm just the messenger, and you are not the person who has the final word on behalf of everyone. Trizek_(WMF) (talk) 18:00, 19 November 2024 (UTC)
- Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)
- Since there are non-native English speakers in this discussion, I'd like to clarify that "dishonest", in English, means that the person deliberately told the opposite of the truth. For example, it is dishonest to say "I love Windows ME", when you actually hate it.
- However:
- Having incorrect or outdated information is not "dishonest".
- Caring about a particular benefit more than a different problem is not "dishonest".
- Disagreeing with you, or with a hypothetical average reasonable person, is not "dishonest".
- There's a reason that English has an idiom about an "honest mistake": It's because it's possible to be factually wrong without being dishonest. For example, if you say "Oh, User:Example said something yesterday", but upon further inspection, it was a different user, or a different day. Or even if you say "The previous discussion shows significant opposition to EditCheck", but upon further inspection, nobody except you publicly opposed it. Such a sentence is only dishonest if the speaker believes, at the time of speaking, that the statement is factually wrong. Unless the speaker believes themselves to be speaking falsehoods, it's not actually dishonest; it's only a mistake or an error.
- Additionally, I think it would be a good idea to review Wikipedia:No personal attacks#What is considered to be a personal attack?. I suggest paying specific attention to these two points:
- "Using someone's affiliations as an ad hominem means of dismissing or discrediting their views" – Claiming, or even implying, that WMF staff have a tendency to be dishonest is probably a violation of this point in the policy.
- "Insulting or disparaging an editor is a personal attack regardless of the manner in which it is done." – Claiming that anyone is "dishonest", especially when the difference between your view and theirs is a matter of opinion, is very likely a violation of this policy. It doesn't officially matter if the manner in which you say this is "you are dishonest" or "your replies are dishonest"; it's still insulting and disparaging another editor.
- WhatamIdoing (talk) 19:45, 19 November 2024 (UTC)
- Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)
- I believe you'll find my view of visual editor circa July
20232013 right here in the barnstar I gave you. I wouldn't describe it as "defend the WMF no matter what", but perhaps you will look at it and refresh your memory of the time. WhatamIdoing (talk) 20:00, 19 November 2024 (UTC)- 2013, not 2023. July was early days in VE testing, when I still thought you were helpful. A few months later I had become wiser. Fram (talk) 20:20, 19 November 2024 (UTC)
- If you need a reminder, here is just one of many examples from that terrible period: Wikipedia:VisualEditor/Feedback/Archive 2013 13#Diligent testing by Fram, my comment of 08:03 12 December.
- I believe you'll find my view of visual editor circa July
- Like I said, one can post all distruths one wants as long as one does it civilly. Reminds me of the discussions we had about VE when it was disastrously deployed but all you did as a liaison was defend the WMF no matter what. And I didn't say their replies were dishonest because they are a WMF employee, just that it is typical behaviour for many of them apparently. Perhaps reread the breakdown of the Gather discussions I gave below, or reread the countless discussions about Flow, VE, descriptions, ... There are some good apples among them, but not too many. Fram (talk) 19:51, 19 November 2024 (UTC)
- Tough luck. You posted a dishonest reply last time we had this discussion. If it had been a genuine error in that previous discussion, you should have just said so. Instead, you not only let your error stand, but then come here and claim that there was no significant opposition to Edit Check in that previous discussion, ignoring the one person who tested it and posted results. And like I said in that discussion, the data the WMF provides is not to be trusted at all, as seen from other deployments. Which I already stated and you again ignore completely. But, like I said, the WMF (and previous WMF employees like Whatamidoing) are very good at civil bullshit, while I am not so good at the civil part but rather good at cutting through the bullshit. Fram (talk) 19:17, 19 November 2024 (UTC)
- For what its worth, I do think a RfC can be made once the proposed details of the deployment is firmed up:
- Do we make VE as the default for new editors?
- Do we enable EditCheck as it is?
- Aside, if we retain the current arrangement, i.e. letting new/anon editors selecting their preferred editor, can we change the buttons to be more balanced in colours and sizing? These do affect one's preference in choosing which button to click. – robertsky (talk) 18:16, 19 November 2024 (UTC)
- robertsky, that's two RFCs, and – respectfully – conflating the two questions was a primary contributor to how far off the rails this conversation got last time.The UX alterations are probably best brought up at meta or mw for the skins devs to consider. Folly Mox (talk) 18:55, 19 November 2024 (UTC)
- Gather was dropped after 3 months (without any "broken WMF promises" nor any time for them to have given such promises or to have acrimoniously debated), and Wikidata SDs seem to be deployed and working completely fine. Aaron Liu (talk) 18:25, 19 November 2024 (UTC)
- Gather was deployed in March 2015 and immediately got severe backlash at the announcement: Wikipedia:Administrators' noticeboard/Archive270#Extension:Gather launching on beta. No good answers followed. So three weeks later we get Wikipedia:Administrators' noticeboard/Archive270#Moderation of Collections?, where we get (laughable) promises of what the WMF will do to solve some of the most basic problems of this tool they rolled out on enwiki but hadn't really thought about at all it seems. Instead, they created a new Flow page on enwiki for this tool (Wikipedia:Miscellany for deletion/Wikipedia:Gather/User Feedback) despite Flow being removed from enwiki long before this. So in January 2016 (hey, that's already 10 months, not 3), Wikipedia:Village pump (proposals)/Archive 130#Disabling Gather? was started. On 22 Januuary 2016, an answer was promised by the WMF "next week" (section "A WMF reply next week"): "by next week, the Gather team will have a major update to share about the feature". Things escalated, so another WMF person came along 6 days later to promise "we will be putting together this analysis starting now with the intention of sharing publicly next week with a decision the week after." (section "A Response from the WMF"). So instead of some great announcement after 1 week, we are now 6 days further and will get big news 2 weeks later... So, more than 2 weeks later, 12 February, we get "the analysis has taken longer than I anticipated. I'll post the results as soon as I can." So, on the 19th, they posted a "proposal" to which others replied "that proposal is an insult to the community." and "his smacks of yet more stalling tactics and an attempt to save face". Only when the RfC was closed with truly overwhelming supprt to disable it did they finally relent.
- Do you really need a similar runthrough of Wikidata short descriptions, which are (or should be) disabled everywhere on enwiki and replaced by local descriptions instead? Or will you admit that perhaps you didn't remember details correctly? Fram (talk) 19:41, 19 November 2024 (UTC)
- Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather.
By no fault of its own, Shortdesc helper made me conflate WD descriptions and SDs. Aaron Liu (talk) 20:42, 19 November 2024 (UTC)
- Yeah man I don't remember anything well, I wasn't there. I'm just reading random things I can find to see what you're talking about, such as the MediaWiki page that states development was suspended by July 2015, but as you've pointed out, that is different from disabling, and thank you for helping me to find. Thanks for your links on Gather.
- I never suggested deploying it on the source editor. Having not fully read the above discussion yet, it currently seems unreasonable that it's not deployed in the visual editor on enwiki and dewiki (while preserving the current "level of defaultness" of the visual editor itself instead of increasing the defaultness). Aaron Liu (talk) 16:30, 19 November 2024 (UTC)
- @Aaron Liu, I never implied you suggested it, I was just one step ahead telling you that it is not available on source editor. :) We can deploy Edit check without changing the "level of defaultness" of the visual editor itself, but the impact might not be the same. Trizek_(WMF) (talk) 18:09, 19 November 2024 (UTC)
- If you didn't see "significant oppo sition" there, then perhaps reread it? The tool you deployed elsewhere had no measurable positive impact (when tested on Simple or French Wikipedia). As for past reasons why enwiki didn't want VE deployed, let's give you one: because when VE was deployed here, it was extremely buggy (as in, making most articles worse when used, not better), but the WMF refused to undo their installation here (despite previous assurances) and used enwiki as a testing ground, wasting tons of editor hours and creating lots of frustration and distrust towards the WMF. This was only strengthened by later issues (Flow, Gather, Wikidata short descriptions) which all followed the same pattern, although in those cases we eventually, after lots of acrimonious debates and broken WMF promises, succeeded in getting them shut down). As shown in the linked discussion, here again we have two instances of WMF deployments supported by test results where in the first instance reality showed that these were probably fabricated or completely misunderstood, as in reality the results were disastrous; and in the second instance, Edit Check, reality showed that the tool wasn't an improvement over the current situation, but even when spelled out this was "misread" by the WMF. Please stop it. Fram (talk) 15:50, 19 November 2024 (UTC)
- (ec) Probably Wikipedia:Village pump (proposals)/Archive_213#Deploying_Edit Check on this wiki. Having reread that thread, it combines all WMF rollout issues into one it seems, from starting with false requirements over a testing environment which isn't up-to-date at all to completely misreading everything that is said into something supposedly positive, ignoring the stuff that contradicts their "this must be pushed no matter what" view. But all in a very civil way, there's that I suppose... Fram (talk) 15:39, 19 November 2024 (UTC)
- What an utterly weird objective for that tool "Newcomers and Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing to publish changes they are proud of and that experienced volunteers consider useful." Very neocolonial. Fram (talk) 15:25, 19 November 2024 (UTC)
- Indeed. I provided some detailed feedback about this, based on my experience of African editors and topics – see Dark Continent. Andrew🐉(talk) 16:02, 19 November 2024 (UTC)
- Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)
- I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)
- The experienced contributors from sub-Saharan Africa who helped write that goal did not feel it was insulting or patronizing. WhatamIdoing (talk) 21:11, 19 November 2024 (UTC)
- I can't help it if you don't see how insulting and patronizing it is to write "Junior Contributors from Sub-Saharan Africa will feel safe and confident enough while editing". Fram (talk) 20:26, 19 November 2024 (UTC)
- Different parts of the world have different responses to UX changes. A change that is encouraging in a high-resource setting (or an individualistic culture, or various other things) may be discouraging in others. It is therefore important to test different regions separately. The Editing team, with the strong encouragement of several affiliates, decided to test sub-Saharan Africa first. WhatamIdoing (talk) 19:50, 19 November 2024 (UTC)
- Indeed. I provided some detailed feedback about this, based on my experience of African editors and topics – see Dark Continent. Andrew🐉(talk) 16:02, 19 November 2024 (UTC)
- If I'm thinking of the right tool, there was a discussion (at one one of the village pumps I think) that saw significant opposition to deployment here, although I can't immediately find it. I seem to remember the opposition was a combination of errors and it being bundled with VE? I think Fram and WhatamIdoing were vocal in that discussion so may remember where it was (or alternatively what I'm mixing it up with). Thryduulf (talk) 15:21, 19 November 2024 (UTC)
- Ooh, I didn't know we and dewiki didn't get deployment. Is there a reason? Aaron Liu (talk) 14:18, 19 November 2024 (UTC)
- We can deploy it. Trizek_(WMF) (talk) 13:15, 19 November 2024 (UTC)
Redone my check at Simple wiki, looking at the most recent edits which automatically triggered this tool[31]. 39 instances were automatically indicated as "declined", the other 11 contain 3 edits which don't add a reference anyway[32][33][34] and 6 edits which actually add a reference[35][36][37][38][39][40] (though 3 of these 6 are fandom, youtube and enwiki). And then there is this and this, which technically add a source as well I suppose... Still, 3 probably good ones, 3 probably good faith bad ones, 3 false positives, and 2 vandal ref additions. Amazingly, this is almost the exact same result as during the previous discussion[41]. Fram (talk) 16:21, 19 November 2024 (UTC)
- I think just creating one good source addition is enough cause for deployment (without making VE the default editor), especially since it doesn't appear to be causing additional harm. Aaron Liu (talk) 16:59, 19 November 2024 (UTC)
- If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)
- Editors who got a popup did not originally give a source when attempting to publish. That is more good source additions. Aaron Liu (talk) 17:11, 19 November 2024 (UTC)
- @Aaron Liu, have you had a read at the data we gathered around Edit check? Trizek_(WMF) (talk) 18:12, 19 November 2024 (UTC)
- I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)
- What you observed (Editors who got a popup did not originally give a source when attempting to publish) is shown in the data we shared.
- We already deployed checks to verify if a link added is not listed in rejection lists and make it more actionable by newcomers. Some users at other wikis expressed a need to have a list of accepted links (the ones that match RSP), but other said that it could prevent new good sources from being added. Thoughts?
- Trizek_(WMF) (talk) 18:37, 19 November 2024 (UTC)
- Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)
- I'm not sure to understand, sorry. Stats are about users adding a citation when asked compared from where not asked. It is not connected to RSP.
- I take note that you are in favor of expanding reliability information when the user adds a link. Trizek_(WMF) (talk) 20:01, 19 November 2024 (UTC)
- Isn't that the programmed heuristic for when the popup appears? I don't get what this has to do with any stats.Only URLs in the spamlist are blocked. Edit check should strongly warn against adding sources found generally unreliable by consensus summarized at RSP. Aaron Liu (talk) 18:59, 19 November 2024 (UTC)
- I'm not sure what that has to do with my reply. Fram was disputing that the source additions were good and useful, and I was replying to him that some of them were good, hence edit check should be deployed (plus I'm fairly sure there's another check in the works to check reference URLs against the local RSP) Aaron Liu (talk) 18:21, 19 November 2024 (UTC)
- @Aaron Liu, have you had a read at the data we gathered around Edit check? Trizek_(WMF) (talk) 18:12, 19 November 2024 (UTC)
- Editors who got a popup did not originally give a source when attempting to publish. That is more good source additions. Aaron Liu (talk) 17:11, 19 November 2024 (UTC)
- If it doesn't create more good source additions than we had before the tool, then there is no reason to deploy something which adds a popup which people usually don't use anyway. Without the popup, there also were new editors adding sources, it's not as if we came from zero. No benefit + additional "noise" for new editors => additional harm. Fram (talk) 17:10, 19 November 2024 (UTC)
- Also, I wonder what you think of the lower revert rate from WMF's study. Aaron Liu (talk) 19:19, 19 November 2024 (UTC)
- Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)
I'm new to all this, could you elaborate on why?I don't trust WMF numbers at all
The 5 bad ones would have included no source at all if Edit Check wasn't there. I don't see how adding a blatantly terrible source is worse than adding text without a source at all. Both are checked the exact same way: eye-scanning.the 5 bad ones wouldn't have been included otherwise either
So there you go, net benefit and no harm. Aaron Liu (talk) 20:11, 19 November 2024 (UTC)- No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)
- @Aaron Liu, I think this is a "reasonable people can disagree" thing. Some RecentChanges patrollers just revert any new unsourced claim, so if it's unsourced, it's quick to get out of the queue. Faster reverting means success to them, whereas encouraging people to add sources is like whispering a reminder to someone during a game of Mother, May I?: It removes an easy 'win' for the reverter.
- OTOH, having a source attached to bad information has other advantages. It's easy to determine whether it's a copyvio if you have the source, and if you're looking at an article you know something about (e.g., your own watchlist rather than the flood in Special:RecentChanges), then having the source often means that you can evaluate it that much faster ("This is a superficially plausible claim, but I wouldn't trust that website if it said the Sun usually rises in the East").
- For content that shouldn't be reverted, then IMO encouraging a source is always a good thing. For content that should be reverted, there are tradeoffs. WhatamIdoing (talk) 21:22, 19 November 2024 (UTC)
- I miss things, especially on a workday. Sorry about that.
I think the mobile short-descriptions thing is believable, as users . This is a case of the methodology being technically correct but misleading, which I don't see for the edit check study, unless you're willing to provide an argument.
IMO, only slightly. Often, only users of experience patrol pages when reading them. (The unacquainted are also sometimes able to realize something's probably wrong with a swath of unsourced text, hence they make up part of the aforementioned "slightly".) And blatantly bad sources jump out to those experienced from the references section. Sources in the middle ground can often link to good sources, though there is a debate on how good it is to have both additionally middle-ground and bad sources vs. no sources at all. Personally, I think it's better. Aaron Liu (talk) 21:47, 19 November 2024 (UTC)an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious.
- Now that a number of people have spoken out on the subject (a few not against it, one other strictly against), what's the next step? Trizek_(WMF) (talk) 11:06, 21 November 2024 (UTC)
- To make a specific proposal then the next step would be a formal Request for Comment. Andrew🐉(talk) 11:40, 21 November 2024 (UTC)
- This is not something I can lead at the moment, but I can assist anyone who would like to start the process. Trizek_(WMF) (talk) 10:03, 22 November 2024 (UTC)
- To make a specific proposal then the next step would be a formal Request for Comment. Andrew🐉(talk) 11:40, 21 November 2024 (UTC)
- Now that a number of people have spoken out on the subject (a few not against it, one other strictly against), what's the next step? Trizek_(WMF) (talk) 11:06, 21 November 2024 (UTC)
- No. I explained it already in the previous discussion. You have made false claims about Gather and so on, but can't be bothered to reply when I take the time to give a detailed answer; but now you are apparently "new to all this" suddenly and want me to again take some time to enlighten you. No. And an unsourced statement is obvious to see, a statement sourced to a bad source is much less obvious. Fram (talk) 20:24, 19 November 2024 (UTC)
- Like I said, of the 11 supposed additions, 5 need reverting (as far as the source goes) and 3 didn't add a source. I don't trust WMF numbers at all, but 5/8 needing a revert is hardly an overwhelming success. Even assuming that the 3 good ones wouldn't have added a source otherwise, one then has to make the same conclusion for the others, and the 5 bad ones wouldn't have been included otherwise either. So where is the net benefit and the no harm? Fram (talk) 19:54, 19 November 2024 (UTC)
Workshopping the RfC question
Given that there are several editors here interested in the feature turning on, I would like to propose the following question and a brief/neutral backgrounder to be asked for the RfC:
Should mw:Edit check be turned on?
Background: Edit Check is Wikimedia Foundation's product to encourage new editors to add citations to their edits, by prompting them with pop-ups before publishing. The pop-ups will work under the following default conditions (points 2 - 4 can be configured further):
- If editing is done through Visual Editor.
- ≥40 consecutive characters added.
- All accounts with < 100 edits
- All sections*
For point 4, I also propose to modify the configuration to exclude this feature from the following sections:
- lead section, as we don't not require leads to have citations
- Notes section, usually handled by {{efn}} in content body, etc.
- References section, no citation required
- External links section, no citation required
- See also section, no citation required
- Further reading section, no citation required (thanks, Chipmunkdavis)
- And any other sections (that I have missed out, and in the future) that do not require citations.
For future changes of the configuration setting, this can be done on wiki through modifying MediaWiki:Editcheck-config.json file after discussing in an appropriate venue. This also means that other than the initial activation, we do not require further changes in the backend (and if we would want to rollback before deactivating in a server update, we can set the max edit count to 1 as a temporary measure).
Prior discussions about this feature can be found at and Village pump (idea_lab) and Wikipedia:Village_pump_(proposals)/Archive_213#Deploying_Edit_Check_on_this_wiki.
@Trizek (WMF): do correct the above if there's anything that I have stated incorrectly. Also, with regards to the configuration settings, can mw:Community_Configuration be utilised as well? – robertsky (talk) 14:24, 30 November 2024 (UTC)
- @Robertsky, all is correct. Also, at the moment, Edit check has not been integrated to Community Configuration but, as you mention, the
json
file attached to Edit check allows your community to decide on de/activation. Trizek_(WMF) (talk) 09:11, 2 December 2024 (UTC) - Further reading section. Idly thinking, is the 100 edits namespace configurable? Further, just to check, "≥40 consecutive characters added." means "≥40 consecutive characters added without a ref tag" or similar? CMD (talk) 09:24, 2 December 2024 (UTC)
- @Chipmunkdavis
- The 100 edits is not namespace configurable. From the codes, it is checked against
wgUserEditCount
JavaScript variable. There is no JavaScript variable(s) for breakdown of edit counts by namespace at the moment, going by this documentation. - I suppose so as well.
- The 100 edits is not namespace configurable. From the codes, it is checked against
- – robertsky (talk) 11:55, 2 December 2024 (UTC)
- 1. Correct. We can have “only activate this check in this namespace” though.
- 2. Correct as well. Any type of reference tag or any template that uses
<ref>
at some point is detected. Trizek_(WMF) (talk) 17:31, 2 December 2024 (UTC)
- @Chipmunkdavis
- Take a look at the possibilitiess under Heading names in Wikipedia:Manual of Style/Layout#Notes and references. Whether or not to exclude some heading names will often depend on where they occur in the article. Donald Albury 16:34, 2 December 2024 (UTC)
Don’t put up Ip addresses for those who are not signed in.
You see, if someone edits Wikipedia and they are not signed in, their IP address is exposed. That means one could track where they live and dox them further. So yeah, don’t put the Ip adrees. But what if the person does an edit that ruins the page, or something bad? you see Wikipedia will have the ip address, and all what they have to do is report the anonymous person, Who will have a name, like not logged in or something, then Wikipedia will block it. Have a good day. Bye bye! Datawikiperson (talk) 09:46, 19 November 2024 (UTC)
- @Datawikiperson Please see Trust and Safety Product/Temporary Accounts - a project to implement more-or-less what you've described is planned and currently in the process of rolling out! Sam Walton (talk) 09:53, 19 November 2024 (UTC)
- FYI, you can't get an exact location from an ip. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 16:01, 19 November 2024 (UTC)
- Sometimes you can. It might not come down to "third desk on the right", but IPs sometimes identify a single building. WhatamIdoing (talk) 18:00, 19 November 2024 (UTC)
- IP addresses will give the location of the ISP node, or if the router has a location recorded with the ISP it will show that, most private routers do not show their location and will just show the ISP node. Try it yourself on a website like https://www.iplocation.net/. But you're right, sometimes it can that's true. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 18:12, 19 November 2024 (UTC)
- It's certainly true less often than it was in 1990s. WhatamIdoing (talk) 21:46, 19 November 2024 (UTC)
- The disaster of "IP masking" is that it will give all the different IP addresses used by the editor over the past 90 days, and of course you can keep sampling so you can effectively build up a profile of the editor's movements in perpetuity. This highly personal information is made available to autoconfirmed editors, so virtually everyone. This is dynamite, and the GDPR has specific safeguards so that the editor can see what she is getting herself into before she commits herself. The Foundation knows nobody would ever accept these terms so lies by omission - it simply says "a temporary account will be opened for you" without warning that the editor's control over her personal information will be cut off. They run a talkpage over at Mediawiki, but even when they are pinged they ignore the awkward questions. LD asked a question of Niharika Kohli at 13:22 on 15 November and is still waiting for an answer. — Preceding unsigned comment added by 92.25.132.250 (talk) 14:24, 28 November 2024 (UTC)
- Agree that the requirements should very much not be available that easily (although the actual terms are 6 months and 300 edits). I wouldn't be opposed to making it available only to CheckUsers or administrators, as they actually have some level of community vetting (or to make a new specific permission for that purpose). Another possible thing that could be done would be to log the IP checks to ensure transparency. Chaotic Enby (talk · contribs) 15:08, 28 November 2024 (UTC)
- The disaster of "IP masking" is that it will give all the different IP addresses used by the editor over the past 90 days, and of course you can keep sampling so you can effectively build up a profile of the editor's movements in perpetuity. This highly personal information is made available to autoconfirmed editors, so virtually everyone. This is dynamite, and the GDPR has specific safeguards so that the editor can see what she is getting herself into before she commits herself. The Foundation knows nobody would ever accept these terms so lies by omission - it simply says "a temporary account will be opened for you" without warning that the editor's control over her personal information will be cut off. They run a talkpage over at Mediawiki, but even when they are pinged they ignore the awkward questions. LD asked a question of Niharika Kohli at 13:22 on 15 November and is still waiting for an answer. — Preceding unsigned comment added by 92.25.132.250 (talk) 14:24, 28 November 2024 (UTC)
- It's certainly true less often than it was in 1990s. WhatamIdoing (talk) 21:46, 19 November 2024 (UTC)
- IP addresses will give the location of the ISP node, or if the router has a location recorded with the ISP it will show that, most private routers do not show their location and will just show the ISP node. Try it yourself on a website like https://www.iplocation.net/. But you're right, sometimes it can that's true. 𝙏𝙚𝙧𝙧𝙖𝙞𝙣𝙢𝙖𝙣地形人 (talk) 18:12, 19 November 2024 (UTC)
- Sometimes you can. It might not come down to "third desk on the right", but IPs sometimes identify a single building. WhatamIdoing (talk) 18:00, 19 November 2024 (UTC)
- See the Guardian article by Victoria Turk, In our house, 'smart' devices aren't welcome (9 November). 92.25.132.250 (talk) 14:33, 28 November 2024 (UTC)
Independent Politicians
Where possible add a section where general info is for sn independent politicians indicate what political position they are ie center, left, right etc 2001:BB6:514B:A300:D35B:58F7:1327:A55 (talk) 00:39, 22 November 2024 (UTC)
- I don’t know what that means Dronebogus (talk) 10:59, 24 November 2024 (UTC)
- {{Infobox officeholder}} already has a parameter for "Other political affiliations", which might be what you are looking for. Otherwise, yes, a section in the article text can be written if there are enough sources to position the person on the political spectrum, but there shouldn't be a strict guideline mandating it to be present, especially since these affiliations can be controversial or contested. Chaotic Enby (talk · contribs) 12:02, 24 November 2024 (UTC)
- There are also many politicians whose views do not neatly fit into a simple left-centre-right box, especially as right-of-centre UK politics is roughly equivalent to the left wing of mainstream US politics. Thryduulf (talk) 00:49, 5 December 2024 (UTC)
- The Nolan chart would be slightly better, but as you say, would have to be adjusted for different countries. Donald Albury 02:14, 5 December 2024 (UTC)
- There are also many politicians whose views do not neatly fit into a simple left-centre-right box, especially as right-of-centre UK politics is roughly equivalent to the left wing of mainstream US politics. Thryduulf (talk) 00:49, 5 December 2024 (UTC)
Dead pixels, an expansion to WP:CITEWATCH, a new noticeboard?
Bit of a long one... more of an essay at this point really, but IMO, it might be worth it to prevent editor burnout and bring in new users, so here goes: You know how once one spots a dead pixel, they can't seem to ignore it? Then one starts wondering whether the monitor vendor has either: gotten sloppy with their work... or if they just got unlucky given the volume of monitors that get put out by the vendor. Then the dread of calling the warranty department...
Just like the analogy above, the news and research outputted by reliable sources is generally problem free. But because of the volume of information, occasionally errors will get in. Sometimes even unscrupulous outlets gets in. But unless one is motivated or knowledgeable enough, few will go through the effort of comparing what the reference says to its references (reference-in-reference). This is the dead pixel problem I'm talking about, and just like a dead pixel, annoys the crap of the person who sees it, for better or worse. Then comes the process of "fixing" it: currently, original research issues, and reference-in-reference issues are handled in science by PubPeer, whose extension is used by a paltry number of users. Response times by authors take days, maybe years even with relentless journalism. At any rate, most people who feel compelled to edit Wikipedia due to accuracy problems have probably never heard of PubPeer. And as for issues with regular journalists, I suppose one could turn to opinions by third parties like NewsGuard? And meanwhile, they can usually get away with publishing contradictory health news without being called out for it.
All made more worrying given that impact Wikipedia has on the real-world non-Wikipedians, like judges and scientists. Recent political developments, as well as LLM usage (see WP:CNET), mean that once reliable sources could suddenly hallucinate or contradict other sources on a whim. Maybe the errors made daily won't be indicative of LLM usage... but they could. In any case, we don't currently track these issues, so whose to say what patterns unreliable sources follow?
Mistake or no mistake, when the inaccuracy is inevitably spotted (probably by us, I wonder why...), an attempt will probably be made to re-balance the article or add footnotes following WP:Inaccuracy. This works great... if you are the only editor of a given article. For everyone else, because not everyone will necessarily see a dead pixel as a big deal, the actions may seem disproportionate and/or violate certain consensus policies, and the talk page will go on and on, maybe then to WP:DRN driving away casual but knowledgeable editors, all of which will be seen by hardly anyone, let alone the original author of the source. One could then go to WP:RSN, but that noticeboard is really only equipped to handle the most problematic and fringe sources, not really the daily errors that get published by sources day to day. We burn out, and the world, by and large, hardly notices the dispute.
To solve this, I propose some sort of objective-ish tracking in WP:CITEWATCH of reference-in-reference accuracy (in line with Wikipedia's policy of WP:NOR) as well as other issues like typos, linking issues, cotogenesis, copyright violations, notable omissions, and most importantly, corrections (sure sign of a RS), and the time elapsed from error spotting to correction for refs, all heuristics that, when aggregated, could be indicative of a sloppy copyeditors or cursory peer review. Editors could put in a template with the relevant issue, hidden by default until patrolled. If there is a dispute, a new reference-in-reference noticeboard, split into categories (typos, copyright violations, etc.)
Bonus benefits - we might finally:
- Know which MDPI journals have decent peer review, allowing them to build a reputation?
- Create an easy place to show that the consensus on WP:ALJAZEERA is justified?
- Create an incentive to keep more accountable (especially on health related topics)? As well as obscure sources on obscure topics that may only be read by the Wikipedian.
- Reduce biting and attrition by creating an easy place for sub-WP:RSN issues to be reported, counted and easily exportable to PubPeer or elsewhere?
- Problematically high counts could then easily be reported to WP:RSN without the need for extensive, hard-to-read discussion.
Other references
| ||||
---|---|---|---|---|
Retraction Watch: Basis for "notable omissions": |
Unfinished ideas, subject to change
|
---|
Older pre-internet sources might be less affected by ref-in-ref errors, since the reader could be reasonably expected to check the sources, necessity. WVhere ref-in-ref notices go to the reader: Probably inside ref tags, after the chosen citation template? This proposal could involve multiple changes to various guideline pages. WP:Inaccuracy will probably be changed the most by this proposal. Patrolling - Mostly in anticipation of misunderstanding of policy, and WP:NOR. Noiceboard name - RRN, reference-in-reference noticeboard? To avoid flooding the noticeboard, require discussion on talk page first? Split noticeboard into categories? Categories - Categories will be separated into errors that will be reported to readers when patrolled, and those that will just be tracked by an expanded SOURCEWATCH table, for later discussion on RSN.
Perverse incentives? Less citing of sources overall? Counterpoints: Existing incentives to cite to increase impact or whatever. Could be solved with another category:
|
Rolling this out might take an extended period of time, and will probably involve the WMF as well as new templates, modules, instructions, etc. Thoughts on this, as well as how improvements could be broken up or rolled out? ⸺(Random)staplers 03:56, 25 November 2024 (UTC)
- This seems to have a lot of thought, but frankly I have no idea what this proposal is actually proposing. Ca talk to me! 07:30, 1 December 2024 (UTC)
- Is the proposal about placing discussions of reliability about the cited source inside the citations themselves? Ca talk to me! 07:32, 1 December 2024 (UTC)
Template for Tetragrammaton
In article concerning Judaism, there ae multiple references to the Tetragrammaton, both in Hebrew and romanized. It would be convenient to have a template that generated יהוה (YHVH, YHWH), possibly with an option for the older Canaanite script. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:53, 26 November 2024 (UTC)
- This is the English language Wikipedia and so there's already a template for the English version of this: {{LORD}}, which displays as LORD, as per the KJV. Andrew🐉(talk) 17:57, 3 December 2024 (UTC)
- That template generates the English translation of the substitution אֲדֹנָי (Adonai transl. my Lord[s]), not the actual Tetragrammaton. There are multiple places in wiki where the actual Tetragrammaton is given, and it would be convenient if there were a template to save typing. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:58, 3 December 2024 (UTC)
Requested move ECR notices
WP:GS/RUSUKR, WP:GS/AA, and WP:GS/KURD all state that:
[…] non-extended-confirmed editors may not make edits to internal project discussions related to the topic area, even within the "Talk:" namespace. Internal project discussions include, but are not limited to, Articles for deletion nominations, WikiProjects, requests for comment, requested moves, and noticeboard discussions.
Of those discussions:
- WikiProjects, RfCs, and noticeboards aren't visible to readers, so non-extended-confirmed editors are less likely to encounter them.
- AfDs are on their own page, so they can simply be given extended-confirmed protection.
- RMs are the exception – they're advertised on the relevant articles, and they're held on article talk pages. These talk pages are only protected sparingly (in response to significant disruption), since there are legitimate reasons for non-extended-confirmed editors to be editing them.
Currently, the only way for non-extended confirmed editors to know that they're not permitted to participate in these RMs is to:
- Spontaneously scroll to the top of the talk page.
- Read the entire GS notice, and understand that requested moves are an exception to the exception to the extended-confirmed restriction.
- Click on the "extended-confirmed editors" link, learn what the term means, and understand that they are not extended-confirmed.
I think this is a highly implausible sequence. If we want non-extended-confirmed editors to stop participating in these move requests, we should put a template in the RM section that instructs non-extended-confirmed editors, in plain language, not to participate in them. The {{if extended confirmed}} template could be used to directly let editors know whether they are extended-confirmed (and possibly tailor other parts of the message as well). jlwoodwa (talk) 17:43, 27 November 2024 (UTC)
- I mean sure, but WP:Nobody reads the directions. So it might reduce the numbers a little, but the unfortunate truth is that much of the time we are just going to end up explaining this on user talk pages to unhappy people. 184.152.68.190 (talk) 20:11, 28 November 2024 (UTC)
- Then I wonder if we should only be displaying the {{requested move notice}} to extended-confirmed editors, on those articles where the ECR forbids non-extended-confirmed editors from participating in RMs. On the other hand, extended-confirmed editors might be reading Wikipedia while logged out, who would log in and participate if they see the notice. jlwoodwa (talk) 20:17, 28 November 2024 (UTC)
- Not a bad idea, and yes I could still see where some would object because an EC editor might encounter an article while logged out, seems enough of an edge case to where hiding might be worth it anyway. The other concern is that even people who only ever read should be alerted that something might happen to the page that has come up in discussions about the utility of AfD notices for example, but in considering the tradeoffs hiding from non-EC may well be the least bad option here, though it's certainly no panacea. 184.152.68.190 (talk) 20:59, 28 November 2024 (UTC)
- Since move discussions normally result in working redirects, I don't think that there's a need for non-editors to be warned that the page's title might be spelled differently in a week or two. The argument with AFD is that the article might cease to exist, so the non-editor might want to save an offline copy in case it disappears altogether. WhatamIdoing (talk) 07:54, 30 November 2024 (UTC)
- That's a good point, and further strengthens the case for hiding, can be combined with the originally proposed notice in hopes of reducing numbers a little further still. For the remainder maybe some type of user talk page notice that explains what happened and why as gently as can be managed while still stressing the seriousness of GS restrictions. 184.152.68.190 (talk) 02:16, 1 December 2024 (UTC)
- Since move discussions normally result in working redirects, I don't think that there's a need for non-editors to be warned that the page's title might be spelled differently in a week or two. The argument with AFD is that the article might cease to exist, so the non-editor might want to save an offline copy in case it disappears altogether. WhatamIdoing (talk) 07:54, 30 November 2024 (UTC)
- Not a bad idea, and yes I could still see where some would object because an EC editor might encounter an article while logged out, seems enough of an edge case to where hiding might be worth it anyway. The other concern is that even people who only ever read should be alerted that something might happen to the page that has come up in discussions about the utility of AfD notices for example, but in considering the tradeoffs hiding from non-EC may well be the least bad option here, though it's certainly no panacea. 184.152.68.190 (talk) 20:59, 28 November 2024 (UTC)
- Then I wonder if we should only be displaying the {{requested move notice}} to extended-confirmed editors, on those articles where the ECR forbids non-extended-confirmed editors from participating in RMs. On the other hand, extended-confirmed editors might be reading Wikipedia while logged out, who would log in and participate if they see the notice. jlwoodwa (talk) 20:17, 28 November 2024 (UTC)
New main page section: Wikipedia tips
I think a page informing the readers of Wikipedia features would be helpful, since the public largely do not know much about Wikipedia's backend even though billions visit this site. Topics featured can be looking a page history, talk page discussions, WP:Who Wrote That?, etc. I imagine it woule be placed under the Today's featured picture, since we want to showcase quality work first. I've made a demo here: User:Ca/sadbox. Ca talk to me! 13:11, 29 November 2024 (UTC)
- Looks good. And it's fine if we recycle them fairly rapidly, since these are things can be easily reused – in fact, I suggest cycling this weekly instead of daily. Cremastra ‹ u — c › 15:56, 29 November 2024 (UTC)
- Perhaps we could do something like {{Wikipedia ads}} and simply post a new random tip upon a purge. Ca talk to me! 16:07, 29 November 2024 (UTC)
- The Main Page is deliberately aimed at readers, not editors. Its purpose is to direct readers to interesting encyclopaedic content, not show them how to edit pages. The Main Page is also very full already, so adding anything would require removing something else. I think it's highly unlikely that this idea would achieve consensus at T:MP. However I'm sure there's a place for something like this in Wikipedia: space. Modest Genius talk 12:42, 3 December 2024 (UTC)
- To be fair, the whole point of Wikipedia is that readers are potential editors. Helping readers take that step would definitely help us keep a steady, or even growing, user base. Chaotic Enby (talk · contribs) 12:52, 3 December 2024 (UTC)
- I am not sure what you mean by
The Main Page is also very full
. There isn't a size limit to Internet pages? In any case, I want the content of the tips to be reader-focused, not editor-focused. Things like creating an account to change website display, identifying who-wrote-what, etc. Ca talk to me! 13:14, 3 December 2024 (UTC)
- There has been a Tip of the Day project since 2004. You can use the {{totd}} template to display the day's tip, as follows. Perhaps there should be a link to this in the Other areas of Wikipedia section of the main page? Or it might go in the top banner, where the portals used to be, as that looks quite empty now. Andrew🐉(talk) 17:34, 3 December 2024 (UTC)
- This is perfect! It seems like people already done the work for me. However, there is some need to retheme the banner so that it fits in with the rest of the main page. Ca talk to me! 23:49, 4 December 2024 (UTC)
- I think the OP's plan is a terrific idea. The vast majority of readers never even think about actually editing a page (despite the ubiquitous edit links). Having a big, NOTICEABLE "tip of the day" seems a great way of changing this.
- An example of a good place for this would be just above "In the News", to the right of "Welcome to Wikipedia", about two inches wide and one inch high. Obviously just one possibility out of many.
- But just having another small link to some variation of Help:How to edit seems futile and unnecessary.
- I would strongly recommend having a two-week trial of the OP's suggestion, and then check the metrics to see whether to continue or not. ——— ypn^2 21:33, 4 December 2024 (UTC)
- Considering that I think most other of the WMF projects have something on their main page about contributing, there is a distinct lack of it on en.wiki. This could be a page spanning box with the usual links of how to get started along with the top of the day floating right in that box. Whether that box leads or ends the page is of debate but it would make sense to have something for that. Masem (t) 00:03, 5 December 2024 (UTC)
- Concur. I'm averse to directly using the WP Tip of the Day (as suggested above), since that's directly to people who are *already* editors, albeit novice ones. What we really want is for people to hit the "edit" button for the first time. I suggest cycling through a few messages, along the lines of:
- See a typo in one of our articles? Fix it! Learn how to edit Wikipedia.
- This is your encyclopedia, too. Learn how to edit Wikipedia.
- Want to lend a hand? Join an international volunteer effort, whether for a day or for a decade – learn how to edit Wikipedia.
- Obviously these will need some finetuning, since I'd really rather not have something as cringy as "for a day or for a decade" on the Main Page, but I think the idea is there. These one-liners should be prominently displayed at the top. Cremastra ‹ u — c › 00:13, 5 December 2024 (UTC)
- I agree that the messaging needs to be toward not-yet-editors, but perhaps they can be more specific? e.g.:
- Did you know that you can italicize words by surrounding them with two appostrophe's? For example,
The ''Titanic'' hit an iceberg and sank in 1912.
appears asThe Titanic hit an iceberg and sank in 1912.
- See something that needs a source? Just add
{{citation needed}}
after the questionable sentence, or better yet, add a source yourself using<ref>www.website.com/page</ref>
! - ypn^2 00:24, 5 December 2024 (UTC)
- Not sure we want to be showing people how to make bare URL references. Cremastra ‹ u — c › 00:28, 5 December 2024 (UTC)
- Rather see editors include material sourced to a bare url than to add without any source or even just give up with trying to add something because the ref system is hard to learn. We have bots that can do basic url to ref formats so that is less a concern. Masem (t) 00:30, 5 December 2024 (UTC)
- Not sure we want to be showing people how to make bare URL references. Cremastra ‹ u — c › 00:28, 5 December 2024 (UTC)
Potentially moving the deletion venue for MediaWiki: pages
The nature of MediaWiki: pages is always such that there will almost never be deletions. And when there are, it is because some message is no longer used. Because of the very technical nature of MediaWiki: pages, I don't think WP:MFD is a suitable venue, since not all users at WP:MFD will have the technical expertise to determine something like whether a MediaWiki message is used or not, etc.
We have WP:TFD primarily for templates and modules. I want to see maybe we can workshop a proposal for determining if, when, and how MediaWiki pages are deleted. I do wonder if maybe due to the nature of MediaWiki: namespace that maybe it should be exempt from most of the speedy criteria and only deleted after a discussion at WP:VPT, where editors can discuss the MediaWiki software, etc.
See Special:PrefixIndex/Wikipedia:Miscellany_for_deletion/MediaWiki: which shows very few MFD discussions. Awesome Aasim 03:45, 30 November 2024 (UTC)
- No matter where the discussions are hosted, it will still be true that "not all users...will have the technical expertise to determine something", or anything, about the page. This is a case where the hosting location is much less important than the efforts to advertise the discussion in suitable places. Fortunately, since there are very few discussions about deleting those pages – 49 since MFD's creation, and only one this entire calendar year that wasn't started by you – it won't require be a significant burden to make sure that those few get advertised. WhatamIdoing (talk) 08:00, 30 November 2024 (UTC)
- Hmmm... That is also true. The closest thing I can think about for technical discussion of pages, etc. would be WP:TFD. We could probably rename that process "Technical pages for discussion" and then it would include MediaWiki: pages as well (as well as maybe user scripts). WP:VPT and WP:TFD seem to have the highest number of technical editors discussing functionality, etc., so maybe we should lean there. Awesome Aasim 16:49, 30 November 2024 (UTC)
- I actually started workshopping what a "Technical pages for discussion" process might look like. Awesome Aasim 18:57, 30 November 2024 (UTC)
- Hmmm... That is also true. The closest thing I can think about for technical discussion of pages, etc. would be WP:TFD. We could probably rename that process "Technical pages for discussion" and then it would include MediaWiki: pages as well (as well as maybe user scripts). WP:VPT and WP:TFD seem to have the highest number of technical editors discussing functionality, etc., so maybe we should lean there. Awesome Aasim 16:49, 30 November 2024 (UTC)
- See also the two proposals Awesome Aasim has made regarding speedy deletion of MediaWiki pages: November 2024, March 2024 and an earlier one by a different editor Wikipedia talk:Criteria for speedy deletion/Archive 78#Add criteria for MediaWiki namespaces.
- Wikipedia:Miscellany for deletion/MediaWiki:Abusefilter-disallowed/de, initiated by Awesome Aasim in February 2021, came to the consensus that an RFC should be held to determine whether the community desired the deletion of those pages. A discussion was held at Wikipedia:Village pump (proposals)/Archive 183#Foreign-language interface messages. There was a unanimous consensus to keep either most or all. Thryduulf (talk) 13:33, 30 November 2024 (UTC)
Disambiguation pages should auto-generate
Hello all,
Per MOS:BOLD, the first appearance of an article's titular subject should be bolded, as should any alternate names for the article. When I first started editing Wikipedia, I was surprised that those were just manual boldfaces with HTML tags. I was wondering whether it would be better to apply it with something like this: " {{article main name|Apples}}, also known as {{article alternate title|Oranges|oranges}}, are a fruit. " which would display as "Apples, also known as oranges". The two templates would auto-populate the title and short description into a disambiguation page if there were multiple instances of the same name. Further, a hatnote would be auto-created (if there were multiple instances of similarly-named pages, the hatnote would lead to the disambiguation page, and if there was only one, it would lead to the other article).
I think that this would vastly improve the simplicity of maintainging disambiguation pages and hatnotes. However, it could increase barriers to entry for new users, but that could be mitigated with editnotices, template documentation, etc. It may also be difficult to implement, but I foresee bots being able to implement the work.
JuxtaposedJacob (talk) | :) | he/him | 21:00, 30 November 2024 (UTC)
- "Apples, also known as oranges"? I'm not sure I understand your use case for making such pages so inaccessible and code-ridden for newcomers. Aaron Liu (talk) 04:09, 1 December 2024 (UTC)
- @Aaron Liu - Yeah, I see what you're saying, but I think most of the learning curve could be eliminated if, when someone tries to edit a disambiguation page, an editnotice of some sort appears and recommends that they go edit the source page.
- JuxtaposedJacob (talk) | :) | he/him | 07:51, 1 December 2024 (UTC)
- On the technical side, disambiguation pages already have edit notices, so that part would be feasible.On the more practical side, disambiguation pages are often more complex than just listing articles with the same title. For instance, a concept might be listed in a disambiguation page even if it doesn't have an article, but is prominently mentioned at an existing page (the kind of thing that would warrant a {{R to section}} or {{R to related topic}}). Spelling variants (especially for languages written in the Arabic script where romanizations can often vary) are also grouped together in a similar page, while more subtle issues come up with partial title matches. I can also foresee the issue of organizing the disambiguation page itself, especially with things like proper names that are often (but not always) moved to a separate page. Chaotic Enby (talk · contribs) 09:41, 2 December 2024 (UTC)
- @Chaotic Enby - Ahh, good points, thanks.
- JuxtaposedJacob (talk) | :) | he/him | 10:19, 2 December 2024 (UTC)
- On the technical side, disambiguation pages already have edit notices, so that part would be feasible.On the more practical side, disambiguation pages are often more complex than just listing articles with the same title. For instance, a concept might be listed in a disambiguation page even if it doesn't have an article, but is prominently mentioned at an existing page (the kind of thing that would warrant a {{R to section}} or {{R to related topic}}). Spelling variants (especially for languages written in the Arabic script where romanizations can often vary) are also grouped together in a similar page, while more subtle issues come up with partial title matches. I can also foresee the issue of organizing the disambiguation page itself, especially with things like proper names that are often (but not always) moved to a separate page. Chaotic Enby (talk · contribs) 09:41, 2 December 2024 (UTC)
- @JuxtaposedJacob, for the list of entries on a dab page, would Template:Annotated link be a step in the direction of what you want?
- Apple – Fruit that grows on a tree
- Apple Inc. – American multinational technology company
- Apple pie – Dessert pie made with apples
- WhatamIdoing (talk) 00:59, 4 December 2024 (UTC)
- Sometimes I wish consensus was on my side more, sigh. "This template should not be used for annotating links on disambiguation pages." However, thank you for pointing me to that link, that is helpful.
- JuxtaposedJacob (talk) | :) | he/him | 01:26, 4 December 2024 (UTC)
- Well, that was 2018. WP:Consensus can change. Maybe it's time that it did. WhatamIdoing (talk) 04:46, 4 December 2024 (UTC)
- Looking at the three reasons given for not using them, while the first one (style issue) can be easily fixed with a new template parameter, the other two are still very much problematic. Short descriptions are not necessarily written with disambiguation pages in mind (or even consistent from one disambiguated term to the next), and different use cases of short descriptions might conflict with each other's needs. And, well, transcluding data on disambiguation pages from other pages (which is actually close to the current proposal) still brings the issue of traceability of the edits. Chaotic Enby (talk · contribs) 08:21, 4 December 2024 (UTC)
- Well, that was 2018. WP:Consensus can change. Maybe it's time that it did. WhatamIdoing (talk) 04:46, 4 December 2024 (UTC)
Adding a timeline of level 3 vital people
I suggested this on the other page, but there was no reply, perhaps their chats are inactive. You can find the draft I made of the timeline here: User:Wikieditor662/Vital sandbox.
Note: I believe that the names for the time periods are not perfect (biased towards west) and there are other areas to improve before publishing but I think it's best to see whether it should be included before going further.
What do you guys think? Is this something worth adding? Wikieditor662 (talk) 04:56, 4 December 2024 (UTC)
- @Wikieditor662 Definitely looks cool and is well-designed. Perhaps you can clarify what exactly we're trying to accomplish with this (e.g., where would you like to have this displayed)? Is the purpose to identify potential changes to the Vital list, or to find vital articles to improve, or just to graphically illustrate the "more exciting" and "less exciting" periods of human history? Or something else? ——— ypn^2 21:22, 4 December 2024 (UTC)
- @Ypn^2 I'm very glad you like the design! It's meant to give a visual representation of the people on there, and to show when these people existed and how they could have interacted with each other. Now that you bring it up, this could also be a useful way for editors to see where there can be some improvements.
- As for the location, the timeline could be its own page, and perhaps we could copy and paste a part of it (such as the overview) under the "people" section of vitality articles level 3.
- Also, if this turns out to be a good idea, we could also create more specific timelines like this to help visualize other areas, for example level 4 / 5 philosophers, and perhaps put a part of that timeline under the History of philosophy page.
- Thanks again and feel free to let me know what you think! Wikieditor662 (talk) 22:32, 4 December 2024 (UTC)
- When it is so broad, I wonder whether the inclusion criteria would be considered original research. JuxtaposedJacob (talk) | :) | he/him | 01:21, 5 December 2024 (UTC)
- I understand this concern, and I think it's important to keep in mind that the vital articles' levels are structured to help define the priority levels for articles. Changes for who's included onto here require deep discussions and reliable reasons as to why they should be included or excluded. Wikieditor662 (talk) 03:43, 5 December 2024 (UTC)
- @Wikieditor662: One tiny point of criticism on the design front: in the overview and ancient history sections, the blue names on dark brown are really hard to read due to very low contrast. AddWittyNameHere 04:23, 5 December 2024 (UTC)
- Thanks, I've tried for a while and couldn't figure out how to change the blue text to a different color. If you know how, please let me know. I did, however, make the border of the text more black, so it should be a little easier to see now, although it may not be perfect. Wikieditor662 (talk) 06:02, 5 December 2024 (UTC)
- @Wikieditor662: One tiny point of criticism on the design front: in the overview and ancient history sections, the blue names on dark brown are really hard to read due to very low contrast. AddWittyNameHere 04:23, 5 December 2024 (UTC)
- I understand this concern, and I think it's important to keep in mind that the vital articles' levels are structured to help define the priority levels for articles. Changes for who's included onto here require deep discussions and reliable reasons as to why they should be included or excluded. Wikieditor662 (talk) 03:43, 5 December 2024 (UTC)
- When it is so broad, I wonder whether the inclusion criteria would be considered original research. JuxtaposedJacob (talk) | :) | he/him | 01:21, 5 December 2024 (UTC)
Photo gathering drive for town, village, and city halls
Like how Wikipedia and Wikimedia Commons has the National Register of Historic Places drives for pictures. There should be effort put into getting the town halls, village halls, and city halls pictures. Every town, every village, every borough, every city, and county has a Wikipedia page and I think they should all have a picture posted of the administrative building. Wikideas1 (talk) 08:21, 4 December 2024 (UTC)
- One consideration is that shorter articles have limited space for images, and a photo of the building housing administrative offices of a politically defined place may not be the best representation of that place. It is fine to upload such pictures to Commons, but their use may not be justified in every article about a place. Donald Albury 15:44, 4 December 2024 (UTC)
Essay on Funding sections
There is a systemic problem: sections on "Funding" for non-profit organizations. They are often disinformation. For example, if an organization is partly funded by the USAID, the organization will be framed as proxy of the US Federal Government. Of, if an organization is funded by the Koch Brothers, it will be framed in a suitably FUD way. This framing is often done through emphasis on certain donors, word choices and so on. Sometimes it's explicit other times subtle. I can show many examples, but prefer not to make it into a single case. The problem is systemic, since the beginning of Wikipedia.
What we need is an essay about Funding sections. Best practices, things to avoid. A link to WP:FUNDING. And some effort to go through these articles and apply the best practices described. -- GreenC 18:31, 4 December 2024 (UTC)
WMF
Wikimedia Foundation Bulletin November Issue 1
Upcoming and current events and conversations
Talking: 2024 continues
- Commons Community Call: The first community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year will take place on November 21. The theme of this call will be about how content should be organised on Wikimedia Commons. The call will be hosted by Chief Product and Technology Officer Selena Deckelmann.
- Conferencia Justicia climática Perú 2024: Conference on climate justice, indigenous voices and Wikimedia platform will be held in Huaraz, Peru from November 8 to 10.
- Affiliations Committee: Applications for joining the Affiliations Committee is open until November 18.
- Ombuds Commission and Case Review Committee: Applications for joining the Ombuds commission and the Case Review Committee are open until December 2.
- Language community meeting: A language community meeting will be hosted on November 29, 16:00 UTC, discussing technical updates and problem-solving.
Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org
- Advisory Council: The new Product and Technology Advisory Council (PTAC) was announced. The PTAC will try to publish a set of community-validated recommendations that can serve as a potential 2-3 year blueprint for product and technical success.
- Wikifunctions: The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. More status updates.
- Tech News: The Guided Tour extension, which help newcomers understand how to edit, now works with dark mode; Wikipedia readers can now download a browser extension to experiment with potential features that making it easier for readers to discover information on the wikis. More tech updates from tech news 44 and 43.
- Temporary accounts: Logged-out editors on 12 wikis, including Norwegian, Romanian, Serbian, Danish, and Cantonese Wikipedia, receive temporary accounts now. This new account type enhances the privacy of logged-out editors and makes it easier for community members to communicate with them. Read the new Diff post to learn more about temporary accounts.
- Mobile apps: The Mobile Apps team has released an update to the iOS app’s navigation, now available in the latest App store version.
- Campaign Events Extension: The Campaign Events extension is now live on two more wikis, Wikidata and the Spanish Wikipedia.
- Admin Retention: A survey on Wikipedia Administrator Recruitment, Retention, and Attrition is open until November 11. As part of the Foundation's 2024-2025 Annual Plan, the research team and collaborators are studying recruitment, retention, and attrition patterns among long-tenured community members in official moderation and administration roles.
- Knowledge is Human: The campaign web page, which educates visitors on Wikipedia’s model and why it’s trustworthy, has earned over 140,000 clicks. The campaign has increased pageviews on WikimediaFoundation.org by more than 50%.
Annual Goals Progress on Equity
See also a list of all movement events: on Meta-Wiki
- WikiCelebrate: From making a minor maintenance edit in 2005 to being one of the most appreciated Wikimedians in the Central Eastern European (CEE) region: this month we celebrate Mārtiņš Bruņenieks.
- Wiki Loves Earth: Mountains, Birds and Lakes – Central Asia Edition
- Future of Language Incubation: As part of a new Future of Language Incubation initiative to support language onboarding, Wikipedia is now live for five languages: Pannonian Rusyn, Tai Nüa, Iban, Obolo, and Southern Ndebele.
Annual Goals Progress on Safety & Integrity
See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog
- Global Advocacy: Reflecting on the anniversary of the EU’s Digital Service Act (DSA), Wikimedians share successes and public policy priorities at digital rights Global Gathering event, and more global advocacy updates.
Annual Goals Progress on Effectiveness
See also: quarterly Metrics Reports
- English Fundraising: The Road to Launch: Wikimedia’s 2024 English Fundraising Campaign.
- Fundraising Report: Our annual fundraising report for the 2023-2024 fiscal year is published. Last year, we had over 8 million donors giving an average donation of m:Fundraising/2023-24 Report0.58. We ran campaigns in 33 countries, 18 languages, and received donations from over 200 countries.
Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · other newsletters:
- Topics: Education · GLAM · The Wikipedia Library
- Wikimedia Projects: Milestones · Wikidata
- Regions: Central and Eastern Europe
Subscribe or unsubscribe · Help translate
Previous editions of this bulletin are on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
MediaWiki message delivery 22:33, 7 November 2024 (UTC)
- Interesting note buried in this about how IP addresses are going to be handled in future, thanks for the update on that timely issue. Espresso Addict (talk) 09:26, 8 November 2024 (UTC)
We would prefer not to deploy on English Wikipedia at that time, though.
A knee jerk reaction would be requesting otherwise and have enwiki be onboard as early as possible. – robertsky (talk) 08:48, 9 November 2024 (UTC)- It makes sense to fine-tune implementation on smaller wikis before rolling out to larger ones, but I am a lot more comfortable about this implementation than I was with earlier reports, which merely talked of hiding IP addresses, with all the worries over how we then handle IP vandalism, and did not provide any benefits to the (logged-in) community of editors. Espresso Addict (talk) 08:57, 9 November 2024 (UTC)
- Currently, extended-confirmed editors -200 edits will have access to the ip information. It is a large pool of users (>70k here) who can look that data. – robertsky (talk) 09:12, 9 November 2024 (UTC)
- Indeed, I was very pleased that the ability to look at IPs had been extended to patrollers. Is there somewhere better that we can highlight this useful update, which allayed many of my concerns as an administrator about the upcoming change, as I fear the WMF page is not much read? Espresso Addict (talk) 09:33, 9 November 2024 (UTC)
- I see the option in the Preferences page. It wasn't there before. Enabling now. :D – robertsky (talk) 11:59, 9 November 2024 (UTC)
- How will this change the WP:OUTING policy? For example can I include the IP address or cidr range of a temporary account in the suspected sock list? Would that be considered outing? Because anyone(logged out editors too) can see a SPI report.Ratnahastin (talk) 09:38, 9 November 2024 (UTC)
- Most likely not, as you're required to agree to certain terms when opting in to view IPs (as you already are on this wiki when enabling IP info). It would be a violation of not only local policy but ToS. Nardog (talk) 11:51, 9 November 2024 (UTC)
- I think there should not be a need to include the IP address or the CIDR range in SPI report. Just the list of temporary accounts will do. Any CU, clerks, or patrolling admins will to have updated their checking processes to account for temporary accounts. – robertsky (talk) 12:02, 9 November 2024 (UTC)
- Has anyone seen an indication of how many buttons you have to click to see IP info? In the past, people might post half-a dozen IPs at ANI and someone else would point out that that was a /64 that should be blocked with no collateral damage. At least one template ({{blockcalc}}) can extract IPs from wikitext and show the ranges involved. We will have to see how much hassle will be involved with the new system. Johnuniq (talk) 02:02, 10 November 2024 (UTC)
- You can ask for the permissions and try it on testwiki: or, if you have enough edits, on any other wiki where it's been rolled out. Nardog (talk) 06:23, 10 November 2024 (UTC)
- @Johnuniq: I have the global version of edit filter helper, so I have access on the wikis where it's just been rolled out (plus testwiki). If I recall correctly, it's just one button agreeing to the IP information policy to reveal IPs, but there are more boxes in Special:Preferences that allow for things like revealing IPs in the edit filter and using IP information on contribution pages. There's also a global preference available to CU/OS and certain global groups (global rollback/sysop, and global abuse filter helper/maintainer) to enable IP information cross-wiki. EggRoll97 (talk) 23:32, 10 November 2024 (UTC)
- Temporary accounts can be changed if one clears cookies or uses a different browser, not the same case with a cidr IP range. This will certainly make it a bit of a hassle to list out every temporary account associated with the IP range, anyway let's see how this feature is implemented first. Ratnahastin (talk) 02:06, 10 November 2024 (UTC)
- Has anyone seen an indication of how many buttons you have to click to see IP info? In the past, people might post half-a dozen IPs at ANI and someone else would point out that that was a /64 that should be blocked with no collateral damage. At least one template ({{blockcalc}}) can extract IPs from wikitext and show the ranges involved. We will have to see how much hassle will be involved with the new system. Johnuniq (talk) 02:02, 10 November 2024 (UTC)
- Indeed, I was very pleased that the ability to look at IPs had been extended to patrollers. Is there somewhere better that we can highlight this useful update, which allayed many of my concerns as an administrator about the upcoming change, as I fear the WMF page is not much read? Espresso Addict (talk) 09:33, 9 November 2024 (UTC)
- Currently, extended-confirmed editors -200 edits will have access to the ip information. It is a large pool of users (>70k here) who can look that data. – robertsky (talk) 09:12, 9 November 2024 (UTC)
- It makes sense to fine-tune implementation on smaller wikis before rolling out to larger ones, but I am a lot more comfortable about this implementation than I was with earlier reports, which merely talked of hiding IP addresses, with all the worries over how we then handle IP vandalism, and did not provide any benefits to the (logged-in) community of editors. Espresso Addict (talk) 08:57, 9 November 2024 (UTC)
- Will there be an option to decline the unnecessary tracking cookies? 216.147.123.189 (talk) 19:36, 21 November 2024 (UTC)
Open letter about Asian News International vs. Wikimedia Foundation
If you (the WMF) are not already aware of it there is an open letter here with over 600 signatures. Phil Bridger (talk) 18:46, 10 November 2024 (UTC)
Will you be moving operations overseas?
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Trump has a tendency to cause disruptions in a number of different ways. He seriously interfered with a government directed radio station of some sort when he was in office last time (https://www.npr.org/2020/06/18/879873926/trumps-new-foreign-broadcasting-ceo-fires-news-chiefs-raising-fears-of-meddling). Will it be necessary for you to move Wikipedia operations overseas or is it already handled in some other way? I'm sorry to voice my concern this directly, but: I'd rather this didn't turn into conservapedia mkII and have Trump attempt to re-write history. 75.142.254.3 (talk) 19:15, 10 November 2024 (UTC)
- The Wikimedia community is editorially independent of the foundation and has remained so during Trump's first presidency, so I see no reason to be worried. * Pppery * it has begun... 19:22, 10 November 2024 (UTC)
- Do you mean the users or a part of the body of wikipedia itself? As in, could Trump take over the website or otherwise exert significant pressure that would otherwise be alleviated by relocation? If not, then I guess no action necessary.
- 75.142.254.3 (talk) 19:35, 10 November 2024 (UTC)
- The only thing he could do is hire a troll farm of some sort, which I don't expect us to have much trouble defending against. Aaron Liu (talk) 19:58, 10 November 2024 (UTC)
- Are the servers located in the United States? It's looking like the answer is no, and I'm sorry for being paranoid, it's just that he has done things in this country that we didn't anticipate because we didn't expect anyone to have the sort of character that it would be a problem in that position. 75.142.254.3 (talk) 20:01, 10 November 2024 (UTC)
- The primary Wikimedia data centers are located in the U.S., with caching centers distributed around the globe. I think you'd be hard pressed to find a country with better legal protections for online free speech, but as you note, it shouldn't be taken for granted. Legoktm (talk) 20:13, 10 November 2024 (UTC)
- Yeah, the 1st amendment provides stronger protections than almost all countries have; even if Trump tried he'd be hard pressed to find a court that would agree with Wikipedia censorship (unlike in India...). Galobtter (talk) 04:34, 11 November 2024 (UTC)
- You are correct about the strength of free speech protections in the US being more robust than just about anywhere else in the world, from a perspective of well-enshrined constitutional protections and the historical jurisprudence and respect from institutions. That said, if there were to be a concerted push by the incoming president and his allies to suppress certain information streams and target free speech that aligns against him, it would not be the first time that he sent shockwaves through the legal world by finding success in overturning long-established doctrines that were until recently thought iron-clad and inviolable, by appearing before a federal judiciary that is now showing the influence of decades of concerted efforts by the GOP and the Federalist Society to pack those courts to the gills with ideologically-aligned and personally loyal jurists. In short, nothing is certain in the current political and institutional landscape. I just don't think a whole-sale move of the organization and its technical infrastructure is either feasible or likely to substantially obviate the risks. The only answer is to take up the fight when and where it occurs. SnowRise let's rap 20:19, 17 November 2024 (UTC)
- I'd just like to add that the Federalist Society is not opposed to the First Amendment, and indeed has been staunchly supportive of what it is and what it means in terms of campaign finance. Unlike with Roe v Wade, where there was in fact a decades long campaign to overturn it, there's no similar movement to overturn key First Amendment precedents. Having said that, I do worry about Section 230's protections for user generated content, which is very important. Jimbo Wales (talk) 11:52, 22 November 2024 (UTC)
- Well said Jimbo Wales, and yes, 230 is a concern. I'd request and suggest that you arrange a meeting with Donald Trump and Elon Musk at Mar-a-Lago to discuss how it would affect Wikipedia and other online projects. They both seem open to such meetings, and my guess is that it would be beneficial for the project in several ways. Randy Kryn (talk) 12:18, 22 November 2024 (UTC)
They both seem open to such meetings
. They do? Are you sure it's that easy to get a meeting with the president-elect and the richest man in the world? –Novem Linguae (talk) 12:23, 22 November 2024 (UTC)- For Jimbo, pretty sure. Trump takes many meetings, both formal and informal, and I would hope that Musk would be interested in sitting in on their conversation(s). Many things happen in Trump's meetings, and I would assume that a Wales-Trump-Musk sit-down would veer into some interesting directions. Randy Kryn (talk) 13:08, 22 November 2024 (UTC)
- I would not afford either of those an ounce of credibility in any statement they make. Both have shown a willingness to say one thing and do another to an extreme extent, and risking something like this to the whims of people like that is not something I'd personally advise. Though, Trump doesn't appear to be looking too good these days: https://www.youtube.com/watch?app=desktop&v=ir3ULEvRqBU
- I'm speaking somewhat plainly, but trying to be appropriate. As for Musk, when he sent his submarine to go rescue some people from a cave somewhere... his response to some of the events was... notable (not for Wikipedia standards maybe though).
- For Trump, there's too many examples (saying that he doesn't know anything about project 2025, and soo many others).
- A discussion with him and Musk could be attempted, but whether it would deliver anything, and whether to believe him? I couldn't say. 75.142.254.3 (talk) 04:04, 23 November 2024 (UTC)
- For Jimbo, pretty sure. Trump takes many meetings, both formal and informal, and I would hope that Musk would be interested in sitting in on their conversation(s). Many things happen in Trump's meetings, and I would assume that a Wales-Trump-Musk sit-down would veer into some interesting directions. Randy Kryn (talk) 13:08, 22 November 2024 (UTC)
- Well said Jimbo Wales, and yes, 230 is a concern. I'd request and suggest that you arrange a meeting with Donald Trump and Elon Musk at Mar-a-Lago to discuss how it would affect Wikipedia and other online projects. They both seem open to such meetings, and my guess is that it would be beneficial for the project in several ways. Randy Kryn (talk) 12:18, 22 November 2024 (UTC)
- I'd just like to add that the Federalist Society is not opposed to the First Amendment, and indeed has been staunchly supportive of what it is and what it means in terms of campaign finance. Unlike with Roe v Wade, where there was in fact a decades long campaign to overturn it, there's no similar movement to overturn key First Amendment precedents. Having said that, I do worry about Section 230's protections for user generated content, which is very important. Jimbo Wales (talk) 11:52, 22 November 2024 (UTC)
- You are correct about the strength of free speech protections in the US being more robust than just about anywhere else in the world, from a perspective of well-enshrined constitutional protections and the historical jurisprudence and respect from institutions. That said, if there were to be a concerted push by the incoming president and his allies to suppress certain information streams and target free speech that aligns against him, it would not be the first time that he sent shockwaves through the legal world by finding success in overturning long-established doctrines that were until recently thought iron-clad and inviolable, by appearing before a federal judiciary that is now showing the influence of decades of concerted efforts by the GOP and the Federalist Society to pack those courts to the gills with ideologically-aligned and personally loyal jurists. In short, nothing is certain in the current political and institutional landscape. I just don't think a whole-sale move of the organization and its technical infrastructure is either feasible or likely to substantially obviate the risks. The only answer is to take up the fight when and where it occurs. SnowRise let's rap 20:19, 17 November 2024 (UTC)
- Yeah, the 1st amendment provides stronger protections than almost all countries have; even if Trump tried he'd be hard pressed to find a court that would agree with Wikipedia censorship (unlike in India...). Galobtter (talk) 04:34, 11 November 2024 (UTC)
- The Wikimedia Foundation, which hosts Wikipedia, is based in the United States, and has to comply with US laws. Unless a relevant law is passed or legal action is taken, there isn't much Trump can do. ARandomName123 (talk)Ping me! 20:17, 10 November 2024 (UTC)
- If Trump goes authoritarian, which at this point I'm not going to rule out, US Law could be changed on a whim. But, I'm going to try to not be paranoid as much on this and WMF may already have evaluated appropriate courses of action given how they've managed to handle a wide variety of different kinds of disruption already. 75.142.254.3 (talk) 20:20, 10 November 2024 (UTC)
- The bottom line is, we just don't know. I'm sure the WMF has contingencies in place for if US law ever becomes prejudicial to the project. Until he actually becomes president, we don't know what will happen. We just have to wait and see. TheLegendofGanon (talk) 20:22, 10 November 2024 (UTC)
- I might have agreed with you a month ago, but considering the current crisis over the ANI matter, I am not at all confident that the WMF does have a proper contingency plan for a concerted litigation campaign from a Trump presidential administration or aligned parties. And actually, in that case, I could forgive their not having one: in that case, it's hard to predict for once bedrock civil and constitutional principles flying out the window, or know the exact combination of legal angle of attack and political pressure which may lead to such outcomes. Unlike certain other recent scenarios where the manner in which things have played out was mostly predictable, there is a lot that could very much be up in the air. The Justice Department will certainly be headed by a political loyalist for the next four years, and SCOTUS and many of the other federal courts are incredibly friendly to right wing causes, but the MAGA movement as a whole has not tended to attract the sharpest of legal minds for advocates, and not withstanding the election results, there is a lot of cultural attachment remaining in the U.S. for robust free speech protections--which afterall, conservative politicians are typically as happy to invoke and benefit from as anyone. So it's very difficult to know how concerned to be or what angle to expect the erosion of expression rights to set in from, if it does occur. In this case, I would sympathize if the WMF felt as much ina holding pattern as the rest of us. SnowRise let's rap 20:34, 17 November 2024 (UTC)
- It s about moderations, https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. Thus it would mean invoking free speeech against the Free speech of a Trumper wanting to use it s Infowars.com episode as a trusted source. As a first step, moving operations wouldn t be needed, just the legal entity for thr new Federal regulations. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:33, 24 November 2024 (UTC)
- That argument only really applies to social media. We aren't a social media platform. Also, I definitely think you're overreacting. QuicoleJR (talk) 01:49, 24 November 2024 (UTC)
- Elon musk tweets higlight he sees wikipedia as a social media that should have it s said censorship legally fought. At that point, what matter isn t what things are but how they are perceived by the ruling party. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 03:24, 24 November 2024 (UTC)
- That argument only really applies to social media. We aren't a social media platform. Also, I definitely think you're overreacting. QuicoleJR (talk) 01:49, 24 November 2024 (UTC)
- It s about moderations, https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. Thus it would mean invoking free speeech against the Free speech of a Trumper wanting to use it s Infowars.com episode as a trusted source. As a first step, moving operations wouldn t be needed, just the legal entity for thr new Federal regulations. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:33, 24 November 2024 (UTC)
- We know what will happen. Everything is written and Elon is tweeting about it specifically about wikipedia. https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. It won t be possible tjrough Executive order, but things laws can be changed by Congress.
- We should not act like the Sigmund Freuds sister's who throught they could survive in 1939. I hope Wikimedia is seriously thinking about moving overseas several time if needed in order to gain some years rather than being turned into a Darwin Awards receipient. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:19, 24 November 2024 (UTC)
- I fear such containgencies would be to fight legally and then Abide after losing even if this results in wikipedia being turned into an other twitter. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:42, 24 November 2024 (UTC)
- I might have agreed with you a month ago, but considering the current crisis over the ANI matter, I am not at all confident that the WMF does have a proper contingency plan for a concerted litigation campaign from a Trump presidential administration or aligned parties. And actually, in that case, I could forgive their not having one: in that case, it's hard to predict for once bedrock civil and constitutional principles flying out the window, or know the exact combination of legal angle of attack and political pressure which may lead to such outcomes. Unlike certain other recent scenarios where the manner in which things have played out was mostly predictable, there is a lot that could very much be up in the air. The Justice Department will certainly be headed by a political loyalist for the next four years, and SCOTUS and many of the other federal courts are incredibly friendly to right wing causes, but the MAGA movement as a whole has not tended to attract the sharpest of legal minds for advocates, and not withstanding the election results, there is a lot of cultural attachment remaining in the U.S. for robust free speech protections--which afterall, conservative politicians are typically as happy to invoke and benefit from as anyone. So it's very difficult to know how concerned to be or what angle to expect the erosion of expression rights to set in from, if it does occur. In this case, I would sympathize if the WMF felt as much ina holding pattern as the rest of us. SnowRise let's rap 20:34, 17 November 2024 (UTC)
- The Constitution of the United States provides protections that would be very hard for Trump or any other president to circumvent, and the consent of 2/3 of both houses of Congress and 3/4 of the states is required to amend it, so I'm not too worried yet. QuicoleJR (talk) 15:24, 11 November 2024 (UTC)
- Not only that, but we already can handle dealing with edits from congress itself. Gaismagorm (talk) 14:15, 12 November 2024 (UTC)
- Disagree, it would be invoking Free speech against the Free speech rights of the Trumper https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/ though things can be done with Congress appeoval. Clearence Thomas and an other judge are apparently waiting for Trump to step down/retire 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:28, 24 November 2024 (UTC)
- The bottom line is, we just don't know. I'm sure the WMF has contingencies in place for if US law ever becomes prejudicial to the project. Until he actually becomes president, we don't know what will happen. We just have to wait and see. TheLegendofGanon (talk) 20:22, 10 November 2024 (UTC)
- Thanks to a recent bill, the President may now strip the WMF of its non-profit status as long as it supports "terrorism". Aaron Liu (talk) 19:36, 23 November 2024 (UTC)
- Not quite yet. The House passed HR 9495 yesterday, but for it to actually become law there are a few more steps that would need to happen. Anomie⚔ 00:09, 24 November 2024 (UTC)
- It probably won’t pass the Senate this session, and the democrats could also filibuster it when the GOP takes a very slim majority next time. And if it did pass, the main targets would be Palestinian rights groups, which the US already treats inexcusably because it shamelessly supports Israeli war crimes as part of the US-Israel-Iran proxy war. The long game that is international geopolitics makes both Wikipedia and the current office holder’s grievance politics look small. Dronebogus (talk) 10:42, 24 November 2024 (UTC)
- Not quite yet. The House passed HR 9495 yesterday, but for it to actually become law there are a few more steps that would need to happen. Anomie⚔ 00:09, 24 November 2024 (UTC)
- And changing laws is indeed the plan https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. The article tells about executive orders, but I think it would be easy to get Fcc power being enlarged by Congress. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:26, 24 November 2024 (UTC)
- If Trump goes authoritarian, which at this point I'm not going to rule out, US Law could be changed on a whim. But, I'm going to try to not be paranoid as much on this and WMF may already have evaluated appropriate courses of action given how they've managed to handle a wide variety of different kinds of disruption already. 75.142.254.3 (talk) 20:20, 10 November 2024 (UTC)
- The primary Wikimedia data centers are located in the U.S., with caching centers distributed around the globe. I think you'd be hard pressed to find a country with better legal protections for online free speech, but as you note, it shouldn't be taken for granted. Legoktm (talk) 20:13, 10 November 2024 (UTC)
- Strongly Disagree. He hired the guy that plan to enact laws allowing to crack down on mederation on Project. The Framework would give the power to the Fcc to prevent any kind of moderations by platforms as long as it s not death threats. Wikipedia Articles would be legally compelled to accept Breibart New or Infowars as a trusted source. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:05, 23 November 2024 (UTC)
- What? What laws? Aaron Liu (talk) 19:37, 23 November 2024 (UTC)
- Project2025 https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. Though as suggested by the article, this would require a vote from Congress 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:25, 24 November 2024 (UTC)
- Nah cause someones gonna use for extreme left leaning content eventually and they will go back. Also I'm sure that it will be such a big screwup in countless of other ways that they will be forced to go back. Gaismagorm (talk) 02:05, 24 November 2024 (UTC)
- Look at twitter. It s not exteme left who did won but far right. Indeed, we can notice the strange marriage between Healthy food and anti regulationists. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:08, 24 November 2024 (UTC)
- What? Gaismagorm (talk) 02:10, 24 November 2024 (UTC)
- Trumpers now promote less pesticides with Robert Kennedy jr. In my Euoroppean country, the far right still boast that non poisned food is for the richs who have enough to eat anything 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:19, 24 November 2024 (UTC)
- Ah Okay. Gaismagorm (talk) 02:20, 24 November 2024 (UTC)
- Anyway, that wash your wishes of wikipedia not going in the right directions as the result of Trump. Moving legally is a lengthy operation that should be srudied in order to be ready when things become required. We can have the WMF as hardware user in the United States were the data is legammy managed from an the new country the WMF have moved to. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:32, 24 November 2024 (UTC)
- Ah Okay. Gaismagorm (talk) 02:20, 24 November 2024 (UTC)
- Trumpers now promote less pesticides with Robert Kennedy jr. In my Euoroppean country, the far right still boast that non poisned food is for the richs who have enough to eat anything 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:19, 24 November 2024 (UTC)
- What? Gaismagorm (talk) 02:10, 24 November 2024 (UTC)
- Look at twitter. It s not exteme left who did won but far right. Indeed, we can notice the strange marriage between Healthy food and anti regulationists. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:08, 24 November 2024 (UTC)
- What? What laws? Aaron Liu (talk) 19:37, 23 November 2024 (UTC)
- Are the servers located in the United States? It's looking like the answer is no, and I'm sorry for being paranoid, it's just that he has done things in this country that we didn't anticipate because we didn't expect anyone to have the sort of character that it would be a problem in that position. 75.142.254.3 (talk) 20:01, 10 November 2024 (UTC)
- The only thing he could do is hire a troll farm of some sort, which I don't expect us to have much trouble defending against. Aaron Liu (talk) 19:58, 10 November 2024 (UTC)
- As a basic precaution there should be a Wikipedia mirror with daily backups hosted on a server geolocated in a country with a higher democracy index and a higher internet freedom index than the US. I'd suggest Iceland, personally.—S Marshall T/C 04:23, 13 November 2024 (UTC)
- Honestly, it's unneeded. Look, I get worrying about this situation but I doubt the situation will get so bad where wikipedia needs to move overseas. As stsated above, wikimedia also likely already has a plan for if this happens. Gaismagorm (talk) 11:40, 13 November 2024 (UTC)
- In any event, I do believe the backups at least are already quite robust in that respect. I'm less certain about the current situation for the mirrors, but I'm sure that information is probably transparently located somewhere on-site or on Meta. SnowRise let's rap 20:39, 17 November 2024 (UTC)
- Data dumps are publics. But passwod hashes are not. We can clone but admins would be unable to login. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:07, 23 November 2024 (UTC)
- In any event, I do believe the backups at least are already quite robust in that respect. I'm less certain about the current situation for the mirrors, but I'm sure that information is probably transparently located somewhere on-site or on Meta. SnowRise let's rap 20:39, 17 November 2024 (UTC)
- What’s so great about Iceland? I don’t like the idea of being subject to the whims of a country with the population of a small city that’s floated the idea of banning internet pornography at least once. The most obvious choice would be Switzerland. Dronebogus (talk) 01:04, 20 November 2024 (UTC)
- Iceland's a fantastic place, and everyone needs to go on a night out in Reykjavik before they die, although some people might need to extend their mortgages to do it. It's true that pornography is technically illegal in Iceland, so in that scenario, if the worst should happen, some of your more worrisome drawings on Wikimedia Commons might be lost; but I understand that the antipornography laws are rarely enforced.—S Marshall T/C 17:05, 20 November 2024 (UTC)
- I have spent a night in Reykjavik (well, it was aboard ship, but we did stay overnight), but I will note that Iceland has no army or navy and only a small coast guard. I'm not sure how well the country could resist pressure from the US (or Russia, for that matter, if the US were looking the other way) to interfere with any entity operating there. I used to have hopes that the EU would get its collective defense act together, but even if it did, Iceland hasn't joined, yet. Donald Albury 18:26, 20 November 2024 (UTC)
- I really don't think we need to worry about the US or Russia invading iceland or something. Besides, they have allies that could protect them. Gaismagorm (talk) 18:31, 20 November 2024 (UTC)
- But since we’re pretending like this actually a viable idea Switzerland has a formidable military for the express purpose of defending its neutrality. Dronebogus (talk) 06:26, 21 November 2024 (UTC)
- OKay I have the perfect one. Vatican city. They'd first have to get through italy, then the elite swiss guard. Gaismagorm (talk) 11:35, 21 November 2024 (UTC)
- Not only that but it would look really bad if anyone invaded the vatican. Gaismagorm (talk) 11:36, 21 November 2024 (UTC)
- Wikimedia starts its own nation. The Bir Tawil is always available. Dronebogus (talk) 21:35, 21 November 2024 (UTC)
- Not only that but it would look really bad if anyone invaded the vatican. Gaismagorm (talk) 11:36, 21 November 2024 (UTC)
- OKay I have the perfect one. Vatican city. They'd first have to get through italy, then the elite swiss guard. Gaismagorm (talk) 11:35, 21 November 2024 (UTC)
- But since we’re pretending like this actually a viable idea Switzerland has a formidable military for the express purpose of defending its neutrality. Dronebogus (talk) 06:26, 21 November 2024 (UTC)
- I really don't think we need to worry about the US or Russia invading iceland or something. Besides, they have allies that could protect them. Gaismagorm (talk) 18:31, 20 November 2024 (UTC)
- @S Marshall: I’m actually thinking of stuff like the Internet Watch Foundation and Wikipedia or Seedfeeder. Plus a country with a tiny, homogeneous population (even a very friendly one) is more likely and able to legally force its weird idiosyncratic opinions onto Wikimedia, especially if it thinks the biggest nonprofit website on Earth has done something to damage its reputation (because in this hypothetical scenario Wikimedia would quickly become synonymous with Iceland by virtue of being its biggest export besides maybe Bjork) Dronebogus (talk) 06:39, 21 November 2024 (UTC)
- Socialists are expected to win the next Iceland elections this month, so we would have at least 5 years without worrying. Many organizations had to move in Paris then in London then in the United States in WWII. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:23, 24 November 2024 (UTC)
- The moon. We will move to the moon. Gaismagorm (talk) 02:06, 24 November 2024 (UTC)
- No. Latency would be tarrible and it wouldn t mean much than moving into the ocean as legally, everything would need to be attached to an earth nation. However by speaking about time, Elon, is planning 2 starship launches per week under Trump. If he moves to mars, in less than a decade, he ll be cut from Internet access. That s why gainning time is usefull. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:15, 24 November 2024 (UTC)
- The moon. We will move to the moon. Gaismagorm (talk) 02:06, 24 November 2024 (UTC)
- Socialists are expected to win the next Iceland elections this month, so we would have at least 5 years without worrying. Many organizations had to move in Paris then in London then in the United States in WWII. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:23, 24 November 2024 (UTC)
- I have spent a night in Reykjavik (well, it was aboard ship, but we did stay overnight), but I will note that Iceland has no army or navy and only a small coast guard. I'm not sure how well the country could resist pressure from the US (or Russia, for that matter, if the US were looking the other way) to interfere with any entity operating there. I used to have hopes that the EU would get its collective defense act together, but even if it did, Iceland hasn't joined, yet. Donald Albury 18:26, 20 November 2024 (UTC)
- Iceland's a fantastic place, and everyone needs to go on a night out in Reykjavik before they die, although some people might need to extend their mortgages to do it. It's true that pornography is technically illegal in Iceland, so in that scenario, if the worst should happen, some of your more worrisome drawings on Wikimedia Commons might be lost; but I understand that the antipornography laws are rarely enforced.—S Marshall T/C 17:05, 20 November 2024 (UTC)
- Honestly, it's unneeded. Look, I get worrying about this situation but I doubt the situation will get so bad where wikipedia needs to move overseas. As stsated above, wikimedia also likely already has a plan for if this happens. Gaismagorm (talk) 11:40, 13 November 2024 (UTC)
- Just a thought, but if the WMF does have or in the future creates contingency plans for moving operations in response to political developments, publicly revealing such plans in advance might make it harder to carry them out. It would be like a business announcing that they will build a factory in a given location without having at least an option to buy the land they will build on. Donald Albury 16:11, 13 November 2024 (UTC)
- They don t have to reveal which plan, only if they have a plan to move and if no build 1. Moving operations isn t required, just move legally. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:38, 24 November 2024 (UTC)
- Stop worrying to much, I doubt Trump is going to do anything against Wikipedia. Attacking and threatening to block Wikipedia will only infuriate the centrist voters, which I didn't think anyone would want to do. Some of the editors here are Trump supporters as well! What is concerning for Wikipedia today is the above case in India, where WMF HAD agreed to disclose the editor's information because of a defamation suit. ✠ SunDawn ✠ (contact) 06:01, 14 November 2024 (UTC)
- This is also an important part of the analysis: we are hardly the most vulnerable collective entity in existence: for obvious reasons, we are meant to be apolitical, unaligned, and disinterested in directly influencing public perception of any matter (beyond the core mission of providing information, of course). But the one time this community was willing to flex its muscles to head off a legislative outcome that it felt was a danger to the fundamental viability of the project, the latent power of the project's reach, through the site/encyclopedia was made pretty obvious--and that strength was not trivial, utterly crushing legislation that had been sailing through congress. If pushed into a corner and forced to abandon its apolitical role, this movement is capable of coming back with potent counter-punches in terms of grassroots mobilization, and I think there is some perception of that fact out there now.
- There's also the massive legal warchest of the WMF to contend with (which so many on this project have groused about over recent years, but which was well-advised to build up, for exactly this moment in time). Of course, the current ANI situation raises significant concerns about the ability of the WMF and the community to row together, which is one of the most concerning things about that situation. But the WMF will not have the same onerous sub judice principles giving it both legitimate and illegitimate reasons not to communicate clearly with us (at least nowhere near to the same degree) with regard to suits before U.S. courts. SnowRise let's rap 20:51, 17 November 2024 (UTC)
- Strongly Disagree. He is attempting to appoint the guy at the Fcc that plan to enact laws allowing to crack down on mederation as the part of Project2025 he did write. The Framework would give the power to the Fcc to prevent any kind of moderations by platforms as long as it s not death threats. Wikipedia Articles would be legally compelled to accept Breibart New or Infowars as a trusted source. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:14, 23 November 2024 (UTC)
- Realistically, I doubt anything in particular will happen to Wikipedia. But if you want to prepare for the worst, as it were, and you have a machine with some extra disk space, consider periodically keeping an updated copy of the Wikipedia database dump. I get one periodically, just in case, since I've got plenty of spare space on this machine anyway. If worst ever came to worst, plenty of volunteers have the technical skill to get a DB dump up and working on a MediaWiki instance elsewhere, and run it at least while things are sorted out. I doubt it'll ever come to that, but if you want to be prepared just in case, well, the more widely copies of those are available, the better. Just remember that Wikipedia was completely run by volunteers once, from software development to sysadmins, and we could do it again if we had to. Seraphimblade Talk to me 06:12, 14 November 2024 (UTC)
- The biggest problem would be providing sufficient server capacity to handle the traffic. Anybody can put up a static mirror of WP as it was on the download date (Lord knowns there are a lot of those on the Internet), but providing an editable version that would be used by a large proportion of current editors would be pretty expensive. And if there were more than one editable version out there, it would be very difficult to ever merge the changes back into a single database, with some clones becoming permanent forks, perhaps sponsored by governments and other large entities. Donald Albury 18:19, 14 November 2024 (UTC)
- I've thought of the technical feasibility of a forked encyclopedia more the last few weeks than I have in the last ten years. Not as a serious exercise in making any plans, but just as a consequences of thinking about the relationship between the project and the WMF and what actually keep volunteers invested in this particular, traditional and only mode of building the encyclopedia. Aside from the obvious organizational and cultural ties, there's the obvious cost of maintaining ongoing access and development that you talk about, but then there's also the liabilities and legal fees. If circumstances were drastic enough to take Wikipedia itself down, it would be hard to shield any project with a big enough profile to be able to afford the access and tools for readers and editors from whatever legal forces had compromised Wikipedia's viability in the first place. Even redundancy different jurisdictions wouldn't necessarily obviate the kinds of threats that would be sufficient to take the original Wikipedia out of the picture. SnowRise let's rap 07:49, 18 November 2024 (UTC)
- You know, unless it's a case of tearing itself apart, I suppose... SnowRise let's rap 07:50, 18 November 2024 (UTC)
- I hadn't thought about the legal side. Trying to fork Wikipedia may well cause more problems than it could ever solve. I think the best chance of preserving Wikipedia is anything like its current form is to let the foundation do its job. If the foundation cannot protect Wikipedia in the US, there is little hope of Wikipedia surviving somewhere else. Donald Albury 15:08, 18 November 2024 (UTC)
- I m thinking about WWII where many organizations had to move in Paris then in London then in the United States. Moving should be studied, the fundation wouldn t be able to protect as much Wikipedia as in the US but it would be allowed to do better than abide to https://www.wired.com/story/brendan-carr-fcc-trump-speech-social-media-moderation/. We might even gain 10 years by behaving like that. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:12, 24 November 2024 (UTC)
- I do own a 200Tb server with 1Tib of ram on a 10Gb/s connection. Enough to power all wikipedia.org websites in read only mode. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:15, 23 November 2024 (UTC)
- Unless it s someone who own the hardware personally. No, as I looked, most of the traffic is static web pages loading numbers aren t that much important. The problem is to have proper physicall backups but this would let the WMF time to organize for moving overseas.
- However, as a matter of risks mitigation, password hashes aren t part of data dumps. Until they aren t dumped, admins wouldn t be able to login back. Asking them to be dumped would be an important step. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:01, 24 November 2024 (UTC)
- I've thought of the technical feasibility of a forked encyclopedia more the last few weeks than I have in the last ten years. Not as a serious exercise in making any plans, but just as a consequences of thinking about the relationship between the project and the WMF and what actually keep volunteers invested in this particular, traditional and only mode of building the encyclopedia. Aside from the obvious organizational and cultural ties, there's the obvious cost of maintaining ongoing access and development that you talk about, but then there's also the liabilities and legal fees. If circumstances were drastic enough to take Wikipedia itself down, it would be hard to shield any project with a big enough profile to be able to afford the access and tools for readers and editors from whatever legal forces had compromised Wikipedia's viability in the first place. Even redundancy different jurisdictions wouldn't necessarily obviate the kinds of threats that would be sufficient to take the original Wikipedia out of the picture. SnowRise let's rap 07:49, 18 November 2024 (UTC)
- Yes, I have the entirety of the English Wikipedia as of a few months ago downloaded onto my laptop, plus a few other Wikimedia projects. TheLegendofGanon (talk) 21:08, 16 November 2024 (UTC)
- Worst comes to worst, execute WP:TERMINAL. 2400:79E0:8071:5888:1808:B3D7:3BC1:B010 (talk) 08:43, 17 November 2024 (UTC)
- In case of emergency, one should always know how to use the terminal. Seraphimblade Talk to me 23:07, 17 November 2024 (UTC)
- But if we have the dumps of the passwords hashes, we can just relocate to an other country. Telegram itself is completely unresctrictred by being based in Dubai. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 20:27, 23 November 2024 (UTC)
- The biggest problem would be providing sufficient server capacity to handle the traffic. Anybody can put up a static mirror of WP as it was on the download date (Lord knowns there are a lot of those on the Internet), but providing an editable version that would be used by a large proportion of current editors would be pretty expensive. And if there were more than one editable version out there, it would be very difficult to ever merge the changes back into a single database, with some clones becoming permanent forks, perhaps sponsored by governments and other large entities. Donald Albury 18:19, 14 November 2024 (UTC)
- Fyi, the US House narrowly stopped a legislation that would give Trump the keys to revoke non-profit status of any non-profit organisation in US. [46], [47]. – robertsky (talk) 01:43, 17 November 2024 (UTC)
- To be frank, I am greatly surprised by the faith you put in the US Constitution. Many of you seem unaware that the threats you are facing are unprecedented. Trump attempted a coup in 2020 and during his campaign he actually said he wants to be a dictator. Or how else are we to interpret such things as "If you vote for me, you don't have to vote at all in four years"? He didn't say all this back in 2016. Neither did he employ such rascals in his government as he is planning to do know. Therefore I find the argument that we lived through Trump's first presidency unharmed very unconvincing.
- He and his loyal servants have expressed their contempt of science on numerous occasions, most recently J.D. Vance by saying "professors are the enemy". With both houses of the Congress and the Supreme Court in Republican hands, checks and balances aren't worth much, especially since the party has shown an unfaltering loyalty for its Great Leader over the past few years. A major Gleichschaltung operation is to be expected. What matters most in situations like this is not the law but the sentiment of the people. And that sentiment seems to be strongly in favour of an authoritarian dictatorship. Under such conditions, laws are easily explained the way that best fits the regime.
- So for goodness' sake, move! Not just the servers, but also the WMF as a legal entity. I am well aware that no country on Earth is entirely safe of a populist threat, but the situation isn't as dire everywhere as it is in the US. Canada could be an option. Or Spain, one of the few European countries that still welcomes immigration of some sort. Do it, before it's too late! Don't let yourselves and our work be ground among the cogwheels of this vile, narcissistic despotism! Steinbach (talk) 10:56, 17 November 2024 (UTC)
- Steinbach, you write that the sentiment of the people
seems to be strongly in favour of an authoritarian dictatorship
and yet the current popular vote count has Trump at 50.1% and dropping as California votes continue to be counted. So, the sentiment is not as strong as you portray it. I too am deeply concerned about the path that the United States is on, but we should not overstate public sentiment for dictatorship. Cullen328 (talk) 22:55, 17 November 2024 (UTC)- We should rather say enough peoples that want to go authoritharian so that it doesn t matters. Clearly, things like Dark Maga couldn t had been something elected several years ago. An ideological shift happnned. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:48, 24 November 2024 (UTC)
- Steinbach, you write that the sentiment of the people
- Billions of people rely on Wikipedia. Trump won't be able to do anything without the world going against him. Tons of his very voters shame his fake news big lie narrative. Aaron Liu (talk) 17:20, 17 November 2024 (UTC)
- Ah! you say that, but look how it ended for Twitter. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:19, 23 November 2024 (UTC)
- How is that related? Aaron Liu (talk) 19:38, 23 November 2024 (UTC)
- In 2023, you could had said: Billions peoples relies on Twitter, Elon won t be able to trick it s algorithms to promote disinfo and gender hate speech since the platform rules disallow such thing (and in fact promoting gender discrimination is still among x.com terms of rules but of course the owner is now doing it all the day along and it s 206 millions followers props its content)
- There s a flight of course, but it s not massive, and x.com largely keeps the original twitter.com userbase. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:54, 24 November 2024 (UTC)
- Yes, but it's important to note that the twitter changes were due to elon buying twitter, not due to new laws being formed. Elon Musk (no matter how much he wants to try) can't buy wikimedia. Gaismagorm (talk) 02:08, 24 November 2024 (UTC)
- What s the difference between Elon buying twitter and Congress weaponizing the Fcc with a conservative court? I d rather says none! 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:11, 24 November 2024 (UTC)
- The difference is one is just a poor business strategy, and the other is mostly unfeasable (at least to the level that some are wanting, or dreading). Besides, wikipedia isn't a social media site. It is a encyclopedia. Gaismagorm (talk) 02:19, 24 November 2024 (UTC)
- Elon musk tweets claims highlights that he sees no difference between speech regulation on wikipedia and Youtube/Facebook. I might agree the biggest risk is gettting the fundation non profit status revoked. McCartysm shows how the constitution can little free speech protections. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:24, 24 November 2024 (UTC)
- And McCarthy didn’t last either, because eventually someone called his BS and he crumbled Dronebogus (talk) 10:14, 24 November 2024 (UTC)
- With the planning purschase of MSNBC by Elon, things will last like in Russia where richs mens that supports the executive using conflict of interests purschase and control the media. It Science evidences that won t last. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 10:32, 24 November 2024 (UTC)
- And McCarthy didn’t last either, because eventually someone called his BS and he crumbled Dronebogus (talk) 10:14, 24 November 2024 (UTC)
- Elon musk tweets claims highlights that he sees no difference between speech regulation on wikipedia and Youtube/Facebook. I might agree the biggest risk is gettting the fundation non profit status revoked. McCartysm shows how the constitution can little free speech protections. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:24, 24 November 2024 (UTC)
- The difference is one is just a poor business strategy, and the other is mostly unfeasable (at least to the level that some are wanting, or dreading). Besides, wikipedia isn't a social media site. It is a encyclopedia. Gaismagorm (talk) 02:19, 24 November 2024 (UTC)
- What s the difference between Elon buying twitter and Congress weaponizing the Fcc with a conservative court? I d rather says none! 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 02:11, 24 November 2024 (UTC)
- Yes, but it's important to note that the twitter changes were due to elon buying twitter, not due to new laws being formed. Elon Musk (no matter how much he wants to try) can't buy wikimedia. Gaismagorm (talk) 02:08, 24 November 2024 (UTC)
- How is that related? Aaron Liu (talk) 19:38, 23 November 2024 (UTC)
- Ah! you say that, but look how it ended for Twitter. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:19, 23 November 2024 (UTC)
- What you are urging is not really feasible, at least not in the short term, and if the fight you fear is coming, it will go best for the movement on the ground that a U.S. base provides. If you think that moving to Spain and putting the project even further under the auspices of EU law will lead to greater free speech protections, I have bad news for you: a substantial portion of the content on this site would be much more amenable to exclusion and state interference under petition by private parties under GDPR principles than it would under U.S. jurisprudence. This is one area of civil and human rights where the EU is much more laissez-faire about suppression than is the U.S., especially when you consider "right to be forgotten" stances. SnowRise let's rap 21:02, 17 November 2024 (UTC)
- Exactly, but we don t have to do it on the short term. We have time before things changes. And that s why we must be prepared to move instead of realizing we have to move within 2 weeks.. We can move in Damage control. For example if we did choose Qatar, we would have to just remove all content that critisize the country. Otherwise they have a strong journalism and allow to critiise anything else, including saudi Arabia. Plus there s no elections there (so stable). There would be no such things as accepting climate changes and vaccine by Trumpers. The United States might had been the best place, but now it risks to become worst than Russia. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:21, 23 November 2024 (UTC)
- We are not moving to any country that would make us remove all content critical of said country. QuicoleJR (talk) 22:14, 23 November 2024 (UTC)
- It s about a tradeoff. Because you prefer not only letting Trumpers to remove anti trump content but to change all sciences articles at a massive scale? No info is better than conspirasionism and disinfo. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:04, 24 November 2024 (UTC)
- This would take longer than two weeks since the WMF would have to legally establish themselves in a new country, and study their laws so they are in compliance with them. So years, not two weeks. Also Qatar would want to delete articles and media of human sexuality and possibly some other highly contentious topics, so that would appear to be a nonstarter for WMF. Abzeronow (talk) 23:47, 23 November 2024 (UTC)
- I m noticing Telegram was allowed to let gender discussion happenning by being in Dubai in addition to outright advertising illegal drug trade. Otherwise, exactly! As passing laws through congress takes time' we do have time. That s why it has to be studied now, so when rather than if it become required everything would be ready. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 01:08, 24 November 2024 (UTC)
- We are not moving to any country that would make us remove all content critical of said country. QuicoleJR (talk) 22:14, 23 November 2024 (UTC)
- Exactly, but we don t have to do it on the short term. We have time before things changes. And that s why we must be prepared to move instead of realizing we have to move within 2 weeks.. We can move in Damage control. For example if we did choose Qatar, we would have to just remove all content that critisize the country. Otherwise they have a strong journalism and allow to critiise anything else, including saudi Arabia. Plus there s no elections there (so stable). There would be no such things as accepting climate changes and vaccine by Trumpers. The United States might had been the best place, but now it risks to become worst than Russia. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:21, 23 November 2024 (UTC)
- Cross that bridge if we get there. I don't imagine this would be seriously considered at the current time. –Novem Linguae (talk) 22:39, 17 November 2024 (UTC)
- Last I heard the WMF keeps both the main site and the backup site in the US. Now might be a good time to reevaluate this and move one of them to another country. The WMF is quite good at employing a diverse multinational workforce scattered across the planet, but it is very centralised when it comes to fundraising, a more distributed model where funds raised in particular countries were controlled by affiliate charities or chapters in those countries would in my view be stronger. At least it wouldn't have a single point of failure. ϢereSpielChequers 15:02, 18 November 2024 (UTC)
- The problem is wikimedia begin subject of thr incoming Fcc laws. 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 18:23, 23 November 2024 (UTC)
- I don't think the WMF has contingency plans for any potential authoritarian steps Trump may take, and as seen with the ANI case, may obey any legal demands the Trump Administration makes of them. WMF does have some flexibility not to do some things since they are not a publisher (that is they don't have editorial control over Wikipedia), and WMF does not want such control. I don't think the WMF would share their contingency plans if they have them though, and by the time Trump or his Administration took extreme authoritarian measures against WMF and its Board, it would probably be too late to do anything. Abzeronow (talk) 19:55, 23 November 2024 (UTC)
- The point is to ask to etablish such moving overseas plans. They don t have to tell us which is the plan but if they have 1.
- Under the project 2025, they would compell the WMF to allow any kind of sources as trusted (and thus requires them to have some controls over Wikipedia). 2A01:E0A:401:A7C0:64A1:A0FD:CDDA:2E99 (talk) 20:04, 23 November 2024 (UTC)
- WMF moving its servers to Switzerland has its own tradeoffs (no PD-Art; possibly different fair use/fair dealing laws, some PD-US works would have to be deleted), and such a process would take years so it would not be helpful against a Trump Administration. Abzeronow (talk) 21:39, 23 November 2024 (UTC)
- Moving servers isn t needed, just the legal entity. I m also noticing that by chosing Dubai Telegram was allowed to have no moderation at all to the point of outright being allowed to let opiods advertising posts. United States is clearly the best country, but things can become worst than in Russia and thus have to legally move to a place where things wouldn t be ideal but better thzn the upUnited States2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:16, 24 November 2024 (UTC)
- What if we hosted some content in some countries and other content in others? I know, I know, that’s probably just the insane troll logic talking Dronebogus (talk) 10:48, 24 November 2024 (UTC)
- WMF moving its servers to Switzerland has its own tradeoffs (no PD-Art; possibly different fair use/fair dealing laws, some PD-US works would have to be deleted), and such a process would take years so it would not be helpful against a Trump Administration. Abzeronow (talk) 21:39, 23 November 2024 (UTC)
As an alternative, would it be possible to have dumps of password hashes for each users? I know it s a little security threat but it would be a good thing in current times, As there s data dumps of everything else, this would allows anyone to resume operations (without physicallly separated backups though). In my case, I personally own what s required for 1/4th of the traffic. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 00:42, 24 November 2024 (UTC)
- Is this thread a good use of time? WMF will not be moving out of the United States, Elon Musk and Donald Trump will not be meeting with anyone from WMF (nor would it be wise for us to do anything to get on their radar), and WMF is not going to publicly release our password hashes. This thread is full of the most hypothetical of hypotheticals. –Novem Linguae (talk) 10:35, 24 November 2024 (UTC)
- It’s not. But it a) helps Wikimedians cope with the uncertainty of the present moment and b) leads to amusing tangents about relocating to Iceland/Switzerland/Spain/the Moon. Dronebogus (talk) 10:45, 24 November 2024 (UTC)
- Well said, Novem Linguae. Phil Bridger (talk) 11:17, 24 November 2024 (UTC)
- Passwords hashes says little about the underlying password as basically it s what things like Bitcoin s security is based on. I m suggesting it as an alternative of moving to a better place if the United States turns from the best place to the worst place in order to to let other peoples take back hosting in other countries. Personally, I created an account in 2013, and wouldn t mind having the password hash being released for thr greater good.
- Ok. Guys Makes sure to not have debates https://x.com/DemocraticWins/status/1835668071773581413. But I m sure to bet something, and I can open a Polymarket about this: Within 11 months you d had lost all your trials by deseparately trying to stay in the United States at all costs, and all langagues of wikipedia would have turned to promoting consiparcies theories even in in maths or wikipedia.org will be shut down. Such passivity in the face of the obvious will be remembered in the history like the actions of the Sigmund Freuds Sisters thinking something like the Shoas won t happen. 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2 (talk) 11:47, 24 November 2024 (UTC)
- 2A01:E0A:401:A7C0:7829:35FD:7F37:21A2, stop WP:BLUDGEONing the debate with your sensational doomerism. You have made fewer than 50 edits and they’re exclusively to this thread. This is WP:SPA behavior and it’s growing tedious. If you are WP:NOTHERE to build an encyclopedia then I see good reason to report you to an admin. Dronebogus (talk) 12:59, 24 November 2024 (UTC)
Wikimedia Foundation Bulletin November Issue 2
Upcoming and current events and conversations
Talking: 2024 continues
- Conversation with the trustees: Speak directly with the Wikimedia Foundation trustees about their work at the next Conversation with the Trustees on 27 November from 12:00 – 13:30 UTC.
- Wikimedia Hackathon: Registration is now open for the 2025 Wikimedia Hackathon which will be held in Istanbul, Turkey, May 2–4, 2025.
- Language Community: The next language community meeting will be held on November 29 at 16:00 UTC.
- Wikimania 2025: Application for scholarship to attend Wikimania 2025 in Nairobi is open until the end of December 8.
- Central Asian WikiCon: The Central Asian WikiCon 2025 will take place on April 19–20, 2025, in Tashkent, Uzbekistan. Applications to be part of the Program and Scholarship Committee is open until November 30.
Annual Goals Progress on Infrastructure
See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org
- Tech News: Admins and users of the Wikimedia projects where Automoderator is enabled can now monitor and evaluate important metrics related to Automoderator's actions; Stewards can now make global account blocks cause global autoblocks. Learn about the latest tech updates from tech news 45, 46, and 47.
- Wikifunctions: Wikifunctions now has a new Type: rational numbers. They expand the ability to deal with numbers considerably, allowing us to work with fractions and decimals, and not just whole numbers anymore. More status updates.
- Temporary accounts: We are rolling out temporary accounts for unregistered (logged-out) editors for more wikis including Romanian, Serbian, Danish, and Norwegian Bokmål.
Annual Goals Progress on Equity
See also a list of all movement events: on Meta-Wiki
- Language & Internationalization: The fifth edition of the Language & Internationalization newsletter is available. Some key highlights: Mooré Wikipedia is live; Keyboard Layouts for Multiple Languages Added; New Projects Added to Translatewiki.net.
- Wikimedia Research Showcase: Watch the latest showcase which looked at external factors that help different language versions of Wikipedia thrive.
- Wikipedia Library: What's new in the Wikipedia Library?
- Tulu Wikisource: Welcoming Tulu Wikisource.
- CEE Meeting 2024: Highlights from Central Asian community members at the CEE Meeting 2024.
- Let's Connect: Let's Connect Learning clinic on Gender Sensitivity Training within Wikimedia communities was held on November 22.
Annual Goals Progress on Effectiveness
See also: quarterly Metrics Reports
- Audit reports 2023-24: Highlights from the fiscal year 2023–2024 Wikimedia Foundation and Wikimedia Endowment audit reports.
- Wikimedia Enterprise: Financial report of Wikimedia Enterprise for the fiscal year 2023–2024.
Board and Board committee updates
See Wikimedia Foundation Board noticeboard · Affiliations Committee Newsletter
- Board Updates: The Board met in Katowice, Poland on August 5 and held its quarterly business meeting before Wikimania. Learn more about the outcomes of the meeting.
- AffCom: The Affiliates Committee has resumed User Group recognition work after a pause to improve the User Group recognition process.
Other Movement curated newsletters & news
See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · other newsletters:
- Topics: Education · GLAM · The Wikipedia Library
- Wikimedia Projects: Milestones · Wikidata
- Regions: Central and Eastern Europe
Subscribe or unsubscribe · Help translate
Previous editions of this bulletin are on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
MediaWiki message delivery 18:18, 25 November 2024 (UTC)
Wikimedia Foundation banner fundraising campaign in Australia, Canada, Ireland, New Zealand, the UK, and the US starts next week
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in Australia, Canada, Ireland, New Zealand, the UK, and the US from the 2nd to the 31st of December 2024.
You can find more information around the campaign on the community collaboration page.
Generally, before and during the campaign, you can contact us:
- On the talk page of the fundraising team or on the community collaboration page
- If you need to report a bug or technical issue, please create a phabricator ticket
- If you see a donor on a talk page, VRT or social media having difficulties in donating, please refer them to donate at wikimedia.org
Thank you and regards, JBrungs (WMF) (talk) 05:54, 27 November 2024 (UTC)
- If it starts next week, then why have I been seeing it for several weeks already? 216.147.127.204 (talk) 17:39, 28 November 2024 (UTC)
The future of US government web sites as sources
I am posting this here because it has very broad implications for the project and may require foundation help in the coming weeks. Wikipedia articles on energy and the environment and other many other subjects rely on data from US government web sites, which are generally regarded as authoritative. There is a significant likelihood that many or all of these sites will be taken offline after January 20, 2025 when the US administration changes over. Is the foundation participating in any organized effort to back this material up? Can we just rely on the Internet Archive? What happens if the new administration puts up conflicting data? Will editors be free to "correct" articles based on what newer Government websites say, regardless of scientific backing? We do not have a lot of time to think this through.--agr (talk) 19:02, 1 December 2024 (UTC)
- I understand (and share) your concern, but deciding which sources are reliable is an editorial decision which the WMF does not get involved in. Sources that were once considered reliable can have their reputation reevaluated if conditions warrant, and even sources that are generally considered reliable should always be examined with a critical eye to ensure that any particular statement holds up to the general reputation.
- This is an important issue, but it's just not one that the WMF has any input on. I would suggest asking this at WT:RS or perhaps WP:RSN. RoySmith (talk) 19:44, 1 December 2024 (UTC)
- As far as I know, whenever something is cited on Wikipedia, the Internet Archive automatically takes a snapshot of it. You can contact someone like GreenC to confirm this.
- The rest of your post seems like it would be a good fit for WP:RSN. Reliable sources have become unreliable before, and RSN can handle reducing a source's ranking on the WP:RSPSOURCES list when that situation comes to pass. A note will even be added to the entry stating that it used to be reliable, and after what date it became unreliable. However, it might be jumping the gun to post about this before it actually happens. There's not really anything to do yet. –Novem Linguae (talk) 00:27, 2 December 2024 (UTC)
- Do you have a specific source for the allegations that many or all of these sites will be taken offline after January 20, 2025? Yes, the Dept. of Ed website's not going to be up anymore if that agency is axed, but this isn't the first post that I've seen here predicting that the administration change will be the end of America as we know it. Yes, if the energy/climate/public health sites go downhill we can/will revisit how we handle those sources. But all of this doom and gloom is overwrought, like when people I knew thought Obama was the antichrist or that Hillary was going to put Christians into death camps. This is Wikipedia, not Reddit. I thought we were a little more level-headed here. Hog Farm Talk 02:01, 3 December 2024 (UTC)
- We had a nice four years where the main agitators in AMPOL were right-wing nuts. These are pretty easy to take care of, since they have virtually zero social capital on Wikipedia. They can be overruled and the community is ready to ban them at the drop of a hat if they get frustrated and lash out. Now we can look forward to four years where the main agitators will be left-wing nuts and #Resistance. This is harder to deal with because these people do have social capital on Wikipedia and have wikifriends (including several established editors and admins) to come back them up in disputes or tilt consensus. I suspect we can also look forward to more Anti-American bigotry toward subjects and editors as well. Thebiguglyalien (talk) 19:43, 3 December 2024 (UTC)
Recent WMF update on ANI case
Noting that the WMF has posted an update on the ANI case here on 2 December, for those interested. —Ganesha811 (talk) 12:37, 4 December 2024 (UTC)
Novak
@نوفاك اتشمان Mustafa jesi išao u džamiju? Д.Р.К.А.Џ.И.Ј.А (talk) 10:34, 5 December 2024 (UTC)
Miscellaneous
Special:Export and Wikidata QID?
Hello everyone, the Wikidata for Wikimedia projects team is investigating the benefit of adding a new <tag> for a Wikidata item QID into the XML file output from the Special:Export function.
Have you used this function before? If yes, we would like to hear from you.
- Would adding a new <tag> for a linked Wikidata item (e.g. <wikidataid>) aid you?
- What types of pages did you export? (article, template, talk etc.)
- What did you do with the exported content?
Please leave your comments or questions as a reply to this message, thank you. -Danny Benjafield (WMDE) (talk) 15:36, 27 November 2024 (UTC)
- What does this new tag do? Blueboar (talk) 18:25, 27 November 2024 (UTC)tag.
- @Blueboar The message is referring to tags in the XML file you get from exporting a page, not tags that are used in wikitext. The tag doesn't "do" anything, XML files use HTML like tags to mark up data fields. 86.23.109.101 (talk) 20:32, 27 November 2024 (UTC)
- I can see this being useful to others, but the tag name (wikidataid) seems suboptimal. Could "wikidata-id", "wikidata-qid", or even just "wikidata" or "qid" be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 30 November 2024 (UTC)
- Hello @Pigsonthewing, yes it can be different, although <wikibaseitem_id> was suggested to fit with an existing schema. However, we have put the task on hiatus due to the potential consequences this addition could have on the size and time required for the weekly Wikipedia database dumps. -Danny Benjafield (WMDE) (talk) 16:55, 2 December 2024 (UTC)
Desblock my account in Wikipedia spanish
Hi wikis,please asked to the User:Taichi (hes blocked my account and e-mail indefinitely from this https://es.m.wikipedia.org/wiki/Wikipedia:Solicitudes_de_verificaci%C3%B3n_de_usuarios?markasread=58923216&markasreadwiki=eswiki) I'm not a sockpuppet of these users. AbchyZa22 (talk) 10:47, 29 November 2024 (UTC)
But im a good faith so please asked this user Taichi AbchyZa22 (talk) 10:48, 29 November 2024 (UTC)
- AbchyZa22, as this is the English Wikipedia, we have no authority over the Spanish Wikipedia. Each language Wikipedia is a separate project. If you are blocked on Spanish Wikipedia, you will have to appeal your block there; you can find instructions here in regards to that. Seraphimblade Talk to me 10:54, 29 November 2024 (UTC)
- Hello, AbchyZa22. This is the English Wikipedia. The Spanish Wikipedia is a separate autonomous project with its own policies, guidelines and administrators. We have no influence or power over them. We cannot help you here. You must use the block appeal processes on the Spanish Wikipedia. Cullen328 (talk) 10:57, 29 November 2024 (UTC)
- Ok, thank you AbchyZa22 (talk) 10:58, 29 November 2024 (UTC)
- @Cullen328@Seraphimblade:Can't edit (https://es.wikipedia.org/w/index.php?title=Especial:UsuariosBloqueados&wpTarget=%239201891) look AbchyZa22 (talk) 11:05, 29 November 2024 (UTC)
- Sorry to hear it, but there's really nothing we can do about it. You will have to follow whatever appeals process the Spanish Wikipedia has; we can neither do that for you nor do anything about it. Seraphimblade Talk to me 11:07, 29 November 2024 (UTC)
- AbchyZa22, I hope that you understand that English Wikipedia editors and adminstrators have no power whatsoever over the Spanish Wikipedia. We are not their bosses in any way. Cullen328 (talk) 11:33, 29 November 2024 (UTC)
Temporary Accounts - introduction to the project
The Wikimedia Foundation is in the process of rolling out temporary accounts for unregistered (logged-out) editors on multiple wikis. The pilot communities have the chance to test and share comments to improve the feature before it is deployed on all wikis in mid-2025.
Temporary accounts will be used to attribute new edits made by logged-out users instead of the IP addresses. It will not be an exact replacement, though. First, temporary users will have access to some functionalities currently inaccessible for logged-out editors (like notifications). Secondly, the Wikimedia projects will continue to use IP addresses of logged-out editors behind the scenes, and experienced community members will be able to access them when necessary. This change is especially relevant to the logged-out editors and anyone who uses IP addresses when blocking users and keeping the wikis safe. Older IP addresses that were recorded before the introduction of temporary accounts on a wiki will not be modified.
We would like to invite you to read the first of a series of posts dedicated to temporary accounts. It gives an overview of the basics of the project, impact on different groups of users, and the plan for introducing the change on all wikis.
We will do our best to inform everyone impacted ahead of time. Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms. At conferences, we or our colleagues on our behalf are inviting attendees to talk about this project. In addition, we are contacting affiliates running community support programs.
Subscribe to our new newsletter to stay close in touch. To learn more about the project, check out the FAQ and look at the latest updates. Talk to us on our project page or off-wiki. See you! NKohli (WMF) and SGrabarczuk (WMF) (talk) 17:39, 29 November 2024 (UTC)
- My main question is: will people still be allowed to mention the IP adresses onwiki in e.g. sockpuppet investigations? If not, then this seems like a severe nuisance for such investigations. But if this will be considered a form of outing or confidentiality breach, then that should be made very clear and taken into consideration before deciding whether this is a blocker for this project or not. Fram (talk) 17:47, 29 November 2024 (UTC)
- Great question. The Wikimedia Access to Temporary Account IP Addresses Policy says
When it is reasonably believed to be necessary, users with access to temporary account IP addresses may also disclose the IP addresses in appropriate venues that enable them to enforce or investigate potential violations of our Terms of Use, the Privacy Policy, or any Wikimedia Foundation or user community-based policies. Appropriate venues for such disclosures include pages dedicated to Long-term abuse. If such a disclosure later becomes unnecessary, then the IP address should be promptly removed.
- In short, it's better not to do it unless you have a good reason and you do it on the right page (like Wikipedia:Long-term abuse). SGrabarczuk (WMF) (talk) 17:55, 29 November 2024 (UTC)
- Thanks, I presume any "official" page dealing with abuse (WP:AN, WP:ANI, WP:SPI, and arbcom) may be considered acceptable locations then. Of course within reason, not gratuitously disclosing IPs for the sake of it. Fram (talk) 18:06, 29 November 2024 (UTC)
- Yup, exactly! SGrabarczuk (WMF) (talk) 18:12, 29 November 2024 (UTC)
- Thanks, I presume any "official" page dealing with abuse (WP:AN, WP:ANI, WP:SPI, and arbcom) may be considered acceptable locations then. Of course within reason, not gratuitously disclosing IPs for the sake of it. Fram (talk) 18:06, 29 November 2024 (UTC)
- My hope, although I've not seen this spelt out anywhere, is that temporary accounts will end CUs deliberately tying their own hands regarding IP socking, due to privacy concerns linking accounts to IPs. As CUs can still see IPs from temporary accounts, and IPs will not usually need to be revealed even on SPI pages, what would before have been socking that can't be technically examined (one tool among others but a useful one), will now be temporary accounts that can be listed alongside permanent accounts at SPI pages and similar. CMD (talk) 02:27, 1 December 2024 (UTC)
- I believe all admins and also some power users (account age 6 months, 300 edits, opts in) will still be able to see temporary account IP addresses. So the checkuser practice of declining to link IPs to permanent accounts may still continue. –Novem Linguae (talk) 03:22, 1 December 2024 (UTC)
- The opt-in is already in our preferences, even though we don't have the full system yet. I do hope the SPI practice could change though, trying to get a benefit from this shift. CMD (talk) 12:35, 1 December 2024 (UTC)
- I believe all admins and also some power users (account age 6 months, 300 edits, opts in) will still be able to see temporary account IP addresses. So the checkuser practice of declining to link IPs to permanent accounts may still continue. –Novem Linguae (talk) 03:22, 1 December 2024 (UTC)
- In the screenshot, a popup says "An auto-generated account has been created for you by adding a cookie to your browser."
- What if the user has cookies disabled?
- This is likely to alarm novice users (has the message been user-tested?). It would probably be wise to add a few words of explanation, say: "A temporary auto-generated account has been created for you by adding a cookie to your browser, in order to preserve your anonymity and not reveal your location." and changing "creating an account" to "creating a permanent account"Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 30 November 2024 (UTC)
- @Pigsonthewing, I believe you are looking for mw:Trust and Safety Product/Temporary Accounts/FAQ#How long does a temporary account last? WhatamIdoing (talk) 17:43, 30 November 2024 (UTC)
You are invited to join the discussion at Talk:2024 Bangladesh anti-Hindu violence § Disinformation in Introduction of the page. Rotideypoc41352 (talk · contribs) 04:51, 1 December 2024 (UTC)
- The last time I posted about an earlier version of this discussion at Wikipedia:Neutral point of view/Noticeboard#Talk:2024 Bangladesh anti-Hindu violence#Article protected, it received no response; this discussion would really benefit from additional viewpoints. Thank you. Rotideypoc41352 (talk · contribs) 04:51, 1 December 2024 (UTC)
Avoiding conflicts with WikiEd course work
Two days ago I created an article on Ann Trevenen Jenkin, as part of WP:Women in Red's "Women who died in 2024". Yesterday there was a message on its talk page to say it is part of a WikiEd project, and I find that a student has been working on their draft article on this topic since 2 October. In the nature of student projects, they have been working step by step, week by week. Their draft is not yet fit for mainspace, and the course continues until 18 December. This must happen fairly often, when students pick notable topics which are missing from the encyclopedia but other editors spot the same gaps.
To avoid duplicated work like this, it would be very helpful if topics which are the subject of assignments in WikiEd courses could be flagged in some way, so that when an editor starts to create an article they are alerted, just as we are routinely alerted to the fact that an article on the topic has previously been deleted. Unless the editor feels that an article on the topic is needed with some urgency, they could then leave it aside (perhaps watchlisting it in case the student work needs some improvement), and choose a different topic. Could this be done? Where should I suggest it? PamD 09:37, 3 December 2024 (UTC)
- I suppose that on a practical level the course tutor could create an article and then speedy-delete it G7 (requested by author) after adding the course banner to the talk page...? PamD 09:40, 3 December 2024 (UTC)
- I wouldn't like to see that done. The expectation is that WikiEd should not be disruptive to the rest of the project, and should work within its normal operations. That includes that if you're drafting an article, someone else may "beat you to it"; that's a normal part of editing and something students who are learning to edit Wikipedia should be expected to deal with. They could always offer ideas for improving the newly-created article instead. Seraphimblade Talk to me 09:41, 3 December 2024 (UTC)
- I didn't see it as disruptive, it wouldn't be an instruction not to create an article, but a nudge that an article was under construction so that it might be a good idea to put ones efforts elsewhere. I'll be interested to see what happens at course end, and I hope the student won't expect to be able to upload their article regardless! I suppose a difference from a normal drafting is that students are forced to work over a matter of months, while normal editors can in most cases work faster. PamD 09:50, 3 December 2024 (UTC)
- Wikipedia:Wiki Ed/University of Mary Washington/Writing and Literacy in the Digital Age (Fall 2024) has a useful scope table. AllyD (talk) 09:50, 3 December 2024 (UTC)
- Yes, that's a standard course dashboard, but only useful if you know to look at it ... ah, just had a thought. Special:WhatLinksHere/Ann_Trevenen_Jenkin includes the Brigham Young course. So, if I remember, my process for starting an article will now include a "What links here" with particular care to look for WikiEd courses. PamD 09:53, 3 December 2024 (UTC)
- I was going to mention "what links here"; I think that's a good idea anyway. Back in 2012 while creating Petite Suite (Debussy), I encountered a similar situation while checking links because there was an articles for creation submission at Wikipedia talk:Articles for creation/Petite Suite (Debussy) (requires admin goggles to view). Nowadays draftspace exists (it was created a year later) and editors do get alerts when there's a draft page at the same title as an article. Graham87 (talk) 14:59, 3 December 2024 (UTC)
- Yes, that's a standard course dashboard, but only useful if you know to look at it ... ah, just had a thought. Special:WhatLinksHere/Ann_Trevenen_Jenkin includes the Brigham Young course. So, if I remember, my process for starting an article will now include a "What links here" with particular care to look for WikiEd courses. PamD 09:53, 3 December 2024 (UTC)
- I wouldn't like to see that done. The expectation is that WikiEd should not be disruptive to the rest of the project, and should work within its normal operations. That includes that if you're drafting an article, someone else may "beat you to it"; that's a normal part of editing and something students who are learning to edit Wikipedia should be expected to deal with. They could always offer ideas for improving the newly-created article instead. Seraphimblade Talk to me 09:41, 3 December 2024 (UTC)
- It happens outside of WikiEd. Early last year I was working on an article on my user sub-page when I realized a new editor was drafting an article on the same topic. In that case, I merged what I had written into their draft. I'm not sure it is worth worrying about such collisions ahead of time. Donald Albury 15:02, 3 December 2024 (UTC)
Population by tribes Guyana and Venezuela
Is there any statistics Population by tribes for Guyana and Venezuela? Kaiyr (talk) 16:02, 4 December 2024 (UTC)
- See Indigenous peoples in Guyana, which has links to articles about tribes, and Indigenous peoples in Venezuela, which has population figures. Donald Albury 17:43, 4 December 2024 (UTC)
LTAs
What research, if any, has been done into the motivations of LTAs? Polygnotus (talk) 20:08, 4 December 2024 (UTC)
- Wikipedia specifically, or more like the kind of person who would do this in general? WhatamIdoing (talk) 00:21, 5 December 2024 (UTC)
- @WhatamIdoing: Wikipedia specifically. The reason I ask is because of User_talk:Polygnotus#808s_&_Heartbreak and then I discovered that someone had tried to have a conversation (at User_talk:MariaJaydHicky2). There are various creative ways to deal with such things, like that conversation or shadowbanning or forcing people to do a boring game for 30 seconds when their edit triggers an editfilter (which would be not too bad for someone who makes one such change a month but terrible for genrewarriors who want to change the genre of an entire catalogue of an artist).
- Or perhaps we could just be less specific when talking about musical genres. I don't even know the difference between synthpop and electropop for example, and very little information would be lost if we simply used x toplevel genres (these are the options in ID3v1, perhaps better to use Eric Kemp's original list of 80 genres).
- I wonder if someone (perhaps but not necessarily the WMF) had ever done any research to discover motivations and commonalities. How does an LTA become an LTA? How does an LTA stay an LTA (what dopamine reward do they get). How can we minimize the chances that they become an LTA and make being an LTA as unrewarding as possible? What can we learn from them (e.g. via an interview or analyzing data)?
- I do, somewhat, understand the motivation of people who just write "poop" or blank a page, just to see if they can. But with LTAs the motivations and origin stories are quite a bit deeper. Polygnotus (talk) 00:29, 5 December 2024 (UTC)
- I'm not aware of any research on LTAs specifically for Wikipedia.
- I believe that there is research on Trolling (e.g., low empathy, anti-social attitudes, Online disinhibition effect, emotional sensation seeking) and on some "one-off" overreactions ("They rejected me, so I will fight them to the death", or at least until something more fun or interesting comes along), but not specific to Wikipedia.
- On Wikipedia, they may not even agree that what they're doing is harmful. We had one LTA many years ago whose main "motivation" was a developmental disability. There was a long string of easily detected socks, but the itch to make the article "right" was apparently irresistible for years. My best guesses about how it stopped are either that the LTA found something else to do all day, or the parents restricted internet access.
- Even getting in touch with Wikipedia's LTAs is difficult, and getting an accurate answer might be impossible. Occasionally we will have information about the person's identity, but even then, you hardly want to call someone and say "Hello, this is Wikipedia. You've got a student/employee/user with this e-mail address. Could you please block them from Wikipedia on your network, and maybe send a note home to their parents or guardians? Thanks." WhatamIdoing (talk) 01:19, 5 December 2024 (UTC)
- I do, somewhat, understand the motivation of people who just write "poop" or blank a page, just to see if they can. But with LTAs the motivations and origin stories are quite a bit deeper. Polygnotus (talk) 00:29, 5 December 2024 (UTC)
- @WhatamIdoing: Thank you. Interesting. Do you think it would be a good area for someone to research? Perhaps someone at the WMF? It looks like the current approach of dealing with LTAs is not very effective, considering they can keep going for years and this one person created hundreds of accounts. I just mentioned a couple ways one could theoretically discourage LTA behaviour, and there are surely many other creative approaches (these were just the first ones that came to mind, and this was the first LTA that showed up on my talkpage). One could use a proof of work approach like Hashcash but with time instead of computational power. To me, it looks like the community could use some help dealing with this problem, and perhaps the WMF is willing to help. Polygnotus (talk) 02:47, 5 December 2024 (UTC)
How do you choose which articles to work on ?
Greetings! My question is the next. How do you choose the articles you want to work on ?
In my case, it's simple. I read articles on topics that interest me and I read the related articles (For example, internal links).
If I don't have time to work on it. I write a note on my user page to work on it later. Anatole-berthe (talk) 01:57, 5 December 2024 (UTC)