Comments

The following is an automatically-generated compilation of all talk pages for the Signpost issue dated 2024-03-29. For general Signpost discussion, see Wikipedia talk:Signpost.

Comix: Layout issue (882 bytes · 💬)

Fantastic comix. Greatly enjoyed it. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 01:25, 30 March 2024 (UTC)

...That's LITERALLY how I figured out how to fix {{CSS image crop}}'s centering issue on mobile. Investigated the code between mobile and desktop. Tried hand-editing the code using the debug. Finally figured out it was just some weird interaction between two nested div tags. Adam Cuerden ^(talk)_{Has about 8.9% of all FPs.} 04:36, 1 April 2024 (UTC)

Humour: Letters from the editors (2,342 bytes · 💬)

Aaaaaahhhhh. Very well written. Too accurate. Therefore disconcerting. jengod (talk) 05:51, 30 March 2024 (UTC)

You got us nailed! I don't know when I laughed so hard, but this really hits home.— Maile (talk) 23:00, 30 March 2024 (UTC)

Oh these are an absolute joy! Too real, perhaps we all should format our talkpage comments as letters. In this spirit, let me add a personal one:

Dear fellow Wikipedians,
After careful deliberation, I found that this discussion presented "no consensus" and I will thus close the section. Nearly 24 hours have passed since this important issue was brought forward, and most of the five interested parties disagree with the proposed solution. Many alternative strategies were proposed, but we will not discuss those any further. May this conversation be archived shortly and be forgotten forever.
Kind regards,
A closing administrator

~Maplestrip/Mable (chat) 09:04, 2 April 2024 (UTC)

Therefore any encyclopedia would be incomplete without a thorough repetition of every complete thought that was reported in regard to this subject.
— AfD Arguer

Seems a bit unrealistic, I think most of them would argue for inclusion of the incomplete thoughts as well. FeRDNYC (talk) 17:18, 6 April 2024 (UTC)

Excellent piece! Not mean, just accurate. Toadspike (talk) 15:52, 13 April 2024 (UTC)

I think I will copy these and re-use them everywhere - while providing attribution of course so I am never accused of plagiarizing which of course I am in fact doing. They are too priceless and too accurate to just let them disappear into the ethernet! I will carry the torch forward setting fires everywhere as I go about laughing like a maniac! YES! Jenhawk777 (talk) 02:53, 15 April 2024 (UTC)

In the media: "For me it’s the autism": AARoard editors on the fork more traveled (8,808 bytes · 💬)

"AARoard" in the title, real yurkey moment. Pretzelles (talk) 23:48, 29 March 2024 (UTC)
And it should be BMACS1002. LilianaUwU ^{(talk / contributions)} 23:52, 29 March 2024 (UTC)

Also, the image's caption is "CAPTION". Recon rabbit 00:15, 30 March 2024 (UTC)
@Reconrabbit @LilianaUwU @Pretzelles must've gotten lost when the WJC report story was split off. fixed all three Y ... sawyer * he/they * talk 01:05, 30 March 2024 (UTC)
Also... what's with the quote in the title? "For me, it's the autism"? It feels wrong to use that quote. LilianaUwU ^{(talk / contributions)} 23:52, 29 March 2024 (UTC)
I am autistic, and it doesn't particularly bother me. I think for some people who are autistic, contributing to Wikipedia really could be something that appeals; it certainly has been to me. Seraphimblade ^{Talk to me} 04:03, 30 March 2024 (UTC)
i'm also autistic, and wikipedia is my primary way to engage with my special interests - based on the context in the interview, it seems the same is true of autistic AARoads editors, per their own words. the full quote is
“For me it’s the autism. You settle on a thing and then you’re like, ‘well, this is my thing now,’” Ben said. “But people get really into all kinds of stuff, and just because it’s not the thing you’re into doesn’t mean it’s not important. We do it because we love it and we can create community around it.”
seems pretty indicative of the somewhat personal nature of the dispute here - if my special interest were US roads, i'd also be pretty upset about the articles going to AfD constantly; hence, the forking. ... sawyer * he/they * talk 19:34, 30 March 2024 (UTC)
Re: "my ultimate goal is to fork back [AARoads content]", it seems to me we really could use a Wikimedia project that provides almanac-like info, covering all the deets of roads, public transportation, radio/TV stations, agriculture data, and more. We could keep the Wikipedia an encyclopedia, with that level of coverage, and its articles can link to the WikiAlmanac page on that or related subjects. Every so often in an AfD discussion, I feel like "this topic of community concern isn't notable for our purposes but coverage of it still seems useful." Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 01:26, 30 March 2024 (UTC)
- Roughly like the CIA Factbook, only bigger and going down to details on cities. You may recall that our Wikivoyage affiliate was once an independent, commercial wiki but the Admins and other heavy hitters got fed up with its commercial policies and begged admission as an autonomous wiki to our little empire, with relaxed standards appropriate to tourism. Similarly a Wikiroads, or Wikialamanac site, with looseness appropriate there but not to an encyclopedia that needs more tightness, might be welcome. Jim.henderson (talk) 15:05, 30 March 2024 (UTC)
- Definitely the right principle to pursue. I've seen it happen with other kinds of content as well. It was extremely useful content for certain purposes but got removed from Wikipedia simply because Wikipedia is a general encyclopedia and a general encyclopedia isn't quite the appropriate place for it. More ought to be done with this concept than has been done with it to date. Quercus solaris (talk) 23:24, 30 March 2024 (UTC)
This is definitely something that shouldn't be forgotten. Just because something is not in scope for Wikipedia does not mean it's without value; it just means it doesn't fit here. Wikipedia, for example, lists recipes as out of scope (and, in my view, correctly so), but there are some very good ones on Wikibooks. Similarly, I've found plenty of how-to guides and tutorials to be of substantial value; they just don't belong here. Unfortunately, with fictional content, that was farmed off to a for-profit endeavor that I know some people are less than happy with, but if we can fit material that is out of scope here but nonetheless useful into Wikimedia sister projects (existing or newly created), I think that we should. An almanac/gazetteer type sister project might be a great way to resolve the issue of permastubs on "populated places", roads, and so on. Seraphimblade ^{Talk to me} 23:52, 30 March 2024 (UTC)
- A WikiAlmanac project appeals to me. I know sports sometimes runs into this as well: primary sources publish sporting results and fans just put those into big tables of results. ~Maplestrip/Mable (chat) 08:00, 2 April 2024 (UTC)
completely agree with all of the above. i'm envisioning something like wikidata but user-friendly, which i'd definitely be interested in contributing to :) ... sawyer * he/they * talk 05:06, 31 March 2024 (UTC)
- The first pillar says: Wikipedia combines many features of general and specialized encyclopedias, almanacs, and gazetteers. Even though we primarily describe ourselves as an encyclopedia, it is reasonable to discuss what almanac information is within our scope. However, I don't think forks should be considered a failure. Many Fandom wikis are huge successes. We are part of a wider movement to make information freely available: it doesn't matter what domain it's hosted at as long as readers can find it, and we should be happy to collaborate across sites. — Bilorv (talk) 10:13, 4 April 2024 (UTC)

@Lajmmoore: Huge congrats, it's such an inspiring achievement! Oltrepier (talk) 13:41, 1 April 2024 (UTC)
Thank you so much @Oltrepier & thank you for pointing me to the signpost too - I'd have missed the mention otherwise! Many thanks to the contributor who added it in - so appreciated! Lajmmoore (talk) 23:00, 2 April 2024 (UTC)

Cooking could be in, not a cooking wiki but in a "how to" wiki along with corset making, cornet playing, courting, corking, cod fishing, whatever doing. Jim.henderson (talk) 01:24, 2 April 2024 (UTC)
I think cooking would in theory be covered by WikiBooks. Not that it's used much, I'm afraid. ~Maplestrip/Mable (chat) 08:00, 2 April 2024 (UTC)
This is perfect for Wikibooks. In fact, why don't we encourage people to write how to on Wikibooks, and then link them from the Wikipedia page? Jim.henderson — Preceding unsigned comment added by CactiStaccingCrane (talk • contribs) 14:00, 5 April 2024 (UTC)

Interview: Interview on Wikimedia Foundation fundraising and finance strategy (1,869 bytes · 💬)

A disappointing lack of discussion of whether the screen banner campaigns are appropriate now and for the future – particularly the obstructive full-screen campaign appeal on phones. During the latter part of 2023, the splash screen impeded using Wikipedia for random momentary queries ("What is the population of Blahtown?" or "this film seems familiar, is it a remake?", etc.). This is an experience counter to point 3 in the linked Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs. It is these queries which are typically the start of a down-the-rabbit-hole process, which lead to discovering the unexpected, correcting errors, etc., so are crucial to the project. If people ("consumers" in that WMF plan) feel impeded from using Wikipedia to seek quick info, the new search engines tools can appear easier to use (with or without hallucinated info). There is a danger in Fundraising simply operating on a rote diary (Aug: pick up last year’s campaign artefacts and get the en.wiki campaign started for Dec). Is there also strategic thinking – about mobile-first, about LLM-driven querying becoming prevalent elsewhere, about whether the splash-screen fails to "make our content easier to discover and interact with" - and, if so, how to re-orient for the future? AllyD (talk) 08:42, 2 April 2024 (UTC)

The budget for the WMF needs to be shrunk drastically, there is no evidence more value is provided to users or editors with them as a behemoth than as a tight lean organization. They have developed a terminal case of Big Non-Profit brain. Antrocent (♫♬) 14:40, 12 April 2024 (UTC)

News and notes: Universal Code of Conduct Coordinating Committee Charter ratified (491 bytes · 💬)

@Jayen466: Thank you so much for taking over the coverage of WLM 2023 during my absence! Honestly, I thought Italy would "colonize" the final Top 15, too, but the overall quality per picture is just out of this world, so that's perfectly fine! : ) Oltrepier (talk) 10:35, 1 April 2024 (UTC)

Op-Ed: Wikipedia in the age of personality-driven knowledge (37,400 bytes · 💬)

Without advertising revenue, there is no monetization. Talent for those personality driven things will go elsewhere, thankfully. We have personalities here also BTW, but they are only watched for entertainment purposes in places like Wikipediocracy. -- GreenC 23:08, 29 March 2024 (UTC)

The Technology Report in this issue discusses a security issue that has essentially caused graphs to stop working in Wikipedia. Other technological "improvements" may carry the same risk.

That Signpost feature also points out how few articles actually have interactive or other fancy graphs - a clear indication that "build it and they will come" isn't always true, particularly for an all-volunteer content creation process.

As for the current situation: as the article pointed out, creators on YouTube and TikTok already routinely harvest facts, ideas, and images from Wikipedia. If our goal is to push out accurate information, as opposed to getting Wikipedia as many page views as possible, then YouTube and TikTok use of Wikipedia may be worth giving more encouragement, not reacting with despair.

Finally, I think the most important metric is how many active editors we have, and how much editing they do. If that turns negative, then we have a very serious problem. -- John Broughton (♫♫) 23:29, 29 March 2024 (UTC)

Indeed, those Youtubers I watch already cite Wikipedia or even show it on screen occasionally. That is a practice we should encourage and make easy: Always cite your sources!

Proper attribution should be standard behaviour and easy, when reusing Wikimedia content. As of today, there is still much UX design and metadata cleanup work to do in this regard, cf. e. g. this recent blogpost. HHill (talk) 11:53, 30 March 2024 (UTC)

@HHill and @John Broughton: Thank you for reading and sharing your thoughts! @John Broughton: I think you're spot on in your summary here:

If our goal is to push out accurate information, as opposed to getting Wikipedia as many page views as possible, then YouTube and TikTok use of Wikipedia may be worth giving more encouragement, not reacting with despair.

Our mission has never been to drive clicks to a website. It is to share the sum of human knowledge, and if this knowledge finds its way to people in new ways, I think that should be celebrated. But as @HHill points out, attribution is an important ingredient in ensuring that Wikipedia knowledge is shared sustainably – without any paper trail back to the concept of Wikipedia as the source, a) it's hard for viewers to know if any given YouTube or TikTok video is full of carefully checked facts harvested from Wikipedia or... not, and b) over time, the awareness that Wikipedia is a place where reliable knowledge is collected may fade from people's consciousness. And with fading awareness that Wikipedia is a website you can read, we may indeed start to see declines in people who experience the magic of discovering that Wikipedia is a website they can edit...

A few years ago, some colleagues and I worked on this attribution guide intended for 3rd party content reusers, but I'm interested in hearing any thoughts or ideas you have about how to approach attribution in a way that gets it to stick – because asking people to read and follow a guide only goes so far. I'm also very curious to see if we could create that magic "I can edit!" moment wherever Wikipedia facts/information get reused (but also very mindful of the careful balance between being more open/inviting to new users and not overburdening the existing community with cleanup work). I'm inspired by the work of my colleagues in the WMF Growth team (e.g., structured safe-to-try tasks) and am thinking about how some things like that might show up in places like TikTok or YouTube. Your thoughts/ideas on either of these topics (attribution, off-platform contributions) would be very appreciated! Maryana Pinchuk (WMF) (talk) 21:32, 1 April 2024 (UTC)

While it's great that there's a guide for this, I honestly doubt the vast majority of content reusers know it exists. From where I'm standing, I think the problem with non-attribution comes down to a few factors:

Most people aren't even aware of our license, let alone its requirement to attribute. Even new (or sometimes seasoned) editors copying content within Wikipedia need consistent reminders that they need to provide proper attribution. Without displaying our license more prominently, people aren't even going to know about it, let alone care.
Almost as a rule, Wikipedia is seen as a monolithic entity where content just exists, not an easily-editable platform that thousands of thousands of real people put time and labour into. You would be surprised (or maybe you wouldn't) at the amount of times I've told people I'm a Wikipedia editor, and they didn't even understand that was a thing that existed. If it's seen as just a thing and not a collection of people, then many are going to think it's fine to lift (or even plagiarise) from.
Maybe I'm not informed enough on this, so feel free to correct me if I'm wrong, but I get the feeling that the Wikimedia Foundation doesn't see enforcing its license as an issue worth pursuing. If our license requires attribution, but there are no consequences (no matter how minor) for not providing attribution, then many unfortunately aren't going to see it as necessary.
This is something I actually saw the YouTuber hbomberguy bring up in his recent video about plagiarism (which highlights a couple cases of YouTubers plagiarising Wikipedia): reusers that lift content without attribution almost invariably see the people they're exploiting as beneath respect, they're not going to attribute our work to us because they don't see us as worthy of attribution. It is sometimes shocking to me how much contempt is levelled at Wikipedia editors and our work by different parts of the internet; many people see our work as worthless, so why would they bother pointing out that they got their information from a platform they consider so contemptible?

I don't think any of these are unfixable problems, although the last one may be a lot harder to fix as it requires broader cultural changes. In fact, I think the first three have solutions that we can do in house:

Display the CC license more clearly on more pages (not in small print at the very bottom of the page), make it even harder to miss that there are clear terms outlined for reuse of our content. The only place I'm regularly confronted with the terms of licensing is on pictures on Wikicommons, and even then it is very easy to miss.
We need to do better ourselves at properly attributing the work of our users. Right now, if I want to find out the authorship of an article, I need to click on "View history" (which many don't know exists), then click an external link to a separate website, then scroll down to see the authorship in terms of percentage and characters. In contrast, Britannica prominently lists the primary authors of its articles underneath the article title, with secondary contributors also being displayed prominently in the history. Make it clearer that there are real people behind these articles and who they are, and this'll contribute to more people understanding that there are real people doing this work and they deserve attribution.
We should probably have a form set up where users can submit information about their work being reused without attribution, so that the Wikimedia Foundation can pursue the issue. I've tried being direct with content reusers about attributing the work of Wikipedians/Wikimedians, whether through emails or comments, but it doesn't work, they usually just ignore such messages. So we really do need the force and resources of the Foundation to help us with this. We should be active in collecting data on content reuse without attribution, leaning on reusers to provide attribution and pursuing them further if they continue unapologetically breaking the terms of our license. It should be made clear to reusers that reuse without attribution isn't just wrong, but has potential consequences.

These are just my thoughts on the matter, which I've been mulling over for quite some time. (I think I started thinking about this sometime last year, after I saw my work getting plagiarised twice in one week) I understand they may not all be workable, to others' liking or if this is even the right venue for bringing this up. I just really wanted to get all this down in writing. Apologies if I've gone on for too long about it. In any case, I think off-wiki reuse without attribution is a major issue that needs addressing, and I'd be happy to see more done on that front. --Grnrchst (talk) 09:50, 2 April 2024 (UTC)

@Grnrchst thank you for sharing these thoughts, and it's so painful and sad to hear how uncaring some reusers can be about taking the hard work of Wikipedians without given them proper (or any...) credit. This is definitely something I and my colleagues care a lot about. IANAL, but my understanding is that we're in a complex and tricky spot to approach this topic from a legal POV, for the following reasons: the Wikimedia Foundation doesn't "own" the licenses used on our projects (the license terms are specified and maintained by Creative Commons) and we certainly don't own the underlying content (which belongs to the original authors). Furthermore, the CC license terms on attribution are flexible by design, to accommodate unforeseen types of reuse (i.e., via new technologies or new creative applications) – but that flexibility makes it harder to argue why something is/isn't reasonably attributed. So, my (non-lawyer) understanding is that pursuing legal action against every reuser who doesn't attribute correctly would be quite resource-intensive, and we would have to balance an investment in WMF Legal staff time spent on this against other important matters (like trademark infringement, Terms of Use violations, etc.).

For all the above reasons, I wonder if taking a different (i.e., more of an awareness/marketing) approach could be both more effective and more cost-effective at getting reusers to attribute – i.e., showcasing the existence of our editing community and highlighting how to do attribution right via popular social channels, doing more to promote the importance of reuse among the tech sector, etc...

Would you mind if I put you on my mental list of Wikipedians to reach out to as I and others at WMF think about how to do some interventions in this area? Maryana Pinchuk (WMF) (talk) 17:23, 5 April 2024 (UTC)

@MPinchuk (WMF): Thanks for the response, I understand my suggestions may not be workable, was just spitballing because I think something needs doing. And aye feel free to reach out at any point. :) --Grnrchst (talk) 11:12, 6 April 2024 (UTC)

The "BY" requirement of CC BY-SA doesn't kick in if you're just citing or paraphrasing Wikipedia. And featuring the usernames of contributors more prominently would be incompatible with WP:OWN. Anybody who contributes to Wikipedia should expect they will get no credit for their work.

I see no problem with content creators not crediting Wikipedia. If they referenced Wikipedia for their research, what I want from them is to verify the claim with the sources cited in the article they read and then credit those sources, not to credit Wikipedia, which we all know is not itself a reliable source. Nardog (talk) 08:33, 6 April 2024 (UTC)

I strongly disagree that crediting contributors has anything to do with ownership or rewards (in particular I take issue with the idea that proper credit is a reward and not basic decency). In fact, neither of those articles you link to mention anything about authorship credit. --Grnrchst (talk) 11:20, 6 April 2024 (UTC)

@Grnrchst: I agree with you on the question of rewards; WP:DNER was the wrong essay to cite, especially since it's primarily an essay about on-wiki rewards. (IOW, don't expect Wikipedia to reward your editing with special privilege.) That doesn't apply here.

However, I largely agree with Nardog on the question of crediting editors more prominently — how does that even work, when a typical article is the collective product of hundreds if not thousands of individual contributors? What makes someone a "primary author" of any given Wikipedia article? How would we even decide?

"source: Wikipedia" IMHO satisfies both the ethical and moral obligations of the project license. (I won't comment on legal obligations because IANAL.) Asking people who reuse Wikipedia content to name-check everyone with a Wikipedia account who's ever tweaked the article's punctuation feels not only unworkable, but counterproductive. And personally, I don't see it as in any way necessary, when it comes to my own contributions. Others' opinions may, of course, vary. FeRDNYC (talk) 17:44, 6 April 2024 (UTC)

I don't see how DNER is inapplicable here (on-wiki rewards are just some of the rewards it discusses, not the only kinds), but if you say so, there are also WP:YANI, WP:NOTYOU, and WP:DGAF. It's not a novel or obscure concept. Nardog (talk) 10:39, 7 April 2024 (UTC)

If you're a content creator and your only source is a Wikipedia article, then you have a moral obligation with your audience (and perhaps with society at large) to disclose where you got that information. But unless you're redistributing the whole or a part of the article verbatim or adapting it beat by beat, you have neither legal nor moral obligation to credit individual contributors. We document facts, and nobody owns them. Nardog (talk) 04:41, 7 April 2024 (UTC)

@Grnrchst: I actually made a quick video about some of the stuff you are talking about with regards to Wikipedia and Hbomberguy. :P –MJL ‐Talk‐^☖ 00:39, 14 April 2024 (UTC)

I think we should be clear that WP has had an easy seven or eight years ride, from the period of the fake news panic. The reason being that WP took to heart why its curation c.2006 was inadequate, and spontaneously did something about it. It is not clear that there is an existential threat credible enough to move communities to react at the content level. That said, concision, illustration and verification need to be working "everywhere all at once", and there is no reason that readers should not be offered different views of the same article content. Charles Matthews (talk) 14:02, 30 March 2024 (UTC)
I can not follow the reasoning in the article. We are not in a popularity contest, but our task is to provide correct knowledge, and I see no threat to this our mission. In 1518 there was a battle that was the start of the modern kingdom of Sweden. In was weekly documented and has been used heavily in propaganda under 500 years, and even in modern time there has been an article about every second year publishing different speculations. After a proper Wikipedia article was published 10 years ago, all speculation articles have stopped and on local heritage sites, earlier full of speculationstexts, there only exists a link to this article. And the number of reads steadily increases. No tiktok discussion will start an alternative truth over this battle. (sv:slaget vid Brännkyrka)Yger (talk) 17:39, 30 March 2024 (UTC)

I rather agree with most of the above comments. The article does not make a persuasive case for the TikTokisation of Wikipedia, for the good reason that the process would be a disaster: at best, a waste of money, its results to be removed from view and the waste swept under the carpet; at worst, the widespread contamination of a perfectly good functioning encyclopedia, which happens to be nothing like today's latest fashion, nor yesterday's forgotten super idea, nor tomorrow's passing fad. Chiswick Chap (talk) 15:19, 31 March 2024 (UTC)
@Chiswick Chap: Thanks for reading! I definitely am not arguing for the TikTokisation of Wikipedia, for all the reasons you mention here. I do think there is an argument to be made (and some in the Wikipedia community are actively making it; see the discussion on the Technology Report in this issue) that we need a bigger investment in more modern, rich-media experiences on Wikipedia (i.e., that we should create software tools to allow Wikipedians to make interactive content like graphs, maps, timelines, videos, etc.) in order to keep up with the modern Internet. I can see the potential benefits but also many potential risks and costs. What I tried to get across here is that there is another way to look at this space, which is more like the Wikipedia-ization of TikTok. Maryana Pinchuk (WMF) (talk) 21:43, 1 April 2024 (UTC)
Yes, I read about the "more modern, rich-media experiences" with the queasy feeling you may imagine. Having replied here, I didn't feel like writing a repeat item, signed Professor Disgusted of Tunbridge Wells. The potential benefits are quite limited from the point of view of an encyclopedia; we already use a variety of media in articles, and in their place they are helpful. Having Ms Attractive Personality "explaining" the Big Complex Topic ("Now then children, we don't want to talk down to you today, but") is not going to be a good idea. Chiswick Chap (talk) 07:36, 2 April 2024 (UTC)

I echo the above comments, in that I'm not sure there's a problem in more entertainment/personality-based content getting more attention. This has always been the case, it's not like Encyclopaedia Britannica was more popular than television programmes or tabloids. What concerns me isn't that TikTok and YouTube are more popular than Wikipedia, it's actually something that this article slightly glosses over: that "Wikipedia is rarely credited or acknowledged in these videos" when it is used as a source. I'm sure I'm not the only editor that has seen their work fed back to them by 'content creators', who never bother even crediting the source, let alone its author. What we should be focusing on is not competing with completely different mediums of information production and distribution, but figuring out a way that we can better integrate with these platforms in a way that doesn't exploit our labour. Attribution is a very important part of our license, so we should be asserting it more. If TikTokkers and YouTubers credited us, I wouldn't have a problem with their videos being more popular than our articles. --Grnrchst (talk) 11:05, 1 April 2024 (UTC)
@Grnrchst: Thanks for reading! I absolutely agree that new mediums of information production could be valuable allies (not competitors) in the sharing of free knowledge, but that attribution is key to making this work. See my comments to User:HHill and User:John Broughton above. One interesting thing I've learned from talking to content creators is that some of them do attribute their sources because they feel it helps them gain more credibility with their audiences, but they tend to cite the sources used in Wikipedia rather than Wikipedia itself (for a variety of reasons, but one of them being that they seem to have internalized the scolding of that one schoolteacher who told them citing Wikipedia is bad). I wonder how/if we might change that... Maryana Pinchuk (WMF) (talk) 21:55, 1 April 2024 (UTC)
I don't mind the idea of Wikipedians creating videos to put in Wikipedia articles as an addition or summation of an article or section. There's lots of issues there, similar to our audio recordings, and might work better for some fields than others (I'm especially thinking technology, engineering, and mathematics). Such videos could even create a certain level of "personality" to an explanation that our text-heavy website tends to avoid (just through editing and design choices; I'm imagining a flat text here). This is the kind of thing I have been thoroughly enjoying Youtube for for nearly two decades now and I think there is value here. Creating such videos is a lot of work, however. ~Maplestrip/Mable (chat) 07:08, 2 April 2024 (UTC)
Thanks for your thoughts @Maplestrip! It is a lot of work to make a good educational video (I've dabbled with this a bit myself), but I think even more importantly:
- New policies/guidelines would have to be created and agreed to by the Wikipedia and Commons community about what can and can't be included in videos, how they should be reviewed, where they can and can't be added, who can make/appear them (i.e, COI), etc.
- New incentives would likely also need to be created (also probably via policy changes, like the creation of a Featured Video process or something). The kinds of people who are very good at making educational videos have some pretty substantial incentives (i.e., money, brand sponsorships, fame, etc.) to make this content on/for YouTube, TikTok, etc., and not a lot of incentives to make freely-licensed content and donate it to Commons – especially if it's not even guaranteed to show up prominently on Wikipedia.
I don't think these are insurmountable challenges, but imo they're just as important to consider as the technical hurdles, and they rely solely on the motivation and desire of Wikipedians to come together and figure this out. As @John Broughton mentions above, we can't assume that "if we build it, they will come." Maryana Pinchuk (WMF) (talk) 20:35, 5 April 2024 (UTC)

@MPinchuk (WMF): Videos are indeed a lot of work, which I can confirm from my own Youtube work. At this point I've spent months on single videos, but those videos do tend to be fairly long (ten minutes +). I don't have any incentives to make those videos, as I am not making any money whatsoever on Youtube with my skills. One or two-minute explainers on Youtube would be a lot simpler to make, perhaps even less work than doing a full-article audio recording (and we have surprisingly many of them). Technologically, I don't think we need to implement anything new; Commons video would already work sufficiently. I am realizing this concept sounds more like a Wikiversity thing than a Wikipedia thing, but I do think this kind of thing falls within our existing policies, similar to making explainer graphics. If someone takes the lead, who knows. ~Maplestrip/Mable (chat) 06:24, 6 April 2024 (UTC)

Hello Maryana! I've been following the work of Future Audiences because I think it's important for us as a movement to answer the question on "How do we keep Wikimedia projects relevant for the future". However, I do want to point out that this personality / authority issue is not a new one. Whenever I've interacted with academics and tried to convince them that they should contribute more to Wikipedia, the main obstacle that they've faced has been that they do not get credit for the work they do on Wikipedia. Unlike writing an encyclopedic article for, say, a special edition of a contemporary encyclopedia of China by Routledge, Wikipedia offers them nothing in the social currency that academics exchanges with (and I'm also using this example because I've seen how much some of these big publishing houses pay academics for such endeavors -- pennies; it's not a money issue what is at stake here). This is a personality / authority / credit issue that we've had since probably the inception of Wikipedia (it's kind of its birthmark!), but I'm concerned that we're asking this question because of the way in which the current media ecosystem overemphasizes personalities above everything else. I'm all for giving more credit to editors -- particularly those editors that contributed to this platform and have done things like, idk, inventing the optic mouse or contributed to IPCC reports -- but that's not what you're referring to, and I don't see how the rest of the arguments follow the "personality theory". Also, why do we keep comparing ourselves to social media platforms like TikTok? Again, I don't see Routledge or Encyclopedia Britannica comparing themselves to Pinterest. We're not on the social media business. We don't cater to the same audiences that Routledge or Britannica do (and I understand that), but there are so many assumptions that would be worth unpacking on how we are imagining those "future audiences" to be and look like. It sounds like this work is only highlighting young people from the US with a heavy media consumption (a very particular demographic). Why haven't we asked ourselves the question about serving entire populations that don't even know how to read in a heavy written environment? Countries like Mali or South Sudan have around 30% of literacy rates, with the most affected being women (source). UNICEF estimated in 2022 that only a third of 10-year-olds could actually comprehend a simple written story (source). Why are not those "future audiences"? It is also a known fact that global population is in a declining trend, with global fertily rates being below the replacement level (source), which means that the 18-24 age bracket might look very different in 15 years from now (2050 looks like years ahead but really in generational terms that's just around the corner). How do we respond to those changes? Again, I like the work that Future Audiences is doing, but I wish there was a more open conversation that doesn't only answers to the fears and concerns of the US tech sector, and that actually help us live more into our values. Scann (talk) 23:13, 2 April 2024 (UTC)
It could be nice to be able to easily identify the primary author of an article in a sort of byline, in cases where "primary author" applies, which is not infrequently. Within our community, some people have made a name of themselves by writing incredible articles in specific fields, but our users are unlikely to ever know there's a specific person behind those articles. I'm sure there aren't tons of issues with this concept tho. ~Maplestrip/Mable (chat) 08:53, 4 April 2024 (UTC)

@Scann: This is a very well-timed comment, because I'm working on setting up some time for a conversation just like this in the coming weeks with the LATAM community Look out for more information soon...

TBC, I'm not comparing Wikipedia to or encouraging it to become more like TikTok – what interests (and worries) me is that TikTok and other platforms like it are becoming entrypoints to getting information online for many young people – not just in the US, but globally (my understanding is that TikTok usage rates are heavier in some parts of Central and South America than in the US). These platforms could amplify/supplement the knowledge and content in our projects... but they could also cut off awareness and entry into our very web-based free knowledge ecosystem. If we ignore them entirely, we do so at our peril.

Since Wikipedia was created, we've relied heavily on web search engines to make people aware of and bring them to our projects. I think it's fair to say that without the fortuitous and not-at-all inevitable situation in the early 2000s of Google prioritizing longform text resources like Wikipedia in search results, Wikipedia would have stayed a small hobby project for Jimmy and a few of his Internet friends. If new social apps like TikTok are replacing web search, and/or if more and more young people no longer turn to long-form text resources (but instead to video, social Q&A sites, podcasts, etc.) to get information, we risk losing a good chunk of this younger generation and those after it as future readers and contributors. Those are the future audiences I'm concerned about.

Like you, I don't consider our mission to be fulfilled if Wikipedia remains known to and used only by an increasingly small population of affluent, digitally-literate, highly-educated elites. I'm hoping that more people from more parts of the movement start to talk about how we can truly fulfill our mission of bringing free knowledge to everyone in the world, anticipating that people and the world will change over the coming years and decades. I also agree that software can't be the entire solution to such a complex socio-technical problem; Future Audiences is just one tiny part of this picture, but it is by no means meant to be the only vehicle for innovation within our movement. Maryana Pinchuk (WMF) (talk) 20:17, 5 April 2024 (UTC)

I want to return to the issue of whether "more modern, rich-media experiences" are in fact desirable. They may be what audiences want (in part), but if we have problems just holding level with the number of active editors - editing text, consider the difficulties of attracting editors to do rich-media work. Or, probably more importantly, to maintain and update rich-media work. Consider if new information makes a video slightly wrong. Who is going to reshoot that video? And if not the original author, then how does the (different) editor deal with changing narrators in mid-video? Or consider a rich-media graph - who updates it, year after year, so it stays current?

One of areas of Wikipedia that I worked on from 2006 through 2008 was U.S. Congressional elections. Since then, I've seen a very significant drop-off in this area - lots of Congressional elections have no articles, or minimal articles, and biographical articles are often not updated with more recent election results. And this is essentially text-only. Why do we think that editors would flock to Wikipedia if it offered (more) rich-media editing, particularly since we essentially offer no (visible) credit to authors. -- John Broughton (♫♫) 20:25, 5 April 2024 (UTC)

We almost (edit conflict)'ed saying basically the same thing

See my response to @Maplestrip above. I agree that this is a very important set of question:

Do Wikipedians want to do this kind of work (make/triage videos for Wikipedia), and/or are there people outside the current Wikipedian/Commonist pool who would want to join our communities to do it?
How can we test that in a lightweight way, before investing tons of time and money into new technical solutions that may or may not see sustained uptake?

I came up with the idea of a "Featured Video" project OTOMH above, but that would be one potentially very interesting signal – i.e., if there were a critical mass of motivated Wikipedians who wanted to sift through existing Commons media and/or make new videos and pilot this as a new WikiProject dedicated to finding and adding videos to more Wikipedia articles, that would be very cool! Maryana Pinchuk (WMF) (talk) 20:46, 5 April 2024 (UTC)

We could leave updating of some graphical content to folks like Our World in Data and simply pipe their amazing material in. (Basque)

For video we have VideoWiki which is an automated system that builds videos from mediawiki based scripts. This makes updating easy (when the tool is not broken). Doc James (talk · contribs · email) 22:33, 16 April 2024 (UTC)

There has been a (limited) experiment with short explanation videos over at dewiki, it didn't go down too well (main discussion was at de:Wikipedia Diskussion:Kurier/Archiv/2020/01#Funk, see de:Wikipedia:Wiki Loves Broadcast/Dokumentation for context). There are plenty of lower hanging fruit to pursue, before embarking on something similar, I think. I remember hearing about problems with uploading videos on Commons, have those been solved? And why is a site like https://lizenzhinweisgenerator.de/ still necessary, shouldn't our own software offer this service in an easy and obvious way? I wouldn't be too surprised, if some of the related bug reports go back at least to the introduction of the Wikipedia:Media Viewer. We will need those software changes anyway, especially in an Age of AI, I believe. And as for articles, I do not think, those people using Wikipedia as a tool to find sources worth citing and not mentioning Wikipedia itself in their videos are a problem. Something similar was (and hopefully still is) true for common printed reference works, everybody at least somewhat experienced knew them and used them but for information found everywhere deemed it unnecessary to explicitly cite them. But for those articles worth citing, it would be useful to have a way to get their bibliographical information easily into a Reference management software, with their authorship information. Over at dewiki plenty of the better (e. g. good or featured) or more obscure articles are mostly the work of a single person. Some outreach would clearly be useful, who searches for a PDF on Commons for (re)using Wikipedia content, without knowing about its existence? Maybe it is worthwhile partnering with experienced and influential institutions or people on TikTok, Youtube etc., who share at least some of our goals, to create useful and entertaining videos on how to properly use and reuse Wikipedia and other Wikimedia content. And while we are at it, why not also some teaching research skills and digital literacy more generally? --HHill (talk) 08:50, 8 April 2024 (UTC)

Time to have Wikipe-tan become a VTuber? Cooljeanius (talk) (contribs) 10:57, 19 April 2024 (UTC)
I am thoroughly amused by this idea and would wholly support it as somesort of project on Youtube. Wikipedia as a vector for entertainment externally is cool :) ~Maplestrip/Mable (chat) 12:59, 19 April 2024 (UTC)
For the attribution/linking back to the source of information issue, an easy first step would be to come up with a standardized attribution text that can be generated with one click and displayed prominently somewhere on each page, specific to that page. Then, an awareness campaign to promote its usage elsewhere. Axem Titanium (talk) 22:27, 19 April 2024 (UTC)

Recent research: "Newcomer Homepage" feature mostly fails to boost new editors (11,099 bytes · 💬)

Looking at just the first 15 days for a new editor seems short. Many people dip their toes in the water and then return to editing more intensely months or even years later. —Ganesha811 (talk) 23:37, 29 March 2024 (UTC)
Hi @Ganesha811, thanks for reading and commenting! I’m the first author on that paper, and you’re right that 15 days appears a bit short. In the paper we describe how we chose two weeks rather than four weeks due to the marginal gains you get from extending the window. We also investigate two longer-term retention windows that were used in the Teahouse paper (1–2 months and 2–6 months), and again find no significant impact. One methodological note about retention is that we control for first-day activity in our models. This means that we can have a “no impact” result even if the Newcomer Homepage increases first-day activity, because the method’s comparing a more active newcomer in the treatment group to a similarly active one in the control group. Understanding or increasing retention is a challenging area, it’s often a “needle in a haystack” kind of problem because the retention rates are very low. Hope this helps explain things, thanks again! Cheers, Nettrom (talk) 19:58, 30 March 2024 (UTC)
Interesting, thanks for the reply! —Ganesha811 (talk) 20:25, 30 March 2024 (UTC)
Just want to comment that I was interested in what was going on with The Wikipedia Adventure and that "blog post" where the whole thing was discussed at length (I believe) is linked to a parked domain now unfortunately. Don't know if the expiration of communitydata.cc came up before... Reconrabbit 04:05, 31 March 2024 (UTC)
- The domain moved from .cc to .science and the old .cc domain expired and appears to have been lost/parked. That said, the post itself is still online (at the slightly different location). I've updated the link in the old WRN report. You can find the blog post here: https://blog.communitydata.science/adventures-in-onboarding-new-users-on-wikipedia/ —mako ๛ 13:45, 31 March 2024 (UTC)
  Thank you very much! I didn't know about the migration. Recon rabbit 14:46, 31 March 2024 (UTC)
There's an interesting conclusion to the paper on Newcomer tasks that I think the Signpost write-up missed: context matters. The strange results from the beginning of the paper (lots of nulls, weak and contradictory postiive results) make more sense if you consider the contexts in which the users are making account. In Section 4.4 they cover this in detail, but to summarize: editors make accounts because (1) they want to make an edit or (2) they want to read. The authors replicate a finding from this 2014 working paper that when an editor receives an intervention after opening the edit window they are less likely to make the edit they were planning to make as an unregistered user---the homepage and newcomer tasks distract the would-be-editor from actually making the edit they started. For the second group, who make an account to read, the authors find the opposite effect, with readers who make an account to read are more likely to make an edit (activate) if they are given the homepage and newcomer tasks.
This is a cool finding! It suggests that the features need a more complicated roll-out system than "give to everyone" and instead take into account what the user was doing at the time they created an account. It seems like an effective first pass would be just providing the newcomer features based on whether an edit window was open or not when the create an account link was clicked, but further research might show better ways to decide what kind of welcome would be most effect for a given account creation context. — Wug·a·po·des 04:34, 31 March 2024 (UTC)
There are surely lots of interesting remarks in the paper that had to be left out in the review (I do encourage folks to read the whole thing). But this particular conclusion was actually already summarized in the overall findings as quoted in the review: "Our intervention appears to distract newcomers who were already in the process of contributing, but seems to support those who were not, and in particular those who did not create an account with an intention to contribute."

Either way, I agree that this is an interesting takeaway. I guess from an UX design perspective it's a good reminder that one should always be aware of the possible downsides and opportunity costs of a particular design feature (here: distracting users from their intended task).

It's interesting that the team appears to have previous have worked from somewhat different assumptions, if I read this 2021 post correctly:

The Newcomer homepage was the second project built as a result of the usability testing of our earlier work, where we noticed a lot of test participants expected a dashboard or some homepage to orient themselves.
[...]
Based on foundational research and cumulative feedback from previous experiments, we knew that many newcomers either arrive with a very challenging edit in mind (e.g., write a new article from scratch) from which failure becomes a demoralising dead-end, or else they don’t have any edits in mind at all, and never find their footing as contributors. The “Suggested edits” module offers tasks ranging from easy tasks (like copyediting or adding links), to harder tasks (like adding citations or expanding articles) that newcomers can filter to based on their specific interests (e.g., copyedit articles about “Food and drink”). This feature is intended to cater to both groups – a clear way to start editing for those who don’t know what they want to do, and for those who do have a difficult edit in mind, it provides a learning pathway to build up their skills first.

I.e. in 2021 they assumed that there basically exist two relevant groups of newbies, those who need be encouraged to edit, and those who already want to make an edit but need to be discouraged from overly ambitious tasks and steered to easier edits first, both of which would be helped by the Newcomer Homepage. Per earlier parts of the same post, the foundational research that this had been based on was qualitative in nature, focusing on user interviews and constructing user personas. The quantitative results in the paper show that this was not the full picture, and vindicate the notion that such assumptions must be tested with the actual user base. The 2021 post also highlighted, commendably, that A very important work principle we try to keep in mind is that experiments fail. When we see something is not working, we try to make a clean stop and take learnings from that failure to make the next experiment better.

PS: It's also interesting that the 2021 post reported quantitative conclusions that are very different from those of the later paper:

Since its launch, and as we added more editing guidance and improvements to the homepage design over multiple iterations and variant tests (a subject for another post), we’ve seen steady increases in edits and number of editors using it. In other words, the release of this experimental feature ["Suggested edits"] saw us succeed in increasing editor activation and retention. 🙌 🙌
HaeB (talk) 06:06, 31 March 2024 (UTC)
If you are curious of the Homepage, you can test it at special:Homepage (which might require to activate it in your Preferences). The coordination around Growth features at English Wikipedia is at Wikipedia:Growth Team features. Trizek_(WMF) (talk) 07:58, 2 April 2024 (UTC)
Thanks, @HaeB, for summarizing the Increasing Participation in Peer Production Communities with the Newcomer Homepage paper for the Signpost. That paper was published in 2023, but from experiments run in early 2022. In the last couple of years the Growth team has completed several other projects and research experiments, many of which have had more promising results: Add a Link, Add an Image, and Leveling Up.
I think it's worth highlighting that the Growth team almost always makes improvements to features once we have initial experiment findings. Sometimes we run a secondary experiment after making those improvements, but sometimes we don’t have the time and resources to run a complete follow-up experiment. For example, in this experiment we saw that Growth features were clearly helping certain user groups, but seemed to distract people who were already mid-edit when they created an account. We then implemented a change so these users no longer receive a Welcome survey or prompt to visit their Newcomer Homepage while mid-edit (T310320). So, as Wugapodes suggests, we now take into account what the user was doing at the time they created an account. We’ve always hoped to eventually personalize onboarding further, for example, the onboarding process for someone who signed up to “create a new article” should likely look different than for someone who signed up to “fix a typo or error in a Wikipedia article.” That work isn’t on our immediate roadmap, but we have many ideas shared in Phabricator (T353301 & T229865). We welcome further ideas about new editor onboarding and retention on the Growth team’s Talk page or join the English Wikipedia conversation at Wikipedia:Growth_Team_features. Thanks, - KStoller-WMF (talk) 17:51, 2 April 2024 (UTC)

Special report: 19-page PDF accuses Wikipedia of bias against Israel, suggests editors be forced to reveal their real names, and demands a new feature allowing people to view the history of Wikipedia articles (11,450 bytes · 💬)

Individuals be complaining about Wikipedia when Israel is criticized in any way, bruh. The WJC's piece is also poorly researched; they couldn't even look for the history tab? --Firestar464 (talk) 22:52, 29 March 2024 (UTC)

I can't believe they cited both Tripodi (2021) AND Klein (2023). Now with Lir (2024), we have completed the holy trinity of bad research that fundamentally misunderstands what this website is. Curbon7 (talk) 22:55, 29 March 2024 (UTC)

Weirdly, Klein interviewed me for that paper, and the one thing not included was the actual limitations of Wikipedia's structure allowing biased content *without* "moderators" being biased about a topic... (t · c) buidhe 23:01, 29 March 2024 (UTC)

Without getting into the weeds, when it comes to 'bias', I sense a pot-kettle scenario with this set of accusations. But keeping this to a dry, technical consideration, we cannot expect to have only editors sans bias, as every editor has bias. Bias can even be thought of as one of many natural motivations for doing the work of editing here. But it's how our policies/guidelines rein these biases in that's key here. We are constantly reminded to find the most balanced way to present a topic, and I posit that the more experience an editor accumulates, the more they are attuned to try to set their biases aside as they write. I surmise that the true underlying complaint, as it were, is that what we call reliable sources are actually becoming less biased in their coverage of Israel (the government, not its people), and that feels like increased bias from the Israeli POV. To wit, the US media used to be hard-biased in Israel's favor, and recently, that has softened (as far as I can tell). And since that's where we source much of our material from, the rest follows. Wikipedia is not exactly detached from the media universe or the global (political) culture, and when those things change, our content is naturally affected to a degree. Any expectation that the Wikipedia find some kind of special detachment seems specious without specific serious proposals that don't violate our editor's privacy rights or make this site too difficult to work on while somehow achieving a less biased result. But what's funny here is a "Wikipedia without any bias" would likely end up being an object lesson of "be careful what you wish for" for those lodging the complaints. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 00:08, 30 March 2024 (UTC)
Wikipedia has some degree of Western, anglophone bias regarding pretty much any topic where that is relevant. (t · c) buidhe 00:25, 30 March 2024 (UTC)
Indeed, as it's the English Wikipedia, as much as we try to avoid it via policy/guidelines, our work here is going to reflect some degree of the bias of the vast majority of English speakers. But I posit the complaint is that in this area of concern, the Western bias is perceived as mildly easing toward a more global view. The prior staunch defense of the Israeli government in the media is now less staunch. And we reflect that media. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 00:34, 30 March 2024 (UTC)
There are three aspects of this: the bias of our sources, of ourselves and of our readers. Hawkeye7 (discuss) 03:54, 30 March 2024 (UTC)
If you can't be bothered to run your article through a basic spell checker, why should anyone take you seriously? "Beurocrats", lmao. ~~ AirshipJungleman29 (talk) 00:34, 30 March 2024 (UTC)
you scared me with this, as i thought there was another egregious typo i'd have to fix after publication lmao ... sawyer * he/they * talk 00:40, 30 March 2024 (UTC)
The report misunderstands policies and makes vague assertions instead of providing conrete examples of bias. And it's very poorly written, I don't believe this took more than an afternoon or two. --Xacaranda (talk) 00:39, 30 March 2024 (UTC)
Another example of being poorly written is the misuse of title case. Alfa-ketosav (talk) 19:00, 1 April 2024 (UTC)
Excellent report, on the whole. One little thing, this clause about "... a link to the complete history of every article has been a central element of the top of every Wikipedia page since the year 2002" is not quite right. Last week a troll made a threat of sexual violence in Wikimedia Commons against a respected Admin. I undid the edit, and soon another Admin wiped out all record that I could see of the event. This was entirely the right thing to do in this case, and has been occasionally done, not just in Commons personal Talk Pages but in WP articles. So, we ought not imply that it never happens. Jim.henderson (talk) 00:40, 30 March 2024 (UTC)
good point! i've added that detail :) ... sawyer * he/they * talk 00:46, 30 March 2024 (UTC)
And I've tweaked it further. Graham87 (talk) 10:38, 30 March 2024 (UTC)
"strong opinions being expressed on the talk page" Which talk page? Please include a link. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:09, 30 March 2024 (UTC)
the talk page discussion was linked earlier in the report at A long discussion ensued, but i've reworded it a bit for clarity ... sawyer * he/they * talk 19:50, 30 March 2024 (UTC)
WJC perceives an anti-Israeli bias seems like a bit of a duh conclusion, although the report itself is impressively poorly researched. AryKun (talk) 15:21, 30 March 2024 (UTC)
I'm not buying it. I've been accused on-wiki of being biased against Israel for creating Palestinian law, and off-wiki and publicly doxxed (actually getting into a shouting match on the NYC Transit Subway and being trolled on "X", formerly known as Twitter) for being biased against Palestine. Our coverage is fair. Bearian (talk) 15:52, 30 March 2024 (UTC)
And they wonder why we don't want to force editors working on our most controversial articles to doxx themselves. AryKun (talk) 16:06, 30 March 2024 (UTC)

If your goal is neutrality, and partisans on both sides scream that you're biased, that's a strong indicator that you're doing a fine job. Seraphimblade ^{Talk to me} 00:13, 31 March 2024 (UTC)
Just stopping by to say I really appreciated this Signpost report, and in particular the writeup from JPxG. It made for interesting reading, noting both the things Wikipedia does well and the areas where we don't, and was impressively detailed. Nice job. --Yamla (talk) 11:32, 1 April 2024 (UTC)
I liked the part about how they based their conclusions in part on, "interviews with Israeli Wikipedians". Someone needs to introduce this 'researcher' to the concept of Selection bias. --21:09, 1 April 2024 (UTC)
WJC will just not stop falling off, will they. Orchastrattor (talk) 05:52, 2 April 2024 (UTC)
Anti-Israel & anti-Jew bias is far from the biggest problem on Wikipedia. There is far more pro western chauvinist, pro US-government bias than there is anti-Jewish bias. But hey, if this is the story that brings Wikipedia criticism into the mainstream, so be it. Philomathes2357 (talk) 19:39, 3 April 2024 (UTC)
WP-critisism isn't mainstream? Gråbergs Gråa Sång (talk) 11:27, 5 April 2024 (UTC)
I very rarely hear serious, sustained criticism of Wikipedia in the mainstream. All books on the topic that I am aware of are self-published, and Wikipedia is almost never mentioned when people discuss bias and propaganda in English-language media. Philomathes2357 (talk) 15:47, 5 April 2024 (UTC)
You can start at Wikipedia:Press coverage 2001 and advance from there. All of it is not mainstream or critisism, but you should be able to find some. "Serious" is eye of the beholder of course. That WP is user generated and has errors should be fairly sustained in critisism. Gråbergs Gråa Sång (talk) 18:36, 5 April 2024 (UTC)

You may or may not find the work of these people interesting: Category:Wikipedia beat reporters. This book [1] isn't self-published, but if it is serious is another matter. Some article talkpages has a template that lists media coverage, like Talk:Warsaw concentration camp and Talk:Recession, perhaps you can find something serious and mainstream in those. The Signpost has been known to include a "Recent research" page. Gråbergs Gråa Sång (talk) 18:44, 5 April 2024 (UTC)
Wait until the ADL follows suit and calls Wikipedians antisemitic for calling the Nakba ethnic cleansing by citing more than a dozen scholars. Literally, at this point I don't trust people who claim there's an "anti-Israel bias" in virtually anything. You do war crimes, you get talked about. Gerald WL 04:07, 8 April 2024 (UTC)

Technology report: Millions of readers still seeing broken pages as "temporary" disabling of graph extension nears its second year (37,325 bytes · 💬)

A politician in Baltimore, commenting on how long it will take to rebuild the Francis Scott Key Bridge, said large infrastructure projects usually take no less than 10 years, and most of that time is not the construction but the politics of who pays for it. -- GreenC 22:59, 29 March 2024 (UTC)

The WMF is swimming in money. As of 6/30/2023, net assets were more than $250 million, with property and equipment making up only $14 million. (source) And that doesn't include the $100+ million in the WMF endowment fund. If it would cost (say) $3 million to fix this problem, that really shouldn't be an issue.

But it doesn't look like there is any obvious technical solution - at least, apparently no one has offered any that are agreeable to everyone, at which point someone could actually add the associated price tag.

More importantly, isn't the real question whether Wikipedia's volunteer base is interested and able to use more complex solutions **to any large extent**? If not, then - at least for the next couple of years, or at least until a good technical solution presents itself, a better approach might well be an automated pass at existing graphs, to convert them to images that don't carry security risks. (Store the snipets of code and data so that they are can be used in the future, if the relevant one ever arrives.) -- John Broughton (♫♫) 23:08, 29 March 2024 (UTC)

I would have a lot more sympathy to the view of "this is hard and needs great investment" (paraphrased) if we were talking about a new feature. But this is an old feature and from the user POV, it just stopped working. Recognizing this feature isn't used in the vast majority of Wikipedia, it nevertheless provided considerable value and it is missed. Why can't an alternative, secure module be found for the common use cases, and editors given migration instructions to make that work? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:27, 29 March 2024 (UTC)

- I agree. This is not rocket science, and the WMF is indeed swimming in money relative to any normal standard. This is a hard problem, but the world is full of people sufficiently talented to solve hard problems for money, so this is a management politics problem, not a technical one. I agree with StefenTower above, I'd start by solving a very few limited use cases to get at least some partial support in the meantime, and only then think about how to implement something better. — The Anome (talk) 00:41, 30 March 2024 (UTC)
- Yeah. In my opinion, we should just go for restricting it to template editors first. Aaron Liu (talk) 01:58, 30 March 2024 (UTC)
  Indeed, while reviewing quite a few discussions for writing this article, I didn't see a good explanation why, after this edit restriction idea (option 1) had been abandoned in favor of option 2 (iframes, as a more thorough solution enabling more editors), and then option 2 was itself abandoned many months later, folks apparently didn't consider to fall back to option 1 again, as a much-better-than nothing solution. Regards, HaeB (talk) 03:00, 30 March 2024 (UTC)
  Actually, it looks like a workaround (for interactive content in general) akin to option 1 is happening right now, with volunteer developer User:Sophivorus recently announcing that
  
  it is now possible to load a specific gadget when a specific template is used in a page. This opens the door (or perhaps a window?) to interactive content using JavaScript. See for example this article in the Spanish Wikipedia <https://es.wikipedia.org/wiki/Juego_de_la_vida> for an interactive instance of Conway's Game of Life, and scroll down for more instances!"
  
  I can imagine that this has various downsides compared to a fully planned out and better resourced WMF effort (and presumably nobody is eager to reimplement the broken graphs infrastructure using this), but can't help being reminded of the term Shadow IT.
  
  (My apologies for missing this when writing this Signpost article, much of it was drafted before this announcement.)
  
  Regards, HaeB (talk) 06:31, 30 March 2024 (UTC)
  Shadow IT is an apt term, as the downsides (and upsides) are kind of similar. The major worry is lack of isolation. User javascript has full access to anything the user can do, which is a bit of a security nightmare (albeit not a new one). If every interactive thing is custom JS, the amount of custom js multiplies. It just takes one mistake, and then everyone viewing the page has their account taken over. And that is just accidental mistakes. If the number of people writing these things multiply, eventually you run into malicious people (seems particularly apt to think about right now given what happened with liblzma yesterday). That said, i do generally like the approach of giving the community low level tools, and letting them go wild. I think trying to anticipate needs is hard and its better to let the community create what it needs. Like how lua was more succesful than just adding more and more special syntax to wikitext. (i've written about that previously). Krinkle of course has some fairly compelling counter-arguments. Bawolff (talk) 15:21, 30 March 2024 (UTC)
  Well yes, this security angle was already discussed at length in the article. Do you agree with Ori that this is also a resourcing issue on WMF's side? Regards, HaeB (talk) 21:02, 30 March 2024 (UTC)
  I partially agree with him. I agree that all these problems have solutions and that more resources could make some particular solution happen (nothing we do here is on the cutting edge of computer science. Other people have had every problem we have).
  
  However, i don't think that is the problem we have here. The real problem is a product management & communication problem. Nobody agrees on what we want. Nobody is telling the community (explicitly) what is happening and what has been decided. Everyone [on the wikimedia-l thread] is talking past each other. Our issue is not solving problems. Our issue is deciding what problems to solve and owning that decision.
  
  The "temporary" graph error message is a perfect demonstration of the problem. It would be totally reasonable for WMF to fix graphs. It would be totally reasonable for WMF to decide its not worth it to fix graphs given their lack of use, and just tell everyone - sorry its not going to happen. At least people could get closure on the issue and move things to alternative solutions. What is unreasonable is just letting the status quo sit there in limbo for 2 years. No amount of extra resources can fix the problem where nobody is willing to make a decision and own it publicly. Bawolff (talk) 23:00, 30 March 2024 (UTC)
It should perhaps be emphasized that option 1 would need to be very, very restrictive. There are currently a grand total of nine interface administrators for the entire English Wikipedia, and one of them is User:MusikBot II. Why is it so restricted? Because an "evil" interface administrator would have de facto superuser privileges for the wiki. They can do at least all of the following:

Cause any logged-in user to perform any action their privileges allow, without that user being aware of the fact, the next time that user loads a page. For example, exercise CheckUser or Oversight privileges when someone with CheckUser or Oversight loads any page on the wiki.
Hide any log entry from everybody, by removing it with JavaScript. Can combine with suppression (via the previous bullet) to make it much harder for anyone to figure out what happened.
Hide or disguise the contents of any page on the wiki, as well as its history. Again, this combines well with suppression.

The only way around this problem would be for someone to manually read the source of the page with "view source" and spot the rogue JavaScript code (which can be obfuscated or minified as desired). Now, let me ask you a question: When you edit or even just read Wikipedia while logged in, do you check the source for rogue JavaScript? I know I don't. --N Y Kevin 20:16, 11 April 2024 (UTC)

The continued failure to re-introduce graphs is the latest, most visible instance of Wikimedia's complete inability to do software projects. There are plenty of talented developers who work there, but for some reason the foundation can't project manage their way out of a paper bag. "We plan to, in a couple months, release the date for when we'll have a roadmap for doing the development" is a deranged statement for any software product feature. They could have implemented non-interactive graphs in a month with a single developer. Heck, it's been so long now they could have implemented interactive graphs from scratch. I get that this isn't a priority for them, but I can't help but notice that pretty much every single feature they work on has absurdly long timelines to produce anything. --Pres N 02:23, 30 March 2024 (UTC)

A somewhat related discussion is ongoing at Wikipedia:Village_pump_(WMF)#Proposal:_WMF_should_hire_a_full-time_developer_to_do_basic_maintenance_on_MediaWiki. Regards, HaeB (talk) 02:53, 30 March 2024 (UTC)

WMF already has significantly more than one FTE working on maintenance (however you define that). I'm not going to claim WMF is perfect in how it prioritizes things, but they have many people working on maintenance type things. Nobody really notices because maintenance is thankless work. Bawolff (talk) 05:10, 30 March 2024 (UTC)

People have no clue how much work and people are required to keep the thing running (mostly) as is. However that is still way too few people to make things evolve quick enough, let alone deal with major problems like these or dare I say the 2030 ambitions.

The biggest issue is that we have all the downsides of a company and all the downsides of a volunteer foss project at the same time. —TheDJ (talk • contribs) 11:31, 30 March 2024 (UTC)

I agree. Recall the period 2005-2008. Forget graphs, everything was down, frequently. And this argument they have pools of money. The US Federal Government has the biggest budget of any institution in the world, and as everyone knows, they are the best run institution in the world... the more money there is, the harder it gets to manage due to politics and special interests, and the more complaints there are. But I can't help returning to the core fact, WMF overall does a pretty good job when you consider what they facilitate. -- GreenC 16:03, 30 March 2024 (UTC)

we have all the downsides of a company and all the downsides of a volunteer foss project at the same time - that's an interesting thought, do you want to elaborate on that? (I know you have been a longtime observer of such matters, so maybe you already wrote about this elsewhere - feel free post a link.) Regards, HaeB (talk) 21:08, 30 March 2024 (UTC)

The advantage of a company with money supporting a software project is that it has resources that it can bring to bear to resolve issues. For example, usually better user support is possible with more resources, as more testing can be performed in more environments. The downside is that with any sizeable project, it can't do everything at once, so it has to prioritize what to do. This means balancing the concerns of the various stakeholders, such as what benefits users (readers and editors in the case of Wikipedia) and the company's objectives. But this also means that companies are often less nimble. One reason is that they have to be able to maintain as much support for their user community as possible, whereas volunteer developers are free to pick slimmer segments of the community for their work. Another is prioritizing dollars spent means having to allocate effort towards making those decisions, and considering the effect of their decisions. (I think part of the problem with the graph situation is that no one on the WMF dev team wanted to be the one to tell the community that they just weren't going to support Vega anymore, knowing it would make people unhappy, and so they tried and continue to try to find a way forward while still using Vega. The result of that is unfortunately drawn-out uncertainty, making planning difficult.)

Volunteer projects are frequently hard up for skilled technical volunteers, and without defined commitments of effort, it's hard to set deadlines or make a roadmap for very far into the future. Thus short turn-around projects can get more easily done than longer-term ones. Putting out version 1 of a feature with limitations on users can fit. Moving that to full support for all users and managing long-term sustainability, such as resolving third-party component dependencies across the entire product, is a long-term project. If the initial volunteers lose interest, then it can be hard to find anyone to pick up the work.

In the context of Wikipedia: the WMF has resources, but it has to spend a lot of them on keeping a large project stable and working for a large community using a wide variety of platforms. By default it has to pick up support for code that was written from many developers no longer involved. All of this makes the speed of development slow. (In general, the industry tries to combat this through lots of automated testing and trying to keep the code in a ready-to-ship state as much as possible. It's a difficult problem for everyone, nonetheless.) This increases the time investment required for volunteers which discourages them. There are certainly dedicated volunteers who have spent a lot of time on Wikimedia software, and their contributions are highly valued. But the reality is that there are lot of choices for where people can spend their volunteer time, and absent targeted recruiting, it's hard to get the right helpers. isaacl (talk) 03:02, 31 March 2024 (UTC)

Thanks for sharing this perspective. This largely matches what I have observed about the dynamic between paid and volunteer contributions to open source. In addition to automated testing, clarity about API capabilities and versioning is another technique that I have seen successfully support diverse contributions and usage, while also enabling more predictability for maintenance needs over time. SDeckelmann-WMF (talk) 19:49, 1 April 2024 (UTC)

I find the comparison to WolframAlpha very silly. WP:NOT is among our largest and most referenced policies because, as it turns out, including too much information in a reference work makes it less useful. We have a lane and we should stick to it. Mach61 04:47, 30 March 2024 (UTC)

I agree with Tisza and TheDJ; we should be focusing on getting the basic graph functionality running rather than trying to devise interactive solutions. While the fanciful visions of interactive content may sound all good and nice, fact is that we've got something broken, and the vast majority of use cases don't currently require interactivity. So we should expend the energy on fixing the broken thing and then the interactive stuff can be added later. And flashy graphs with complex interactive features are better served by other sites anyway; we shouldn't try to be everything to everyone. ― novov (t c) 05:13, 30 March 2024 (UTC)

This problem with tables is only the most glaring example of software problems that don't get fixed. It takes a lot of resources, and I figure those resources ought to be beefed up. Amateurish enthusiasm works all right for editing articles, surprising as it may seem, but software coding seems to be a more delicate kind of clockwork. My own little problems are mostly with the interworkings of the WP App, Commons App, Wikidata, and their various mapping methods. They do not connect to each other neatly, and when teaching new editors we have to introduce them to various workarounds. I like to think there must be some other part of the budget that could be robbed to pay for better software, not just for tables but for mobile. The mobile site is good enough for readers, but it's poor for editors, and the internal mobile apps are what ought to work together to make life easier for mobile editors. Jim.henderson (talk) 15:33, 30 March 2024 (UTC)

First, HaeB, thanks for this write-up, I really appreciated getting up to speed without having to read all the mailing list discussions. In my view, this comes down to two lines:

the path forward will require a substantial investment – one that we have not yet started given the other priorities we’ve been working on

and

Still, on English Wikipedia, only 19,160 pages were affected.

The WMF isn't going to spend millions of dollars to fix something that's only a problem on 20k enwiki pages. Bottom line is bottom line, unfortunately: graphs aren't popular enough to care about, by and large. Personally, I think they're great and could be profitably used on millions of pages, but you can't argue with the fact that they just aren't very popular, not very widely used, and thus low-priority when compared with other features that are more widely used. Levivich (talk) 16:41, 30 March 2024 (UTC)

Meanwhile, the fact on how essential it is to the Arabic 'pedia is interesting, though it's debatable how much influence over the projects as a whole it has. Aaron Liu (talk) 16:55, 30 March 2024 (UTC)

Even that is significantly over-stating the impact. Most of those 20K pages are talk pages not content pages. Of the content pages, it was largely used for static graphs where an uploaded png/svg would serve the same purpose just as well. Much of the damage here is self-inflicted. Instead of replacing graphs with something that works when possible, we have replaced them with a giant error message, in the hopes that the ugliness of the error would blackmail WMF into re-enabling the feature, which clearly did not work. Bawolff (talk) 17:00, 30 March 2024 (UTC)

I think I would be willing and able to develop a Lua module that replaces the Graph extension for the most common use cases (bar charts, line graphs and maybe even pie charts). However, the Wikimedia Technology Fund has been marked as Permanently on hold with no explanation given (at least that I know of). Perhaps this year I'll find the time and energy to attempt it as a volunteer, but it would really help to get some compensation for it, since it will require a lot of time and effort that I could otherwise spend in remunerated work, or just reading a book. Sophivorus (talk) 23:01, 30 March 2024 (UTC)

We already have bar charts that are ready to use (see Template:Climate chart). OhanaUnited^{Talk page} 06:42, 31 March 2024 (UTC)

We also have {{pie chart}}, but these all feel less satisfying than graphs did. Aaron Liu (talk) 14:34, 31 March 2024 (UTC)

Good point, but that's a bit "We have graphs at home" ;) This template existed long before the Graph extension, so it seems that the latter was meeting some needs that the former left had left unfulfilled. Regards, HaeB (talk) 06:43, 1 April 2024 (UTC)

We probably don't want any more modules that use HTML and CSS to create graphs. It is essentially one big hack. I would advise technical contributors who have the time to instead consider working on phab:T334372 or phab:T66460, which would enable creating SVGs via Lua. The benefit would be that the resulting graphs would be real images that can be indexed by search engines, copied, downloaded, etc. Today's lua-generated graphs are just elaborate HTML structures with which none of that is possible. – SD0001 (talk) 18:24, 31 March 2024 (UTC)

Hello everyone. I'm Marshall Miller; I'm a Senior Director of Product at WMF (I was quoted in the article above), and I work with teams that build features for the reading and editing experiences (e.g. Discussion Tools or Night Mode). Thank you all for thinking about and discussing the graphs issue. I know that it is frustrating that this remains unresolved -- it has been a deceptively complex problem, involving issues around security and scalability. I just wanted to post here saying that I am following this discussion, and that I have been working with colleagues to propose a path forward for graphs. We'll be resuming the discussion and updates on Meta, and I will also post a link here once there is a new update over on that wiki. -- MMiller (WMF) (talk) 05:06, 31 March 2024 (UTC)

Has WMF appointed a single-threaded owner for this? I wouldn't be surprised that no progress occurs if the person handling Graphs also happens to be working on Discussion Tools and Night Mode. They would just choose to spend their time on the less challenging assignments. – SD0001 (talk) 18:47, 31 March 2024 (UTC)

@SD0001 -- I'm sorry for the confusion; let me try to clarify. In my role, I am the manager of several product managers, each of whom is part of a product team. One of those several PMs works with the Editing team on Discussion Tools and another of those PMs works with the Web team on Night Mode. I just mentioned those two features to give examples of the sort of things my broader team is responsible for. I'm the point person for Graphs right now, as this is a complicated situation that spans the expertise of multiple teams. Does that all make sense? MMiller (WMF) (talk) 04:42, 1 April 2024 (UTC)

I agree with the frustration, but.... Those of you who consult resources hosted by the British Library are aware of the cyberattack that brought down their system in October. Some of the functionality is still not there and won't come back until the architecture is redesigned (see the report Learning Lessons From The Cyber-Attack). Security threats are real. I suspect most people would not want Wikimedia projects to be hacked and all off its content erased in such a way where it was not retrievable. Perhaps the best way forward is to ask WMF to devote more resources to security and replacing those parts of the infrastructure which are at risk. - kosboot (talk) 14:49, 1 April 2024 (UTC)

Just FYI the security risk graphs presented were more of either a mass account takeover, or to be used as a launching pad to attack users (e.g. to distribute malware). Data deletion/ransomware was probably not a threat from this particular issue. Bawolff (talk) 16:00, 1 April 2024 (UTC)

I find it hilarious that they had enough time, effort, and energy to debut the unwanted vector 2022 mandatory "upgrade", but can't (or won't) get this fixed. Incompetence be thy name, foundation. TomStar81 (Talk) 21:12, 1 April 2024 (UTC)

Vector 2022, which is just CSS ~~and normal PHP~~ and a smatter of JS, does seem a lot easier than graphs. Not to mention that they spent 4 years on it anyway. Aaron Liu (talk) 21:42, 1 April 2024 (UTC)

I, for one, did want the Vector redesign and welcome it much, and if it took more time and effort than it should have, I'm sure it's because of the unending complaints and the impossible attempt by the foundation to please everyone. I sometimes wish developers listened less to users and just do their job. — Preceding unsigned comment added by Sophivorus (talk • contribs) 18:42, 1 April 2024 (UTC)

In addition to updating CSS being much easier than patching the Vega security hole, V22 is on 100% of articles, graphs are on less than 0.3%. Apples and oranges. Levivich (talk) 23:46, 1 April 2024 (UTC)

Not to mention its a totally different skillset. Being a developer is not just one skill. The people who work on vector would not be the people who work on graphs and vice versa. Bawolff (talk) 16:49, 2 April 2024 (UTC)

I get that the security problem with graphs was a zero-day vulnerability, but the level of visibility to readers meant a zero-day fix was needed. Instead we have had nothing but delay and misleading claims from the WMF. This is an ongoing embarrassment that, it seems, could have been avoided by a temporary, low-quality solution (like replacing each graph usage with a PNG image and then disabling graphs). I'm sure there are valid questions to be asked about interactivity and desired functionality, but it seems to me that the WMF would have been better to say "you're on your own, kid" on day zero and en.wiki volunteer programmers and editors would have had a mostly working solution rolled out months ago. — Bilorv (talk) 23:39, 3 April 2024 (UTC)

But a zero-day fix was implemented: Graphs were disabled. That's all a security response requires, mitigation of the exposure.

Beyond that, should the response have focused on eliminating the interactive graphs entirely? Perhaps. Though I don't feel like we can blame the WMF for us not doing that.

For example, the article mentions Another Wikipedian reported that "In ruwiki, interactive Lua-based graphs are used in more than 26000 articles about settlements and administrative units through https://ru.wikipedia.org/wiki/Module:Statistical. The primary uses of ruwiki Module:Statistical are in templates like ruwiki Шаблон:Население ("Template:Population"), which for years has had the ability to format population data as either an interactive <graph>, or a pure-HTML-based bar chart. When Vega went offline, instead of displaying the "can't do that" message, they simply updated their template so that all requests for the graph version instead get the HTML bar chart. It's less satisfying (note: discussion in Russian) than the interactive graphs, but it conveys most of the same data.

Here on enWiki, OTOH, seems to me we've either wrung our hands about either the WMF not fixing graphs fast enough for our tastes, or complained about them not giving us permission to work around the absence of graphs. ...Do people feel that's an unfair characterization? ruWiki didn't need the WMF's permission, why do we? FeRDNYC (talk) 01:24, 4 April 2024 (UTC)

A quote from the top of the article from a WMF employee: "My hope is we can maybe restore some functionality in the next week or so". Given this it was reasonable to revert and delay attempts to replace graphs at the time. The point I'm making about the zero-day issue is not a security one but a reputation one. The zero-day fix needed for reputational purposes was restoring the information that was encoded into graphs (even in a lower-quality format). — Bilorv (talk) 15:41, 4 April 2024 (UTC)

OK, but "zero-day reputational vulnerability" is a nonsense thing you just made up. FeRDNYC (talk) 17:11, 6 April 2024 (UTC)

It is worth noting, I think, that parts of the problem have been solved. For example, the much-discussed Template:OSM_Location_map, used by 5,600 pages on the English Wikipedia, is functioning again since 11 March 2024, with some newly added features. See the Return to service article. On the other hand, those 5,600 pages were not included in the count of 19,160 -- a count that underestimates the true impact of the problem, leaving out all the templates that are indirectly rendered inoperable. Renerpho (talk) 07:46, 5 April 2024 (UTC)

Well, the article does allow, (Those numbers likely already reflect the manual removal of broken graphs from many pages.) But it goes on to say:

In a more detailed 2020 analysis, volunteer developer User:Bawolff had found that "the graph extension is used on 26,238 pages [on English Wikipedia]. However, most of these are in non-content namespaces, from a template that generates a graph of page views for a specific page (w:Template:PageViews graph). There are 4,140 pages on wiki.riteme.site in the main namespace that use graphs."

That information appears roughly consistent with both the numbers discussed here (19,150 + 5600 = 26,750), and the current contents of Category:Pages with disabled graphs — which is actually down to 18,249 pages now, but is still overwhelmingly dominated by Talk-namespace pages. Since the analysis was done in 2020, when graphs were working, it wouldn't have been biased by any manual removals. We can assume that the numbers would've gone up a bit since, and the fact that Category:Articles containing OSM location maps alone contains 5319 members (and AFAICT is restricted to mainspace) bears that assumption out. So that 4,140 is obviously a bit out of date.

(Aside: Category:Pages with disabled graphs does still include Template:OSM Location map itself (despite it having been returned to service), because the category is manually added in the template's source for some reason. But it's done in the <noinclude> documentation section, so that it's only applied to the template itself, not its consumers.)

Beyond that, I don't see how the count underestimates the true impact of the problem, leaving out all the templates that are indirectly rendered inoperable. The tracking category is populated by MediaWiki itself, and any use of <graph> in a template, no matter how indirect, would cause every page that transcludes the template to be counted. It's only the pages where the transclusion was removed (as the article notes), or where the transcluded template was modified to eliminate its use of graphs (like {{OSM Location map}}), that wouldn't be counted. FeRDNYC (talk) 17:00, 6 April 2024 (UTC)

-- This subject demonstrates Wikimedians' propensity to blather on, building towering walls of text in place of taking action. The way forward seems blindingly obvious: implement a safe static graph facility while separating off the issue of whether and how to provide dynamic and/or interactive graphics safely. The most efficient way is likely to be to subset the Vega framework (or just syntax) to those constructs that can only produce safe, static code. The point is to actually act on that rather than talk about that. --R. S. Shaw (talk) 23:09, 8 April 2024 (UTC)

Your most efficient way has been discussed. I can't find the specific discussion right now, but the conclusion was that Vega's syntax was too complex to provide a viable subset or sth like that Aaron Liu (talk) 23:44, 8 April 2024 (UTC)

How many of the 4,000 articles that use broken graphs use only pie charts or bar charts? There are working templates for both of those,[2][3] so long as you don't miss the hover-over feature. And you shouldn't miss it. Pretty sure most users just want a simple, easy-to-read image in most cases - before they spend millions on making something, they should check if people would actually find it more useful. Wizmut (talk) 03:44, 10 April 2024 (UTC)

Line chart? Aaron Liu (talk) 11:37, 10 April 2024 (UTC)

Hello everyone. I wanted to follow up here on my earlier comment above. I just posted an update to the Graph project page laying out a proposal in which WMF would build a new extension for making graphs. We've come to this proposal after talking to community members over the past weeks, analyzing data, and thinking through architecture with staff. This would be a substantial amount of work, and I hope that community members can weigh in on whether this seems like the right approach and to help us plan the project. Please join the discussion on the talk page! -- MMiller (WMF) (talk) 23:15, 10 April 2024 (UTC)

OWID

We at WikiProjectMed have funded the building of a template which first shows a still graph from Commons. And than once consent is given by the reader shows the live version piped in from Our World in Data. It is live at eu:Haurdunaldi#Nerabezaroa. Thanks to User:Bawolff who did the programing. We still need to figure out translation aspects. Doc James (talk · contribs · email) 21:40, 16 April 2024 (UTC)

Traffic report: He rules over everything, on the land called planet Dune (0 bytes · 💬)

Wikipedia talk:Wikipedia Signpost/2024-03-29/Traffic report