Jump to content

Abstract Wikipedia talk:Response to English Wikipedia criticism

Page contents not supported in other languages.
Add topic
From Abstract Wikipedia
Latest comment: 2 days ago by Sannita (WMF) in topic Closing discussion

So fix it

[edit]

The criticism started on 25 March, only a week after releasing the beta version of Abstract Wikipedia. Instead of looking into it and trying to understand the causes and fixing it the first reaction is criticism. I understand that large Wikipedia communities are hesitant (to say the least) on allowing Abstract Wikipedia articles on their Wikipedia, you could at least be more cooperative, empathetic and help fixing it. HenkvD (talk) 20:50, 6 July 2026 (UTC)Reply

I know that this reply may court controversy since it runs afoul of AGF, but: Can we even really say that w:en:WP:VPW is representative of the English wiki more broadly? It's basically the WMF haters' club board at enwiki. Which, I certainly understand the broader criticisms of the Foundation. But to assume that the particular talking points vis-a-vis Abstract Wikipedia are made in good faith boggles the imagination. Would any other WMF-hosted wiki consider it worthwhile to address uninformed chatter on another language edition's wiki? I doubt it, because of the overall pattern that wikis have independence of governance. Arlo Barnes (talk) 20:14, 7 July 2026 (UTC)Reply
This reply made me chuckle - yeah, I agree. The people at VPW are generally more emotional about there stuff. There was some guy in the thread that made insults towards WMF staff like seven times, before some other guy told him to be quiet.
There are completely valid concerns which I agree with a lot, but many people there seem to have a false assumption that AW is meant to "replace" the language-versions of Wikipedia. It's not.
There probably came a point where the WMF learned to largely tune out what is happening there. EatingCarBatteries (talk) 06:58, 8 July 2026 (UTC)Reply

English centric?

[edit]

Yes the functions might be English centric at first, but not as bad as is being portrayed. As with Wikidata the names of the functions can be translated, as can the input labels. And gradually the functions are written for other languages. In case the functions are not yet tailored for an other language the English text, or parts of texts were shown in English. As that was not marked as such it gave a very distorted image of the situation. We are (I am) working on marking those default texts to make that clear. But it is difficult as currently no HTML codes like <span> can be used to highlight default texts. Instead of that I currently use texts like ❌≪NLG Default text≫❌, but the goal is to replace it by NLG Default text by the HTML text <span style="color:magenta;">NLG Default text</span>. HenkvD (talk) 21:05, 6 July 2026 (UTC)Reply

I think the current (at time of writing) wording of the response is fine. WF is Anglocentric and Eurocentric, and like WD etc., it will probably always be Anglocentric because that is the international lingua franca. (I'd like to see a bit more globalisation in Project-space, but I'm not sure that's where the criticism was being directed.) The Anglocentric bias has already caused some problems with NLG functions, but the next generation of NLG functions is being designed and will be more accommodating. And as you say, we'll build mechanisms for CTAs in generated text (@ copyeditor maybe mention that in this section). YoshiRulz (talk) 15:23, 8 July 2026 (UTC)Reply

Developers and budget

[edit]

The emphasis of the criticisem lies heavily on developers and the budget for the development project. The functions and the result of those functions are (to be) written by the community. Any error in the functions is NOT related to the effort of the development project, but on the communities of Wikifunctions and AbstracWikipedia. As this is very much in Beta it unfair to blame that on the development. HenkvD (talk) 21:11, 6 July 2026 (UTC)Reply

That's true, but at some level, developer time+money (or lack thereof) is to blame for the endless timeouts and flakiness. And we who write all the functions, surely we'd be more productive if the servers had limitless computing power? I wonder how different the project would be if it had the same devs and management but was bankrolled by, say, Anthropic (Q116758847) or Meta (Q380). YoshiRulz (talk) 15:47, 8 July 2026 (UTC)Reply

Thoughts

[edit]

It's great to push out a detailed response. Here are some mixed thoughts I have:

  • Much of this is vague. I understand that "response" aritcles written by organizations typically are so, but it's important to be more concrete about intentions/plans to the audience because we are a wiki-style model. For example,

    We hear this criticism: we will improve our documentation, aiming to make it more up to date, and easier to navigate.

    This just reads as an empty promise - I suspect many people at VPW will be ticked off reading it. It's vague enough that you could just update the docs once and add one more hyperlink and call it complete. It's okay if you don't currently have plans, but throw out some ideas and invite people to give feedback.
  • When asserting that other projects have successfully done natural language generation, you could list which languages they support and any shortcomings that they may have (that Wikifunctions can solve)
  • One reply I noticed on enwiki mentioned how unapproachable AW is, to the point where even though they know a foreign language (in this case Hungarian), they have no idea where to start. Ultimately, editing on AW requires knowledge in AW, Wikifunctions, and Wikidata. That is too much for many people.
  • You could start with a short high-level overview on what your intentions for AW is (to reiterate that it's not gonna replace content on articles), and you could end with clear-cut examples (with links) on how editors can help contribute (for example, by adding Wikidata lexemes in their language)

EatingCarBatteries (talk) 07:11, 8 July 2026 (UTC)Reply

Seconded on the corpo-speak. If I wanted equivocation I'd ask an LLM.
I elaborated on this in my other comment, but regarding documentation and roadmaps, you can't have too much (assuming what you write is actually content and not filler).
Regarding new users, on top of more and better documentation, the main page could do with a makeover. I assume the AW team has put some thought into what kinds of editor they want and where to direct them, but that hasn't translated (no pun intended) into changes to the main page, f:Help:Contents, or f:Help:Multilingual. YoshiRulz (talk) 16:57, 8 July 2026 (UTC)Reply
I feel the need to reiterate again that the Wiki model is based on transparency and community feedback. This is the reason why across MediaWiki projects, virtually every single talk page across namespaces, articles, drafts, etc, have their history open. Decisions are made by community consensus, and importantly, they may be decisions that the WMF disagrees with. In the worst case scenario for this project, only a couple extremely small/niche languages will take up on this while all of the major languages ban it from their wikis.

If you don't have radical transparency for future plans, you're just asking volunteers to either quit or get burnt out. Why work towards a project when it's future is uncertain? I started to contribute functions in late March (f:Z32839), but I quickly got confused and decided to leave until the future is more sorted out. EatingCarBatteries (talk) 23:02, 8 July 2026 (UTC)Reply
Thanks for this. Unfortunately, I don't think we can do more than promise and keep the promise after that. Do you think this can be achieved with another formulation? We're open to proposals on this. Sannita (WMF) (talk) 12:45, 13 July 2026 (UTC)Reply
My trivial proposal would be to start the task before making the promise. As others have suggested, f:WF:Status is out of date and could be updated quickly by staff (it discourages non-staff ownership). --99of9 (talk) 04:29, 14 July 2026 (UTC)Reply

re: "Natural language generation feasibility across diverse languages"

[edit]

The critics were pointing at the current generation of NLG prototypes, which do suck (in terms of cross-language output, as well as being unruly to work with). So acknowledge that. Link to Project:Abstract article architectures. YoshiRulz (talk) 14:24, 8 July 2026 (UTC)Reply

IMO they were mostly pointing at the previous generation when we hadn't even engaged with HTML yet, and were trying all kinds of messy fallback strategies. Yes, that link would be good, but I'm confident are making and will make further progress even before the new architectures come online. There was some criticism of AW being a "research project", so demonstrated concrete improvement is as important as planned future improvement. --99of9 (talk) 05:58, 13 July 2026 (UTC)Reply

re: "Generated article quality"

[edit]

[...] but to produce accurate and useful content that any language community can choose to adapt or integrate to fill their current knowledge gaps. either use as a template for a local article, or use as a placeholder indefinitelythe choice will be with that community. If you're familiar with mw:Extension:ArticlePlaceholder or toolforge:autodesc, our goal is to meet and then surpass their usefulness to readers, while keeping all the logic editable on WF/AW.

  • Reiterates that each wiki decides which articles to take (since at least one of the critics still held that misconception)
  • Name-drops ArticlePlaceholder (which I feel has been the "elephant in the room", unmentioned by staff since I joined last year), and acknowledges that the current prototypes are inferior to it

YoshiRulz (talk) 14:59, 8 July 2026 (UTC)Reply

Added to the draft, thanks! Sannita (WMF) (talk) 12:40, 14 July 2026 (UTC)Reply

re: "Content governance and control"

[edit]

Link to AW policy discussions/drafts. Maybe reassure the critics by mentioning that As the system gets more expressive and articles improve in quality, poor-quality articles will become easier to spot. The community can also make new editing and moderation tools. YoshiRulz (talk) 15:36, 8 July 2026 (UTC)Reply

Slightly rephrased and added to the draft, thanks! Sannita (WMF) (talk) 12:44, 14 July 2026 (UTC)Reply

re: "Technical performance and stability" and "Transparent documentation and progress reporting"

[edit]

Keeping f:WF:Status updated would be a good start (last meaningful edit: 2025-11). I've mentioned it once or twice and was ignored... There's also f:WF:Feature petitions which we could promote more (last edit: 2026-02), then the dev team could rely on that and f:WF:BUG (last edit: 2026-07) as a summary instead of trying to keep up with disparate discussions. And it really shouldn't fall to me to write something like f:Help:Z89.
Speaking for myself, I've filed a few Phabricator tickets, but I've also just come up with workarounds for many bugs and annoyances, to the point where I've internalised them and found it jarring when one "broke" last month. This feels out-of-line, but I have to ask: do you actually use the interface you've created? And perhaps more importantly, have you ever watched someone else use it? My programming workflow would probably seem insane were you to analyse it.
edit: I didn't intend to join the critics when I started writing, but here we are... WF SUX The current "progress" of WF/AW is indeed exaggerated, and even if you look at the average function instead of cherry-picking the best, it's only impressive because it's built on MediaWiki. FP languages, language interop, FOSS libraries, and machine translation (though not NLG) were already widespread. I agree with the pushback against calling it "beta software", because the problems are in the fundamentals: for WF, type checking, debugging, recursion; for AW, data structures. YoshiRulz (talk) 17:15, 8 July 2026 (UTC)Reply

We hear you. We will prioritise this in the next days. Sannita (WMF) (talk) 12:44, 14 July 2026 (UTC)Reply

Evidence

[edit]

The current draft says:

In the discussion many examples are mentioned where output technically exists but is not considered useful, natural, article-like, or publication-ready. The concern is that successful rendering can still produce text that is grammatically incorrect, repetitive, too thin, misleading, mixed-language, or not recognisable as encyclopedic article content.
This is a concern that we share, but we have evidence that the results will get better with time, and with the expansion of the community.

This begs at least two questions:

  1. Can you present this evidence?
  2. What makes you think that the expansion of the community will actually happen?

~2026-38939-76 (talk) 14:53, 9 July 2026 (UTC)Reply

Consider broadening the scope

[edit]

If tweaked, this could become a living document that addresses common critiques / FAQs. That way it would address not only the particular enwiki criticisms at one point in time, but could become something we build on and refer to. --99of9 (talk) 06:01, 13 July 2026 (UTC)Reply

We already have f:WF:FAQ, f:WF:Status, etc. (which are out of date as-is, so yet another page won't do any good), plus all the pages on Meta like meta:Abstract Wikipedia/Related and previous work/Natural language generation. YoshiRulz (talk) 06:39, 13 July 2026 (UTC)Reply
True, so maybe we've spread to too many venues and should just reuse this content there? --99of9 (talk) 06:41, 13 July 2026 (UTC)Reply
Yes.
We should have an accessible community-consensus view of the current and future state of both Wikifunctions and Abstract Wikipedia.
This should link through (eventually) to the Phabricator tasks that are still open, and regular status updates should reflect on how both the current and future state are evolving, particularly if contributors are so preoccupied with what they are doing that the current views are getting out of date.
Just as an example, there is a proposal at phab:T429926 to create a new inert function-call wrapper, which overlaps with new function f:Z37712 and (potentially) with f:Wikifunctions:Type proposals/Wikifunctions object reference. The intended future state is that any object can be substituted by a given default alternative rather than an error, in support of the “graceful fallback” principle that was articulated back in 2020. There is no current community consensus on this future state, however.
Clearly, piecing these things together can require a lot of effort from the community, so much of it will rightly remain sketchy. A community-curated catalogue of Phabricator tickets, on-wiki, would be a good place to start, in my opinion. But that reminds me that f:Z37712 is not in the f:Wikifunctions:Catalogue yet. GrounderUK (talk) 17:05, 14 July 2026 (UTC)Reply

Closing discussion

[edit]

Hi all, due to the RfC currently going on on Meta, we decided to close one day earlier the period of discussion and publish the answer on Meta. We thank you for your opinions and suggestions, we tried to include them as much as possible in our response. As Denny said, shortcomings in this answer are staff's only, not yours. Thank you very much. Sannita (WMF) (talk) 13:44, 16 July 2026 (UTC)Reply