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.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Utterly badly sourced business articles
I observed somewhere over a decade ago how Articles for deletion was often approaching People, bands, and businesses for deletion.
This is still true today.
I wonder whether we can relieve some of the pressure on the AFD process, and on volunteers, with a modification of policy.
Consider the likes of Industrial Fasteners Institute (AfD discussion)
It has stood for 12 years (and a few hours!) with its only source ever being the business's own WWW site.
Or there's Imagine Sports (AfD discussion) which has stood for 16 years with two "official web site"s and an "official blog".
Should we encourage a presumption of deletion, or perhaps greater use of the proposed deletion process, for articles on business where they cite no other sources than the business's own direct publications?
We have the proposed deletion of biographies of living people process for biographies with no independent reliable sources, perhaps we need a similar mechanism for utterly badly sourced business articles, where we demand at least something other than company self-published histories and "about" pages.
(I'd agree with the deletion of business articles sourced to nothing other that the business's own publications, and press releases in other publications; but I think that that's another discussion. And similarly, I notice that people are addressing the undisclosed paid editing through other means. That's another discussion, too. It's the plethora of business articles that are basically vehicles for company website links that I think that we could address.)
I'd agree. But it should apply to all articles about anything. Which is better, a badly-sourced article that might or might not be accurate but nobody cares enough to source it, or no article? Does WP:BURDEN not apply to article creation as much as to its content? Maybe we need a WP:NOEXCEPTIONS policy. — Cheers, Steelpillow (Talk) 18:49, 13 November 2023 (UTC)Reply[reply]
Many of the older ones are actually fine, they originated in the days when sourcing was optional but derived from respectable sources such as other encyclopedias. Espresso Addict (talk) 02:33, 14 November 2023 (UTC)Reply[reply]
That claim is currently not verifiable, and the longer the cites stagnate the less tenable it becomes. Again, I draw your attention to WP:BURDEN. — Cheers, Steelpillow (Talk) 07:29, 14 November 2023 (UTC)Reply[reply]
As I've said in various fora of late, if we all just referenced articles instead of wasting breath discussing how to delete them the encyclopedia would be a great deal better served. Espresso Addict (talk) 10:03, 14 November 2023 (UTC)Reply[reply]
Undersourced businesses are already prod staples, I don't think any more encouragement is needed, and there's a big difference between non-profit societies/organisations and for-profit companies. Espresso Addict (talk) 02:33, 14 November 2023 (UTC)Reply[reply]
After the recent changes to WP:NCORP, the standards for for-profit companies are higher than for non-profit bodies such as academic societies – which just have to be national/international in scope & meet GNG – rather than having to meet the new elevated standards for companies. Espresso Addict (talk) 23:36, 14 November 2023 (UTC)Reply[reply]
"nobody cares enough to source it" includes those trying to delete it, in many cases. The "BURDEN" is WP:BEFORE. A lack of sources in an article does not mean there are a lack of sources. Wikipedia itself is not a reliable source for determining if a topic is notable. Many editors don't look beyond Wikipedia. This is a common problem at AfD. -- GreenC 15:07, 14 November 2023 (UTC)Reply[reply]
That sword cuts both ways. Many editors have not gone beyond corporate promotional blurbs when creating articles, and not only is this a problem at AFC this is a worse problem in the encyclopaedia. Vehicles for corporate WWW site links like International Labmate Ltd (AfD discussion), which had even more external links to the company's various WWW sites in its older versions than it has now, are littered throughout the encyclopaedia. Uncle G (talk) 17:29, 14 November 2023 (UTC)Reply[reply]
The most slam-dunk case is articles on businesses. If the above example one went to AFD, it would be an easy fail or if there is advocate for the article they will need to quickly find and add GNG sources. But for those years nobody even questioned it. Sports articles are a lot tougher. Since in sports, coverage itself a form of entertainment (rather than the typical criteria to receive coverage) and has lots of fan clubs in Wikipedia, and whoever takes it to AFD will get beat up for not first searching for the missing sources. Edge case bands always end up as edge cases because there is a lot of edge case coverage situations. (interviews etc.) Finally, the typical mechanics of the Wikipedia system are that WP:Ver is a way to remove content and not directly a criteria for existence of an article. Theoretically, if GNG sources exist that aren't in the article it can be kept. So if it's a sports article with no substantive sources from a place when the media is non-english in a different character set, it's arguable that you need to have someone fluent in the language/character set to search to show no suitable coverage in order to delete it. Bottom line, I don't think that anything that speeds up the simplest cases is going to do much. Sincerely, North8000 (talk) 15:35, 14 November 2023 (UTC)Reply[reply]
This is why I asked specfically about businesses, and about a specifically identifiable set of business articles, at that. This isn't setting out to solve the world's problems, just to address one thing to see whether there's a way to make things incrementally better. And I think that there's a good case to be made that if we already apply the just one reliable independent source criterion to biographies, we can apply it to businesses. Indeed, we already do that and more to business articles at AFC.
So maybe we should close this hole in our standards and require that as a simple uniform minimum across the article namespace too: at least one reliable independent source in the article for a business. We decide that we don't host external linkfarms for corporate WWW sites for 15 years like, say, Forsythe Technology or Nisco Invest.
Nowadays, these wouldn't make it through our excellent if overloaded NPP process. The community might be minded to enact WP:CSD#X4: article about a business, enterprise, or product that was started before 2020 and has never had an independent source?—S MarshallT/C 17:51, 14 November 2023 (UTC)Reply[reply]
If we can't get consensus to speedy new articles like this, then we're unlikely to find it for deleting old ones. —Cryptic 18:05, 14 November 2023 (UTC)Reply[reply]
CSD is really not appropriate, because Wikipedia:Deletion is not cleanup, and therefore there is the potential for it to be legitimately contested. PROD should be sufficient.
That said, I took a look at Industrial Fasteners Institute, mentioned at the top of the thread, and I have two overall thoughts:
Wow, that industry is way more complex and interesting than I'd ever have imagined, and
I can find sources for European Industrial Fasteners Institute (EIFI), which started a trade dispute a little while ago, but not as much about the (US) IFI. But I suspect them of being a case of WP:ITSIMPORTANT in the real world (like: they're actually important, if you care about things like whether a plane is likely to spontaneously disassemble itself while you're inside), and I'd suggest a "merge" (of this one stub plus a half-dozen similar organizations for whom a stub hasn't been created) to a List of fastener industry organizations or Fastener industry, rather than deletion.
I was reminded recently that it's our official policy that more information (NB: information, not separate articles) is better than less. If we make a recommendation, I would like to see us recommend something that results in more knowledge. WhatamIdoing (talk) 18:09, 14 November 2023 (UTC)Reply[reply]
I too looked at the fasteners article and was intrigued. Agree merging would be more useful than deletion.
Unless we want to purge almost all content on companies, a new speedy tag is not the way to go. I don't see why standard prod is not effective for old articles where the creator has retired? Are people mass-removing the prods? (I try to check the prod list from time to time but mostly tend to leave the businesses alone, as it is not an area in which I edit.) Espresso Addict (talk) 23:45, 14 November 2023 (UTC)Reply[reply]
In 1976, the IFI instituted a proceeding over import relief for U.S. fastener manufacturers with the International Trade Comission.[1][2]. It's also necessary to search under its pre-1949 name "The American Institute of Bolt, Nut and Rivet Manufacturers"[3]. There's more out there than people seem to have found so far. Jahaza (talk) 04:44, 28 November 2023 (UTC)Reply[reply]
Can we get a list generated of company articles for which the only external link on the page is the company website? BD2412T 04:02, 10 December 2023 (UTC)Reply[reply]
I imagine that would be tricky as it's not always going to be easy for a bot to identify that given only the article title. A list of articles about companies (presumably identified by presence in a category) that include external links to only a single domain would I guess be easier. There will be false positives in that list (e.g. when the only citations are to the same newspaper), but I suspect it will also be worth examining those articles for issues. There will also be false negatives (e.g. if an article cites megacorp.com and megacorpinternational.co.uk), and no such query will be able to identify when the article cites only regurgitated press releases and similar, however as long as these limitations are understood and presence or absence from the list is not treated as evidence of anything in itself I think the list would still have value. Thryduulf (talk) 12:32, 10 December 2023 (UTC)Reply[reply]
If any article is longstanding but as poorly sourced as you state, I'd at least give them the benefit of a cursory search for RS, then prod it. Wikipedia won't be specially harmed if an ultimately notable business gets removed, as if it's truly notable, it will come back as a new article (or restored deleted article) with proper cites. But as someone who has seen plenty of this kind of junk, my emotional center says to "Prod away!". Stefen Towers among the rest!Gab • Gruntwerk 19:06, 15 December 2023 (UTC)Reply[reply]
I'm doubtful that it's an entirely harmless action (what if someone's looking for that information during the interregnum?), and I'm even more doubtful that it will somehow come back as a new article with more sources.
As a side note, one of the distinctions drawn in the academic literature into whether users trust websites is between "trusting" and "finding useful". A Wikipedia article can be very useful to a reader ("Oh, I thought the account I was just assigned was an agribusiness customer, but it looks like they have a lot more business interests than I thought...") even when they don't really trust it ("...so I should probably check in with the previous account rep before I call them"). WhatamIdoing (talk) 03:12, 17 December 2023 (UTC)Reply[reply]
Since Wikipedia is not a business directory, the lack of an article for a likely non-notable (or barely notable at best) enterprise will be harmless within reason. There's Google and the yellow pages and what-not to cover the rest. We don't have to host it. There's myriad notable subjects we're still missing so I won't lose sleep over prodded business articles. :) Stefen Towers among the rest!Gab • Gruntwerk 04:00, 17 December 2023 (UTC)Reply[reply]
Who says that a poorly sourced article is "likely non-notable (or barely notable at best)"?
I believe that sending readers off to other sites (e.g., with worse privacy policies, or which might be secretly paid advertisements) is not harmless. WhatamIdoing (talk) 04:08, 17 December 2023 (UTC)Reply[reply]
If something has been prodded, the prodder is supposed to have done a cursory search to see if there's hope for a subject being notable. Per AGF, I assume this happens most of the time. Also, the Wikipedia does not exist for being a web searcher's soft landing. I'm not buying into the scope creep. We're just an encyclopedia. Stefen Towers among the rest!Gab • Gruntwerk 04:14, 17 December 2023 (UTC)Reply[reply]
I totally side with encourage a presumption of deletion, not only when the only sources are directly related to the topic but also with articles that are loaded with obscure sources that seem purposely dredged-up to prevent deletion on what would otherwise be a totally non-notable topic. This seems to be a common hallmark of paid-editing. Just, in general, I wish we would be more strict with notability, especially for business-related topics, including questioning if sources are actually notable (eg, WP:CONTEXTMATTERS). Also despite WP:SOURCEACCESS some things like trade publications available only to a limited audience, etc., simply shouldn't count as reliable sources as they weren't generally available to the public as per WP:PUBLISHED. Ultimately, despite all the policy stuff, it needs to boil down to asking ourselves, "Hey, has somebody purposely scraped the bottom of the barrel to get this article to pass our notability standards?" If so, I think we should err on the side of deleting it; otherwise, we just accumulate promotional cruft. Historically, I think we've tended to side with keeping anything that is referenced with too little weight put on the quality of the references. We need a cultural shift that tighten the hatches. Jason Quinn (talk) 15:33, 26 December 2023 (UTC)Reply[reply]
Do the whole bold Oppose. Nobody seems to have explained why Prod isn't enough for me to get behind this. I'd also argue it's a strawman argument, there isn't actually a problem beyond I don't like it that these article are in wikipedia. If they exist and have existed a long time it indicates they are doing something right and that consensus is to keep, as that's how consensus forms and works. If we need to change the rules to exclude them, what does that say about us? And how does it come to define Wikipedia? Don't we have enough articles that require copyediting to be worried about this, the top of my watchlist indicates a drive there? Wouldn't our efforts be better directed there than here? A look at Wikipedia:Backlog tells me over 400,000 articles need more refences. Could we better pressed finding them? I do wonder why I give my valuable time to this project, creating and salvaging, when so many people want to destroy that work. Sometimes I decide I no longer want to because of the negativity. Does that make Wikipedia better? Or should we strive towards consensus. Should we say we're at an even keel as things stand, the guidelines are balanced, in harmony, we know how to use them to achieve the goal, let's kill the backlogs then regroup on discussions such as these if merited? HidingT 19:57, 5 January 2024 (UTC)Reply[reply]
Spongebob Squarepants is now freely licensed!
Gee Spongebob, tell me more.
Wait, really?
Well.. At least Commons seems to think so. Sites like Flickr and YouTube allow their users to set the license for their uploads, offering the option to release one's content with a free license. Which is really awesome! I use it myself. (but I do it on purpose)
Look Squidward, I'm freely licensed!
For some reason, several major entertainment companies are also doing this or used to. For example Nickelodeon, Ubisoft, Bandai Namco, Disney (to be precise, DisneyChannelIsrael) and Microsoft. For short clips of live action series this could be defensible: creating a spin-off from live action footage would be difficult and it doesn't print well on mugs and t-shirts. And a free license might encourage people to make memes using screenshots of that, which is free publicity. But according to at least three Wikimedia Commons administrators (one of them is a crat and CU even!) I can make my own Spongebob webcomic spinoff! (title idea: "Squidward motorboats Bikini Top") I can start selling t-shirts and lunchboxes with Spongebob Squarepants and Squidward now! (as long as I provide attribution. I'll print that on the bottom of the lunchbox) Imma be RICH!!
Shall we get back to earth now? In videos that include non-live action characters from companies whose business model is to sell licenses, that CC-BY license is an accident. Why these clips are freely licensed? Maybe some SEO idiot determined it makes the YouTube algorithm 0.1% happier. Maybe an intern thought that any creative work needs to be marked as "creative commons". Maybe it's a bug in some upload script. Who cares?
Here are the important questions: 1. Is this license enforceable? If I do start selling Spongebob-branded lunchboxes and scuba gear, will this license hold up in court? My best guess? Yes and no, because it'll never go to trial. Nickelodeon would start with a simple cease and desist. If I'd ignore that, they would make me settle, no matter the cost. It's irrelevant how solid of a case they might be able to build - even a 1% chance they would lose would be FAR to costly. They would rather give me a free license to sell my lunchboxes and a million dollars cash to sweeten the deal. Nobody wants that to go to trial. Literally nobody, because it would be bad for free culture as well. If Nickelodeon wins, it may undermine the validity of Creative Commons licenses. If Nickelodeon loses, the stock price for at least Nickelodeon and Disney will take a nosedive and the headlines will read "Wikipedia stole Spongebob". Does that sound like good publicity? Even the monkey selfie had some negative impact in that regard, but in that case the precedent it would've set otherwise was an unacceptable risk. Now imagine the negative impact of the monkey selfie, times a billion.
2. Do these files endanger our re-users? Well, yeah, I think they do..
If Commons is declaring Spongebob to be freely licensed and two clicks away from declaring a few dozen Disney characters to be freely licensed (Big Hero 6, Ducktales 2017, Star vs. the Forces of Evil, Mickey Mouse and Donald Duck, Milo Murphy's Law).. We can't tell Commons what to do. "Freely licensed" images of characters that are owned by multinationals based solely on the license setting on Flickr or YouTube is silly. It might be up to us to not allow them to be embedded here to protect re-users. How we would technically achieve that, or how we would word such policy? I don't know yet. Or we need to find another solution.
— Alexis Jazz (talk or ping me) 17:55, 22 November 2023 (UTC)Reply[reply]
Ask George Romero if he ever got Night of the Living Dead back out of the public domain after it was accidentally released in cinemas for a few years without a copyright licence.... (Ironically you would need to raise him as a zombie to ask, but there we go.) Historically even accidental copyright releases are held to that. So commons wouldnt be incorrect in saying *for the moment* that anything released on a free licence is *free*. Because there is a lot of previous cases that absolutely support that. Of course the other side is, dont mess with the mouse. Only in death does duty end (talk) 18:11, 22 November 2023 (UTC)Reply[reply]
Only in death, true, true, Debbie Does Dallas is also public domain. But those are older US cases of failing to include a copyright notice, which was literally required by law at the time. A Creative Commons license on Flickr or YouTube is uncharted territory, and I honestly doubt it'll generally hold up unless the companies were clearly aware of what they did. If they put out a press release to say "we're releasing a bunch of stuff with a free license!", sure, but that's not the case. — Alexis Jazz (talk or ping me) 18:44, 22 November 2023 (UTC)Reply[reply]
As to how we could technically achieve it, MediaWiki:Bad image list. Or we could go fully nuclear and overwrite the files locally with blank images and protect, so you can't get to the images on the en.wikipedia.org domain at all. —Cryptic 18:18, 22 November 2023 (UTC)Reply[reply]
Note: the latter requires the reupload-shared right which only administrators have. — Alexis Jazz (talk or ping me) 09:13, 24 November 2023 (UTC)Reply[reply]
You need to be an admin to protect them, too. Or edit the mediawiki namespace, for that matter. —Cryptic 09:54, 24 November 2023 (UTC)Reply[reply]
While I agree the liberal interpretation of Commons rules means we can host these, it's worth having a more in depth discussion for the sake of our re-users. That discussion shouldn't be here, though; it should be on Commons, which is where they're hosted. — Rhododendritestalk \\ 21:15, 22 November 2023 (UTC)Reply[reply]
Rhododendrites, that'd be ideal, but that discussion so far is what resulted in the undeletion of Spongebob. And I generally avoid Commons as it seems to be bad for my health. It's not without precedent to locally disallow some images from Commons. For example, files with {{c:Template:PD-US-no notice}} are not allowed in articles on the German Wikipedia. — Alexis Jazz (talk or ping me) 09:49, 23 November 2023 (UTC)Reply[reply]
Commons has almost certainly screwed up, and the WMF lawyers should probably check in. We had a very similar situation where some subsidiaries of Ubisoft uploaded some gameplay trailers for their games and the like with permissive licensing turned on, but it was investigated, and of course it was just a mistake of the uploaders and not really releasing all this into the public domain (see c:Commons:Deletion requests/Template:Attribution-Ubisoft 3, which redirected the template to Copyvio). Some random social media consultant getting paid 30K a year clicking the wrong settings on a YouTube upload doesn't mean it's actually free, in the same way that getting a clerk at the convenience store to give you permission to use the store's name & logo yourself doesn't mean much. In the deeply unlikely situation of SpongeBob being released under a permissive license, it needs to come from, like, the general counsel of Nickolodeon, not from NickRewind's YouTube guy. (And hell, even if the video is really freely licensed, that doesn't mean everything in it is - if I take a freely licensed photograph with SpongeBob in the background, that doesn't free SpongeBob.) SnowFire (talk) 06:27, 24 November 2023 (UTC)Reply[reply]
That linked discussion does not seem all that similar to me. Yes, there were a few people arguing that a signed and notarized statement from the executive board would be required for a valid license release. But ultimately the decision there turned on whether the somewhat vague discussion of terms reflected a license that was sufficiently free or not, particularly with respect to one point where the company representative stated that they were reserving the right to "revoke" the license grant with respect to any particular use they didn't like. In this case there's no ambiguity on that point as the release here is explicitly CC-BY. Anomie⚔ 14:45, 24 November 2023 (UTC)Reply[reply]
Why? That's not how CC licensing works – with the exception of ND licenses (not used here), which don't allow derivatives, the license does of course also apply to shorter excerpts, stills, and details of stills. "Elements in this image are protected by copyright" would only be the case if these elements belong to a different rightsholder who didn't allow their relicensing, but of this we have no evidence here. Gawaon (talk) 17:20, 24 November 2023 (UTC)Reply[reply]
@Gawaon: That isn't really accurate, though. This is the most obvious with "freedom of panorama" issues. It is totally fine to release into the public domain a picture of, say, someone in the kitchen under cc-by. If you crop it to just the part of the image that's the Coca-Cola can, sorry, Coke's images aren't suddenly CC now. It would be ridiculous if a video that involved random SpongeBob stills from some random fan or other party didn't mysteriously release SpongeBob himself into CC, but the same exact video if released by a Nickelodeon affiliate was assumed to do so because the top-level of Nick owns SpongeBob. SnowFire (talk) 20:14, 24 November 2023 (UTC)Reply[reply]
Sure, but if Coca-Cola releases Coke can images under CC, then that Coke can images are CC-licensed. And that's what's really the case here, right? We're talking about a release by the rightsholder (in so far as we can tell), not by some random third person who doesn't have the rights to SpongeBob in the first place and so cannot give them away. Gawaon (talk) 20:47, 24 November 2023 (UTC)Reply[reply]
@Gawaon: The whole point is that the rightsholder almost certainly did not release this into the public domain a free license, by basic common sense. It's just a clerical error. I've cited two cases above where there was believed to be a surprising, major release into CC and it turned out it was just a mistake in video settings. It is incredibly unlikely this was intended to be a stealth release into the public domain a free license. Are you arguing that, if you found yourself mysteriously teleported into a conversation with Nick's general counsel, they'd say that yes, they really meant to release SpongeBob? Or is the claim that it doesn't matter what the counsel says, if one social media intern says otherwise it's too late no take backs? SnowFire (talk) 23:00, 24 November 2023 (UTC)Reply[reply]
As JohnCWiesenthal pointed out farther below, NickRewind has been publishing CC-licensed videos for years, so a clerical error seems unlikely. If it was an error, they would have noticed it long ago. And CC is not "the public domain" – some rights (such as attribution) still apply. Gawaon (talk) 23:17, 24 November 2023 (UTC)Reply[reply]
I don't find that one terribly useful either. The question about whether Bandai Namco actually had the rights to release various pieces of content as CC-BY in the first place seems a good one (but not relevant here), but appears to have not gone anywhere. Instead an "a signed and notarized statement from the executive board would be required" type attitude won out. Anomie⚔ 14:14, 25 November 2023 (UTC)Reply[reply]
(de-indent) @Gawaon: I'm very familiar with the difference, was just speaking generally and the difference isn't that important here. The CC setting being there for years just means that... the setting has been wrong for years, no different than finding a Wkipedia article that's been wrong for years, which happens all the time. Or that the release was strictly the video parts like interviews and not the brief flashes of copyrighted characters. Okay, so you're saying that Nickolodeon really actually intended to release SpongeBob into CC? That if you called up the Nick CEO and counsel they'd agree with "yes, that's the plan, anyone can go make SpongeBob derivative stuff, go nuts"? That's the question very specifically I'm raising and you're not answering: do you really think that this was truly intentional at the highest levels of the company? Like, if you had to place money on a bet, say? (Because if we don't have that level of intentionality, it shouldn't be on Commons.) SnowFire (talk) 00:57, 25 November 2023 (UTC)Reply[reply]
> Because if we don't have that level of intentionality, it shouldn't be on Commons.
As you note, this is really a Commons debate, and not a Wikipedia one (and so should be had there).
Anyway, this is a dangerous and unworkable standard. The principle is to raise the standard of evidence for a valid license — and in practice open the door for license revocation, which CC licenses are specifically designed to avoid. A license grant does not need to be "truly intentional at the highest level of the company" in order to be valid. D. Benjamin Miller (talk) 08:24, 25 November 2023 (UTC)Reply[reply]
No, you cannot use characters from SpongeBob SquarePants on your own merchandise, because they are protected by trademark law. The same goes for Mickey Mouse even after he goes into the public domain next year.
CC BY specifically grants a license for adaptations. Disney can only protect Mickey Mouse with a trademark because they haven't also granted everyone under the sun a license to do what they like with him. This is a very different thing from simply going into public domain because the copyright term expired. MrOllie (talk) 15:46, 24 November 2023 (UTC)Reply[reply]
I don't think we (or Commons) have much to worry about licensing issues here. Nickelodeon is very likely the rightsholder of that series (as it's produced for them), so if one of their official Youtube channels applies a CC license to that stuff, that should be valid. A licensing decision can't be "undone" later, even if the rightsholder should later feel regret (of which we see no signs here, as far as I can tell). Gawaon (talk) 17:14, 24 November 2023 (UTC)Reply[reply]
JohnCWiesenthal, Applying a CC license to your trademarks and logos could even result in a loss of your trademark rights altogether. The same goes for Mickey Mouse even after he goes into the public domain next year. Well it'll be interesting to see what will happen exactly. Did you really think Disney wasted loads of money on the Mickey Mouse Protection Act to protect Steamboat effing Willie if trademarks were guaranteed to be sufficient? I kinda think that if I created a webcomic with a mouse based on the looks of Mickey in Steamboat Willie and I don't call that character Mickey Mouse (maybe.. Lickey Louse), I just might be in the clear. Why on earth anyone would even want to do this is another question, that version of Mickey isn't particularly appealing. — Alexis Jazz (talk or ping me) 17:27, 24 November 2023 (UTC)Reply[reply]
For what it's worth, the first Mickey Mouse cartoons will enter the public domain in the US on January 1, though that's neither here nor there. D. Benjamin Miller (talk) 18:06, 24 November 2023 (UTC)Reply[reply]
Unlike the Ubisoft case, the terms of the license here are not unclear. CC-BY 3.0 is a perfectly acceptable license — that much isn't in dispute. The assertion isn't that the form of license is bad, but that it wasn't validly applied to the content. There are, as far as I can tell, two main grounds on which this would be argued:
The person who purported to release the content wasn't the copyright holder and so had no legal authority to do so.
A large corporation couldn't have meant it!
Case 1 is fairly common — it's what's behind all examples of Flickr laundering, for instance. If I interviewed Tom Kenny, that would be perfectly fine, and I could CC-license my pictures or video of him, but if, during my interview, I showed some copyrighted pictures whose rights belong to someone else (and which aren't covered by a free license), then those pictures wouldn't be freely licensed, of course, even though my video of Tom Kenny would be. Arguably, some of these cases might involve channels not in fact operated under authority of the copyright holder, where the channel operator has surpassed the terms of the license.
As far as we understand, the Nick Rewind channel isn't such an example — which takes us to Case 2. It's a channel which is operated by Nickelodeon. Some of the videos on the channel are CC-marked (and some aren't). The CC-BY 3.0 license is free and irrevocable — if it's validly been granted, then it can't be taken back. The fact that CC-BY 3.0 is explicitly marked on these videos put out on Nickelodeon's official channel would be strongly in the reuser's favor in a lawsuit. I know that some large corporations are reputedly abusive about copyright, but if they themselves give explicit permission (which is what CC-BY is), and it is verifiably their channel (it is), then they cannot sue you on the theory that this didn't count. They are, after all, responsible for their representations of the license status they attach to their work.
As others have mentioned, this really has to do with what media are acceptable on Commons. If you don't want to get involved in discussions on Commons, OK. But Commons and Wikipedia are both WMF, so if it's really about legalities, then the question is the same whether here or on Commons.
In any case, banning certain Commons images from enwiki is a terrible idea (especially on the basis of such a shaky rule as given above). The German Wikipedia's basis for doing so is that they only accept images that are PD in DACH countries (even though Wikipedia is hosted in the US). Whether or not that should be their policy is a question for the editors there, but it at least has a fair principle behind it and applies to general classes of file. The principle here is far more dubious, not based on a legal distinction (only on the assumption that you cannot win over the community on Commons, rather than different rules being applicable) and hard to maintain (as it would apply to individual files). D. Benjamin Miller (talk) 18:40, 24 November 2023 (UTC)Reply[reply]
Oh, and it seems absurd and backwards to say that files allowed on Commons (due to CC-BY licensing) should be disallowed on Wikipedia in an instance where they are actually equivalent to a claimed fair use file on Wikipedia. The basis of our decisions isn't whether or not a lawsuit would occur — we are actually more principled than that; other sites regularly reuse images with impunity and virtually never get sued (and WP:NFCC is stricter than what fair use would allow). The purely hypothetical lawsuits you gave involve people making scandalous derivative works. Even putting aside whether or not such suits would happen and what the results would be, that discussion certainly belongs on Commons (which is a repository for reusers) and not Wikipedia. D. Benjamin Miller (talk) 18:46, 24 November 2023 (UTC)Reply[reply]
Oh, and it seems absurd and backwards to say that files allowed on Commons (due to CC-BY licensing) should be disallowed on Wikipedia in an instance where they are actually equivalent to a claimed fair use file on Wikipedia.
Like, why should those clips be allowed on the French Wikipedia but not here? JohnCWiesenthal (talk) 20:58, 25 December 2023 (UTC)Reply[reply]
As far as we understand, the Nick Rewind channel isn't such an example. Are we sure? Does the Nick Rewind channel hold the copyright to Spongebob Squarepants? Nick Rewind may be able to eventually trace it's corporate ownership up to Viacom International Inc., same as Spongebob, but that doesn't mean that Nick Rewind is the rightsholder. --Ahecht (TALK PAGE) 22:13, 6 December 2023 (UTC)Reply[reply]
It seems fairly irrelevant at this point. Legal has contacted Nickelodeon for clarification, so we can simply stand by and wait what will happen. Gawaon (talk) 23:04, 6 December 2023 (UTC)Reply[reply]
Just blacklist all Commons files that are claimed to be free images. We are not responsible for Commons screwups. Black Kite (talk) 18:50, 24 November 2023 (UTC)Reply[reply]
Does this mean that all songs on her eponymous debut album are free to use by anyone? No, the license in theory should apply only to those five excerpts. --JohnCWiesenthal (talk) 18:52, 24 November 2023 (UTC)Reply[reply]
Of course any license only applies to the works that were released under it. That much is not in dispute. Gawaon (talk) 19:45, 24 November 2023 (UTC)Reply[reply]
Has anyone tried contacting Nickelodeon/Disney's legal department to see what they think? Galobtter (talk) 23:27, 24 November 2023 (UTC)Reply[reply]
I'm with D. Benjamin Miller on this one. A free work is a free work, CC licences are irrevocable, and it's not our job to audit the internal procedures of media companies. I don't think protecting our reüsers from frivolous litigation is a good argument, either, as that in this case would mean promoting intellectual property even beyond what the IP owners claim. -- Maddy from Celeste (WAVEDASH) 15:52, 26 November 2023 (UTC)Reply[reply]
@Alexis Jazz: this is the best village pump initial post I have ever seen. 10/10, no notes.I have emailed Legal with a request they share their perspective on this issue. I personally think it is highly unlikely whoever clicked the "CC BY" button on YouTube had the legal authority to do so, but I would love to be wrong.HouseBlastertalk 03:20, 27 November 2023 (UTC)Reply[reply]
HouseBlaster, glad you liked it! Legal most probably won't respond, and they might be slightly annoyed you contacted them as this might give them "actual knowledge". I considered posting this on Jimbo's talk page, maybe I should have just done it, I don't know, maybe consider it if this kind of thing happens again. What I had drafted was a section titled "Spongebob Squarepants Spongebob Squarepants" with something like "Hey Jimbo, there's discussion on WP:VPP that, to be honest, we don't really need specifically your opinion on. So this thread is kinda pointless, I realize that. Unrelated fun fact: when Legal is made aware of copyright issues, that knowledge may legally require them to act, which can possibly annoy them. Also unrelated fun fact: you are not expected nor have a legal obligation to read the nonsense random users write on your talk page. Good day sir." Also! Legal won't take Spongebob down because there's a legitimate fair use defense. No, there's no fair use template on Commons, but that doesn't matter legally. Templates are opinions, not legal statements. Quotes from Jrogers (WMF): "I do think the BP Helios logo is creative enough for copyright protection" ""That said, I think the 1 o'clock image is hosted as a fair use". (in reference to a file hosted on Commons with a PD-textlogo template) — Alexis Jazz (talk or ping me) 07:04, 27 November 2023 (UTC)Reply[reply]
While the original videos may be marked in a free license, it is obviously clear that the free license suddenly doesn't translate to make all content of the videos free. We have had this issue with Voice of America videos before, which generally are released under a free license but include photos and short videos that are clearly not free.
Also, the recent copyright office ruling related to the character of Sherlock Holmes being distinct from the stories that feature him also applies (and as many people will likely discover next year when Steamboat Willie falls into the public domain) It is 100% clear that Spongebob is a copyrighted character well into the latter half of this century; the appearance in a freely-licensed video does not magically make it free. Masem (t) 04:05, 27 November 2023 (UTC)Reply[reply]
Unlike Voice of America which occasionally uses licensed clips from sources such as the Associated Press, NickRewind's Nickelodeon clips should not be considered as "licensed" as NickRewind is owned by Nickelodeon. Also, some of NickRewind's CC-BY videos, such as episode clips, consist purely of material from previous series. --JohnCWiesenthal (talk) 05:13, 27 November 2023 (UTC)Reply[reply]
JohnCWiesenthal, there's no guarantee the license setting was even a conscious act. If the license setting is the result of a software bug, an intern who doesn't know what they're doing or a rogue employee, that's most probably (I have no knowledge of this having ever been litigated) not enforceable. If it were enforceable, random interns would be operating under a risk that's uninsurable. Even if it were fully intentional, the IP should be legally isolated to prevent rogue copyright transfers or permissive licensing without signatures from higher-ups and/or lawyers. Within the company, higher-ups can probably sublicense the IP to Nick's subsidiaries, but that sublicense wouldn't itself be sublicensable and may carry additional restrictions. The only legal effect a social media copyright setting might have is that Nickelodeon will have a harder time suing people who use it for damages. That doesn't mean the license will hold up (you'd still have to take your use down or obtain an actual license), and it's far from guaranteed. One may need to plead insanity 🤪 to convince the judge they really believed this license to be legit. To be clear, I'm not saying you are insane, I'm only suggesting someone who starts printing Spongebob lunchboxes and manages to become the defendant in a criminal case may need to claim legal insanity to be found not guilty. — Alexis Jazz (talk or ping me) 07:52, 27 November 2023 (UTC)Reply[reply]
Don't forget that there are still trademarks involved here too. Everybody can use all of Wikipedia's content and even set up their own wikiclone, but they aren't allowed to name that wikiclone "Wikipedia" – that's a trademark issue, and our trademarks are not free. Similarly everybody is now allowed to print that Spongebob image at the top of this thread on a T-shirt or lunchbox and sell it – and I am confident that they would get away with that in court, if they should be challenged – but that doesn't mean they have the right to advertise it as Spongebob Squarepants merchandise. For that they would still need to get additional permission from Nick's legal department, which they very likely wouldn't get. Gawaon (talk) 09:01, 27 November 2023 (UTC)Reply[reply]
Creative Commons licenses don't deal with trademark in any way. You can verify this by reading the text of a CC license, or, in fact, that of the page to which you link: "Yes, you may offer material under a Creative Commons license that includes a trademark indicating the source of the work without affecting rights in the trademark, because trademark rights are not licensed by the CC licenses. However, applying the CC license may create an implied license to use the trademark in connection with the licensed material, although not in ways that require permission under trademark law." D. Benjamin Miller (talk) 20:14, 27 November 2023 (UTC)Reply[reply]
While you've presented a wonderfully baroque scheme which you say we must presume exists, the implied facts here are quite different from those on the ground.
If we were discussing a license tag that was removed after ten minutes on a single video, then perhaps your theory would be more justifiable. In this case, we are talking about a license tag applied to most videos for multiple years, on a channel that is verifably owned by the copyright holder. Nickelodeon, through this channel, distributes the videos under this explicit public license. While it could at any time cease to do so (though this wouldn't affect the validity of the license for existing recipients and further downstream recipients), it never has.
Reliance on the notices attached to those videos can hardly be the province of the insane. The level of skepticism demanded here is considerably higher than that of a reasonable person, and I'm fairly sure that a court would agree. Allowing for a corporation to attach a license to its copyrighted content for years and then act as though it never did would be disastrous as a matter of public policy. D. Benjamin Miller (talk) 20:52, 27 November 2023 (UTC)Reply[reply]
@Masem:Also, the recent copyright office ruling related to the character of Sherlock Holmes being distinct from the stories that feature him Can you provide a link? Is this something more recent than Klinger v. Conan Doyle Estate, Ltd.? Anomie⚔ 13:08, 27 November 2023 (UTC)Reply[reply]
My bad, that case is what I was thinking of and its repercussions (eg the Enola Holmes films for exampke) Masem (t) 14:43, 27 November 2023 (UTC)Reply[reply]
Creative Commons Attribution 3.0 != public domain, to be clear.
As for Sherlock Holmes: yes, that comparison is relevant. But the cases are a bit reversed from one another. In the Sherlock Holmes case, the vast majority of Arthur Conan Doyle's Sherlock Holmes stories were in the public domain, while a few were still in copyright at that time. The Arthur Conan Doyle heirs were arguing that Sherlock was only truly complete once all the stories were finished, and that thus any use of the character would infeinge on the last stories that completed his development. This was (sensibly) rejected.
The SpongeBob case involves a relatively small amount of material from the original series, and that material is under license, rather than being in the public domain (although I'll grant that the license is fairly liberal). The vast majority of SpongeBob content would have to be avoided as a basis for an adaptation on the grounds that it isn't licensed.
More broadly, this all ties into an issue often elided in discussions of copyright in characters, which is the relationship between copyright in works of authorship and in constituent elements, including characters developed in those works. D. Benjamin Miller (talk) 20:29, 27 November 2023 (UTC)Reply[reply]
In my opinion, all such SpongeBob uploads need to be immediately speedy-deleted as copyright violations and such uploaders trout-slapped. (I've noticed that the person who uploaded the SpongeBob image above, for example, has used a similar rationale to upload a video containing iCarly's theme song, which is currently undergoing a deletion discussion, as well as an image of the Annoying Orange.) You don't get to silently put SpongeBob under a free license after years of taking down YouTube Poops based on SpongeBob episodes, despite them having a very strong fair use argument. Also note that Google's explanation of the license, visible under every YouTube upload licensed as CC-BY, does not mention commercial use, nor does YouTube, unlike Flickr, allow the use of CC licenses other than CC-BY. I'm also unsure as to what Stephen Hillenburg's estate makes of this...
That said, does anyone know where I can find contact information for Nickelodeon or Paramount's legal department? I think contacting them might be the best way out of this mess. -BRAINULATOR9 (TALK) 21:44, 28 November 2023 (UTC)Reply[reply]
You do realize that these videos have been CC-licensed by NickRewind's own official Youtube channel, right? Gawaon (talk) 22:05, 28 November 2023 (UTC)Reply[reply]
You and D. Benjamin Miller keep repeating this as if it isn't already understood. Again, it does not matter if a random clerk paid 30K a year at Big MegaCompanyX signs a document saying that the company's IP is free to use, or that they accept all financial liability for some Corporate Scandal, or that the company will contribute a million dollars to the WMF. Something that surprising and far-reaching needs to come with confirmation from higher up the chain, say a press release from Nickolodeon announcing they're releasing SpongeBob into Creative Commons. If this wasn't true, that any random disgruntled employee on their last day could just randomly donate all the IPs owned by the company into the public domain, no take-backs. Also, this would never get in front of a judge, but if it somehow did, judges are not, like, robots. They assess the full circumstances. That judge is going to ask "did you really think SpongeBob was intentionally released under a permissive license, and the notification of this was a setting on a YouTube video? And that you didn't need to check with Nickelodeon to make sure?" If your answer is "yes", then the judge is going to get mad at you.
Anyway there's a very simple way forward: get confirmation from Nick on whether everything is CC (deeply unlikely), the video-as-a-whole is CC but not the brief copyrighted stills (in the same way as a home video with SpongeBob in the background doesn't mysteriously release him into the public domain), or the whole creative commons video setting was wrong. If the people who want to keep the images can't be bothered to do that, the extracted images should be deleted. SnowFire (talk) 22:33, 28 November 2023 (UTC)Reply[reply]
Yes, but it looks to be little more than a default setting that some barnacle head set years ago and no one ever caught or paid attention to. -BRAINULATOR9 (TALK) 22:48, 28 November 2023 (UTC)Reply[reply]
So that deletion request closed as keep. Ugh. -BRAINULATOR9 (TALK) 01:27, 20 December 2023 (UTC)Reply[reply]
You don't get to silently put SpongeBob under a free license after years of taking down YouTube Poops based on SpongeBob episodes, despite them having a very strong fair use argument.
People have been saying the same about music from the Beatles for years, only for them to upload their entire discography all at once on June 17, 2018.
What I'm saying is that there can be instances of even the most unlikely license holders turning on a dime like this. JohnCWiesenthal (talk) 01:50, 20 December 2023 (UTC)Reply[reply]
Upload them where? And under what license? The samples on the Beatles article are all marked non-free. -BRAINULATOR9 (TALK) 02:16, 20 December 2023 (UTC)Reply[reply]
I never said anything about a different license. I'm just noting that the Beatles' core catalog, The Beatles Anthology albums, 1, 1962–1966, 1967–1970 and Love – among others – were all uploaded to YouTube on that date simultaneously, after years of their music effectively being banned from YouTube. JohnCWiesenthal (talk) 02:49, 20 December 2023 (UTC)Reply[reply]
That's still an apples to oranges comparison. The Beatles did not license their music as CC-BY when they uploaded their music to YouTube. -BRAINULATOR9 (TALK) 03:42, 20 December 2023 (UTC)Reply[reply]
My point is that what can be considered the status quo (the takedowns of Viacom clips and Beatles excerpts) can change in an instant. Just because something has always been the case doesn't necessarily mean that it will remain as such. JohnCWiesenthal (talk) 03:52, 20 December 2023 (UTC)Reply[reply]
However, a CC license is not just a "status quo", but a legally binding instrument, on which the rightsholder cannot have second thoughts – certainly not after years. This is getting fairly ridiculous. Legal has contacted Nickolodeon, let's see if and when they hear back from then. Until then there is nothing more to do or discuss in this regard. Gawaon (talk) 07:10, 20 December 2023 (UTC)Reply[reply]
This is a long read but honestly there's more smoke than fire here... Its not our problem and while I respect the high minded hypotheticals its not an issue until its an issue. Horse Eye's Back (talk) 22:38, 28 November 2023 (UTC)Reply[reply]
Strong agree. Zero reason to think any litigation will arise. Mach61 (talk) 03:05, 29 November 2023 (UTC)Reply[reply]
But see c:COM:PCP, which does not allow us to keep files on the basis that we can get away with it. -BRAINULATOR9 (TALK) 22:27, 29 November 2023 (UTC)Reply[reply]
Horse Eye's Back, if you find a bear in your backyard, do you say "it's not an issue until it's an issue" or call animal control? Do you insist we must wait for some poor soul to actually get sued into bankruptcy? Mach61, the only way you can make that argument is if you believe nobody will be stupid enough to commercially exploit this "license" because they understand it won't hold up in court. In that case, why accept images without a valid license to be embedded on Wikipedia in the first place? — Alexis Jazz (talk or ping me) 11:26, 29 November 2023 (UTC)Reply[reply]
Apparently you don't live in an area with bears... If I called animal control and told them a bear was in my backyard they would ask whether it was causing damage or being a threat to people... If the answer to both was no they would ask me not to call again until the answer was yes. If I continued to call animal control every time I found a bear in my backyard I would eventually be charged with a misdemeanor for abusing 911. Horse Eye's Back (talk) 15:19, 29 November 2023 (UTC)Reply[reply]
Fine, let's say our concern is solely for the "little guy", not "corporate asshats." Consider the following scenario. A different image is uploaded to Commons under a free license, but in truth, it's been Flickr-washed in a non-obvious way, and was really copyrighted. The innocent citizen who used that image in good faith for their book or whatever is given a scary demand letter by a corporate lawyer asking for big money. Our hapless reuser talks to his own lawyer about the odds if the case somehow went to trial. His lawyer says that his case may look better if trusting Commons licenses is seen as rational and an unavoidable, innocent mistake. The corporate lawyers' job is to show that trusting Commons licenses is stupid. What's exhibit A that a Commons license claim is worthless? That a blatant copyright infringement was hosted and explicitly given a thumbs-up by the Commons administrators. Now our little guy's case is worse, and he may have to settle on worse terms than if otherwise. SnowFire (talk) 22:19, 29 November 2023 (UTC)Reply[reply]
The words "in an non-obvious way" are doing a lot of work here, to the point where this principle would require us to discard basically all material posted online. After all, who's to say that Bob really took the photos he uploaded as his own work on Flickr, and that they weren't actually taken by his buddy Jeff and uploaded without Jeff's permission? Followed to its logical conclusion, this would require us to reject virtually every image that was not in the public domain due to term expiration or released by a governmental body.
And this is not a trusting-Commons scenario. After all, we link back to an original source, which is Nick's YouTube channel, which has a "verified" badge on YouTube and where you'll find the license that Commons indicates. The question is whether or not the user can trust that a verified Nickelodeon channel on YouTube's license tag is actually valid, not whether or not all Commons tags are necessarily always right. D. Benjamin Miller (talk) 22:54, 29 November 2023 (UTC)Reply[reply]
You didn't understand the scenario I described. I'm talking about some unknown, really-copyrighted other image (i.e. not SpongeBob) hosted in good faith (of which I guarantee there are at least some of such images on Commons because it's impossible to be perfect with a free upload form for users). We can't preemptively discard these cases even if we wanted to because it's not even clear that the licenses are wrong. Our hypothetical image - call it image C - looks like it's free use, but we don't know that it's really copyrighted in this scenario until the copyright holder sends the demand letter off, which is a thing that can and does happen. If it looks like Commons takes copyright infringement seriously, then things look better for innocents trusting it then if it looks like Commons is run by people who confuse wishes with legal reality.
Going back to SpongeBob and if it's really copyrighted, did you read Alexis Jazz's initial post? Do you think you personally are ready to take the plunge and go legally sell some SpongeBob-themed merchandise without talking with Nickelodeon first? If not, why are you willing to tell others that they can do so? (And if you do genuinely well and truly believe that the YT license setting means that the doors have been opened and you can go get rich selling SpongeBob merch, please, please talk with a lawyer first.) SnowFire (talk) 23:46, 29 November 2023 (UTC)Reply[reply]
It's not really relevant, because the user is not expected to trust Commons. Anyone whose argument in court is that the license must be valid because it was listed that was on Commons is foolish, because the argument that the license was given on what Nickelodeon publicly identifies as one of its official YouTube channels is much stronger.
I'm not interested in selling merchandise. If I were, I'd be more interested in the trademark implications, not the copyright ones. Actually, that is an interesting legal question — the trademarkability of characters and their likenesses — but that's a different matter.
If you're asking me whether or not I think the CC copyright license is valid, I'll still say yes. D. Benjamin Miller (talk) 00:13, 30 November 2023 (UTC)Reply[reply]
I can't comment on Nickelodeon's enforcement policy but, in general, I would not attempt to exploit a borderline-protected image even if a loophole permitted it. If I did, I would expect the owner's lawyers to pursue the matter until my life savings had been drained into my lawyers' coffers, at which point I'd lose the case, guilty or not. In practice, litigation can be determined by who is better funded rather than who is right, and rights holders' pockets are generally much deeper than mine. This seems particularly true for cases brought in the U.S. As you have probably guessed by now, I am not a lawyer. Certes (talk) 09:35, 30 November 2023 (UTC)Reply[reply]
This type of thinking (at least, before WMF legal was brought in) is what made the National Portrait Galley and the monkey selfie bigger issues than they needed to be for WP. We must as editors be proactive on removing questionable copyright problems until cleared by WMF that they will vouch for them. Masem (t) 15:27, 29 November 2023 (UTC)Reply[reply]
The difference between you and I is that apparently I don't consider those big issues, those were extremely minor issues. Why do we need to waste editor time to satisfy corporate asshats when we pay perfectly good lawyers to do that? The downside here is so small as to basically not exist, worst case scenario we have to fundraise a few million. I'm happy to waste editor time on something we know is an issue, but not because some editor legal eagle did some OR and thinks we might be in jeopardy. Horse Eye's Back (talk) 15:44, 29 November 2023 (UTC)Reply[reply]
It may be worth mentioning that both of those cases involved mainly questions of law, not of fact. In the NPG case, the question is really (to some extent) one of UK law, but (even beyond that) whether or not the (US-based) WMF would decide to apply US law rather than deal with UK law (since Corel is unambiguous). The monkey selfie case, too, was really just a matter of law (whether or not a monkey's selfie can have authorship for copyright purposes). Here, we are dealing with much more of a question of fact (whether or not the license was granted by the actual copyright holder) than one of law, although the question of what might constitute such a grant is to some extent one of law.
And, importantly, in both those cases there was no problem and the content was in the public domain. D. Benjamin Miller (talk) 22:41, 29 November 2023 (UTC)Reply[reply]
I am concerned about the imprecision in some of the comments here. It appears that Nickelodeon has licensed this a small number of specific images. That is not equivalent to releasing the copyrights on the characters as a whole or the entire series. The entire SpongeBob SquarePants (franchise) is not "a work" in terms of copyright law. AIUI each of the two images at the top of this thread would qualify as "a work". You can license one work without licensing all of them. WhatamIdoing (talk) 02:32, 30 November 2023 (UTC)Reply[reply]
Then what exactly does that make any of NickRewind's other uploads where they post various clips of past Nickelodeon shows like iCarly and Victorious? If the CC-BY license is correct, I could very much bundle them all onto a DVD and sell those. -BRAINULATOR9 (TALK) 03:47, 30 November 2023 (UTC)Reply[reply]
I'm primarily concerned with the gap between "These specific, individual works are freely licensed" and "All of Spongebob Squarepants is now freely licensed". WhatamIdoing (talk) 05:01, 30 November 2023 (UTC)Reply[reply]
WhatamIdoing, if it matters, the clip they were extracted from contains many more bits of footage as well as voiced lines. — Alexis Jazz (talk or ping me) 10:47, 30 November 2023 (UTC)Reply[reply]
@Houseblaster, if you or anyone else wants to force WMF Legal to look at this, upload https://imgur.com/a/ekW9o7g to any Wikimedia project and draw WMF Legal's attention to it. As it's an inaccurate depiction, Legal can't ignore it as fair use. Drawing attention might be difficult, ideally Paramount would DMCA it, but "actual knowledge" can be achieved in other ways. — Alexis Jazz (talk or ping me) 19:30, 29 November 2023 (UTC)Reply[reply]
The fact that this isn't how Squidward looks like in SpongeBob doesn't make it not fair use. It would almost certainly have little to no bearing on any fair use analysis. D. Benjamin Miller (talk) 22:56, 29 November 2023 (UTC)Reply[reply]
D. Benjamin Miller, an accurate depiction can be used for critical commentary and identification. A three-headed Squidward is fanfic, and not original/innovative enough to apply for fair use as a parody. See c:Commons:Deletion requests/Files in Category:BP logos where Legal clearly differentiated between accurate and inaccurate depictions of the logo. — Alexis Jazz (talk or ping me) 10:53, 30 November 2023 (UTC)Reply[reply]
That's just not how fair use works, though. Fair use is not a list of enumerated exceptions, but a method of holistic analysis. (Enumerated exceptions are what you'd find in some other countries' equivalent laws, but the US fair use doctrine does not use them. The Copyright Act gives "criticism" and "comment" as examples of purposes for which a copyrighted work may be used.)
The actual determination of whether or not a use is fair under US law is based on the four-factor test. D. Benjamin Miller (talk) 11:29, 30 November 2023 (UTC)Reply[reply]
Legally correct but irrelevant. In a lawsuit three-headed Squidward may be considered fair use - probably mostly because I'm not commercially exploiting him and the lack of effect on the original work's value. But WMF Legal seems to be more careful in this regard as they took down the inaccurate BP logo but left the accurate logos up. — Alexis Jazz (talk or ping me) 12:15, 30 November 2023 (UTC)Reply[reply]
I think there may be some confusion over the procedures and reasoning here.
BP sent a DMCA takedown for the inaccurate logo (but not for the accurate logos). As a result of the takedown notice, Legal was required to remove the requested file (subject to counternotice), but was not required to remove any others.
Legal expressed the opinion that the logo (accurate or inaccurate) was probably above TOO.
It happens that Commons doesn't allow content on fair use grounds (as a community rule). Legal explicitly said they don't enforce that — only the community does. Since they had not received a takedown request for that file and they believed it would not be an unlawful use to keep it up, Legal didn't remove it. The community users decided to remove those files separately.
(As an aside, although Josve05a says in that DR discussion that the DMCA notice was a determination that the BP logo was above TOO, this isn't quite true. The DMCA takedown of course implies this claim, and Legal found it reasonably likely to hold up, but nobody involved here can make a definitive determination.) D. Benjamin Miller (talk) 12:49, 30 November 2023 (UTC)Reply[reply]
Yes, and it's probably the same deal; some intern giving a broader license than was intended. This is especially worse since this is run by a foreign branch, with probably little oversight from the domestic portions of CN. -BRAINULATOR9 (TALK) 00:14, 2 December 2023 (UTC)Reply[reply]
It isn't just Nicktoons, Nick Music and NickRewind though. From March 22 to November 30, 2018, MSNBC released some of its videos under the CC-BY license, and a screenshot from one is used in the infobox for the Rachel Maddow article. JohnCWiesenthal (talk) 01:31, 3 December 2023 (UTC)Reply[reply]
@Alexis Jazz Something else I've found that should be brought up is that Disney Junior Israel has also been uploading under the CC-BY license since December 2, 2018. With this information, I think it would be more difficult to prove that this license decision is unintentional. JohnCWiesenthal (talk) 23:41, 19 December 2023 (UTC)Reply[reply]
For Disney Channel Israel, I guess the subtitles/dubs can be interpreted somewhat as "digital watermarks," as either one can distinguish them from the original works:
For dubbed videos, the video itself and any derived screenshots should be okay to use, but any audio must be in Hebrew and not any other language, including English.
For subtitled videos, the audio is kept in English and should be okay to use. However, any included subtitles must be retained in the video and any derived screenshots as the versions without subtitles are not under the CC-BY license.
I'd also like to note that we don't actually know who owns the rights to SpongeBob Squarepants the character, show or any other aspect. It could be the estate of Stephen Hillenburg, United Plankton Pictures, or some entity in the enormous octopus that is the Paramount conglomerate. If the YouTube channel is owned/operated by one subsidiary of Paramount/Nickelodeon Group and the rights are held by another subsidiary and licensed to the channel operators, then they didn't actually release it under CC-BY because they can't release something they don't own. The WordsmithTalk to me 03:24, 20 December 2023 (UTC)Reply[reply]
Hi, Alexis Jazz and others above have mixed up several things above (I would have liked to be informed when you talk about me.).
Second, all these works are still under a trademark. So even if the video content is free, you can't use it to compete with these companies on their business.
Third, it is really stupid and arrogant to think that these companies and their employees don't know what they do, specially on legal matters. They have a huge legal department, which probably decided that a free license will help their marketing campaigns. Never underestimate someone when they do something unexpected. I did write to these companies inquiring about the validity of their free license, but I only got a mail saying that my question was forwarded to their legal department. Yann (talk) 22:22, 25 December 2023 (UTC)Reply[reply]
But I wanted to sell a DVD based on iCarly clips, I could do that without violating copyright or trademark laws? -BRAINULATOR9 (TALK) 22:39, 25 December 2023 (UTC)Reply[reply]
Probably not without violating trademark laws. IMO we can use extracts from these videos for illustrating Wikimedia projects, but I won't do more than that without a steel-armor for legal issues. But IANAL.
As someone says above, a warning in the description of these files might be a good idea. You are welcome to help. Yann (talk) 23:01, 25 December 2023 (UTC)Reply[reply]
Would {{c:Trademarked}} be sufficient for said warning, or should the warning template be more specific? JohnCWiesenthal (talk) 02:13, 26 December 2023 (UTC)Reply[reply]
I wonder how much Dastar Corp. v. Twentieth Century Fox Film Corp. plays into this. In that case, it was ruled that you can't use trademark law in order to target plagiarism without turning it into copyright law. So I imagine selling DVDs of, say, iCarly clips, would fall closer to copyright law (unless you made it seem like Nickelodeon or whoever supported the production and manufacturing of the DVDs themselves - that is, the physical item, not its contents). -BRAINULATOR9 (TALK) 04:47, 26 December 2023 (UTC)Reply[reply]
Yeah, it is a tricky borderline. Responding to JohnCWiesenthal, we probably need a warning about derivative works. IMO the restriction is similar to freedom of panorama issues. The whole file is under a free license, but extracting some specific parts may come into breaking copyright laws. We also have had this issue for court cases (PDF files) which include copyright works as fair use. We can't extract these items under the pretext that the whole work is free of copyright. Yann (talk) 10:52, 26 December 2023 (UTC)Reply[reply]
Partially, though I don't think images of SpongeBob in a video about SpongeBob would count as being merely incidental according to c:COM:DM#Guidelines. -BRAINULATOR9 (TALK) 19:13, 26 December 2023 (UTC)Reply[reply]
I meant that The whole file is under a free license, but extracting some specific parts may come into breaking copyright laws. sounds like c:COM:DM in general. So, I would think that a warning template for these purposes may be based on {{c:De minimis}}. JohnCWiesenthal (talk) 02:27, 27 December 2023 (UTC)Reply[reply]
I preface my comment by stating that I am not a lawyer. I intend on providing a perspective to resolve this issue using pragmatic statements of fact and a foundation for further perspectives. It is my understanding, then, that the scope of employment for uploading the content does not consider the inclusion of material that has not been sublicensed, invalidating the Creative Commons licenses in the content referenced by Alexis Jazz, furthered by the absence of elucidated definitions of copyrighted material by the referenced parties. The Wikimedia Foundation legal department must seek further guidance from the referenced parties and, in order to assure conservative practicality with respect to the licensors, the copyrighted material must be deleted.
The basis for whether or not copyrighted content may be freely used once referenced in a medium that permits free distribution is a determining factor in this discussion, but not the solitary determinative. It is within Wikipedia's interest to use content that is available within the public domain or that which the copyright holder grants use to the general public as a licensee. For the purposes of this discussion, the public domain is irrelevant. With regards to the concerned parties, the videos in question have been licensed under the Creative Commons Attribution 3.0 Unported license, a permissible license under Wikimedia Commons. Copyright is assumed for original characters and derivatives under the Berne Convention; trademark, as referenced in Alexis Jazz's imaginative first question, concerns commercial use and is insignificant to a broader understanding of the situation.
The Creative Commons Attribution license assumes the most permissive and irrevocable position to licensees, an assurance that may serve paramount to a commercial entity. Walt Disney Television, for instance, licensed a July 2016 photograph of Paul Manafort under the Creative Commons Attribution-NoDerivs 2.0 Generic license. Walt Disney Television's photograph of Manafort, thus, cannot be uploaded to Wikimedia Commons as the prohibition of derivatives conflicts with free distribution. It is within the corporate interest to protect the commercial and derivative use of a work. The licensor is expected to knowingly apply the proper license and must be given the assumption of intent, irrespective of true intent.
The content in this discussion contains copyrighted content that has not knowingly been released under a free distribution license or within the public domain, necessitating the representation of a licensor or an explicit sublicense, the latter having not been achieved. Having read the legal basis behind the Creative Commons Attribution license, the individual who uploaded the referenced content cannot represent the licensor, as said individual had no involvement in the creation or licensing of the subcontent, regardless of the intention of the applied license. The judgement I hold would apply to all material referenced by Alexis Jazz. I previously upheld the belief that the Hogwarts Legacy trailer is able to be freely used and distributed; the trailer includes content that is the copyright of Warner Bros., including the logo of the game, and cannot be considered material eligible for the Creative Commons licenses. elijahpepe@wikipedia (he/him) 21:44, 30 December 2023 (UTC)Reply[reply]
In regards to the last sentence, are you saying you changed your mind since that deletion request? -BRAINULATOR9 (TALK) 21:56, 30 December 2023 (UTC)Reply[reply]
The last sentence seems oxymoronic. You first say that the trailer is able to be freely used and distributed, but then say that it cannot be considered material eligible for the Creative Commons licenses. What do you mean by this? JohnCWiesenthal (talk) 03:07, 31 December 2023 (UTC)Reply[reply]
Thank you for writing to the Wikimedia Foundation's Legal Department, and for your summary of the situation. We are now looking into this. To start, one thing we will try to do is reach out to Nickelodeon with a question about their CC licensed content on YouTube. Given the time of year, I don't expect we will hear back right away. I've read the thread on VPP; I will post this reply there as well. Since we are prioritizing other legal matters, I can't promise regular updates or responsiveness on-wiki about this in the near term.
BChoo, thanks, I hadn't quite expected a public notice like this, I appreciate it. If you could drop Disney a mail as well for their DisneyChannelIsrael channel that would be great. I'd do it myself, but (if I could get in touch at all) they'd get stuck in their script when I can't give them a Disney+ account name and refuse to reboot my phone.. — Alexis Jazz (talk or ping me) 11:11, 30 November 2023 (UTC)Reply[reply]
One thought I have: I'm sure it's very much in their interest to try and claim they're still in copyright (though, that said, trademark is probably a big defense here). In some ways, if Wikipedia isn't all-in on it, this is how we encourage the creation of bad law that overturns a host of other public domain works. Adam Cuerden(talk)Has about 8.7% of all FPs. 21:20, 25 December 2023 (UTC)Reply[reply]
A reminder that a CC licensed work can include copyrighted portions under fair use allowances, but that doesn't magically convert the copyrighted portions to CC. There is supposed to be appropriate mention of the copyright origin of the fair use segments as part of the CC work, but even absent that, CC doesn't have this magical conversion in place. See [5]. --Masem (t) 02:32, 26 December 2023 (UTC)Reply[reply]
It's also worth remembering, though, that if a copyright holder releases something under a non-revocable license like CC, they can't just take it back. It's like loss of the secrecy of a trade secret; once the cat is out of the bag, it is out. — SMcCandlish☏¢ 😼 06:31, 30 December 2023 (UTC)Reply[reply]
RfC to limit the inclusion of the deadname of deceased transgender or non-binary persons
For deceased transgender or non-binary persons, their former name (birth name, professional name, stage name, or pseudonym) should be included in their main biographical article only if the name is documented in multiple secondary and reliable sources containing non-trivial coverage of the person.
This text was added boldly by different editors, originally in July and again in October, but was removed in December. 18:38, 10 December 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have split this long discussion to its own page, because (a) it's only been open a few days, and we've already got 85 comments from 46 people here and (b) due to the number of large discussions, this Village Pump page is currently almost half a million bytes long, which is much longer than some people can effectively read and participate in. The new location for this RFC is Wikipedia:Requests for comment/Names of deceased trans people. Please join the discussion over there. Thanks for your understanding, WhatamIdoing (talk) 06:24, 14 December 2023 (UTC)Reply[reply]
Wikipedia is WP:NOTCENSORED. Your opinion amounts to comic book style political censorship of the kind we just don't do. So no. Hard no. Note that the Saudi flag also has an offensive slogan on it, are we to discontinue its use as well? Horse Eye's Back (talk) 22:54, 21 December 2023 (UTC)Reply[reply]
Wikipiedia is also not for WP:THINGSMADEUPONEDAY, so despite your sneering contempt, the question of whether this is an actual flag or is just something someone installed on Wikipedia is worth looking into. Doing a Google Image search on "Ansarullah Flag" finds nothing similar, so one could understand not feeling it's a flag... and it's not as the term is normally used.
If you do an Image search on the term as it is described in its file (Houthi Ansarullah "Al-Sarkha" banner), one does find a few picture examples, but only one in which it seems to be being used as a "flag" (and there it is described as a picture of a slogan rather than as a flag); more commonly, its shown as a banner or poster. Whether it is the best choice for a flag image to represent a group is a fair question. -- Nat Gertler (talk) 23:45, 21 December 2023 (UTC)Reply[reply]
The version you see here with their slogan on the white background is their flag, the slogan itself is just the words written on it. Horse Eye's Back (talk) 01:19, 22 December 2023 (UTC)Reply[reply]
The image we are discussing here is literally their slogan written on a white flag... Did you think that it was on a blank background? Did you think that it was just a coincidence that they were all the same? Horse Eye's Back (talk) 01:29, 22 December 2023 (UTC)Reply[reply]
Okay, so you don't have a source, but you assume it's their flag. If I write "E pluribus unum" on a white piece of fabric, does that make it the flag of the United States? -- Nat Gertler (talk) 01:42, 22 December 2023 (UTC)Reply[reply]
I've bern following the Houthi movement for longer than I've been editing wikipedia. You're asking for a citation that the sky is blue which can be surprisingly hard to find... All I can really show you is it being used, typically its called the "Houthi banner" (the difference between a banner and a flag is immaterial for wiki purposes, it only matters to sexologists) such as this 2014 Reuters piece "At a People’s Committee checkpoint bedecked with a Houthi banner in Sanaa's Bier Abu Shamla district"[6] This CNN piece "Fighters loyal to the Saudi-backed government point rifles toward a Houthi banner on the outskirts of Hodeidah."[7]. Horse Eye's Back (talk) 02:10, 22 December 2023 (UTC)Reply[reply]
You may mean 'vexillologists' not 'sexologists', but I suppose sexologists may also care about flags and banners.-gadfium 03:16, 22 December 2023 (UTC)Reply[reply]
Both can likely tell you why your flag is at half mast Horse Eye's Back (talk) 21:26, 22 December 2023 (UTC)Reply[reply]
It seems to be a notable image/sign/slogan often used at protests, per Slogan of the Houthi movement. But I can't see anything official indicating that it is the flag that leaders of the Houthi movement have chosen to represent them as a group. If it isn't an official flag, it shouldn't be used as on on Wikipedia. The WordsmithTalk to me 01:56, 22 December 2023 (UTC)Reply[reply]
Besides for the fact that its the flag that the leaders of the Houthi movement use to represent them as a group? [8][9][10][11]Horse Eye's Back (talk) 02:10, 22 December 2023 (UTC)Reply[reply]
I'm not especially familiar with the Houthi movement nor can I read Arabic, but I'm not sure these photos are sufficient. I'm fairly sure that in order to call somethign the flag of this movement, we'd need to have third party reliable sources saying so. In a pinch, I'd even say a primary source like a website/statement of the movement leaders or spokespeople would be enough. I'm sure it can be difficult for movements like this, but we need verifiablility if we want to give some kind of official standing to symbols associated with a group. The WordsmithTalk to me 02:23, 22 December 2023 (UTC)Reply[reply]
Nobody has proposed that we call something the flag of this movement unless I'm missing something. What we are discussing is whether it can be used to represent them. We don't actually *need* even a single source to do that. Horse Eye's Back (talk) 02:29, 22 December 2023 (UTC)Reply[reply]
MOS:NONSOVEREIGN: if a flag is felt to be necessary, it should be that of the sovereign state (e.g. the United States of America or Canada) and not that of a subnational entity, even if that entity is sometimes considered a "nation" or "country" in its own right.Hawkeye7(discuss) 02:37, 22 December 2023 (UTC)Reply[reply]
And then note where it says that many editors disagree and not to try to enforce it universally? Seems like poorly written MOS. Horse Eye's Back (talk) 02:46, 22 December 2023 (UTC)Reply[reply]
Take a gander at War in Afghanistan (2001–2021) for how we normally treat these sorts of groups... AKA we use their self-declared flag, whether it be for the Taliban, the Northern Alliance, or the ISAF. Or try Belligerents in the Syrian civil war for a bewildering number of flags/banners of things other than sovereign states. Horse Eye's Back (talk) 21:56, 22 December 2023 (UTC)Reply[reply]
Offensive slogans are not uncommon on flags. To give an example from US history, both the First navy jack and the Gadsden Flag contain the slogan “Don’t tread on me”. This could be seen as offensive and anti-government. Yet the slogan is part of the flag nevertheless. Blueboar (talk) 23:23, 21 December 2023 (UTC)Reply[reply]
If you think something being anti-government makes it offensive, I'd say you deserve to be offended. --Trovatore (talk) 01:47, 22 December 2023 (UTC)Reply[reply]
If it is appropriate to display the flag of this movement in any particular article then it should be displayed as is. I dont think that the example given above is a good one, as I don't see why any flags should be displayed. I wouldn't say that the Saudi flag is anywhere near as offensive as the Houthi one. As a confirmed atheist I do not agree with its slogan, but it does not call for anyone's death. Phil Bridger (talk) 23:32, 21 December 2023 (UTC)Reply[reply]
The example use would seem inappropriate under MOS:ICONDECORATION, as it doesn't add information, given that the country or group being represented is immediately named. (And because it's a banner and thus vertical in nature, reducing it to that height makes it unrecognizable, which is not so true of horizontally-oriented flags.) -- Nat Gertler (talk) 00:05, 22 December 2023 (UTC)Reply[reply]
Flag-icons seem to be used in some other "International reactions" sections of articles on major events when that section is a simple bullet-list rather than paragraphs or subsections. DMacks (talk) 00:23, 22 December 2023 (UTC)Reply[reply]
If we can verify that this is indeed an official Houthi flag, then it should go in the article. We display the flag of Nazi Germany in their article and I can't imagine a more offensive flag than that one. Loki (talk) 00:29, 22 December 2023 (UTC)Reply[reply]
Except Houthi is not a nation, it's a political group. So if this is its flag, that might be appropriate on Houthi movement, but it makes it less appropriate when we are talking about the jurisdiction represented (Saada Governorate), much as if we were talking about something the Biden administration was doing, the proper symbol would not be the Democratic donkey, but the flag of the United States. -- Nat Gertler (talk) 01:16, 22 December 2023 (UTC)Reply[reply]
Yes... And when a political group takes power in a nation and makes their symbols the national ones thats what happens... Whether its the Houthi movement or the National Socialist movement. Horse Eye's Back (talk) 01:22, 22 December 2023 (UTC)Reply[reply]
And again, I ask for source. It's really not that wild a thing to ask for. Can you find me a reliable third-party source that this is the flag for the jurisdiction? -- Nat Gertler (talk) 01:47, 22 December 2023 (UTC)Reply[reply]
I can not, the Houthis don't get that level of coverage where we would have significant coverage of the history of their flag... At least from non-primary sources. I think you'll actually have trouble with that for many jurisdictions. Also note that Saada Governorate =/= Houthis. Horse Eye's Back (talk) 02:16, 22 December 2023 (UTC)Reply[reply]
NatGertler makes a good point: if we can't WP:V that this flag/banner/thing actually formally represents the organization who is speaking in this "reaction", then it doesn't belong on WP. If the group speaking is a government or at least whatever organization is nominally in charge, then that's what should be used. It's not POV to use a verified representation of the group. DMacks (talk) 02:37, 22 December 2023 (UTC)Reply[reply]
Yes, but in an article that's about the group, the unofficial flag is generally one of the example items used to illustrate the group. That is different when it's used in other articles, where it serves as more of a stand-in for the group. For example, the flag that's used in the Black Lives Matter article is only used to represent the movement as a symbol in one other article -- an infobox in Proud Boys -- and that use is questionable. This despite the fact that we have about 50 articles that link to the Black Lives Matter page (not counting hundreds more that have it linked in a template.) I'm not sure anyone's saying this banner cannot be on the page Houthi movement -- but even there, there is not the claim that it is their "flag", just a display of their slogan. --Nat Gertler (talk) 06:44, 22 December 2023 (UTC)Reply[reply]
Actually, if you go to Proud Boys now, you won't even find the BLM flag there. I just removed it for reasons utterly unrelated to its flagness, officialness, or the proper use of icons; it was part of an item which should not have been there. --Nat Gertler (talk) 14:09, 22 December 2023 (UTC) Reply[reply]
If we are using a flag to represent a group in this way (not just as an illustration in the article about them, but as an icon used across other articles), it should be unambiguously well-attested as an official symbol of that group in multiple reliable third-party sources. Otherwise, it places us in a non-neutral position of promoting a symbol rather than just recognizing others' use of it. If a flag isn't widely used in secondary sources, it won't be effective as a recognizable symbol anyway.--Trystan (talk) 06:12, 22 December 2023 (UTC)Reply[reply]
Whether it is an "official" symbol or not is irrelevant. What matters is whether it is commonly used in reliable sources (which may be primary or secondary) to represent the group/place/country/etc in question in contexts where flags of other groups/places/countries are used, the group/place/country/etc do not verifiably object to its use in such contexts, and that there is no other symbol that is unambiguously used more often in the same contexts. Thryduulf (talk) 10:50, 22 December 2023 (UTC)Reply[reply]
It seems like that answers the question of whether or not it has recognition as their flag. The only remaining question is whether it is too offensive to be used, which correctly doesn't seem to be getting any traction here per WP:NOTCENSORED. The WordsmithTalk to me 20:23, 22 December 2023 (UTC)Reply[reply]
I would distinguish pictures depicting Houthi use of the banner from use of it by third parties to represent the Houthi movement (with a large majority of Wikipedia's uses being the latter). Based on the sources provided so far, it seems like the only two bodies actively using the flag as a symbol to represent the Houthis are the Houthis themselves and Wikipedia. I agree the offensiveness is irrelevant, but we shouldn't be cutting new ground in this regard.--Trystan (talk) 20:37, 22 December 2023 (UTC)Reply[reply]
Are there examples of other symbols used to depict the Houthi movement that present alternatives? VQuakr (talk) 20:51, 22 December 2023 (UTC)Reply[reply]
If there are no symbols widely used by third-party sources to depict a group, the alternative would be for us not to use one.--Trystan (talk) 20:55, 22 December 2023 (UTC)Reply[reply]
But we have such a symbol, you've rejected the wide use by third-party sources in favor of a declaration that it needs to be "bodies" which use the symbol. Horse Eye's Back (talk) 21:26, 22 December 2023 (UTC)Reply[reply]
In this particular case I don't know that the "third party" bit is terribly important. If an org uses a flag to identify themselves, to the extent of slapping it (as mentioned above) on the side of their fighter jets, that seems like strong evidence that it is a symbol that can be used to represent the organization. An affirmative rebuttal of "no, this third party uses this other symbol to identify them instead" is certainly not the only counter-argument to that, but it is a potentially valid one. VQuakr (talk) 21:49, 22 December 2023 (UTC)Reply[reply]
...strong evidence that it is a symbol that can be used to represent the organization... Presumably, the Houthis want their banner to be widely disseminated and associated with them. If our sources aren't already doing that, I think it is non-neutral for us to lead the way. ...you've rejected the wide use by third-party sources... I haven't seen any use by third party sources, only pictures depicting the Houthis themselves using it. That is qualitatively different to the way Wikipedia has turned it into an icon used across many articles.--Trystan (talk) 22:00, 22 December 2023 (UTC)Reply[reply]
We rarely cite encyclopedias in our articles. Why would we expect RSs to use icons in the way established within Wikipedia? That's not a neutrality issue, it's a style issue. Treating one org differently than any other by omitting their flag is non-neutral. VQuakr (talk) 22:09, 22 December 2023 (UTC)Reply[reply]
News media use flags as graphical symbols all the time, and are therefore a good barometer of which symbols are well-established, and which symbols where our adoption would amount to novel promotion. One of the first considerations of any style issue is whether it supports the neutral presentation of information.--Trystan (talk) 22:33, 22 December 2023 (UTC)Reply[reply]
The Jpost source is an opinion piece, as is the MEI one ("the views expressed in this piece are his own.") The Small Wars Journal cite is a photo caption, which we sometimes treat as equivalent to a headline, and the phrasing of which indicates that this is a Houthi banner rather than the, The Critical Threats source (again a photo caption) recognizes an item in the photo as a flag, but not specifically the Houthi flag. -- Nat Gertler (talk) 21:55, 22 December 2023 (UTC)Reply[reply]
As I said, one can easily find more sources than the ones listed above. For instance, the book Yemen Endures: Civil War, Saudi Adventurism and the Future of Arabia (p. 180, published by Oxford University Press) also discusses that the Houthis used banners adorned with their slogan from their earliest days. The Chaos in the Middle East: 2014-2016 (p. 244) also talks about their flag, stating that "the organization's philosophy is summarised with blinding clarity by their flag, which consists of five statements in Arabic [...]" before describing the Houthi flag. Yemen's Road to War: Yemeni Struggle in the Middle East also details the Houthi flag in Section 1.9.2. I could mention more examples. Applodion (talk) 23:13, 22 December 2023 (UTC)Reply[reply]
The first one doesn't quite make the statement we're looking for. The second one does, but its Amazon listing says it's published by Troubador, which is a self-publishing service, so I'm left with the question of whether Neville Teller is suffiiciently an expert for a WP:SPS, a question I won't claim to have an answer to. -- Nat Gertler (talk) 23:52, 22 December 2023 (UTC)Reply[reply]
Both the first and the third book talk about the Houthi flag, so I'm unsure why those aren't yet "the statement we're looking for". As you liked the second book's quote, however, I assume you mean a phrase like "... the organization's philosophy is summarised...". I found another source with a very similar framing: Political Musings: Turmoil in the Middle East (Chapter 3) states "The group has very clear objectives, which are spelt out on their flag in five statements, the first and the last in green colour - 'God is Great; Death to America; Death to Israel, Curse on the Jews; Victory to Islam'". This source is published by Vij Books which appear to be a reputable Indian publisher. Applodion (talk) 00:12, 23 December 2023 (UTC)Reply[reply]
I'm just going by your description; "the Houthis used banners adorned with their slogan from their earliest days"; nations and groups have used many things adorned with slogans that aren't their official jurisdictional flags -- military flags, Keep Calm and Carry On posters, etc. Something being a flag or banner they displayed is not the same as being "the flag of". -- Nat Gertler (talk) 00:22, 23 December 2023 (UTC)Reply[reply]
Ok, let's try some more examples. This pdf of an article from Bloomsbury Collections states "The omnipresent flag decorating the machinery of the Houthis' quasi-military wing renders the sarkha emblazoned with words and colors that emulate the Iranian post-Islamic revolution flag (Figure 11.1)" [the sarkha is the slogan]. In Chapter 1 of The Huthi Movement in Yemen: Ideology, Ambition and Security in the Arab Gulf, it is emphasized that "[...] the movement's slogan or 'shout' (sarkha), which appears on its flag [...]". This article by the Konrad Adenauer Stiftung states "After all, the slogan printed on their flag is already reminiscent of the 1979 revolution and expresses the general aims of the militia: 'Death to America, Death to Israel, Damn the Jews, Victory to Islam!'" Applodion (talk) 02:46, 23 December 2023 (UTC)Reply[reply]
I think we may be missing the forest for the trees here. Before we discuss whether this flag icon is appropriate for use in the article, I think we need to ask whether ANY flag icons belong in the article. See WP:ICON which lays out when and how we should use flag icons. Blueboar (talk) 22:02, 22 December 2023 (UTC)Reply[reply]
Well, we're responding to a rather narrow question about racist slogans in flags. Where the flag should be used is a different discussion one that doesn't seem to make sense to me to be discussing here unless a change in policy is being considered. VQuakr (talk) 22:07, 22 December 2023 (UTC)Reply[reply]
The VP(P) isn’t just for discussing changes to policy (in fact, that is best done on the talk page of the policy itself)… it is also for discussing how policy should be applied. What I am asking is how/whether WP:ICON applies? Blueboar (talk) 22:39, 22 December 2023 (UTC)Reply[reply]
Looking at the first few pages its listed as used on, it largely isn't. It mostly appears next to the Houthi name on, say, a list of belligerents in a war or a list of bodies that use a given weapon. That is appropriate if the icon is later used in the piece. For example, 2023 Israel–Hamas war has a list of involved parties, each with an icon.... which is useful because there's lists of individuals and units and the Israeli flag is used to mark which individuals and which units are Israeli. But there are no Houthi individuals or units listed, so the icon does not serve as a key, merely a decoration. (This isn't 100% the case -- on 2023 attacks on U.S. bases in Iraq and Syria, the key is used.) We can argue whether if we have key icons for some groups, we should have them for all groups whether or not they are used. But in a place like the list of operators of the 76 mm divisional gun M1942 (ZiS-3), every group is given a flag in a purely decorative way, which is against WP:ICON.
I should note that while this banner makes a lousy icon (its vertical format means that it's displayed at half the size of horizontal flags and it fades into gray infobox backgrounds), when used as an icon the text is unreadable (well, it always is to me, but at that size, to anyone.) This at least alleviates concerns that in these examples, the image is being inserted primarily to spread the message of its text.
Overall, this becomes more a reflection that flag icon use on Wikipedia and what our guidelines call for are not in accord. -- Nat Gertler (talk) 02:40, 24 December 2023 (UTC)Reply[reply]
Well... The conflict is also that the guideline is internally inconsistent... One part of the MOS appears to say only use the flags of sovereign states and another part says you can use any subnational flag you please as long as there is direct relevance. (MOS:FLAGRELEVANCE) seems to accurately reflect what we actually do in practice:
"Subnational flags (regions, cities, etc.) should generally be used only when directly relevant to the article. Such flags are rarely recognizable by the general public, detracting from any shorthand utility they might have, and are rarely closely related to the subject of the article. For instance, the flag of Tampa, Florida, is appropriately used on the Tampa article. However, the Tampa flag should generally not be used on articles about residents of Tampa: it would not be informative, and it would be unnecessarily visually distracting."
One thing you'll run into is "everyone else gets a flag" situations, like at 76_mm_divisional_gun_M1942_(ZiS-3)#Operators, where there are two dozen entries, all but two being nations. Now in that particular case, no one should have a flag as it is not being used as a key. (The problem with relying on these keys can be seen in 2023 attacks on U.S. bases in Iraq and Syria, where there are keys for political and substate entities in addition to nations... but three of the entities are using , making the keying useless.) --Nat Gertler (talk) 18:57, 24 December 2023 (UTC)Reply[reply]
Less helpful, but not useless (it would only be useless if they were *all* the same). Overuse is absolutely an issue, but I'm not convinced that any use = overuse. Horse Eye's Back (talk) 01:29, 25 December 2023 (UTC)Reply[reply]
As a general matter, the answer to the question is obviously "yes", per WP:NOTCENSORED. However, in this particular case – which has nothing at all to do with offensiveness but with verifiability – there appears to be insufficient evidence this is a real banner/flag used by the Houthi militants. Its use as a symbol for Mohammed al-Houthi in particular at Riyadh Agreement#International reactions is clearly inappropriate. Its use at Houthi movement seems to be dubious; there's some hint of sourcing above, some of it unreliable, some less so but not necessarily sufficient. At least in the case of Mohammed al-Houthi in that table of Riyadh Agreement politicians, it should be replaced with the flag found at General People's Congress (Yemen), or perhaps the one at Supreme Political Council; they are actual flags adopted by the Houthi movement and better sourced, and he actually represents those political bodies. — SMcCandlish☏¢ 😼 22:19, 27 December 2023 (UTC)Reply[reply]
But in that context al-Houthi was not representing the General People's Congress, they were representing the pro-Houthi faction of the General People's Congress. So presenting him as the representative of the party and not a faction within the party would be clearly inappropriate (as well as nonsensical). If any flag is appropriate its the Houthi one, but perhaps no flag at all is appropriate. Horse Eye's Back (talk) 18:52, 1 January 2024 (UTC)Reply[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Currently, WP:PGCHANGE says this: After some time, if there are no objections to the change and/or if a widespread consensus for your change or implementation is reached through discussion, you can then edit policy and guideline pages describing the practice to reflect the new situation.
Should WP:PGCHANGE include an explanation, or else clarify the meaning of "widespread consensus" to mean the following:
For the purpose of this policy, "widespread consensus for the change" means that the discussion about substantive changes to a policy or guideline must be advertised sitewide to the entire community (such as through a request for comment and/or by posting at centralized discussion) and, after being so advertised, would reach consensus for the change.
It need not be the exact wording, but this would be the intended meaning. The possibility to edit policies and guidelines if there are no objections to these changes will stay. Szmenderowiecki (talk) 13:27, 22 December 2023 (UTC)Reply[reply]
Background
A recent discussion about WP:ARTICLESIZE (a guideline) was closed as "consensus to change". But there were a few editors over there who opined that in WP:PGCHANGE (the policy about changing policies and guidelines), "widespread consensus" means that the discussion must be sufficiently advertised (preferably sitewide, as in with an RfC) and there be consensus. VQuakr went on to say that in a discussion about changing policy or a guideline, even a unanimous discussion with ~15 editors would mean little if it only remained known to those who cared about the guideline and did not appear as an RfC or similar.
I then asked DfD to help me out, and the one editor (Isaacl) who answered didn't say whether this was what the policy said but suggested that personally they would prefer to read it as asking for sitewide advertisement. Other editors (the majority of those people) wanted to avoid an RfC as it would be a drain on the community.
To be clear, I do not mean this discussion to overturn that closure (I don't have a horse in that race), but I do want to hear opinions on whether changing policies and guidelines is appropriate without an RfC, given the doubts that have appeared in interpreting that policy. I do not wish to comment about that discussion so as not to appear favouring either side of that discussion. Szmenderowiecki (talk) 13:27, 22 December 2023 (UTC)Reply[reply]
Survey
Oppose - I don't think the additional text works in the broader context of the section. A change can be made if no one objects. A single objection shouldn't neccessarily trigger the need for a site-wide RFC. Often the consensus can become clear through ordinary, widespread discussion, without the bureaucratic overhead of an RFC. There are some changes that should be put to such an RFC, but they shouldn't be mandatory in all cases that aren’t strictly unanimous.--Trystan (talk) 15:25, 22 December 2023 (UTC)Reply[reply]
Oppose as needless bureaucracy. A WikiProject talk page isn’t a valid place go get consensus, but a policy talk page obviously is Mach61 (talk) 18:28, 22 December 2023 (UTC)Reply[reply]
Reword. I think something is needed, but perhaps not this precise wording. What's really necessary is some sort of link to WP:CONLEVEL and an indication that you need a consensus commiserate to the level of the change you are making - minor tweaks don't require widely-advertised consensus, and sometimes may not require affirmative consensus at all if they're slight wording tweaks and nobody objects, whereas if your change would fundimentially alter the functioning of core policy then it needs consensus on a level appropriate for that massive impact. Currently, at least at a glance, the page doesn't mention that at all; there needs to be at least one link to CONLEVEL somewhere on the page, since understanding that policy is essential for any major policy change. (Especially see the second paragraph of CONLEVEL, which is central here.) --Aquillion (talk) 10:49, 24 December 2023 (UTC)Reply[reply]
A few months ago, Aquillion said that "an RFC on an article talk page is by default local, and any conclusions it reaches are local; that is the heart and soul of WP:CONLEVEL".
This is neither consistent with what CONLEVEL says (it gives an example of an unadvertised, non-RFC discussion between a self-selected group of editors on a WikiProject's talk page that they claim overrides the views of editors on hundreds or thousands of articles) nor with how RFCs (the primary mechanism for advertising a discussion to the wider community, with the goal of getting comments from uninvolved editors) are understood by the community. WhatamIdoing (talk) 18:01, 5 January 2024 (UTC)Reply[reply]
Oppose at least in something like that form, per WP:NOT#BUREAUCRACY and WP:CREEP and WP:EDITING and the intent of WP:P&G (particularly WP:PGCHANGE) in the first place. That said, I agree with Aquillion that the section should include a cross-reference to WP:CONLEVEL. If some suggestion to do an RfC or something is included, it should not refer to WP:CENT which is for high-profile things needing massive amounts of editorial attention and which are likely to affect a bazillion articles (or editors thereof). CENT is absolutely not for minor clarification or loophole-closure tweaks to P&G material. The more appropriate venue for "advertising" a discussion about something like that is WP:VPPOL itself. Editors who care to be involved in the formation of our P&G pages already watch this page, but the entire editorial pool do not need CENT browbeating about what is usually maintenance trivia. — SMcCandlish☏¢ 😼 22:01, 27 December 2023 (UTC)Reply[reply]
About a year ago, on the talk page of one of the core policies (NPOV?), an editor stated that (in their opinion) every single edit to a policy page needed prior discussion, if not an RFC. We pointed the editor to the history page to review the edits made during the last month or so, and asked them how many of those they would revert. The answer was "none". I don't think most editors understand how many changes produce no real change in meaning – a link here, a grammar tweak there, but no substantive changes. Few of us make substantive changes without prior discussion, and even fewer of us make those edits without the change being reverted. WhatamIdoing (talk) 18:06, 5 January 2024 (UTC)Reply[reply]
Oppose I guess, I tend to agree and want to support but consensus works by being a consensus, not declaring it to exist. If enough people don't like the change when it is made, you enter into Bold revert discuss, don't you, because the consensus wasn't as strong as first thought or has changed since you thought you had it defined. So, hmmm, sitting on the fence getting splinters maybe? HidingT 20:02, 5 January 2024 (UTC)Reply[reply]
Discussion
@Szmenderowiecki: thanks for the well-thought out content above and the ping. I would say that the meaning of "widespread" varies depending on the scope of the impact of the proposed change. In the specific case of the article size discussion that prompted this, the group was discussing subsequent changes to other policies and believed that those changes would be subject to the consensus they had there. For the impact of the change they were proposing, their consensus was not widespread. I think we agree, though, that most changes to PAG do not need sitewide advertisement. The proposed change above effectively just kicks the can of when to advertise from the definition of "widespread" to the definition of "substantive". Ultimately, a judgement call will need to be made, and given that groupthink is more or less inherent in a collaborative environment, the reminder that a small team of editors (however internally aligned) shouldn't be making sitewide decisions in a vacuum will be met with occasional resistance. I'm not sure that's a problem that can be mitigated with a tweak to policy. VQuakr (talk) 16:53, 22 December 2023 (UTC)Reply[reply]
The "substantive change" thing is already in the policy. Before making substantive changes to policy and guideline pages, it is sometimes useful to try to establish a reasonable exception to the existing practice. Maybe this will be an issue sometime later but we can assume that typos, grammar, markup and general changes to wording that do not change the meaning of policy or guideline are non-substantive changes. Szmenderowiecki (talk) 17:20, 22 December 2023 (UTC)Reply[reply]
I'm not sure if the proposed change to the text is the best approach. Often changes face objections by someone who raises no specific concerns other than suggesting that a request for comments discussion be held, which can lead to the degree of impact being exaggerated and thus deadlocking minor changes from proceeding. In the referenced discussion, I said that in my view, the affected community of editors should be given the chance to discuss and influence the proposed change. This may not require a site-wide advertising of the proposal. It will depend on the scope of the guidance and the proposed change in question. isaacl (talk) 18:24, 22 December 2023 (UTC)Reply[reply]
Yep. Going through this right now with a bit of policy cleanup, which is being stonewalled by someone resistant to change (even basic grammar correction) simply for the sake of being resistant to change, as far as I can tell. — SMcCandlish☏¢ 😼 06:21, 30 December 2023 (UTC)Reply[reply]
I guess WP:NOTAVOTE would apply in that case. If the best they can argue is that their gut feeling is wrong or that I just want to resist all change, then I think we can safely disregard this. Szmenderowiecki (talk) 09:19, 4 January 2024 (UTC)Reply[reply]
Since I closed the discussion referenced above, I guess I'll just note that of course I think matching a proposed change to an appropriate quorum will always be a balancing act. Those affected by a change should have the opportunity to share their thoughts about it. In this case, a table listed "rules of thumb" in two (intended-to-be) equivalent measures – word count and kb of prose. A discussion at the guideline's talk page concluded the second measure (kb of prose size) should be removed as potentially confusing and unneeded. How broad a discussion is needed for such a change? The guideline's meaning is unchanged, it's just now expressed in one way rather than two. Even if WP:PGCHANGE read as proposed above, I likely would have closed the discussion the same way, considering this to not be a "substantive change", and expecting no particular controversy. Ajpolino (talk) 03:05, 3 January 2024 (UTC)Reply[reply]
Been a part of that discussion, and it does seem to be stonewalled also by a single party. I think their argument amounts to a (rather impassioned and stubborn) disagreement that the change is non-substantive. They seem to feel that the change, while perhaps not altering the actual end-result size/length limits, will in some way strongly affect at least some subset of users' understanding of how to arrive at it, their sense of what it means in reality, or something to this effect. I don't agree with the position, for reasons given over at that discussion, but it doesn't seem entirely out of left-field. — SMcCandlish☏¢ 😼 15:01, 5 January 2024 (UTC)Reply[reply]
Disclosing anti-government actions by notable people
I'm not sure how concerning it may be, but amid modern tightening of screws by certain governments and regimes: do we have some policy or advisory that handles the disclosure of anti-government actions by wikinotable people considering potential government punishments in that regard and usage of Wikipedia as a searchlight for government retaliation? While it's probably ok to mention, e.g., wikinotable people who signed anti-government open letters and petitions, I don't know if some relevant regulation exists (similar to Voices under Threat for editors). Brandmeistertalk 20:37, 29 December 2023 (UTC)Reply[reply]
Since we are a tertiary source, wouldn't the source material already be available to the governments? Wehwalt (talk) 21:12, 29 December 2023 (UTC)Reply[reply]
Yeah, we should only be including such information after it's been reported on in reliable sources. At that point, the cat's out of the bag. If someone is trying to insert primary sources with such information, then yes, it should be removed and perhaps even be oversighted depending on the information. But I feel like our existing policies already cover that. SilverserenC 21:15, 29 December 2023 (UTC)Reply[reply]
I would say that our BLP policies cover accusing someone of anti-governmental activities without it being well-sourced. Leaving aside opinions as to the government. No government's happy about actions against it, so we would avoid such things unless well-sourced. Wehwalt (talk) 21:28, 29 December 2023 (UTC)Reply[reply]
WP:DUE is relevant here - not every single statement or action over a person's life is appropriate to be covered in an article, and over-stressing undue details (whether anti-government or some other unpopular opinion - for example opinions on gender politics and the like) could cause problems for subjects (not necessarily directly from governments).Nigel Ish (talk) 21:31, 29 December 2023 (UTC)Reply[reply]
It would be a mistake to categorize anti-government opinion as universally unpopular. You will find many places where such an opinions is the popular opinion. For example when polled almost every single American holds some opinion that could be characterized as anti-government. Heck in the US its currently popular for elected members of the government to hold anti-government opinions. Horse Eye's Back (talk) 09:46, 30 December 2023 (UTC)Reply[reply]
The sorts of places where you need to worry about that sort of thing are generally not the places which need to go on wiki to build a dossier on a dissident. Also government and regime mean the same thing in this context. Horse Eye's Back (talk) 21:27, 29 December 2023 (UTC)Reply[reply]
Yes, we tend to want to do the "dossier on a dissident" but we really only should include incidents considered anti-government that are reported by multiple RS as to avoid singular source inputs. Masem (t) 00:31, 30 December 2023 (UTC)Reply[reply]
Yeah, upon further thought the cat out of the bag came to mind, RS and WP:DUE aside of course. Brandmeistertalk 09:19, 30 December 2023 (UTC)Reply[reply]
Aren't multiple RS always required for that sort of stuff when its BLP? And if its not BLP I fail to see the issue. Horse Eye's Back (talk) 09:41, 30 December 2023 (UTC)Reply[reply]
Finishing the ABOUTSELF ← SELFSOURCE ← BLPSELFPUB merge
For a while now, we've been talking about how to merge WP:SELFSOURCE (in WP:RS) and WP:BLPSELFPUB in (WP:BLP) to WP:ABOUTSELF (in WP:V), since they're all three nearly-identical WP:POLICYFORKs of the same material. This has kind of stalled out over the holidays, and some additional input and "energy to get it done" would be helpful.
I think we've hammered out the desirable merged version as to which variants of which clauses to use from the three slightly divergent versions (favoring pre-existing policy language over guideline language when the difference is substantive, but favoring the more concise guideline language when it's simply a matter of how to express the same point). The sticking points, to the extent there are any, seem to be whether or not to do some grammar cleanup on the opening sentence, and whether to include a clarification reading "Author includes an organizational one, not just an individual.", to address recurrent confusion about that.
There was also a suggestion that the footnote from the BLP version (about self-published denials of wrongdoing) could be shortened to remove one of its statements, but this would be a substantive, not just merge-and-copyedit, change to the policy material. So I've suggested that be punted for later discussion. Same with regard to a question about whether the rule's point no. 5, "the article is not based primarily on such sources", is applicable to certain kinds of things, which I've also suggested reserving for later discussion, since substantive change proposals should be examined separately from non-substantive cleanup. — SMcCandlish☏¢ 😼 06:17, 30 December 2023 (UTC)Reply[reply]
Over-capitalization of NFL Draft
In you look at sources, "draft" is overwhelmingly lowercase in most relevant sports contexts, including NFL (see [12], [13]). Yet it's hard to get away from the capitaized "Draft" on wikipedia due to the large number of football-fan editors compared to the editors who want to respect our style guidelines (at least, the was my impression in past discussions). Is there anything to be done about that? I recently moved a bunch of "List of ** in the NFL Draft" articles to lowercase draft, as that context is one of the most overwhelmingly clear in stats, but before I got most of them done they all got reverted. Is another RFC the way to go? Other ideas? Dicklyon (talk) 04:38, 2 January 2024 (UTC)Reply[reply]
Thanks for finding that clear lack of consensus. Dicklyon (talk) 05:17, 2 January 2024 (UTC)Reply[reply]
@BeanieFan11:, in reverting my moves to the "in the NFL Draft" articles, you wrote the current consensus is that the main draft article is spelled with an uppercase "D" - that should be reflected here. Can you share where you find that consensus? Dicklyon (talk) 05:53, 2 January 2024 (UTC)Reply[reply]
A gaggle of editors from the American football wikiproject will stonewall any attempt to move any of these articles; RM process has too few uninvolved participants to overrule their false-consensus. The article title "National Football League Draft" is demonstrably inappropriate per WP:COMMONNAME (and WP:CONCISE) policy, and also fails WP:NCCAPS and MOS:SPORTCAPS and etc. [14] It should be at NFL draft, which is actually the common name by a wide margin – with d not D. Of the four renditions "National Football League Draft", "National Football League draft", "NFL Draft", and "NFL draft", the "National Football League Draft" one is the least frequent and "NFL draft" by far the most. (And that's without even doing anything to filter out title-case appearance in names of works and chapters/sections; i.e., the capitalized forms are being significantly over-represented in these search results.) The long version is barely attested in published material. But this means nothing if no one one but football fans who love capitalizing everything to do with football weighs in on the question. (Which shouldn't be a question in the first place. Dicklyon's moves should not have been reverted, because they comply with the policies and guidelines and the over-capitalization has no leg to stand on (it's unadulterated WP:ILIKEIT). — SMcCandlish☏¢ 😼 11:20, 2 January 2024 (UTC)Reply[reply]
I suspect you'd get the same resistance in an RM at the NHL Entry Draft page, fwiw. Editors can't force other editors to agree to what they want. Thus they can't force such changes, if enough editor oppose. GoodDay (talk) 12:13, 2 January 2024 (UTC)Reply[reply]
No. They are specific events, or processes, but not proper names unless maybe in the context of the TV show or something (e.g. "I got tickets for 2024 NFL Draft", or "ESPN got rights to broadcast 2024 NFL Draft", perhaps). Stats show lowercase dominant draft, same as in other sports. Dicklyon (talk) 18:40, 2 January 2024 (UTC)Reply[reply]
Regardless of where one stands on the issue, we should be consistent with the capitalization used at the primary article that these other articles are based off, which is currently at National Football League Draft. Until that article is moved, which there is not consensus to do based off past discussions, we are essentially in limbo and should be consistent, otherwise it'll devolve into edit warring. Hey man im josh (talk) 01:51, 3 January 2024 (UTC)Reply[reply]
We definitely have a WP:CONLEVEL failure happening here, where a WP:FALSECONSENSUS of people devoted to a topic area are defying site-wide guidelines that apply to all topics, to get an over-capitalization result in their pet subject (against both MOS:SPORTCAPS and MOS:SIGCAPS, as well as WP:NCCAPS, and WP:COMMONNAME policy), all on the basis of a specialized-style fallacy, namely that various American-football-specific sources like to capitalize just about everything to do with football, while general-audience sources provably do not do this. Statistics this stark [15] do not lie. We have a problem that WP:RM, a process nearly no one pays any attention to, is regularly overrun by topic-specific editors after one of them alerts the related wikiproject, and the results end up being a predictable pile-on that ignores the large stack of guidelines and at least one policy, to just suit the preferences of the topical wikiproject participants; meanwhile few RM closers have the gumption to just discount their anti-WP:P&G and anti-source arguments and close in favor of the lower-cases moves, because the headcount majority crying for upper-case is apt to make WP:MRV noise about it and otherwise cause a bunch of drama. The RM process is palpably failing for cases like this; it is being outright WP:GAMED.
I'm skeptical that this can be settled any other way than with a broadly advertised RfC, tedious as style RfCs may be. If football fans are convinced they have on their hands some kind of demonstrable exception that just must be made to site-wide capitalization rules, then they are welcome to try to prove that to the community's satisfaction. This sort of thing has come up before many times (common names of species, capitalization of breeds and cultivars, etc.) that have festered sometimes for years, with a lot of editorial strife and disruption in sporadic, uncentralized debates, and were not resolved until broadly RfCed (here or at WT:MOS). — SMcCandlish☏¢ 😼 11:20, 2 January 2024 (UTC)Reply[reply]
I suspect there'd be resistance as well from WP:HOCKEY, concerning pages related to the NHL Entry Draft, too. BTW the Major League Baseball draft page, was moved to its current form without an RM & with little input. GoodDay (talk) 12:07, 2 January 2024 (UTC)Reply[reply]
The NHL Entry Draft stats are a good example of what happens when over-capitalization in Wikipedia influences the real world. It's not too late to fix it, as it's still not nearly consistently capped in sources, esp. independent sources. Dicklyon (talk) 18:35, 2 January 2024 (UTC)Reply[reply]
@Dicklyon: You should either officially propose a move of National Football League Draft or accept that editors will (and should) try to be consistent with the capitalization used at that article. Otherwise this is, frankly, a waste of everyone's time. We'd just end up rehashing the exact same discussion happening here. Hey man im josh (talk) 01:54, 3 January 2024 (UTC)Reply[reply]
The problem with RM, mentioned above, makes it hard to get to a consensus in such cases. Maybe an RFC? Dicklyon (talk) 03:12, 3 January 2024 (UTC)Reply[reply]
You could go the route of an RFC, but I don't really think there will be consensus on this issue either way. I suppose I'm asking what the goal of starting this discussion is. Are you planning to craft an RfC based on this discussion? Hey man im josh (talk) 03:27, 3 January 2024 (UTC)Reply[reply]
I'm seeking ideas; I had asked: "Is another RFC the way to go? Other ideas?". RFC was one idea supported. Dicklyon (talk) 03:50, 3 January 2024 (UTC)Reply[reply]
Personally I'm not convinced there is an issue of overcapitalization, given that many editors are trying to be consistent with the main draft article. Hey man im josh (talk) 16:07, 4 January 2024 (UTC)Reply[reply]
This is turning entrely circular. We've been over this already: the main article is capitalized, against WP:COMMONNAME and MOS:CAPS and WP:NCCAPS and other considerations, because a handful of "give us capitals or else" football fans want it that way, and will en masse blockade any RM that tries to change it, producing a FALSECONSENSUS against guidelines applying to a "magically special" wikiproject. The problem is not that the main article says what it does, the problem is that RM is easily and badly gamable by a wikiproject who want a "pet" variance from guidelines that apply to every other subject, which is prevent that or any other related article from changing names, without wider community input that cannot be gamed by half-a-dozen people from a particular wikiproject. — SMcCandlish☏¢ 😼 14:54, 5 January 2024 (UTC)Reply[reply]
Your best bet is to neutrally summarize all the pro and con arguments and counter arguments, and place them right after the brief opening RFC statement. Too often people are !voting without knowing all the factors, which is difficult when bits and pieces are scattered in other people's !votes. At least give those people who want to be informed a clear overview. MOS, esp. capitalization, can be quite nuanced. Some !voters that only see "NFL Draft" in their everyday sources, honestly don't know there are other options or why. —Bagumba (talk) 04:43, 5 January 2024 (UTC)Reply[reply]
If someone can point out a pro-capitalization argument, I'd like to see it so I can include it. About the only thing we heard before was a multiply-repeated claim to trademark status, but that was pretty thoroughly debunked, I felt, with the only found "NFL Draft" trademark being for clothing items, like caps and tee shirts, not for the player selection meeting. Dicklyon (talk) 00:42, 6 January 2024 (UTC)Reply[reply]
My understanding is that the NFL uses a capitalization for the term, but I'm not able to dig into it at the moment. For what it's worth, I personally don't really care either way, but I do advocate for consistency with the main article. Hey man im josh (talk) 01:04, 6 January 2024 (UTC)Reply[reply]
I imagine some !voters only see "NFL Draft" on ESPN, NFL.com—and even many (most?) newspapers—and just write off that non-NFL fans aren't following the NFL expert sources. —Bagumba (talk) 02:09, 6 January 2024 (UTC)Reply[reply]
If people are only watching ESPN, they'll see it pretty much always lowercase, and we wouldn't have this problem. On NFL.com, usually uppercase (but they sometimes forget to tell their headline writers, like here and here. Dicklyon (talk) 02:22, 6 January 2024 (UTC)Reply[reply]
You're right about ESPN. Try CBSSport.com, which seems to regularly cap. (And I might be wrong re: the extent of newspapers)—Bagumba (talk) 03:11, 6 January 2024 (UTC)Reply[reply]
If you can't get consensus for a move, then there's no consensus for a move. It's a tautological statement, but it's also the core fact of it all. Not enough people agree with you. So what, move on and don't dwell on it. Also, can we not have presumptive and biased discussion headers like calling it "over-capitalization" when the point is to discuss if it is properly capitalized. oknazevad (talk) 02:16, 6 January 2024 (UTC)Reply[reply]
Sure, we disagree there. It's clearly over-capitalized, with respect to our guidance and sources. The question is just what to do. Probably a central RFC makes more sense than an RM at the article(s), to get a more balanced participation. Dicklyon (talk) 02:22, 6 January 2024 (UTC)Reply[reply]
I think in order for you to get a 'green light' on the changes you're proposing? you'd first have to have an RM at National Football League Draft, with the result being - change to National Football League draft. GoodDay (talk) 02:46, 6 January 2024 (UTC)Reply[reply]
Please see Wikipedia talk:Naming conventions (companies)#Use of comma and abbreviation of Incorporated - a discussion (with some proposed revisions) to resolve apparent conflict between this page (with a {{Guideline}} tag on it but little community input) and various other guidelines and policies, including aspects of MOS:TM and MOS:INSTITUTIONS, WP:COMMONNAME and WP:CONCISE, WP:DAB, and the WP:OFFICIALNAME supplement, as well as the interplay between WP:RS and WP:ABOUTSELF. The short version is that NCCORP says to defer to "the company's own preference" on article naming (and in-text usage) matters such as whether to include a corporation-type designator, whether to abbreviate it, whether to include a comma before it, etc.; instead of deferring to predominant usage in secondary sources.
There has been significant discussion already, but it has stalled out completely over the holidays, and needs further input for resolution. Also some related discussion at a pair of back-to-back RMs at Talk:Mars Inc. — SMcCandlish☏¢ 😼 11:41, 2 January 2024 (UTC)Reply[reply]
Asking Advice About Giving Advice About Contentious Topic Protection
If another editor asks me for advice about their disagreement with the extended-confirmed protection of an article, where should I tell them to go to discuss the protection? I will explain the origin of this inquiry, but I am not asking specific advice about the case in point, but about all similar cases. A case request was made at DRN by a relatively new editor. The filing party had added some information to a biography of a living person. Their edits were then reverted by another editor, and the article was then placed under Palestine-Israel restrictions, including extended=confirmed protection. As a result, the new editor couldn't edit the article, and wanted the protection reviewed or appealed. I am not asking for advice about the specific article or its content dispute, because I think that the protecting admin was right. But what advice should I give in the future if another editor wants to ask about partial protection of an article because of a contentious topic? I could tell them to request unprotection at requests for protection, but that would just shift the question off to the admins at RFPP. I could say to discuss with the protecting administrator.
Also, even if the protection was removed, the new editor still can't make edits relating to Palestine-Israel. Galobtter (talk) 02:12, 5 January 2024 (UTC)Reply[reply]
User:Galobtter - Thank you for providing the information on appeals. I did explain that the protection was right.
I assume that you mean that the user still is not allowed to make Palestine-Israel edits. Protecting the page also protects the user from making the edits that they are forbidden from making. Robert McClenon (talk) 04:52, 5 January 2024 (UTC)Reply[reply]
Adding a policy bias against articles without sources
Currently, there are over 114,000 articles on Wikipedia that contain no citations or sources, making it one of the largest clean up categories on the site. WP:WikiProject Unreferenced articles has been one of the main WikiProjects attempting to dig through this giant haystack in order to give as many articles proper sources. Unfortunately, a main obstacle to cleanup has been how stringent deletion policy is. If you WP:PROD an article, it takes a week to delete, which is fine, and can be reversed by anyone. The issue is that many of these articles are unsourced stubs with no indicated notability, an article that me and others would agree to be a uncontroversial deletion via WP:PROD. Many of these PROD's are contested and then must go through the possibly month long review process VIA WP:AFD. The conclusion to this process usually is delete, but I believe that a criterion should be proposed that biases an article in favor of deletion, which is not having any sources. If this is written into the WP:DELETE policy, then I believe that editors like me will have a much easier time combing through the massive garbage dump that are unsourced articles. Tooncool64 (talk) 06:39, 5 January 2024 (UTC)Reply[reply]
Doesn't our current policy effectively do that? Editors arguing for notability are already required to provide or attest to the existence of sources which support notability. Horse Eye's Back (talk) 07:09, 5 January 2024 (UTC)Reply[reply]
True, but this is more directed at solidifying a valid reason for deletion, or a secondary reason, an article lacking sources, such that a PROD could say "Article fails WP:NGEO and WP:NOSOURCE", and be viewed as uncontroversial. Tooncool64 (talk) 07:12, 5 January 2024 (UTC)Reply[reply]
I think to some extent PROD will always be controversial. Horse Eye's Back (talk) 08:15, 5 January 2024 (UTC)Reply[reply]
Interesting. I wasn’t aware of that. I proposed deletion for this article [16] but the tag was reverted. The reason was supposedly that other elections later on are notable, but regardless, the problem is many of the earlier articles are unsourced and redundant, and many just redirect to the nominated Emperors' pages. Yr Enw (talk) 07:46, 5 January 2024 (UTC)Reply[reply]
Its not a great reason, but its nice that they gave a reason at all (none is actually required to remove a PROD). The next step would be opening a talk page discussion on notability, hopefully the editor who removed the PROD is willing to work with you to find sources and if not will be willing to support a move towards AFD. Horse Eye's Back (talk) 08:15, 5 January 2024 (UTC)Reply[reply]
I did talk page them, but they never responded. I get the need for collab, but often it can just become unintentional filibustering Yr Enw (talk) 09:19, 5 January 2024 (UTC)Reply[reply]
What if the concepts of WP:BLPPROD were expanded to non-BLPs without any sources? At a minimum, a deprod could be required add one reliable source.—Bagumba (talk) 08:35, 5 January 2024 (UTC)Reply[reply]
This might be the best option. I wasn't even aware of the WP:BLPROD policy myself, but having a similar policy apply to unsourced articles would allow for both one, editors to more quickly sift through unsourced articles, and two, editors who want to do specialized research to find obscure sources for articles that are proposed via this hypothetical process. If no sources can truly be found, reliable or otherwise, then it would be an uncontroversial deletion that would be able to avoid the lengthy WP:AFD process. Tooncool64 (talk) 08:43, 5 January 2024 (UTC)Reply[reply]
Support this idea myself as well. Let'srun (talk) 15:06, 6 January 2024 (UTC)Reply[reply]
Well, I don't. AfD exists for a reason: inclusion criteria are based on whether sources exist, and whether it's possible to write an article on a subject. They aren't based on whether Bill has time tomorrow afternoon to go get an interlibrary loan and then drive out to pick up eighteen books and spend the entire evening going through to frantically reference 53 articles before the guillotine falls. AfD lasts seven days. If an AfD is relisted because of lack of participation, it means that there isn't enough volunteer effort available to properly assess the article. If there isn't enough volunteer effort available to properly assess an article...there isn't enough volunteer effort available to come to a firm conclusion that the topic is non-notable. jp×g🗯️ 09:39, 6 January 2024 (UTC)Reply[reply]
If someone wants to re-create the article in the future with sources, then more power to them. It would be a soft-delete, allowing an editor to re-create the page. Tens of thousands of these articles have no reason to exist, no content, no usability for information. Like I said previously, Wikipedia is not meant for collecting items that exist. Tooncool64 (talk) 10:02, 6 January 2024 (UTC)Reply[reply]
Well, it's not meant to be a shoot-em-up game either -- the fact that deleting articles causes an enjoyable sensation on the back of the neck isn't a reason to do it. There are plenty of reasons why stubs exist. They're written by someone who had access to some information, or maybe to a lot of information, but who for whatever reason wrote a very short article; for the vast majority of them, it's completely possible to write something longer. If it's not, and the article is such a turd it needs to be wholly extirpated from the project, we have AfD, which sees approximately fifty nominations per day, with a turnover of somewhere around a week. In fact, we also have draftification, PRODs and speedy deletion -- that makes four separate processes by which stuff can be taken out of mainspace if it's bad. Why do we need another? jp×g🗯️ 10:33, 6 January 2024 (UTC)Reply[reply]
I can completely understand why many people where against this in the way it was worded. If an unsourced PROD were to exist, it would need to have at the very least a 7 day time limit, like current WP:PROD. The major reason I am in favor of something like this is because I believe, at the very least in 2024, articles on Wikipedia need to have sources, even if it is just one. No article would pass WP:AFC without sources attached. Tooncool64 (talk) 08:59, 5 January 2024 (UTC)Reply[reply]
Thanks for pointing that one out. After a quick glance, it seems it involved a new tagging process that people objected to, as opposed to just expanding a known process, PROD. The proposal just waved at a link, and some likely thought TLDR or made some wrong assumptions, and rejected for that reason. Not saying this would necessarily pass, but an improved presentation and concise pitch could go a long way. —Bagumba (talk) 09:18, 5 January 2024 (UTC)Reply[reply]
Yep. I tried an RfC on that. Snow-opposed. (Although the wording was really badly done, as I recall, so everyone was at least moderately confused.) 🌺 Cremastra (talk) 00:42, 7 January 2024 (UTC)Reply[reply]
This is close to becoming a perennial proposal. Policy is the way it is a foundational principle of this project is that imperfect content is an opportunity for collaboration, not something that needs to be expunged. If you instead choose to look at articles that fellow volunteers have taken the time to write as a "garbage dump" and deletion as the preferred way of dealing with them, then of course you're going to meet friction. – Joe (talk) 09:05, 5 January 2024 (UTC)Reply[reply]
My rhetoric might be harsh, but unfortunately, many of these unsourced articles are tens of thousands of one sentenced geography stubs, that may or may not even meet WP:NGEO, or tens of thousands of unsourced "Topic in Year" articles. If you are looking at these articles as part of a maintenance category, which they are, then you are forced to realize that many of these are not worth keeping, if for the very fact that they are unusable for information. Tooncool64 (talk) 09:13, 5 January 2024 (UTC)Reply[reply]
Clearly at least one person disagreed with you about that, or the articles wouldn't exist. – Joe (talk) 10:01, 5 January 2024 (UTC)Reply[reply]
Unfortunately, the standards for creating articles was much lower back in the day. Tooncool64 (talk) 10:04, 5 January 2024 (UTC)Reply[reply]
That's amazing how much hard work and care went into those articles! If an editor in the future wants to re-create an article that was deleted via this hypothetical process, it wouldn't be difficult. We do not need to hoard unsourced articles currently for the possibility in the future that they may be found to be notable. Tooncool64 (talk) 10:03, 6 January 2024 (UTC)Reply[reply]
Yes it will: our hypothetical editor will have to notice that something's a redlink (from where?), look through the deletion log, ask the deleting admin for a WP:REFUND, wait on a response, and then get it restored to their userspace or draftspace. This is a rather long and complicated process that, generally, only power users are able to do. What concrete benefit is brought by forcing them to go through this? jp×g🗯️ 10:33, 6 January 2024 (UTC)Reply[reply]
Or they can just...create the article themselves without going through REFUND... The difference between expanding and de novo creating a 1-sentence stub is like, the one minute it takes to create a 1-sentence stub... An admin could literally paste the entire REFUND of the text in an edit summary, it's not like we're talking about valuable starting material here. JoelleJay (talk) 18:24, 6 January 2024 (UTC)Reply[reply]
Creating a new article on a title that has been deleted before requires one to know that one is encouraged to recreate some, but far from all, deleted articles. The box that comes up for all deleted content is far from encouraging. Espresso Addict (talk) 11:13, 7 January 2024 (UTC)Reply[reply]
The problem in that regard is that the way PROD is set up collaboration is "encouraged, but not required." Why not require collaboration as a requirement of challenging a PROD? Horse Eye's Back (talk) 09:17, 5 January 2024 (UTC)Reply[reply]
The fallback collaboration option is a formal AfD. PROD offers some rare opportunites for lightweight deletions if nobody is looking or people agree and don't contest, but a WP:REFUND is typically possible. —Bagumba (talk) 09:24, 5 January 2024 (UTC)Reply[reply]
TBH I think the ideal collaboration option is actually in between the two... A talk page discussion should be able to settle the issue the vast majority of the time... If the challenger was required to open a talk page section with their rationale (preferably in the form of sources) I think that would go a long way towards facilitating collaboration without the wounded feelings that jumping to AfD can cause. Horse Eye's Back (talk) 09:35, 5 January 2024 (UTC)Reply[reply]
Honestly I consider PROD a failed experiment at this point. The grey zone between CSD and AfD is just too narrow to support an extra process, and the awkward process (add a template, wait a week, keep checking back in case it's removed and you need to turn it into an AfD) makes it useless for anybody who's patrolling articles en masse. – Joe (talk) 10:03, 5 January 2024 (UTC)Reply[reply]
I would love to see some statistics on PROD... What percentage get challenged... What percentage of those go to AfD... What percentage of those survive AfD... Horse Eye's Back (talk) 10:12, 5 January 2024 (UTC)Reply[reply]
The problem is that nominating an article for prod takes a few seconds, and editors often nominate many in a short space of time. Finding a source will often take hours or more, and needs to be specific to the article in question. They are not symmetrical operations. Espresso Addict (talk) 00:55, 6 January 2024 (UTC)Reply[reply]
The creator of the article can take as long as they need to find sources, years even. There is no need to create the article in mains space to work on it, it can be done in draft or namespace . Horse Eye's Back (talk) 10:15, 6 January 2024 (UTC)Reply[reply]
No problem with requiring sources for new articles, but we're talking about the backlog of old ones here. Espresso Addict (talk) 11:07, 7 January 2024 (UTC)Reply[reply]
There has never been a time when that wasn't true, its as true of the old ones as the new ones... If the creator didn't want them judged by mainspace standards they wouldn't have created the article in mainspace. Horse Eye's Back (talk) 15:52, 7 January 2024 (UTC)Reply[reply]
Requiring a source be added to dePROD an unsourced article would be ideal. JoelleJay (talk) 20:14, 5 January 2024 (UTC)Reply[reply]
oppose incredibly strongly. Merge and redirect them if you can't source them rather than run them through afd. Deletion isn't clean up. If the merger is undone, build consensus for the merge. Job done. There's no deadline. We don't need to constantly revise the rules to do the work, we just need to use the rules we've got to make Wikipedia better and coach the editors around us on the way to use the tools. Merge. Redirect. Build consensus that that's the right approach.HidingT 22:05, 5 January 2024 (UTC)Reply[reply]
Oppose. Haven't we discussed this recently? The existing procedures (prod, then AfD if challenged) are adequate for removing nonnotable unsourced material. Espresso Addict (talk) 00:32, 6 January 2024 (UTC)Reply[reply]
I think this is a bad idea for the reasons I've explained above. jp×g🗯️ 09:44, 6 January 2024 (UTC)Reply[reply]
Oppose. This proposal is not compatible with WP:NEXIST or WP:ATD. The topic of an unsourced article is often notable. The content of unsourced articles is often accurate and verifiable. In fact, the content of unsourced articles is often WP:BLUE. James500 (talk) 11:40, 6 January 2024 (UTC)Reply[reply]
“The content is often WP:Blue”… really? prove it! 😉 Blueboar (talk) 15:13, 6 January 2024 (UTC)Reply[reply]
So your suggestion is to merge unsourced material elsewhere...? JoelleJay (talk) 22:07, 6 January 2024 (UTC)Reply[reply]
If the info is unsourced, then we shouldn't be merging it anywhere. Lee Vilenski(talk • contribs) 00:47, 7 January 2024 (UTC)Reply[reply]
Nah, part of the merge process is either sourcing what is unsourced or discarding it and improper for merging. This discussion is about entire erstwhile articles with no sources, not about snippets of text without sources in articles that otherwise are sourced. — SMcCandlish☏¢ 😼 03:14, 7 January 2024 (UTC)Reply[reply]
Merge and redirect them if you can't source them is directing us to merge the unsourced content of an unsourced article into another article. JoelleJay (talk) 18:44, 7 January 2024 (UTC)Reply[reply]
Oppose. I agree with Hiding, above. We aleady have the policies we need; what we lack is editorial focus to get the job done. — SMcCandlish☏¢ 😼 03:14, 7 January 2024 (UTC)Reply[reply]
My idea would be to increase the “unsourced article deletion” time to 60 days. Then I would probably accept it. 71.239.86.150 (talk) 20:08, 7 January 2024 (UTC)Reply[reply]
RfC: Should a special PROD category, similar to WP:BLPROD, be created for unreferenced tagged articles?
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
Should a special PROD category, similar to WP:BLPROD, be created for unreferenced tagged articles? Tooncool64 (talk) 06:33, 8 January 2024 (UTC)Reply[reply]
This category for deletion would have four caveats.
1. Articles could be removed from this process by having at least one sourced attached to it, removing the unreferenced tag.
2. Articles held within this category would not be deleted until 30 days have passed, hopefully allowing editors ample time to go through these articles and potentially find sources.
3. This would not be an automatic process. Unsourced articles would optimally be only tagged for this special PROD after editors have looked for a source and have failed to find one.
4. This proposed PROD policy would not supersede WP:AFD or WP:CSD.
Survey (RFC for an unreferenced PROD procedure)
Oppose per Expresso Addict above and Phil Bridger below. This proposal is not compatible with WP:NEXIST or WP:ATD or WP:BEFORE. The topic of an unsourced article is often notable. The content of unsourced articles is often accurate and verifiable. This proposal was overwhelmingly rejected just three months ago. The word "optimally" in caveat 3 appears to mean that tagging without a search for sources would not actually be forbidden. Caveat 3 does not specify that the search for sources must comply with the "minimum search" specified by criteria D1 of WP:BEFORE, let alone require a search for sources on sites that are not indexed, or not properly indexed, by Google, and which can only be searched, or properly searched, with their own internal search engine. The proposal assumes that if at least one source exists, then someone will search for, find and add that source within 30 days. In view of WP:NOTCOMPULSORY, there is no reason to assume that anyone will do that, not even the closing admin. James500 (talk) 18:28, 8 January 2024 (UTC)Reply[reply]
Oppose Per my comment in the section below, which was made before the title of this section changed. Phil Bridger (talk) 21:02, 8 January 2024 (UTC)Reply[reply]
Oppose - purging articles without references after a 30-day waiting period will not contribute to building an encyclopaedia. What is more, as written this proposal will inevitably lead to editors stripping citations from articles that have references (whether due to concerns about source quality and relevance, or for quite different motives), then PRODding them under the new criterion. Of course similar things already happen prior to some AfD noms, but even our largely broken AfD process calls in more eyeballs than this new "unreferenced PROD" process would do - I imagine that if the initial tagging is turned over to bots and carried out at a mass scale, then the judgement of only one human editor would typically be involved in each deletion. Not in the interests of encyclopaedia-building, as I say. Newimpartial (talk) 21:24, 8 January 2024 (UTC)Reply[reply]
editors stripping citations from articles that have references [...] then PRODding them under the new criterion; yes, I have seen similar many times with BLPPRODs. Some IPs will vandalize a BLP by removing the citations and then an editor drive-by tags the article for BLPPROD without checking the page history. Curbon7 (talk) 22:18, 8 January 2024 (UTC)Reply[reply]
Oppose - As far as I can see, no examples have been given of unsourced articles that these proposals intend to target, so I looked in WP:WikiProject Unreferenced articles and cherry-picked a few: Echo chamber, Agricultural aircraft, Armoured companion. I don't see any value to the encyclopedia by speedily deleting articles like these. If they must go (and I hope they don't), then they should at least go through the AfD process. Toughpigs (talk) 22:17, 8 January 2024 (UTC)Reply[reply]
Support This is clearly going to fail, but my comment the previous time this was proposed remains valid: The current situation, through no fault of anyone else, amounts grandfather clause (old unreferenced articles survive, new ones usually get deleted), which is exactly what should not be happening* Pppery *it has begun... 06:07, 9 January 2024 (UTC)Reply[reply]
Support, per WP:V, which says any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation to a reliable source that directly supports the material. This will provide a practical way to challenge material in articles where there are no sources.
This change would also bring us into stronger alignment with WP:5P2, which says All articles must strive for verifiable accuracy, citing reliable, authoritative sources, especially when the topic is controversial or is about a living person.
Beyond policy and principles, we want to build an accurate encyclopedia that readers can trust, and we want to demonstrate through practice rather than instruction that new material, including articles, should be referenced ("Do as I say, not as I do"); this change will help towards both ends. BilledMammal (talk) 06:26, 9 January 2024 (UTC)Reply[reply]
Oppose. As I've said countless times the majority of old unsourced articles are valid topics for which sources exist (often in related articles or other language wikis) on uncontroversial topics which would never be outright deleted at AfD. I have spent time going through the unsourced categories in the past and can't recall encountering a single article that was a hoax or completely inaccurate. I would also estimate that a significant fraction of articles marked as unsourced (perhaps as much as a third) actually already have primary sources and/or external links present. I fail to see how deleting valid articles helps us to build an encyclopedia. (Also noting did not receive ping.) Espresso Addict (talk) 08:05, 9 January 2024 (UTC)Reply[reply]
@Tooncool64: I don't understand your fourth point. Anybody can recreate any non-protected page now, without going through WP:REFUND or anywhere else. WP:REFUND is for restoring a page (i.e. recreating it with its former content and history) and there is no way for a non-admin to do that without help. – Joe (talk) 07:13, 8 January 2024 (UTC)Reply[reply]
I see. I was under a different impression and confused about what can and cannot be re-created, will edit that now, thank you. Tooncool64 (talk) 07:15, 8 January 2024 (UTC)Reply[reply]
Yes, this would apply to all unsourced articles. No unsourced articles are being created today anyways, they wouldn't pass new page patrol. Tooncool64 (talk) 17:07, 8 January 2024 (UTC)Reply[reply]
No. This proposal was overwhelmingly rejected just three months ago. Let's spend our time looking for sources and using the many existing procedures rather than looking for new ways to delete articles. I note that there is a section for votes in support of this but none for votes against. Hardly neutral. Phil Bridger (talk) 11:15, 8 January 2024 (UTC)Reply[reply]
Votes "for" does not mean "votes in favor of", but "votes regarding". It is not meant for only supporting votes, obviously. Tooncool64 (talk) 17:05, 8 January 2024 (UTC)Reply[reply]
Personally, I don't think the bar for an article existing being a single source is strong enough, but that being said, adding a way to get articles that have never been sourced closer to either getting sourcing, or being removed is a positive in my book. Lee Vilenski(talk • contribs) 14:10, 8 January 2024 (UTC)Reply[reply]
RfC on capitalization in "NFL Draft"/"National Football League draft" etc.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Regarding the capitalization in "NFL Draft"/"National Football League draft" etc., should it be capitalized "Draft", or lowercase "draft", in article text and titles? With what exceptions, if any? 03:46, 6 January 2024 (UTC) Dicklyon (talk) 03:46, 6 January 2024 (UTC)Reply[reply]
Forum issue
Note: an editor felt that this subsection should come first, so rearranged it. The comments in the other subsections started earlier.
Inappropriate forum shopping There was no consensus at the last requested move, which was held at the actual article talk page, which is the right place for this discussion. This is not an RFC to determine a Wikipedia policy, the purpose of this page. This is not the right place for this. This is forum shopping plain and simple. oknazevad (talk) 04:57, 6 January 2024 (UTC)Reply[reply]
This RfC is not the norm. However, I think an exception is reasonable if it helps to break the continued "no consensus" regarding the NFL and its draft. —Bagumba (talk) 06:51, 6 January 2024 (UTC)Reply[reply]
Yes, any time consensus fails to be reached, another method of reaching it needs to be tried. Perpetual "no consensus" is not a stable or desirable result. — SMcCandlish☏¢ 😼 02:54, 7 January 2024 (UTC)Reply[reply]
Innapropriate forum, in good faith disagreement, this is an WP:RM issue. That's where name change requests go, including upper or lowercasing. There have been too many hard-argued discussions in the past to just up and change that. Wikipedia culture is in question here. You can do an RfC all you want but the result will be in dispute either way, and where do we go from there? RM is the only proper spot to decide this, Wikipedia culture-wise, and let that process play out as it always has. Randy Kryn (talk) 03:20, 7 January 2024 (UTC)Reply[reply]
It is a perfectly stable result. Any time there's an RM, the burden is on the proposer to convince enough other editors that there is consensus for a change. No consensus to change is perfectly stable because there's no change, which is the ultimate definition of stable! To say otherwise is silly. Just because the proposer can't accept that others don't agree with them doesn't make anything unstable. Maybe the proposer should learn to accept that they're not always right and learn to drop the stick. oknazevad (talk) 17:42, 7 January 2024 (UTC)Reply[reply]
Wrong forum. RM is the proper process for this; presumably the creator of this RfC understood this, or he wouldn't have initiated the last discussion as an RM in the first place. Not liking his chances of success at RM, though, because of "the large number of football-fan editors compared to the editors who want to respect our style guidelines", he asked village pump for advice on how to find a friendlier forum (#Over-capitalization of NFL Draft), the direct result of which is this RfC. This comes after having performed a series of undiscussed moves, [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29] (reverted afterward), despite knowing the precise issue was controversial when discussed less than a year ago, in violation of Wikipedia:Requested moves#Requesting controversial and potentially controversial moves. Centralized discussion isn't for something as parochial as capitalization of one word in one subtopic of one sport in one country. Imagine if every unsuccessful RM did this, unhappy that they didn't get the audience they hoped. Start another RM if you want. You might even be right. Sincerely. Adumbrativus (talk) 07:34, 6 January 2024 (UTC)Reply[reply]
Bad forum Even the proposer admits that this is here because "football-fan editors" at the last RM won't approve the move. This strikes me as pretty clearly forum shopping. I did see any indication there that the editors who participated are "football-fan editors", whatever those are. This has been brought up repeatedly by the same editor for years, and the answer to it is not to go in search of a friendlier forum. This is not an appeal court for failed RMs, the answer is a discussion and, if necessary, a further RM at the same forum. To the extent a vote is necessary, I vote for the current capitalization.--Wehwalt (talk) 18:19, 6 January 2024 (UTC)Reply[reply]
Forum-shopping seems to be what this is, to me. This user has proposed on numerous occasions to make this change, when rejected, for years, has repeatedly attempted to make the change to little-viewed pages to get it to pass by, and is now trying at a different forum to get this changed because "there's too many football fans at the normal routes to discuss this. I want it to be at a forum with non-experts because they're easier to convince to support me." I feel he should just WP:DROPTHESTICK. BeanieFan11 (talk) 18:37, 6 January 2024 (UTC)Reply[reply]
Oppose, already at the common name and styling. I don't know exactly where to put this, discussions like this shouldn't have multiple sections and sideroads but be in one 'Oppose or Support' section like any RM. Randy Kryn (talk) 23:35, 6 January 2024 (UTC)Reply[reply]
Striking this because it is not applicable here, this is not an RM and is an inappropriate forum for a requested move. Take this to WP:RM if there is a concern (apparently past RM's have been done on this question and kept the uppercasing, and then it shows up here on a tangential page). How about an administrator step in and stop this, thanks. Randy Kryn (talk) 13:57, 7 January 2024 (UTC)Reply[reply]
@Randy Kryn: Agree that these "sideroads" are confusing. Wehwalt re-factored to its currrent form here with the edit summary I'm dubious we should be refactoring what people have written, but if we are, the question of a bad forum is definitely preliminary to the question of whether this is a valid RfC and should come first It was dubious, esp. from an involved "forum" !voter, to refactor from the prior order within #Survey II. Closers are competent, and don't need this extent of spoonfeeding, and the self-prioritized order is non-neutral. Consider self-reverting. Thanks. —Bagumba (talk) 02:35, 7 January 2024 (UTC)Reply[reply]
Feel free to undo/repair whatever I did; sorry if I messed up. Dicklyon (talk) 03:04, 7 January 2024 (UTC)Reply[reply]
With the subsequent comments, the window to revert this has probably closed, without an elegant process to re-position the new comments. It is what it is. We probably need a neutral comment at the top noting that the order of this section is not to be misunderstood that forum concerns were the first reactions to the RfC. —Bagumba (talk) 04:56, 7 January 2024 (UTC)Reply[reply]
Perfectly good venue and process. See discussion a bit above this one. The fact that RM is being system-gamed by a handful of people from a single wikiproject, because it is a process actively watched and participated in by hardly anyone, and can be easily overwhelmed by a gaggle of single-topic-focused editors, is precisely why an RfC at a high-profile location for system-wide discussions is needed. Wikipedia is not a bureaucracy, and the RfC process can be used to address virtually any issue. See also WP:Consensus policy: consensus is established through discussion, and can form anywhere. Trying to short-circuit a discussion for coming to a consensus that has failed to be reached by previous narrower discussions is not constructive and comes across as completely disingenuous. PS: This is by no means unusual; e.g. how to address names of standardized animal breeds (versus landraces and other varieties) at MOS:LIFE was settled right here in VPPOL after various inconclusive/inconsistent RMs and related disputes (again among a small number of editors) resulted in stalemates. And that's hardly the only such case. Numerous failures to reach consensus on isolated pages with too much of a WP:CONLEVEL or "locals-only" WP:FALSECONSENSUS problem have been resolved at VPPOL. A prominent example being extensive stonewalled debate about an |ethnicity= parameter in biographical infoboxes was resolved here (with a firm community consensus against the parameter) after discussions at Template talk:Infobox person, thinly attended only by template editors and some WP:BLP and MOS:BIO regulars, failed to resolve the question. There is nothing unusual about using a VPPOL RfC for this, especially since it's what some of us advised Dicklyon to do. — SMcCandlish☏
This sectioning appears to be another inappropriate attempt to sway this discussion. Sheesh. BeanieFan11 (talk) 03:16, 7 January 2024 (UTC)Reply[reply]
BeanieFan11, it's good that you've joined the discussion, but you still haven't responded where I pinged you in the discussion above. It was hard to guess what your reasoning was. Sorry if the sectioning bothers you; attempting to keep organized isn't working so well. Dicklyon (talk) 03:51, 7 January 2024 (UTC)Reply[reply]
Please note that no notice of this fake RM (real RM's occur at WP:RM) has been put on the main articles being targeted or on any of the scores of related articles it would change. Again, an administrator should step in and stop this process and direct the nominator to take it to WP:RMand to put notices on all affected pages. Randy Kryn (talk) 14:03, 7 January 2024 (UTC)Reply[reply]
@Randy Kryn: You'd have to ping an administrator to this RFC, or contact the appropriate board, to get an administrator's attention. GoodDay (talk) 16:47, 7 January 2024 (UTC)Reply[reply]
It's laughable that you still think that because a discussion is at some obscure Wikipedia namespace talk page (and all Wikipedia talk namespace pages are obscure) that it automatically represents broader consensus that what happens in the article talk space where there dozens of not hundreds more involved editors. The usual suspects of lockstep support !votes doesn't make this the proper forum, no matter how much it might reflect your desired outcome. oknazevad (talk) 17:46, 7 January 2024 (UTC)Reply[reply]
Nothing nefarious here The 2016 RM, which resulted in captialization to "Draft", had procedural oversights; the move review was closed with ...interested users may start a fresh RM with due notification on the talk pages of all articles that would be affected. Dicklyon opened a 2023 RM, closed with no consensus. Following up on "no consensus", not to be confused with a consensus of "Not moved" (see WP:THREEOUTCOMES), is not a case of WP:IDIDNTHEARTHAT. The spirit of WP:FORUMSHOP is to discourage simultaneous discussions in different venues on the same topic. There is no other current formal discussion on this. At the aformentioned move review, the RM closer, JFG, wrote: The way forward, if you and others feel strongly about caps, would be to file an RfC at the appropriate wikiproject or sports venueWP:VPP has a wider audience of ~3700 page watchers, and notification was given at WT:NFL.—Bagumba (talk) 07:51, 8 January 2024 (UTC)Reply[reply]
I think the question is as much "what is the proper case for that main page?" So why should that page have capital "Draft"? —Bagumba (talk) 06:47, 6 January 2024 (UTC)Reply[reply]
I can't go along with 'lowercase' usage, as long as the main page is uppercased. GoodDay (talk) 17:49, 6 January 2024 (UTC)Reply[reply]
I know what's being suggested & I'll oppose it, as long as the main page is capitalized. Get NFL Draft moved to NFL draft & let the rest trickle down to all the related pages. GoodDay (talk) 17:57, 6 January 2024 (UTC)Reply[reply]
I'll leave others to decide on whether that page should be moved or not. Concerning American football, the last time I proposed anything at WP:NFL, the proposal was 'figuratively' shot down. GoodDay (talk) 18:06, 6 January 2024 (UTC)Reply[reply]
That's a very deeply indented "don't care". Thanks. Dicklyon (talk) 05:09, 7 January 2024 (UTC)Reply[reply]
This RfC would not move any page, it is an opinion survey. Case moves are done at WP:RM not at WP:Village pump (policy). Avoiding putting a tag of National Football League Draft through a Statue of Liberty play such as this calls for a 15-yard grabbing-the-facemask penalty. Randy Kryn (talk) 00:53, 9 January 2024 (UTC)Reply[reply]
Lowercase draft in article text and titles except where it's an obvious trademark (e.g. "He wore his trademarked NFL Draft tee shirt."), or where it's in a reference title that has it capped. Dicklyon (talk) 04:03, 6 January 2024 (UTC)Reply[reply]
Lowercase. Dicklyon's proposal is commendable, and his ngram surveys below win the day. GoodDay, what a main page uses has nothing to do with the question, in my view. Tony(talk) 04:49, 6 January 2024 (UTC)Reply[reply]
Lower case in titles and text, with the notable exception of where it is being used as part of a title of a broadcast or published piece (i.e., "Juanita Sportsexpert was the host of ESPN's NFL Draft 2037", "Manaheim Duffer wrote The NFL Draft: Secrets Behind the Selections.") -- Nat Gertler (talk) 07:44, 6 January 2024 (UTC)Reply[reply]
Upper case My !vote to retain the current title was refactored into a "Forum" section, and I restate it here.--Wehwalt (talk) 23:33, 6 January 2024 (UTC)Reply[reply]
If you'd like to go ahead and refactor it to here, I don't think anyone would have reason to complain. Dicklyon (talk) 03:54, 7 January 2024 (UTC)Reply[reply]
Lower case. It is unquestionably demonstrated that "NFL draft" and similar terms are not consistently treated as proper names in independent reliable sources, and frequently appear lower-case. "As long as the main page [on the subject] is capitalized" is in no way a sensible or meaningful opposition rationale; this RfC is about renaming that one as well. The entire problem here is that WP:RM has failed to come to a consensus about the entire set of such articles, because RM process has too few participants, and is easily overrun on any particular move discussion by even a small handful of wikiproject editors intent on defying WP:AT policy and WP:NCCAPS and MOS:CAPS and MOS:TM and other guidelines. — SMcCandlish☏¢ 😼 02:59, 7 January 2024 (UTC)Reply[reply]
Lowercase. This doesn't look complicated. Wikipedia has clear policies and guidelines saying to use lowercase when the sources are mixed or predominantly lowercase. Independent reliable sources are preferred over "official" ones, and there is no shortage of independent sources for this topic. Escalation to a place where participation is more broad is a way to encourage consistency. — BarrelProof (talk) 15:03, 8 January 2024 (UTC)Reply[reply]
Lowercase. Wikipedia policy should always trump a WikiProject, and here WP:NCCAPS and WP:MOSCAPS appear to apply. Let'srun (talk) 22:23, 8 January 2024 (UTC)Reply[reply]
Discussion II
Some recent history – It's a bit complicated; maybe I'll go further back later. Most sports settled on lowercase many years ago, but the NFL editors are a notable holdout. The most recent RM discussion at Talk:2024 NFL Draft#Requested move 27 April 2023 closed as "no consensus", with a few editors claiming that NFL Draft is a registered trademark, and others pointing out that that trademark (registered in 2019) is only registered as a marking on clothing items (e.g. hats and tee shirts) and that the player selection meeting does not have a trademarked name. Editors in favor of lowercase pointed out the overwhelming majority lowercase use of "draft" in sources (while one editor claimed, citing another who didn't, that "The vast majority of reliable sources capitalize the 'D' in draft"). Dicklyon (talk) 03:59, 6 January 2024 (UTC)Reply[reply]
When deciding how to format a trademark, editors should examine styles already in use by independent reliable sources. From among those, choose the style that most closely resembles standard English – regardless of the preference of the trademark owner.
An organization specifying the trademarks it is protecting is about preventing branding confusion, and not a naming decision by the organization, thus I don't think they should play a role in this discussion. A generic term can't be trademarked, because if, for example, I write a guide to the NFL draft, that's literally what it is and so I'm allowed to call it that. (If I make it clear my guide has no association with the NFL, the NFL doesn't have a case against me for trademark infringement.) So trademarks of that type will inevitably capitalize words. Even so, I'm not bound to use an uppercase "D" when writing "NFL draft" in my guide (or forced to use a lowercase "d", for that matter), just because it was trademarked with an uppercase "D". On the other hand, if I'm the office supplier to the location of the draft, and I try to claim that I'm the "Official paper clip supplier for the NFL draft", I'm fairly certain the use of a lowercase "d" won't save me. isaacl (talk) 03:30, 7 January 2024 (UTC)Reply[reply]
Keep it uppercase based on being a proper name and based on the NFL using this capitalization as well. Basically for all the same reasons we can't just move every article with "Final" in it's title to "final".
I'll chime in on this more tomorrow, but there's a long history of this request by Dicklyon. It comes up every couple of years and, I believe, when I was looking the other day it even goes back as far as 10 years. In all that time there's never been a consensus to downcase the name. After all this time, and the failed requested moves, I think it's time to let it be. Additionally, if you choose not to, I hope that people do not falsely claim that it's a WikiProject cabal stopping the articles from being down cased. There are members of the project on both sides of the matter. Hey man im josh (talk) 05:00, 6 January 2024 (UTC)Reply[reply]
Except it isn't based on a proper name. All involved were using the lower case for many, many years. It's a descriptive term. -- Nat Gertler (talk) 07:49, 6 January 2024 (UTC)Reply[reply]
Outside Wikipedia, and within certain specific fields (such as medicine), the usage of all-capital terms may be a proper way to feature new or important items. However these cases are typically examples of buzzwords, which by capitalization are (improperly) given special emphasis.
Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia.
The NFL, not being independent, should not be a factor in this determination. —Bagumba (talk) 08:02, 6 January 2024 (UTC)Reply[reply]
There's also never been a consensus that Wikipedia should capitalize Draft, even while most reliable sources use lowercase. That's why I opened the discussion above about what's a good process for trying to get to a consensus. The idea of an RFC was supported there. Dicklyon (talk) 17:43, 6 January 2024 (UTC)Reply[reply]
To avoid further 'discussion' in the survey section. I will change my position on this topic - only if/when National Football League Draft is moved to National Football League draft. GoodDay (talk) 18:02, 6 January 2024 (UTC)Reply[reply]
Some older history – The main article was moved in April 2005, without discussion, from NFL draft to NFL Draft, after being stable at lowercase for about a year since creation; the lead was changed from draft to Draft at that time, too. Interestingly, lowercase was even more prevalent in sources at that time, and this change in WP may have influenced an uptick in capitalization in books in the years that followed; see graph. Still, lowecase dominates. Dicklyon (talk) 20:34, 6 January 2024 (UTC)Reply[reply]
Yes, several times in each direction, including once by me. Dicklyon (talk) 22:42, 6 January 2024 (UTC)Reply[reply]
That probably should be brought back to uppercase, but I haven't checked common name etc. As for the NFL Draft, that's a capital "D" from the get-go. Randy Kryn (talk) 23:37, 6 January 2024 (UTC)Reply[reply]
From the get-go, the main article was at NFL draft, lowercase "d"; as in sources. It was changed without discussion, as I pointed out already. You have to pore through logs to find the move, but it was followed up by this lead edit. Dicklyon (talk) 01:54, 8 January 2024 (UTC)Reply[reply]
By "From the get go" I meant that the ordinary fan or reader is acceptable of the uppercased "Draft". Didn't know it's been uppercased since 2005. That's a pretty good run, and it should take extraordinary reasons to change it, which past no-consensus decisions have yet to find and nothing has changed lately except for common usage in media solidifying its common name recognizability. Randy Kryn (talk) 03:41, 8 January 2024 (UTC)Reply[reply]
Well, not since 2005 exactly. It spent a couple of years lowercase in between, too (2014–2016), and should have just stayed that way, like it should have from the get-go. Dicklyon (talk) 06:46, 8 January 2024 (UTC)Reply[reply]
Question: What is the article actually about - is it about which players were chosen by the various NFL teams? Or is it about the gala televised spectacular (with its interviews, and background clips) that contains the announcement? The TV program should probably be capitalized… the picking of players should not. Blueboar (talk) 00:59, 7 January 2024 (UTC)Reply[reply]
I see relatively little discussion of the gala, though typically the leads on the annual meetings (e.g. at 2010 NFL Draft) mention the venue, dates, and who televised it. They're mostly about the draft process, and which teams selected which players, and what deals went on, and such. E.g. a whole bunch of college team articles about who got drafted, such as List of Colorado State Rams in the NFL Draft and others like it that I moved a dozen of recently, but got reverted. Dicklyon (talk) 01:23, 7 January 2024 (UTC)Reply[reply]
And thanks for your sensible comments; I agree, as I spelled out under my exception to lowercase above. Here's how ESPN covered that 2010 gala at Radio City Music Hall that they televised: search hits. Dicklyon (talk) 03:02, 7 January 2024 (UTC)Reply[reply]
2024 NFL draft in the news, enough lowercase draft to show it's not consistently capped in sources (current news, plus already shown books and magazines):
Page title timeline There have been comments and innuendo about National Football League Draft's page title history. Here is a more specific timeline (due to lack of centralized history information on Wikipedia titles and moves, this might not be comprehensive. Feel free to update):
Thanks for filling in that history, Bagumba. My comment about it being lowercase 2014–2016 was not quite right; it was 2013–2016. What happened in 2016 was so gut-wrenchingly wrong that many of us complained loudly, but it stuck. As it happened it was your comment at the 2016 RM that was misinterpreted and wrongly applied to move all the articles even though the only article notified was a new one with no watchers. Sheesh. This is why I said there was never a consensus for capping all these articles. There just was not. Dicklyon (talk) 07:12, 8 January 2024 (UTC)Reply[reply]
For convenience, my !vote was:
Procedural oppose It doesnt make sense to just change this to uppercase without including into this RM the parent article NFL draft, and every other year's draft at Category:National Football League draft.
At the subsequent move review, I wrote:
In hindsight, the basis for my procedural oppose are the exact reasons we are here at Move Review now: lack of proper notification at related pages.
Comment - In future (and somewhat related to this RFC) may we have an RM at WP:SPORTS (for example), concerning whether or not all draft pages should have an uppercase "Draft" or lowercase "draft" in their titles? This would maintain consistency. GoodDay (talk) 18:42, 8 January 2024 (UTC)Reply[reply]
Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia
Hypothetically, "XYZ Draft" might mostly be capitalized in sources, even if "ABC draft" is not.—Bagumba (talk) 00:11, 9 January 2024 (UTC)Reply[reply]
The real question is what constitutes "a substantial majority". I've seen people say they think that threshold is about 90%. That's absolutely ridiculous. If two thirds of sources capitalize something, that should be enough to capitalize the Wikipedia article, let alone rations like 7/10, 3/4 or 8/10. Intentionally not capitalizing something even if two out of every three sources does just makes us look stupid. There's no other word for it. We need to set a firmer guidance than the current vague wording, and make it clear that the threshold is not some ridiculous level that puts our formatting firmly in the minority of real-world usage. Two-thirds is not too low of a threshold.
This is the discussion to actually have, and the only one that actually affects the writing or interpretation of policy. This back-door move discussion (which still doesn't have a pointer on the article itself) is not a policy discussion. oknazevad (talk) 02:44, 9 January 2024 (UTC)Reply[reply]
Yes, that's worthy of a serious discussion. But if we don't even follow guidelines when the data clearly show a majority lowercase, do you think that kind of splitting hairs is going to help anything? Dicklyon (talk) 03:30, 9 January 2024 (UTC)Reply[reply]
Question - Does this RFC include pages being 'moved' & likewise related links being changed? Examples - 2023 NFL Draft to 2023 NFL draft, AFC Championship Game to AFC Championship game? GoodDay (talk) 04:27, 9 January 2024 (UTC)Reply[reply]
Note: put survey responses above the #Discussion II header, not here.
Getting the name of an article right can sometimes make a big difference in readership. My example is the article Society of Jesus which from July 1, 2015 until August 22, 2022 was viewed 181 times per day. The name of the article was changed (with substantial opposition to the change) to Jesuits on August 23, 2022 and the article was viewed 1,685 times per day from then until January 7, 2024. I can't think of any explanation except the name change for the sudden increase in readership. Smallchief (talk) 14:34, 8 January 2024 (UTC)Reply[reply]
I'm fairly certain of two things Smallchief: 1) that this is not the right place for this discussion and 2) that you have misunderstood how the pageviewer tool interprets redirects (this link may help). ~~ AirshipJungleman29 (talk) 14:57, 8 January 2024 (UTC)Reply[reply]
I'm fairly certain (1) I don't understand what you're trying to say and (2) if naming articles isn't part of policy what is? Smallchief (talk) 16:07, 8 January 2024 (UTC)Reply[reply]
(1) What AirshipJungleman29 is saying is that the reason not many people were visiting Jesuits prior to 22 August 2022 is that the article was at Society of Jesus; if you look at the pageviews for that article from 2015 until the page was moved ([37]), you will find that it averaged 2,340 views/day. (2) There is indeed a policy regarding article names, but there are policies regarding everything on Wikipedia; WP:VPP is for proposing new policies or changes to existing policies and it is not clear what, if anything, you are proposing should change about our article naming policies. Caeciliusinhorto (talk) 20:38, 8 January 2024 (UTC)Reply[reply]
@InfiniteNexus I encountered the same bug about 10 minutes ago. Bug now, it seems that the this DB bug is resolved. Hooman Mallahzadeh (talk) 08:13, 4 December 2023 (UTC)Reply[reply]
To avoid creating high replication lag, this transaction was aborted because the write duration (3.465854883194) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[5b6f2722-25fb-4736-a8a1-061b5bc2d481] 2023-12-04 14:31:18: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
JFTR that edit went through in the meantime. And Phabricator indicates the developers are figuring it out. --Joy (talk) 17:05, 4 December 2023 (UTC)Reply[reply]
I also had errors on two edits in the last couple of hours. I didn't record the first but the second was [29eec93d-299b-4bdf-89d1-88caca3466b5] 2023-12-04 14:13:41: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" on this edit. Both worked after I used the browser's Back button and clicked Publish again. Certes (talk) 14:17, 4 December 2023 (UTC)Reply[reply]
Still getting an error on this. I was getting something about a transaction being too large and taking too long (>3 sec) for a couple attempts. This attempt I got
A database query error has occurred. This may indicate a bug in the software.
[4d773f04-424e-4f64-af0f-f259aa808ecd] 2023-12-04 14:44:28: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Attempts to edit my user sandbox page were successful.
I've been getting this error this morning too: To avoid creating high replication lag, this transaction was aborted because the write duration (15.307519674301) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead. [1cd8ddfe-f560-4300-b162-1d4d0448423c] 2023-12-04 16:19:03: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError" These aren't large changes I'm attempting. I have gotten a few edits through, but it's hit or miss. – Muboshgu (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
A database query error has occurred. This may indicate a bug in the software.
[38a2ed1b-239f-4448-841c-e65ec46331ef] 2023-12-04 08:28:23: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
I've tried a couple of different edit summaries, and I'm able to edit other articles. Could someone else please try reverting the edit? Thanks. DH85868993 (talk) 08:32, 4 December 2023 (UTC)Reply[reply]
Me as well at Vista, California ... [ab2894fb-78ff-4187-a212-713464e91635] 2023-12-04 12:22:58: Fatal exception of type "Wikimedia\Rdbms\DBQueryError". Magnolia677 (talk) 12:25, 4 December 2023 (UTC)Reply[reply]
Same here, at Deer Park, New York: [a4dc9654-fbed-48be-8eb3-a597446272e9] 2023-12-04 12:32:07: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"WikiDan61ChatMe!ReadMe!! 12:33, 4 December 2023 (UTC)Reply[reply]
And the same here (in the UK), from about 2 hours ago, editing Caligula, using MacBook. Sometimes it lets me edit but not save. Other times, it works fine but not for long. There's no pattern to it that I can discern. My Watchlist responds to changes in all other articles. Haploidavey (talk) 12:59, 4 December 2023 (UTC) Just tried a test edit, and was treated to the following:Reply[reply]
I am getting this with many different articles. Mellk (talk) 13:21, 4 December 2023 (UTC)Reply[reply]
Database error
To avoid creating high replication lag, this transaction was aborted because the write duration (5.7858679294586) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead.
[b08b554e-cf70-4cd8-8291-03dd2733d85a] 2023-12-04 13:01:46: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError"
Getting the same issue with the article Martin Artyukh. [85a67d40-833b-409f-a662-ba0486de9b09] 2023-12-04 15:51:16: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" --BlameRuiner (talk) 15:52, 4 December 2023 (UTC)Reply[reply]
Yup, I'm getting the same error across multiple articles - sometimes takes multiple attempts to get a change to save. Parsecboy (talk) 16:23, 4 December 2023 (UTC)Reply[reply]
Recovering from it?
When this error hits me, if I go "back" in the browser to get back to the text I was working on, all my changes are gone. This is actually weird behavior in Chrome. E.g., if I instead get an edit-conflict page, I can "Back" in the browser freely. But when this DB error happens, it's like it somehow messes up the page cache. Does anyone know of a way to recover the text that was being worked on? I have an article that did a whole lot of cleanup work in (probably a good half hour of it) and don't want to lose all that work if I can help it. I'm still sitting on the DB error page on that one. — SMcCandlish☏¢ 😼 14:08, 4 December 2023 (UTC)Reply[reply]
Update: I took a gamble, and it turns out that clicking the Reload button worked (caveats: in Chrome, and without triggering another DB error; I have no idea what another browser would do, or what would happen if the DB error had recurred, and it might, since in trying to make a typo fix at another page I had to try five times, though each time I did it as a manual edit, not a reload). — SMcCandlish☏¢ 😼 14:28, 4 December 2023 (UTC)Reply[reply]
FWIW in my Firefox, the back button got me back into the previous state, with the content and summary fields intact, so I can keep retrying trivially. --Joy (talk) 14:33, 4 December 2023 (UTC)Reply[reply]
I'm in Microsoft Edge, and the back button gets me to the state pre-submission, with edits and summary in place. Though I am now taking a copy of the text before clicking Publish. Tacyarg (talk) 14:55, 4 December 2023 (UTC)Reply[reply]
I'm using Chrome on a chromebook and if I hit the Back button, I get the original article state from when I hit edit (i.e., I lost my changes and edit summary). I'm just going to wait until it seems to be resolved before making any more edits. Kimen8 (talk) 14:58, 4 December 2023 (UTC)Reply[reply]
The reply tool is doing some rather dumb and bad stuff and I do not know how to fix it. I'm using the mobile website (the app, while nice for reading, is more or less unusable for editing and administrative tasks) on Android. The issue is with saved comments. If the reply tool has a saved partial comment, it will disable itself for any other comment on the page. Fine. But it will also gray out the expand button for the section it's in! It's impossible, then, to access the comment I have saved, or even to read the section it's in. It's also impossible to discard the comment so that the page works normally. The only way to fix it is to switch to the desktop display, then edit the URL to be the desktop URL, then scroll down to the section and cancel the reply, then go back to the mobile version and it will work again.
I don't think a noob is gonna figure this out.
Yall heard about this??? jp×g🗯️ 20:41, 30 December 2023 (UTC)Reply[reply]
@JPxG: I’ve also been having this issue, and the only thing that occasionally fixes it (ie. opens the section and allows me to continue typing the reply in mobile mode) is repeatedly refreshing the page until it decides to work. Wonder if it’s worth a phab ticket (unless it’s already got one?). Best, —a smart kitten[meow] 21:34, 30 December 2023 (UTC)Reply[reply]
Oh yeah, ReplyTool does this to me too. I think I've been able to open the source editor and publish an edit to the page, which restores my ability to discard the saved comment. It will trigger the inaccessible comment subroutine any time I close a tab with a comment neither published nor discarded. Folly Mox (talk) 01:41, 5 January 2024 (UTC)Reply[reply]
Man the reply tool is really "on some other shiznit" as the kids say, I can't reply to this either. jp×g🗯️ 21:42, 30 December 2023 (UTC)Reply[reply]
Is this phab:T338920? I searched Phabricator and found this other ticket, which looks like the issue in question; but that was closed in favour of re-opening the aforementioned task. Best, —a smart kitten[meow] 02:08, 3 January 2024 (UTC)Reply[reply]
Pages with most transclusions of a template
Is there a way to easily identify which page has the most transclusions of a particular template? For example, which article has the most {{citation needed}} tags? Nikkimaria (talk) 00:35, 1 January 2024 (UTC)Reply[reply]
Nikkimaria, I am fairly sure the answer is no, because that would require looking at the source text. — Qwerfjkltalk 09:52, 1 January 2024 (UTC)Reply[reply]
insource:... is a longstanding feature of the search interface. If you want to make the servers fall over, you could craft a regex (see mw:Help:CirrusSearch#Regular_expression_searches) to look for "at least 100" of a template. Then depending on how many hits you get, look for "at least 200" or "at least 50", gradually narrowing down the largest number of uses. Maybe the WP:Quarry magicians can help? DMacks (talk) 10:13, 1 January 2024 (UTC)Reply[reply]
Quarry won't be able to help with this, because it has no access to the wikitext. The nearest it could manage is to list pages with one or more tags, without saying how many tags each page has, which is insufficient and more easily done by other means. Cirrus search has its own flavour of regular expression which lacks many features found in most flavours. In particular, Cirrus lacks a syntax such as (Foo){100} meaning 100 occurrences of Foo. It would have to be written out in full, grossly exceeding the 300-character limit for search expressions. It's a job for a (simple) custom program running on a database dump. Certes (talk) 12:32, 1 January 2024 (UTC)Reply[reply]
I agree this would be easy on a local dump:) But the CirrusSearch docs say grouping and repetition-count are supported. And I just verified that my test page containing the string:
foo wocka foo fiddle foo banana foo more
was found by
insource:/(foo.*){XXX}/
when XXX was any single number 1–4 (but not any larger) or any range of numbers (comma-separated) that included at least any subset of 1–4 (but not if it only included 5+). Not surprisingly,
insource:/(\{\{citation needed.*){10,25}/
timed out. But before doing so it did find >20 results and spot-checking they do have at least 10 CNs. DMacks (talk) 13:23, 1 January 2024 (UTC)Reply[reply]
Hey, let's play kill-the-wiki!
insource:/(\{\{citation needed.*){100}/
limited to mainspace timed out after finding 8 results:
so there are at least these articles with 100+ literal CN tags in their wikisource. In Kazuhiko Inoue, they are all in a commented-out table. DMacks (talk) 13:46, 1 January 2024 (UTC)Reply[reply]
Thanks, I never knew Cirrus supported {n} – I always wondered why { and } were special characters! A shorter version of kill-the-wiki
produces one result and might find most cases if repeated for B–Z (and prefix:2, which has several). Certes (talk) 14:24, 1 January 2024 (UTC)Reply[reply]
Now just need to find out what < and > do.— Qwerfjkltalk 16:31, 1 January 2024 (UTC)Reply[reply]
< and > are for number ranges, e.g. <1998-2002> finds any of those five years. Certes (talk) 20:05, 3 January 2024 (UTC)Reply[reply]
I suppose one added problem here is that 550k+ pages transclude {{citation needed}} but another 35k have {{fact}} & 97k have {{cn}} (plus a couple of thousand in total using one of the more obscure redirects). I guess about 20% of uses are using a variant form, and presumably some fair chunk of articles that have built up tags over time will use a mixture of formats? Andrew Gray (talk) 18:32, 3 January 2024 (UTC)Reply[reply]
There are 70 redirects from {{Are you sure?}} to {{Uncited}}. In theory, we could check them all. In practice, only the two you mention are probably worth the bother.
Somehow, in Integrated Software for Imagers and Spectrometers, this (basically, "Alessandro Frigeria,d,*, Trent Hareb, Markus Netelerc, Angioletta Coradinia, Costanzo Federico d, Roberto Oroseia"), got scraped into Wikipedia as "Alessandro Frigeria,d,n, Trent Hareb, Markus Netelerc, Angioletta Coradinia, Costanzo Federicod, Roberto Oroseia". This sort of thing could potentially leave readers searching for the "Trent Hareb" or "Costanzo Federicod" erroneously listed here. Any thoughts on how to find and fix instances of this? BD2412T 14:45, 1 January 2024 (UTC)Reply[reply]
It happened in [40]. The link syntax was completely wrong and clearly not made by a tool so I assume the user manually copy-pasted from the PDF. I don't see a practical way to discover similar human errors. This user hasn't edited since 2020. I don't know whether any of our tools can make similar errors. PrimeHunter (talk) 22:50, 1 January 2024 (UTC)Reply[reply]
Thanks, I am astounded. BD2412T 03:49, 2 January 2024 (UTC)Reply[reply]
Not surprising. Entry of long lists of journal author names is error prone for this reason, cut and paste then fail on manual cleanup. I've had this problem personally (though not this severe). It should be possible for a bot to retrieve the names from a source (DOI?) and compare it with the names in the citation. It could verify not only misspellings but also normalize abbreviations "James A. P. Smith" vs "James AP Smith", check for missing names, and for long lists with et al. create something like Footnote #5 in Rising Star Cave. It would have be a tool or usertool with diff preview. We have all sorts of issues like this and a lack of programmers to make the tools. Another one is a tool to generate |author-link=. A tool to convert |author= to |first= / |last=. It goes on. -- GreenC 04:20, 2 January 2024 (UTC)Reply[reply]
Formatting citations is one of the most irritating parts of Wikipedia editing. I suspect that one's eyes glaze over after only a little time and then such errors happen. Jo-Jo Eumerus (talk) 08:39, 2 January 2024 (UTC)Reply[reply]
Those who are focused on this kind of work, automated citation maintenance, could get masters degrees. This is no joke. For example the history of {{cite encyclopedia}} and its polysemic |title= field could easily fill at least a class or two. A masters thesis on how to rewrite this template and how to implement those changes, technically and politically, would be most helpful. We have thousands of other citation template varieties to consider. -- GreenC 18:02, 3 January 2024 (UTC)Reply[reply]
PrimeHunter, I suppose you could look for a, b, c etc. at the end of author names. — Qwerfjkltalk 10:15, 2 January 2024 (UTC)Reply[reply]
Massviews
I would like to run off a list of the most popular articles under Category:WikiProject Military history articles in 2023 but massviews is limited to 20,000 "for performance reasons" (getting the wrong answer more quickly). Is there a way to run this query? Hawkeye7(discuss) 02:41, 4 January 2024 (UTC)Reply[reply]
Lua errors for not enough memory seem to be popping up in articles - Google Chrome is an example. I expect this may quickly become an UBN in Phabricator but I wanted to drop a note about it in VPT. Best, —a smart kitten[meow] 00:05, 5 January 2024 (UTC)Reply[reply]
Okay, on further inspection it might just be the Google Chrome article, and this thankfully might not be as much of a problem as immediately thought. —a smart kitten[meow] 00:14, 5 January 2024 (UTC)Reply[reply]
I previewed {{Infobox software}} alone with no parameters on the article and "Parser profiling data" at the bottom said Lua memory usage 49,651,978/52,428,800 bytes. That's 95% of the limit. PrimeHunter (talk) 00:20, 5 January 2024 (UTC)Reply[reply]
The problem is d:Q777. Infobox software is running out of memory because it's trying to get data from a 2MB wikidata page for the version numbers. Fixed here. – Hilst[talk] 00:36, 5 January 2024 (UTC)Reply[reply]
Sidenote -- in my opinion, even though the immediate error has been resolved, it's still worth this being looked into if anyone has the time (and/or patience), as I don't know if it should be possible to break an article on enwiki through good faith additions to its item on Wikidata. I'll put a link to this section at Template talk:Infobox software as that seems to be the template that temporarily broke the article. Best, —a smart kitten[meow] 00:58, 5 January 2024 (UTC)Reply[reply]
Vector (2022) still has limited width with the skin setting turned off
The thing is, if you click the preview link in Preferences, it displays correctly as if the setting is in effect, but otherwise it is not. KPu3uC B Poccuu (talk) 04:58, 5 January 2024 (UTC)Reply[reply]
Have you tried to Bypass your cache ? It looks like one of the css files is missing, maybe it was cached incorrectly in your browser. —TheDJ (talk • contribs) 12:56, 5 January 2024 (UTC)Reply[reply]
(edit conflict) @Tom.Reding: That's the safemode look of Wikipedia when some CSS isn't loaded. It works for me in Firefox. Make sure "Always enable safe mode" is disabled at Special:Preferences#mw-prefsection-rendering (it probably already is when other skins work). Try to bypass your cache. Use Ctrl+F5 in Windows browsers, not F5 or the reload button alone. If it still happens then does it go away if you log out? What is your browser? What did you do to get black background? PrimeHunter (talk) 12:58, 5 January 2024 (UTC)Reply[reply]
Make use mdy dates have effect on the as of template
I can't figure out how {{use mdy dates}} works, and could somebody make {{as of}} automatically change date formats based on it? Aaron Liu (talk) 22:26, 5 January 2024 (UTC)Reply[reply]
The primary function of that template is to assign a tracking category. Secondarily, when Citation Style 1 templates (like {{cite web}}) are used, date formats in those citation templates are rendered to match the {{use mdy dates}} or {{use dmy dates}} template, as described in the template's documentation. Making {{as of}} behave like {{cite web}} automatically is probably not trivial, but there are some good coders around here. Since {{use mdy dates}} or its sibling template should be stable on a given page, adding |df= to a given {{as of}} template transclusion shouldn't be that much work. – Jonesey95 (talk) 23:48, 5 January 2024 (UTC)Reply[reply]
How do the citation modules detect the dateformat templates? I couldn't find anything in the source code. Do they just scan the page content for the template syntax? Aaron Liu (talk) 00:27, 6 January 2024 (UTC)Reply[reply]
Not so difficult really. Because the date-format detection code is in a module that is loaded using mw.loadData ('Module:Citation/CS1/Configuration'), it's relatively inexpensive to write a small module that will use the global_df value that ~/Configuration creates. See Module:Sandbox/Trappist the monk/as of.
My sandbox has {{use mdy dates}} and live and sandbox versions of {{as of}}. {{as of/sandbox}} auto-formats to the mdy date format.
Just because this is relatively easy to do does not necessarily mean that we should be doing it. That is a question for a different venue.
The way Vector 2022 displays seems to have altered on my PC screen, though not on my Android device. On my PC I use the Vector 2022 Skin on Chrome, on Windows 10; on my Android I also edit using the Chrome browser rather than an app, using Desktop view with the Vector 2022 skin. Since yesterday, my PC has displayed pages differently, with a large left sidebar rather than a drop-down toolbar under the search bar. Pages still display correctly on my Android, and I have not altered my preferences. I am not aware of any change I have made on my PC which could cause this behaviour. Can anyone suggest what might have happened to cause this and how I can recover my preferred display without the obtrusive sidebar? RolandR (talk) 22:30, 5 January 2024 (UTC)Reply[reply]
Did you try clicking the "hide" link at the top of the sidebar? – Jonesey95 (talk) 23:49, 5 January 2024 (UTC)Reply[reply]
There doesn't seem to be one. RolandR (talk) 03:50, 6 January 2024 (UTC)Reply[reply]
I have discovered that if I log out of Wikipedia, the Hide link appears and I can close the sidebar. But as soon as I log in again, the sidebar reappears, and the Hide does not stick. There seems to be something in my settings which blocks this, but I can't figure out what, or why it should suddenly have started. RolandR (talk) 23:28, 7 January 2024 (UTC)Reply[reply]
Sounds like it is maybe a gadget or a user script. You have a "User:PleaseStand/hide-vector-sidebar.js" in your common.js, maybe that's it ? —TheDJ (talk • contribs) 09:28, 9 January 2024 (UTC)Reply[reply]
android app login
How do I log into the Android app? The only settings I see are "Customize toolbar" Uhoj (talk) 01:45, 6 January 2024 (UTC)Reply[reply]
Uhoj, it's a bit hidden when you've got an article open. First, find and tap the "Explore" button in either the bottom bar or the top right three-dot menu (screenshot). That should bring you to a page with a "More" button in the bottom right corner of the screen (screenshot). Tap that and you should see a menu with a login button. Rummskartoffel 11:12, 6 January 2024 (UTC)Reply[reply]
DOI links give generic citations in VE citation tool
Hi all
I'm working on a partnership with FAO (the part of the UN that works on Food and Agriculture). I have a question about the VE citation tool, when I try to cite their links which all use a DOI eg https://doi.org/10.4060/cc7937en the citation tool doesn't give the name of the publication, just 'publication preview page'. Can someone tell me why this is happening so that I can ask them to change it so their DOI links work with the VE citation tool?
Might be an issue with the information passed on to Zotero, my understanding is that Citoid draws its information from there. Jo-Jo Eumerus (talk) 07:18, 7 January 2024 (UTC)Reply[reply]
Thank you Jo-Jo Eumerus is there anywhere I can ask or anyone I can ask who would know about this and specifically what to change at their end to make this work properly? John Cummings (talk) 08:53, 7 January 2024 (UTC)Reply[reply]
And it looks like it is gathering information from the metadata of the target page, e.g. <meta property="og:title" content="Publication preview page | FAO | Food and Agriculture Organization of the United Nations" />. — Jts1882 | talk 14:25, 7 January 2024 (UTC)Reply[reply]
Hey, everyone. I did a disk clean-up the other day and appear to have checked too many boxes. My memorized edit summaries are gone and, worst of all, they do not seem to be being recorded again. It means that I have to type out all of my detailed edit summaries every time I edit instead of using autocomplete. What do I do? Surtsicna (talk) 13:09, 7 January 2024 (UTC)Reply[reply]
On my computer, those edit summaries are remembered by my web browser (Firefox), not by Wikipedia. See this help page for instructions on how to tell a browser to remember form field entries. – Jonesey95 (talk) 14:40, 7 January 2024 (UTC)Reply[reply]
Well, you could get a list of your edit summaries and put them into your own Default Summaries gadget (paste it in lines 20-24 and lines 27-33), at least until your browser remembers them again. Do you use all of your edit summaries, or is there an delimiter, like last x days or top x used ? Snævar (talk) 16:12, 7 January 2024 (UTC)Reply[reply]
spacing between non-indented paragraphes and indented lines
Under the headers, the spacing between the first paragraph and the following colon-indented line is larger than the spacing between subsequent colon-indented lines. There is no excess space in the code. I'm using Safari 17.2.1 on macOS Sonoma 14.2.1. — Fourthords | =Λ= | 17:29, 7 January 2024 (UTC)Reply[reply]
I can replicate this, at least in Vector 2022 (logged in or logged out, in Firefox and Brave for Mac OS). The colon-indented paragraphs are in one big block whose CSS includes
The opening (non-colon-indented) paragraph's CSS includes
.vector-bodyp{margin:0.5em01em0;}
the relevant portion of which translates to
margin-bottom:1em;
Someone more versed in site-wide CSS will have to take it from here, or debunk my research with a better explanation. – Jonesey95 (talk) 18:29, 7 January 2024 (UTC)Reply[reply]
Thanks for getting much further than I did! Is this the/a correct venue for this, or should I have posted it somewhere else? — Fourthords | =Λ= | 15:07, 8 January 2024 (UTC)Reply[reply]
It makes general sense -- a top-level block of text is a <p>, but the : syntax creates (nested) definition-lists and the text within them will just be contained in <dd>s. CSS that applies spacing to paragraphs won't automatically also apply to list items.
It's plausible that we should have Vector 2022 incorporate its own version of that override to the .ns-talk list item spacing. DLynch (WMF) (talk) 23:52, 8 January 2024 (UTC)Reply[reply]
(Or amend the site CSS to match the presumably-new paragraph spacing in Vector 2022.) DLynch (WMF) (talk) 23:57, 8 January 2024 (UTC)Reply[reply]
The left sidebar buttons on Wikipedia mobile don't work, when I push on them the list simply hides again/exits. I've tried this on multiple Android phones all running the latest Android Google Chrome version and have ran into the same problem everytime. I can't even log in from the mobile site, I have to first scroll down to the bottom to force desktop then I can log in and then go back to mobile after. I have no problems editing articles using the mobile version however. Bzik2324 (talk) 19:55, 7 January 2024 (UTC)Reply[reply]
@Bzik2324: I can reproduce this on both Firefox and Chrome on Android 14. And yet, you've asked this question twice without a single "me too". So there must be something unusual about our settings. Do you have animations turned off under Android Settings -> Accessibility -> Visual Enhancements -> Remove animations? Does the boat move at WP:Articles for deletion/Ever Given? If you turn animations back on, does the problem go away? Suffusion of Yellow (talk) 22:15, 8 January 2024 (UTC)Reply[reply]
Does anyone know how to change the RefToolbar so that it is compatible with sfn?
Currently, the Wikipedia:RefToolbar/2.0 outputs a template within ref tags. Is there anyone who knows how to write an userscript or gadget with similar functionality that instead outputs a template w/o ref tags, but with a pre-filled {{sfn}} output? I don't know anything about how to write JS. Jo-Jo Eumerus (talk) 07:55, 8 January 2024 (UTC)Reply[reply]
I don't think VE has anything in the cite-making for making sfn:s either. Gråbergs Gråa Sång (talk) 10:30, 8 January 2024 (UTC)Reply[reply]
I'll ask a few technically versed editors if they know of any such script, or how to make one. Jo-Jo Eumerus (talk) 06:51, 9 January 2024 (UTC)Reply[reply]
Adaptive multiple tables
If an article has several small tables, it is often "nicer" to have them displayed in a row rather than in a narrow vertical column. This fine for large screens, but on a mobile or other small screen it is better to have the tables float into several rows to match the available display. To do this, I have used an inline-table style like this:
This does indeed work. However, is there a better way? Is there a more "official" way? — GhostInTheMachinetalk to me 14:38, 8 January 2024 (UTC)Reply[reply]
Can't you just use {| style="float:left" on each table? — Jts1882 | talk 15:01, 8 January 2024 (UTC)Reply[reply]
I can! I used float:left; margin-right:1em; That works too and is a lot simpler. Thanks. Any view about an "official" way? — GhostInTheMachinetalk to me 17:06, 8 January 2024 (UTC)Reply[reply]
I've noticed this curious case regarding Google's behaviour in indexing Wikipedia. The page Elephant duel was created as a redirect to War Elephant in 2009. I converted it into an article on 3 October 2023, but so far Google has refused to show it in its search results, not even when specifying the Wikipedia domain in the query. However, it is shown as a knowledge panel. Other search engines behave normally, so the problem lies with Google, but I'm curious if anyone has an idea of what might be going on? The article isn't a new page, so it shouldn't have anything to do with the 90-day noindexing. --Paul_012 (talk) 16:32, 8 January 2024 (UTC)Reply[reply]
Pages which are newly converted from redirects must go through NPP the same as others. Izno (talk) 19:35, 8 January 2024 (UTC)Reply[reply]
Paul_012 is autopatrolled since 2017 so an article creation should allow indexing right away. Does that not apply when autopatrollers convert a redirect? PrimeHunter (talk) 21:06, 8 January 2024 (UTC)Reply[reply]
Also it's already beyond 90 days, and the knowledge panel shows up long before then (as well as the Bing results). --Paul_012 (talk) 04:51, 9 January 2024 (UTC)Reply[reply]
Searching for the source of the user-facing "email this user" guidance
Where is the text in the box at the top of the Email this user special page coming from?
Presumably SpecialEmailUser.php is the code that runs the special page for sending email, but if the boxed message at the top of that page isn't part of the code base, where does that code get it from? This is not easy to figure out. How does public function sendEmailForm() generate the "send email form"? Is the box above the form part of the form, or separate from it? wbm1058 (talk) 18:39, 8 January 2024 (UTC)Reply[reply]
Yes, and the message is customized here at the English Wikipedia. The default message can be seen at MediaWiki:Emailpagetext/qqx. See WP:QQX for tips to find system messages. PrimeHunter (talk) 21:13, 8 January 2024 (UTC)Reply[reply]
At least it's an intuitive shortcut. — Qwerfjkltalk 21:17, 8 January 2024 (UTC)Reply[reply]
Right. QQX. I have no idea what that acronym stands for. Thanks for your help. I recall being shown this trick before, but had forgotten the specific syntax that was used.
I guess this is the line of code that findsMediaWiki:Emailpagetext, since it's the only place I found 'emailpagetext' in the code:
qqx is a special code which can be deployed for internal purposes. MediaWiki uses it to request debugging information. Certes (talk) 23:08, 8 January 2024 (UTC)Reply[reply]
I made the redirect WP:QQX for users who already know there is something called qqx and search for it. Somebody else added {{Shortcut|WP:QQX}} at the target section. PrimeHunter (talk) 23:13, 8 January 2024 (UTC)Reply[reply]
@Wbm1058:qqx isn't an acronym, it doesn't stand for anything. See ISO 639-2#Reserved for local use, which has: The interval from qaa to qtz is "reserved for local use" and is not used in ISO 639-2 nor in ISO 639-3. Therefore, we can use qqx as an unofficial pseudo-language code, safe in the knowledge that the ISO will never allocate it to a real-world language. --Redrose64 🌹 (talk) 00:17, 9 January 2024 (UTC)Reply[reply]
Tech News: 2024-02
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
mediawiki2latex is a tool that converts wiki content into the formats of LaTeX, PDF, ODT, and EPUB. The code now runs many times faster due to recent improvements. There is also an optional Docker container you can install on your local machine.
The way that Random pages are selected has been updated. This will slowly reduce the problem of some pages having a lower chance of appearing. [41]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 January. It will be on non-Wikipedia wikis and some Wikipedias from 10 January. It will be on all wikis from 11 January (calendar). [42][43]
also, currently the only 2 given news sources nyt and ap are both american organisations. by adding the 4 below, there will be 3 american vs 2 british and 1 global, which will be less usa-centric as a whole.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
consensus seems to be against adding these sources. theleekycauldron (talk • she/her) 22:26, 25 December 2023 (UTC)Reply[reply]
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.
Add reuters
support because reuters is better than AP (in its scope), and NYT (in everything).--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Neutral: Reuters is ok to add but I'm not sure we need many more links. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations. GenQuest"scribble" 07:15, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support as stated by the first support they are superior to the NYT. --Emir of Wikipedia (talk) 15:18, 24 December 2023 (UTC)Reply[reply]
Add BBC
support because bbc news is probably the most reputable among the most visited news websites, and the most visited among reputable news websites. and it's free, no login and whatnot.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose in favor of something more WP:WRS-like, as suggested just above. We don't have links to individual scientific journals; why should we have links to individual news outlets? XOR'easter (talk) 17:52, 28 November 2023 (UTC)Reply[reply]
Oppose: BBC is usually ok but it's even more prone to the political winds of one country; not suitable. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:31, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB and echoing XOR'easter, remove all individual news outlets as source recommendations, we don't do journals or magazines, so there's no need for profit-driven newspapers either. GenQuest"scribble" 07:29, 4 December 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose — the WSJ hard paywall makes the site impractical to use for a large number of editors, and it goes against Wikipedia's free-content ideals. —pythoncoder (talk | contribs) 04:15, 27 November 2023 (UTC)Reply[reply]
Oppose in favor of a general custom search engine, as suggested above. We go through the trouble of identifying "generally reliable" sources; we might as well benefit from all that work. As to the point about controversies raised above, plenty of those at the NYT have been about its editorial positions rather than its reporting, and, well, the WSJ is no stranger to that, either. I don't see why circulation is relevant in this context. XOR'easter (talk) 17:44, 28 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:31, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb; because the WSJ has a hard paywall; and because its web archives only go back to the late 1990s. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Add The Times
support because The Times is better than nyt. for example, a company has created an archive of it for scholars to study it. do you see people doing that for nyt? as the most important newspaper of a country that once ruled many countries around the world, it reported a lot more on news around the world for a much longer period, compared to the usa-centric nyt.--RZuo (talk) 15:19, 24 November 2023 (UTC)Reply[reply]
Oppose in favour of a general custom search engine that searches for all reliable outlets, something WP:WRS was supposed to offer before being abandoned. I proposed a mock-up here, but I will listen to all your suggestions. {{search for}} is great! Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Oppose, it seems even more paywalled. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
Oppose per Sdkb, remove individual news outlets. Eddie891TalkWork 15:32, 29 November 2023 (UTC)Reply[reply]
Oppose per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:32, 4 December 2023 (UTC)Reply[reply]
Oppose in favor of removing all individual news outlets, per Sdkb. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Remove all individual news outlets
Yikes. Let's take a step back here. As background, the module we're talking about is what produces the links seen mainly at the bottom of the 700k instances of {{Talk header}}. The goal is to help make it easier to find sources on a topic. However, that needs to be balanced with the imperative to keep the links in Talk header as minimized as possible to combat the notorious banner bloat on talk pages. So when we're thinking about which links to include or exclude, the frame should not be "might a few people find this helpful?" but rather "is this essential?"
In light of that, let's consider how people use this template. When I'm searching for sources for a Wikipedia article, I'm not interested only in what The New York Times, or Reuters, or the WSJ, or any other individual news outlet has to say on it (since Wikipedia articles are supposed to summarize all the reliable sources on a topic, not just a single source). So the main link I want to find news coverage is the Google News search, which will turn up those outlets as well as any others. And lucky me, that link already exists in the list, along with other links to places that collect works from many different publications (like JSTOR). The NYT link long stood out as the sole link to an individual source, and frankly including it was a mistake from the beginning. The way to remedy it is to remove it, along with the recently added link to AP, not to add more and more links to try to achieve some sort of balance.
What we're seeing above is the start of a path we don't want to go down, where we establish a new "worthy of Find sources inclusion" tier of source reliability and spend countless hours debating which sources to include in it and end up listing every newspaper of record across the globe to avoid the (legitimate) fears of geographic bias. Let's turn back from that and establish a simple standard that avoids all that ugliness and comports with how people actually do search: Find sources is for collections of sources, not for individual news outlets.
Support as proposer. {{u|Sdkb}}talk 17:02, 24 November 2023 (UTC)Reply[reply]
Support: hell, same. jp×g🗯️ 20:39, 24 November 2023 (UTC)Reply[reply]
that's exactly my point when i raised my objection to nyt back on 13 July 2023 Wikipedia:Village_pump_(proposals)/Archive_203#Replace_nyt_with_reuters. there had never been any argument for why it's chosen over all other sources. yet it took 125 days(!) for enwp to come to a conclusion of adding AP and not removing nyt, and no one has over the 125 days come up with argument for why nyt was chosen over other organisations but only some (Personal attack removed) kept lecturing me.
so here they go, to balance out the 2 american sources, at least 2 non-american must be added. :) RZuo (talk) 07:12, 25 November 2023 (UTC)Reply[reply]
This is why I created {{search for}} to be a comprehensive suite of searches that one can pull out the type of searches that one wants from. And if there's something useful to add to it, we can certainly consider it.
But {{find sources}} isn't the same thing. In the event that the multiple searches of {{search for}} are needed, simply replace {{find sources}} with {{search for}}, which is definitely the workman's multitool here. Otherwise {{find sources}} really should be focussed upon a few broad search engines. It's a spork to the multitool.
It's somewhat questionable that it gives such prominence to Google, which is another reason that {{search for}} exists, but the very reason that I designed {{search for}} as a series of collapsing boxes is that if you add everything in a single line it becomes enormous. I tried that with {{search for}}.
Something that is a single line mid-dot-separated list needs to be minimal, and if you keep adding more and more useful specialist searches to it you'll end up reinventing {{search for}} but badly.
@Uncle G:somewhat questionable that it gives such prominence to Google - see Searx + Startpage.com, as per my comment below. Boud (talk) 13:19, 25 November 2023 (UTC)Reply[reply]
I can imagine Search for replacing Find sources. In fact, I think you could make the tool even better by integrating some tools like WP:WRS, by expanding the scholarly articles section, by integrating the subject-specific recommendations or by emphasising you may get help to find your source. But that one is very good and practically fulfills the same purpose. Szmenderowiecki (talk) 23:25, 25 November 2023 (UTC)Reply[reply]
Comment. I just spent at least three or four minutes at maximum zoom trying to figure out whether bits three and seven (from the left) in the "multitool" photo are star drive, and I can't tell and it's upsetting my professional sensibilities. Even if they are, with only two included you're bound to run into screws you can't undo, either T15 or T20. Folly Mox (talk) 09:41, 26 November 2023 (UTC)Reply[reply]
Support but replace the privacy-violating Google link by a link to either the Searx meta-search news link at Openxng.com, Searx.be and/or Priv.au (alternatively, it should be possible technically to set up a round-robin selection from the best-rated Searx instances listed at https://searx.space), or to Startpage.com (though I don't know of how to directly link to the News section there). Startpage also protects privacy, so would satisfy UCOC, but it does do some advertising, so that would count as advocacy conferring financial benefits, as in the case of Google, with a financial motive for search engine bias in its search results, affecting the neutrality of our finding sources. Boud (talk) 13:16, 25 November 2023 (UTC)Reply[reply]
Support and I see no issue in a longer but more informative template. I only see the use of replacing Google with other browsers if they offer a comparable quality of search or it's slightly inferior but otherwise usable and respects privacy better. Privacy isn't a goal in and of itself, so we must weigh tradeoffs. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
Yeah, and we already have (sorta defunct) WP:WRS, which was supposed to be a one-stop tool to search all news.
Keep the number of links at the minimum, maximise searching within one custom search engine.
It's not really possible with peer-reviewed articles, but we have Google Scholar and equivalents for that and anyway we should strive to use the best sources we have, right? Szmenderowiecki (talk) 21:10, 25 November 2023 (UTC)Reply[reply]
@Szmenderowiecki:Browsers are not search engines. Google's version of its web browser is getting worse and worse in terms of privacy violation, but that's an independent issue.Boud (talk) 16:31, 26 November 2023 (UTC)Reply[reply]
Support for reduction of clutter. — Bilorv (talk) 20:25, 25 November 2023 (UTC)Reply[reply]
Support per proposer, reduces clutter Sohom (talk) 20:55, 25 November 2023 (UTC)Reply[reply]
Support strongly, especially since there's no reason to emphasize news sources by including many of them - for the vast majority of uses of {{find sources}} news sources might not even be right (let alone US based ones). Galobtter (talk) 21:00, 25 November 2023 (UTC)Reply[reply]
Neutral: ok to remove individual outlets but it doesn't help much when there's a link to Google News which contains all sort of trash. Also support removing JSTOR as another individual outlet that has no business being here alone. Support replacing the links to NYT and AP with a search engine which contains them (preferably with a small manual selection of outlets rather than an automated crawling of news-like websites). Nemo 07:21, 29 November 2023 (UTC)Reply[reply]
Support. Less is more. This is used very widely via templates, and what gets included in it should be of exceptionally broad and global applicability. There should only be tools to actually "find sources" and not any individual source or publisher. Adumbrativus (talk) 04:19, 30 November 2023 (UTC)Reply[reply]
Support per Sdkb. This is a slippery slope. Retswerb (talk) 01:31, 1 December 2023 (UTC)Reply[reply]
Strongly support per nom, Galobtter and particularly the desire to reduce banner bloat. Remagoxer(talk) 15:30, 1 December 2023 (UTC)Reply[reply]
Very Very Strong Support per SdkB, remove all individual news outlets as source recommendations (we don't do journals or magazines, so there's no need for profit-driven newspapers either). GenQuest"scribble" 07:36, 4 December 2023 (UTC)Reply[reply]
Support - per nom and above. (I trust I don't have to individually oppose the other sections if I'm voting support here.) Levivich (talk) 16:52, 4 December 2023 (UTC)Reply[reply]
Support per nom's criticism of banner bloat. The overall proposal rightfully recognizes America-centrism in a widely used template, but the solution cannot be adding the top English publications of each country BluePenguin18 🐧 ( 💬 ) 18:50, 4 December 2023 (UTC)Reply[reply]
Support to avoid inappropriate product placement and because I doubt anyone actually needs these links to find sources. – Joe (talk) 13:28, 5 December 2023 (UTC)Reply[reply]
Support Only including certain RS and not others violates NPOV, and the generic links are good enough for this purpose. QuicoleJR (talk) 14:19, 6 December 2023 (UTC)Reply[reply]
Support - Honestly, I don't think we should be giving any outlets any undue attention, as it may violate NPOV as mentioned above. Also, as others have mentioned, this will reduce link clutter as well. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support. It's prejudicial toward certain corporate "voices" in the news sphere (and certain countries' news), plus it would just continue to grow into an increasingly long list of such news outlets, which ultimately are redundant with the Google News link (though I wouldn't mind seeing that replaced by something that isn't subject to Google's own skewing, and using Microsoft's or Yandex's equivalent wouldn't help but just shift the problem of whose skew we're buying into). Maybe replace all these Google search types with DuckDuckGo ones, if we trust DDG more. — SMcCandlish☏¢ 😼 21:41, 18 December 2023 (UTC)Reply[reply]
Oppose. I think picking representative examples is very important—it seems totally useless to force a less useful presentation solely to create an appearance that information need not come from anywhere in particular. We don't get to freely choose where information we can use comes from or how we can get it. Yes, you can characterize a mention of a particular entity as promoting it, sometimes obviously, sometimes only in an abstract sense—but no one can actually take the reasoning here to its logical conclusion. It is uncomfortable that we rely on certain outlets to create Wikipedia, but I'm sorry to say that there is no intellectually honest remedy for this discomfort, only ways to obscure it. This change is arbitrary; the generic links only push the problem people seem to have back a singular step. Remsense留 21:56, 18 December 2023 (UTC)Reply[reply]
Oppose and I am in full agreement with Remsense. The sources in the module are helpful as the results from those links are narrowly-focused to meet the reseach needs of editors of this project, namely to provide independent, reliable source. We are frequently advised that this project does not right great wrongs, whether in terms of political or societal issues, nor in this case about the dominance of corporate voices in our media landscape. --Enos733 (talk) 00:36, 19 December 2023 (UTC)Reply[reply]
I don't really understand how this came to be a right-great-wrongs issue. We don't dispute NYT or AP is good, but if you need coverage from, say, Serbia, Poland or Canada, then using NYT or AP is kinda suboptimal compared to using local reliable outlets, which obviously cover local stuff better. Also, the framing about "corporate voices" is simply misguided. This is not the problem. The problem is that we choose to advertise only one voice among hundreds that are valid, and which WP:RSP recognizes are valid. It is also about creating a more versatile search tool. If among all sources they decide to choose NYT, we can't help it, but we should first offer a choice we don't really give right now. Instead we are suggesting "use NYT and AP". Adding individual outlets will just make the template needlessly bloated. Szmenderowiecki (talk) 10:37, 23 December 2023 (UTC)Reply[reply]
If you look at the discussion, there are several people who support removal to remove corporate voices or that somehow listing any outlet is a POV issue. - Enos733 (talk) 12:40, 23 December 2023 (UTC)Reply[reply]
I acknowledge that. As I said, for me the "corporate voices" thing is misguided. I can potentially agree with POV concerns for listing individual outlets if we are speaking about WP:SYSTEMICBIAS, which this diversification could help combat if only a little (the ultimate choice of sources still rests with the editors, and the source of that bias is mostly editors). Szmenderowiecki (talk) 16:20, 23 December 2023 (UTC)Reply[reply]
What I could agree with, if this could be implemented easily, is a way to personalize the search links. - Enos733 (talk) 01:29, 24 December 2023 (UTC)Reply[reply]
What do you mean by "personalise"? Doing Google's work all over again is not feasible. If you mean something like a dropdown list where you could tick the relevant boxes, I'm not sure Google's custom search engines can do that but maybe there are other techniques.
Probably the best would be to sort these outlets by regions (North America, Latin America, W Europe, Central-Eastern Europe, Middle East, Indian subcontinent, E Asia, Australia and Oceania, Arab Africa, Central Africa, S Africa; and a general one). I think it would be beneficial for editors to see all news outlets and not simply let them cherry-pick the ones that align with their preconceived notions and POV, or for that matter only choose the most famous ones at the detriment of others thst also do good journalism. Szmenderowiecki (talk) 18:36, 24 December 2023 (UTC)Reply[reply]
Support news outlets are not good general sources, full stop. (t · c) buidhe 02:17, 27 December 2023 (UTC)Reply[reply]
Support removing all individual outlets, those present are too America-centric. Stifle (talk) 14:25, 3 January 2024 (UTC)Reply[reply]
Replace the generic link
The generic link to Google violates Wikipedians' privacy (storing detailed private data for the purpose of sales to advertisers), which is contrary to the spirit of UCOC; like any individual search engine, it is subject to search engine bias that biases our selection of sources, and it uses filter bubbles targeted to each individual, tending to amplify existing demographicbiasesin Wikipedia. We could either give a link to list of search engines or choose a meta-search engine that gives high-quality general search results while protecting user privacy, reducing the bias to any particular engine, and avoiding filter bubbles. Boud (talk) 13:48, 25 November 2023 (UTC) Clarify: this section is only for the generic link, not for the specific links for news, books or scholarly sources. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support as proposer. Suggest either (1) list of search engines, or (2) the Searx generic link at Openxng.com, Searx.be and/or Priv.au, or if a pseudo-random generator can be linked up to the module (should not be difficult with e.g. /dev/urandom, which is fast), use a round-robin selection from a list of e.g. 10 of the best-rated Searx instances listed at https://searx.space), or (3) Startpage.com. The round-robin solution with Searx would keep the link compact (5 characters) and would statistically reduce the bias of any individual Searx instance implicit in the way it is configured and run. Boud (talk) 13:48, 25 November 2023 (UTC)Reply[reply]
Given that Searx is not longer maintained, security vulnerabilities would not be widely reported and addressed in a timely manner. Furthermore, with such low market share, the Searx links you have provided would undoubtedly scare editors into suspecting they have been redirected to malware. While the random assignment to Searx instances increases privacy, this approach is unfamiliar to the average editor that expects links to consistently route them to the same specific site BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
@BluePenguin18: The main development of Searx shifted to Searxng, which is actively maintained; currently there are 882 closed bugs vs 183 open bugs and the master branch is updated every few days or so. Searx.space only lists Searxng instances. Education of editors is worth the price of protecting their privacy; those who actually check URLs are likely to know enough to be able to search further for an explanation and learn. There's also the option of Wikimedia techies running a searx instance: https://searx.wikimedia.org. Boud (talk) 02:28, 10 December 2023 (UTC)Reply[reply]
@Boud Thanks for the clarification on Searxng! I would support a Wikimedia instance of Searx being offered alongside Google Search to comply with WP:ASTONISH, providing curious editors an opportunity to learn about and choose meta-search engines while still offering the currently dominant option BluePenguin18 🐧 ( 💬 ) 05:10, 10 December 2023 (UTC)Reply[reply]
Oppose. Google Search has plenty of problems that make it non-ideal, but it has over 90% market share. At that level, it's what editors expect, so providing anything else would go against WP:ASTONISH. Google also leverages its market dominance to provide better results in some cases, and editors' familiarity with it makes it easier for them to use. The metasearch engine idea is intriguing, but I wasn't impressed when I tested it just now. Searching for "Wikipedia" and navigating to the news tab produced results like this. Linking to the list of search engines is a nonstarter. The entire point of these links is to make searching for sources easier (to encourage more people to do it or just to add convenience). The current setup goes instantly to the Google results for the topic, whereas linking to the article would then require people to navigate to the search engine they want, click through to its article, click the external link to its site, and then re-enter the search term. At that level of inconvenience, people are just going to type the search query into their browser instead, bypassing the template and making it useless as a convenience aid. {{u|Sdkb}}talk 17:34, 25 November 2023 (UTC)Reply[reply]
Just to check what the actual arguments presented here are against the Searx proposal. They seem to be: (1) Google is dominant and it's what people expect; (2) anecdotal evidence. Boud (talk) 16:26, 26 November 2023 (UTC)Reply[reply]
As of September, Searx's github repo is no longer maintained. I'm not real familiar with the project, but surely that's bound to be an issue moving forward if we were to use it as the sole replacement for Google search? Any replacement for the sole link should be something with staying power. Retswerb (talk) 01:29, 1 December 2023 (UTC)Reply[reply]
See above: Strictly speaking, Searx is closed, replaced by Searxng. When I said "Searx" above, formally speaking I was referring to Searxng software and instances. Boud (talk) 02:30, 10 December 2023 (UTC)Reply[reply]
Oppose. Privacy isn't a goal in and of itself. I want to see the balance we trade between utility and privacy. If otherwise equal, obviously switch from Google but prefer utility in the balancing equation. Szmenderowiecki (talk) 20:24, 25 November 2023 (UTC)Reply[reply]
If we balance between utility and privacy, then privacy is a goal (among others). Boud (talk) 16:33, 26 November 2023 (UTC)Reply[reply]
A goal that I believe is secondary to utility, which is the primary goal (find as many sources as you can). You can believe we should prioritise privacy even to the detriment of utility, which is fine but I think few people will share your view.
Also, {{search for}} already includes a couple of search engines outside Google. You can suggest a couple more there. Theoretically if there is independent confirmation that startpage.com is equivalent to Google but is more privacy-friendly, why not? We can change the link.
But my testing of relatively obscure topics I mentioned (e.g. reasons why few people live in Tasmania) showed that most alternatives simply performed worse. Now whether Google (or Microsoft, Apple or whatever) abused its market dominance is basically irrelevant for me, because the point is to find data and (hopefully) let users exercise best judgment in choosing.
I need to see that any of the SearX, Mojeek or other search engines are good enough to use. This also applies to searches in languages other than English, so if the engine is optimised for English but sucks in Russian, it's not good enough. Szmenderowiecki (talk) 18:41, 26 November 2023 (UTC)Reply[reply]
In principle, OK to let users exercise best judgment in choosing, but the search engine bias in the results that the users have to choose from only makes it easy for them to use judgment within that biased selection. A mix of biases (via a meta-search engine) should tend to reduce the overall bias.Searx is not a search engine, it is a metasearch engine. Mojeek is a search engine.As for other languages, given that in English a very sort of notorious example is when the Google search engine was categorizing black people as monkeysper a Princeton engineering interview, the case of Timnit Gebru's exit from Google, and the Santa Clara University advice Search engines and artificial intelligence are neither neutral nor free from human judgment, I see no reason to trust Google to be better in non-English languages than in English. Financial reasons suggest the opposite: paying fluent speakers of small-population languages of poor countries won't contribute much to Google/Alphabet advertising revenue. Boud (talk) 19:35, 26 November 2023 (UTC)Reply[reply]
Oppose This proposal feels a bit wikilawyery especially bringing up the UCOC which has nothing to do with this proposal. Given everything being equal, I would definitely support using alternative engines (or atleast giving users the options to do so). However, this is not the case, instead results from other engines tend to be inferior or outright non-existent for certain search terms. Additionally, a geographical bias can actually sometimes help editors who live in specific regions find better sources (Annecdotally, I have a easier time digging up sourcing about Indian topics if I switch to my Indian registered internet connection when I am in other countries.) -- Sohom (talk) 21:09, 25 November 2023 (UTC)Reply[reply]
If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. Recommending that other Wikipedians violate their privacy is disrespectful and risky, e.g. it's inconsistent with ensuring that the Wikimedia projects are productive, pleasant and safe spaces, and contribute to the Wikimedia mission. It's not safe to be encouraged to violate your personal privacy. To make an analogy: suppose you're invited to a Wikimedia community face-to-face workshop and on entry to the room, there's someone at the door who asks you to take off all your clothes. Whether Google's privacy invasion into your mind - your browser history and browser parameters - is worse or better than a violation of your bodily privacy is a matter of judgment, but both cases are privacy violations. Boud (talk) 19:57, 26 November 2023 (UTC)Reply[reply]
@Boud You've lost me at the analogy. Giving up ones privacy is not akin to sexual harrasment, linking to the UCOC's harrasment clause and giving examples of sexual harrasment as a analogy is not going to change that fact.
The {{find sources}} template links are just suggestions/convinience links for good places to find sourcing, you are welcomed to ignore it completely and use your own search engines (in fact I do so myself most of the times, even when using Google). I would liken it more to being offered a milk-coffee at a Wikimedia event, when I myself am lactose intolerant (I am not, but hypothetically speaking). Sohom (talk) 14:07, 30 November 2023 (UTC)Reply[reply]
Oppose Google search/news/scholar/books are very good for finding sources and any replacement has to have similar quality. Galobtter (talk) 21:11, 25 November 2023 (UTC)Reply[reply]
Oppose. A pretty normal WP:BEFORE would probably include Google news, Google books, and Google scholar. Removing links to Google would make this workflow inefficient. At a minimum, equivalent search engines that search news articles, books, and academic papers should be proposed. A general "let's get rid of Google" with no suggested replacement, in my opinion, is not the way to go. –Novem Linguae (talk) 02:00, 26 November 2023 (UTC)Reply[reply]
This proposal is only for the generic link. That is independent of the specific links for news, books and scholarly sources. The above section (so far) seems to be only about news links. Boud (talk) 16:10, 26 November 2023 (UTC)Reply[reply]
Support replacing Google search with (pretty much) anything else. Linking Google means we're letting advertisers decide what ends up used as source in Wikipedia, an obvious source of systemic bias. If people think a direct link to a web search is needed for people's workflows, DuckDuckGo would be an improvement on the current state. DuckDuckGo introduces less systemic bias because it generally doesn't personalise results based on user fingerprinting and doesn't serve automatically generated prose or other non-sources into the "search results" page. Nemo 07:12, 29 November 2023 (UTC)Reply[reply]
This is misguided. By not personalizing, all users would get the same search results for the same query, reducing the variety of sources used on Wikipedia. While Wikipedia faces systemic bias for its disproportionate share of cis, white, and male editors, the diversity that does exist generates alternative advertiser profiles to see unique sources BluePenguin18 🐧 ( 💬 ) 19:11, 4 December 2023 (UTC)Reply[reply]
So this argument is that by violating Wikipedians' privacy in tracking and recording their habits (in some cases) as being non-cis-white-male, these Wikipedians will select from sources that help create source diversity, but will to the same degree statistically out their gender/social-group profiles, whether they wish it or not. This makes the UCOC violation even worse: it's not just that Wikipedians are encouraged to give their browsing habits to an organisation known for tracking this to great detail, but those browsing habits risk being (statistically) revealed in their choice of sources. Machine learning applied to Wikipedians' selection of sources could suggest their likely Google gender/group profiles. For Wikipedians living in some countries and editing en.Wikipedia, this puts them at risk of prison or death. Boud (talk) 02:54, 10 December 2023 (UTC)Reply[reply]
I might be misunderstanding this argument, but are you suggesting that oppressive regimes will be targetting Wikipedians living under their rule by trawling through contributions and compiling a list of sources added per account name, and then reverse engineering those accounts' possible google profiles based on the sources they've added? Folly Mox (talk) 04:24, 10 December 2023 (UTC)Reply[reply]
Not will, but could; and not trawling by hand, but rather intelligently doing analysis using a mix of software and human thinking. Actions such as the Saudi infiltration of Twitter - or Google - will not always work and they risk embarrassment. To the extent that Google's filter bubbles characterise Wikipedians' profiles and improve diversity in the selection of sources (the point made by BluePenguin18), there would, in principle, be a signal, by definition.Suppose that Wikipedian X is LGBT, that the Downtown Post Daily Times strongly promotes LGBT content, as well as news content unrelated to LGBT issues, and is accepted as a WP:RS in Wikipedia, but X is unaware of the LGBT aspect of the DPDT (it's not obvious in the name). Then Google often gives X sources from DPDT (which buys lots of Google ads), and X often uses them in Wikipedia, unaware that other Wikipedians get DPDT links from Google much more rarely. Boud (talk) 13:47, 10 December 2023 (UTC)Reply[reply]
Even when machine learning models become capable of identifying editors' characteristics based on their choice of sources, it would simpler and more accurate to surveil their list of top edited pages. When the Saudi government infiltrated the Arabic Wikipedia's administrator community, they took the simplest approach to content control by looking at what specific editors were writing. BluePenguin18 🐧 ( 💬 ) 20:02, 10 December 2023 (UTC)Reply[reply]
Some editors may deliberately attempt to hide their interests by editing Wikipedia in a way that hides their (in this hypothetical case) LGBT profile, but some of their general non-Wikipedia searches will be for LGBT material. We get back to the case of our hypothetical editor unintentionally using DPDT as a source for a non-LGBT Wikipedia article, unaware that this is a statistical clue to being LGBT. Whether or not this is the best way to identify people to for arbitrary arrest and torture, it's available in the record. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
@Boud: You gotta stop bringing up the UCOC thing. It's not helpful. I try not to inject myself in every conversation involving the UCoC, but I won't be able to sleep tonight if I don't correct the absolute absurdity that is your reply: If there's consensus to continue violating UCOC - and in fact I expect that there will be consensus to continue to at least partially violate UCOC by keeping at least one or two Google links - then we'll find that out. WMF will have to fight us if it wishes to fully implement UCOC. I've spent hours of my life having discussions with the WMF and the community about the UCOC. What you are suggesting is so far removed from anything a rational person would even consider when enforcing it. There is zero possibility of anyone of applying it to this case; most especially not the WMF. Your logic here is so twisted and nonsensical that I'm embarrassed to even feel the need to respond. –MJL‐Talk‐☖ 06:55, 13 December 2023 (UTC)Reply[reply]
I don't see any arguments here explaining why encouraging Wikipedians to violate their privacy and thus put themselves at increased risk of harm is consistent with the spirit of UCOC; absurdity ... twisted ... nonsensical are not arguments. Boud (talk) 18:52, 13 December 2023 (UTC)Reply[reply]
The amount of logical assumptions you have to make to get where you are at is indeed absurd, twisted, and nonsensical. Adding a link to a Google search is not encouraging Wikipedians to violate their privacy (as has already been explained to you). Even if it was, the spirit of the UCoC (if there can be such a thing) which you keep referring to would not be violated nor enforced. I know this because I co-wrote the enforcement guidelines. –MJL‐Talk‐☖ 18:55, 14 December 2023 (UTC)Reply[reply]
Support the idea of replacing the generic google link with some sort of list of search engines. We already do this when providing links to ISBNs and co-ords. Rather than picking what search engine people use, we can present them with a list of options. I'm not convinced any Google alternative is actually good enough to fully replace the link to google, especially recognizing its sheer market dominance (it will be what many people expect to find and use). Eddie891TalkWork 15:36, 29 November 2023 (UTC)Reply[reply]
Oppose replacing Google: The top searches on Bing, and likely most other search engines is "Google". Meet the reader where they're at. Mach61 (talk) 05:41, 30 November 2023 (UTC)Reply[reply]
Oppose As much as I dislike the corporation, it is the best overall source of sources. O3000, Ret. (talk) 19:38, 1 December 2023 (UTC)Reply[reply]
Whether or not a search template not used in article content contains a hyperlink to Google has nothing at all to do with verifiability. Even if this template didn't exist at all, stuff could still be verifiable. Uncle G (talk) 14:56, 11 December 2023 (UTC)Reply[reply]
Oppose - As much as Google may have plenty of privacy issues, that is a separate matter from whether it is useful, which it is. Thus, I don't see a reason to remove it at this time. I would support adding different search engines like Bing or Yahoo if there were consensus for it, though. Epicgenius (talk) 16:57, 12 December 2023 (UTC)Reply[reply]
Support adding links to other search engines; the current google search engine is deeply flawed. The list of search engines should continue to include google -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:13, 13 December 2023 (UTC)Reply[reply]
Oppose The generic search link can be valuable to editors. There is no replacement in this proposal, just removal. --Enos733 (talk) 12:44, 23 December 2023 (UTC)Reply[reply]
Discussion (Module:Find sources)
There are two orthogonal issues here, reliability and coverage of sources (which is core encyclopedia stuff) and search engines' respect for privacy (which is a user preference). This is unlikely to lead to a productive conversation. Personally I think we should recommend source-finding techniques on a per-wikiproject basis. We need to look in different places for sources for a contemporary American biography, a 20C New Zealand law, a 19C Malay biography, an 18C German political scandal, a 17C book and an ancient Middle Eastern location. Seems likely to me that we can come up with a per-user preference for generic search engine privacy and then parameters to help find specific content (bot-assisted based on cats and wikiprojects). Stuartyeates (talk) 19:14, 25 November 2023 (UTC)Reply[reply]
It's true that there are two orthogonal motivations, and you are probably right that a tech solution may be able satisfy both. The idea of a per-user preference parameter for search engine privacy, that would be used by the module to switch between privacy-violating and privacy-respecting search engines and meta-search engines, is good. This would need techie willingness to implement it. There would also be the question of which setting should be the default: should selecting privacy be opt-in or opt-out? Boud (talk) 20:13, 26 November 2023 (UTC)Reply[reply]
If we think this is going to be a popular subject (~50 editors?), please copy/paste it to a subpage before adding an RFC tag. This page was recently nearly a million bytes long, and that makes it very difficult for people to read (especially on smart phones). The most popular title is Wikipedia:Requests_for_comment/YOUR-THING-HERE (see examples), but it's okay to do Wikipedia:Village_pump_(proposals)/YOUR-THING-HERE if you prefer. WhatamIdoing (talk) 18:59, 24 November 2023 (UTC)Reply[reply]
I think this first should have an RfC tag before we move it to a subpage of VPR. People won't know of this discussion if we hide it in a subpage. Szmenderowiecki (talk) 21:12, 25 November 2023 (UTC)Reply[reply]
If it's an RFC, people will know about it no matter where it happens. The Wikipedia:Feedback request service posts personalized messages to editors' talk pages about RFCs in subject areas that interest them. But I agree (and, more importantly, so does WP:RFC) that it would be good to keep a link here, especially if the discussion starts here and gets moved. WhatamIdoing (talk) 23:20, 26 November 2023 (UTC)Reply[reply]
Maybe this should be done reactively rather than proactively. That is, wait for sections to get big, then put them on a subpage. –Novem Linguae (talk) 02:05, 26 November 2023 (UTC)Reply[reply]
@Novem Linguae, do you have a preferred number for "big"? There are already more than 50 comments in this section. WhatamIdoing (talk) 23:22, 26 November 2023 (UTC)Reply[reply]
Exactly how many news sources are deemed reliable by Wikipedia & which ones are they? GoodDay (talk) 16:28, 23 December 2023 (UTC)Reply[reply]
RfC: disallowing new signatures obsolete tags
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is clearconsensus in favor of the proposal. Any remaining technical questions can be worked out during implementation. (non-admin closure) {{u|Sdkb}}talk 20:40, 24 December 2023 (UTC)Reply[reply]
Background/details (disallowing new signatures obsolete tags)
In 2020, as part of the DiscussionTools project, signature validation was added to MediaWiki. Since its implementation, users have been unable to save an invalid signature in Special:Preferences (invalid signatures saved beforehand are still allowed). Currently, the validator disallows every WP:LINT error except for obsolete-tags. (The most commonly used obsolete tag is <font>...</font>, but <tt>...</tt>, <center>...</center>, and <strike>...</strike> are also obsolete.) This proposal would eliminate that exception. Pre-existing signatures would not be affected by this proposal.
Survey (disallowing new signatures obsolete tags)
Support as proposer. Bots (and humans) are currently fixing obsolete-tags en masse, and this was backed by community consensus in February. I believe this change should appeal to people on both "sides" of that debate. If you support fixing obsolete tags, the benefits are obvious. If you oppose fixing obsolete tags, fixing them is already backed by community consensus. This change would help limit the amount of lint that bots need to fix.Additionally, WP:SIGFONT is already part of the signature guidelines. This would simply enforce that section techincally. HouseBlastertalk 01:10, 3 December 2023 (UTC)Reply[reply]
Support, if bots are already fixing them what's the point in allowing them? — Alexis Jazz (talk or ping me) 01:18, 3 December 2023 (UTC)Reply[reply]
Support, these are already deprecated in terms of browser support, and the day will come that support for them is dropped entirely. This is a good step to ensure those who may not know that are not negatively impacted by such a change, and eliminating the need for linter bots to make needless edits fixing them. SeraphimbladeTalk to me 04:35, 3 December 2023 (UTC)Reply[reply]
Support, use of obsolete tags cause too much drama. BilledMammal (talk) 05:03, 3 December 2023 (UTC)Reply[reply]
Support When saving edits, edits that contain lint errors should be blocked too Killarnee (talk) 14:23, 3 December 2023 (UTC)Reply[reply]
Support: Seems like a no-brainer to me. It's just real signature validation, plus this'll reduce needed resources by bots as there'd probably be less signatures that need fixing. Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
Support I'm kind of iffy on the whole fixing obsolete tags thing (I kind of doubt browsers will ever drop support for it), but we should what we can to prevent new additions of these. Galobtter (talk) 16:32, 3 December 2023 (UTC)Reply[reply]
Weak SupportEhhh - this should be dealt with WMF-projects wide or not at all. — xaosfluxTalk 18:56, 3 December 2023 (UTC)Reply[reply]
I assume the response to a global proposal would be "not without enwiki consensus", and there's nothing in this proposal preventing a later global one. ~ ToBeFree (talk) 22:56, 3 December 2023 (UTC)Reply[reply]
OK sure, don't think this is that big of a deal but if it's going to reduce bot edits then sure. — xaosfluxTalk 10:56, 4 December 2023 (UTC)Reply[reply]
Support as someone who spends a lot of time fixing Linter errors. It has been frustrating to watch new errors introduced into pages when we have such a huge backlog (3.6 million listed errors currently). Turning off the flowing tap of obsolete tags in signatures is a way to stem the flow when the bathtub of errors is overflowing. – Jonesey95 (talk) 23:28, 3 December 2023 (UTC)Reply[reply]
SupportWe should definitely prevent new additions, I'm surprised that this is not already the norm.Sohom (talk) 01:41, 4 December 2023 (UTC)Reply[reply]
Support Anything to reduce pointless addition of deprecated syntax, with subsequent time-wasting fixes, would be good. Johnuniq (talk) 04:07, 4 December 2023 (UTC)Reply[reply]
Support - regardless of how one feels about the urgency of fixing existing obsolete tags, it makes sense for Wikipedia to stop adding new obsolete tags to its pages. Long overdue, thanks for proposing this, HB. Levivich (talk) 05:23, 4 December 2023 (UTC)Reply[reply]
Support - My signature formerly used those tags to get under the maximum length. While as a web dev I knew they were outdated, I thought they were relatively harmless in this context (as browsers will continue to support them for compatibility) and didn't realise they were discouraged on enWP until another user gave me a heads up. If bots are already changing these tags the proverbial ship has already sailed regarding their usage. ― novov(tc) 02:38, 7 December 2023 (UTC)Reply[reply]
You could subst the font template to cut down on some chars to maybe make it fit. Aaron Liu (talk) 12:09, 7 December 2023 (UTC)Reply[reply]
Aaron Liu, surely that would be bypassing the signature limit (WP:SIGLENGTH: please be careful to verify that your signature does not violate the 255-character length limit when the templates are expanded, as the software will not do this automatically). — Qwerfjkltalk 18:35, 7 December 2023 (UTC)Reply[reply]
Support. We are already fixing these sigs (which was also approved in a recent RfC). Disallowing new ones to be introduced will reduce the amount of work needed and the "watchlist spam" issue some editors were complaining about. --Gonnym (talk) 12:30, 7 December 2023 (UTC)Reply[reply]
Support. I'm not convinced on the necessity of fixing lint errors on old talk pages, but stopping new ones seems more worthwile. -- LCU ActivelyDisinterested«@» °∆t° 19:05, 7 December 2023 (UTC)Reply[reply]
Support, as long as there is a crystal clear error message linking to mw:Help:Lint_errors/obsolete-tag or similar that can be understood even by someone who started editing yesterday and has tried to emulate the non-compliant signature of their favourite long-term editor. Certes (talk) 12:15, 8 December 2023 (UTC)Reply[reply]
Support Good idea Isla🏳️⚧ 13:20, 10 December 2023 (UTC)Reply[reply]
Support Since we should be designing Wikipedia for browsers that almost all people use (Chrome/Edge 120, Firefox 120, Safari, etc.). We should aim for modern web compliance including HTML5 and ES6 compliance. AwesomeAasim 15:40, 12 December 2023 (UTC)Reply[reply]
Discussion (disallowing new signatures obsolete tags)
@HouseBlaster: Please add a couple more words to the RFC question. It could be read as preventing me from changing my signature to one that has an obsolete-tag lint error, or it could be read as preventing a current user who has an obsolete-tag lint error from signing a new comment. I know the background explains that, but a word or two more might help. Johnuniq (talk) 01:16, 3 December 2023 (UTC)Reply[reply]
I just pinged you because you participated in the earlier discussion; this change would not impact you at all. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
HouseBlaster, I thought Q1 was going to go first, did I miss it? — Alexis Jazz (talk or ping me) 01:21, 3 December 2023 (UTC)Reply[reply]
Oops. Mentally I had this one going first... my bad. I think this order is better because this one does not require mass messages (because it only impacts people in the future). That brings two benefits: one, we only have to generate a list/write a message/etc. once. Two, people whose signature are both invalid under the current criteria and contain <font>...</font> tags would not be double mass-messaged. HouseBlastertalk 21:56, 3 December 2023 (UTC)Reply[reply]
FRS recipient: My main question is how exactly would that work? If someone included <tt>...</tt> in their signature, would they just get an error message, or would it prompt them to replace the tag with {{mono|}}? Seeing as this could be one of the earliest things someone does after creating an account, we absolutely do not want to make them dive into the wikipedia help documentation to track down accomplishing their preferred signature, especially if they see existing accounts' signatures still using the deprecated functionality before they've been fixed by bot. VanIsaac, GHTVcontWpWS 03:10, 3 December 2023 (UTC)Reply[reply]
I see nothing wrong with shoving headlong into formatting syntax documentation any newcomers whose first orders of business on the website include fancy sig customisation. Folly Mox (talk) 04:19, 3 December 2023 (UTC)Reply[reply]
The issue is when syntax that a new editor sees working for someone else won't work for them. The deprecated html tags work just fine when they make a comment, but for some reason there is an exception when it comes to their signature, but not anyone else's. That's a distinctly WP:BITEY behavior for the interface. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Aren't bots already fixing such signatures with deprecated tags? Aaron Liu (talk) 16:03, 3 December 2023 (UTC)Reply[reply]
@Vanisaac, if you have a disallowed sig (and this RFC proposes to expand what's considered disallowed by software), and you leave a note on the talk page, it will just use the normal, default sig (e.g., like mine, like Folly Mox's, like Johnuniq's). It won't bother you about it; it'll just ignore your disallowed sig and quietly substitute the default.
If you notice it and try to update your prefs, it will not let you save an improper custom sig. It will give you an error message then. Consequently, one approach is that you just try to fix it until you hit upon something that the system will accept. If solving it by the trial-and-error method seems unappealing, then the editor can ask for help. Most people do this at Wikipedia talk:Signatures or Wikipedia:Village pump (technical) or a friend's page.
So that seems like the most unhelpful functionality imaginable. VanIsaac, GHTVcontWpWS 08:27, 3 December 2023 (UTC)Reply[reply]
Why? The options are:
Don't restrict anything in software, or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then prevent you from using talk pages until you fix it (e.g., throw an error message after you have already typed a comment), or
Restrict invalid sigs in software, and if you happen to have an invalid sig, then keep letting you use talk pages with a known-valid sig.
Interfering with normal use of the wikis until you debug your sig would be my candidate for a "worst approach" prize.
As Alexis Jazz corrects below, the first step is to stop people from adding new invalid sigs to their prefs. We could stay in that state for years. WhatamIdoing (talk) 20:18, 3 December 2023 (UTC)Reply[reply]
No, the options actually are:
Do nothing.
Restrict new non-standard sigs, but provide instant feedback on what the problem is and a direct link to a tool tip or the section on the help page that shows you how to accomplish what you are trying to do using current standards and has updated content that would let that user know that some of the solutions won't be valid in signatures.
Restrict new non-standard sigs, providing the same feedback and help AND at some time implement a system to require old editors with non-standard formatting to also update those sigs, providing the same helpful guidance thereby lessening the workload on lint fixing bots.
Restrict new non-standard sigs but implicitly say by your omission of any help or suggestions "ha ha, you saw something somebody else did that you want to do, but we don't allow that any more, but only for new guys, and we're not going to tell you what you did wrong or how to fix it. So fuck you as you try to track down what it is that you did wrong and how to fix it, or you can just give up and become disillusioned with a site that is so massively hostile to new contributors."
If the choice is between fuck you and do nothing, doing nothing is vastly superior as a choice. VanIsaac, GHTVcontWpWS 18:55, 6 December 2023 (UTC)Reply[reply]
The linter already will provide you with a help page to the relevant error when it detects lint errors. In this case, it’ll probably direct you to mw:Help:Lint error/obsolete-tag. I don’t see why you think it’s a choice between whether or not to “fuck you”.I just tested, and it should say “Your signature contains invalid or deprecated HTML syntax” along with a list of problems with a “learn more” link button for each. Aaron Liu (talk) 19:54, 6 December 2023 (UTC)Reply[reply]
Well, the "fuck you" option is what Folly Mox gave me when I specifically asked about how this proposal would be implemented. So maybe you need to get your ducks in a row and give me a straight answer on how this proposal will be implemented. What exactly does the linter tell you? When does it tell you? How does it tell you? How can we make more useful information available? Should we have a validation wizard that would output code fixing linter errors that we could point these new signature editors to? If the intent is to not give a "fuck you", then we need to actually back that up with our actions. VanIsaac, GHTVcontWpWS 20:18, 6 December 2023 (UTC)Reply[reply]
Firstly, I think Folly Mox meant just giving them a link to the relevant doc page when they said shoving. Secondly, just look at this screenshot I found by simply searching "signature lint" on commons (though there has been a very minor difference: instead of bullet points, the extension uses a numbered list now.) Aaron Liu (talk) 23:06, 6 December 2023 (UTC)Reply[reply]
The behavior depends on what stage things are at. In the stage that prevents the creation of new bad sigs, you get instant feedback. That feedback may or may not be understood, but it is instant and provided in bold-faced red letters. In the stage in which old bad sigs are no longer accepted, it silently switches to the default, known-good sig. WhatamIdoing (talk) 07:21, 10 December 2023 (UTC)Reply[reply]
The latter stage seems like a separate RfC. The former's feedback seems pretty clear to me. Aaron Liu (talk) 16:48, 10 December 2023 (UTC)Reply[reply]
After the conclusion of this RfC (regardless of if it is successful or not), I plan to propose that we apply the signature validation rules retroactively (after affected users are mass messaged with pertinent info). Both of these proposals are a simple config change; the retroactive option would default invalid signatures to MediaWiki:Signature, e.g.
This is an example message with a default signature. Example (talk)
How would you know which users to mass message? Aaron Liu (talk) 12:19, 7 December 2023 (UTC)Reply[reply]
Quarry; you can see a partial report at toolforge (note that sig-too-long-post-subst and some of Line breaks would not be affected).HouseBlastertalk 00:15, 8 December 2023 (UTC)Reply[reply]
Wait, that signature length detection is possible and disabled‽ Aaron Liu (talk) 11:57, 8 December 2023 (UTC)Reply[reply]
No, they are not detected/disabled. That's why they would not be affected.HouseBlastertalk 16:55, 8 December 2023 (UTC)Reply[reply]
No, I mean that the substituted length detection is disabled. I really wonder why. Aaron Liu (talk) 17:49, 8 December 2023 (UTC)Reply[reply]
WhatamIdoing, looking at Note that the scope of this proposal has been narrowed to only impact newly saved signatures. it seems users who already have obsolete tags in their signature can continue to substitute that signature on talk pages, they just won't be able to adjust it in their preferences. But presumably if this passes we'll see another proposal down the line to end that grandfather clause. Unless the number of signatures that bots need to adjust ends up being really really low, in which case it could be a non-issue. — Alexis Jazz (talk or ping me) 10:05, 3 December 2023 (UTC)Reply[reply]
Out of curiosity, how would one set one's username's font in their signature without the font tag? — Red-tailed hawk(nest) 05:55, 4 December 2023 (UTC)Reply[reply]
To save people the click: <font face="foobar"> can be rewritten as <span style="font-family:foobar;">.HouseBlastertalk 13:34, 4 December 2023 (UTC)Reply[reply]
Another curiosity: whilst HTML 3.2 allowed the <font> tag to have either or both of the color= and size= attributes, it noted Some user agents also support a FACE attribute which accepts a comma separated list of font names in order of preference. This is used to search for an installed font with the corresponding name. FACE is not part of HTML 3.2.HTML 4 formally added the face= attribute to the syntax, but immediately deprecated it along with the element itself. --Redrose64 🌹 (talk) 11:27, 5 December 2023 (UTC)Reply[reply]
Query: Is <strike>depreciated in favour of <s> or is there another, more convoluted way? Adam Cuerden(talk)Has about 8.6% of all FPs. 23:39, 5 December 2023 (UTC)Reply[reply]
[44]: Use the <del> tag to define deleted text [...] Use the <s> tag to mark up text that is no longer correctAaron Liu (talk) 00:03, 6 December 2023 (UTC)Reply[reply]
And if you want a strikethrough without semantic connotations, you can use <span style="text-decoration:line-through;">.HouseBlastertalk 00:09, 6 December 2023 (UTC)Reply[reply]
Why stop there? We could make everything so much simpler by using <span class="mw-signature-struckthrough mw-signature-nonsemantic-strikethrough" title="nonsemantic-strikethrough" id="struckthrough-nonsemantic-qghlm11j" onclick="" style="font-size:100%; font-family: san-serif; filter: hue-rotate(0deg); text-decoration: line-through; display: inherit; text-align: inherit;" alt="Non-semantically struckthrough signature"></span>. jp×g🗯️ 13:13, 9 December 2023 (UTC)Reply[reply]
This outcome is looking pretty snowy, and discussion seems to have reached a natural conclusion. – Jonesey95 (talk) 20:44, 15 December 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post RfC: disallowing new signatures obsolete tags close
@Gonnym open a site configuration request in phabricator. — xaosfluxTalk 10:18, 26 December 2023 (UTC)Reply[reply]
In T140606, matmarex wrote: I updated the patch to include a config variable $wgSignatureAllowedLintErrors. It defaults to [ 'obsolete-tag' ] (which allows <font> tags etc.), and you can file a task to change this config to an empty array [] whenever the community of English Wikipedia (or any other wiki) agrees to that. I have filed T354067 to make that request, based on the RFC consensus listed above. If I have made any technical errors, feel free to weigh in with comments or corrections. – Jonesey95 (talk) 00:36, 28 December 2023 (UTC)Reply[reply]
About a week ago I got into a discussion at Wikipedia talk:Articles for deletion regarding IP editors such as myself making AfD nominations. Long story short, several ppl there falsely claimed I could've completed the nomination myself despite being an IP user, and they got onto my case for going to the talk page and requesting logged in users complete the nomination process, even tho WP:AFDHOWTO says to do exactly that.
“
If you are unregistered, you should complete step I, note the justification for deletion on the article's talk page, then post a message at Wikipedia talk:Articles for deletion requesting that someone else complete the process.
”
This culminated in one of these users suggesting that the quoted text be changed to encourage ppl to create an account. ("Less work for us / teach people to fish... etc.") Should this change be made, or should the text be left as-is? 100.7.34.111 (talk) 18:51, 26 December 2023 (UTC)Reply[reply]
I see no reason for this to be part of AFDHOWTO. There doesn't seem to be any reason to restrict AFD creation from unregistered users. If you think the AFD nomination will improve the encyclopedia, see WP:IAR, and just make the nomination, regardless of whether some bureaucratic nonsense on the AFD page says not to. EggRoll97(talk) 04:51, 27 December 2023 (UTC)Reply[reply]
@EggRoll97: You're missing the point, which is that IPs and other non-confirmed users cannot create pages in Wikipedia: namespace, an action that is central to WP:AFDHOWTO step II, even if they wanted to. It's not rules, or bureaucracy: it's a software limitation. --Redrose64 🦌 (talk) 08:33, 27 December 2023 (UTC)Reply[reply]
Pedantically, the bar on non-(A)C accounts is a rule, but the fact that we can't make an exception for AfD is a software limitation. (We could lift the MW-level restriction and then filter more selectively by edit filter, but that would add a lot of headaches for a limited benefit.) Anyways, this particular limitation at AfD is why I created an account 11 years ago, so maybe it does some good (or bad, depending on one's opinion of me). -- Tamzin[cetacean needed] (they|xe|she) 08:52, 27 December 2023 (UTC)Reply[reply]
Alternatively, we could go the exact opposite route and create something like the redirect wizard for AfD, which would automatically create pages via bot. Mach61 (talk) 13:52, 28 December 2023 (UTC)Reply[reply]
There used to be bots that did this. My own was the first; I stopped because I got sick of people screaming at me for "letting bots automatically afd pages", even though I did curate the list. The most recent I'm aware of was User:DumbBOT, though judging from the User:DumbBOT/IncompleteAfD list linked from its userpage, it hasn't done so for more than a decade. —Cryptic 00:11, 29 December 2023 (UTC)Reply[reply]
Set index articles
Happy new year everyone! Please see Wikipedia talk:Content assessment#Request for comment. I am trying to get consensus on what an SIA is and whether they are a useful classification of article on Wikipedia. Please comment there. — Martin (MSGJ · talk) 17:58, 1 January 2024 (UTC)Reply[reply]
Explicitly allow A2R to tag redirects that are related topics with another redirect
This is a redirect from an alternative title for (redirect page name), another redirect to the same title.
+
This is a redirect from an alternative title or related topic of (redirect page name), another redirect to the same article.
This stems from a discussion at User talk:Aaron Liu#The Mind Electric with @Richhoncho concerning the redirect The Mind Electric, which is a good example to illustrate why we should do this. That redirect, a song name, was originally a redirect to its album’s article, which was replaced with a redirect to the artist. As the song is not an alternative title for the album, the current wording does not make it clear whether this is allowed.
Makes sense to me. Any case where A really should redirect to B but it can't because B itself is a redirect seems valid for {{R avoided double redirect}}. Anomie⚔ 00:11, 6 January 2024 (UTC)Reply[reply]
So let's simplify the question. Artist, Album, Song. If album is removed does the song cease to be an artist song. That is what the OP is arguing, which is plain nonsense. Richhoncho (talk) 00:48, 6 January 2024 (UTC)Reply[reply]
How? I don't even know what you mean by "cease to be an artist song". We all agree (or at least consensus does) that when the album article for a song appears, the song should then redirect to the album instead. So why not add the tag which would help automatically do that in that event? Aaron Liu (talk) 00:55, 6 January 2024 (UTC)Reply[reply]
Your failure to understand the purpose of A2R is self-evident. Your inability to understand the difference between song and album is also self-evident. Your inability to bring this discussion to appropriate place beggars belief. It is time to stop wasting everybody's time over one redirect because you got it wrong, goodnight. Richhoncho (talk) 01:17, 6 January 2024 (UTC)Reply[reply]
I really don't understand what you're trying to do now. You operate under the unfounded assumption that A2R can only be used for alternative titles of the same thing, tell me to get "substantial support" for what I think about A2R, thank me for creating this thread at VPR, accuse me of more things in lieu of argument and then chastise me for creating this thread at VPR. Aaron Liu (talk) 01:33, 6 January 2024 (UTC)Reply[reply]
Wikipedians can be so confidently wrong, hey. J947 ‡ edits 03:21, 6 January 2024 (UTC)Reply[reply]
Makes sense. But from my experience I do think the whole {{R avoided double redirect}} template text could do with a rework for clarity: all we want to express is "this redirect is dependent on this other redirect, and the dependent redirect's target should sync with the other redirect", correct? J947 ‡ edits 03:21, 6 January 2024 (UTC)Reply[reply]
Seems like it, but at the same time I can't think of any other cases than alternative names and related topics. Aaron Liu (talk) 03:28, 6 January 2024 (UTC)Reply[reply]
OK. That's enough misinformation. Let's pare this discussion back to the basics and the redirect it relates to, read what has been said and see if we can all understand it.
The redirect has 2 tags, the first is R from song which reads, This is a redirect from a song title to a more general, relevant article such as an album, film or artist where the song is mentioned. This entry is not in contention, but does confirm that the redirect can be to a more general article. The OP then wants to add A2R stating that The Mind Electric is an an alternative name for the album Hawaii: Part II, because it does not have it its own article.
This gives us 3, and probably more, inconsistencies.
It assumes that songs articles cannot exist without supporting album articles (some song articles exist without album or artist).
That song articles should not be pointed to the artist without a specific note of the instance.
And, returning to the original point, in which universe is The Mind Electric (a song) an alternative name for Hawaii:Part II (an album it has appeared on)?
Finally, is Village Pump the correct place for this discussion? --Richhoncho (talk) 15:02, 6 January 2024 (UTC)Reply[reply]
I think you may need to step back and reexamine your assumptions here. #1 and #2 you are overgeneralizing. Just because this one song is marked as being intended as a redirect to the album (but then redirects to the artist because there is no album article either) doesn't mean that every song "cannot exist without supporting album articles" or that no song ever could skip an album redirect. But chances are the exceptions prove the rule. Your assertion #3 is outdated, as the template now says "or related topic", and the album a song appears on certainly is a related topic in most cases. Anomie⚔ 15:33, 6 January 2024 (UTC)Reply[reply]
My point entirely. I was paraphrasing the OP's opinion. Richhoncho (talk) 17:02, 6 January 2024 (UTC)Reply[reply]
Your points argue against tagging the redirect as A2R, while everybody else here including me and Anomie think that it's fine to tag the redirect as A2R. I don't see how you were just paraphrasing my opinion. Aaron Liu (talk) 17:21, 6 January 2024 (UTC)Reply[reply]
Note that this is now Done, though the last word remains "title" instead of "article" as this tag is also used on non-articles. Aaron Liu (talk) 17:22, 6 January 2024 (UTC)Reply[reply]
Increase default thumbnail size from 220px to 250px
Example at 220pxExample at 250px
Way back in 2009, English Wikipedia decided to change its default thumbnail size from 180px to 220px (which became the default for all wikis). It's been 15 years since then, and the most common screen resolution is now 1920x1080,[45][46] which makes 220px seem rather small. The Swedish, Norwegian, and Finnish Wikipedias have already switched to 250px and the Dutch Wikipedia switched to 260px(!). Since there are already other wikis using 250px, the impact on the thumbnailing services and thumbnail storage should be manageable (as the most commonly requested thumbnails will already be available in 250px). A 2014 proposal to increase the default size to 300px failed to reach consensus, which is why I'm trying the more modest proposal of 250px (which is the next size up in wgThumbLimits). Nosferattus (talk) 19:00, 5 January 2024 (UTC)Reply[reply]
Support as proposer - After wondering why thumbnails are so tiny on Wikipedia (especially compared to other websites), I finally figured out I could change the default in my preferences, which made me wonder why the default is so small, which led me to research the history of the issue. Seems like a bump in the size is overdue. Nosferattus (talk) 19:04, 5 January 2024 (UTC)Reply[reply]
Support - I've always thought that Wikipedia has frustratingly small thumbnails. 4.16.149.14 (talk) 20:01, 5 January 2024 (UTC)Reply[reply]
Oppose In many case images aren't just used on their own, but side by side with other images (the multiple images template for example). This already leads to cramped text on none desktop screens, and this propodal only makes that worse. Thete is also the issue of |upright= to think of, as this would effect the size from which images are scaled. If images appear to small a setting for larger base size is available in preferences. -- LCU ActivelyDisinterested«@» °∆t° 20:33, 5 January 2024 (UTC)Reply[reply]
The common screen size of phones have also increased. In most cases where the multiple images template is used, it's on its own line instead of sharing with text. IP editors and readers should also be accounted for, and I don't see what considerations upright adds to thumbnail sizes. Aaron Liu (talk) 21:45, 5 January 2024 (UTC)Reply[reply]
Sorry but In most cases where the multiple images template is used, it's on its own line instead of sharing with text is the opposite of my experience. -- LCU ActivelyDisinterested«@» °∆t° 22:01, 5 January 2024 (UTC)Reply[reply]
You're right - the one line ones are "mini-galleries", which are vastly preferable to multiple images, which are used far too often. Johnbod (talk) 04:12, 7 January 2024 (UTC)Reply[reply]
Yep with this increase all horizontal multiple images templates will immediately become to wide. Mini-galleries are definitely a better idea. -- LCU ActivelyDisinterested«@» °∆t° 12:49, 7 January 2024 (UTC)Reply[reply]
Template:Multiple image is used in less than one percent of articles. It has a hard-coded default of 200px and therefore should not be affected by this change at all. WhatamIdoing (talk) 18:30, 7 January 2024 (UTC)Reply[reply]
Support - 220px is tiny, especially on a 4K monitor which are becoming more common. I think it would be useful to increase the size, especially since other Wikis already have. 30px isn't much in the grand scheme of things and hasn't caused any issues for me when putting images in infoboxes. --StreetcarEnjoyer (talk) 20:46, 5 January 2024 (UTC)Reply[reply]
Support 220px looks tiny on my screen. I can set my default up to 300px but prefer to see what the readers are seeing. Or not, given the small size on their 4K monitors. Hawkeye7(discuss) 23:02, 5 January 2024 (UTC)Reply[reply]
Meh Personally, despite my screen being 1920×1280, I seldom maximize my browser. Also keep in mind how Vector 2022 shrinks the content area. Anomie⚔ 00:29, 6 January 2024 (UTC)Reply[reply]
As a staunch supporter of V22, I don't think the larger Earth image looks wrong here. (Not sure if that means we should do it though, so I'm neutral.) Aaron Liu (talk) 12:51, 7 January 2024 (UTC)Reply[reply]
@Nosferattus: isn't 360×800 the most common screen resolution (a very quick check showed readership of TFA today at about 2:1 mobile web to desktop web). — xaosfluxTalk 00:41, 6 January 2024 (UTC)Reply[reply]
@Xaosflux: Yes, I think you're correct and 250px (or 300px for that matter) works great at 360×800, as the mobile layout puts images on their own line. Nosferattus (talk) 01:31, 6 January 2024 (UTC)Reply[reply]
Isn't mobile configured separately? I'm pretty sure that we can change the desktop size without changing the mobile size. WhatamIdoing (talk) 04:41, 7 January 2024 (UTC)Reply[reply]
Support. It's not 2009 anymore, and the images look way better bigger. Relativity 02:56, 7 January 2024 (UTC)Reply[reply]
Comment I don't fully understand the importance of screen size here, as I thought WP:VECTOR2022 specifically constrains article width by default. Could anyone with a super-wide monitor clarify? CMD (talk) 03:39, 7 January 2024 (UTC)Reply[reply]
It does by default. But the people !voting here probably either use a different skin or have clicked the button to un-constrain it. Anomie⚔ 04:29, 7 January 2024 (UTC)Reply[reply]
Given the resistance to the community wish of making unconstrained the default, it would be best to make decisions considering restricted width as the most likely one to be encountered by desktop readers. Having a look myself, I don't think 250px creates an issue within the constrained width (and I believe the latest zebradesign has been implemented), but worth keeping this default look in mind. CMD (talk) 14:31, 7 January 2024 (UTC)Reply[reply]
Support I feel like I have to squint to look at images pretty often. This should be an RfC advertised on WP:CENT tho. Galobtter (talk) 03:47, 7 January 2024 (UTC)Reply[reply]
Strong Support Hardly any images except photos of faces can be properly read at 220px. As per Relativity, except even in 2009 our images looked too small. Johnbod (talk) 04:10, 7 January 2024 (UTC)Reply[reply]
Support. I'd prefer jumping straight to 300px (and I think mw:Ops would, too), but 250px is fine and an improvement over what we have now. Somewhat bigger images are easier for people to see (e.g., if you're old enough to use reading glasses, which I'm sure I set down somewhere just a minute ago), but they also make the pages seem more interesting. I set mine to 300px last year, and I've never regretted it, and you can, too: go to Special:Preferences#mw-prefsection-rendering-files and change the thumbnail size. As noted above, several other communities have made this change already, and I'll add that AFAIK no community has ever switched to a bigger number, regretted it, and then asked to be switched back to a smaller size. BTW, because the English Wikipedia is the largest wiki in the history of the world, etc., the actual switch is something that requires a bit of planning. This is not difficult – in fact, on our end, it's really quite easy – but we should not be surprised, e.g., if we get an official request to manually set the images in the very most popular articles (probably on the order of the top 0.01% by page views) to the new size in advance of the official switchover. We can send a bot around to do this (and also to undo it after the switch is made), and that will take some of the strain off the servers on the magical day (plus give both editors and readers a way to see the change in action before it happens everywhere). Let's do this. WhatamIdoing (talk) 04:55, 7 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing. I've had a default size of 300px for a couple of years now, and it's hugely improved the desktop reading experience. MichaelMaggs (talk) 11:09, 7 January 2024 (UTC)Reply[reply]
Oppose We still also must consider mobile screens, and going above 220 px will put a strain on those readers. If you are on desktop, you can set the default size through a registered account to handle this. Masem (t) 18:32, 7 January 2024 (UTC)Reply[reply]
Why would it? As mentioned above, since images are put on their own line in mobile, having bigger images is nice and causes no issues. I just increased my thumbnail size to 300px and it looks great - a lot of images are a lot easier to see that way (Special:Preferences#mw-prefsection-rendering-files also affects mobile, so you can test it for yourself). 250px is not going to cause any issues for mobile. Galobtter (talk) 18:53, 7 January 2024 (UTC)Reply[reply]
I disagree, I find larger thumbs on mobile to be too large for a reasonable reading experience. Masem (t) 20:13, 7 January 2024 (UTC)Reply[reply]
I'll also add that there is an issue with anything larger than 220px for a large chuck of non-free images, which we have constrained to 0.1MP. Many portrait non-free images like movie posters end up with image sizes around 400 x 225 px to stay within the 0.1MP. Thumbnail sizes over 220 px will implicitly and incorrectly imply that non-free images can be uploaded to larger sizes, which will not happen. Masem (t) 20:19, 7 January 2024 (UTC)Reply[reply]
Is there any actual legal basis for 10% of a megapixel? My impression is that this was more or less a random number pulled out of somebody's. jp×g🗯️ 15:42, 8 January 2024 (UTC)Reply[reply]
Support, especially for mobile. I've got a tiny screen for a mobile, and default thumbnail has a lot of ugly white around it. On desktop it's a no-brainer; I usually set upright=1.35 to ensure images/graphs are easy to see. By choosing a better default, fewer people will need to rescale. Many people rescale using the px parameter, which causes accessibility issues, so another plus if that is avoided. My guess is that a default of 300px or 260px would be even better. —Femke 🐦 (talk) 18:58, 7 January 2024 (UTC)Reply[reply]
Support - Sensible suggestion. I would even support 300px in the future. Schierbecker (talk) 19:07, 7 January 2024 (UTC)Reply[reply]
Support Looks good, more accessible, and none of the concerns raised bother me. ~ F4U (talk • they/it) 19:12, 7 January 2024 (UTC)Reply[reply]
Support as a longtime smartphone user. My phone can easily handle the larger images. Cullen328 (talk) 19:13, 7 January 2024 (UTC)Reply[reply]
Support Jeez, I remember it was pulling teeth to get the thumb size bumped up years ago, and now it's been more than a decade? I think we are hitting the useful limits of thumbnail size at 250px, given that a) lots more reader use is mobile, which is width-restrained, and b) the WMF's Vector redesign harms screen horizontal real estate for the vast majority of readers and it's likely even if they're browsing full-screen at 1920x1080, they don't necessarily have correspondingly more content area, but I think the small bump proposed here is sensible. Der Wohltemperierte Fuchstalk 19:24, 7 January 2024 (UTC)Reply[reply]
Support. This is less of an issue with Vector 2022, which makes the horizontal area much smaller, but I still recommend it be done. I myself have manually set the thumbnail size to 400px so I can see more in Vector 2017, which is the skin I use. SWinxy (talk) 19:45, 7 January 2024 (UTC)Reply[reply]
Support I set my personal default to 400px some time ago and that's fine so even 250px is small. And I'm not using anything special – mostly a 1920 x 1080 laptop or a smartphone. Andrew🐉(talk) 21:09, 7 January 2024 (UTC)Reply[reply]
Support: aesthetically, I like the current size better, but that's no reason to oppose, just my opinion. I am convinced by supporter's arguments above. 🌺 Cremastra (talk) 22:41, 7 January 2024 (UTC)Reply[reply]
Support. I do not see downsides to this proposal. Screens are significantly larger than they were a decade ago, so they should be able to handle slightly larger thumbnails just fine. For non-free media, that means the media will likely be smaller than the proposed new default, but that is only a minor issue. Conversely, I think 250px default thumbnails would be a significant benefit for both desktop and mobile users, especially seeing how many articles already use images that are 250px or larger in their infoboxes. – Epicgenius (talk) 23:28, 7 January 2024 (UTC)Reply[reply]
The "0.1 megapixels is an ironclad rule we bot-enforce" definition of "low resolution" is something else that probably needs revisiting in a separate discussion. Der Wohltemperierte Fuchstalk 01:00, 8 January 2024 (UTC)Reply[reply]
Yeah that seems like a very arbitrary rule we could relax without issues. Galobtter (talk) 14:56, 8 January 2024 (UTC)Reply[reply]
In that case, I don't think there are any other issues with upscaling the default thumbnail size to 250px. Although I definitely see why there is a size limit for non-free media, I agree the 0.1 megapixel limit seems arbitrary (for example, why can't it be 0.11 or 0.12 megapixels, which would allow non-free media to be slightly wider?). – Epicgenius (talk) 19:56, 8 January 2024 (UTC)Reply[reply]
Strong support - sane defaults make the world go round. There's always option for templates and or individuals to hard-code other sizes. ~ 🦝 Shushugah (he/him • talk) 23:59, 7 January 2024 (UTC)Reply[reply]
Support, a really good idea. Now hopefully somebody will get around to increasing the default text size, probably small enough that it was designed for 18-year-olds with the eyesight of eagles. Randy Kryn (talk) 00:32, 8 January 2024 (UTC)Reply[reply]
Support Reading and commenting from mobile to say that this looks better on the mobile version of the wiki and doesn't raise any issues there. CoconutOctopustalk 12:20, 8 January 2024 (UTC)Reply[reply]
Support going straight to 300px; I am almost kind of reticent to support going to 250px because we might end up stuck there for another fifteen years. 300px is, I'd say, close to an absolute minimum for things being legible. 220px is so mindbogglingly tiny I can't even explain it without using language from the old country:
>220px thumbnails
>2011
I seriously hope you guys don't do this
All else aside, this is a great idea and overdue. jp×g🗯️ 15:33, 8 January 2024 (UTC)Reply[reply]
For reference, here is a screenshot of this page on a 4K monitor at 100% zoom level lol.Please sir may I have some more pixelsjp×g🗯️ 15:38, 8 January 2024 (UTC)Reply[reply]
The default skin has limited width, not to mention most use 1080p monitors. You may make it 300 for yourself. Aaron Liu (talk) 15:42, 8 January 2024 (UTC)Reply[reply]
The default skin was not handed to us on tablets from heaven; it was made by designers in accordance with the constraints of the project, one of which was that thumbnails were 220 pixels wide. This seems like a rather circular problem: we can't increase the thumb resolution because the skin wasn't designed around them, and the skin won't be designed around larger thumbnails because we don't use them? jp×g🗯️ 20:45, 8 January 2024 (UTC)Reply[reply]
Hmm, I've searched a bunch of places and I can't seem to find a place that says V22 was designed on the basis of 220px thumbs. Aaron Liu (talk) 20:59, 8 January 2024 (UTC)Reply[reply]
Weak support. It's a marginal change, but apparently important enough to end up at CD. Oh well – I kinda like bigger images anyway. I can't support this beyond personal opinion on aesthetics, but I'd be willing to put a Weak Support on it. InvadingInvader (userpage, talk) 15:57, 8 January 2024 (UTC)Reply[reply]
Support per WhatamIdoing given that the screen resolutions of both computer and mobile screens has increased since 2009 designation. BluePenguin18 🐧 ( 💬 ) 16:35, 8 January 2024 (UTC)Reply[reply]
Support per WAID. Personally, I use 300px, which works fine also on my phone. —Kusma (talk) 18:21, 8 January 2024 (UTC)Reply[reply]
Strong support - Increasing to at least 250px (if not 300px) makes sense in relation to more advanced mobile phones and desktop screens. As a visual thinker and learner (as opposed to a "word person") this change would also increase literacy for those of use who are visually dominant. Therefore I see it as an accessibility issue as well. Netherzone (talk) 18:36, 8 January 2024 (UTC)Reply[reply]
Support Just like with money inflation, keeping as the relative same as 15 years ago would be about 500px and 250 is a tiny step in comparison. North8000 (talk) 19:04, 8 January 2024 (UTC)Reply[reply]
Flag icons for sports men and women should show the country they represent in sport if it is a page related to international events, if not (eg. pages relating to club sport and club teams) the flag icon should show their actual nationality/nationalities
Examples: John Aldridge is an english footballer who chose to play for the Republic of Ireland in international football. Meanwhile John Barnes played football for England but is also a dual-national Jamaican. Firestar47 (talk) 22:56, 5 January 2024 (UTC)Reply[reply]
Support This goes beyond flag icons. Multi-national athletes are becoming more common, and should be listed against the country they are actually representing at a particular event, even though this may mean different nations for the same athlete on different pages. It will also stop arguments over what nationality someone is (which often they don't even know themselves). Hawkeye7(discuss) 23:07, 5 January 2024 (UTC)Reply[reply]
Oppose - I support the existing guidelines on this as presented at MOS:SPORTFLAG. Using flag icons to indicate representation in some articles and nationality in others seems likely to cause confusion. If representation isn't needed, just don't include a flag icon at all. Since this proposal contradicts the guidelines at MOS:SPORTFLAG, it needs to be advertised at Wikipedia talk:Manual of Style/Icons. Nosferattus (talk) 01:41, 6 January 2024 (UTC)Reply[reply]
Oppose per Nosferattus, use the representative nationality yes per MOS:SPORTFLAG, do not introduce flags elsewhere to mean other things. CMD (talk) 02:05, 6 January 2024 (UTC)Reply[reply]
Oppose. MOS:SPORTFLAG does a good job capturing the appropriate use of flag icons attached to a person's name. Flag icons should not be used to represent an individual's country of citizenship, country of birth, nationality, ethnicity, or any other combining parameter. Then they become debatable, changeable, and potentially confusing. Also flag templates are wasteful of memory, and flags are annoying and give undue prominence to nation states in a world where such divisions already causes enough problems without importing them to unrelated matters. Folly Mox (talk) 14:41, 7 January 2024 (UTC)Reply[reply]
Improvement to how Wikipedia handles multiple citations of the same source.
Currently multiple citations to the same source are handled reasonably well, with a number appearing in superscript in the body multiple times, with the same number appearing just once in the references list, with letters (a, b, c, etc) after the number allowing you to return to the exact place in the article that you were up to, however, the reader won't necessarily know whether they were up to a, b, c, or whatever. Sure, it's usually not too hard to find your place, but it could be made easier if the in-text superscript said for example, 8a, 8b, 8c, etc rather than just using the same repeated numeral for multiple citations of the same source. MathewMunro (talk) 05:38, 7 January 2024 (UTC)Reply[reply]
When clicking the numbered link to get to the ref, the ref becomes highlighted. Maybe the specific 'a', 'b', etc. could be specially denoted there? That would be an extension with consistent behavior. Changing the way the footnote marker is written in the text seems more confusing to readers, since it suggests that either there are different refs ('8a' vs '8b') or that there are different subparts of ref 8 (some refs do bundle multiple entries). DMacks (talk) 05:50, 7 January 2024 (UTC)Reply[reply]
Sure, the reference becomes highlighted, but whether you have to click on 'a' or 'b' or whatever to get back to where you were is not clear, whereas if the superscript in the body of the article said '8a' or '8b', it would be pretty clear which one you were up to. An alternative would be to differentially highlight the 'a' or 'b' after the '8' or whatever number & letter it was in the references after you click on the superscript number in the body of the article, so you know which letter to click on to get back to where you were, or some similar means of making it stand out so that people know which one is the one to click to get back to where they were. MathewMunro (talk) 10:23, 7 January 2024 (UTC)Reply[reply]
It sounds like you are objecting to my proposal of do exactly what you later wrote as your alternative:) To wit, I wrote "clicking the numbered link to get to the ref...the specific 'a', 'b', etc. could be specially denoted [in the ref after clicking]". DMacks (talk) 14:11, 7 January 2024 (UTC)Reply[reply]
Sorry, I didn't understand what you meant by 'Maybe the specific 'a', 'b', etc. could be specially denoted there?', but I'm on the same page now :)
And yes, that would be a smaller and for some a less confusing change. Highlighting the specific 'a', 'b', etc in a different colour would be one effective way of specially denoting which hyperlink to click on to get back to where you were. MathewMunro (talk) 14:39, 7 January 2024 (UTC)Reply[reply]
This seems like it would be confusing in combination with T100645, which IMO would be far more useful than this. Particularly since it seems to me that the browser's back button is more convenient than trying to figure out whether 'a' or 'b' or whatever is the right tiny link to click to get back, assuming someone isn't just using the Reference Tooltips gadget in the first place. Anomie⚔ 14:05, 7 January 2024 (UTC)Reply[reply]
That phab task looks like it would be a software replacement for {{rp}}? That sounds helpful. I agree that the idea floated here, of adding letters to the citation numbers[2b] would be more confusing than anything else, and imply a seperate work or portion of work supporting the cited claim despite actually being the same.[2a] Seems like it might also interfere directly with the citation style of some articles, which use ref groups to generate citation numbers with a similar format.[C 2]I'm not necessarily against a software patch to use javascript to change the metrics of the hopback link followed to make it easier to guess, but: the tiny sliver of the userbase that actually interfaces with citations probably reads them through an on-hover or single tap, without clicking through to the reflist; whenever I guess wrong, I tap "back" in the browser and guess again; most multiply cited sources shouldn't have so many different loci of citation that it's a difficult or tedious process to find the correct hopback link; and those that are cited that many times will probably be recognisable based on their oft repeated citation numeral, negating the need to click through to it after the initial few appearances. Folly Mox (talk) 14:29, 7 January 2024 (UTC)Reply[reply]
Thanks for the tip. I didn't realise just using the browser's back button would take me back. Although I noticed that when using the back button, the reference will be somewhere on the page, depending on where it was (top, middle or bottom of the page) when you clicked on the reference, but clicking the correct 'a', 'b', 'c', etc hyperlink in the references will set the relevant line in the body of the article to the top of the page, making it easier to find. I realise that most people can find a reference that's somewhere on the page pretty easily, but it is easier to find it in my opinion if it's at the top of the page.
I accept that there are drawbacks of using a 1a, 1b, 1c, etc referencing style, and so forget about that. How about instead we do either one or preferably both of the following:
1. Make the back button take you to the place you were, but with the line containing the reference set to the top of the page; and
2. After you click a citation superscript numeral in the article's body, highlight & bold the relevant 'a', 'b', or 'c', etc in the references that you have to click on to get back to where you were?
Although, I just noticed that if you click the little '^' symbol in the references, it does exactly what I want it to do, and the hover works well too, so maybe it's just a matter of learning how to use it properly :) although, there's nothing wrong with having multiple ways of accomplishing the same thing. MathewMunro (talk) 14:49, 7 January 2024 (UTC)Reply[reply]
Neither of these is a good idea. We should not attempt to change how the browser's "back" button behaves. Some websites do this, by various means including server-side immediate redirection, client-side immediate redirection, and Javascript that actually modifies the botton's action. It can mean that you get trapped on that website with no way of getting back to where you came from - this might of course be intentional, but it's not what we want for our readers.
When you follow a link from a superscripted ref marker to the ref itself, or from the backlink on the ref to the superscripted ref marker, the place that you reach gains a pale blue background; this is due to a CSS rule:
The first selector (ol.references li:target) goes for a whole list item in the references section. To pick out an individual backlink within that list item could be possible, but would mean that the individual backlink would need to be the target of the link from the superscripted ref marker, and since this is not the whole ref, the pale blue background would be less visible. Such changes - even if agreed on here - would need to be requested through phab:. --Redrose64 🌹 (talk) 18:18, 7 January 2024 (UTC)Reply[reply]
Agreed modifying the back button behaviour would be bad if it had any kind of spill-over effect trapping you on a page. I certainly don't know enough about web-programming to know whether or not it could be done in a way that only does what it's supposed to do on all browsers & devices. And if you had to choose between highlighting the whole reference and highlighting just the relevant 'a' or 'b' or whatever, you would certainly be better off just leaving it the way it is, especially seeing as clicking the '^' symbol takes you back to where you were even if you don't know whether it was reference 'a' or 'b' or whatever. But if you could differentially highlight both the whole reference and the relevant 'a' or 'b' or whatever, (or change the text colour of the relevant 'a' or 'b' or whatever in addition to highlighting the whole refernece) that would be ideal, but again, this would only be a very very marginal improvement. I'm happy to let it go :) MathewMunro (talk) 21:07, 8 January 2024 (UTC)Reply[reply]
Idea lab
Interest in testing a tool for Breaking News? Seeking feedback.
My team at the foundation, WME, has developed a dashboard that tries to identify new articles related to global "newsworthy" events as they are being written about across Wikipedia language editions at any given moment. You can read more about it here. I'm seeking help to improve the feature.
I'd appreciate if anyone that tries it out can surface any potentially missing templates from across language projects that would help us capture more results. Using the thumbs up and down buttons in the demo to confirm or deny if entries are accurately identified as breaking news, would help me in the long and medium-term in building a better, more accurate tool.
Although Enterprises' focus is not on creating editing tools or gadgets, we hope this can be of use to the community, too.
Are the thumbs up/down supposed to be if the article as a whole is about a current news event, or has been created in wake of a current news event? Because e.g. you have on the tracker Mama Diabaté who died two days ago, so that would be news and result in increased traffic and editing, but her notability would have been established over decades. On the other hand 2023 Guyana Defence Force helicopter crash was created for the purpose of covering a specific important recent news event. Are both to be considered "hits" for the tracker?
Also, "indications count" isn't documented, and I don't know what it means, and it seems odd (being a count) that you can only filter numbers equal to the count as opposed to higher or lower than. I also don't think the raw number of edits is too useful of a metric for the user to filter potential news articles, since news is rather localized by interest and region. Page-views-to-editor-ratio would seem more useful -- a niche new article or split may have a lot of edits from a dedicated editor and reviewers at first, but very few outside viewers will care to see it in the first hours. Any news event will blow it out of the water in viewer-to-editor ratio, even if news stories will have more anonymous editors. SamuelRiv (talk) 16:58, 8 December 2023 (UTC)Reply[reply]
Thanks for this feedback @SamuelRiv -- thumbs are to say, is this news or or not. there are a lot of false positives so were trying to filter what is not news. I'd consider both those examples as news. What is news and what isn't is so subjective, so really just up to the individual.
We don't use any pageviews right now, so all this is based on editing behavior/presence. Good call on the "viewer-to-editor" ratio idea ... My only issue that we could only calculate that 24/h too late (given how PV work right now). FNavas-WMF (talk) 21:10, 8 December 2023 (UTC)Reply[reply]
A 24h delay in the ratio is fine as long as you have some smoothing average on both views and edits -- it will be better than the metrics you currently have available. (I'm sure you can figure out better metrics once you get some data.)
News isn't really subjective in these clear cases -- your first verification would just be a Google n-gram call to see if there was a major spike in searches in the past week. If the API for that is free, that'd be the best metric I can think of. There's tons of simple algorithms to verify a spike or step discontinuity in rough data. SamuelRiv (talk) 21:20, 8 December 2023 (UTC)Reply[reply]
@FNavas-WMF many breaking news items are related to articles that already exist - so being able to see articles that have high "within last hour" activity instead of only new articles may be useful. — xaosfluxTalk 18:08, 8 December 2023 (UTC)Reply[reply]
yep 100% agree @Xaosflux -- i'm working on getting us to within the last hour method you describe as we speak! FNavas-WMF (talk) 21:11, 8 December 2023 (UTC)Reply[reply]
I would go further and say that anyone who feels compelled to write about a news event on Wikipedia should look for existing articles to update rather than create a new one. This is an encyclopedia, not a newspaper. Phil Bridger (talk) 21:27, 8 December 2023 (UTC)Reply[reply]
@Phil Bridger totally agree. It seems to me that folks, at least on enWiki, do try to add to an existing article, which is why this tools as it works now is only very good for NEW, totally unforeseen events. Do you pointing editors to existing articles that are part of news is more valuable than to new articles? FNavas-WMF (talk) 16:25, 11 December 2023 (UTC)Reply[reply]
Thanks for the ping. This is on my radar and I was even able to chat with Francisco a bit at WikiConference North America recently. I've subscribed to this discussion and I'm curious to see what folks say about the tool. ---Another Believer(Talk) 00:39, 12 December 2023 (UTC)Reply[reply]
Thanks! These comments have been very useful. I'm looking for more ways to cut down false positives to cut the noise! The "cite news" template is extremely useful to catching breaking news. It seems quite reliably used in new news events.
{{cite web}} gets used a lot as well, especially when being used by newer editors who are using one of the citation insertion tools. — xaosfluxTalk 20:46, 18 December 2023 (UTC)Reply[reply]
That template is probably less specific, though. WhatamIdoing (talk) 21:13, 18 December 2023 (UTC)Reply[reply]
Indeed. But especially if you are a user (new or old) that isn't aware of some of these templates and go through the basic VE workflow of (a) Type in something (b) Click the Cite button (c) Dump in your URL -- you will end up inserting a cite web. — xaosfluxTalk 21:46, 18 December 2023 (UTC)Reply[reply]
@FNavas-WMF, an article being tagged with {{Current}} would be a direct indicator that we consider it a current event. But it is automatically removed by bot as soon as editing activity fades, which is often still while a layperson might consider something to be breaking news. Wikipedia:Current event templates#Current events has related templates/categorization. I'm curious how your tool uses/relates to this. An article being linked from Portal:Current events would be another strong indicator. {{u|Sdkb}}talk 00:12, 3 January 2024 (UTC)Reply[reply]
Option to omit subordinate sections on edit
Case in point: [47] The editor meant to add the content at the end of the "Discussion (II)" section, but ended up adding it at the end of its subordinate section, "Split off into a new page". He didn't catch the error and it was fixed later by a different editor (me). He is an experienced editor, significantly above average in technical competence, and I see this happen too often.
(In this case, I ended up changing the level of "Split off into a new page" to that of "Discussion (II)" to prevent this from happening again, but that solution was sub-optimal. By all logic the "Split off into a new page" should be subordinate to the Discussion section.)
Even if one is aware of this pitfall, it can be really cumbersome to have to back up to find the section you want. Imagine if there are four or five subordinates, some of them really long.
There should be the option to edit a section without its subordinates. Equally beneficial on any page that has multi-level sections, including articles, not just talk pages. As for specifics, that's why I'm on this page.
One thing to consider is that an editor might not know the option exists, or it might not occur to them to use it. In such cases the option would do little good. I'm thinking a pop-up box if the edited section has any subordinates: "Do you want to include the subordinate section(s)?" ―Mandruss☎ 21:58, 10 December 2023 (UTC)Reply[reply]
+1 for this sort of feature. It's been requested in various places for over a decade IIRC. I don't get caught adding content in the wrong place, so much as it's annoying to have to scroll to the correct place and an excessively long preview of subsections I am not planning to change. DMacks (talk) 22:19, 10 December 2023 (UTC)Reply[reply]
So the last comment in that thread was PrimeHunter, one of our most credible editors on technical questions, saying this is not only technically possible but "straightforward". There was no reply, suggesting concession by the naysayers. That was at VPT, and it seems to me the next step would've been this page. Not sure why that didn't happen. ―Mandruss☎ 22:17, 12 December 2023 (UTC)Reply[reply]
I said "It seems straightforward". I'm not a MediaWiki developer and don't know how easy it would be in practice but it doesn't sound hard. I don't believe Izno's earlier comment there: I'm pretty sure "this is not technically feasible" is the answer due to the way that HTML sectioning works. That seems irrelevant. When you save a section edit, MediaWiki reparses the wikitext of the whole page in the same way as if you had edited the whole page. PrimeHunter (talk) 21:55, 18 December 2023 (UTC)Reply[reply]
-1 to the popup confirmation, but +1 to being able to edit just the "lead" of a section sans any subsections. I'm sure people will jump in with some good examples, but I'm struggling to imagine when "edit smallest applicable subsection" and "edit entire page" are both worse options than "edit intermediate size chunk". Folly Mox (talk) 02:19, 11 December 2023 (UTC)Reply[reply]
@Folly Mox: Your last sentence seems to suggest that it should never include subordinate sections, which would be another way of solving this problem; do I have that correct? If so, there are some cases where one would want to do that, such as re-ordering the subordinate sections or moving text between subordinate sections. Such things could be accomplished in other ways, including editing the entire page, but significantly less easily and more error-prone. ―Mandruss☎ 20:33, 11 December 2023 (UTC)Reply[reply]
Yeah, never including subsections except in the "edit full page" case was my idea for avoiding a popup confirmation, but those things you mention are fine arguments for retaining the ability to edit a section including all its subsections. Another one is when there is no "section lead", and the prose starts after the first subsection. Misclicking on the wrong pencil would send users to an empty editing interface, which we'd have to cancel out of annoyingly. So maybe my idea is bad? I definitely am not liking an additional modal thing to tap between the editing pencil and the editing interface, but I'm not sure of the way round it. Folly Mox (talk) 21:45, 11 December 2023 (UTC)Reply[reply]
"Editing pencil": You must be using a different editor. I click [ edit ] next to the section heading.Remember that the pop-up would only happen when there are subordinates, so the impact might be less than you imagine. The question would be asked only when needed. ―Mandruss☎ 21:56, 11 December 2023 (UTC)Reply[reply]
On mobile skin, you have to go all the way to the top toolbar on a page, click the three dots, and click "edit full page" to do that. On very large pages that may well be a bigger inconvenience than the issue described here. Mach61 (talk) 19:50, 11 December 2023 (UTC)Reply[reply]
(Actually, there's no technical reason why this feature would have to be implemented the same on m.wiki AFAIK, so carry on) Mach61 (talk) 19:52, 11 December 2023 (UTC)Reply[reply]
There are indeed two issues here. The major one is the back-end: we need MW API support for it. The other one is the interface to activate it, for which we could have all sorts UI/UX design ideas, gadgets, etc. But none of the latter matters without the former. DMacks (talk) 02:12, 12 December 2023 (UTC)Reply[reply]
That's above my pay grade. If this earned a consensus at VPR, what are the realistic odds it would happen? ―Mandruss☎ 06:47, 12 December 2023 (UTC)Reply[reply]
Any chance the gadget that allows the editing of lead sections might help? CMD (talk) 07:43, 12 December 2023 (UTC)Reply[reply]
No, that is quite different. Each section is numbered sequentially, so the lead is section 0 already and is not a header-delimited section at all (so the other sections are not subsections of it, in the way a === is a subsection of ==). DMacks (talk) 07:52, 12 December 2023 (UTC)Reply[reply]
Brainstorming a gadget that would be a clickable link in the section to call action=edit buth then intercept the actual spawning of the editor. It would snip off everything starting with the first line that begins with "==" into a hidden separate field, then reattached it when the user clicks 'publish'. DMacks (talk) 10:11, 2 January 2024 (UTC)Reply[reply]
Mechanism for establishing clearly notable topics
Some years ago, YouTube took a controversial decision that prevented users from seeing the number of dislikes (or likes) to their content. This was based on the supposed psychological effect this had on content creators. While there are obvious differences in the internal workings of YouTube and Wikipedia, the underlying logic have obvious similarities that I consider relatable. I have worked extensively with new editors on Wikipedia (even though not as often as before), and one thing that is really discouraging for them is to see their article (or AFC submission) being tagged as "not being significant". You can argue that this only means the article in its present state does not have notability established, however in
practice it really means pick another to write about, not this one. And herein lies the need for my proposal.
I intend to propose that there is a mechanism for listing definitely notable topics. Not just anyone should be allowed to enter and validate an entry to this list, probably only editors with reviewers rights should accept entries. Articles with marginable or contentious notability will not be accepted to this list. This will not in any way address other issues regarding article suitability, such as promotional/not written in encyclopaedic form/no references/etc but it will also reduce the number of blatant deletion or rejection of articles that usually have a psychological impact on editors. From experience, if a new editor creates
an article, there is a big difference between I am rejecting your AFC because this article is promotional and I am rejecting your AFC because there is no claim of notability. This vetted list will also ensure that new editors who claim they just want to create content, will be able to do that from a pool of community chosen content. You can say there are many todo list on Wikipedia across various WikiProject, but those are not really vetted and many contain non-notable article suggestion. I really think this can work and will be value-adding even though my hunch tells me
it will be hard for it to be accepted. It can very well be refactored into something better. HandsomeBoy (talk) 11:36, 15 December 2023 (UTC)Reply[reply]
I think the psychological effect you mention, as well as the extremely common and understandable misconception that notability has some connection to significance, would be well ameliorated if we change the word "notability" in all guidance across the project to the more accurate and descriptive "alreadypublishedaboutness". Notability is a word about sourcing, not any intrinsic property of a subject, and is a definition of the word wholly divorced from standard English usage anywhere but here.Having said that, the idea of a community-vetted central list of approved topics seems like it would be a systemic bias black hole.An alternative idea might be to start with topics in sister language wikipediae that have passed some form of peer review but lack a corresponding en.wp article. This could be done algorithmically, and would spread out the bias to become the bias of the experienced contributors of the entire Wikimedia editing ecosystem. I have no doubt, however, that due to en.wp's stricter sourcing requirements, there are Good / Featured article analogues on other projects that would not be acceptable for inclusion here.The real real problem, as I see it, is one of education. People seem to think that Wikipedia has an article on everything, and that therefore their thing should belong here as well. A substantial proportion of new accounts register in order to create a new article on a topic they've already selected, most of which are not the subject of sufficient prior publishing in reliable independent sources, but they don't learn that until they've had their aspirations crushed at AfC.I think I've suggested this somewhere before, and see people occasionally ask it at the Teahouse, but a pre-draft source review would be a really beneficial process to add. Before someone starts a draft, they submit a list of 3–5 sources. Then experienced editors can evaluate them, and come back with judgements as to whether the provided sources (an important distinction, moving the conversation away from the topic, which the article proposer may have feelings about) are sufficient to establish appropriateness of encyclopaedic inclusion (another go at eliminating the term notability). Folly Mox (talk) 13:09, 15 December 2023 (UTC)Reply[reply]
I think the dream was that draftspace and AfC would provide that kind of function, but that never materialised. It used to be something one could post at wikiprojects, but aside from Women in Red, I've not seen much evidence of editors doing this recently. The problem is that it would need to be a specialised review, by someone familiar with the appropriate subject guidelines and outcomes at AfD in that area; for example, rejections of academics at AfC tend to give the wrong boilerplate. Espresso Addict (talk) 00:51, 16 December 2023 (UTC)Reply[reply]
No doubt a specialised review as you describe (sort of a pre-AfD) would greatly improve accuracy, and might come close to HandsomeBoy's idea of "guaranteed notability" (minimal false positives). But it doesn't take a topic area notability specialist to tell a first-day editor "source 1 is self-published, source 2 is a press release, source 3 just mentions the subject in a single sentence" etc.I agree that the AfC declines could use an additional layer of granularity. prof being underutilised seems like a reviewer culture issue, and all the SNGs seem to have their own NN declines, but as far as I'm aware, there's no automated way to append, for example, "interviews don't help establish notability" or "a gallery hosting an artist's exhibition is not considered an independent source with respect to the artist", and the reviewers have to type it in manually, so often don't. Folly Mox (talk) 04:35, 16 December 2023 (UTC)Reply[reply]
Sure; I guess I'm principally interested in cases where a good-faith new editor comes into conflict with an enthusiastic AfC reviewer, where the newbie has a better understanding of relevant policy than the AfC reviewer, which in my experience has mainly been over academics but also occasionally material falling under CREATIVE. DGG used to accept a lot of aca-bios from AfC and no-one (as far as I know) has stepped in to fill that chasm. Espresso Addict (talk) 05:22, 16 December 2023 (UTC)Reply[reply]
That's a good point, and a scenario I hadn't considered. Folly Mox (talk) 05:28, 16 December 2023 (UTC)Reply[reply]
Possibly one way to handle this would be advising new article editors to state what notability standard they are targeting. A talk page comment saying what standard and what references prove that the article passes that standard would help any AfC reviewer. -- LCU ActivelyDisinterested«@» °∆t° 17:23, 19 December 2023 (UTC)Reply[reply]
A step in the wizard which asked the creator to check if any of the following applied (The article's subject is an academic...author...artist) and then guided them into presenting appropriate evidence to meet the relevant guideline might be useful. Espresso Addict (talk) 01:18, 20 December 2023 (UTC)Reply[reply]
I could imagine some (possibly very small) value in the question, especially if the wizard then provided more relevant advice, but I think that claiming that I think this SNG applies is kind of pointless. Just because I think the article's subject should be evaluated according to WP:SOMETHING doesn't mean that it should be, or that other editors will apply the SNG that I've picked out (even if they really ought to). WhatamIdoing (talk) 04:20, 26 December 2023 (UTC)Reply[reply]
God no. We do not need a layer on top of AfC, on top of AfD, on top of PNG. GMGtalk 01:30, 20 December 2023 (UTC)Reply[reply]
Watchlist adjuster
I have a somewhat odd way, usually setting my time limit at two days and looking at the edit as it approaches the bottom. Such edits are usually around 30 or 40 hours old, so the more obvious problems have been caught by quicker watchers and I can check for more subtle ones. However, the pace of those edits varies greatly, so I must keep going into Preferences to adjust the time limit by a fraction of a day so as to avoid missing them. Simpler if there were a click from the watchlist to the Preference page that can make fine adjustments to it. Jim.henderson (talk) 04:48, 22 December 2023 (UTC)Reply[reply]
A user script could probably do this. Might want to ask for a user script at WP:US/R. Please be very specific about which setting(s) you want it to be able to edit. Is it the "Days to show in watchlist" setting? –Novem Linguae (talk) 11:12, 25 December 2023 (UTC)Reply[reply]
In the watchlist, the "Period of time to display:" dropdown has eight predefined values: 1 hour; 2 hours; 6 hours; 12 hours; 1 day; 3 days; 7 days; and 30 days. It's not necessary to use those values - just amend the URL in the browser's address bar. Using 4 days as an example, the following amendments could be used:
The days= parameter can have any value between 0.00001 (approximately one second) and 30. --Redrose64 🦌 (talk) 16:37, 25 December 2023 (UTC)Reply[reply]
Ah. Thank you. And it resets the Preference for the next time I look. This URL editing trick is indeed quick and not too techie for me to remember. I normally run my ENWP watchlist at two days, but when traffic is heavier or I miss most of a day, I generally add one day and then trim it down successively by fractional days. Or, when a bot has made changes to a great many of my pictures in Commons, sometimes it's better to handle it by making the day count large. Then I adjust the number shown, usually by ten at a time. I still would like if the watchlist, along with the short list of choices in the multiple choice list, would offer a link to the Preference page for finer tuning. However, it looks like I'll follow this method from now on. Thanks again. Jim.henderson (talk) 01:59, 26 December 2023 (UTC)Reply[reply]
There's a setting or gadget somewhere to show a blue dot if a diff in the watchlist is unread. I set mine to show 1000 revisions, then track things that need my attention by using the blue dot. –Novem Linguae (talk) 10:10, 27 December 2023 (UTC)Reply[reply]
Brainstorming a COPYVIO-hunter bot
I'd like to propose the idea of a a COPYVIO-hunter bot, but I'm not ready to make a specific Bot request yet, and so I'd like to expose this idea here first to brainstorm it. Sometimes, copyright violations are discovered that have been present on Wikipedia for years. (The copyright-violating content at Barnabas#Alleged writings was added on 4 August 2014 and discovered 18 December 2023.) But for an alert Tea house questioner two days ago, who knows when, if ever, this would have been discovered. That's worrisome.
We have some good tools out there, such as Earwig's detector, and my basic idea is to leverage that by building a bot around it, which would apply it to articles, and either generate a report, or apply the {{Copyvio}} template directly. A couple of additional bot tasks could streamline the human part of the investigation by finding the insertion point (Blame) and determining copy direction (IA search). There are input, performance, scaling questions, and human factors, and likely others I haven't thought of. As far as input, ideally I'd like to see a hybrid or dual-channel input of a hopper with manual feed by editors (possibly semi-automated feed by other tools), and an automated input where the bot picks urls based on some heuristic.
For performance, I launched Earwig with all three boxes checked, and it took 62 seconds to return results for Charles de Gaulle (174,627b) and 16 seconds for (randomly chosen) Junes Barny (5,563b). I'm pretty sure there are a lot more articles closer in size to the latter than the former, so let's say Earwig takes 30 seconds per search on average; multiplying that by {{NUMBEROFARTICLES}} gives us 6.43 years to search all of Wikipedia with a dumb, single-threaded bot with no ability to prune its input stack. (Of course, Wikipedia would be bigger six years later, but that gives us an idea.) Given that the Barnabas violation went undiscovered for nine years, six years is not so bad, as I see it. But not all articles are equal, and probably some pruning method could decrease the size of the input stack, or at least prioritize it towards articles more likely to have undiscovered violations.
As far as scaling, I have no idea of server availability at WMF, but presumably there are some bot instruction pages somewhere for bot writers which address how many threads are optimal, and other factors that could scale up the processing for better throughput; maybe someone knows something about that. If we had six threads going against one input stack, that would reduce it to one year; it would be great to run it annually against the entire encyclopedia.
For human factors, I'm thinking about the increased number of articles tagged with copy violations, and the additional load on admins that would inevitably result. There are currently 17 articles tagged with the {{Copyvio}} template right now. I wanted to provide some estimate of activity at Wikipedia:Copyright problems to gauge current throughput, but I'm not so familiar with the page, and was unable to do so. Inevitably, a bot would increase the load on admins (for WP:REVDEL) and other volunteers, and it would be helpful to gather some data about what would happen. Not sure if its possible to project that, but maybe a stripped down version of the bot just to wrap Earwig and spit out numbers on a test run of a week or two might give us some idea. I'm guessing in operation, it would generate a big, backlog balloon initially based on the first two decades of Wikipedia, but then its output would slow to some steady state; in any case, backlogs in other areas have been generated and attacked before with success.
Maybe a bot could somewhat reduce load per investigation, by means a handy output report that includes Earwig percent, maybe a brief excerpt of copied content, and so on. A couple of additional tasks could be defined which would work off the output report, one task running Blame on the suspect articles to add date of insertion to the report, and another to read IA snapshots and determine direction of copy (i.e., is it a mirror, or a copyvio), resulting in a report with information that ought to make the human part of the investigation considerably faster and more efficient per occurrence, which should at least somewhat offset the increased overall number of investigations.
Would love to hear any feedback on the technical aspects of this, as well as the human factors, and whether something like this should even be attempted. Thanks, Mathglot (talk) 02:00, 21 December 2023 (UTC)Reply[reply]
Maybe a fourth task could be a disposition-triage task, and would act on the report output of previous tasks based on configurable values; something like: "if copy-direction = copyvio then if Earwig-pct > 85 then remove content from article and mark/categorize as revdel-needed; else if Earwig-pct < 20 then remove Copyvio template and mark report as handled; else leave for human assessment; else mark as mirror and handled." Mathglot (talk) 02:29, 21 December 2023 (UTC)Reply[reply]
EranBot currently sends every new edit through CopyPatrol if I understand it correctly, which essentially runs the edits through Turnitin/iThenticate. One could reduce the bot load by making it only look at articles that were created prior to August 2016.
@MusikAnimal (WMF) and Mathglot: I understand that the WMF is currently working on a replacement/re-vamp of CopyPatrol (i.e. Plagiabot). Is there a way to integrate a sort of "historical article detection" into a similar interface while re-using some of the code from the new Plagiabot, or is this something that you think would be better kept separate? — Red-tailed hawk(nest) 02:42, 21 December 2023 (UTC)Reply[reply]
That's terrific news, which means, if I understand correctly, that whatever the scope of the problem is, at least it's not getting worse (assuming perfect precision from Plagiabot). So we only have to deal with the pre-whatever-year issue, and slowly chip away at it. (I am subscribed; no ping needed.) Mathglot (talk) 02:56, 21 December 2023 (UTC)Reply[reply]
@MusikAnimal (WMF) I remember putting this up on phabricator somewhere (I think?), but would it be possible to provide a stable API to integrate CopyPatrol with various other editing/CVUA tools (specifically it would be great to be able to answer the question "What is the iThenticate score/URLs for a specific edit") Sohom (talk) 06:29, 21 December 2023 (UTC)Reply[reply]
I've left MusikAnimal a comment on their WMF account talk page. It would be nice to hear from them on this. — Red-tailed hawk(nest) 17:45, 25 December 2023 (UTC)Reply[reply]
I acknowledge it's Christmas, and many WMF staff are taking vacation/holiday, so it's fairly possible that we might not hear back for a week or so. — Red-tailed hawk(nest) 17:53, 25 December 2023 (UTC)Reply[reply]
Thanks. I've added DNAU for 1 month, imagining that he may be on a nice, long winter vacation. Mathglot (talk) 21:24, 25 December 2023 (UTC)Reply[reply]
An API for reviewing/unreviewing does exist, but it's undocumented right now. It also doesn't provide Access Control headers. I was working on an external-use API for CopyPatrol, but decided to hold off until the new version that uses Symfony was finished and deployed, since it won't be usable anyway until deployment has finished. Chlod (say hi!) 02:22, 26 December 2023 (UTC)Reply[reply]
Thanks for your patience! I was "around" on my volunteer account, but haven't been checking this one until today (my first day back at work after the break).
It sounds like you all are asking for phab:T165951, which was declined last November. It can be re-opened if there's interest in it. However, it's worth noting CopyPatrol doesn't go through every edit, only those that meet certain criteria. I let @JJMC89 speak to that before I say something wrong ;)
As for an API, we can certainly add an endpoint to get the score for a given revision, if it exists in our database. That's simple to implement and won't require authentication. If you could file a bug, I can have that ready for when the new CopyPatrol goes live.
API endpoints that make changes to our db, such as reviewing/unreviewing, is another matter. Right now we authenticate with OAuth, so we'd need to somehow have clients go through that before they could use the endpoint. If @Chlod is interested in building this, I'll happily review it! :) Off the top of my head, I'm not sure how to go about implementing it. Alternatively, maybe we could provide all logged in users an API key? That would avoid clients having to login to CopyPatrol.
I don't think we want to permit requesting new scores for any arbitrary revision, at least not until our partnership with Turnitin is finalized. That should happen very soon, and then we'll know for sure if we can send out that many API requests. Some changes to JJMC89's bot would likely also need to be made. All in all, I'd say this feature request is not much more than a "maybe".
Also, in case no ones mentioned it yet, attempting to identify old copyvios is tricky because of the all-too-common WP:BACKWARDSCOPY issue. In some cases it may not be possible to ascertain which came first -- Wikipedia or the source -- so I'd weary of attempting to automate this. MusikAnimal (WMF) (talk) 00:57, 3 January 2024 (UTC)Reply[reply]
The new bot looks at edits made in the article and draft namespaces (0 and 118) to submit to turnitin and skips the following types of edits:
made by a bots or users on the allow list
(revision) deleted before processing (rare unless catching up from a service outage)
rollbacks (MediaWiki native or Twinkle)
additions of < 500 characters after cleaning the wikitext.
Those that come back with more than a 50% match to a (non-allow listed) source are shown in CopyPatrol for human assessment.
As a quick test, I added an endpoint to dump the data from the database for a specified revision.[48]
{"diff_id":7275308,"lang":"en","page_namespace":0,"page_title":"Mahāyāna_Mahāparinirvāṇa_Sūtra","project":"wikipedia","rev_id":1178398456,"rev_parent_id":1178304407,"rev_timestamp":"Tue, 03 Oct 2023 12:16:34 GMT","rev_user_text":"Javierfv1212","sources":[{"description":"C. V. Jones. \"The Buddhist Self\", Walter de Gruyter GmbH, 2021","percent":50.3817,"source_id":820817,"submission_id":"3084bde6-3b8b-488c-bf33-c8c27a73ae06","url":"https://doi.org/10.1515/9780824886493"}],"status":0,"status_timestamp":"Tue, 03 Oct 2023 12:38:16 GMT","status_user_text":null,"submission_id":"3084bde6-3b8b-488c-bf33-c8c27a73ae06"}
Please file a task so we can workshop the best way to design the API.
Filed as phab:T354324. This could be done on either the frontend or the backend; but it doesn't look like the backend source is publicly-available (and API endpoints are a frontend task anyway, so it should probably live on the frontend). Chlod (say hi!) 10:03, 4 January 2024 (UTC)Reply[reply]
I'd encourage making the repos public unless there is a reason for keeping them private. It will make things easier if someone goes inactive or if someone wants to submit a patch. –Novem Linguae (talk) 11:36, 4 January 2024 (UTC)Reply[reply]
Hi, Mathglot! Great to hear more initiative on copyright cleanup tasks; they're always a big help. Someone brought up a related idea at WT:CCI a while back, and I responded with a few points that probably apply here too. I've got a cannula lodged in my hand right now, so I'll copy over what I said in that thread to avoid straining it. There wasn't a lot of back-and-forth on that thread anyway so it's probably easier if I just repost it here.
There was an idea previously floated around about having Turnitin or Earwig run on all revisions of past cases; I'd say this is probably the general idea when talking about automation for CCI cases. When it actually comes down to making it happen, though, it's a spider web of caveats and limitations that make it hard to get off the ground. Here's a more-organized explanation of my thoughts that I randomly collected in the past few months:
First is the issue of cost. There's around 508 thousand revisions left to check (as of May this year), but we only ever have a finite amount of Earwig search engine searches or Turnitin credits. Processing all of these automatically means we have to work with the WMF to get more credits for a one-time run-through, and we're not sure if we'll get decent results for a majority of those checks.
We could work around this by completely disabling search engine checks, as the thread you linked discussed, but this can either work for or against us based on the case. We could also work around this by only selecting a few cases which rely mostly on web sources or (for Turnitin) sources that we know would probably be indexed. This significantly cuts down on the amount of revisions to check. But then there's the next issue:
A lot of the older cases, especially the ones over three years old, start getting a lot of false positives. As article text remains on the wiki for long periods of time, SEO spam sites, academic documents, slideshows, and others start copying from Wikipedia. We filter out a lot of these already (like those in this list and a bunch of others), but we still hit them every once in a while and enough that it clogs up what reports we would otherwise get from Earwig/Turnitin.
A possible solution to this would be human intervention (which is more or less a given with something like this), where editors will double-check to see if a flagged revision actually is copied from somewhere, or if it's just a false positive. Human intervention will weed out false positives, but then it won't weed out the false negatives.
At the end of the day, copyvio checking is a really hard computer science problem that humanity is still in the middle of solving. False negatives; like when a revision flies under the radar because a source it copied from has died, or when the text has been paraphrased enough to make checkers think it's completely original text; will always be one of the biggest brick walls we face. False positives waste editor time, yes, but false negatives arguably take up more time, because we then need to re-check the case. It also wouldn't be a good look for us or the WMF if it turns out that we get a lot of false positives and negatives, since that could be perceived by the community as a waste of funds. Perhaps this is still something that could benefit from research and testing. — User:Chlod 13:02, 24 November 2023 (UTC)
This was for checking revisions on CCI pages, but the same applies for scanning every latest revision for all articles. It seems we've also been stretching Earwig to its limits recently, Earwig has been going down for almost every day in the past two weeks (CommTech's UptimeRobot). Unfortunately, the Earwig logs are project members-only, so I can't snoop in to figure out the cause by myself. But usually, we chalk this up to Earwig running out of Google API tokens. Would appreciate comments or ideas for the problems above; anything to ensure copyvios don't fly under the radar. Chlod (say hi!) 02:15, 26 December 2023 (UTC)Reply[reply]
Chlod thanks much for this. A few questions or comments:
Whats the 508,000 revisions? Is that just from CCI investigations?
In that same bullet, what cost are you talking about, processing time? And what did you mean by decent results, are you alluding to false +/- that you raised lower down?
As far as the workarounds, this sounds like roughly what I referred to as various pruning methods to shorten or reorder the input list.
Re false + due to websites copying from Wikipedia, I don't see this as a major problem and I addressed it in the 'direction of copy' comment involving IA checks. Maybe we'd have to negotiate with IA for a certain amount of search traffic per unit time, but as a fellow non-profit and given the reasons for it, I can't imagine there wouldn't be some positive arrangement to come out of that. That would eliminate the need for human intervention in a proportion of cases; see the "if-then" psuedo-code at the end of my comment. The triage attempts to automate a lot of it, and steer only the grey-area cases toward human intervention. And it should also weed out most false negatives for the same reason, and I don't see the failure to have 0% false negatives as a problem. There is always a problem identifying edge cases, even when humans are involved; if an automated solution improves our accuracy and throughput over what it was before, then it's worthwhile. One hundred percent accuracy and coverage are a goal but they will never be attained and that shouldnt stop us from incremental progress; even if automated processes fail to identify some sites for human intervention, we'll catch 'em, hopefully, next iteration of the processing.
"Really hard computer science problem": again, imho, we don't need to "solve" it, we just need to do a bit better than we were doing heretofore. Paraphrase will fall, imho, to better shingling turbocharged with some AI to recognize synonyms and linguistic transformations at some point in the not-nearly so distant future as I would've guessed a year ago. We needn't let the perfect be the enemy of the good, and I think we can do a lot of good now.
Yep, the 508k revisions is those we have to check at CCI. That's from a dashboard by Firefly to see how much is left. It has its inaccuracies, but it's correct for most cases.
For the cost, it's actual monetary cost. From what I've heard (and what I assume from what I've heard), the WMF pays for the Google API and Turnitin credits, and that cost is pinned to how much we use Earwig and how many edits are checked by CopyPatrol, respectively. Attempting to request more credits for either needs discussion with the WMF, who then needs to discuss with Google/Turnitin. And yeah, the decent results is whether or not Earwig comes up with a false positive/negative.
Definitely; there's a lot of one-or-two-sentence stubs that don't really need checking. This could, of course, be filtered out, possibly with a lot more criteria for skipping than just that.
I'm wary about using Internet Archive as a "source of truth" for dates. Though we do exactly that in CCI, it's probably not reliable enough to make broad judgements on whether a page is a copy or was copied from. If the pipeline goes Earwig → URL of likely match → Internet Archive, the data it would provide in a report could be a false positive if either the page changed URLs at any point in time (as I've seen happen with Sparknotes) as Internet Archive may not recognize the switch or if it was never archived before (though this practically never happens for recently-added citations). Of course, it's best if this is tested empirically first.
This is a step in the right direction though. The downside of not using a system like this at all is that the direction checking will be manual, which then just pushes the investigation work back to the addressing user/administrator, and that could result in anywhere from zero (by luck) to a lot of false positives. But what has to be checked first is whether this will end up increasing processing time/workload for checking users.
Earwig's Copyvio Tool is actively maintained by The Earwig. The recent downtimes were shortly discussed in User talk:The Earwig § Copyvio tool is down; I only saw this now. Seems to have been from increased usage.
I agree; something is better than nothing. I'm mostly just worried about stretching the few editors working on copyvio even thinner by adding more work to do. We could balance this by encouraging more editors to help out at WP:CCP, but copyright cleanup really just has historically low participation rates. Chlod (say hi!) 05:14, 27 December 2023 (UTC)Reply[reply]
Hey Chlod, thanks for pinging me here.
With Google's API, there's a hard daily limit of 10,000 queries per day, which costs US$50. The copyvio detector will make up to 8 queries per page (each query corresponds to a sentence or so of text, so that is chosen to strike a balance between performance and detection accuracy – longer articles would really benefit from more than 8 queries in many cases). So that works out to somewhere between 1,250 and 10,000 articles per day; let's say 2,000 on average. To be very clear, that's a limit built into Google's API terms. We can't get around it without a special agreement with Google, and everything I've heard from the WMF indicates we have no special agreement: we're paying the regular rate. Over ten years of running the copyvio detector, and despite multiple people asking, I've never managed to make the right connections with the right people at Google to get a special agreement (or the WMF hasn't, and IMO it's really them who should be doing that instead of me).
Just bashing the numbers out, checking 500,000 pages without a special agreement with Google would cost $12,500 and take at least 8 months (again assuming 5 queries/page).
The search engine is really the limiting factor here, hence my emphasizing it. Compute cost is much cheaper and we could use WMCloud to parallelize this more effectively if the daily limits weren't so severe.
Recent issues aren't related to using up all of our Google API credits but mostly due to my own poor software engineering decisions ten years ago. Sometimes it's due to unauthorized bot traffic that needs to be identified and blocked, but in this case I haven't noticed any. There's an ongoing project to improve performance, but no timeline for when it will be ready, unfortunately.
Thanks for these detailed explanations. Just noting that I've started User:Novem Linguae/Essays/Copyvio detectors to try to document all these copyright tools and their nuances. Seems like every couple months this comes up and I've forgotten all the details since the last discussion, so maybe an essay will help me remember it :) –Novem Linguae (talk) 12:13, 31 December 2023 (UTC)Reply[reply]
@The Earwig: Anywhere I could possibly help with the copyvio detector's uptime? It's also affecting the NPP workflow at times, as the copyvio detector is part of checks to be done when patrolling. Chlod (say hi!) 13:56, 4 January 2024 (UTC)Reply[reply]
@Chlod: Thanks for offering to help! I've given you maintainer access to the tool, and you have permission to restart it when needed. This is the case if the request backlog gets full (a log message "uWSGI listen queue of socket" is printed to uwsgi.log over several minutes) but occasional slowness doesn't necessarily mean the queue is full and needs to be cleared. It's good for us to have maintainers across different timezones. But beyond the occasional restarts, addressing the underlying issue is complicated and not something I expect help with. As hinted above, a backend rewrite is in progress to improve performance. — The Earwig (talk) 16:41, 4 January 2024 (UTC)Reply[reply]
As I understand it, the issues with applying Earwig's copyvio thing to more pages (and the reason it always takes a million years to run) has nothing to do with computational power or programming skill on our part, but rather because Google search, which is a quite critical part of this software working, has deliberately decided to fuck us sideways on search queries.
Well, it's not clear: it could be that or it could be that nobody from Wikipedia or from the WMF has succeeded in figuring out how to ask them from a special dispensation.
At any rate, we have a rather low quota, and it would cost tens of thousands of dollars to make it higher, and we do not get any special dispensation although I guess they are perfectly fine to make millions of dollars from reusing our content in their own knowledge panels lol. jp×g🗯️ 11:25, 28 December 2023 (UTC)Reply[reply]
Maybe @NPerry (WMF): might give more insight as to why the Wikimedia Foundation has not been able to get resources for copyright detection with Google search ? AFAIR, last year, they were involved with managing Wikimedia's partnership with Google. Sohom (talk) 11:54, 28 December 2023 (UTC)Reply[reply]
I'm not active in copyvio detection work, so take what I say as an outsider's perspective. Overall, copyvio detection on Wikipedia seems like an area that's struggling despite the heroic efforts of those working on it — multi-year backlogs at places like CCI are indicative of a system that's just not working. Bot assistance is our best hope of changing that dynamic on a systemic level, so I think it's a fruitful avenue to pursue. It'd be complex on a level greater even than ClueBotNG, but if successful it'd be similarly impactful.One thing to perhaps think about is the difference between old copyvios and newly added ones. My vague understanding is that a lot of the difficulty/pain comes from years-old insertions, which have since been built upon, necessitating removal of large chunks of an article. If it'd be simpler to build a bot that only checks/fixes new contributions, then perhaps that'd be a good place to start. If it could sufficiently stem the tide, perhaps it'd lead to a situation similar to what we have with non-notable articles/deficient FAs today, where there's a bunch of stuff in the past to clean up, but ultimately it's a finite backlog with few new entries being added, creating hope we'll someday get through it (cf. WP:SWEEP).Hope that's helpful, and good luck with this work! {{u|Sdkb}}talk 00:03, 3 January 2024 (UTC)Reply[reply]
(Possible overlap with part of above) - we have a copyright flagging system already (see log) - and allowing more bots to flag is fairly easy to do. Like many have said, building a reliable algorithm for doing the actual checking is a "hard" problem. One problem that came up during prior third party solutions like TURNITIN is that these companies wanted to reuse Wikipedia content without honoring the licensing requirements (e.g. We send them some text, they store it, then they reserve that to other people without attribution). — xaosfluxTalk 17:00, 4 January 2024 (UTC)Reply[reply]
Grammar checker
My idea is that when you edit an article, there should be a built in grammar checker that doesn't detect spelling errors in links but instead in general text. Oo-rah! the marines are here (talk) 04:37, 21 December 2023 (UTC)Reply[reply]
@Redrose64: Is there a regional variety of English in which "comittee" or "paralell" are considered correct? jp×g🗯️ 11:34, 28 December 2023 (UTC)Reply[reply]
To me, the idea of a spellcheck feature built into the editing interface seems like it would have negative utility. In addition to the ENGVAR issues, spell checkers in general have a tendency to propose changing proper names they don't recognise into common terms they do, and the same goes for words in other languages, which appear with some frequency in certain topic areas. Additionally, high typo / misspelling proportions in an article can be a hint there are deeper issues, since they are often the earliest problems corrected. Folly Mox (talk) 19:50, 30 December 2023 (UTC)Reply[reply]
Disagree. In addition to what others have stated, spellcheckers can be clumsy when applied to technical topics. A spellcheck function would be very obtuse when, say, talking about genes that often have strange names like GLUT. Even if this could be disabled, I can foresee countless edits by laypeople to "correct" something the program highlights, but is accurate. Just-a-can-of-beans (talk) 00:03, 1 January 2024 (UTC)Reply[reply]
How to message a range
So, there was one day where an IPv6 made an edit/addition to an article which was later modified by an user. A little later, a different IPv6 commented on this edit on the user's talk page. The IP Range calculator says that they have a common range 2a01:cb1d:3cf:ca00::/64, and according to mw:Help:Range blocks/IPv6 this is a range with an "end-user allocation size" which I guess means "probably just one computer". The list of enwiki contributions from said range and list of global contributors from said range strongly imply that all the edits come from the same person. However, the only action that can be performed range-wide is a block. Has anyone ever thought of creating a message/ping functionality for an entire range? Jo-Jo Eumerus (talk) 10:17, 23 December 2023 (UTC)Reply[reply]
Or make it worse, depending on how it works. I don't see much explanation of how it applies vis-a-vis a range. Jo-Jo Eumerus (talk) 08:35, 26 December 2023 (UTC)Reply[reply]
I've asked questions on that matter but not received answers, probably because no decisions have been made. If a vandal can just hop from 2000:9:8:7:0:0:0:1 to 2000:9:8:7:0:0:0:2 and appear like someone on the other side of the world, we'll have to reconsider whether to abandon our founding principles and disallow unregistered editing. I'm hoping that the lack of response means that the backward step of IP masking is stuck in development hell and won't be imposed in the foreseeable future. Certes (talk) 11:40, 26 December 2023 (UTC)Reply[reply]
Thanks. Of course, clearing cookies isn't always malicious, and tools such as uMatrix withhold cookies from sites which request but don't need them. I have it turned off for Wikipedia, because this site uses cookies in ways that help readers rather than advertisers, but casual visitors may not. Certes (talk) 14:11, 26 December 2023 (UTC)Reply[reply]
Maybe try to make the mobile version of the website more comfortable for readers
For me, the display of the mobile version is not very comfortable for me and I have trouble understanding what I‘m reading. Can we make it more easier to read and more comfortable? Acman1o (talk) 01:20, 24 December 2023 (UTC)Reply[reply]
Acman1o, what facets of the mobile reading experience are uncomfortable for you or lend themselves to misunderstanding? Special:MobileOptions allows you to adjust the default font size if that would help. The Wikimedia Foundation actually did a lot of research and testing to try to make the website as readable as possible, most recently by increasing the default spacing between lines, I think. More work has gone into the desktop skins, so depending on your device and your eyes, you might find the desktop version more comfortable, but you might be redirected to the mobile frontend unless you have "Desktop site" (or similar) enabled in your browser. The dark mode gadget (enabled in Special:Preferences) has made my experience here a lot more comfortable. Folly Mox (talk) 02:23, 24 December 2023 (UTC)Reply[reply]
According to this announcement, WMF are planning on launching a new beta feature soon that should allow you to fine tune the typography of the site for your account. The main project page is here. I'm sure they'd welcome your feedback. Folly Mox (talk) 02:29, 24 December 2023 (UTC)Reply[reply]
Deletion of account is needed
There should be an account deletion system. Edits made by deleted account should be left with name of the account without a link. 160.238.0.118 (talk) 19:34, 26 December 2023 (UTC)Reply[reply]
For legal reasons related to attribution of material, it is not possible to delete accounts. They can however be renamed in some circumstances: see Wikipedia:Courtesy vanishing. AndyTheGrump (talk) 19:45, 26 December 2023 (UTC)Reply[reply]
Given I can just search for all other edits made by that "name of the account", there is no difference whether or not they have a "link". Sounds like a distinction without a difference. What is it your understanding of what an 'account' actually is? DMacks (talk) 10:03, 2 January 2024 (UTC)Reply[reply]
Curlie
Curlie is the successor to DMOZ. We have a long tradition of including links to DMOZ in lots of articles and the current template, {{Curlie}}, has 6749 transclusions. I saw it recently and thought "who uses these anymore?" Web directories used to be essential tools, but in 2024 ... I can't remember the last time I used one. Most seem to be a combination of links already easily found in relevant Wikipedia articles, the most obvious links that would come up with any search, and spam. Over time, we've come to see the external links space as something to be used sparingly, but these remain.
So, real question: does anyone use these Curlie links?
This is not a proposal to remove them, to be clear. Even if they aren't used very often, they may be sufficiently aligned with our ideals/purpose to retain them, but it seems worth asking nonetheless. — Rhododendritestalk \\ 18:29, 28 December 2023 (UTC)Reply[reply]
Maybe it's time for another TfD discussion. Some of the "keep" opinions last time seemed to want to keep these links only as somewhere to send people who want to add unwanted links to Wikipedia articles. That is a very poor reason for keeping. We should be honest and tell people that their links are unwanted if that is the case. Phil Bridger (talk) 18:37, 30 December 2023 (UTC)Reply[reply]
Allow soft deletion of unopposed nominations
Hi. I am wondering what people would think about repealing the "a page is only eligible for soft deletion if it has been PROD'd/deleted in the past" rule. I am not the most active person at AfD, but I invite anyone to go to a random page in the (recent-ish) AfD archives and ctrl+f for the word "ineligible". Uncontroversial nominations (or nominations in which the nominator leaves nothing for further participants to add) get relisted all the time because someone objected to a PROD, or it was previously deleted.
I went through the closed discussions in December, and I found 36 discussions which were relisted as ineligible for soft deletion but were subsequently deleted (usually after a few delete per nom or delete NN !votes, and perhaps some additional relists): 1, 2, 3, 4, 5, 6, 7, 9, 10, 11[a], 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32[b], 33, 34, 35, and 36.
To be fair, I found four bluelinks that were saved because they were "ineligible for soft deletion": 1[c], 2, 3[d], 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day[e] justify the volunteer hours spent rubber-stamping uncontroversial nominations. Therefore, my idea: let these things be soft-deleted. Even if they were controversial[f] at one point in time, they are not anymore. They would be eligible for WP:REFUNDs, and a single objection in the current AfD debate would still prevent soft deletion. I think it is time to get rid of this WP:CREEPy rule. HouseBlastertalk 05:51, 2 January 2024 (UTC)Reply[reply]
It generally takes a lot more effort to create content than to delete it, so I'd apply strict scrutiny to any proposal to relax the criteria for PRODding. {{u|Sdkb}}talk 22:35, 2 January 2024 (UTC)Reply[reply]
To be clear, this would not change eligibility for PROD. It would only change eligibility for WP:SOFTDELETEing articles listed at AfD for a week (with all the associated notifications).On a different note, I would also consider that the status quo is those 36+ articles (accounting for batch nominations) are "hard"-deleted. If someone subsequently finds sources, you either have to make a very convincing case to the deleting admin or spend a week's worth of editor-time at DRV. This proposal would make them all eligible for a REFUND.HouseBlastertalk 23:28, 2 January 2024 (UTC)Reply[reply]
Ah, thank you for clarifying, and best of luck formulating the proposal! {{u|Sdkb}}talk 23:31, 2 January 2024 (UTC)Reply[reply]
Notes
^with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...
^a batch nomination of seven was relisted because one had been dePROD'd
I respect the ambition, but realistically any massive change to WP:N would have to have been prompted by some unprecedented event or shift in community sentiment. I don't think people are actually dissatisfied with how notability as a whole works, even if some individual SNGs remain contreversial. Mach61 (talk) 10:12, 2 January 2024 (UTC)Reply[reply]
My feedback is that it looks like you are throwing out all of WP:N and trying to start again from first principles. But why? Barnards.tar.gz (talk) 11:10, 2 January 2024 (UTC)Reply[reply]
My first problem is with length: all the notability guidelines(SNG and GNG) make up for a reading experience nearing typical novellas — WP:N alone contributes 4000 words of reading material. However, all those tens of thousands words of guidance are thrown into a wrench by WP:PAGEDECIDE. How our numerous SNGs interacts with GNGs are defined is lacking, and newcomers are just meant to figure it out themselves. Any attempt to formally define it will inevitably be met with series of no-consensuses. I believe that hints that the way we are defining notability right now is fundamentally flawed. My goal with the proposal is instead of trying to use importance as criterion for inclusion(an insurmountably subjective and unfeasible task), but just to use the pre-existing policies as guidance. Catalk to me! 11:19, 2 January 2024 (UTC)Reply[reply]
Is "trying to use importance as criteria for inclusion" actually the current standard? WP:N goes to pains to distinguish notability from simple importance (except as reliable sources decide to cover it, which is the current N standard). DMacks (talk) 11:27, 2 January 2024 (UTC)Reply[reply]
That's what it says on the tin, but reading SNGs like WP:BIO and WP:NPROF clearly shows it's more of a importance criteria than anything. Even GNG proves to be an publicity indicator since it does not actually deal with article content. I don't know why we have all these guidelines when it could be replaced with "What is the best possible article that can be made?" Catalk to me! 11:40, 2 January 2024 (UTC)Reply[reply]
If you feel that the criteria are not being properly applied, have you tried fixing that first before deciding that everything should be thrown out? 331dot (talk) 11:49, 2 January 2024 (UTC)Reply[reply]
I recognize I am in a minority position with this belief but I believe notability as a system is fundamentally flawed for reasons described as above.
So I'm just wondering what makes you think a broader proposal covering more ground will gain consensus when a narrower proposal didn't. 331dot (talk) 15:04, 3 January 2024 (UTC)Reply[reply]
I would be a fool to think such a radical change like this would gain consensus. I'm poking around with different proposals to gauge community sentiment with notability. Catalk to me! 15:43, 3 January 2024 (UTC)Reply[reply]
The rationale behind notability is positively defined at WP:WHYNMach61 (talk) 16:31, 2 January 2024 (UTC)Reply[reply]
I am not sure what point is being made here. WHYN only explains the reasoning behind GNG. Catalk to me! 16:36, 2 January 2024 (UTC)Reply[reply]
So, practicality concerns aside, I want to engage with the philosophy of this, since that's really what's interesting and it's what you're looking for.
If I'm reading correctly. you see "notability", the term of art we have built up onsite, as fallacious: we claim "notability" to be something robust and objective, independent from "importance"—which is ultimately a subjective notion—but ultimately, "notability" just boils down to just being "importance" in many cases anyway. I agree with this.
However, I'm not really convinced it's a problem that can be solved, and I think your attempt goes a ways to explain why: you've just moved the problem back a step, offloading the subjectivity at the heart of an encyclopedia onto other terms of art: how do we know when we can establish WP:NPOV and WP:V—when we feel like the framing is neutral enough; when we feel like the claim is verifiable enough? Surely these can't be solved by statistical analysis, or whatever—at least I don't think so.
Since we're also axiomizing "what Wikipedia is not"—when does an article stop being an indiscriminate collection of information, or a dictionary? Those are informed by our present policy, and now they have no practical criteria whatsoever.
The consensus mechanism we have to fill in the gaps left by the flexibility of WP:N is ultimately powered by subjectivity, but I think someone here may need to win a Berggruen Prize before we can really tackle that problem. Remsense留 09:01, 3 January 2024 (UTC)Reply[reply]
I've always been first in line to say that SNGs are a mess and should generally be ignored in favor of GNG, just like discretionary sanctions should be ignored in favor of simply not being a jerk. But the community is attached to their pet SNGs and there's almost zero chance of doing away with them. We got NPORN removed, and even on such an immensely niche topic, it was like pulling teeth. GMGtalk 12:47, 2 January 2024 (UTC)Reply[reply]
If I'm understanding correctly, the problem you're trying to address is that there are some articles that meet the notability threshold but nevertheless should not have an article because of one of the reasons at WP:PAGEDECIDE. I agree that that's a problem. My explanation for it would be that, because 95% of AfDs deal with notability rather than PAGEDECIDE, many inexperienced editors use the heuristic "notable → keep" and ignore PAGEDECIDE.That said, I don't think a new policy or guideline is the solution. We already have too many of those, and the impulse to replace them with a simplified version isn't going to succeed. PAGEDECIDE already has guideline status as part of the WP:Notability guideline page, so I'd instead encourage you to suggest changes to make it clearer, more easily invoked, and the notability guideline page as a whole simplified.Something our policy/guideline pages badly need overall is for someone good at plain English writing to go through them with no agenda except shortening/simplifying/clarifying them. It won't be an enviable task, as everything on every PAG page was added for some reason or another, so there will be a lot of discussion/pushback about how to simplify without losing meaning. But it'd really be a valuable service. {{u|Sdkb}}talk 23:46, 2 January 2024 (UTC)Reply[reply]
The main thing is, I do not understand why we have the whole vaguely defined concept of notability when PAGEDECIDE supposedly trumps everything. Catalk to me! 02:15, 3 January 2024 (UTC)Reply[reply]
PAGEDECIDE doesn't trump WP:N. It says that there are times that while a topic may merit a stand-alone article that it can be shown to meet the GNG or an SNG, there are reasons not to have a stand-alone article (such as when the topic is better covered in concern with a larger topic or similar topics).
Notability is a guideline and purposely vague because it is meant to encourage articles to start from a point that shows potential for growth so that the wiki-way can be used to expand. But as others have pointed out, this is not a one-size-fits-all approach, due to systematic bias from sources. Masem (t) 05:09, 3 January 2024 (UTC)Reply[reply]
If you were seriously proposing to dump GNG and its emphasis on hype and publicity and one-size-fits-all rules over importance, and try to push more subject-specific importance-based guidelines, I might be on board. This goes in exactly the wrong direction. We cannot possibly include articles on all topics about which reliable but local or routine sources have provided enough information to write start-class articles, which is what GNG pretends to do (but in practice doesn't). Instead, we need to use notability to filter out the truly unimportant topics. But because GNG does that based on publicity, it is inaccurate and easy to game. Cutting out all the nuance and making it be one size fits all can only worsen those problems, without solving any actual problem with current practice. —David Eppstein (talk) 04:43, 3 January 2024 (UTC)Reply[reply]
I'll echo the above comment: this seems to be a step in the opposite direction from what I could conceivably report. Moreover, it doesn't actually reduce the "subjective" aspect, just pushes it off to a different place. Who decides whether a biography is "negative", or whether all the sources are "marginally reliable", or what counts as "undue weight", or when an article is "unwieldy", or when related topics are "better appreciated" as separate pages, or when a topic is "controversial" instead of "mundane"? If the goal is to reduce the number of different policy/guideline pages, I say we go all out and synthesize WP:V, WP:NPOV, WP:NOR, WP:NOT, and WP:BLP into a single Wikipedia Rulebook. They're only separate pages due to historical accidents; if one were starting a wiki-based encyclopedia project now, with the benefit of Wikipedia's accumulated experience, one could cover the whole ethos in a single document instead of multiple pages that all talk about each other. XOR'easter (talk) 05:35, 3 January 2024 (UTC)Reply[reply]
Tangential note: A few people have mentioned that it's hard understand notability guidelines due to their length and detail. A couple weeks ago, I began drafting User:Wracking/Notability with the goal of creating bullet-point summaries of each SNG, mainly for my own reference. If this is something anyone wants to collaborate on, please reach out. Wrackingtalk! 05:47, 3 January 2024 (UTC)Reply[reply]
I tend to agree with David and XOR'easter. If I got to rewrite Wikipedia's inclusion guidelines from scratch, I'd go for specific guidelines on specific subjects, based on the consensus of editors knowledgeable about those subjects, and drop the futile quest for a Grand Unified Theory of Notability. The idea that we can use a single standard to classify literally all of human knowledge into the boxes "notable" or "not notable" would sound like complete madness to the average non-Wikipedian. And then try telling them that we think we can do so with just five bulletpoints... – Joe (talk) 09:29, 3 January 2024 (UTC)Reply[reply]
Yeah, what he said, and also what they said. jp×g🗯️ 11:06, 3 January 2024 (UTC)Reply[reply]
@Joe, in fairness, the idea that we're going to have an encyclopedia that anyone can write without even needing so much as a user account or email, that also sounds like complete madness. So not sure that "sounds like complete madness" is a strong argument against anything on Wikipedia :-) Levivich (talk) 20:57, 7 January 2024 (UTC)Reply[reply]
I actually think that WP:GNG is a good Grand Unified Theory of Notability, since it ties back into core policies with the theory "So, can this topic ever make a core policy-compliant Wikipedia article?". Most alternatives tend to lean into "Someone finds this important" which is a lot more subjective and tends to invite both mass stubs and snobbery. Jo-Jo Eumerus (talk) 13:37, 3 January 2024 (UTC)Reply[reply]
Counterproposal: rename "Notability". If we're really going to rework the inclusion criteria for an encyclopaedia article here, let's do away with the confusing term "notability" and call it what it is. Right now it's something close to alreadypublishedaboutness (catchy, I know), but if we're going to redo the inclusion criteria, we could either rename the larger body of policy after what consensus agrees on the fundamental criterion is, or just call it inclusion criteria. Folly Mox (talk) 14:16, 3 January 2024 (UTC)Reply[reply]
Support this idea much more than dismantling GNG. 🌺 Cremastra (talk) 00:59, 7 January 2024 (UTC)Reply[reply]
While I'm not convinced this is necessary per se, I'm just going to vomit a few potential terms: the crime of "notability" is arguably the "-ability". However, the term should have as little lexical overlap with "verifiability" as possible.
How about substantiation, attestation, recognition, corroboration, representation, precedence?
No, I don't think any of these work: I think "notability" might be the closest, best English word to use for this concept, so that the greatest number of people understand its usage as easily as possible.
I still think it's likely we just have to live with the subjectivity at the heart of "encyclopedias" as a concept. It's not like anyone else has figured this out! Remsense留 01:33, 7 January 2024 (UTC)Reply[reply]
"Inclusion criteria" is the way to go. One fundamental flaw in "notability" is it suggests a property of the subject that we as editors are discovering (something is notable or not notable and it's up to us to figure out which). In fact, "notability" isn't a property inherent in any subject, it's a decision editors make (we don't discover or learn if a subject is notable, we decide whether subjects are notable or not). "Inclusion criteria" has the advantage of being clear that it's a set of rules made up by editors for the purpose of deciding what topics should be covered--and not some inherent property, or something having to do with the inherent value of topics. Levivich (talk) 21:01, 7 January 2024 (UTC)Reply[reply]
Oh and the inclusion criteria should be "enough reliable independent secondary sourcing to write an accurate and complete tertiary encyclopedia article" which is what GNG already tries to get at. Levivich (talk) 21:04, 7 January 2024 (UTC)Reply[reply]
Agree with this. This is why some SNGs, and de facto notability, are bad, because sometimes there isn't enough information out there to write an encyclopedic article. 🌺 Cremastra (talk) 21:14, 7 January 2024 (UTC)Reply[reply]
"Standards of inclusion" is the term I suggested once upon a time, in one of the longest discussions on renaming the notability page. One of the reasons was indeed that it emphasizes that it's a Wikipedia standard, not an inherent characteristic or externally defined property. These days I usually use the more clunkier "standards for having an article", due to Wikipedia:What Wikipedia is not, as it is another standard of inclusion based on scope that is typically evaluated independently of the guidance on the notability page. isaacl (talk) 22:34, 7 January 2024 (UTC)Reply[reply]
I have to agree with Remsense on most points. While some kind of notability reform is needed, this is not the best way to go about it. Currently, apart from some less stringent SNGs, all articles have to meet GNG. This keeps out of one-reference sub-stubs that are better suited to wiktionary or wikidata. If we remove GNG, then our only rationale for deleting unhelpful articles that wouldn't be notable under GNG is likely a combination of WP:NOTDIC, WP:NOTDB, WP:INDISCRIMINATE, and WP:5P1.
The problem is that all of those are mostly or entirely subjective. Who decides what qualifies as an "indiscriminate collection of information", or what "encyclopedic" really means, when you get right down to it? We already have these disputes (case in point: the Barbenheimer RfC), but if they became commonplace at Articles for Deletion, matters would get worse.
We shouldn't rely on subjective measures. We already do, to a degree (how much coverage is "significant" coverage? How reliable is this source, really?) but implementing such a proposal, and accordingly dismantling the GNG, would intensify existing disputes.
The GNG is not great. But it works, and it's quantifiable, at least more so than allusions to WP:NOT. You need multiple sources, three is recommended, and they have to be reliable and secondary.
I think we should have more, specific, SNGs, that are objective and easily quantifiable. Notability isn't a yes-no question, but if we have more subject-specific notability guidelines, then we can be more accurate. Vaguer standards aren't helpful, because vagueness invariably leads to disputes. 🌺 Cremastra (talk) 18:26, 7 January 2024 (UTC)Reply[reply]
WP:Notability is a big vague confusing mess but it mostly works. IMO the way that it really works is that it combines 3 attributes:
Sourcing criteria which ostensibly is the only criteria. This is also used as a measuring stick for #2
Real world importance/notability
Degree of enclyclopedicness .....degree of compliance with Wp:not, above the floor of outright rejection under Wp:not
If we ever want to tidy up wp:notability, we're going to need to acknowledge this as a starting point. North8000 (talk) 14:29, 3 January 2024 (UTC)Reply[reply]
I agree with this. There is a balance between coverage (how often and how in-depth a subject is featured in independent sources) and the importance of the subject. There ought to be or there is more flexibility of sourcing needed for individuals who are at the top of their profession (whether in academics, sport, politics, business) compared with individuals who are active locally, in minor or secondary leagues, or non-executive positions. This is why the SNGs are useful - to help make determinations of real world importance. - Enos733 (talk) 18:23, 3 January 2024 (UTC)Reply[reply]
For example, if two published high school newspapers did lengthy in depth coverage of guitar player John Smith, that fully satisfies GNG but the system might not let that one pass. If the same two writeups were in Rolling Stone magazine, the system would certainly pass him. So the prominence of the sources (combined with the space they dedicated) matters for assessing #2, and #2 matters.
Another example: A town of 1,000 people with no sources other than a couple which (merely) reliably establish it's existence. The system is going to let that one be an article. Some will say it's because "GNG sources are likely to exist" but in reality it's because it's an ultra-enclyclopedic topic. Because it passes wp:not by a mile, and is also mentioned in 5P. North8000 (talk) 21:53, 3 January 2024 (UTC)Reply[reply]
Agreed. When we let the sports SNGs die, we inadvertently opened the door to a lot of minor league baseball players, because minor league baseball necessarily receives a bunch of local/routine coverage which looks like or could be GNG even if the player never comes close to making the major leagues, which was functionally necessary to enter a print baseball encyclopaedia. I'm not generally a fan of SNGs, but the ones that exclude rather than include can be very helpful. SportingFlyerT·C 07:01, 4 January 2024 (UTC)Reply[reply]
I knew at the time that that fix was only going to be 1/2 of a fix. In the "grand wp:notability unification" that I have in my head, it
Acknowledges that real world notability/importance is a factor and the coverage is a measuring stick for that as well
Calibrates for the ratio of coverage to real world notability in that field. Since in sports coverage is an end/product of itself and so less of / a weaker indicator, coverage in this area is less meaningful and it adjusts for that
Calibrate for degree of enclyclopedicness. A typical sports artticl is a bit lower here than a typical enclyclopedia article and it adjusts for that
The net result would be that the standard would be a bit tougher for sports than it currently is. North8000 (talk) 18:14, 4 January 2024 (UTC)Reply[reply]
Adding searching to the nearby page
Hello,
Not sure is this is the correct place to put this, but is it possible to add coordinate or location searching to the nearby page, to allow for location permissions to not have to be granted?
Thanks, Geardona (talk) 12:49, 4 January 2024 (UTC)Reply[reply]
Ok, did not realise that was a feature, maybe add a search bar to the page itself for more user-friendliness? Geardona (talk) 13:03, 4 January 2024 (UTC)Reply[reply]
Auto-confirmed
Hi. I’ve realized that it’s insanely easy to get auto-confirmed status… and I thought I had to use articles for creation forever. Would it be a good idea to make it more difficult? Say 50 edits, like on es.wp, or more time editing; one month, maybe? Encyclopédisme (talk) 14:32, 4 January 2024 (UTC)Reply[reply]
I mean being able, to say, move pages, create pages etc. You need 10 edits and a 4 day old account. That is auto-confirmed. Encyclopédisme (talk) 14:39, 4 January 2024 (UTC)Reply[reply]
@Encyclopédisme Sorry, I mixed it up with auto-patrolled :) My bad !
Despite the name, the autopatrolled flag is only handed out manually. Some accounts are marked as autopatrolled fairly quickly; others can be active for many years and create thousands of pages without it. Certes (talk) 20:30, 4 January 2024 (UTC)Reply[reply]
@Certes I am one of those in the second group :) The funniest part is that I am interface administrator of Serbian Wikipedia, wrote over 800 articles there yet somehow English Wikipedia needs me to show more values.
Please don't take it personally. I've created thousands of pages over the last 16 years and am not autopatrolled. The flag is simply a convenience for patrollers, and doesn't allow the account to do anything it couldn't do anyway. Certes (talk) 22:44, 4 January 2024 (UTC)Reply[reply]
@Боки: You have been autoconfirmed since 03:20, 14 July 2020 (UTC). --Redrose64 🦌 (talk) 22:17, 4 January 2024 (UTC)Reply[reply]
@Redrose64 Yeah, I just realized that I have misread the auto confirmed vs auto patrolled :)
The section refers to autoconfirmed status, which is handed out automatically on the account's tenth edit or four days after registering (whichever is later). That link should show a box top left saying "Your account is autoconfirmed" if you are logged in to an account that is not very new. Certes (talk) 14:46, 4 January 2024 (UTC)Reply[reply]
I personally would keep the WP:AFC route, until an AFC reviewer recommends the article author directly publishes articles. Having multiple eyes is an asset, not a detriment. I wish sometimes as a niche publisher that more people would review my articles. I say that as someone who is WP:AUTOPATROLLED. But making space for newer article contributors is in the interest of the wider encyclopedia. ~ 🦝 Shushugah (he/him • talk) 17:50, 4 January 2024 (UTC)Reply[reply]
I started creating 2 articles already. One of them was reviewed, the other already edited by other editors. The problem is indeed that niche subjects are widely overlooked, and due to the small audience, often state outright false info (Specifically I created articles about the Inca, also widely touched by this), based on old sources, or works of vulgarisation which don’t correspond exactly with the academic consensus. Encyclopédisme (talk) 17:56, 4 January 2024 (UTC)Reply[reply]
Mass patrolling
Hi everyone,
I was just curious if there was any discussion earlier, as I was not able to find it in the archives. If not, is it possible to have mass patrolling done? This could be helpful when dealing with multiple edits, where a user has made minor changes such as adding a specific number or other minor details. Instead of going into each and every single one of the edits, is there any way that mass patrol can be implemented, allowing us to check and approve certain unpatrolled edits more efficiently?
@Боки: We don't have edit patrolling enabled on English Wikipedia. Only new pages are patrolled, not individual edits. 🌺 Cremastra (talk) 01:01, 7 January 2024 (UTC)Reply[reply]
@Cremastra If I may ask, why not ? How do you manage the information that gets posted on the Wikipedia pages then ? People can just post anything and everything. There has to be a way that this gets managed. БокиWrite to me! 15:02, 8 January 2024 (UTC)Reply[reply]
@Боки: That's a good question, but I don't really know the answer. Many users informally patrol RecentChanges to watch for vandalism, myself included. We check our watchlists, and keep an eye on worrisome editors. Things seem to generally tick along fine. 🌺 Cremastra (talk) 20:46, 8 January 2024 (UTC)Reply[reply]
@Cremastra What about the fact if someone makes a mistake or puts some incorrect information ? How do users here correct it ? They redo it or do they just revert the edit ? БокиWrite to me! 20:59, 8 January 2024 (UTC)Reply[reply]
Yeah, someone would generally fix the problem or just revert the edit. There has been discussion of enabling edit reviewing lately, but I believe the idea was shot down. I think, in practice, edits are generally reviewed at some time or another, there's just not a special person clicking a "review" button. The process is unofficial and informal. It seems to (mostly) work. 🌺 Cremastra (talk) 21:01, 8 January 2024 (UTC)Reply[reply]
@Cremastra The reason why I am asking is because at Serbian Wikipedia (with a lot less edits, mind you) we have bunch of reviewers (including myself) who review edits of non-auto-patrolled users which brings me to the next point, how does person here on English Wikipedia become auto-patrolled ? БокиWrite to me! 21:04, 8 January 2024 (UTC)Reply[reply]
The auto-patrolled right (where your articles are patrolled automatically) is granted by an admin through a formal request process. See WP:PERM/AP. Cheers, 🌺 Cremastra (talk) 22:12, 8 January 2024 (UTC)Reply[reply]
@Cremastra I will definitely work towards that considering I am an interface admin of Serbian Wiki. My only concern is with this amount of edits, does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while ? БокиWrite to me! 00:26, 9 January 2024 (UTC)Reply[reply]
does it not "ruin" the reputation of article if someone can easily add something to the article without anyone noticing it for a while Someone easily adding something to an article is how Wikipedia works. 🌺 Cremastra (talk) 00:31, 9 January 2024 (UTC)Reply[reply]
@Cremastra I know but in this occassion, I am referring to person adding, for example, "... and this woman has been involved with my dad" (literally) as part of the article. If this does not get patrolled or checked, then this goes on the article that someone will read and say what is going on. БокиWrite to me! 08:45, 9 January 2024 (UTC)Reply[reply]
@Боки, I think you might be unclear on the purpose of auto-patrolled. Most new articles are reviewed by a team of editors, the new pages patrol. When an editor has created a lot of acceptable articles, they can be assigned "auto-patrolled" so the reviewing editors have more time to concentrate on other articles. It makes no difference in editing abilities or rights for the editor who has auto-patrolled. Schazjmd(talk) 00:32, 9 January 2024 (UTC)Reply[reply]
@Schazjmd on Serbian Wikipedia, auto-patrolled means we, as patrollers, do not have to check your edits (whether it's new page or just a simple edit on something) any more and you have gained trust that you will not make meaningless edits and that you know what you are doing on Wikipedia. That's what my definition of auto-patrolled is and that's what I am referring to. БокиWrite to me! 08:47, 9 January 2024 (UTC)Reply[reply]
The scale of editors on enwp, as well as automated anti vandalism tool leaves good faith but non-constructive edits. And it generally works on enwp. Incorrect Source verification is probably hardest challenge we have ~ 🦝 Shushugah (he/him • talk) 09:02, 9 January 2024 (UTC)Reply[reply]
A Wikipedia journal
There's a lot of research about Wikipedia, but it tends to be from an 'outsider' perspective: computer scientists and computational social scientists that are interested in Wikipedia because it's a huge, open dataset; critiques of our content, or lack thereof, in specific fields; or, increasingly, experiments in replacing some or all of our work with algorithms. All very interesting and valuable, but what I'd really like to read is more studies of Wikipedia in its own terms. Things like the histories of specific policies, analyses of how processes work, biographies of prominent editors. Research like that does exist (e.g. the WMF's Wikipedia @ 20 edited volume springs to mind), but it's scattered around and hard to find.
If the Wikipedia community was a conventional collective organisation, a scholarly society or a trade union or something, it'd probably already have its own little periodical for that kind of thing. Something like The Signpost, but with bibliographic references, peer review, etc. Written and read primarily be people who are involved in, or at least have a deep knowledge of, the community. It could be hosted on-wiki like the Signpost or, perhaps better for discoverability, somewhere else, as long as it has that rooting in the community. Would anybody else be interested in something like that? – Joe (talk) 08:56, 5 January 2024 (UTC)Reply[reply]
Well as you know I don't really agree with what you wrote there. But certainly that could be one role of a journal like this: counter-critiques to academic critiques of Wikipedia are unfortunately not going to be taken as seriously when they're published on Wikipedia itself. – Joe (talk) 13:59, 8 January 2024 (UTC)Reply[reply]
A nice idea! A major issue is the unpaid aspect of it. On other hand, if an academic is being paid, they can push for open-access, open-data etc.. which is what a lot of meta:Wikiresearch is. I also think about wikinews:Main and the success/challenges it faces ~ 🦝 Shushugah (he/him • talk) 01:11, 7 January 2024 (UTC)Reply[reply]
@Shushugah: Thanks. I'm not sure I follow though, who is(n't) being paid? – Joe (talk) 13:53, 8 January 2024 (UTC)Reply[reply]
Not quite what you're describing, but there are the WikiJournals. The idea there is more about getting wiki contributions to "count for something" by sending them through peer review and formatting them as journal pieces. There was the Wiki Studies Journal which involved several Wikipedians, but it doesn't appear to still be going. Heather Ford kicked off Wikihistories fairly recently -- not sure where that's headed.
Back to your thought, though, it would certainly be interesting. I'd be curious how much enthusiasm there is. I've seen a lot of valuable research projects undertaken by volunteers that would benefit from being cleaned up and formally "published". It may also be useful to provide a forum to publish literature reviews or to critique existing research. — Rhododendritestalk \\ 14:26, 7 January 2024 (UTC)Reply[reply]
My thinking exactly. This is the kind of thing people do already, and especially for users that are also in academia, or plan to be, it would be nice to be able to collect formal citations and credit for it.
Level of interest is the key. If the Wiki Studies Journal was a similar and failed, then it'd be good to know what went wrong. Otherwise, I was thinking of trying to put together an initial issue of invited contributions. If we couldn't find enough contributors, then we have our answer. – Joe (talk) 13:57, 8 January 2024 (UTC)Reply[reply]
We have a number of articles titled 'Bibliography of X'/'X bibliography'. Sometimes these are lists of works by a subject, eg Virginia Woolf bibliography. Sometimes they are lists of works about a subject, eg Bibliography of Andrew Jackson. Sometimes they're both, eg Harold Pinter bibliography. Is "both" a desired approach? For example, if I wanted to split out some of the massive bibliography at Virginia Woolf, would I add it to the existing Virginia Woolf bibliography or would I create a new article? And if the latter, what would that be called to distinguish it from the existing article? Nikkimaria (talk) 21:06, 7 January 2024 (UTC)Reply[reply]
That massive bibliography at the Virginia Wolfe article isn't just a bibliography, it is part of the references. The article uses shortened footnotes, so each of those sources is the target of a hyperlink from the short footnotes in the references section. So they can't be moved to another article. Since the term "Bibliography" is ambiguous I would rather articles used the terms Citations / References for the two sections rather than References / Bibliography.
Yep, wouldn't be looking at removing any of the sources actually cited, just some of the ones that aren't. Thanks for the example, that's helpful - anyone have thoughts on what the best titling approach would be for these different types of bibliographies? Nikkimaria (talk) 00:04, 9 January 2024 (UTC)Reply[reply]
I think spoken versions of articles have some of the most potential for improvement of any area of the site. Of course, the existing paradigm has an obvious central issue: recordings become out of date almost immediately, which dissuades both potential narrators and listeners. I've thought a bit about this, and I have a preliminary idea for a format that could at least exist alongside the existing spoken articles: abridged spoken sections. Especially on good or featured articles, it seems like sections could be excerpted, possibly adapted to be better read aloud (adapted to a "podcast" form, if you like), and then those could be recorded. Because they are their own text—which would also exist as a readable transcript, of course—they wouldn't immediately go out of date, while reflecting both the work put into the accompanying article and the needs of listeners.Remsense留 04:47, 8 January 2024 (UTC)Reply[reply]
Why wouldn't these excerpts also be prone to going out of date?
I'd be interested to know how many people prefer listening to an out of date version of an article, versus having a screen reader read the up-to-date version.
I also wonder if effort could be focused on marking up difficult passages to assist screen readers in some way. Barnards.tar.gz (talk) 08:58, 8 January 2024 (UTC)Reply[reply]
Because they would have their own transcript that may be edited to have particular suitedness to being read aloud—they would only meaningfully become out of date if the substance of the part of the article that was abridged changes, not just minor changes in wording or sentence reshuffling.
I think screen readers are the other major reason articles aren't read anymore, but I think—albeit as someone who uses screen readers but does not require them to read—that they're just not as nice a lot of the time? Sure, people can set screen readers to a blistering pace they're still comfortable with, but they still produce errors and best-fit algorithmic awkwardness. There's plenty to explore in a "podcast" presentation to achieve what screen readers cannot. Perhaps the format can diverge even further—during a discussion I was having a few days ago, the possibility of writing for/recording a dialogue format came up, and I think that has potential. Remsense留 20:57, 8 January 2024 (UTC)Reply[reply]
I think the best way to solve the outdating issue would be to create a clickable tool or function that would use something like AI or computer speech that would be in-built in Wikipedia that can read the text in all articles exactly as they currently stand. Helper201 (talk) 21:50, 8 January 2024 (UTC)Reply[reply]
As already mentioned, many people already use screen readers that are highly customizable by each individual user: we are discussing a potential form of spoken article that would also be less redundant in the age of screen readers. Remsense留 21:53, 8 January 2024 (UTC)Reply[reply]
Screen readers have existed longer than Wikipedia has. They've probably become a bit more mainstream though, with VoiceOver and Google TalkBack being pre-installed on smartphones. As a screen reader user, I'm very text-oriented so I almost never use Spoken Wikipedia and would almost never use spoken excerpts either. I don't think many proficient screen reader users would. Graham87 (talk) 06:08, 9 January 2024 (UTC)Reply[reply]
Thank you very much for your insight. This may seem like an off-topic question, but what about podcasts? Are they perceived as too slow or inferior to (hypothetically) equivalent passages from books using a screen reader as well? If not, what advantages do they have? Are there any advantages for you personally to have something narrated by a person as opposed to a screen reader, or are the disadvantages simply too great? Remsense留 06:15, 9 January 2024 (UTC)Reply[reply]
WMF
RfC to issue a non-binding resolution to the Wikimedia Foundation
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Consensus for Wikipedia: Village pump to issue non-binding resolution for all three sections, especially #3: Increased support for internal needs. Onetwothreeip (talk) 04:00, 24 December 2023 (UTC)Reply[reply]
Should the English Wikipedia issue the following non-binding resolutions to the Wikimedia Foundation?
Each of the resolutions has its own section for !votes and discussion:
Grants to organizations intending to be active on the English Wikipedia
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
Grants to organizations unrelated to supporting Wikimedia Projects
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
Increased support for internal needs
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they need
to improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
Related discussions
There are three related discussions that editors involved in this may be interested in; they are listed here.
Community Response
Grants to organizations intending to be active on the English Wikipedia (Community Response)
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
Grants to organizations intending to be active on the English Wikipedia (Survey)
Support (Grants to organizations intending to be active on the English Wikipedia)
There have been many issues over the years where groups have been funded by the WMF to engage in activities on the English Wikipedia, only for the activity to be actively harmful to our project by providing no benefit and resulting in our volunteers having to spend time cleaning up the resulting mess. Often, this result can be reasonably predicted, as it could have been with the Deforestation in Nigeria project, if only the WMF had actively sought our input; hopefully this resolution will convince them to do so. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
As someone unfamiliar, what happened with the Deforestation in Nigeria project?—Ineffablebookkeeper (talk) ({{ping}} me!) 12:09, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support as amended. Some initiatives seem to be about experimenting with editing privileges as a classroom tool rather than improving Wikipedia, and that's not where these grants should go. Certes (talk) 14:32, 3 October 2023 (UTC)Reply[reply]
Support as amended. Notifying us ahead of time when a grant recipient's activities are expected to affect this project will allow people to help them course correct in the early stages if lack of competence appears to be an issue, rather than waiting for it to be discovered organically once it has already become a problem. The tighter feedback loop should result in better articles, less discouragement from the grant recipients, more competent new editors, and decreased frustration from en.wp editors. The increased transparency may reduce ill will between this project and the Foundation. Folly Mox (talk) 14:58, 3 October 2023 (UTC)Reply[reply]
Support with the amendment made. The community should be emphasizing *what* the community wants to happen. Exactly how to make that happen is a separate issue and I think statements like this should be distilled to the key element(s). CoffeeCrumbs (talk) 15:08, 3 October 2023 (UTC)Reply[reply]
Support. The language requires the WMF to inform the community, it doesn't say the community has to approve the grant. "Non-trivial" should be defined later as some dollar threshold, so there will be large grants and small grants, and the WMF should be required to inform enwiki whenever it is considering a large grant that will affect enwiki. I for one would like to know about large grants being considered without having to read through every grant application on meta. I've been surprised at how many grants are in the tens of thousands, hundreds of thousands, or millions of dollars. This would be very easy for the WMF to comply with, and I don't see any downside. Levivich (talk) 16:59, 3 October 2023 (UTC)Reply[reply]
Support. The fairly recent case of Nigerian deforestation articles springs to mind and asks serious questions about the ability of the WMF to allocate grants. More attention is needed here. Willbb234 20:34, 3 October 2023 (UTC)Reply[reply]
Support as amended. Would be good to define "non-trivial" for clarity. Espresso Addict (talk) 21:03, 3 October 2023 (UTC)Reply[reply]
Support, but I don't think that the notification necessarily has to be a discussion (alternatively it could simply be a post), and I'd be fine with any discussion ocurring on metawiki. It'd create less work for the folks that review grants and less places to monitor. As for the merits of notification, enwiki might often know more about the state of the wiki than grant approvers when a grant largely concerns enwiki (in my opinion should be determined at reviewer discretion), so I think that it makes sense to notify enwiki as a courtesy. —Danre98(talk^contribs) 02:59, 4 October 2023 (UTC)Reply[reply]
Support. This isn't even asking for veto power, just "Hey, if a grant you're giving is likely to have a substantial impact on the English Wikipedia, please give us a heads up beforehand." I do not think that is an unreasonable request. SeraphimbladeTalk to me 03:06, 4 October 2023 (UTC)Reply[reply]
This seems like a good step toward transparency and harm reduction. —siroχo 03:45, 4 October 2023 (UTC)Reply[reply]
Reviewing grant applications and judging a project's likely impact on content are two tasks that require different skill sets. Perhaps it would help if grant applicants without an established track record as Wikipedians submit some samples of work to the editor community before being awarded tens of thousands of dollars. AndreasJN466 11:43, 5 October 2023 (UTC)Reply[reply]
Support, now that the problematic lines in the statement have been removed. – SD0001 (talk) 16:30, 5 October 2023 (UTC)Reply[reply]
Support: there are far too many situations where unpaid volunteers are cleaning up the mess left by paid agents. It is one thing for this to be for-profit COI editing but entirely another for it to be grant money coming from reader donations. We are the best placed to judge whether an idea fits en.wiki. Creating new articles will rarely be an appropriate task for newcomers. Some absolutely shocking grant approvals show the process has no oversight by anyone with a clue. — Bilorv (talk) 20:59, 6 October 2023 (UTC)Reply[reply]
Support I think it is actually totally reasonable to say "please let us know if you are going to give money to an organization that is going to edit on Wikipedia so that we can have oversight and guidance". Introducing grant money has the power to overwhelm the abilities of even a project as large English Wikipedia to clean up errors and problems. We should at least be able to know when a project is going to start. Steven Walling • talk 02:16, 7 October 2023 (UTC)Reply[reply]
Support. I don't even mainly edit in enwp but I am looking forward of this kind of initiatives from the community and whether we can apply it outside of enwp. RXerself (talk) 16:15, 11 October 2023 (UTC)Reply[reply]
Support as a way to increase transparency and community involvement. DFlhb (talk) 12:25, 12 October 2023 (UTC)Reply[reply]
Support many of these grants are poorly designed and allocated, resulting in waste of money and damage to the project --Ita140188 (talk) 18:58, 13 October 2023 (UTC)Reply[reply]
Support No-brainer. A mild version to just inform. North8000 (talk) 19:26, 13 October 2023 (UTC)Reply[reply]
Support. The WMF is not a generic "make things better-er" charity. Mebigrouxboy (talk) 23:45, 22 October 2023 (UTC)Reply[reply]
Support I'm amazed this isn't being done already; giving money to something that creates un-helpful articles here that we have to deal with seems counter-intuitive. Oaktree b (talk) 15:42, 23 October 2023 (UTC)Reply[reply]
Support. If money is given in the promise of activity in English Wikipedia a notification should be a common sense approach. The community would gladly assist the organizations receiving the grant, but the community also should have the right to scrutinize "paid" activities going on in their wiki. ✠ SunDawn ✠(contact) 03:05, 25 October 2023 (UTC)Reply[reply]
Support Grants should go to organizations aiming to actually help the project, or at least not add more work for volunteers to repair it behind them. In any case, transparency over the goals and intended actions of such organizations receiving grants is more than welcome. ChaotıċEnby(t · c) 02:41, 27 November 2023 (UTC)Reply[reply]
Oppose (Grants to organizations intending to be active on the English Wikipedia)
Too vague to be useful and doesn't respect the autonomy of other projects. What does "non-trivial" mean? What does "active on the English Wikipedia" mean? While I can imagine what they might reasonably mean, if we're going to support a resolution that we hope will be implemented, we need to provide actual metrics against which we can evaluate compliance. Presumably the resolution intends that non-rapid fund grants made for activities that will result in edits directly on EnWiki seek feedback from the EnWiki community. It could also mean something else (allocations over a particular dollar amount, for example, or organizations doing specific kinds of activities). The risk is we pass this because we all imagine some shared understanding when no shared meaning exists, and then when the WMF does what it thinks we mean the false consensus is laid bare as more backlash ensues. Further, the proposal could amount to an EnWiki veto over what occurs on other projects should a grant cover multiple projects (like Commons or Wiktionary). We could say that the WMF should do the same for those projects too, but if every project impacted by a grant gets its own on-project discussion and potential veto, we now have potentially hundreds of consultations to be managed being tracked across multiple projects and threads. That's why these kinds of discussions on grants already take place on Meta, the wiki for cross-project coordination. Of course, communication as to what's happening on meta could be improved such as when I and others added a dedicated "Meta" section to CENT to raise awareness of important discussion on that wiki, but the "here to build an encyclopedia" argument cuts both ways: EnWiki is for building an encyclopedia, not grant administration. I agree with (what I imagine to be) the sentiment, but as a resolution I think it is too loose. — Wug·a·po·des 02:23, 3 October 2023 (UTC)Reply[reply]
I appreciate the amendment as it addressed a main concern. I'll take some time to consider how I feel about the remaining vagueness but for the moment consider me somewhere between neutral and weak opposition. — Wug·a·po·des 23:49, 3 October 2023 (UTC)Reply[reply]
Editor attention is already spread thin among so many (too many) Foundation initatives. Spreading thinner the attention of foundation minded editors further concerns me. The foundation needs to be competent in making grants and to the exten that it's not, that high level problem at the macro level is what needs solving, not micro level feedback. Best, Barkeep49 (talk) 03:42, 3 October 2023 (UTC)Reply[reply]
Regarding Editor attention is already spread thin among so many (too many) Foundation initatives. Spreading thinner the attention of foundation minded editors further concerns me.: My hope, by having them inform us rather than expecting us to watch metawiki and inform ourselves, is that we will make it easier for editors to engage with these sorts of issues and thus increase the number of editors willing to do so. BilledMammal (talk) 07:38, 3 October 2023 (UTC)Reply[reply]
I understand. My preference would be that volunteers help the Foundation setup productive systems that do not require constant wide spread volunteer oversight. Grantmaking is a time consuming activity and I'd be happy to let paid people spend the lions share of the time on it. Best, Barkeep49 (talk) 12:52, 3 October 2023 (UTC)Reply[reply]
Oh dear. Please take a good look at all the formal groups that exist in the movement today - roughly 180 of them, at least half of which will directly or indirectly contribute to English Wikipedia. (Don't forget, almost all of these groups do or can participate formally in discussing global policies and processes that will affect our project; and those supporting international events, as well as MediaWiki, Commons and Wikidata, certainly have a trickle-down effect.) And that doesn't count informal groups, "recognized" groups that aren't affiliates, and individual volunteers. Oh, and hubs - which are deliberately intended to involve multiple groups focused on particular topics. If people want to get stuck into reviewing grant applications, they should go over to Meta, volunteer their time and energy, and do it. They're always looking for volunteers. Oh, and incidentally, deforestation in Nigeria is a real thing.[49]Risker (talk) 04:09, 3 October 2023 (UTC) (Adding parenthetically that there are multiple Wikipedias edited by Nigerian Wikipedians; just because there's an article in English - one that has lots of tags on it - doesn't mean there is a parallel article in other local languages. This isn't just an English Wikipedia issue. Risker (talk) 04:44, 3 October 2023 (UTC) )Reply[reply]
@Risker: Regarding your parenthetical comment about Nigerian Wikipedians working in many languages, note that the Task List for the $20,000 Deforestation in Nigeria project only mentions English Wikipedia articles. The first draft of the grant application did mention Igbo articles in addition to English, but the references to Igbo article work were first reduced in scale and then deleted altogether: [50], [51]. AndreasJN466 11:28, 5 October 2023 (UTC)Reply[reply]
Also, I think reviewing grant applications and judging a project's likely impact (positive or negative) on Wikipedia content quality require different skill sets. (Of course, the latter is always difficult without a work sample supplied beforehand, or an established track record of article work.) AndreasJN466 11:36, 5 October 2023 (UTC)Reply[reply]
Per Wugapodes and Risker, with more comments to follow. KevinL (aka L235·t·c) 04:15, 3 October 2023 (UTC)Reply[reply]
We can and should tell the Foundation that they need to rethink the broad direction they're taking on grants. But in no way should EnWiki, or for that matter any community, become the grant overlords. We are hardly qualified to give individual level feedback on grants. There is a reason we have the board and a foundation. Wikipedia's community governance works great at creating an encyclopedia, but it does not do great at managing money. We can effect grant reform without having to become grant reviewers. CaptainEekEdits Ho Cap'n!⚓ 05:07, 3 October 2023 (UTC)Reply[reply]
Per Wugapodes, Risker and CaptainEek. Thryduulf (talk) 08:07, 3 October 2023 (UTC)Reply[reply]
The amended version is considerably less bad than the previous version, but I'm still not convinced this is a direction we should be going in. Thryduulf (talk) 16:52, 3 October 2023 (UTC)Reply[reply]
This sounds vague and appears to ask for an enwiki veto of what happens on other projects. I'm not convinced there isn't a problem here, as the deforestation issue highlights, and the WMF should have some introspection of that happened. But I don't believe the current suggest is the right way to go. -- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 21:18, 3 October 2023 (UTC)Reply[reply]
I won't repeat the points made so well by others but I want to note that if we deleted the second paragraph and the last sentence of the first paragraph, then I'd certainly "support", and I think others might too. This having been done, I'll move to support.—S MarshallT/C 08:34, 3 October 2023 (UTC)Reply[reply]
Oppose per Risker. You want to review grants, nobody is stopping you. Also the non-neutral wording declares matters of opinion as matters of fact, enough to oppose on this basis alone. Gamaliel (talk) 23:08, 3 October 2023 (UTC)Reply[reply]
Per the very good comments above, with special mention to Barkeep49 and CaptainEek regarding the competencies (and lack of) of our community-governance system here. There have been many expressed concerns with the grant system, but I am unsure how this proposal would move assist much with them. CMD (talk) 03:21, 4 October 2023 (UTC)Reply[reply]
Oppose. Review of grants should be done through meta. However, it may be good to compile a rolling list of grants that may generate content for enwiki for editors here for ease of tracking related updates. Through this list, we can potentially see if there is an overall benefit or negative outcomes from the grants and then see how such grants can be processed or advised in the future. How it is to be done can be explored further if there's support for this consideration instead. – robertsky (talk) 08:34, 4 October 2023 (UTC)Reply[reply]
Per most of the above. Badly worded and likely impossible to implement. Not a solution to the issues given as examples. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:39, 4 October 2023 (UTC)Reply[reply]
The revised proposal moved me from a clear oppose to being on the fence. This is one where other opinions have influenced my perspective, so I weakly oppose mainly per Risker, but also Barkeep, Eek, and Wugapodes. — Rhododendritestalk \\ 18:59, 4 October 2023 (UTC)Reply[reply]
Grants can already be reviewed. Meta is the place for it, not here. Hawkeye7(discuss) 20:27, 4 October 2023 (UTC)Reply[reply]
Mine is a weak support, given the "non-binding resolution" nature of the proposal and the fact that I don't think it hurts to remind the WMF that grants which could impact the on-project conduct of parties, be they regular editors or not, are worth special consideration and have a special level of interest to this community. That said, I'm pushed to a formal oppose based on 1) the fact that the specific proposal here still strays a little into miscasting the community's position to oversight the foundation's financial and administrative decisions in such areas and, 2) the fact that despite this relationships, the Foundation already has more than abundant transparency on such matters through Meta. A better outcome here would be a push to make more editors conversant in broader Wikimedia movement processes and procedures. SnowRise let's rap 21:32, 4 October 2023 (UTC)Reply[reply]
Weakly mostly on two items: 1) Wugapodes' objection over imprecision, and 2) that I think any discussion should continue where it has been, which is Meta, rather than here (i.e. that it should be a notification only here). I think this is otherwise supportable and to be fair is something that could/should be done for every wiki which might be affected by grants work. Izno (talk) 22:45, 4 October 2023 (UTC)Reply[reply]
While it may not literally be written to enable that, the "opening of a discussion" over a new grant would become an avenue to propose revoking that grant, and I don't think it's our place to do that, both in principle and from an official standpoint. RunningTiger123 (talk) 02:54, 8 October 2023 (UTC)Reply[reply]
There is already a process for this. Curbon7 (talk) 02:26, 25 November 2023 (UTC)Reply[reply]
Grants to organizations intending to be active on the English Wikipedia (Discussion)
Comment. Not opposed to this, but it feels like a bit of a sledgehammer–nut response targeted at the single (awful) grant. Would prefer a longer list of grants falling under the education programme, and elsewhere, that have resulted in clear harm to the encyclopedia. Espresso Addict (talk) 01:56, 3 October 2023 (UTC)Reply[reply]
I don't have a list on hand, but the most common time for it to occur is when the WMF gives a group funds that they use as monetary prizes for editing; for example, Wikipedia Pages Wanting Photos in past years, although it is no longer an issue as it no longer offers monetary prizes. BilledMammal (talk) 02:19, 3 October 2023 (UTC)Reply[reply]
While I would love it if the WMF did apply this to other projects I didn't feel it would be appropriate for us to ask the WMF to do so without the consent of those Wiki's. BilledMammal (talk) 02:16, 3 October 2023 (UTC)Reply[reply]
Question what does it mean by non-trivial sum? Fresh from organising Wikimania 2023, of which I had a direct hand in operationalising Wiki Loves Living Heritage Singapore 2023, would the sponsored prizes there (offhandedly, not more than 10,000 USD) be counted if it was funded by the Foundation? Of it, it generated 1,180 new images, many are of certain quality that can be used on the articles here. How low do we consider as trivia? This also raises the question of grants that are given that on surface seemingly does not affect enwiki directly, but in reality is. Do we want to or should we be policing those as well? – robertsky (talk) 03:21, 3 October 2023 (UTC)Reply[reply]
@Robertsky Side note. As far as I can tell, WMF does not even support any community requests for funding under 500 USD (rapid grant minimum). If I am wrong, I'd appreciate a link. IMHO 500 USD plus is non-trivial, considering global scale of our project (it is more tham mimimum monthly income in some poor places). Piotr Konieczny aka Prokonsul Piotrus| reply here 05:52, 3 October 2023 (UTC)Reply[reply]
Defining "non-trivial" seems in the cards. I do not know how many grants would usefully be reviewed though if that number is any higher than the floor, since I suspect it is the smaller grants that have an outsized influence on the volunteers here. Pizza for a badly-planned editathon seems more likely to disrupt than most other kinds of grants. Izno (talk) 19:56, 3 October 2023 (UTC)Reply[reply]
Comment. I'd support something closer to For any WMF-funded activity that is determined to have had a net negative effect on the English Wikipedia, the WMF will pay an equivalent amount for contract labour to slay backlogs of the community's choosing. I know, I know: who defines and decides "net negative"? It's just a dream. Folly Mox (talk) 03:31, 3 October 2023 (UTC)Reply[reply]
Comment I think there's a resolution to be made here, but needs to be more specific in light of the oppose comments. I would leave out the part which says "and does not proceed with the grant if the English Wikipedia is not convinced of its utility." The foundation should certainly evaluate our comments, but the final decisions should be up to it. Also, this needs to be more narrowly focused on projects which seek to directly affect the content on English Wikipedia. – SD0001 (talk) 08:15, 3 October 2023 (UTC)Reply[reply]
Because the original wording didn't appear to have the broad community backing we need for the WMF to take these resolutions onboard; I'm hoping this wording will be more palatable. BilledMammal (talk) 10:38, 3 October 2023 (UTC)Reply[reply]
You haven't changed anything that would change my opinion. If people want to get involved in grants, they need to get directly involved. It is incredibly disrespectful to the volunteers who work so hard to analyse grant requests to suggest that *one* community gets veto rights on their carefully considered and nuanced decisions, many of which affect multiple projects. I would suggest that authors of these proposals (I know it wasn't just you, BilledMammal, you're just taking the brunt of the responses) actually spend the time to talk to people involved in grant review and analysis, and perhaps actually try to assist in grant review and analysis, before saying that (a dozen or so people from) a project should be able to essentially veto a grant. Please walk a mile in those shoes. This is WP:IDONTLIKEIT on a global scale. Risker (talk) 19:12, 3 October 2023 (UTC)Reply[reply]
I don't see a veto here now post-change, I see a required notification so that users who might be interested in specific proposals can indeed actually try to assist in grant review and analysis. If the grants at that point are vetoed by review of interested users from here, that would seem to say more about the utility of the grant than not. The clearly detrimental Deforestation project (and others before it!) should not have been approved and review by en.wp users would likely have identified issues with that grant immediately.
I have a remaining concern that this could be used to detrimental effect for grants which do not per se target en.wp. For example, the "Deforestation" project was clearly (or perhaps not clearly) intended to be done as work targeting en.wp, and it is this kind of grant I think a notification would be good for. It feels like a miss to notify about a general grant to improve software affecting multiple wikis or multi-wiki coverage of material but not intending to focus on en.wp or even substantially contribute here. Can this framing be tightened? Izno (talk) 19:54, 3 October 2023 (UTC)Reply[reply]
Sorry Izno, I missed this. That was a fair request, but I think it is a little too late now - however, my personal perspective is that a software project wouldn't result in activity on enwiki, even if it would affect enwiki, and thus notification wouldn't be required. BilledMammal (talk) 01:12, 16 October 2023 (UTC)Reply[reply]
Where does this proposal "suggest that *one* community gets veto rights"? Please, let's not spread misinformation. Levivich (talk) 19:54, 3 October 2023 (UTC)Reply[reply]
Comment. Hi everyone, Yael here, VP of Community Growth at WMF, which is a sub-team within Advancement that includes the Community Resources team, responsible for grants distribution. I’m seeing two (and-a-half) interconnected issues in this RfC, and I’m happy to speak to each of them: 1) Funding activity on EnWP that is not intended to contribute to our goals of building an encyclopedia; 1a) A specific comment about a grant on deforestation in Nigeria, which is used as an example of either non-encyclopedic content or an active hindering of that goal. And 2) How WMF communicates with EnWP about grants that will result in activity on EnWP. Regarding #1: The grants we make through our Community Resources team are intended to support the Wikimedia community to contribute to our collective goal of increasing encyclopedic content. I am in complete alignment with the spirit of this RfC - that grants should contribute to this goal, and that they should be of a high enough quality that they don’t make work of en-Wiki editors more difficult. Sometimes people disagree with what is encyclopedic content, but we trust that the Wiki projects make those decisions themselves; thankfully, it’s rare that content directly supported by grants is added to any of the Wikis that is counter to this objective. Sometimes, we make funding mistakes or the grants don’t go as we had hoped. That’s what happened with the specific grant referenced re: deforestation in Nigeria. As others have mentioned, this is a topic that many believe should be on Wikipedia. Unfortunately, the quality of the article didn’t live up to en-Wiki standards and as a result caused EnWP admins more work. I genuinely apologize for that. There’s a lot we’ve learned from this grant portfolio (you can see the full proposals, both those funded and not, on Meta here). I won’t go into detail here, as I’m trying to respond to the main point of the RfC. In short, this grant came from a pool of funding that did not go through our Regional Funds Committee community review process, and we’ve since sunsetted that pool of funding. We are now sending all applicants from The Organizer Lab to the Rapid Grants program, which has both a lower cap in funding and is reviewed by the Regional Funds Committees. Regarding #2: Current practice is that all proposals are publicly available on Meta for community input. We rarely see much engagement there, but community members are welcome to engage and their comments will be considered and reviewed by the Regional Fund Committees, which are made up of community volunteers. We also ask all grantees to describe to what extent they’ve engaged with their relevant Wiki communities in drafting the proposal; I acknowledge that some do this more than others and we’re reliant on their self-attestation to this. Given that Meta can be hard to navigate, and that many EnWP members are more active on the Village Pump, the request to share information there is a fair one. Community Resources can commit to sending out an announcement on all Village Pumps (not just EnWP), when the funding round is open and proposals are open for Community input. This announcement will link to Meta, where the proposals are posted for comment. Ultimately, Regional Fund Committees make the final recommendations on funding, but they take community input, which can be done directly on the Meta pages associated with the proposals. Finally, I’m open to learning what other communication channels would be helpful (e.g., a Wikimedia-l announcement?) when each funding round is open. On a personal note, I welcome requests and feedback particularly on relatively solvable asks like this. I respect that RfCs are important to EnWP for community alignment, but you are welcome to also just send concerns like this directly to the Community Resources team or to me. We genuinely love solving solvable problems. RWeissburg (WMF) (talk) 17:40, 13 October 2023 (UTC)Reply[reply]
RWeissburg (WMF), that doesn't solve the core problem. Have a look at WP:THEYCANTHEARYOU. That should have been treated as an emergency blocker-level bug. Yet, years after reporting, it still is not addressed. We need editors to be notified consistently if we leave a message on their talk page, and for that to be dead obvious in the interface. If the "mobile app" does not or cannot support that, get rid of it, and ask people to use a browser to access the website, which they should be doing anyway (no website should have an "app" to access it; the "app" to access a website is a browser). But if you must have an "app", make sure it functions completely correctly, including letting the user know, in no uncertain terms, when someone has left them a talk page message. SeraphimbladeTalk to me 04:48, 22 October 2023 (UTC)Reply[reply]
Hi @Seraphimblade - I think maybe your comment is intended for the third topic: "Increased Support for Internal Needs"? @JTanner (WMF) has responded on that topic below. 75.104.108.53 (talk) 16:04, 23 November 2023 (UTC)Reply[reply]
My apologies - that comment above is from me; I had accidentally been logged out. - Yael RWeissburg (WMF) (talk) 16:05, 23 November 2023 (UTC)Reply[reply]
I don't understand what this proposal actually entails. m:Grants shows there are many different processes. Occasionally there can be dozens of grant requests for projects which may produce edits on the English Wikipedia. Does this proposal ask for more granular links pointing out each individual proposal in its own section on the village pump, or what? Nemo 14:01, 28 October 2023 (UTC)Reply[reply]
Grants to organizations unrelated to supporting Wikimedia Projects (Community Response)
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
Grants to organizations unrelated to supporting Wikimedia Projects (Survey)
Support (Grants to organizations unrelated to supporting Wikimedia Projects)
In most cases it will not be appropriate for the WMF to provide funds to organizations unrelated to supporting Wikimedia Projects; our donors gave money to support the projects and we should respect that. Rare exceptions may occur, but in such circumstances broad oversight from the community should be sought, to ensure that the grant is appropriate and that it will not damage our image by causing the public to believe that we are becoming a partisan entity. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
As I've said in the past, soliciting donations for one cause and then handing them off to a different cause is in effect the same thing as a scam. 100% of funding collected by the WMF should go into supporting the various editions of Wikipedia and its sister projects or to keeping the WMF operating as an organization that facilitates these projects. Thebiguglyalien (talk) 03:07, 3 October 2023 (UTC)Reply[reply]
Frankly, I'd find it astonishing that this needed to be said, if it wasn't for the evidence that it clearly does. AndyTheGrump (talk) 03:11, 3 October 2023 (UTC)Reply[reply]
WMF solicited donations using disingenuous messaging like "Wikipedia is not for sale" and is transferring not-insignificant amounts of such funds to goals that have nothing to do with Wikipedia or with any of its sister projects. That is morally dubious at best and fraud at worst. It needs to stop. Ciridae (talk) 05:57, 3 October 2023 (UTC)Reply[reply]
The money needs to be used for the purposes the donors expected it to be used for. If donors were told they were paying to keep the lights on and the servers running, and they were, then it's unethical and duplicitous to spend it on advocacy think-tanks. Also, Wikipedia has a reputation for neutrality that was very hard-won and will be very easily-lost. Don't squander it please. Spending donors' money on advocacy groups is reckless and risks our core mission. I can envisage headlines about "Wikipedia applies political pressure" on a slow news day and I think that would be a catastrophic outcome.—S MarshallT/C 08:42, 3 October 2023 (UTC)Reply[reply]
Money raised for Wikipedia should stay for Wikipedia. As I said elsewhere, $200K USD for a non-profit organization based in Indonesia that works on human rights and advocacy issues for indigenous people is a nice plan, but not related to the project in any way. Edward-Woodrow • talk 12:21, 3 October 2023 (UTC)Reply[reply]
If I may, While I understand the concerns regarding the allocation of funds by the Wikimedia Foundation, it's important to remember the wisdom in the quote, 'It's not right to take the children's food and throw it to the dogs.' In this context, the children represent Wikimedia Projects, and the dogs represent unrelated external organizations. It's crucial that funds donated for supporting Wikimedia Projects are prioritized for their intended purpose. Therefore, I wholeheartedly support the request for the Wikimedia Foundation to reappropriate any remaining money in the Knowledge Equity Fund and seek community approval before making grants that may appear unrelated to supporting Wikimedia Projects. This approach aligns with the principle of responsible fund allocation. Icem4k (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support, in the interests of honesty and transparency. Certes (talk) 14:26, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
Support, per S Marshall's points. The bait-and-switch of WMF fundraising has gone on far enough. Even if used for other good things, it's important to be honest about what money donated will be used for. People who provide financial support deserve that honesty, yet we have this yearly débâcle in which we have banners that suggest that donated money will be used for something that's only a small portion of the budget. CoffeeCrumbs (talk) 15:06, 3 October 2023 (UTC)Reply[reply]
For many years, the WMF has been spending way too much money on non-editing improvements (like trying to solve the root causes of systemic bias or knowledge inequity) and too little money on editing improvements (like upgrading Visual Editor, or the graphs extension). This needs to stop. They need to spend the donations primarily on hardware and software development and maintenance; only when those needs are met should they even consider spending the donations on anything else, and those needs are not met and never have been. Levivich (talk) 17:03, 3 October 2023 (UTC)Reply[reply]
Strong support. I believe donors are misguided on where their money will end up. Giving money to other organisations is a big no and I can't believe this has been going on for so long. Willbb234 20:41, 3 October 2023 (UTC)Reply[reply]
Donors expect the WMF to spend money on WMF projects and goals, not to be a general-purpose grant making group --In actu (Guerillero)Parlez Moi 11:11, 4 October 2023 (UTC)Reply[reply]
Support. Our donation money should be spent at home, not on third party causes that have minimal or no inter-relation with Wikimedia. Reminding the WMF of this is appropriate. I am a bit surprised at the quantity of opposes. Perhaps this RFC should have been simplified to "The English Wikipedia opposes spending donor money on causes not closely related to Wikimedia, and is deeply concerned about the Knowledge Equity Fund." –Novem Linguae (talk) 07:54, 5 October 2023 (UTC)Reply[reply]
Support. I think the idea of rephrasing this per User:Novem Linguae's suggestion (or by simply cutting the second sentence) has merit. We do not really want to micromanage these grants, nor are we properly equipped for it. We want the WMF to get the message – a message that a good number of opposers appear to agree with. --AndreasJN466 18:17, 5 October 2023 (UTC)Reply[reply]
Support Novem Linguae's suggestion, with tentative support for the other wording. It's rather dishonest to advertise for donations on Wikipedia and then have that money go to something that's at best very remotely related to Wikipedia. 173.244.10.85 (talk) 15:03, 6 October 2023 (UTC)Reply[reply]
Support: readers who donate are largely unaware of what their donations are used for and external organisations is a big part of it. WMF mission creep exceeded ludicrous levels several years ago. Of course good things come from working with other organisations like Internet Archive, but the statement is that the WMF need to consult the community over such collaborations. — Bilorv (talk) 21:05, 6 October 2023 (UTC)Reply[reply]
I would prefer if "and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community." was removed but support the general principal. Jenks24 (talk) 17:24, 7 October 2023 (UTC)Reply[reply]
Support - funds raised by Wikimedia are understood (and advertised as such) to be used (and necessary) to run Wikipedia and associated projects, not third party organizations. --Ita140188 (talk) 13:56, 9 October 2023 (UTC)Reply[reply]
Support. While doing projects on knowledge equity itself is not inherently opposed to what we are doing in Wikipedia, the fund that was gathered by benefiting from the work of the community must be used to help the people inequity inside the community first. I would rather see a legal fund for editors in oppressive countries, or expand the coverage of The Wikipedia Library. RXerself (talk) 20:52, 11 October 2023 (UTC)Reply[reply]
Support. WMF funds should be for WMF projects, of which many are needed. Crossroads-talk- 21:55, 11 October 2023 (UTC)Reply[reply]
Support. The WMF has gone from the stewards of Wikipedia to a 'movement' in it's own right, and it is impeding Wikipedia's ability to be a reliable, high-quality encyclopedia. INeedOGVector (talk) 22:12, 12 October 2023 (UTC)Reply[reply]
Support A much needed reform. And ending deception of donors who largely are asked to donate to support Wikipedia and then transferring money to people and organizations unrelated to that. North8000 (talk) 19:30, 13 October 2023 (UTC)Reply[reply]
Support. The second part of the sentence could be just removed, since it is too prescriptive on implementation details. For example, simply removing the KEF would also be a good course of action. Anyway, I agree with the overall idea. MarioGom (talk) 07:51, 15 October 2023 (UTC)Reply[reply]
Strong Support - Money given to WMF is given out of an understanding that it is to uphold WP - Any deviation from this merits a discussion prior. Captain Jack Sparrow (talk) 20:57, 15 October 2023 (UTC)Reply[reply]
I think the specific wording could use a bit more workshopping, potentially after the RfC, but agree with the overall sentiment. (I prefer Novem Linguae's version.) Tol (talk | contribs) @ 15:38, 19 October 2023 (UTC)Reply[reply]
Strong Support Money given to WMF should be used for WMF. My time to edit Wikipedia (that strongly benefited WMF) should be used for WMF/Wikipedia, not for projects that are too far unrelated from the goals of Wikipedia. There are many good causes in this world - people should donate directly to those causes instead. WMF should be totally unbiased, and allowing money to flow out for "causes" can cause biases. ✠ SunDawn ✠(contact) 03:07, 25 October 2023 (UTC)Reply[reply]
Support - The mission creep has been harmful and means ever more requests for funding not actually required for the sites people think they are donating to tompagenet (talk) 13:17, 29 October 2023 (UTC)Reply[reply]
Support Fund the community's work, not things that aren't our mission. It's also not being straight with the donors.--Wehwalt (talk) 01:33, 1 November 2023 (UTC)Reply[reply]
Support The grants made should be related to Wikimedia projects. Strobilomyces (talk) 21:16, 5 November 2023 (UTC)Reply[reply]
Support. Knowledge equity can mean a lot of things, and the inequity continues in many non-English Wikipedias and most sister projects. These funds should be directed to WMF projects first as that was the donor's expectation. Yet when I see Knowledge Equity fund recipients don't contribute towards WMF projects at all despite having strong synergies (e.g. "Arab Reporters for Investigative Journalism" wrote 0 Wikinews article despite being an investigative journalism organization in their name and "Borealis Racial Equity in Journalism Fund" admitted in their report to WMF that they improved/wrote 0 articles and added 0 images.) Even a Wiki Edu classroom project has a bigger and meaningful impact towards an WMF project and at a far cheaper cost. As the Knowledge Equity fund currently stands, it needs to be reined in when projects are funded with so few strings attached. OhanaUnitedTalk page 06:10, 23 November 2023 (UTC)Reply[reply]
Support Grants made with the expectation of reaching Wikimedia projects should go to Wikimedia projects. ChaotıċEnby(t · c) 02:39, 27 November 2023 (UTC)Reply[reply]
Oppose (Grants to organizations unrelated to supporting Wikimedia Projects)
Knowledge equity and related issues, while not directly related to the projects, are crucial issues that are within the WMF's scope. Frostly (talk) 02:01, 3 October 2023 (UTC)Reply[reply]
This seems like an over-reaction to a poorly-communicated initiative; the WMF has conceded that it should have provided more information and explanation as to how funding these groups had the potential to expand available free knowledge that can be used in Wikimedia projects. Noting also that this is English Wikipedia, and should only include proposals that are specific to English Wikipedia. Those grants are at the global/meta level. Risker (talk) 04:19, 3 October 2023 (UTC)Reply[reply]
The first sentence is fine. The second sentence is way outside outside the English Wikipedia's area of competence. Thryduulf (talk) 08:09, 3 October 2023 (UTC)Reply[reply]
I'm especially opposed to demanding the money already allocated for the fund be returned, it seems unnecessary to me and risks stuff being killed off prematurely every time there's a change in leadership in ways we may not like. There seems to be agreement that the KEF is not going to be repeated, so while there are still going to be changes a gradual winding down based on existing decisions is far better than a sudden change. Do we really want when we finally get something we want funded only a year or two later it will be killed immediately just because new leadership no longer agrees? To be clear, I understand the money hasn't been allocated to any particular purpose yet, but it's still been allocated for the fund. I'm also deeply concerned that there is already a serious imbalance between the English Wikipedia and pretty much every other project (some a lot more than others) and while I don't think many or maybe even any other projects agree with the KEF, effectively we're demanding that the English wikipedia alone is able to dictate where money is not spent which is a major WTF. I'd also note that while the general idea may be laudable, it's actually a lot more complicated than that. I've looked at some of the projects and while they may not directly ensure project improvements, they may in the long term do so. It's well known that there is extensive systemic bias in the English Wikipedia and all projects are affected by this in varying ways. Improving access to education etc in places where it is limited increases the chances we will one day have editors from these areas able to contribute. It's clearly a very long term goal and the actual effect from some minor project is likely to be miniscule, so I don't actually think it's an effective way for the WMF to spend their money and would not encourage it but it also illustrates why a vague statement cannot really limit the WMF. I also consider the issue of insufficient funding for important projects separate issue. The WMF is not short on funds and it's clear that the reason why some important areas aren't getting sufficient attention isn't because they're spending all their money on stuff like KEF. This doesn't mean they should be spending the money on such things but it does mean it is unlikely doing this will achieve anything other than prematurely killing the KEF. Nil Einne (talk) 11:05, 3 October 2023 (UTC)Reply[reply]
meta:Knowledge Equity Fund clearly explains its relevance to the WMF's core mission: the fund is used to (emphasis added) support knowledge equity by addressing the racial inequities preventing access and participation in free knowledge. The English Wikipedia has struggled to address systemic bias from the beginning. It's a major problem and I'm glad the WMF is using some of its considerable financial resources to try tackling the root causes. You can't fix everything with editathons. – Joe (talk) 14:16, 3 October 2023 (UTC)Reply[reply]
It is very interesting and unfortunate that the wording of this part of the rfc equates "knowledge equity" with "non-trivial" activities. The self righteousness is not lost on me. I can only reiterate the sentiments on this oppose section. The zero-sum mindset herein is simply unhelpful. I am yet to hear real facts leveled against "the knowledge equity fund" that are worth talking about, other than "we need money to do stuff and we dont like this projetc, therefore stop it and give us the money". --Thuvack | talk 17:52, 3 October 2023 (UTC)Reply[reply]
I agree with Thryduulf here, although the first sentence is fine the second oversteps. Editors dissatisfaction with current spending shouldn't control specific details.-- LCU ActivelyDisinterested∆transmissions∆ °co-ords° 21:25, 3 October 2023 (UTC)Reply[reply]
I don't think having the English Wikipedia community approve all such grants individually is an effective use of either the WMF's or the community's time. The community should help set the objectives of these grants, so they can be filtered appropriately as part of the grant process. isaacl (talk) 23:32, 3 October 2023 (UTC)Reply[reply]
@Isaacl: Here "community" doesn't refer to enwiki, but the broader community - I was thinking through a securepoll vote (not, in my opinion, an unreasonable overhead when we are talking hundreds of thousands or millions of dollars), but other methods as determined by the WMF would also be appropriate. BilledMammal (talk) 03:41, 4 October 2023 (UTC)Reply[reply]
I have the same view regarding the effective use of the Wikimedia community's time. isaacl (talk) 04:00, 4 October 2023 (UTC)Reply[reply]
Ideally we shouldn't need to spend time on things like this, but unfortunately the WMF has demonstrated that they can't be trusted to act without oversight, through things like KEF and through other grants like POSTCARD which I discuss below (supporting Youtube and Instagram influencers). Personally I think the overhead can be kept to a minimal, such as by broad requests for approval (for example, rather than having voted on every grant proposed under the KEF, the community votes on the KEF itself), but reasonable minds may differ. BilledMammal (talk) 04:09, 4 October 2023 (UTC)Reply[reply]
It would be more effective to influence the setting of objectives and engage with the review process as necessary. isaacl (talk) 04:15, 4 October 2023 (UTC)Reply[reply]
While I suspect this will find some support, after some thought I find myself in the oppose column -- and for reasons not directly connected to the KEF. First, some background: This proposal began as a proposal to hold fundraising hostage unless the English Wikipedia got line-item veto power over all of the WMF's finances. That's been toned down quite a lot, but I can't get over the pervasive sense of English Wikipedia supremacy/exceptionalism running through all of the discussions up to this point. We are already the largest and most powerful of the projects. We already numerically dwarf everyone else. We already have most of our users in the richest countries on the planet. The idea that we deserve total financial power over the entire rest of the Wikimedia universe is shocking, and while that's not being proposed here, knowing that was the goal means I can't help but carry forward some skepticism here. I can fully appreciate that the idea of funding projects "unrelated" to Wikimedia projects is going to unite many people with a range of valid criticisms about how the WMF spends its money (i.e. "X feature or Y bug has been missing/broken for ages, but you're funding this?"). But the target of criticism here is something where the feedback has already led to a decision not to fund it again. What we're doing is deciding whether to adopt a general principle about "unrelated" projects using the KEF as an example, but never actually defining "unrelated". Others above have tried to explain the extent to which calling this "unrelated" is misleading. Wugapodes gives some good examples of other "unrelated" (but not actually unrelated) potential grantees. I'd add research into wikis in general, work on OpenStreetMap, research into linked data practices, funding for archives to digitize sources, and other kinds of projects that help us indirectly. And it's in that context that the KEF is indeed related. It's just not an edit-a-thon or Wikipedian-in-Residence. TL;DR - This might look like a referendum on the KEF, but it's actually a broadly worded principle with unclear implications. Given the background of these proposals, I have no reason not to think "unrelated" won't be treated as broadly as possible. — Rhododendritestalk \\ 00:49, 4 October 2023 (UTC)Reply[reply]
Per Thryduulf; that bit ought to originate from meta (if it's a good idea in the first place) and seems entitled coming from one wiki. In addition, Wugapodes brings up good concerns about wording. —Danre98(talk^contribs) 03:08, 4 October 2023 (UTC)Reply[reply]
Agree with the concerns raised above. Furthermore, even if the proposed method wasn't worded as vaguely as it is, handling individual grants through community vote seems an inherently poor idea, an inherent mismatch with our slow and fuzzy consensus system. CMD (talk) 03:17, 4 October 2023 (UTC)Reply[reply]
Per others. While I agree with the first sentence, the second feels like we're overstepping a bit. ARandomName123 (talk)Ping me! 06:32, 4 October 2023 (UTC)Reply[reply]
Per Rhododendrites above, and per Folly Mox and Wugapodes in the discussion section below. While the proposal's goals are understandable, the vague wording makes it impractical to actually enforce, the proposal would give enwp a disproportionate amount of power over other wikis, and I'm not convinced that a single-wiki RfC has the scope to enforce this change regardless. ModernDayTrilobite (talk • contribs) 15:59, 4 October 2023 (UTC)Reply[reply]
Not a good idea at all. And if this was a good idea, a "non-binding resolution" is not the way to go about it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:44, 4 October 2023 (UTC)Reply[reply]
This is far beyond our purview. I can envisage a speculative (if highly unlikely) scenario in which this project were so underfunded with regard to basic needs, relative to the amount of funds raised in relation to en.Wikipedia and donor intent that the en.Wikipedia community might need to make some noise to see more commitment to en.Wikipedia in the WMFs budget. But bluntly, we don't live in that reality or anything remotely like it. This project's needs are more than substantially enough met to justify our attempting to beackseat drive for the fiduciaries and professionals at the WMF on decisions that are well withing their legal and institutional discretion. A more generally worded appeal for a higher level of consultation/seeking feedback from the community might be something I can get behind, but this proposal (especially considering how it arose) is just presumptuous and way beyond the division of labour and authority as relates to WMF and movement finances. SnowRise let's rap 21:45, 4 October 2023 (UTC)Reply[reply]
we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community. This is too vague to support. What is non-trivial? What counts as "approval" and how would it be solicited? Which community do you mean, as there are many of them beyond English Wikipedia? The WMF already tries to get community approval, but globally from all Wikimedians via Meta. The disconnect is that most editors don't show up to Meta and participate in grant reviews, but that work does in fact happen. I agree the WMF should work on encouraging more on-wiki connection between the grant review (which is actually conducted by volunteer committees in many cases, btw) and the editing communities, but this is not a clear enough proposed solution to take action on. Steven Walling • talk 15:31, 6 October 2023 (UTC)Reply[reply]
@Steven Walling: You said "too vague to support." What specific definitions of the terms "non-trivial," "approval," and "community" would cause you to support the proposal? Levivich (talk) 16:02, 6 October 2023 (UTC)Reply[reply]
This isn't my proposal so not really incumbent on me to fix it. It seems implied that the proposal actually means "The WMF should run a straw poll !vote on the Village Pump every time before they want to make a grant over [insert whatever arbitrary $ amount qualifies as non-trivial]". Really unclear if that's specifically what is meant though. In definition this vague, technically speaking the WMF already fulfills the requirements, because the entire grantmaking process on Meta is done transparently and mostly via volunteer committees. Steven Walling • talk 02:06, 7 October 2023 (UTC)Reply[reply]
If this proposal was only the first sentence – a reminder to spend money more wisely and prioritize the Wikimedia Community, in tandem with proposal 3 which I supported – I would certainly get behind that, but a targeted shot across the bow against the Knowledge Equity Fund, which I broadly agree with and would argue is quite valuable and important, is not something I can get behind. Curbon7 (talk) 19:20, 7 October 2023 (UTC)Reply[reply]
Rhododendrites brings up good points about how this seems to value too much authority over all Wikimedia projects with the English Wikipedia. As noted elsewhere, if there is a place for that authority, it's at meta with the global community. I also think WMF's support for groups outside the project is important – we need places to get our information from in the first place – and I can't shake the feeling this is a step towards stopping that. RunningTiger123 (talk) 03:03, 8 October 2023 (UTC)Reply[reply]
Rhododendrites and RT put it well. The proposal is poorly worded, misrepresents a particular community-overseen grant pool, asks to cancel that grant pool and for an impossibly vague en:wp veto over future grants, and misuses the trope of donor intent. It also implausibly suggests that grants earmarked during a year of surplus and amounting to under 1% of the WMF's program budget, are somehow preventing it from addressing unspecified "internal deficiencies". There are valid + uncontroversial points to be made for the Foundation to better align its prioritize with community needs... but this does not make any of those points, instead proposing to make a dubious statement on behalf of the whole community. No, thank you. – SJ + 04:21, 8 October 2023 (UTC)Reply[reply]
The original proposal is waaay to broad for me to support in any sensible fashion. The community has absolutely no remit in deciding to veto funding based on what is relevant to the movement (with enough wikilawyering, we would probably have consider recent funding for projects like Wikidata and WikiLamda (or allocation of money for Wikimania 2023) to have not directly support the movement and could have labelled them as mission creep). That being said, I would Support @Novem Linguae's rewording since it is short and succint and gets the point across without resorting to insinuations/effectively codifying a veto power for the en.wikipedia community and assumption of bad faith on the part of the Foundation. -- Sohom (talk) 12:51, 6 October 2023 (UTC)Reply[reply]
@Sohom Datta Judging by the content of your comment and your reference to Novem Linguae's rewording, I suspect you meant to oppose the proposal below this one, i.e. "Grants to organizations unrelated to supporting Wikimedia Projects (Community Response)". (Feel free to delete this comment either way.) Regards, AndreasJN466 16:24, 6 October 2023 (UTC)Reply[reply]
The purpose of WMF, as mandated by the founding documents, is the support of free knowledge. Maintaining Wikipedia is just one method to do so. Giving to other organizations working in the field of free knowledge is supported by this purpose. --h-stt!? 15:18, 23 October 2023 (UTC)Reply[reply]
As others have said, the second sentence goes too far. I also agree with others that the Knowledge Equity Fund is not obviously unrelated to Wikipedia's mission; we should instead push for greater transparency around the KEF. Suriname0 (talk) 22:24, 23 October 2023 (UTC)Reply[reply]
Grants to organizations unrelated to supporting Wikimedia Projects (Discussion)
So I guess my issue with this text is that the WMF does consult with the community about disbursement of Knowledge Equity Grants. See meta:Knowledge Equity Fund#The Knowledge Equity Fund Committee, which lists five volunteers alongside the six staffers.It's widely known that the Knowledge Equity Fund is pretty unpopular, and no one seems to have indicated it will recur after the third year of disbursements, which I guess we'll hear about on Friday. Someone on wikimedia-l or some other email thread compared these grants to basic research, like laying the groundwork for a more successful "free knowledge movement", which was a minority view but makes sense.The thing I suppose rubs me wrongest is that the goal here seems to be to stop giving these planned grants to marginalised groups, and spend it instead on English Wikipedia, the rich white dude of the Wikimedia Party Palace. Yes, that's not stated explicitly, but Resolution 3: Here's How to Spend Money on Us immediately follows. We don't not need Foundation money for staff to maintain technical debt, fix bugs, talk to us, etc., but it just feels... kinda gross? Please note this is a comment, not an oppose. Folly Mox (talk) 03:22, 3 October 2023 (UTC)Reply[reply]
Folly Mox, I think you hit the nail on the head with this comment. This proposal feels....entitled. Risker (talk) 07:29, 3 October 2023 (UTC)Reply[reply]
It is reasonable that many in the community feel entitled to see WMF budget used to support Wikimedia projects (not us, which sounds like anyone here is expecting to see a penny). Especially since that is what all fundraising messaging strongly implies. On seeing Wikimedia projects as the rich white dude... I couldn't disagree more. Some of us still see Wikimedia projects as a humanist mission that deserves full focus from the Foundation that was established to guarantee its continuity. MarioGom (talk) 17:48, 5 November 2023 (UTC)Reply[reply]
The WMF should be spending its money on improving WMF projects for readers, and on helping editors to make such improvements. No one suggests limiting the spending to wikipedias, or to English-language projects. (Spending on Chinese Wiktionary is fine, and probably doesn't benefit many rich white dudes.) Giving money to some external body to spend should require evidence that it will benefit WMF projects more than spending that money directly. Certes (talk) 18:47, 5 November 2023 (UTC)Reply[reply]
I think that's an important distinction. The WMF is certainly not "The English Wikipedia Foundation", and we of course must remember that. If WMF spends funds on, for example, helping a project in a less common language recruit editors and get off the ground, that is a totally valid use of those funds, because it is spent in direct support of the Wikimedia mission. But WMF is the Wikimedia Foundation, not the Fix-Everything-Everywhere Foundation. So it is reasonable to expect that when WMF spends its funds, it will be able to directly answer the question "What direct benefit is this expenditure expected to have toward the Wikimedia projects?". That doesn't have to be spent directly on the projects—if, for example, the WMF were to help start up a journal willing to do peer review and publication for articles in areas that are traditionally underrepresented in academic publications, that is of direct value to the Wikimedia projects by expanding the range of things we have enough high quality source material to write about, where before that we wouldn't. But it is then possible to say "Well, here's how this benefits Wikimedia." On the other hand, it seems that many of the things WMF is currently doing are in the realm of "That's a nice thing to do—but it seems out of scope for us to be doing it." SeraphimbladeTalk to me 19:50, 5 November 2023 (UTC)Reply[reply]
There seems to be a dichotomy between Wikimedia Projects and external orgs that I think misunderstands the relationship between our projects and the wider free knowledge movement. Creative Commons and the Internet Archive are external organizations which are mission aligned, and their success is directly relevant to the success of our projects. If they asked us for a grant would we tell them to kick bricks because it doesn't benefit our projects? A more specific example, I spent some time last year working with Cornell's copyright information center on a grant proposal to increase their staffing so that they could resume and increase their outreach work which our CCI group had found valuable but which had been cut due to university budgetary restrictions (it fell through in the planning stage, unfortunately). Would this resolution have prevented that kind of support for mission-aligned organizations? It wouldn't have been spent "on the projects", but the benefit of being a "good neighbor" and supporting groups who share our values and support our goals has knock-on effects that shouldn't be summarily dismissed. — Wug·a·po·des 00:19, 4 October 2023 (UTC)Reply[reply]
@Wugapodes: This purpose of this proposal isn't to stop grants going to entities that a reasonable individual could consider unrelated to supporting Wikimedia Projects; it's to give the broader community oversight of the process, because things like the KEF and other grants like POSTCARD, which are intended to support (I am not making this up) Instragram and Youtube influencers have shown that we cannot trust the judgement of the WMF in this matter.
If the WMF wanted to give $500,000 to Internet Archive or a similar project then I have no doubt that the community would approve it, because there is no possible reputational damage from such a grant and because IA is critical to our mission - it is essential to allow us to comply with WP:V. Indeed, I would argue that it is related to supporting Wikimedia projects, but perhaps a reasonable argument can be made as to why it is not. BilledMammal (talk) 03:54, 4 October 2023 (UTC)Reply[reply]
After your response I'm less clear on what's being proposed. You keep using really vague words like "broader community" and "oversight" which on the surface sound agreeable but are being used to mask what seem to be more controversial positions. The "broader community" is Meta, it's the global community comprising participants of all projects. Do you mean everyone or do you mean EnWiki? This community (i.e., the global community) already has broad oversight of these processes including multiple volunteer led, region specific committees and an open comment period on Meta (one of which you linked to). Wanting more participation is reasonable, but I don't think that framing this as if there's no community involvement or participation is fair; not liking a process and a process not existing are different things.The premise of the resolution isn't even well motivated: the resolution hinges on what individual donors think they're supporting, but neglects the other $30 million dollars in major gifts,enterprise funds, endowment returns, and investment returns which don't come from the small individual donors relied on by the rhetoric. It uses vague language games of "non-trivial" and "reasonable individual" to hide that fact that even among supporters there's no clear understanding of what those mean---some supporters suggest that "non-trivial" would cover every single rapid grant over the $500 minimum. Even your comment here can't firmly reject that this proposal would implicate partnerships with major mission aligned organizations like the Internet Archive I would argue that it is related to supporting Wikimedia projects, but perhaps a reasonable argument can be made as to why it is not. I'm not going to sign my name to something so vague that it can be twisted in whatever way someone wants. — Wug·a·po·des 06:22, 4 October 2023 (UTC)Reply[reply]
Do you mean everyone or do you mean EnWiki? Everyone, and I would argue that they don't have broader oversight of the processes; if they did, KEF would not have happened.
vague language games of "non-trivial" and "reasonable individual" For broad statements like this specificity is difficult, and results in situations where the WMF could use technicalities to get around seeking community approval. However, I don't see that as an issue; the very worst that can happen here is the WMF unnecessarily asks for community approval for some grants.
Even your comment here can't firmly reject that this proposal would implicate partnerships with major mission aligned organizations like the Internet Archive I don't discount the possibility that a reasonable argument could be made, but I can't envisage one. BilledMammal (talk) 06:34, 4 October 2023 (UTC)Reply[reply]
Everyone so then why is this on EnWiki? Why are the first words of the proposal "The English Wikipedia community"? Has this been translated in to any other languages? Have opinions of any other community been considered? The KEF was half volunteers hailing from English, French, Spanish, Indonesian, and Arabic projects; the current grants structure was was redesigned over nearly a year on the basis of multiple consultations with stakeholders including various project volunteers from across the globe. Why should anyone believe that an RfC held on EnWiki and talking solely about EnWiki accurately reflects global consensus on how communities would like to oversee grants? On what basis are you speaking for the global community?For broad statements like this specificity is difficult You want greater control and oversight of a $20 million grants budget, but defining the scope of what you want greater control over is too hard of a problem? Indeed, revolution is easy; governing is hard. Are you prepared to accept the increased staff overhead (read: the administrative costs being criticized elsewhere) that comes with managing all those "unnecessar[y]" postings? Too many posting will make it harder to find the important proposals (compare banner blindness); how will you ensure that this glut of "funding for edit-a-thon pizza" requests won't paradoxically lead to less oversight as people tune out? We could say these (and other questions) are for the WMF to figure out, but if you don't trust them to even implement specific requests, why would you trust them to implement vague requests? Plus, that would mean yet more admin overhead spent on interpreting our vague resolutions. I don't see vagueness as a problem in its own right; I see it as a problem because it belies a lack of strategic direction. The allocation of a $20 million annual grants budget, let alone the $170 million annual budget, shouldn't be decided on the basis of vague value statements. I find it ironic that misappropriation of funds is seen as a problem when the WMF does it, but we're allowed to hand-wave away the specifics of allocating millions of dollars because it's too difficult to figure out. — Wug·a·po·des 22:50, 4 October 2023 (UTC)Reply[reply]
Regarding "everyone", I suspect you would find it more objectionable, not less, if the proposal was that grants to organizations unrelated to supporting Wikimedia Projects needed approval from the enwiki community, rather than from the broader community.
defining the scope of what you want greater control over is too hard of a problem It's a difficult problem, but it is one that we could work around, if it was beneficial to do so. It is not; with this being a non-binding resolution we are better served by defining a principle that we can then work with the WMF to implement - and as I said, the worst that can happen is the WMF unnecessarily asks for community approval for some grants.
how will you ensure that this glut of "funding for edit-a-thon pizza" requests won't paradoxically lead to less oversight as people tune out edit-a-thon's are indisputably related to supporting Wikimedia Projects; this proposal isn't asking for the WMF to get our approval on such grants.
I find it ironic that misappropriation of funds is seen as a problem when the WMF does it, but we're allowed to hand-wave away the specifics of allocating millions of dollars because it's too difficult to figure out. We're not going to be allocating them; this resolution doesn't ask for us to decide where they will go. All it asks is that the WMF ensures that the community is onboard with their decisions. BilledMammal (talk) 08:45, 5 October 2023 (UTC)Reply[reply]
You didn't answer my question: on what basis are you speaking for the global community? You claim to be speaking for everyone, but when asked for justification on how you represent global opinions you deflect. When the EnWiki centrism of your position is pointed out, you start speaking about the global community again. You see how we keep playing this language game, right? Do you understand why this inability to speak plainly gives me no confidence in the resolution?And again, you didn't answer my question: are you prepared to accept the increased administrative costs necessary to handle the superfluous postings and consultation work required to manage your vague resolution? If you balk at doing threshold levels of strategic planning, I do not trust that you are prepared for the far more difficult work ahead.You're right, I got this confused with the other resolution where edit-a-thons would potentially be covered as a "non-trivial grant[] that will result in activity on the English Wikipedia".We're not going to be allocating them [funds] This is outright false. The resolution explicitly says "We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund". You're seeking to direct millions right here and right now, and later on ask that they "seek[] approval" for ill-defined categories of future grants. — Wug·a·po·des 18:18, 5 October 2023 (UTC)Reply[reply]
I think there has been a miscommunication here. This resolution speaks for the English Wikipedia; if passed the English Wikipedia would be asking that the broader community is consulted on grants to organizations unrelated to supporting Wikimedia Projects. I don't believe there is any enwiki centrism here; we are saying that we are concerned about these grants but we recognize that it isn't our place to decide alone whether they go forward or not; instead, we are asking that the WMF seeks approval for them from the broader community.
This is outright false. Perhaps we are using a different definition of the word allocate; the definition I am using is the act of deciding officially which person, company, area of business, etc. something should be given to. This resolution doesn't ask that we are allowed to decide who will receive funding; instead, it asks that we are allowed to reject funding within a narrow area, to act as gatekeepers. If that isn't the definition you are using can you clarify?
are you prepared to accept the increased administrative costs necessary to handle the superfluous postings and consultation work required to manage your vague resolution I'm not convinced there will be an increased administrative overhead. Some of the grants issued in the past are ones that should be obvious to the WMF would be rejected by the community; even absent this requirement those grants consume administrative capacity. Ideally, the WMF will recognize this and rather than wasting their time, and the communities time, on the grants will instead redirect the administrative capacity to handle the community consultation work. However, even if they don't and administrative costs are increased I believe the net result will be less money spent on the program as a whole due to grants being rejected. So yes, I am prepared to accept it.
If you balk at doing threshold levels of strategic planning, I do not trust that you are prepared for the far more difficult work ahead. I feel I have already replied to your statements about the lack of specificity in the proposal; It's a difficult problem, but it is one that we could work around, if it was beneficial to do so. It is not; with this being a non-binding resolution we are better served by defining a principle that we can then work with the WMF to implement - and as I said, the worst that can happen is the WMF unnecessarily asks for community approval for some grants.BilledMammal (talk) 18:48, 5 October 2023 (UTC)Reply[reply]
I can't really support this as currently worded (I do not think that the English Wikipedia in and of itself has the authority to demand that the WMF do a particular thing with already allocated funds), but I will give a "moral support" here. The WMF certainly has been spending too much money on things which do not have a clear connection to the core mission of Wikimedia, and has not generally been willing to give further detailed explanations for "How does this further Wikimedia's goals, and how is this expenditure the best way to achieve that?" beyond platitudes. So, I agree in the spirit of the thing, but this proposal is not the right way to ask for that. SeraphimbladeTalk to me 03:19, 4 October 2023 (UTC)Reply[reply]
@Seraphimblade: It's not a demand, but a request - and personally, I would have no issue if the WMF did proceed with the third round, so long as they first secured the broader communities approval through a securepoll vote. BilledMammal (talk) 03:54, 4 October 2023 (UTC)Reply[reply]
@Seraphimblade: seconding your point, a proposal to focus on the core mission, with specific examples of what needs clearer focus, would feel constructive. That does not feel like the spirit of this proposal to me, which second-guesses and mischaracterizes a specific effort to counter systemic bias that already involves community input, and at least tried to explain its origins and how it furthers Wikimedia's goals. – SJ + 04:50, 8 October 2023 (UTC)Reply[reply]
Small note that the Oppose/Support section titles are potentially a tad confusing. When read at face value, they might suggest you support/oppose the opposite of what you intend. Support for instance, when read as a sentence means: support, giving grants to external organisations, while in reality it means I support the proposal that that we are against giving external organisations grants. This is also a common issue with Survey polls in politics. —TheDJ (talk • contribs) 09:38, 4 October 2023 (UTC)Reply[reply]
Many of the topics and concerns raised here were discussed at the open community call hosted by the Knowledge Equity Fund Committee last Friday, October 6. You can find the notes from that call on Meta. These topics include how we can more clearly communicate opportunities for communities to participate in nominating grantees and getting involved, how the Knowledge Equity Fund grantees are connected to the movement and how we can better connect the dots, and how we are measuring the impact of knowledge equity. The Committee will be meeting this week to discuss the suggestions and feedback from the call and will post an update about next steps in the next two weeks.NGunasena (WMF) (talk) 19:42, 11 October 2023 (UTC)Reply[reply]
I just posted some next steps and changes that the Knowledge Equity Fund Committee will be taking based on the feedback we heard in the community call, in three distinct areas: Improving communication, Clarifying impact, and Connecting the dots with the movement. This is not a comprehensive list as we're still in discussion, but we wanted to share the changes as we go. NGunasena (WMF) (talk) 20:56, 20 October 2023 (UTC)Reply[reply]
The most important way to address Knowledge Equity also involves "sticking to our knitting": improving our mobile editing interface and mobile apps. Many potential editors only have access to smart phones, not computers. If we really want to boost editing from areas like the Global South, we need to make it easier.
I think the first thing to address there is WP:THEYCANTHEARYOU. That should have been treated as an emergency level bug from the beginning, and it's well past time to get that fixed. SeraphimbladeTalk to me 04:41, 22 October 2023 (UTC)Reply[reply]
Hi @Seraphimblade, my name is Jazmin (Jaz) and I am the Product Manager for the Mobile Apps team. I very much agree that maintaining on-wiki communication functionality is important and necessary. This is why, over the last two years, we’ve prioritized improvements to make the WP:THEYCANTHEARYOU table more and more green. (e.g., 1, 2, 3), though for some added context, depending on the platform (Android app, iOS app, or Mobile Web) the implementation, or lack thereof, of alerts differs, but steps are being taken to change that.
Specifically on the issue of IP editors not seeing notifications, we are currently working on it. I can understand that specific mobile communications issues feel a bit slow or quirky (depending on the platform) as compared to others; this is due to several teams working systematically to address anonymous edits through temporary accounts.
In the future, the shift to “temporary accounts” (formerly known as IP Masking) will hide IP addresses from the general public while also allowing people to continue editing without creating actual accounts. Particularly in the apps, users that do not login to a permanent account when attempting to make an edit, will automatically be assigned a temporary account that is based on cookies, not location. On the apps, users with temporary accounts will have the same editing and notifications experience as people that create permanent accounts. This will eliminate the quirks and inconsistencies across platforms, addressing many of the outstanding gaps in mobile notifications. @NKohli (WMF) and @SGrabarczuk (WMF) can share more about this project overall should you have any questions.
Additionally, next week we will make some updates to the cross team on-wiki communication MediaWiki page, which was created to be more inclusive of other language wikis; the refresh will include incorporating updates currently represented on team specific project pages. The app's Community Relations Specialist, @ARamadan-WMF will ping you there once the updates are live so that we can continue the conversation and get your input on whether or not we are going in the right direction.
Hi @A. B., I am happy to see your passion for improving editing on mobile. My name is Jazmin (Jaz), and I am the Product Manager for the Mobile Apps team. While I collaborate with the team responsible for Mobile Web, I do want to make that distinction, so you can understand the context of my response.
My manager, @MMiller (WMF), shared just a few improvements we are working on for the mobile app experience. What isn’t mentioned there is that we are completely rewriting the editor on iOS to improve the performance.
We have an open meeting coming up Friday if you’d like to have a closer look at our roadmap and share additional ideas to improve the editing experience on the app. If you can’t make the time, no worries, we will record it and provide notes. We also make updates for the Android and iOS app on a monthly basis, which includes sharing early designs and ideas and we welcome your partnership. If ever you have feature ideas or bugs you notice feel free to reach out to @ARamadan-WMF so that we can triage it in our weekly team meeting.
For any Mobile Web ideas that are editing specific feel free to reach out to @PPelberg (WMF) and for more reading features @OVasileva (WMF) is a good person to talk to. JTanner (WMF) (talk) 20:55, 26 October 2023 (UTC)Reply[reply]
Increased support for internal needs (Community Response)
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they need
to improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
Increased support for internal needs (Survey)
Support (Increased support for internal needs)
What we need from the WMF most of all is tech support; for them to maintain the website and develop the tools that we need to build the encyclopedia. Unfortunately, this support is often lacking; despite the criticality of New Page Patrol it took a massive lobbying effort to get the WMF to dedicate any resources to it, and it has been six months since we were notified that the graph extension had to be disabled due to security risks, but there has been little progress on restoring it despite its utility. Hopefully the WMF will be willing to take this resolution on board and in its next budget direct a greater proportion of resources towards providing this support. BilledMammal (talk) 01:01, 3 October 2023 (UTC)Reply[reply]
Easy support, though I'd encourage removing "established" from "established editors". While accepting this non-binding resolution is several steps removed from actually seeing a change in TWL resources, what would help knowledge equity is actually to lower the requirements to access TWL. Help people get off on the right foot when they're editing rather than assume they'll slog through 500 edits without access to good sourcing. Certainly not enough to cause me to oppose, but I'd like to see that word removed (apologies for not catching it before the proposal went live -- perhaps it's not too late, BilledMammal?). — Rhododendritestalk \\ 01:36, 3 October 2023 (UTC)Reply[reply]
While I understand your concern, I'd prefer to leave "established" in there. Realistically publishers offering resources are going to want to have some idea of the hit rate they are signing up for. I can't see Elsevier, for example, wanting to open ScienceDirect much more widely than they already have. Espresso Addict (talk) 01:47, 3 October 2023 (UTC)Reply[reply]
Then what is the funding going towards? Last I checked, everything in TWL isn't because the WMF paid for it but because someone simply asked the publisher for it. WMF could help close the gap. I cannot imagine the WMF paying to add these resources, as that would lead to all the other publishers saying "wait, we don't have to give it away?" — Rhododendritestalk \\ 02:01, 3 October 2023 (UTC)Reply[reply]
@Rhododendrites and Espresso Addict: Just jumping in with a quick note that Rhododendrites is correct - we don't pay subscriptions for any of The Wikipedia Library's resources. It would be obscenely expensive given that we serve tens of thousands of users (approaching the entire WMF budget), and as you suggest, paying one publisher would risk resulting in a chain of events where other publishers also demand payment. I'm sympathetic to the idea of lowering access requirements, I'd love for more editors to be able to use the library. Unfortunately this would require renegotiating all our agreements, which is a lot of work. Input is welcome on this topic at T314357. Samwalton9 (WMF) (talk) 10:06, 6 October 2023 (UTC)Reply[reply]
Thanks for the response, Samwalton9 (WMF). I read the interesting Phab link but it won't let me comment. I think it would be more realistic for the Foundation to pay for access for a small group of highly active named editors, perhaps for a specific type of task, which would make it fall more under the Wikipedian-in-Residence type of relationship. On the access requirements, fwiw, I have chatted to several non-editors about the library resources as a recruitment ploy and non-editors are generally interested until I mention the access requirements, which seem unapproachably steep to them. Espresso Addict (talk) 21:44, 6 October 2023 (UTC)Reply[reply]
If they say they're raising money to support and improve the encyclopedia, they should do so. Intothatdarkness 01:52, 3 October 2023 (UTC)Reply[reply]
I've said as much before and I think leveraging existing resources like the legal fees assistance program and Rapid Grants would be an efficient way to make progress on this in parallel with increasing Wikipedia Library holdings. — Wug·a·po·des 02:30, 3 October 2023 (UTC)Reply[reply]
Community Wishlist items that consistently receive high support are continually being overlooked due to currently insufficient funding for technical staff. Reallocating funds from such editing grants would arguably enable editors to more efficiently pursue these grants' aim of increased article coverage BluePenguin18 🐧 ( 💬 ) 02:48, 3 October 2023 (UTC)Reply[reply]
"Hire more devs" is a no-brainer. The microgrants sound like an interesting idea as well, and the Wikipedia Library is already amazing. But yeah, hire more devs. Help us align with our shared goals. Folly Mox (talk) 03:02, 3 October 2023 (UTC)Reply[reply]
The WMF has more than enough money to do these things, but it has inexplicably decided to spend a large sum of this money on things that do not help Wikipedia and its sister projects. Thebiguglyalien (talk) 03:14, 3 October 2023 (UTC)Reply[reply]
Mainly due to the graph extension being disabled and the lack of work going towards fixing it. It's like a ghost haunting the talk pages of most Wikipedia articles. I've noticed a concerning amount of decay when it comes to tech support, and if additional funding will help then I'm all for it. Deauthorized. (talk) 03:23, 3 October 2023 (UTC)Reply[reply]
While I'm a little worried about monkey paw effects here, that doesn't diminish my support per BilledMammal. Barkeep49 (talk) 03:39, 3 October 2023 (UTC)Reply[reply]
In agreement with Barkeep49, with more comments to follow. Best, KevinL (aka L235·t·c) 04:16, 3 October 2023 (UTC)Reply[reply]
Common sense. There have been several technical issues at NPP that we have had to beg and grovel for the WMF to fix. More resources towards technical development is self-evident. Curbon7 (talk) 04:17, 3 October 2023 (UTC)Reply[reply]
While I understand that the Foundation has had some growing pains in the tech department, that is no excuse to not continue to put effort into our software. If that requires some radical changes, so be it, but we need more effort going into our backend. That means more money. There are far too many tech issues that have lingered for years. CaptainEekEdits Ho Cap'n!⚓ 05:03, 3 October 2023 (UTC)Reply[reply]
100%. Don't know if this is going to move the needle but it couldn't hurt. Nardog (talk) 05:08, 3 October 2023 (UTC)Reply[reply]
Tech support and maintenance, and development of features requested by editors is the minimum that is expected from the WMF. Ciridae (talk) 06:00, 3 October 2023 (UTC)Reply[reply]
I'm not generally as critical of the WMF as many but this is the one areas I agree with the critics. The WMF has been slack in supporting the communities needs. I appreciate that it doesn't always go well since some features have been implemented on request then disliked and abandoned, and that there are a lot of communities with differing needs to support, but they can and should do better. Nil Einne (talk) 11:23, 3 October 2023 (UTC)Reply[reply]
Micro-grants for old Resource Requests seems like a pretty good idea. ARandomName123 (talk)Ping me! 13:07, 3 October 2023 (UTC)Reply[reply]
This is what the WMF was created for. Certes (talk) 14:27, 3 October 2023 (UTC)Reply[reply]
The Wikimedia Community, and not the Wikimedia Foundation, governs the Wikimedia Movement. When donors give money to Wikipedia, they give it to the Wikimedia Community and not the Wikimedia Foundation. It is essential that money go to support the Wikimedia Community, its culture, and its values. With increasing regularity and forcefulness, the values and ethics of the Wikimedia Foundation are contrary to those of the Wikimedia Community. Bluerasberry (talk) 14:25, 3 October 2023 (UTC)Reply[reply]
It's the primary mission of the movement, after all. The execution should match the sales pitch. Many of the other things they do are, I feel, for laudable goals, but fundraising shouldn't be pretextual in this way. There are many projects related to the core mission that receive anemic funding. The core mission is the reason the WMF exists. CoffeeCrumbs (talk) 15:14, 3 October 2023 (UTC)Reply[reply]
WMF has consistently shown that it is willing to spend any amount of money needed for fundraising, and the fun parties that are involved with that, and very little on actual needed functions. The leadership has been a disgrace for years, and is part of the reason I don't spend more time here. Dennis Brown - 2¢ 16:46, 3 October 2023 (UTC)Reply[reply]
WMF has been neglecting its core function for too long. Levivich (talk) 17:05, 3 October 2023 (UTC)Reply[reply]
Support. I particularly like the idea of widening the scope of the Wikipedia Library. I think this is a resource which so many editors use and could do with additional investment. Willbb234 20:43, 3 October 2023 (UTC)Reply[reply]
Yes, the foundation should always have its primary mission in mind. However, I support with the nuance that the foundation has hired support staff, of which some are necessary, and that whilst micro grants for resource requests are a good idea, the linked page (at least) is only on enwiki which is a negative. —Danre98(talk^contribs) 03:23, 4 October 2023 (UTC)Reply[reply]
One of the WMF's primary founding purposes was to provide technical services and software development for the Wikimedia projects. If not its top priority, that should be very close to it. We have far too often seen highly desired community requests go either entirely unanswered or get a "We don't have the resources right now" for years on end, while we see tons of resources flowing out in dozens of other directions. SeraphimbladeTalk to me 04:43, 4 October 2023 (UTC)Reply[reply]
Support, if for no other reason than this is what donors expect their money to be spent on. Barnards.tar.gz (talk) 07:50, 4 October 2023 (UTC)Reply[reply]
I think this is where we're on firmest ground, because we're asking for something that we need rather than trying to dictate to the WMF. It really is astonishing how little of the WMF's enormous budget goes to software. We haven't been able to use mw:Extension:Graph for six months, apparently because it was unmaintained for years before that. NPP had to beg for fixes to Page Curation, also unmaintained for years, and after three months of work all the team assigned to it could manage to do is switch to a more modern backend with no significant changes to the functionality (to be clear I'm not criticising the team; they're clearly under-resourced). We can't reliably talk to editors on mobile. And that's with volunteer developers doing a great deal of the heavy lifting. – Joe (talk) 08:24, 4 October 2023 (UTC)Reply[reply]
Technical maintenance is important and is outside the ability of the community to perform. I think conveying to the WMF that we'd like to see more investment in that area could be productive. ModernDayTrilobite (talk • contribs) 16:05, 4 October 2023 (UTC)Reply[reply]
We have some of the most-obsessive volunteers and they give the world their labor for free. Least we could do is ensure truth in advertising by supporting those editors. Chris Troutman (talk) 20:11, 4 October 2023 (UTC)Reply[reply]
Now this one I can get behind. My support is a little on the weaker side, because I recognize the complexities involved in the financing of the Wikimedia movement and institutional ecosystem, with it's many stakeholders and I broadly respect the discretion of the WMF as pertains to addressing and balancing the competing needs. That said, the specific areas highlighted by this proposal are known current weaknesses in our technical infrastructure (even if vaguely defined here). And while I have often felt the scrutiny the WMF faces from some of it's more consistent critics as regards it's management of movement resources has strayed into the presumptuous (to say nothing of those that are sometimes histrionic, speculative, unrealistic, or simply wildly outside the purview of those without the relevant fiduciary or professional duties), I do think that these would-be muckrakers have succeeded in at least one respect: highlighting just how sizeable a largess the WMF has managed to accrue for the movement through effective fundraising. While I do not believe it is this community's role to set terms on how those funds are distributed (outside of a speculative existential crises from underfunding), I do not see the harm in pointing out to the WMF that we have a few areas where funding of technical solutions would be especially helpful at this moment in time, and that there is an argument to be made, based on donor intent, that the large role that en.Wikipedia plays in generating funds for the movement as a whole arguably militates for plugging these needs sooner, rather than later, at least when the reserve financing is as flush as apparently they currently are. SnowRise let's rap 22:01, 4 October 2023 (UTC)Reply[reply]
Support. I am not so concerned with the Wikipedia Library and WP:RX part as this is the first I'm hearing of problems in those areas. I am very supportive of the Community Wishlist and community software part of this RFC though. Community software seems like an area that has historically been neglected, with some small progress made recently, but still with much work to do. –Novem Linguae (talk) 08:00, 5 October 2023 (UTC)Reply[reply]
Support: with the amount of money the WMF have, the technology we have should be cutting edge. The graph extension is a prime example of something that should have been fixed overnight. The Wishlist simply doesn't work. The problem is not just the broken things and the missing functionality. I don't think many experienced volunteers understand just how unusable this website is to newcomers. For one thing, website design has advanced since 2001 when writing in lightweight markup language was expected. For another, experienced volunteers accrue all sorts of gadgets and js code to make simple tasks that are otherwise very complicated or make readable what is completely unreadable on the base site. — Bilorv (talk) 21:16, 6 October 2023 (UTC)Reply[reply]
Support This year the Foundation did the annual planning in public with community input for the first time in years. That was a step in the right direction, and many of the things they committed to are explicitly with the editing community in mind. There is still more that could be done to put sufficient staff attention on community needs however, and be responsive/agile when it comes to planning and resourcing. Steven Walling • talk 02:10, 7 October 2023 (UTC)Reply[reply]
Support it's ridiculous that the foundation has apparently enough money to donate to other organizations, while not enough to perform basic software maintenance to support its core mission --Ita140188 (talk) 14:00, 9 October 2023 (UTC)Reply[reply]
Support – Most people who donate I've talked to IRL have the impression that "it's to keep the servers running". I think using a larger portion of funds towards tech support is necessary or should at least be an option to allocate your donation to. Clovermoss🍀(talk) 20:33, 10 October 2023 (UTC)Reply[reply]
Support This will also stop deceiving donors who do so to support Wikipedia. It would have been better to include / implicitly includes "shift funds from other less related areas, not increase total expenditures." North8000 (talk) 19:34, 13 October 2023 (UTC)Reply[reply]
Support The WMFs number one job - really the only reason it needs to exist - is technical and it seems to always forget that in favor of "flashier" initiatives. The impact of more technical work dwarfs any other uses of donor money. Galobtter (talk) 22:51, 13 October 2023 (UTC)Reply[reply]
Support We could do so much more. (comment from involved editor) — TheresNoTime (talk • they/them) 11:48, 14 October 2023 (UTC)Reply[reply]
Support The WMF needs to provide far more support to the community, and there are almost zero blockers preventing it, or at least a request for it from us. Justarandomamerican (talk) Have a good day! 21:11, 14 October 2023 (UTC)Reply[reply]
Support. This should be the top priority of the WMF. I would suggest finding ways to align C-level executives with this core mission, rather than aligning Wikimedia projects with whatever makes good high profile resumes in the US NGO scene. MarioGom (talk) 08:00, 15 October 2023 (UTC)Reply[reply]
Support. In particular, improve the mobile interface and apps so less affluent editors can more easily add content. Many have mobile devices but no desktop computer. Also see my 23 October TWL suggestion in the discussion section below. --A. B.(talk • contribs • global count) 02:37, 22 October 2023 (UTC)Reply[reply]
Support. Obviously. Stop wasting $$$ on "flashy" projects in lieu of increased support for the community, that's what people give their money for. --Randykitty (talk) 13:26, 24 October 2023 (UTC)Reply[reply]
Support Organization failure when everything is for the "flash" and "bangs" instead of taking care of the core values. We didn't need too much work. WMF is already bloated with millions of dollars they have received - we didn't need to bloat it even more. Any IT startup tech having money/resources WMF got today can easily fix any tech issues around here - but WMF can't. ✠ SunDawn ✠(contact) 03:10, 25 October 2023 (UTC)Reply[reply]
Support I know of at least one privacy-impacting security flaw which is still not fixed because we have to balance what we are physically able to contribute our time to, and what is within the scope of the project we commit to. What else needs to be said? Suffusion of Yellow (talk) 23:55, 27 October 2023 (UTC)Reply[reply]
Conditional Support. I agree with Rhododendrites that the word "established" should be removed from "established editors". I also think mention of the Graph extension should be removed, as there were good reasons it was disabled and it distracts from our overall point to bring it up here. Nosferattus (talk) 01:52, 28 October 2023 (UTC)Reply[reply]
WP:TCHY creates a tremendous workload for volunteer editors and has frustrated me for a long time. — SamX [talk·contribs] 08:15, 28 October 2023 (UTC)Reply[reply]
Support - we need the resources of the Wikimedia foundation to go directly into wikimedia websites. The ever growing funding requirement that is essentially unconnected from the actual task of running the websites is unacceptable tompagenet (talk) 13:19, 29 October 2023 (UTC)Reply[reply]
Oppose Should the WMF devote more effort to community requests? Sure! But I've been here nearly two decades and I've never used grapher extension. And tools I use every day you've probably never used. We're not all going to agree on what is a critical request, so this is pretty pointless. Gamaliel (talk) 23:15, 3 October 2023 (UTC)Reply[reply]
Oppose including Graph extension Solely on the grounds of including/dragging the the Graph extension into this topic. The Graph extension was disabled due to issues wrt to vulnerabilities with upstream libraries. This is not something that the WMF can do something about. While the WMF could theoretically somehow commit to maintaining our entire upstream software stack, this is prohibitively expensive to the point that even Google and Microsoft do not tend to do this. The approach that the Wikimedia Foundation is currently taking is that of sandboxing libraries is notoriously hard to do correctly, as evidenced by the gazillions of bugs in Microsoft and Google products that use client-side sandboxing (such as research.google.com and Visual Studio Code) which are still being found and exploited. I think the tardiness in this case, is warranted. Support otherwise. -- Sohom (talk) 14:05, 6 October 2023 (UTC)Reply[reply]
This is because the extension was not updated for several years. All we need is to transition to the newest software versions as all established organizations do regularly Ita140188 (talk) 14:01, 9 October 2023 (UTC)Reply[reply]
@Ita140188All we need is to transition to the newest software versions it is significantly harder to do that than you think, especially in the context of the aging technical debt surrounding the usage of MediaWiki. Porting the Graph extension over to Vega 3,4 or 5 (which I agree would also solve the problem) is a non-trivial task that includes more than just updating version numbers but also making sure that wikitext written for the graph tag using the previous version of the library still works on the newer version even though the abstractions used by the libraries might have radically changed, not to mention that in-case this compatibility is not possible, editors will have to manually check and update each and every instance of the usage of graph tags. Sohom (talk) 05:49, 10 October 2023 (UTC)Reply[reply]
I agree, and that's the point. The lack of investment over many years created this technical debt, which reinforces the case for having more resources allocated to this. We cannot and we should not assume that old versions of software will work forever and no bugs will be ever found. The only way to have functioning software today is to constantly update it, and that takes resources. Ita140188 (talk) 07:38, 10 October 2023 (UTC)Reply[reply]
Mild oppose as worded. While I agree with the overall sentiment, "To improve knowledge equity [...] assist established editors" sounds like a contradiction in terms. Reinforcing the existing community might just consolidate the status quo.
I tend to agree with the three premises I see in this statement, namely that:
the most direct way for Wikimedia to improve knowledge equity is to grow and improve our freely licensed projects (more diverse works for a more diverse audience);
our contributor base, while insufficiently diverse, is more diverse than the average media landscape, therefore making the existing contributor base more effective will be a net positive for the world;
the most direct way to make contributors more effective is to look at the existing community and provide them more of the tools they need.
However, those premises are not universally accepted or verifiable. Sure, if you try to improve a specific article like Deforestation in Nigeria you're going to conclude that it's far more effective to message its contributors and give them a few hundred dollars in resources to make further work easier, compared to giving 20 k$ to someone seemingly unaware of the existence of the article. Once you try to do the same across a broader topic like Nigeria or deforestation globally, if you just help the existing contributors it's likely they'll keep doing more of the same. So we need to at least keep an eye on some of our broader goals, such as verifiability, which involve all of our users, including unregistered users.
Which brings me to the specific suggestion included in the proposal. The Wikipedia Library might as well increase inequality, in that it reinforces a relatively narrow base of contributors and contributions based on established/exclusive sources (such as USA-centric publishers or prestige-based research), further amplifying structural bias. The alternative is to invest in more inclusive sources and source providers, which would help all our users get in touch with more diverse sources. An unregistered user who wants to verify a claim from a reference has a much easier job when a link to open access version is provided, or when a preview or digital loan from the Internet Archive is linked. Moreover, such open or semi-open resources help the production of secondary sources by helping library users, translators, researchers, authors, educators. It's relatively easy and low-risk for us to help, as it takes relatively low effort new initiatives or existing initiatives like Invest in Open Infrastructure.
No it's not. Nemo 17:45, 7 November 2023 (UTC)Reply[reply]
Increased support for internal needs (Discussion)
I'm not going to read any of these long-worded points, I started to but am guessing that they (Edit: now have read many of them) ...all comes down to WMF has control of the money gained from touting Wikipedia so of course they owe us anything we want and they should also include the community in almost everything they do. Why not? And more power to WMF in everything. I hope some wonderful billionaires will be giving them (and, in turn, some trickle down to Wikipedia please) $100 million at a pop. Bill Gates, donate a 100 million, or 200, give them a lot, and kindly stipulate that 1/3 of that should go to the projects conceived of and organized by Wikipedia editors. Every year someone else should step up and do this. Taylor Swift, a million would go a long way, and Elon, how about funding Commons to the hilt, create the creation. By the way, VivaWikiVegas could use a few million in cash/and or MGM housing donations to throw the bash of the century for Wikipedia's 25th birthday. As for Editor Expeditions...
For just one of a thousand examples, this is something I literally thought of yesterday. WMF Wikipedia coffers (which should be overflowing with kindness) can send teams of Editor Expeditions out in the field. An individual or a group, say an art editor, a technology editor, a city-specific subject-expert, a few fill-in-the-blank editors, sent or a week or two as individuals or as a team to a city, a nation, to the citadels of a scientific field, to work on article sources, photographs for Commons, meeting with local officials to promote Wikipedia etc. Participation of the local community with the Wikipedia community to give options for growth. A team would have a back-up crew working with them daily, maybe the people who will be leading the next on-site expedition.
Randy, I admire your unselfconsciousness. In your first sentence you call others' contributions "long-worded points" and decline to read them, and then you've written all this.—S MarshallT/C 08:49, 3 October 2023 (UTC)Reply[reply]
Thanks, I learned at my father's knee. In my above comment I was referring to the many varied questions and proposals on this page and the others put up yesterday. Brevity might do all of us a favor, but in this case I've added my comments concerning all of them in one place. Randy Kryn (talk) 14:05, 3 October 2023 (UTC)Reply[reply]
@Deauthorized: On graph extension. The extension is disabled, but there is no lack of attention from the developers. From phab:T334940, the amount of work to be done to fix the extension is... non-trivial, with no direct path to upgrade the underlying engine to the latest version. Just that the conversation isn't happening here, it doesn't mean there is a lack of work. – robertsky (talk) 03:36, 3 October 2023 (UTC)Reply[reply]
Does anyone understand what the plan actually is? If so, what can editors do to help fix broken graphs which presumably need to be edited somehow, e.g., to make them compatible with Vega 5? This is a good example of something that fell apart when a vulnerability was discovered, because there were no staff resources devoted to fixing emergent faults. That does indeed seem like a money allocation deficiency to me. Sandizer (talk) 09:53, 3 October 2023 (UTC)Reply[reply]
I guess so, but it's hard to confirm. After this and that, I still really don't have a handle on what needs to be done at all. Sandizer (talk) 16:22, 5 October 2023 (UTC)Reply[reply]
Does anyone understand what the plan actually is? If so, what can editors do to help fix broken graphs which presumably need to be edited somehow, e.g., to make them compatible with Vega 5?
Hi @Sandizer, great question. The plan is to re-enable the Graph Extension in a sandboxediFrame with a restrictive content security policy. Additionally, we will make the Graph Extension compatible with Vega 5 so that, going forward, all new graphs will benefit from Vega 5's security, accessibility, and syntax improvements. We will also equip volunteers with code and processes that will ease the transition from Vega 2 to Vega 5 when the time for this transition comes.
This is a plan we've converged on through months of conversations with a network of volunteers. Within the next week, you can expect to see a roadmap that details the specific steps we – volunteers and staff – will need to take to make the above happen.
In the meantime, we appreciate how proactive you are, and have been, about asking what you [and other volunteers] can do to help fix the broken graphs.
I recognize that it is likely frustrating to be willing and ready to lend help and for it to not be clear how to do so. I’m naming this potential frustration because it’s important to me that you know it’s something we’re thinking about as we try to strike a balance between re-enabling the extension as quickly as possible while doing so in a way that keeps Wikipedias as a whole safe and secure.
And hi, I'm Peter Pelberg 👋🏼 I work as the product manager on the Editing Team. I'm also responsible for safely and securely restoring access to the information and capabilities disabling the Graph Extension has left people without.
@Sohom. You bet. If any new questions/ideas/concerns emerge as you're thinking about the Graph Extension, please ping me! PPelberg (WMF) (talk) 18:43, 16 October 2023 (UTC)Reply[reply]
It is beyond ridiculous that this problem was allowed to occur and with each passing day it damages Wikipedia's reputation to editors and readers. This is not to criticise the employees working on the issue, but the misallocation of WMF funds that led functionality like the Graph Extension to be neglected for years. The WMF is rolling in money but not spending enough of it on maintaining tech, modernising interfaces, community wishes and so forth. — Bilorv (talk) 19:30, 16 October 2023 (UTC)Reply[reply]
Thank you for the response. I hope that this issue is corrected soon. Deauthorized. (talk) 00:39, 17 October 2023 (UTC)Reply[reply]
@PPelberg (WMF): the roadmap seems ok. 2 points in mind, 1. I think it is also best to involve those who hold the templateeditor user rights and/or actively working on WP:TFD/H queue here on enwiki, if you have not done so, to accelerate the transition over to Vega 5. 2. is there an end date to Vega 2 backport? Will Vega 2 be eventually be decommissioned totally and when? Asking because it will give the community a sense of urgency to move to Vega 5 for the supported graphs in Vega 5, while solutions or workarounds for the unsupported graphs/features either in form of somehow grafting the unsupported graphs or decoupling them to another template, etc. can be worked on. – robertsky (talk) 13:42, 21 October 2023 (UTC)Reply[reply]
@PPelberg (WMF): the roadmap seems ok. 2 points in mind, 1. I think it is also best to involve those who hold the templateeditor user rights and/or actively working on WP:TFD/H queue here on enwiki, if you have not done so, to accelerate the transition over to Vega 5.
Great call, @robertsky. We have not yet contacted the two groups you named above. Although, I've filed T346291 to hold us accountable to doing so.
A clarifying question: were you thinking the communication you described above would happen once the technical components for porting existing graphs to Vega 5 are in place? Were you thinking that communication would happen now? Both? Something else?
…I want to be sure I'm accurately understanding you.
is there an end date to Vega 2 backport? Will Vega 2 be eventually be decommissioned totally and when?
Great questions. I'm going to respond to the second question first…
Regarding the first question you asked – "Is there an end date to Vega 2 backport?" – can you please say a bit more about what you mean by this question? E.g. might you be asking:
1) "When the Graphs Extension is re-enabled, will it support Vega 2-based graphs?"
2) "If the answer to "1)" is "yes," how long after the Graph Extension is re-enabled with support for Vega 2 will Vega 2 support be removed?"
Asking because it will give the community a sense of urgency to move to Vega 5 for the supported graphs in Vega 5, while solutions or workarounds for the unsupported graphs/features either in form of somehow grafting the unsupported graphs or decoupling them to another template, etc. can be worked on.
Understood! I appreciate you sharing the thinking that prompted you to ask the above. PPelberg (WMF) (talk) 23:52, 26 October 2023 (UTC)Reply[reply]
were you thinking the communication you described above would happen once the technical components for porting existing graphs to Vega 5 are in place? Were you thinking that communication would happen now? Both? Something else?
For a wider participation, the communication can happen when the components are in place for the migration, hopefully with clear instructions on how to use the tools, which I assume to be at the end of Phase 2? My thoughts are that with clear instructions, at least of the simple charts, any editors can change the charts without much assistance, and for the more complex ones, the experienced template editors, with respect to Charts extension, can quickly work on doing up a suitable replacement based on these instructions, other prior experiences, and/or creativity.
With respect to the end date question, it is was asked under the assumption that Vega 2 will be enabled in a safe manner in the meantime. So yes, your clarifying 2-part questions is correct. – robertsky (talk) 03:21, 27 October 2023 (UTC)Reply[reply]
And presumably if the WMF allocated more resources to it, that work would get done faster? That's how work usually works, anyway. More importantly, with more resources, we can hope that there won't be more extensions in the future that just get forgotten about for six years, causing blow-ups like this. – Joe (talk) 13:21, 4 October 2023 (UTC)Reply[reply]
Exactly. This is the result of underinvestment and neglect for many years, and something that was entirely predictable Ita140188 (talk) 19:11, 11 October 2023 (UTC)Reply[reply]
Hard to say if throwing more developers at this stage for the Graph extension is going to make the work get done faster. But definitely will be helpful to have more developers/eyes to look into other extensions, being used on all projected hosted on the Foundation's servers, neglected or not. At the very least sort out a priority list based on criteria such as security or feature gap, etc. for future development. – robertsky (talk) 10:29, 16 October 2023 (UTC)Reply[reply]
What Robertsky said. There are thousands of us who remember the early WMF having the total staffing of what is today the staffing of the smallest team in the Product & Technology sphere. There are thousands of us who remember hours-long and even occasionally days-long downtime. I can still remember the time there was nobody officially "on call" for keeping the site up, and one of the few capable individuals actually had to deplane just before take-off in order to get Wikipedia back up. (And never did get reimbursed for their missed vacation.) We cannot be complaining about the WMF spending too much money on staffing and benefits while at the same time complaining that there aren't enough staff to do everything. The technological debt is significant (although being worked down). Part of that debt comes from extensions built by volunteers years ago that managed to get into MediaWiki core, only to have the maintainers leave. We may have to give up some extensions that are difficult or impractical to maintain, or consider other ways of doing certain things. But that would mean change, and we all know how Wikimedia communities respond to changes.... Risker (talk) 04:32, 3 October 2023 (UTC)Reply[reply]
"We cannot be complaining about the WMF spending too much money on staffing and benefits while at the same time complaining that there aren't enough staff to do everything." True, but it's almost inevitable that growing organizations will eventually lose focus on some if not most of their core needs, resulting in too many people and not enough vital work being accomplished. Sandizer (talk) 10:06, 3 October 2023 (UTC)Reply[reply]
I object to Wikimedia Foundation staff hired to do things best done by the non-technical community, including convening conversations on ethics and values, doing outreach, and community organizing. I support Wikimedia Foundation hiring technical staff for code development. The coders are not the ones who find themselves in conflict with the community. The staff who speak on behalf of the Wikimedia community and for the Wikimedia community frequently do. Bluerasberry (talk) 14:36, 3 October 2023 (UTC)Reply[reply]
Perhaps you should ask the technology staff this. When I sit with developers, they point to the differing expectations between communities, and the disproportionate entitlement of English Wikipedia, as major issues. They aren't here to build English Wikipedia, they're here to support 800 projects, all with different needs and demands. Those staff you're worried about were brought in to act as buffers between the very demanding individuals in many communities, and the developers who (as a group) are quite conflict-averse. When it used to be the developers talking to communities, they were pilloried, too. Risker (talk) 18:10, 3 October 2023 (UTC)Reply[reply]
That's a really insightful point, which is in some ways at the crux of this: what amount of entitlement is appropriately proportionate for the English Wikipedia? About half of the 820 Wikimedia projects appear to have fewer than 20 active editors. I'll not touch on revenue or mindshare / reputation. That acrimony is best handled elsewhere. I will say that Community Wishlist items are often unfulfilled, which affects all projects, and the priority of the survey results is already determined by devs, so they're free to rebalance to help serve smaller communities disproportionately to their sizes.Do the dev teams not want more crew? I understand there's a point in software engineering where throwing more people at a problem loses effectiveness, but we're hardly close to that point. Folly Mox (talk) 21:11, 3 October 2023 (UTC)Reply[reply]
I guess I'm not seeing anywhere in the proposed resolution where it recommends cutting staff positions that are ancillary to development and maintenance in order to pay for the proposed new technical positions.In any case though, I think I misunderstood Risker's Perhaps you should ask the technology staff this as something more general than a reply to the sentence directly above it. Folly Mox (talk) 01:16, 4 October 2023 (UTC)Reply[reply]
[Developers] aren't here to build English Wikipedia, they're here to support 800 projects, all with different needs and demands. Then it'd be great if the WMF would hire some devs to work specifically on the English (and other large) Wikipedias, given that we're its flagship project and bring in the lion's share of the money used to support the rest of those 800 projects. – Joe (talk) 13:18, 4 October 2023 (UTC)Reply[reply]
Hi all - I’m Sam Walton, the Product Manager for The Wikipedia Library (and now Moderator Tools). I saw increased support for The Wikipedia Library was mentioned in this RfC so I wanted to jump in to share some information about how we grow the library and what we’ve been doing recently. First, some good news - The Wikipedia Library continues to grow, with 12 new partnerships in the last year and numerous collections renewed or moved to more seamless methods of access. We also recently hired Vipin SJ as a dedicated partnerships manager, so for the first time we have someone solely focusing on growing the amount of content available through the library. This has really helped us be more comprehensive and committed in our approach - I’ve worked on the library for something like 8 years now and I think the program is currently in the best place it’s ever been.
Acquiring new partnerships to expand the available content in the library can be a slow and frustrating process, but usually not because of a lack of capacity on our side. We’re building the library through no-cost partnerships, and this isn’t a proposal publishers are accustomed to evaluating. Unlike with sales, they don’t have teams ready to field these requests and simply action them. Getting a new partnership is a process that starts with getting through to someone at the organisation who is in the right position to understand what we’re asking, usually involves multiple meetings to explain the partnership model, answer their questions, and assuage their concerns. We then need to agree on how access will be provided, and often need to get legal teams involved to review and sign agreements. Although this is all fairly rote to us at this point, and we have dozens of conversations on the go simultaneously, during this process it’s very common for the publisher to lose interest or to spend a lot of time in long discussions around the details (we signed with Wiley about 1.5 years after our first contact with them!). Once we’ve got a partnership signed and content is available to editors, we then need to keep the partner up to date and engaged with the program, so that if we need something from them, we won’t be disappointed to discover, for example, that our contact no longer works there. The reason I’m laying all this out is to explain that although this requires effort from our side, the bottleneck in this process is usually the organisations we’re dealing with.
I also wanted to be candid and note that we shouldn’t lose sight of how much content is already available! We regularly hear from librarians from around the world who are jealous at the range and volume of content we have available in The Wikipedia Library today, because it would simply be unaffordable for them to subscribe to it all. We did a back-of-the-envelope calculation and if the WMF was directly paying for all the subscriptions for the library, for the tens of thousands of users who qualify to use it, the total cost would come out to something like the entire current Wikimedia Foundation yearly budget! All this to say, although - obviously - I appreciate the message you’re sending here about how valued the library is, I personally think we’re already dedicated to growing it and making it as broad in its coverage as possible.
If you want to help us prioritise our partnerships, we have a suggestions page where you can add or upvote content suggestions. It’s not been obvious where these suggestions go historically, so we’re actively trying to do a better job of linking these to corresponding Phabricator tickets, where we’ll post updates on our progress, so you can subscribe to tickets to learn more about how things are going with any particular organisation. If you want to stay up to date with new content available through the library you can also sign up to our newsletter. I also just want to take the opportunity to quickly note that in my capacity on Moderator Tools I created Wikipedia:Moderator Tools/Automoderator to provide opportunities for en.wiki input into our team’s current project.
This message turned out a lot longer than I anticipated, but I hope it's a helpful overview. Happy to answer any questions you have about the library or anything I wrote above. Samwalton9 (WMF) (talk) 09:03, 13 October 2023 (UTC)Reply[reply]
@Levivich Instead of directly paying for content subscriptions like a typical library, we have agreements through which they provide us access for free. They see benefits from the partnership (more editors citing their content on one of the most popular websites in the world), and so we're usually able to convince them that it's in their interest to go down this route rather than charging us money. Samwalton9 (WMF) (talk) 15:30, 13 October 2023 (UTC)Reply[reply]
Sam, I just want leave a drive-by kudos for the entire TWL team. I'm not privy to the internal details, but having worked on partnership projects like this before, I can only imagine how chaotic this is. Every partner has its own rules, its own API, its own licensing quirks, its own level of commitment, its own level of technical (in)competence, its own collection of demonstrably stupid and broken things that it insists must happen. Am I close? While I often rant about how clunky some parts of the system are, I recognize the heroic job you folks are doing and the incalculably huge benefit TWL provides to wikipedia editors. Thank you. RoySmith(talk) 15:56, 13 October 2023 (UTC)Reply[reply]
Extremely well-put, Roy. ♠PMC♠ (talk) 17:35, 13 October 2023 (UTC)Reply[reply]
The library is the best development, by far, in my 17+ years of editing Wikipedia. Thanks to everyone who works on it. Espresso Addict (talk) 01:04, 15 October 2023 (UTC)Reply[reply]
Suggestion for TWL: Libraries buy licenses for digital versions of books they can lend to patrons. Consider a trial program to do the same for the TWL. Considerations:
Start with a small number of the most requested items and buy them.
Require a brief explanation from the borrower why they want to check out the resource. It could be a simple one sentence note such as: "I am writing articles on Albanian military battles in the 15th century".
To prevent hoarding, if a book is not returned by the return date, cancel the loan (if that's technically possible)
Use volunteers (editors) as gatekeepers, at least on this Wikipedia to save aggravation and distraction for WMF staff. Maybe someday WMF would fund a full time librarian but let's crawl before we walk.
Before checking out more books in the future, ask borrowers to point to work they did with their first loan. Again, a simple sentence or a few diffs would suffice.
Hi everyone – I’m Marshall Miller; I’m a Director of Product at WMF. I work with many of the WMF teams that build and maintain editing and reading experiences, including the Editing team, which is taking point on the Graphs extension, the Moderator Tools team, which operates The Wikipedia Library (please do check out the responses from Peter and Sam on those topics above), and other teams like Web, Mobile Apps, and Growth, each of which maintains parts of the software that I’m sure many of you use.
I’d like to address some of the overarching concerns raised in this RfC discussion about the foundation’s level of investment in technical infrastructure and software. I’ll explain below how we’ve made a deliberate shift this year to focus on the needs and ideas of experienced editors, but I know that even with that shift, it can continue to feel like key tools and features are neglected. I understand that feels demoralizing, and can lead to editor burnout. I can say that we’re striving to address that directly through how we spend our resources, and I’m hoping you all will notice the results in the coming months.
So to explain a bit how we’ve prioritized and budgeted this year – the product and technology area is the largest area of focus (both in terms of staff and budget allocation) at WMF. Much of that allocation is toward what we call “essential work” – which refers to the sort of maintenance, monitoring, upgrading, and fixing that keeps our sites running at a fundamental level and across hundreds of languages, including data centers, security, databases, etc. I know most everyone here knows that that kind of work is essential, even though much of it takes place behind the scenes.
Then there are the strategic parts of our work, which is about making substantial changes to how the software works. That work is laid out in this year’s annual plan. You can see that it says that this year, the Foundation’s plan is recentered around Product & Technology, and that we are prioritizing established editors over newcomers. We’re doing this because we know that the wikis depend on the most active volunteers, and that those volunteers have an outsized positive impact on the content. How we’re doing this is expanded upon on this page about the “Infrastructure” parts of the plan, and you can find further detail by following links on that page to the specific objectives and key results, and further detail on the budget here and here. It’s worth noting that the foundation committed to these priorities even while slowing overall budget growth for the foundation as a whole. And we’ve shared that these priorities are intended to be multi-year - meaning that this strengthened focus on our technical needs is meant to be the driving priority for the Foundation’s budget and plans in coming years.
I’d like to lay out some examples of outputs and upcoming priorities from the teams I work with, which I think show the current focus on experienced editors. These projects are all based on ideas and requests coming from experienced users, and are geared toward helping them have more efficient workflows, helping them be able to spend their time on the most important wiki work, and have control over how features are used on their wikis. If those don’t sound like the right priorities for experienced editors, we definitely want to hear how you see it. I think it’s also important to note that for each initiative in this list, knowledgeable and interested community members have been involved in the planning and design throughout – this helps us make sure that the plans to invest in experienced editors’ workflows will actually make a difference to them.
New Pages Patrol / PageTriage: after the open letter from new page patrollers about the PageTriage software, the Moderator Tools team worked with patrollers to modernize the software so that future improvements and bugs can be much more easily addressed. The new version of PageTriage entered production this past week.
Discussion Tools: over the past year and a half, the Editing team has rolled out the many parts of the “Discussion Tools” project, which added the “reply” button on talk pages and the ability to subscribe to specific threads on a long talk page, among other features to make it efficient to engage in conversation on the wikis. About 2.6 million edits have been published with the reply button, with 79% of those being made by users with over 100 edits. And for newcomers, data analysis has shown us that these tools have increased the quantity and quality of the comments they make on talk pages.
Dark mode: having a “dark mode” for Wikipedia has persistently been a top wish in the Community Wishlist, and it is prioritized in this year’s annual plan and currently under development, along with the ability for readers and editors to choose their preferred font size. We’ve heard from many community members that these changes will make both reading and editing Wikipedia a more comfortable and accessible visual experience.
Patrolling on Android: the Mobile Apps team is building a way for patrollers to easily patrol edits from the Android app, meant to give patrollers more options and opportunities to do their wiki work on their mobile device.
Watchlist on iOS: the Mobile Apps team introduced the watchlist on the iOS app this past week, which gives experienced editors a new way to monitor important pages from their phones.
Edit Check: we’ve heard from many experienced users and wishlist proposals that software could help prevent or improve low-quality edits from newcomers, which experienced users then have to correct or revert. To address this, the Editing team is building “Edit Check”, which is going to start out by automatically warning newer editors when they have added information without a reference, encourage them to add a reference, and then check whether their reference comes from a dubious source. This is meant to decrease the burden on patrollers while also teaching newcomers how to add reliable information. As of this past week, Edit Check is now being tested on several small pilot Wikipedias.
Automoderator: English Wikipedia and some other large wikis have benefited tremendously from bots that automatically revert clear vandalism, like ClueBot NG. This takes a major burden off of patrollers and frees up their time. The Moderator Tools team is working to bring that capability to other language wikis that don’t currently have any of those sorts of bots, so that their patrollers can also focus on more challenging problems.
Community Configuration: when WMF builds features, it is common that different wikis want the feature to work in different ways. We want experienced volunteers who know their wikis well to have control over how a feature works on their wiki – instead of WMF being the sole keepers of that control. The Growth team is building Community Configuration, which is a way for administrators to specify aspects of how a feature will behave for all the users on that wiki. This is currently implemented for the Growth features, allowing English Wikipedia administrators to specify, for instance, which sorts of edit suggestions newcomers receive. With the work being done here, administrators will be able to similarly configure many of the other features listed above, like Edit Check and Automoderator.
Commons Upload Wizard: among multiple community concerns being addressed around Commons are upgrades to the upload wizard. These upgrades will help newcomers load content appropriately to Commons, guiding them toward making the right designations about licensing so that Commons patrollers can more accurately make deletion decisions.
That list touches on some of the projects specifically geared toward experienced editors, and does not include items addressed through the Wishlist process (more updates to come on how that process is evolving to better meet community needs). I hope that many of you follow along with the above projects in which you’re interested so that you can weigh in and help guide them.
How does this all sound? Does this approach make sense? What thoughts or concerns do you have about the work or the prioritization? -- MMiller (WMF) (talk) 04:55, 23 October 2023 (UTC)Reply[reply]
Hello, I’m Runa Bhattacharjee, Senior Director of Product for Languages and Content Growth. I oversee the Community Tech team, which runs the annual Community Wishlist Survey. I am based in India.
The wishlist is an important avenue for the Foundation to understand and address the technical needs of volunteers. While the Community Tech team is tasked with a prioritized list of wishes during the year, they are not the only team who supports this work. More than 20 teams across our Product and Technology department support the wishlist process right from evaluating the incoming wishes, providing technical input, responding to dependent technical debt, infrastructure support, and various kinds of reviews. These teams also work on wishes and provide maintenance work for completed wishes as a core function of their roles. Periodically, the teams also gather (virtually) multiple times a year for dedicated wish completion sprints. Going forward we would like to do a better job of highlighting how editors' priorities expressed through the wishlist make it to teams across the Wikimedia Foundation.
To give you a few examples of recent work done through this setup:
Auto-save feature now known as Edit-Recovery Feature that saves wikitext and other edit form information while typing, and allows for restoring it after the browser has been accidentally closed, or a power or network outage or browser crash.
Realtime preview that allows users using the 2010 wikitext editor to preview the page in real time when editing.
Rewrite XTools - a project to update and maintain XTools, the wiki curation and moderation tools originally developed by User:X! and rewritten by User:Hedonil.
Watchlist Expiry that allows users to watch pages for a limited period of time.
Recently at Wikimania I heard from volunteers their appreciation and support for the community wishlist survey process. At the same time some voiced their frustration and concerns about the process the way it is now.
Advanced editorial role responsibilities are growing across languages, regions, and affiliate needs. Besides a growth in volume of technical issues, there is also an increase in the technical complexity in the issues that the editors are bringing to our notice. It is important that we help connect the dots and make the necessary improvement within the Wikimedia Foundation so that editors' priorities expressed through the wishlist make it to formal priorities listed in our annual plan to make sure they are resourced and tracked more impactfully.
We have begun a process to improve and redesign the wishlist survey, with the objective to have an effective response system in place for the technical requests we know are of high importance like critical editor workflows. In the coming weeks, I’ll be sharing more information about how the wishlist will evolve.Runa Bhattacharjee (WMF) (talk) 18:35, 2 November 2023 (UTC)Reply[reply]
Procedural query If proposals 1 and 2 pass, would they pass with the wording The English Wikipedia community is [...], because frankly ~40 in favor with ~20+ opposed is not representative of the English Wikipedia community (at least of those who are participating here) especially when compared to the overwhelming support in favor of proposal 3. Curbon7 (talk) 02:30, 25 November 2023 (UTC)Reply[reply]
My understanding is yes; while the support isn't as extensive as for #3, approximately twice as many editors support #1 and #2 as oppose it and so in my opinion it is still appropriate to say that the English Wikipedia collectively - though not unanimously - supports this position.
For a different example, we still say that the Arbitrators are elected by the English Wikipedia Community, even though some receive less than 2/3rds support. BilledMammal (talk) 03:39, 25 November 2023 (UTC)Reply[reply]
Correct. Although this does also highlight the fact that we may need to make this page more accessible to editors in general - My first year at wikipedia, I dont think I even knew this page existed. If you look at the discussion above, the experience amongst editors is much higher than what would be typical of wikipedians - Which can be a benefit and a hinderance both. Captain Jack Sparrow (talk) 13:06, 25 November 2023 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Post-close
A small note of elaboration. I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition. I have not stated whether this is supported by English Wikipedia, and the absence of reference to the Wikipedia community in the closure statement should not be seen as summarising the discussion. There is clear support that this discussion page supports these resolutions, with the third resolution being supported especially strongly.
The English Wikipedia community is concerned about the distribution of grants related to activity on the English Wikipedia that will either not contribute to our goals of building an encyclopedia or will actively hinder those goals. We request that the Wikimedia Foundation informs the English Wikipedia of all non-trivial grants that will result in activity on the English Wikipedia through the opening of a discussion at the Village Pump (WMF) prior to the grant being issued.
The English Wikipedia community is concerned that the Wikimedia Foundation has found itself engaged in mission creep, and that this has resulted in funds that donors provided in the belief that they would support Wikimedia Projects being allocated to unrelated external organizations, despite urgent need for those funds to address internal deficiencies. We request that the Wikimedia Foundation reappropriates all money remaining in the Knowledge Equity Fund, and we request that prior to making non-trivial grants that a reasonable individual could consider unrelated to supporting Wikimedia Projects that the Foundation seeks approval from the community.
The English Wikipedia community is concerned that the Wikimedia Foundation has neglected critical areas of the project, and that continued neglect of these areas may endanger the project. To improve the resilience of the project, we request that money be reallocated to hiring more technical staff, whose role will be to fulfill requests from the community such as those expressed on the Community Wishlist, as well as restoring access to tools such as grapher extension. To improve knowledge equity we also request that that the Foundation provides funding to assist established editors in accessing the resources they needto improve the encyclopedia, such as by increasing the number of libraries accessible through the Wikipedia Library and by giving micro-grants for the purchase of backlogged items at Resource Request.
I'm still quite peeved that statement 2 directly targets the KEF for liquidation. It just seems unproductive to phrase it that way, which is a shame because the first portion of statement 2 raises a solid point regarding the apportionment of WMF funds. All I'm saying is it would have been far more productive to request that the WMF focus on WMF projects first for funding rather than just saying "Nuke it!!!!". Curbon7 (talk) 18:02, 24 December 2023 (UTC)Reply[reply]
The resolutions can be amended by consensus as well. Onetwothreeip (talk) 21:50, 24 December 2023 (UTC)Reply[reply]
For clarification, I'm not just whining because my position did not achieve consensus. I am well-aware that my support of the KEF is a minority position here on en.wp. I'm just trying to say that there is a more tactful way to word that statement. Curbon7 (talk) 05:37, 25 December 2023 (UTC)Reply[reply]
@Onetwothreeip, I'm concerned regarding the lack of coverage regarding opposition for the resolutions in your close. Please consider amending it to be more detailed in summarizing the discussion rather than only providing a broad result. Additionally, I see in the discussion that while there is a numerical consensus for the resolutions, there are also quite reasonable arguments opposing it. I encourage you to weigh the content of the discussions rather than merely the quantitative !votes. (involved) — Frostly (talk) 04:39, 25 December 2023 (UTC)Reply[reply]
I believe I have implied that there was more opposition to the first and second resolutions than there was to the third resolutions, without giving undue weight to that opposition. I have been purposefully concise to avoid amplifying any particular arguments.
Regarding the opposition to the first two resolutions, I could not find any objective reason to weigh the minority view disproportionately in its favour. There is much less scope to weigh the minority view greater than the majority view in a non-editorial discussion such as this, where editing policies don't apply. As a neutral closer, I cannot find (or should disregard) that one argument is subjectively or arbitrarily better than another, though I do not mean to suggest that I think you are saying I should. I can add the underlined to the closure comment. Onetwothreeip (talk) 06:04, 25 December 2023 (UTC)Reply[reply]
Wait what? (involved): 1. I thought this closed like two months ago? 2. I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition is the least best closing rationale I've seen outside AfD. Folly Mox (talk) 04:48, 25 December 2023 (UTC)Reply[reply]
It did close a while back, was reopened, and then archived without close if I remember correctly. And now reclosed. Captain Jack Sparrow (talk) 05:07, 25 December 2023 (UTC)Reply[reply]
I closed it and the close was overturned. Honestly this RfC is so stale I doubt the WMF will draft a response to it. Mach61 (talk) 05:25, 25 December 2023 (UTC)Reply[reply]
There is simply not much more to say. There is greater support for the three resolutions than opposition, not only in number but in relative weight as well. I have elaborated above that there is a lack of any compelling reason to give disproportionate weight to the minority view, rather than a reason to not do so. Onetwothreeip (talk) 06:11, 25 December 2023 (UTC)Reply[reply]
I could have been a lot kinder in my characterisation of your closing rationale, but what about identifying common themes, subtopics, and rationales? I thought a close was supposed to summarise the discussion. See example. Folly Mox (talk) 07:09, 25 December 2023 (UTC)Reply[reply]
I appreciate that discussion closures can be longer, but I did not feel it was appropriate in this case to summarise the points of the discussion. Unlike closing a discussion for an editorial dispute, determining the reasons for the consensus wouldn't provide further editing guidance. The unusually lengthy closure comment in your example helps editors contribute to the article further than the direct question being discussed. There is not much more to summarise this discussion than editors choosing to support these resolutions, and I aim to avoid expressing an opinion on which reasons are good or bad. I would encourage anybody to summarise the arguments of the discussion. Onetwothreeip (talk) 07:53, 25 December 2023 (UTC)Reply[reply]
I think for long RFCs, long closes are better. Part of a good close is summarizing the discussion. The participants need to feel like you read everything and understood it, and enough of the closer's thought process needs to be disclosed to make the participants feel like the close is within closer discretion. –Novem Linguae (talk) 11:40, 25 December 2023 (UTC)Reply[reply]
Summary: Resolutions supported due to discussion participants' concerns over Wikimedia Foundation funds being provided for non-encyclopaedia initiatives, funding of activities which cause article quality issues requiring editors to resolve, lack of notice to the community regarding grants being awarded, and desire for technical upgrades to Wikipedia. Onetwothreeip (talk) 01:37, 26 December 2023 (UTC)Reply[reply]
I have determined that the Wikipedia Village Pump has issued the three non-binding resolutions, due to the support of discussion participants outweighing opposition. I have not stated whether this is supported by English Wikipedia, and the absence of reference to the Wikipedia community in the closure statement should not be seen as summarising the discussion.
I find this a little confusing - it makes it unclear to me how the support of the Wikipedia community could ever be determined, if a CENT-listed RfC in the Village Pump is insufficient to do so. I think it would be helpful to close this as we would any other global discussion; simply stating whether this or isn't a consensus, without making the consensus limited to a specific area that doesn't reflect the true scope of the discussion.
Would you be willing to update the close to do so? BilledMammal (talk) 03:54, 30 December 2023 (UTC)Reply[reply]
It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation. There have been discussions and votes on Wikipedia with hundreds of supporters (38, 45 and 78 supporters for these three resolutions). I found consensus for these resolutions, but there is not enough to say that the Wikipedia community supports the resolutions directly. Instead, it can be said that the Wikipedia Village Pump believes that English Wikipedia should issue these resolutions. I am willing to update the close to describe that this is not limited to a specific area, but neither should it be implied that it is unlimited. Onetwothreeip (talk) 05:04, 30 December 2023 (UTC)Reply[reply]
I am willing to update the close to describe that this is not limited to a specific area, but neither should it be implied that it is unlimited.
Can you specify how you would update it?
It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation
In the past, a CENT-listed RfC at the village pump that comes to a consensus on the question asked. Can you clarify on what basis, and what policy or guideline supports that basis, that lead you to decide that it was insufficient in this case? BilledMammal (talk) 05:41, 30 December 2023 (UTC)Reply[reply]
It can be described that the consensus is not necessarily limited to this talk page, but the closer can't determine the extent of the consensus beyond what they can see in front of them. I did not decide that anything was insufficient in this case and I made no decisions about how the Wikipedia community feels. The close was purely regarding how this talk page feels. Onetwothreeip (talk) 23:26, 30 December 2023 (UTC)Reply[reply]
It was listed on T:CENT and had at least 78 participants. I do not think that saying It is certainly unclear how the support of the Wikipedia community can be determined, without far greater participation is accurate. To request any higher sets the bar way too high, to a number that is unachievable, imo. This was, by all measures, a well-attended RFC that was advertised in all the places necessary to make it a community-wide consensus rather than a local consensus. –Novem Linguae (talk) 00:42, 1 January 2024 (UTC)Reply[reply]
@Onetwothreeip: I agree with Novem Linguae here; I think your close was broadly appropriate, except where you try to say that there was only a local consensus; I don't believe that such a statement is supported by policy. Would you be willing to adjust your close, or failing that revert it and allow another to close? BilledMammal (talk) 15:17, 4 January 2024 (UTC)Reply[reply]
Well I don't say that it's only a local consensus, it just can't be determined how broad the consensus is. If the resolutions had a thousand supporters for example (rather than thirty-eight), it would be much easier to determine a project-wide consensus. I could add this detail to the closure comments. Onetwothreeip (talk) 21:17, 4 January 2024 (UTC)Reply[reply]
I feel like if you believe this, you should close the entire RfC as no consensus. That's generally what closers have done when they feel a higher quorum is necessary to justify changes. Mach61 (talk) 05:44, 30 December 2023 (UTC)Reply[reply]
I don't believe that a higher quorum is necessary. There is enough consensus here to determine that the Village Pump supports these resolutions. Onetwothreeip (talk) 23:28, 30 December 2023 (UTC)Reply[reply]
The difference between this and other RfCs is they don't explicitly claim to speak on behalf of the entire website/community. There have been very few other RfCs along those lines before, and they've more often been styled more like an open letter, or have gotten more support than these got (e.g. the SOPA/PIPA blackout). I'm involved, of course, but it does seem like a good point that if the RfC is framed as speaking for the entire Wikipedia community, it's setting itself up for failure because it would need a high degree of participation to be justified. Even if it's listed at CENT, if only a small number of people support something it's hard to close as consensus on behalf of the entire site. IMO the discussion didn't need unarchiving and closing. The WMF has certainly already seen it, has seen that there was more support than opposition, and has seen the arguments on both sides. — Rhododendritestalk \\ 15:37, 30 December 2023 (UTC)Reply[reply]
Wikimedia's financial health
Wikipedia:Wikipedia Signpost/2023-11-20/News and notes has a update on Wikimedia's financial health, including an audit report for FY2022–2023. Income is up $25m at $180m. Expenses are up $23m at $169m, including salaries up $13m to $101m and hosting up $0.4m to $3.1m. Certes (talk) 11:35, 21 November 2023 (UTC)Reply[reply]
Proposal: add user-defined Common edit summaries to Preferences
I'd like to propose an enhancement to Preferences to add a feature enabling a user to enter a list of their own commonly used edit summary phrases, and then present them in the "Common edit summaries" dropdown that appears in Preview mode below the Edit summary input field.
In my case, I rarely use any of the potted ones, but I do have ones I use all the time, and this would be a real productivity enhancement. Probably one set per namespace to match current dropdown functionality, but just implementing mainspace would be a good start. (If I had my choice, I'd have the offerings be additive, i.e., organized as checkboxes, or permit multiple choices in the dropdown via Ctrl+select so I could assemble my edit summary by picking several, but this is probably a separate proposal.) Extra credit: in Preferences, if my custom edit summary list is empty, then prepopulate it grayed out with my top ten summaries in my last 500 edits (or top seven, as mainspace common summaries dropdown length is now). In the Preview mode dropdown, place user-defined list at the top, and if not fully filled out, then fill in remaining slots below from the potted summaries. When the cheers die down, extend to other namespaces. Mathglot (talk) 23:28, 21 November 2023 (UTC)Reply[reply]
Does your browser not save them for you? Firefox does for me, so all I need to do is start typing and then select from the options FF gives me. Nthep (talk) 14:22, 22 November 2023 (UTC)Reply[reply]
Editting the desktop site via mobile and the keyboard does all this for you, including narrowing selection based on what has already been typed. Most of my summaries take no more than two or three taps. -- LCU ActivelyDisinterested«@» °∆t° 20:45, 22 November 2023 (UTC)Reply[reply]
I use section edits almost exclusively (for many reasons, including ease of use, faster, fewer ec's, etc.) and the browser suggestions have to match from the very first character. For this section, it has to match /* Proposal: add user-defined Common edit summaries to Preferences */ which means there aren't any, except for my OP and further edits here. Same thing in, say, Mainspace or User talk space, where this feature would be really handy, and where browser suggestions help barely at all. Mathglot (talk) 00:32, 23 November 2023 (UTC)Reply[reply]
Copy and pasting are also easier on mobile. I cut the section details get the summary I need, and paste the section details back at the front. -- LCU ActivelyDisinterested«@» °∆t° 20:35, 23 November 2023 (UTC)Reply[reply]
Wikimedia Foundation banner fundraising campaign on English Wikipedia starts next week
Dear all,
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 28th of November to the 31st of December 2023.
Thank you to everyone who has worked together to prepare the campaign this year! We’ve built up the collaboration process this year on the community collaboration page, at in person events (e.g. Wikimania and WikiCon North America), and in other individual discussions. More information around the campaign, like example banners and messaging, can be found on the community collaboration page. We continue to welcome ideas on the page.
Some more resources around the fundraising campaign:
It's starting now? Then why have we had banners up for a month or so? There have been complaints here and at the Teahouse. Edward-Woodrow (talk) 19:04, 26 November 2023 (UTC)Reply[reply]
Many thanks for all your hard work this year, for both you personally Julia and the entire team. Best, KevinL (aka L235·t·c) 07:35, 29 November 2023 (UTC)Reply[reply]
Another complaint
Another IP user (1.157.92.55 has complained about the advertising banners, this time at AN:
If the donations were ACTUALLY going to the editors who make this website, I would pay. But no, that money goes towards the Wikimedia "Foundation" and their ludicrously overpaid executives. Why can't they just relinquish some of their salary? WHY do you act like Wikipedia will fail without these donations? You DON'T need that money for servers so stop acting like you do. It's absolutely pathetic, sleazy, and utterly dishonest. I don't CARE about Wikimedia's projects, I ONLY care about Wikipedia, and if I'm going to be paying money, that money should be going to the ACTUAL users who create this website, not a bunch of overpaid bourgeoisie "staff" who accomplish absolutely nothing.
Absolutely disgusting. And the INSISTENCE is utterly obnoxious - EVERY time I load a Wikipedia page your misleading begging loads up top and forcibly scrolls upwards to the top. Enough is enough. STOP LYING
And honestly, I don't entirely disagree with them, although I wouldn't put in those terms. Cremastra (talk) 01:12, 16 December 2023 (UTC)Reply[reply]
I am sorry that readers are upset and I also wouldn't have used those words, but the comment does match my own reasons for not donating money. I am glad that at least one potential donor is clearer about how donations are spent, and thus able to make an informed decision about giving. Certes (talk) 19:51, 16 December 2023 (UTC)Reply[reply]
"The CEO of the most important website in history [Wikipedia] makes $790,000. The CEO of Docusign, a company that JUST signs documents for you, made $85,940,000 this year," I believe top positions should be compensated well. And 790k is only less than 1% of 85 million. It is a reasonable salary. Also, I suggested the fundraising ads, in line with the ads of The Guardian. After all, we don't want Wikipedia to be taken over by commercial ads in a bid to raise funds. Ads that come with demands of undue censorship and bias. Regards, Thinker78(talk) 03:55, 16 December 2023 (UTC)Reply[reply]
I have been quite critical of WMF fundraising practices in the past, but that rant is unhinged and amounts to trolling. I do not think that it should be taken seriously. Cullen328 (talk) 20:04, 16 December 2023 (UTC)Reply[reply]
I think he means the original post. The pay rates shown on twitter amounts to a storm in a teacup. They are quite low for the positions. Maybe other spending could be criticised, but not that. -- LCU ActivelyDisinterested«@» °∆t° 17:16, 19 December 2023 (UTC)Reply[reply]
One interpretation is that, although top WMF staff each have a reasonable salary, there are too many managers and too few lower-paid staff assigned to more visibly useful tasks such as fixing bugs. Certes (talk) 22:39, 25 December 2023 (UTC)Reply[reply]
The proliferation of middle management is the bane of all large organisations, I'm sure the WMF is no different. -- LCU ActivelyDisinterested«@» °∆t° 22:56, 29 December 2023 (UTC)Reply[reply]
There is no risk that Wikipedia will ever be forced to carry commercial advertising, even if literally all fundraising were completely stopped for multiple years. jp×g🗯️ 11:12, 28 December 2023 (UTC)Reply[reply]
This rant demonstrates a lack of understanding regarding the volunteer nature of Wikipedia. As well, see grants. — Frostly (talk) 22:06, 25 December 2023 (UTC)Reply[reply]
I don't think it's clear from the comment whether the IP user understands that Wikipedia is written by volunteers and feels that the consequent cost saving makes requesting donations unnecessary, or if they think we ask for money and are refused. Certes (talk) 22:36, 25 December 2023 (UTC)Reply[reply]
#2 (courtesy of the Teahouse)
Please STOP YOUR ONGOING BEGGING adverts asking for money. If you can’t manage the operation - CLOSE IT DOWN & go away - Stip ruining our experience 👎😡👎😡👎 2A00:23C4:D0F:1D01:9C29:17CA:2F74:C7EF (talk) 07:58, 20 December 2023 (UTC)
Is it productive to post these here? This feedback doesn't seem very actionable. –Novem Linguae (talk) 13:32, 20 December 2023 (UTC)Reply[reply]
It's useful to know what some readers are thinking, even if those who feel strongly enough to comment are unlikely to form a representative sample. It's not actionable in that the WMF is unlikely either to stop begging or to close down, but the feedback may be helpful when wording future banners. Certes (talk) 15:53, 20 December 2023 (UTC)Reply[reply]
I agree that continuing to copy these here is not useful. I'm sure the WMF is aware that some people are upset about their fund raising practices, and the complaints embodied in these posts are all things that have been talked about before. These kinds of posts don't add anything new. RoySmith(talk) 16:08, 20 December 2023 (UTC)Reply[reply]
I don't think volunteers should be heat shields for people upset at the foundation's fundraising. So what would the correct way to make sure these complaints are seen by the people they're meant to be seen if not posting here? Barkeep49 (talk) 03:02, 21 December 2023 (UTC)Reply[reply]
I'm not sure that there is any benefit in making unconstructive rants more visible than they are at present. Volunteers are not acting as "heat shields" but more akin to spam filters. If you do think it's important that the foundation see it, then email it so as not to waste more volunteer time by posting it here. Thryduulf (talk) 11:10, 21 December 2023 (UTC)Reply[reply]
VTRS gets loads of emails on similar lines to the posts quoted above. Nthep (talk) 13:21, 21 December 2023 (UTC)Reply[reply]
They could post puppies and kittens are cute, and someone on the internet would have a rant against it. Unless someone posts something useful or interesting I don't see the point, I'm sure the WMF are well aware of their detractors. -- LCU ActivelyDisinterested«@» °∆t° 20:11, 20 December 2023 (UTC)Reply[reply]
"If you can’t manage the operation - CLOSE IT DOWN & go away". So basically they rather have Wikipedia close down rather than see fundraising requests. I think whoever wrote that should simply go away from Wikipedia. Anyways, I suggested the fundraising ads because I read they have been very successful in The Guardian. No idea if it was because of my suggestion they implemented it or not but I support the ads, even though I don't donate money because I have donated thousands worth of my time. Regards, Thinker78(talk) 03:24, 21 December 2023 (UTC)Reply[reply]
I am not against posting these here, it's light tongue-clucking reading, but I think it serves no real purpose. My reasoning is as follows: For most feedback/reviews (think restauarant reviews on Yelp, product reviews on Amazon or your fave website), there's a human tendency to a bivariate distribution: people who loved loved loved it, and people who hated hated hated it; maybe a few just shy of that on either end. But the number of people who take the time to say a restaurant or product was decent, pretty much "met their expectations" is underrepresented, because where's the motivation to sign in, type that all out, and send it? You have to be a real data demon to do that. However, fund-raising is different: no matter how good the objective, nobody writes in to say how excited they were to receive the dunning request from Save the Manatees, or whatever there fave charity is; only some small fragment of the negative cohort bothers to write back, and their reaction is predictable. So, whether there are five posts thundering vitriol about our fund-raising or five thousand, I don' believe there's anything we can learn from it, other than perhaps the timing of when some social media platform posted a link to it, and how much influence they have, and there's nothing much we can do about that. I'm sure the WMF must do some A–B tests on the *wording* of such requests in order to measure the results (on the positive side) no doubt provides useful info, but I'd love to hear whether any A–B tests are done to measure negative reaction of the outraged-flame type, and whether anybody at WMF cares if there is. My guess is 'no' and 'no'. Mathglot (talk) 06:01, 25 December 2023 (UTC)Reply[reply]
Hi all, I'm posting on behalf of WMF's online fundraising team. This is an interesting discussion around a topic we see as both important and challenging for the scale at which we operate: how to measure and ‘weight’ qualitative feedback. We work on it all the time, and we try to take both a human approach, e.g. building relationships through dialog, as well as running A/B tests to detect and improve points of friction.
On the more relational and dialog-based approach: we do rely on valuable feedback from various sources from readers, donors, and volunteers to inform the campaign, and we thank you for passing along more feedback. This year, we've been working with volunteers the past few months on the campaign and appreciate all the time and creativity everyone has brought to the collaboration process. We also recognize the increased volume in messages from readers at this time of year, and have staff dedicated to responding to inquiries who are monitoring our email address, donate[at]wikimedia[dot]org. Please feel free to forward any fundraising related messages to that email address and the team will follow up. We could also discuss having the team assist with responses at the teahouse, if that would be helpful. We welcome ideas for how we can better support volunteers during fundraising campaigns.
In our A/B testing, we often design tests that are aimed at improving user and reader experience, e.g. adding clarity around how to find the close button, improving the flow so that fewer donors get stuck or see error messages, etc.
I agree that online feedback can often swing to the extremes, but it is also true that any feedback contains a kernel of an idea that might lead to positive outcomes for all users. So we try to stay humble and receptive to input. Thank you and happy new year. - SPatton (WMF) (talk) 15:31, 29 December 2023 (UTC)Reply[reply]
Wikimedia Foundation banner fundraising campaign on English Wikipedia ended yesterday
Dear all,
The WMF annual banner fundraising campaign for non logged in users in Australia, Canada, Ireland, New Zealand, the UK, and the US ended yesterday.
We would like to thank all of you whether you collaborated with us on the community collaboration page, or answered questions from readers on the Helpdesk, the Teahouse, or the VRT. Thank you all for your engagement during the Foundation’s biggest banner fundraising campaign of the year and for all your contributions to the projects. Thank you to all the donors who made the campaign a success and support free knowledge.
You can find the fundraising team across on meta if you have any questions or comments.
@JohnWheater would you try to access the link from this page, then try to log on? Be sure you are not blocking scripts or cookies. — xaosfluxTalk 14:38, 28 December 2023 (UTC)Reply[reply]
No, thats the very page that gives the error message when I click login John Wheater (talk) 15:19, 28 December 2023 (UTC)Reply[reply]
I believe that the Echo/Notifications message triggers when you make your 500th edit. WhatamIdoing (talk) 02:58, 3 January 2024 (UTC)Reply[reply]
Thanks for filing the ticket. We're only checking overall edit number and tenure, not the block status or recent edits, as these were harder to engineer and only impact a small number of users receiving the notification. We're unlikely to stop sending to users who are blocked somewhere due to the ambiguities around blocks and our willingness to allow some blocked users to use the library, but recent edits seems feasible to address. Samwalton9 (WMF) (talk) 11:36, 8 January 2024 (UTC)Reply[reply]
Wow, mobile browser editing really is bad
My usual device is not working, so I tried editing off of Safari (I did sign up for the NPP backlog drive, after all). Genuinely unusable. Probably going to take a break until it's fixed. DrowssapSMM 22:41, 2 January 2024 (UTC)Reply[reply]
Calling @Folly Mox, who knows about editing on the mobile site. Unfortunately, there's no central noticeboard or other page where mobile-based editors congregate. WhatamIdoing (talk) 03:00, 3 January 2024 (UTC)Reply[reply]
My experience (as a frequent iPhone user) is that m.wiki is very good for reading pages (better than Vector is on desktop, actually), serviceable for copyediting and projectspace discussions, and very bad for expanding articles (no tools like ProveIt for citations, and switching between the article and the sources is harder with mobile browser tabs). Vector 2010 holds up surprisingly well for editing, seeing as it wasn't mobile-optimized at all, but is a much worse reading experience. Mach61 (talk) 03:06, 3 January 2024 (UTC)Reply[reply]
(responding to ping) I do like the mobile web experience for the most part, and don't really find any part of it particularly burdensome or uncomfortable. I've been a fully mobile editor since the death of my last computer in summer 2022, but I must confess almost complete unfamiliarity with most advanced editing tools. I've never applied for the NPP perm, but having a look at Special:NewPagesFeed just now, it seems essentially identical between Minerva and Vector 2022.There are, of course, some tasks that are more difficult: I can't run two browser windows sidey-side with a source in one and an open editing interface in another, but it is a bit more convenient that I can hold my phone flat against the opposing page of a physical book if I'm using one of those. Most scripts don't support Minerva, so I'll have to hop into desktop view if I want to use Rater or Prosesize or many functions of Twinkle, and the limited RAM of a mobile device has led me to uninstall scripts that have some utility because the additional javascript load times weren't worth it. And of course the input is typically a bit slower on a cell phone keyboard than the usual kind, but the predictive text helps to an extent (I never have managed to figure out swipe typing).Essentially though, genuinely unusable is so nonspecific and unactionable that I don't know what to say or how I could help. This reminds me of another recent complaint at VPI, which suggested the mobile frontend was "uncomfortable" without specifics or further elaboration. That's not a way to get functional help or to suggest software improvements. User:DrowssapSMM, I hope your computer gets fixed soon, but do you have any examples of specific tasks you were unable to complete using your mobile device, and what it was in particular that made them impossible for you? Folly Mox (talk) 12:33, 3 January 2024 (UTC)Reply[reply]
@Folly Mox I edit a lot on an Android phone and find that I keep changing between different interfaces, voluntarily or involuntarily, to get different functionality: If I want to look at an editor's contributions I have to get their user page, opt for "Desktop view" and then look at the contributions list. If they haven't created a user page ... I have to find something they've edited, find a version which gives a "contribs" link alongside their username as part of the diff, etc. There is one ghastly state I sometimes fall into where the font size increases with every keystroke so it's very soon impossible to do anything at all and I have to abandon the edit.
It seems impossible to contribute to some talk page discussions, I think Wikipedia Project talk pages mostly, though I can contribute to article and user talk pages. If I want to add to the end of the automatic edit summary after doing an "undo", I often struggle to scroll along to its end, if it's longer than the input box: sometimes it will move, sometimes not, possibly dependent on what scale Ive zoomed it to.
It's altogether a somewhat unpredictable and stressful experience, but I keep on doing it because I can use the phone in places where I don't have my computer, such as sitting on the sofa, semi-sociably half-watching something on the television. PamD 17:08, 3 January 2024 (UTC)Reply[reply]
PamD huh, I have encountered zero of those problems using Firefox on Android with "advanced" mode in my mobile preferences. Contribs are available at the page header of User: and User talk: pages, I can tap "read as a wiki page" to view and edit Wikipedia talk: conversations, and my typeface size has never increased outside a pinch zoom. I could see an Undo diff preview being uncomfortably long, but have never had a problem getting the screen to scroll. Folly Mox (talk) 17:18, 3 January 2024 (UTC)Reply[reply]
Hmm, I use Firefox on desktop but Chrome on phone. Perhaps I should try Firefox on the phone. PamD 18:08, 3 January 2024 (UTC)Reply[reply]
You might find this page useful: User:Cullen328/Smartphone editing. I do a lot of editing while mobile (such as now!) and I find the desktop version of Vector 2010 to be the best interface for it. Barnards.tar.gz (talk) 17:26, 3 January 2024 (UTC)Reply[reply]
I mean, maybe, and I'm not sure of any other high profile mobile editing user essays, but the takeaway from the linked essay (briefly: desktop view, landscape orientation) is the exact opposite to how I edit, and I get on fine. It's really up to personal preference (and Special:Preferences) except in some edge cases, like viewing navboxes or the source of a fully protected template. Folly Mox (talk) 03:22, 4 January 2024 (UTC)Reply[reply]
Mobile editing is terrible, but for me even mobile reading (Samsung Galaxy A50, Chrome) is nearly impossible since a few weeks. And then there are the strange things on Mobile view even when seen on a desktop. E.g. the right side of the translate box at the top of this is a clear "show", while the same in mobile view has a "show" which for some reason fades out to the right. The watchlist in mobile uses way, way too many lines (4 or 5 per entry for no good reason), where "thank" is a too big button and "rollback" is a lot smaller and without a border (on desktop view they are nicely aligned and formatted).
This is simply brilliant. Above the diff, it shows the legend: "Content added" in a blue box, "Content deleted" in a yellow box. Below, the actual diff, shows content added against a green background, and content removed against a red background. Phew, good thing I had the legend... Oh, but perhaps because I look at it in Wikitext and not in Visual? Er, no, when I make that switch, the added text is shown against some green-bluish hue, not the same as the "content added" box at all, and the removed line is no longer visible.
Editing? I can't edit a complete page in mobile, if I use the "edit" pencil at the top I only get the lead. E.g. swapping two sections is not possible (or at the very least not intuitive) this way. Doing this in desktop mode is straightforward. Doing all this also reminded me of one of the reasons why Visual Editing is such a pain in the ass. Changing a short description in wikitext is "click edit, change shortdesc, save". Doing this in VE is "click edit, scroll up (!), click short desc icon, click edit again but now at the bottom, change shortdesc, save, save again because you only "saved" the template change". Fram (talk) 19:19, 3 January 2024 (UTC)Reply[reply]
I use to edit using the mobile version on my phone a lot. ... no longer do so...instead I switch to desktop mode on my phone. There is a link at the very bottom of every page to change to desktop view and back. Moxy- 20:06, 3 January 2024 (UTC)Reply[reply]
There's a script that will force the desktop version as well, useful if you're googling something and end up following a link back to Wikipedia. -- LCU ActivelyDisinterested«@» °∆t° 01:11, 4 January 2024 (UTC)Reply[reply]
An "edit full page" option for mobile was added a few months ago, in the vertical ellipsis menu in the upper right, with the rest of the page tools. Swapping sections seems pretty identical (cut-paste). I don't see the same blue / yellow legend boxes in inline diff mode, which might be the result of a user preference. Folly Mox (talk) 03:18, 4 January 2024 (UTC)Reply[reply]
I get the exact same look when I log out, so not the result of a user preference. Fram (talk) 09:39, 4 January 2024 (UTC)Reply[reply]
After checking the linked diff logged out in three separate browsers, I haven't been able to view the "content added" / "content removed" legend in either source or visual mode, so it doesn't seem like it's one of my user preferences either. Folly Mox (talk) 12:11, 4 January 2024 (UTC)Reply[reply]
Looks like the legend hides if your device is 1000px wide or smaller. Which may explain why it hasn't been noticed that MobileFrontend overrides MediaWiki core's diff colors but not the colors in the legend. Compare this desktop diff (again, in a browser with a width >1000px) where the legend and colors do match. Anomie⚔ 12:38, 4 January 2024 (UTC)Reply[reply]
Seconding the concern that editing pages on mobile in Firefox gives a bizarre situation where editing the entire article only gives you the lead section. I figure this might be some weird user preference but it always annoys me a lot. In general, the mobile editing experience leaves a lot to be desired, although I'll confess I do not have a lot of concrete suggestions. It does seem like the mobile website downplays the editor-created nature of the site a lot (i.e. history and the like are often hidden). jp×g🗯️ 08:46, 6 January 2024 (UTC)Reply[reply]
JPxG, the edit pencil at the top of an article opens only the lead. "Edit full page" is collapsed inside the vertical ellipsis menu in the upper right, along with Special:WhatLinksHere, Special:PageInfo, et al. This is a recent change (feels like second two thirds of 2023; I'll see if I can find the date). Folly Mox (talk) 12:40, 6 January 2024 (UTC)Reply[reply]
1 August, as part of MediaWiki 1.41/wmf.20, pursuant to phab:T203151, but apparently this option is only available if you enable "Advanced" mode in Special:MobileOptions. I think not having this mode enabled probably severely cripples the editing experience (link anchored to "1 August" above has the deets). Folly Mox (talk) 12:54, 6 January 2024 (UTC)Reply[reply]
Computer is fixed, so it doesn't really matter all that much anymore. I just couldn't deal with mobile diffs. DrowssapSMM 12:10, 4 January 2024 (UTC)Reply[reply]
Screenshot added. Also note the ridiculously large footer (which extends further to the right than the actual page, poor layouting once again) Fram (talk) 12:23, 4 January 2024 (UTC)Reply[reply]
Illustrate a mobile view anomaly on Wikipedia
Another screenshot, showing the weird "show" (bottom right) fade out. Very artistic. Fram (talk) 12:28, 4 January 2024 (UTC)Reply[reply]
Separately from any issues with it, the mobile view has the appearance of something that is a decade or more out of date. I would hope the WMF are working to consolidate around one appearance that scales across devices and different screen sizes. Working on each separately at this point would be a waste of resources. -- LCU ActivelyDisinterested«@» °∆t° 19:45, 4 January 2024 (UTC)Reply[reply]
I don't think I share that hope. Having one or more giant screen, with a keyboard + mouse input setup, and the ability to have multiple apps open in a single view, is a fundamentally different experience to a vertically oriented, cramped, "one app at a time", "long-press contextual menu instead of shortcut keys", "keyboard input necessarily occludes a non trivial portion of the screen" kinda situation.Also there are pretty big differences in system resources. I really should replace my phone soon, but my device memory is such that even if most gadgets and userscripts were supported in Minerva I'd still disable them due to the overhead of loading all the javascript. I only enable Twinkle if I have to restore an old revision or AfD an article.I'm sure that Minerva probably looks old and busted viewed full screen on a desktop monitor, but on a mobile device it does a good job giving the page contents most of the screen real estate and keeping the other elements out of the way until needed. Folly Mox (talk) 18:00, 6 January 2024 (UTC)Reply[reply]
Minerva probably looks old and busted viewed full screen on a desktop monitor – before Vector 2022, before even Wikiwand, I understand that how to switch to Wikipedia's "secret" mobile view periodically made the rounds on social media. Reportedly, people thought it was easier to read. It's not my own personal favorite, but that doesn't mean those people are wrong. WhatamIdoing (talk) 23:02, 6 January 2024 (UTC)Reply[reply]
It's altogether possible that what looks "fine and normal" to me actually looks a decade or more out of date to younger eyes. That probably applies to most of the things I own and uh me. Folly Mox (talk) 23:21, 6 January 2024 (UTC)Reply[reply]
Shaping the Future of the Community Wishlist Survey
We are also grateful for your feedback about the survey and your patience in waiting for a response.
We have reviewed your feedback and made preliminary decisions to share with you.
In summary, Community Tech would like to develop a new, continuous intake system for community technical requests that improves prioritization, resourcing, and communication around wishes. Until the new system is established, the Community Tech team will prioritize work from the recently audited backlog of wishes rather than run the survey in February 2024. We are also looking to involve more volunteer developers in the wishlist process, beginning with the first-ever community Wishathon in March 2024.
Wikipedia has ORed its modern history periodization
English Wikipedia has more or less invented a non-existent term called the "late modern period" and seems to be basing it's top-level categorization of historical topics on it. I started a thread about the matter here:
I urge editors familiar with modern historiography to join in. I think this is a sign of a pretty serious deficiency in our treatment of historical topics. PeterIsotalo 20:46, 4 January 2024 (UTC)Reply[reply]
Documentation is here: Module:Piechart/doc#Labels_and_Legend. The charts are inspired by Lea Verou CSS charts. They should be fully accessible as long as you add the legend meta-option. The pichart module is also independent of any extensions (like the currently broken Graph extension). All graphs from the Module:Piechart are simply HTML with just a bit of CSS tricks. Nux (talk) 16:56, 6 January 2024 (UTC)Reply[reply]
@Gadfium Various ways make it better, which probably come from the fact that it's a module:
You can just provide values for the module (don't have to add labels), and it will just work. See examples on module:Piechart and some more on pl:Module:Piechart/test.
You can provide actual numbers, and percentages will be calculated for you. Graph extension module had this, but Pie chart brakes in weird ways when you provide it with numbers larger then 100.
You can reorder slices easily e.g. to sort them by value. So should be easier to update when data changes. Templates have to enumerate each parameter, in JSON which my module uses this is not needed.
Also, I didn't know about the Pie chart template (: So I just found out... Visually, it seems to be on par with my take. Most of the things I talked about come from calculations I do under the hood. I must say that it is weird the Pie chart template wasn't mentioned when the Graph extension failed (or I missed it). Still, it seems I got some interesting results starting with a completely different approach. I have already replaced some usages of the Graph extensions with the new module. From what I can see, my version is more stand-alone (it doesn't use image classes), more flexible (easier to place in different parts of the page), and more accessible too (the legend is just a list, making it usable for screen readers). Nux (talk) 01:49, 7 January 2024 (UTC)Reply[reply]
How about a new start for WikiProject Inca Empire. It never really went up, huh? Well I think there are enough Inca/Andes interested Users to get that thing rolling. Are there though? Anyway I just wanted to ask if anyone was interested in instating some minimal organization, like on the other WikiProkects. Cheers. Encyclopédisme (talk) 03:04, 7 January 2024 (UTC)Reply[reply]
@Encyclopédisme, you might find WP:REVIVE useful. The first and most important thing to do, if you want to revive Wikipedia:WikiProject Inca Empire, is to find editors who are already editing relevant articles and make friends with them. Find ways to help them out, and then ask them to watchlist the page (as a favor to you). WhatamIdoing (talk) 04:35, 7 January 2024 (UTC)Reply[reply]
Central banner for a Commons contest to photograph the culinary diversity of Bengal
A photographic contest is going to happen from 15th January, 2024 to 14th February 2024 on Wikimedia Commons to enrich the photographic content Bengali culinary diversity and a central notice request has been placed to target English Wikipedia users including non-registered ones from Bangladesh and the Indian states of West Bengal, Tripura, Assam, Sikkim and Jharkhand. Thanks. -- Bodhisattwa (talk) 06:33, 9 January 2024 (UTC)Reply[reply]
, making the keying useless.) --Nat Gertler (talk) 18:57, 24 December 2023 (UTC)
.png)
You are invited to join the discussion at Template talk:Contains special characters § Displaying only when needed. {{u|Sdkb}} talk 04:59, 8 January 2024 (UTC)
The way that Random pages are selected has been updated. This will slowly reduce the problem of some pages having a lower chance of appearing. [41]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 January. It will be on non-Wikipedia wikis and some Wikipedias from 10 January. It will be on all wikis from 11 January (calendar). [42][43]
Done, though the last word remains "title" instead of "article" as this tag is also used on non-articles. Aaron Liu (talk) 17:22, 6 January 2024 (UTC).jpg)
![[8]](https://smallwarsjournal.com/sites/default/files/inline-images/Zulfiqar_1.png){kind=link}
![[9]](https://www.criticalthreats.org/wp-content/uploads/2017/02/Reuters-Houthi-fighter-in-parade-in-Yemen.jpg){kind=link}
![[10]](https://jcpa.org/wp-content/uploads/2023/11/houthi_launch.jpg){kind=link}
![[11]](https://www.aljazeera.com/wp-content/uploads/2021/04/2019-09-17T191607Z_1829542554_RC167A191840_RTRMADP_3_SAUDI-ARAMCO-HOUTHIS.jpg?resize=770%2C513&quality=80){kind=link}
_-_Lua_errors.png){kind=link}
Write to me! 14:38, 4 January 2024 (UTC)
Write to me! 14:37, 4 January 2024 (UTC)
Mathglot (talk) 23:28, 21 November 2023 (UTC)
.svg/15px-Maple_Leaf_(Pantone).svg.png)
20:06, 3 January 2024 (UTC)
