Talk:Product and Technology Advisory Council/August 2025 draft PTAC proposals for feedback

August 2025 draft PTAC proposals for feedback

• Draft recommendation summary
• Communication
• Experimentation
• Provide feedback

Feedback

Feel free to provide feedback, the proposals are on this page. Sohom (talk) 17:15, 6 August 2025 (UTC)

@Sohom Datta One point that could perhaps be made more explicit is: use community consensus and not (just) external surveys.

I understand the value of asking readers and users questions, and of course the wishes of the community do not always match those of casual readers 1:1, but using external surveys instead of talkpage discussions sidesteps the most valuable asset, the community. Often the quality of the surveys (the en:Research design) could've been improved by having a community discussion beforehand.

Please make en:User:Polygnotus/Scripts/Surveys.js obsolete. Polygnotus (talk) 20:45, 6 August 2025 (UTC)

One of the goal of the proposal (1) to (4) are to increase community participation and feedback in the processes leading up to the release of surveys. I don't think we should do away with external surveys (or necessarily reduce them). But, you are right that we do need more participation earlier in the process (and that's kinda also one of the conclusion the experimentation working group came to)! Sohom (talk) 20:56, 6 August 2025 (UTC)

Yeah "doing away" with them is too extreme, but involving the community at the earliest possible stage, asking for community feedback on the research design before the survey goes live, and understanding the upsides and downsides of surveys is important. Polygnotus (talk) 21:11, 6 August 2025 (UTC)

While I can envision targeting specific communities for discussion and managing feedback for a given project, I don't know how feasible it is to engage all communities (as a comment on the Experimentation page says, "but it’s different for every wiki…yikes"). Is the plan to choose lead communities to work with (which could vary from project to project)? Or will there be more resources dedicated to work with all communities and balance their interests?

A key stumbling block with community engagement is keeping volunteer contributors interested for a sufficiently long period of time. Another is getting a representative sample of concerns. Has there been any discussions on how to address these challenges? isaacl (talk) 22:46, 6 August 2025 (UTC)

To get engagement across multiple wikis, have you considered a model of keeping the discussion centralised on meta, but notifying communities that discussions are taking place? The Signpost on En Wiki and the mailing list are obvious places to notify. Plus of course presentations on meta. Also and not to be underestimated, how do we change the WMF attitude so that when the community does come to the view that something would best be killed with fire, the WMF is a tad less defensive, and much much quicker to learn a lesson and reallocate resources to something else? WereSpielChequers (talk) 20:29, 7 August 2025 (UTC)

Regarding en.wiki, I would say that centralized discussion is a more effective tool than the Signpost, as it is updated when necessary (rather than once a month) and displayed on all major noticeboards. Chaotic Enby (talk) 20:45, 7 August 2025 (UTC)

I like some ideas, such as building a central overview of the current projects and providing guidance to help community members find relevant discussions. However, I am afraid that having a specific PTAC group in charge of that might make it too closed-off, and insulate the WMF from the wider community. Some points such as Should the community have a say in the failure criteria or if the experiment takes place in the first place (counterpoint: the community often might not have the domain knowledge to evaluate and understand the context behind the experiment or might have inertia towards certain features, for example, Vector 2022) read as condescending and underestimate the ability of folks beyond PTAC to be of help. Notably, it makes sense that community members without domain knowledge would be less likely to participate either way, while those more familiar with it should have an opportunity to do so.

This also applies to issues like proposed wording changes. The broad strokes are helpful, but more people should be able to participate in refining the communication pathways and say which changes would be helpful to them, instead of providing feedback on an already-written plan.

In general, the proposal lacks openness on the side of PTAC. As WMF-appointed representatives of the Wikimedia community, the ideal should be to facilitate direct communication between the community and the WMF, rather than decide what you think is best for us. In other words, elevate community voices rather than filter and replace them. Chaotic Enby (talk) 20:44, 7 August 2025 (UTC)

• I think V'22 is a good example of failure, mostly because people using something often don't really want it to change. This will sound harsh, but I think the community, in some cases, lacks openness to change. I'm saying this as part of the community and someone who took part in releasing the original Vector to one of the wikis (I helped in introducing Vector to then a monobook-addicted community and yes, I was also addicted back then ;)). In many cases, the community needs to be assured that they will still be able to do things as they used to, but also encouraged, for those open to change, to try out new things early. It's also important to smooth out differences with configuration options, so that's not just about communication, but identifying crucial pain points and acting on that knowledge (or allow the community to do the adjustments). I work in IT, and I know how hard it is to change daily habits for people using software. Only a few people are open to experimentation and adapt quickly to change.
• What I'm also saying is that even if people have domain knowledge, they might not be willing to really test things and give them a chance (especially if the change is too big). So I think it is useful to gather participants who are willing to experiment, make sure they are from various communities, and ensure that things are really explained to them – as they will be the ones explaining the changes and options to their communities. That's why I think having domain knowledge is not actually the key factor. The key factor is explaining things to those who are willing to listen, test, and spread the information further.
• I also want to note, not sure if this is obvious, that this group of early testers, early adopters, probably shouldn't be the same group for every project. Even those willing to experiment might not want to do so all the time or with all things. I know I wouldn't want to be engaged in everything, and I could easily burn out if I tried.

Nux (talk) 10:57, 12 August 2025 (UTC)

As someone who is definitely open to experimentation and change (and would like to see more folks in the community be like that), I absolutely agree with your points! Getting early adopters for feedback is a great idea, although at the same time we should be careful of not just selecting a crowd of yes-men, and that's one of the reasons why I believe this should be open to anyone interested in experimenting with changes, rather than a hand-picked group. If that's how it goes, then this could be very promising! Chaotic Enby (talk) 11:15, 12 August 2025 (UTC)

cc @Chaotic Enby the proposal lacks openness on the side of PTAC - From my point-of-view, we've released all material that was available to us during the making the decision (outside of back-and-forth between ourselves during the meetings). Could provide some thoughts on how PTAC could be more open going forward? Sohom (talk) 04:10, 18 August 2025 (UTC)

@Sohom Datta: Sorry if I wasn't clear! I wasn't thinking about transparency in terms of releasing communications, for which you did a great job, but in helping directly involve non-PTAC users. I feel like the proposal could make more clear where we can or cannot participate in the project as community members, as I (and probably many others) would love to! Chaotic Enby (talk) 11:33, 18 August 2025 (UTC)

So I've been ruminating on this response for the last 24 hours and when I was thinking about it in my head, it wasn't nearly as negative as it's turned out to be when I actually put pen to paper. So let me repeat something I wrote on enwiki when this was announced: I really like and respect many of the members of this council (and the rest I don't know).

I'm mildly surprised to see two enwiki controversies be such a driving force for this council. I think any time the WMF starts out with tool development on enwiki on its own initiative, rather than in response to a community ask, it's doing so on hard mode. So it's not surprising that AI generated summaries and Tone Check received harsh feedback. This is in contrast to more successful rollouts of other tools where enwiki implementation was somewhere down the line.

A big reason that developing for enwiki is hard is that getting a durable consensus is hard. There is no good way to get a small group of editors to get a consensus that a dev team can count on to hold when a larger group of editors weigh in. And I don't love the idea implicit in a couple of these proposal that if the WMF had just communicated better the community would have supported the idea, rather than honoring actual legitimate problems and concerns raised by the community in well attended discussions. "This is in experiment phase so don't worry that you think it's a bad idea that is incompatible with Wikimedia values" just isn't going to cut it. And I write this as someone who is, I think, more open than the average enwiki editor to the idea of doing experiments to learn and grow for the future and to meet the challenges and opportunities AI provides. I don't think a better comms strategy is what is going to change consensus on that front and that seems to be what this set of proposals is. Best, Barkeep49 (talk) 02:59, 8 August 2025 (UTC)

My personal take away from the conversations we had were not: "Had the WMF communicated better the proposal would have been adopted" but rather that "Had the negative feedback come in earlier the WMF would have reversed/reconsidered their course faster" and that's the crux of why I'm pushing for WMF to change the way it communicates product updates, so that community members (not just PTAC members) are able to provide the negative/positive concerns/feedback faster, before the WMF invests significant effort in bigger experiments. The AI summaries experiment were preceded by much smaller experiments/feedback sessions where the feedback was overwhelmingly positive or there was none received, that is what needs to change. Sohom (talk) 04:08, 8 August 2025 (UTC)

I think there's some moment in the development process where an issue becomes "ripe" for real community feedback. Prior to that you're going to get the outliers - kinda like the people on this talk page - who will be willing to engage. There aren't tons of them for any particular issue and they may or may not hold views that are representative of the community. The AI summaries are actually a great example of that. They post in February and get no feedback. They post to the same place in June and then suddenly the issue is ripe and they get loads of feedback and it's enough and bad enough to kill the initative. Now fundamentally the idea of "if we can get more feedback earlier that's better for everyone" is correct. But it's not clear to me that feedback will necessarily be ready earlier. So while efforts to drive that attention are good, I admit to being skeptical they'll work and I worry that will feel doubly frustrating to the WMF product teams who will have been asked to do more to only perhaps end up in the same boat as before. One reason I'm skeptical is because "Community members champions and drives community discussion" presupposes editor capacity - in both skill, time, attention, and passion for the work - that I'm not sure will be there. And I don't know that the central repository is enough to be that bridge. I'm especially dubious because of the complete failure of the new wishlist, where this central repository strategy seems ot be in effect - in a limited scope but still in effect - and has gutted participation. As one of the few people still around, I'm doing quite well at getting wishes worked on which is great for me, but if anything signals just how big a failure the new process has been and why this central repository is a good idea that won't, I think, drive the results the PTAC is hoping for. And it's still seems to me the remaining strategy is "better communication strategy" and I fundamentally don't think that's the answer.

On enwiki I think what separates a mediocre arb from a good or great arb is the ability to figure out which criticism is worth listening to at the Arbitration Noticeboard. There, like it has been here, the feedback to stuff is often way on the negative side. The mediocre arb does one of two things: takes all the criticism to heart and thus loses the ability to make the tough decisions that the role calls for and bends to whatever whim they think the community wants or decides "we can't do anything right in the eyes of the community so I'll just ignore everything" and thus misses out on feedback they should be listening to on how to do things better. I'm going to be fascinated to see what the PTAC does here. Can they figure out how to handle the feedback received here? Because if they, like the mediocre arb, can't despite being experienced Wikimedians in touch with the community, I think it'll be completely unreasonable to expect product teams to be able to sort that out here. Best, Barkeep49 (talk) 02:39, 9 August 2025 (UTC)

P.S. Just to make this explicit I think the ideas are good ideas worth of implementation or trial. What I don't think they do is combine to deliver the results desired to the problem identified. Best, Barkeep49 (talk) 03:38, 9 August 2025 (UTC)

I also don't think the issue is (just) about communication/feedback, but I think there's an issue regarding feedback which has not been mentioned yet: One of the reasons, why community members sometimes even reject small experiments is the feeling, that this is the only chance to reject a project entirely. Down the road with more resources already spent on a project the risk is too high that someone decides to push it through despite negative feedback / criticism from the community. I'm very much in favour of doing more experiments, even regarding controversial topics like AI, as long as it's clear how the community will be involved in the evaluation process and as long as there's trust that our voice will still be heard after the experiment is done. Johannnes89 (talk) 06:57, 10 August 2025 (UTC)

I agree regarding ripeness. I know en.wp has also gotten stuff earlier (but later than AI summaries on development timeline) and has just thrown up their hands at "why is this here this doesn't look remotely ready for user review". IznoPublic (talk) 18:01, 11 August 2025 (UTC)

I agree ripeness is something that I (personally) hadn't considered before. Thought I wonder if that is a framing problem ("better feedback sections") or necessarily a "the product wouldn't have gotten feedback whichever way it was pitched". (@IznoPublic, if you have examples, feel free to throw them at me).

To address the other point regarding community involvement from Barkeep, there is (to my understanding) some interest in "Community members champions and drives community discussion" amongst folks in the technical community in a variety of niches. What doesn't exist is a organized effort to do this (technically the Tech/Ambassadors program exists, but it doesn't see a lot of use from the WMF outside of Tech/News).

Also, to other points, I agree that this isn't a silver bullet, but the hope is to shift the needle towards having a higher success rate and lesser confrontations. Sohom (talk) 19:55, 11 August 2025 (UTC)

I do agree that an organized effort to drive community discussion would be great, and I genuinely hope that folks outside of PTAC will be able to get involved in this effort. Chaotic Enby (talk) 20:46, 11 August 2025 (UTC)

I actually don't know which case I was thinking of, but I recall it being fairly recent. Izno (talk) 03:58, 12 August 2025 (UTC)

A perhaps controversial take

I think the underlying assumption here is - WMF did not know the community's views on this matter, and if they did things would be different. I think this is a common view on why bad things happen in foundation/community relations. I think its the wrong view. My opinion on why events like this happen is the following:

• WMF has a work culture where staff do not feel comfortable giving negative feedback leading to confirmation bias.
• Decisions are made by a small group of people who have a conflict of interest. Namely decision makers are either (a) the people who came up with the idea, so have a bias out of pride, or (b) are being evaluated/promoted based on if the idea succeeds or fails, so are incentivized to ignore risks, since project failure because the community rejects it and project failure because they know its a bad idea, amount to negative performance eval either way. (In other words, incentives are misaligned. The personal risk is basically locked in at the planning stage so its difficult to be agile in a non-superficial way)

I suspect if you had a private survey of WMF staff about this experiment, the majority would have agreed with the community's view on it. I do not think it was a surprise to the average staffer that the community rejected this "experiment". I suspect many of them probably secretly cheered. With that in mind I don't think proposals here will do anything. Feedback can help discover issues, but its just one part of the equation and I don't think its the missing part. I find it very hard to believe that WMF as a "whole" did not know how this experiment would be received. I believe that structural issues prevented WMF from internalizing and taking appropriate action on the knowledge it did have. For those who disagree I have three questions - Why did the community reject this, were any of those reasons things the WMF didn't already know, and if so, why did WMF not know them? Bawolff (talk) 02:56, 10 August 2025 (UTC)

As someone with very little internal insight (maybe a little more than the average bear for a couple years due to routine T&S interaction), this take would not strike me as surprising. I have definitely observed similar while reading Phabricator. I can think of at least one or two changes that look like they went through on the energy of the owner and less on the energy of good technical decisions making and external desire. (And of course I mean smaller changes rather than larger in context, Vector 22 as an example of a big change that ruffled many feathers for obvious reasons but which is now ultimately more or less a nothing burger, as Vector before it.) IznoPublic (talk) 17:58, 11 August 2025 (UTC)

I don't completely buy this take/want to pushback, being involved in this thing from before it blew, I don't disagree that WMF probably knew that the change would be somewhat unpopular, I think the main misjudgment there is how unpopular (the scale of it) the change was. This (imo) could have been communicated through more negative commentary during the initial stages (which saw mostly positive commentary, I think partially emboldening the team in taking more missteps). Sohom (talk) 19:30, 11 August 2025 (UTC)

I support the perspective Bawolff is describing here. On top of that I miss multiple key aspects in the PTAC proposal that have caused major issues in earlier years.

• Communication: when a change is announced, explain why this change is needed. This is often left out and causes a lot of frustrations.
• Feedback: reactions from the community can often be raw/direct, often the result of frustrations and/or different social way of using language in some parts of the world due the local culture. Be prepared for raw feedback.
• Testing: A-B-testing is not the holy grail, it provides only short term feedback and misses key information.
• Implementation of changes: over the years communities often have been frustrated by having changes implemented, which were perceived as not being ready. One reason for that is that system messages weren't translated when they got implemented, which resulted in that the community got the feeling they had to fix something again. This can be avoided by requesting translations in advance. Another reason is that software implementations had with its introduction a lot of bugs, which effected the work of the community negatively and a general roll-out was perceived to be way too early. With proper testing those bugs could have been foreseen. Also, if WMF has set a deadline when a product needs to be finished, is that of secondary importance, quality of the software has a higher priority then meeting a deadline.
• Human nature: in general people are creatures of habit and do not like changes, unless a change has a really major benefit (seen from the community perspective). Changing something without major benefits means in practise that community members have to change they way they are working, which is hugely frustrating and which drains time and energy from the community that it wants to use for the content of the wikis. Try to avoid frustrating workflows of core users: often they aren't waiting for another change, including small ones: like a link or button missing or relocated, etc. Keep the possibility to stay with the used way if doing things, unless it causes problems.
• Amount of changes: in the past years the amount of changes that requires community action (LintErrors, dark modus, TemplateData, etc etc) are in many wikis not fully implemented and are a burden on the workload of communities. That on top of the various backlogs communities are facing (like for example the 365 K files on Commons without an infobox template, or the million+ items on Wikidata without the simple statement what it is, just to name two). Ideas are nice, but in the end it is the community that has to deal with it.

WMF is the legal owner, the community is practically owner of the wiki and maintains it with passion. WMF exists to support the community and to create a safe and good workplace where community members can work on the content. Changes often form a distraction and not a real improvement, causing frustrations. The community expects from WMF more insight and understanding what the community needs. Romaine (talk) 01:03, 12 August 2025 (UTC)

Yes

The "Diagnostic" section at the "Communication" page reads exactly as I conceptualise the problems we have as communities while pushing against WMF's fresh ideas (often good ones but half-baked, unfinished or simply cumbersome). It lists every problem I have with communications: the awful WMF corpo-lect, the lack of transparency, and the defensiveness.

I'm not sure how to solve all of this, but the provided suggestions sound interesting and are definitely worth exploring.

Thank you PTAC! Le Loy (talk) 02:05, 12 August 2025 (UTC)

I imagine @Iniquity and @Stjn would have some helpful feedback too as passionate community advocates, so I'd like to invite you both to read this doc and share what you think. Le Loy (talk) 02:06, 12 August 2025 (UTC)

Two cents

Ironically, this page may in itself be an example of problems in reaching communities. This is a meta page, but I believe that I am the seventh non-mainly-ENWP editor to walk into here; and that only four non-mainly-EN editors came (out of 14). That means 50% ENWP while ENWP is 23% of active editors; 71% EN even though EN is 24%.

(In the same vein, the links are a bit enwp-centric. Linking "AI-generated article summaries" to VPT and "Tone Check" to VPWMF, without specifying that these link to enwp discussions/reactions, can be kind of confusing. Also, the RFC surrounding AI features by the WMF implies that everyone will be familiar with an RFC because it happened on ENWP; should probably be something like an English Wikipedia RFC surrounding [...].)

Receptiveness to feedback

More to the point: in my experience (which of course isn't necessarily representative), the main problem in technical communication has not been so much WMF having trouble reaching editors, than WMF having trouble discussing with editors; by that, I mean WMF ignoring concerns. I feel like a useful measure would be perhaps a reminder to WMF employees that ignoring questions and feedback, well, doesn't help with anything; that if you ignore consensus it doesn't give anyone a reason to trust you.

Let's take a concrete example: among the things Vector 2022 does, is drastically enlarge vertical spacing between paragraphs. This is a breaking change in ENWS, because text sometimes must fit into a fixed-width frame. Before deployment, WMF employees started two discussions warning of deployment (one five months before, one three weeks before), and ostensibly welcoming feedback. Both times, we told them that the change in paragraph spacing was a breaking change. If and when they answered, they gave vague answers that completely ignored the important concern raised, even while ostensibly stating that communication between editors and WMF is important. We only got half-answers on the day of planned deployment, and only after sending emails.

Complete timeline, footnotes and details if someone cares
No offence meant against anyone involved; just showcases a communication strategy that I can't understand and that makes cooperation harder. 2023-12: V22 drastically enlarges margins (T351754): first from 0.5em (don't know why it'd been that) up to 1em, which is about V10 margins; then up to 1.5em for no reason specified beyond "separating paragraphs". 2024-03: first announcement. Warns March 14 for April 3. V22 criticised because of paragraph breaks being much larger, which breaks stuff. Nowhere in that discussion does WMF answer to any concerns or even say anything—despite pings to the two employees who sent the announcement, which said please contact us. For some reason or other, deployment does not happen on April 3. 2024-11-06: second announcement. Warns of deployment for the week of November 25. As for the precedent, calls for feedback. Up to Nov 10, five answers, including 4 pings to the employee that sent the message; including a specific question about paragraph spacing and reminder that that was already raised in March. Nov 15: a WMF employee posts a ~4kb (!) reply that strikingly manages to address everything but the breaking change, despite saying 4 times that they're listening to our questions Nov 15-16: Three user replies to that, including 2 pings, specifically raising the question of paragraph spacing, and of how WMF seems to be skirting around the topic. No WMF answer. Nov 22: still not having gotten any answer to a breaking change that's been on the table for 8 months; and with deployment still planned in three days despite that; I send an email nudging them again and asking them a) why you did not answer the community's concern, and b) why you [...] decided to space paragraphs further away?. Nov 22: WMF employee emails back; strikingly enough not answering the question of "why did you ignore this?"; and pointing us to a MW Web Team summary of off-wiki articles on typography Nov 23: with WMF still not having addressed how we were supposed to deal with their breaking change, and deployment in two days, users workshop some css that we could add to site css to override V22 spacing Nov 25, planned deployment day: WMF reply, deployment delayed to a week later. Notably says: We fully recognize that the spacing issues have not yet been resolved, we didn't communicate about it earlier, and we apologize for the inconvenience this has caused. - although they still didn't answer our question of why they didn't communicate about it earlier - which doesn't help for transparency We believe that the long-term solution would [... be ...] rather decreasing dependence on absolute values when making editing decisions - except we don't have that choice, because images have to be sized with absolute values; except if we just drop trying to fit text with images at all about a week later, V22 becomes default skin on ENWS; after a while and after a proposal, we get an intadmin to add the css in question to gadget-site.css References for details and/or info only partly relevant:

That's one incident; this kind of behaviour of seeming to dodge questions comes up sadly often in WMF requests for feedback. I wouldn't say the community is 100% wrong when it feels as though these are developed without community input (from this document).

"Should the community have a say in the failure criteria"

Besides the condescension raised by Chaotic Enby, can someone explain me since when this is a question? How exactly is there supposed to be trust and transparency if WMF does not deign to let the community be implicated in what software it gets to use? What's the point of collecting community feedback if ultimately we don't have a say? — Alien  3
3 3 02:51, 12 August 2025 (UTC)

@Alien333 Regarding the small text, it was just sent out as Tech/News today in a effort to reach more folks. I'll try to do some more village pump/scriptorium posting to get more folks in. I agree that the linking was probably a bit enwiki specific, but outside of that, we've tried to keep the recommendations relatively free of specific enwiki-terminology.

Wrt to enws, I remember being involved in some of the discussion off-wiki regarding Vector22's deployment on wikisource, thought I do not remember being involved in that specific discussion you reference. If I had to guess what went wrong here, it was the fact that Extension:ProofreadPage works in very different ways to a lot of code on MediaWiki and while the Web team did fix some early concerns (there was a lot of problems earlier on with them forcing fixed width in the main and Page namespace). I think with paragraph spacing they weren't able to find a good enough solution that would make sure ProofreadPage worked without also breaking other wikis all over again. The correct fix here would have been to upstream the patch to ProofreadPage, but I can understand how/why that fell through (ProofreadPage can be a mess at times).

To me, I think there is a deeper question there of WMF developing software a lot of the time specifically for Wikipedia and not spending enough time and resources to adapt it for other sister projects. (Which is what happened here imo, partially) I'm wonder what a good way of solving that will be (or whether that is a separate question to solve altogether).

"Should the community have a say in the failure criteria", the question that we asked ourselves is basically "Should the community have a say on specifically what causes a experiment to fail" and the answer there was "probably, but also, maybe not", this is not the same question as "Should WMF ignore feedback" (the answer to that question imo is 99% no, 1% maybe), but rather "Should the community be able to say if Wikisource-Export doesn't get X downloads, then we should scrap the tool" or "Should the community be able to stipulate to the Foundation that if a UI prototype does not get X clicks on Y element, it should rethink the design". We honestly did not come to a consensus on which side to land on and decided to record both sides as point vs counterpoint. (I can see both sides of why you could argue that the community would not necessarily be the best equipped to make such a proclamation or vice versa). Sohom (talk) 05:37, 12 August 2025 (UTC)

Thanks for the answer.

developing software a lot of the time specifically for Wikipedia and not spending enough time and resources to adapt it for other sister projects - Yes, there is a big part of that. IMO, it wouldn't be so much of a problem if they then didn't proceed to repeatedly insist to force upon us. Leave WP software to WPs, and let us do our thing.

For the record, the paragraph spacing wasn't related to PRP or other MW WS-specific technical software; it was related to Wikisource trying to replicate styling for faithfulness, and the Web Team, thinking from a WP point of view, considering styling not part of the content and inserting arbitrary styles. There have also been other instances of that. For instance, MobileFrontend imposing a rem font size on all paragraphs at all levels of the DOM tree (T401137), probably done because wikipedias don't do much font sizing; whereas just adding the size to .mw-parser-output and letting the ems scale would have been simpler. And sometimes, it's not only styling they're inserting into content but also random stuff that breaks formatting; notably QuickSurveys catastrophically places its invite (T393436). What doesn't help is that in most cases (including these two) the Web Team has been quite unresponsive to bug reports, including right after a prod deployment, and despite that continued prod deployment. The user-facing feeling of it is that someone just wants this through and doesn't care.

But that aside, I think you'll agree that ignoring feedback isn't a good way to collect feedback and should be discouraged.

On failure criteria: I suppose this is again an instance of different ideas of what they should be, but when the community rejects something, it rarely is out of bright-line numerical tests. Editors have expressed (including on this page) reservations on a WMF over-reliance on A/B tests and surveys. Talking about transparency, those are also conducted with minimal transparency. They are started without warning, consultation or notice. Qualtrics question lists are not available after the fact. Which doesn't help with the not necessarily wrong claims of questions or UI being made in such a way as to favor a "yes" response. As far as I can see, the leading sentiment has been that "the community doesn't want this for reasons XYZ" should be a rejection criteria. The foundation, as far as I know, is here to support and host the projects, not to unilaterally choose what the projects' content should be.

— Alien  3
3 3 19:00, 12 August 2025 (UTC)

Community members champions

Hello,

I think the whole process is going in the right direction, but I am uncomfortable with the expression "Community members champions". It is an odd way of pointing as volunteering product owners. People from several communities who are usually elected as admin or other rights for years but who usually are dealing with some part of the activity without any understanding of the whole picture (who can, really?). I mean, it is not that easy to identify people willing to communicate about long-term technical projects and harder to have them having skills and acknowledgment by the community.

One can not be a product owner (or champion, or liaison, or referee, or else) without a dedicated training and a place to develop social skills (identification of services and key people, intertwingularity of needs and options, third parties, past task forces and reluctance for some solutions, etc.). Some place like Wikimedia Space maybe. At least, please do not consider picking people and pin them with a "champion" suit without any preparation. Issues of communication have to also be considered for the community people part. Noé (talk) 10:30, 12 August 2025 (UTC)

FWIW, generally the role of "product owner" and the role of "champion", as the terms are used in the software industry, are very different roles. Bawolff (talk) 04:16, 18 August 2025 (UTC)

I read this as "let's have community members translate the NGO-industrial-complex-speak of WMF". I think a better solution would just be for WMF staff to communicate in plain English. voorts (talk/contributions) 22:30, 24 August 2025 (UTC)

About communication and experiments

Thanks to @Le Loy for pinging me into this discussion — this is exactly my topic.

First of all, thank you for paying attention to the issue of experiments and communication between communities. The problems are described quite accurately, but some things are missing — more on that below.

Secondly, you know, I’ve often and for a long time reflected on what exactly is wrong with communication between communities and the WMF. I’ve argued a lot, stopped and restarted initiatives, and could never understand why the WMF keeps making the same mistakes. So the text below is essentially a repetition of my points that I’ve made in different places — meaning that perhaps no one will see anything new here.

1. Define what the WMF is for the community

Everything starts here: all the difficulties, all the desynchronization, everything we do begins with answering this question. Is the Foundation part of the Wikimedia Movement? Is it a totalitarian ruler, or a curator? What is it for, how does it see itself, and how is it perceived by the community?

2. Define what you are doing

This is the most interesting part. I am quite an active technical community member, subscribed to a bunch of mailing lists/newsletters and involved in many technical matters. But even I sometimes don’t understand the purpose of certain experiments. What benefit will they bring to the movement and the community? I didn’t see that question addressed in the hypothesis summary or analysis.

You are testing the introduction of AI cards, but you have a huge technical debt, no proper tools for editing and reviewing changes, and a massive backlog of unfinished work — yet you’re testing AI cards and complaining about the lack of technical specialists. I’ll just leave here this link to a backlog of 2,000 (!) tasks: https://phabricator.wikimedia.org/project/view/71/.

I also want to point out that within the WMF there is a recurring practice of abandoning tools after release in their current state, and then switching to newer, more «interesting» features. TD — unfinished; Content Translation — unfinished; the new Vector — unfinished; Discussion Tools — unfinished; the Visual Editor — unfinished; Wikidata integration — unfinished; gadgets — unfinished; graphs — unfinished; TemplateWizard — unfinished; Newcomer Homepage design — unfinished. I could go on endlessly.

And this is precisely why I am often against introducing experimental features — because I know they will remain unfinished and the Foundation will simply switch to something else.

So, you are doing things that raise questions in the community about proper resource allocation. AI cards do not help to understand how this experimental direction might benefit the community in the future.

3. Who are you in communication?

• It’s very hard to communicate with the WMF when it pushes its ideas in an ultimatum form.
• It’s very hard to communicate with the WMF when it remains silent on a topic it started on a local wiki’s public forum.
• It’s very hard to communicate with the WMF when any objection on the forum, or a request to fix something before release, runs into vague deadlines and responses like «we’ll fix it someday, but later.»
• It’s very hard to communicate with the WMF when all communication is in a corporate-neutral tone, giving the full impression that you’re applying for a job at some corporation, rather than talking to colleagues.

But here I want to say a huge thanks to @SGrabarczuk (WMF) and @Trizek (WMF) — they are almost the ideal example of how to communicate with community members, and they don’t have issues with the corporate style or 'silence'.

All four problems above stem from the fact that the Foundation cannot answer the first question: who are you for the community? If you are community members, then communicate as community members. The community has many processes to build consensus, and we do not communicate in a corporate style. All of these things cause backlash and rejection of ideas. Look at how experiments were conducted that were useful to the community or built on existing processes: Newcomer Homepage, Community Configuration or Discussion Tools. This is a great example of how communities are open to new ideas, but they need to be clear and understandable and based on the benefit to the community. Iniquity (talk) 19:12, 12 August 2025 (UTC)

Apologies if I am stating the obvious, but it should be the community who decides who the WMF is for the community, not the WMF. So the WMF's answer to the question who are you for the community? should be "who the community needs/wants us to be". Currently it seems like they mostly do whatever they feel like, and it seems like a way too small percentage of the money and effort is spent on things the community wants/needs. Perhaps it would be smart to be more transparent, because people will assume the worst if you're not. Polygnotus (talk) 00:12, 18 August 2025 (UTC)

In my opinion this comes back to what in my opinion is why the foundation was created. "to do things that need to happen, that the community doesn't want to do themselves, because they are writing the encyclopedia" which is a clear indicator of why there is so much disjunction, especially because editors often think they are the community, whereas the foundation tends to view it as ALL people related to the wikipedia and related projects. —TheDJ (talk • contribs) 15:11, 20 August 2025 (UTC)

The problem isn't how the ideas are communicated. It's that the ideas are bad.

Let's say you run maintenance for an apartment co-op. You want to do a construction project that will involve jackhammering concrete right next to people's doors at 3 AM, every night, indefinitely. You don't technically need the co-op board's approval to do this, but they are able to veto you after the fact, so effectively you need at least a rough consensus from them in favor.

What communication steps do you take to get this consensus?

None, of course. There is no combination of words that will make people okay with what you're proposing. People don't like being woken up by jackhammers at 3 AM and no amount of communication will change that.

The WMF does stuff with poor communication all the time. Usually it goes somewhere between "great" and "a little subpar", with a median outcome of "fine". The thing that made these two proposals so controversial wasn't poor communication; as noted, they were communicated with a fair amount of advance warning. The problem was that they were really bad ideas, at least according to the views of most community members who care about these things. The enwiki community in particular, and people in technical and creative spaces in general, grow increasingly sour on using AI at all every day. Enough so that I think, even if someone could find a good use for it in production on Wikimedia (beyond the existing limited deployments of fairly rudimentary AI tools), I doubt you'd get consensus for it. And these were not good uses. One was a direct insult to anyone who's ever written an article, the other a tool that would have facilitated abuse.

There's this thing people do sometimes, when they get caught doing something people don't like (crimes, infidelity, what-have-you), where they insist that if you'd just listen to them, you'd understand what they did was okay. And then when people don't understand, they try to find the failure in communication that's keeping people from seeing how right they are. But maybe they're just wrong. The WMF can bring in the best communications specialist in the world, and the next time they try something like this, the pushback will still be worse than it was this last time, because a stone only rolls downhill, and patience for AI hijinks wanes with each passing day.

If the WMF doesn't want massive backlash to projects that the community will never support, it should not undertake projects that the community will never support. I think that's all PTAC needs to tell it. -- Tamzin^{[cetacean needed]} (they|xe) 04:36, 18 August 2025 (UTC)

@Tamzin I have a extremely strong reaction to the phrasing it should not undertake projects that the community will never support., thought experiment, assuming there was no community support for moving towards a WYSIWYG editor should the Wikimedia Foundation not pursue such a endeavor? I speak for myself when I say that there are cases where it makes sense to invest in somewhat controversial projects for the better of the encyclopedia and I personally cannot bring myself to take a explicit stance of "do not ever invest in anything where a significant chunk of the community will hate" knowing that the community can (under certain cases) have a significant amount of inertia. Also, to make it clear, the proposals are not "if we explained this hard enough you would listen", instead a majority of the focus on communication in the proposal is to deliver negative feedback faster, so that WMF folks have time to iterate and change course during earlier phases of the project, to avoid interactions where folks are at odds with community feedback.

What this proposal is, is for the construction company to have a conversation with some members of the co-op board early so that they can go "hey maybe try 10 am in the morning very few people will be in their homes" or "maybe you could construct this in a manner where you minimize noise?", that way the construction gets done, and we don't end up jackhammering concrete at 3 AM. Sohom (talk) 05:29, 18 August 2025 (UTC)

I see what you're saying, Sohom, but a competent construction company doesn't need to be told that no one wants jackhammering beside their bedroom at 3 AM. I don't think it's unreasonable to expect the WMF to not pursue projects that the community will strongly oppose. If teams don't have a sense of what the community will strongly oppose, they should do more communicating internally with the people the WMF pays to know those things. If the Product and Technology Advisory Council wants to give advice, it should be to not make products or technology that are bad and are more likely to cause an editors' strike than ever see the light of production. -- Tamzin^{[cetacean needed]} (they|xe) 05:51, 18 August 2025 (UTC)

Teams definitely had a sense of what the community would strongly oppose: People who are technically and linguistically hyper-literate like most of our editors, internet pundits, and WMF staff will like the feature the least. The feature isn't really "for" them.

The fact that this WMF team already predicted that "most of our editors" would not like a feature, yet went ahead with it anyway, speaks for itself far more clearly and honestly than any massaging of the "communication" or crisis PR possibly could. Gnomingstuff (talk) 05:55, 27 August 2025 (UTC)

@Gnomingstuff See #c-Sohom_Datta-20250811193000-IznoPublic-20250811175800 for my thoughts on this exact subject. Sohom (talk) 06:36, 27 August 2025 (UTC)

The very term "hyper-literate" says it all. Tuvalkin (talk) 17:49, 20 October 2025 (UTC)

I agree that the WMF needs room to experiment with Vector 2022 serving as a great example of investing in improvements to the reading experience despite foreseeable pushback favoring the familiar status quo. To be clear, Vector 2022 nonetheless had a variety of issues fixed through community feedback per Alien333. However, to Tamzin's point, the community gets frustrated when the WMF prefers its novel proposals like AI article summaries over the communities' pitches. With the annual Community Wishlist Survey replaced by the continuous Community Wishlist, we have been subjected to en:reinventing the wheel as the WMF came to Wikimania 2025 explaining how after two years, we can once again support wishes to indicate community priorities at a bare minimum.

I share the criticisms expressed at Talk:Community Wishlist since the start of this year and believe that reverting to the annual wishlist model would be more effective than anything the PTAC could advise. The Wikimedia projects fundamentally need a designated time each year to focus their energy on pitching ideas and then clarifying which wishes have the most support based on both need and feasibility. Even with the ability to support wishes in the continuous Community Wishlist, participation is predictably far lower when wishes can by made any time like Phabricator tickets. ViridianPenguin🐧 (💬) 04:01, 20 August 2025 (UTC)

I would rather not be quoted as saying Vector 2022 nonetheless had a variety of issues fixed through community feedback. V22 had a variety of issues indeed, and some were fixed through community feedback. But the development team of V22 was spectacularly unresponsive to reports of a breaking change in their own feedback discussions. To this day, they never even suggested a way out. We had to do everything ourselves, and are still using hacky CSS that relies on V22 not changing a selector, because of that. The lesson I take from all of that is not that V22's issue were fixed thanks to discussion. It is rather that WMF should slow down on the experimentation and ensure they actually follow each support channel they open, to not just make people speak into a wall. — Alien  3
3 3 22:53, 20 August 2025 (UTC)

I think there's merit to what the council is saying here. Part of the backlash to the AI summaries project was nearly a year of work going into it without better notification/communication: Special:GoToComment/c-Polygnotus-20250603051500-EBlackorby-WMF-20250602182000. Aaron Liu (talk) 02:50, 25 August 2025 (UTC)

Well aligned but...

I know there is a Community Wishlist where members can ask the "tooth fairy" for improvements or new features in our projects. However, I am unsure if there's an instance where the community can participate in brainstorming new features or experiments. I see a lot of these in the Tech News (which I translate into Spanish every week), but some of them don't seem aligned with the communities. Sometimes, it even feels like an obligation for communities to adopt them. In the past, my community has expressed that the Wikimedia Foundation (WMF) is imposing tools and methods that are not aligned with community priorities. Alternatively, we don't have a way to disable tools that are enabled without community consent or consensus.
I have read previous messages in this discussion and I agree with some of them: too many parallel projects, unfinished initiatives, and in some cases, it appears that KPIs are more important than community satisfaction.
It's easy to just say "no," but how can we improve this situation? (trying to see not-empty vase :))

• Make more frequent announcements: increase the number of community calls, newsletters, or bulletin board posts to explain the next steps for the upcoming quarter. I know, Tech News are already doing this, it doesn't seem to be enough or relevant for communities(?)
• Establish a sub-community: create a dedicated space (e.g., Discord or Meta) for discussing early sketches, ideas, and drafts before any implementation or significant time investment. Phabricator is not the best tool for sharing ideas with non-technical users.
• Catch new feedback early: gather feedback as soon as possible to determine if an idea is aligned with community needs. Ask before shoot as my grandpa said :) (or it's more easy ask before than say sorry after)
• Bring discussions to the project's native language: encourage conversations and debates to happen in the primary language of the project. Some users can't engage discussions in English due lack of skills or just don't feel comfortable.

My two cents :) Superzerocool (talk) 14:38, 18 August 2025 (UTC) (disclaimer: English isn't my primary language, so I used AI to improve grammar and tone...)

Hi @Superzerocool, I really like all the ideas you shared here. I’m on the Movement Comms team supporting Product and Tech, and I agree with you that while we have TechNews as an easily digestible source for updates, we don’t necessarily have a similar space for communities to give feedback.

I feel like there are two needs you bring up here: one, more frequent planned opportunities for community feedback (like calls or newsletters), and two, a dedicated space for more frequent, informal conversations around early ideas. I have a couple questions and would love to know more of your thoughts here.

• What do you think about how to ensure language accessibility in such a space?
  • Maybe a Discord server with channels for different languages?
  • Or Meta for more async translation options?
  • Something else?
• What would be most helpful and interesting to you in product updates? Or to phrase it another way, what can we share with you that TechNews doesn’t already accomplish?

EBlackorby-WMF (talk) 17:10, 21 August 2025 (UTC)

@EBlackorby-WMF, thank you for the feedback! I'm unsure if all of these ideas will work; in the past, new spaces have been created and everyone has returned to Meta or their local wikis. Regardless, volunteers may be more engaged with new ideas if there is a space to share comments and suggestions without the need for extensive bureaucracy. Discord seems aligned with a certain type of person (those who are already familiar with the platform and want to use it), but the majority of volunteers will want to have discussions on Meta or their local wikis. About Meta, it's very limited and it's easy to mix up ideas because everyone can edit at the same time. The platform also isn't the best tool for creating translated versions. Every platform has its pros and cons.

I suggest we hold discussions with communities in their local languages, then use an AI to translate the feedback into English. External tools could be used for a limited and focused group of users to get more detailed feedback, share ideas on new tools, or provide updates.

Regarding your second question, one idea is to create a quarterly newsletter about product updates, adapted for each Wikimedia project (e.g., one for Wikipedia, another for Wikisource, etc.). This newsletter could share news about new UI or UX improvements in non-technical language and feature the "next big ideas" or concepts from the Community Wishlist. This would create a virtuous cycle, showing the community, "Hey, we've implemented these improvements! Don't be shy—take a look at other great ideas and share your comments with us."... You could use gif, animations, short videos... A good idea would be what Chrome did on YouTube (an update for every new version)

I know this might sound like an ideal solution from a long-time volunteer (I confess: I'm living in an ideal world), but trying it for just one semester or a year could significantly reduce the gap between the community and WMF teams.

Kindly Superzerocool (talk) 18:01, 21 August 2025 (UTC)

@Superzerocool You make a very good point about Meta and local wikis tending to be the place where people feel comfortable returning to. I quite like the idea of meeting people in their local wikis, in their native tongues, using AI to translate as needed. The newsletter format is also an underutilized one, I think, that we will be happy to think through a little deeper.

I hadn't seen the Chrome videos, those are great! Something like our Wikiminute videos but for product features could be a really fun idea to play with.

There are no ideas too ideal :) I think anything is worth trying out! Really appreciate your ideas and feedback. EBlackorby-WMF (talk) 20:50, 22 August 2025 (UTC)

I agree with the idea of establishing a sub-community. WMF may consider re-boosting the Tech ambassadors program (or creating a new program) and inviting volunteers (especially volunteer developers and local sysops) to join this sub-community. While I personally prefer instant messaging platforms like Discord or Telegram, as their environment tends to be casual and people feel more comfortable sharing their honest thoughts, it would also be beneficial to allow sharing thoughts on talk pages or mailing lists for those volunteers who prefer to use these platforms. (BTW I personally very like the former Trustee Pundit's idea about community-elected "liaisons", but I believe PTAC already serves as the community liaison.)

Regarding receiving feedback, while I know that WMF staff are open to receiving private feedback via email, it is suggested that an anonymous survey be conducted as an additional channel for feedback. This would allow community members to share their comments privately and comfortably, providing their most candid opinions. The survey could be limited to the sub-community (Tech Ambassadors, etc.) to avoid disruption from trolls. Additionally, when collecting feedback from the community, it would be great if WMF could share a prototype or MVP, rather than only providing abstract and unclear ideas.

it appears that KPIs are more important than community satisfaction. I agree with this point. I understand that satisfaction is difficult to quantify, but community satisfaction should be counted as one of the KPIs. Perhaps survey of users can be one of the ways to measure satisfaction.

Furthermore, the documentation on MediaWiki and announcements are sometimes a bit long for volunteers, who don't have much time to read these texts. Perhaps the summary and FAQs can be provided for easier reading. Also, I'm also curious if it's possible to release some features as beta features before deploying them for all users,

Anyway, that's just my two cents. I really appreciate PTAC's efforts on WMF's communication and experimentation! SCP-2000 06:09, 24 August 2025 (UTC)

What's Going On

Last I checked in, six months ago (February), you were prioritizing mobile apps. Now I see you're prioritizing AI-generated article summaries. Looking forward to checking back next February to see what new thing you're prioritizing then. Meantime, chilling to some great music. Wbm1058 (talk) 02:51, 24 August 2025 (UTC)

Summaries was an idea that received so much negative feedback it looks like the WMF abandoned it in early June. I don't see any indication of other projects being prioritized over mobile apps either, and last I heard they were still focusing on and testing new features on the Android app: mw:Wikimedia Apps/Team/Android#Updates. Aaron Liu (talk) 02:47, 25 August 2025 (UTC)

@Wbm1058 The prioritization of mobile-first editing is till ongoing. You can see updates regarding it at Product and Technology Advisory Council/February 2025 draft PTAC recommendation for feedback/Updates and the associated task! (It is still very much in it's early stages but there is some progress with hopefully more to come). For what it's worth, AI summaries are not being prioritized in any way, we are looking at ways of improving community communication with the WMF to decrease the likelihood of misunderstandings like the AI summaries issue happening going forward. Sohom (talk) 15:32, 25 August 2025 (UTC)

In what way was this a "misunderstanding"? The community understood perfectly what the project was, and overwhelmingly agreed it was a bad idea with even worse execution. Gnomingstuff (talk) 04:33, 27 August 2025 (UTC)

"misunderstanding" from the POV of the WMF. Sohom (talk) 05:43, 27 August 2025 (UTC)

I think Sohom might mean the WMF misunderstanding the community's communications expectations or other opinions or something like that. Aaron Liu (talk) 16:05, 27 August 2025 (UTC)

Phabricator abuse

I think the more pressing issue is to tackle WMF staff abuse. Like one of my filed bugs in the translate extension has harassment against me. It was a bug on diff not working in the translate extension when the time difference between the diffs was high. Nemo bis tried to assign the bug to me, I refused and that went on and on and on. I just wanted not to be assigned to it and was flamed for other things I did not do. Eventually one of the staffers hid the bug, I objected. They said that bugs like that where not kept public, but I refered to an humor bug about Eyjafjallajökull. Then a staffer followed me to Wikidata and continued flaming me there. This is all from memory, by the way. Snævar (talk) 14:27, 29 August 2025 (UTC)

I will stop you here, this is not the correct place for this kind of feedback, the Code of Conduct Committee is what you want. Sohom (talk) 19:39, 29 August 2025 (UTC)