Talk:Product and Technology Advisory Council/May 2026 draft PTAC recommendation for feedback

May 2026 draft PTAC recommendation response

• Proposal
• Provide feedback

Collaboration with WMF teams

We at Wiki Med are working on ways to remove EXIF location data from peoples uploads on Commons, so if you give away your home or work address by mistake it is easier to remove it. See the Commons:RemoveGPS script. We would like to introduce this into the Upload Wizard but no team is in charge of it currently. We need easier ways to determine which team at the WMF owns what current tool and processes for if no one owns a specific functionality. Doc James (talk · contribs · email) 11:31, 3 May 2026 (UTC)

@Doc James This should eventually be fixed. To my understanding WMF is planning to make sure most/all extensions will have a steward of some nature. Sohom (talk) 15:17, 3 May 2026 (UTC)

Excellent great to hear :-) Doc James (talk · contribs · email) 15:23, 3 May 2026 (UTC)

For what it's worth, partially putting my volunteer developer hat on, I think integrating RemoveGPS with UploadWizard is also a example of why the the "Wikimedia Foundation buy-in" clause is necessary, particularly because integrating the userscript into extension code would require significant rewriting/engineering effort touching multiple components to upstream into UploadWizard (for example, the dependency to a external Toolforge tool would need to be removed completely). Sohom (talk) 15:39, 3 May 2026 (UTC)

Yes more technical work is required to integrate. That no one currently maintains the upload wizard is unfortunate. And thus there is NO method of getting WMF buy-in before development. The fact that we have allowed long-term users home addresses to be exposed for a decade with no easy fix, before we developed the above script, is a sad state of affairs IMO.

So sure, folks need to get WMF buy-in at some point but there also needs to be a process to get that buy-in. Doc James (talk · contribs · email) 08:23, 4 May 2026 (UTC)

@Doc James I will say, having looked at UploadWizard fairly deeply, I do not think "we do not maintain UploadWizard" is necessarily the causal relationship for the GPS situation. There is a reason anonymizing GPS data is a significant technical lift (your script does half of the job, the details are still embedded in the previously uploaded file).

Regarding the broader question of "how do I get buy-in", my internal model tells me that the way you would go about this is RFC on Commons -> Community Wishlist -> Talk to WMF folks -> (On getting the go-ahead) Implement. However, I will ask around if this is the correct approach to follow. Sohom (talk) 15:01, 4 May 2026 (UTC)

Script also emails the Commons oversighters to delete the old file which still has the GPS data embedded :-)

As you mention it is multi stakeholder buy-in that is required, not WMF buy-in alone. But one really needs to do it all at once. Without progress from a technical point of view and something to show as an example, requests do not generate serious discussion.

I have been working on the GPS data security issue for about 10 years including a bunch when I was on the board of the WMF. Basically it is far from easy. And doing the technical work is actually the easier part of the effort. Doc James (talk · contribs · email) 15:46, 4 May 2026 (UTC)

Flexibility

In my opinion flexibility is key. Different problems need different solutions and different processes to arrive at those solutions. Ignore all rules is one of our core principles for a reason. Doc James (talk · contribs · email) 11:40, 3 May 2026 (UTC)

@Doc James Which part of the model do you have problems with in this context? For what it's worth, I'd counter that I don't think "ignore all rules" has ever applied to technical contributions by a large degree (atleast since 2019, which is around the time I've been around) Sohom (talk) 15:20, 3 May 2026 (UTC)

I do not think formal WMF buy in should be required for a "new MediaWiki extensions". Should I may be required for use on Wikipedia, but often one needs to build something, show that something to the movement, get buy in, and than only once buy in is achieved can one than convince the WMF to accept it. WMF is hesitant to accept anything that might be rejected by the communities. Doc James (talk · contribs · email) 15:27, 3 May 2026 (UTC)

@Doc James In my memory, the last time a volunteer led extension was put into production was in 2020/2021 (4 years ago) as mw:Extension:GlobalWatchlist which has subsequently been unmaintained after the volunteer maintaining it became inactive. (Technically Taavi did deploy mw:Extension:RealMe in 2022, but the extension is very bare-bones and easy to maintain and I would discount it on account of the fact that Taavi shortly after became a WMF employee). I don't think it is realistic to hope to deploy a extension on WMF wikis in the near future, not because the WMF fears that the extension might be rejected, but rather they do not want to add more technical debt over what already exists in the Wikimedia ecosystem. Sohom (talk) 16:31, 3 May 2026 (UTC)

This is a rather odd document

Given the very long history of distributed contributions to the technical side of the Wikimedia movement, this is a very odd document to read. Talking about affilates having 'expressed interest' misses the vital role that affiliates have been playing in the technology development of the Wikimedia projects over the last two decades. I would, however, completely agree that there is "no simple, consistent way [...] to identify contributors' needs" - deliberately with that omission in the middle. That's a good general statement, and it's not something that WMF has been able to do either, particularly since contributors' needs vary so much across different geographies - implying that actually the affilites are the best placed Wikimedia organisations to identify what is needed.

The focus only on the CEE model is odd - particularly given WMDE, WMSV, WMB, and others' long-term involvement in technical development work. What is different with CEE's model vs. what has already been happening elsewhere?

I find it bizzare that we have had the annual Wikimedia Hackathon this weekend, yet this was nowhere to be seen on its agenda. That would have been the ideal venue to discuss this recommendation with the technical community. Thanks. Mike Peel (talk) 21:11, 3 May 2026 (UTC)

@Mike Peel implying that actually the affilites are the best placed Wikimedia organisations to identify what is needed. I would agree and the document effectively asks affiliates to do the same!

The focus only on the CEE model is odd - particularly given WMDE, WMSV, WMB, and others' long-term involvement in technical development work. - I think it's worth saying that WMDE already meets and more than exceeds basically everything espoused in this model, through their TechWishes program and their close work with the WMF on multiple core features. I'm not immediately familiar with WMSV and WMB's work in much detail but if they roughly followed a similar structure of deriving what they were working on from folk's needs, the only new thing the model ask for is the on-wiki documentation of the same (which some folks within the onwiki editor community have previously asked for). I know this is true of folks working on tech in the OKI-IIITH chapters in India (I guess there isn't a long-standing working group per-se but again those are relatively minor changes when they are working to the correct direction).

I find it bizzare that we have had the annual Wikimedia Hackathon this weekend, yet this was nowhere to be seen on its agenda Both of these lining up were a coincidence to my understanding and not pre-planned. I personally wasn't able to make it due to personal circumstances, but I'm pretty sure other PTAC members would be interested in socializing this in future events where they are present~! Sohom (talk) 02:48, 4 May 2026 (UTC)

Still I think it's worth mentioning WMDE. WMDE recently developed (still developing) a core feature (Sub-referencing or subrefs in short). This shouldn't be a baseline of work by chapters, but still I think that might be worth mentioning so that other chapters might reach out and ask those involved and check: what worked for them, what was hard and perhaps what was too much or could have been avoided. Nux (talk) 14:24, 6 May 2026 (UTC)

I would say that WMDE sort of goes beyond what most affiliates will be able to achieve. I consider it WMF lite and it's pretty expensive. It's maybe the most advanced form of what the CEE model is. —TheDJ (talk • contribs) 15:28, 6 May 2026 (UTC)

My take is that the order of progression goes: CEE Hub (light-weight survey and then execution) -> Wikimedia Brasil (much more structured wishlist, but with much limited funding) -> WMDE (full fledged wishlist with teams working on the wishes) Sohom (talk) 21:00, 7 May 2026 (UTC)

I think that order of progression is an important thing to highlight. You're saying that the CEE model should be the minimum standard, but there are ways of doing better than that. You could easily also include praise for WMB and WMDE here, particularly with the last point about requiring WMF buy-in that those affiliates already have.

The timing with the hackathon and the point about refraining from developing 'core MediaWiki code' also felt particularly off, given the encouragement for developers to contribute more to core MediaWiki code at recent hackathons. But I hear that it was a coincident. Thanks. Mike Peel (talk) 20:58, 18 May 2026 (UTC)

OK, but needs nuance

I write this in my personal capacity, not as Wikimedia Brasil leadership.

I welcome the recommendation and align with the core principle that affiliates with technical capacity should be empowered and funded to develop tools that serve their communities. I believe the recommendation should be grounded in a formal agreement between the Wikimedia Foundation and affiliates, establishing mutual commitments and ensuring that community-developed tools receive appropriate recognition and support. Such an agreement would transform this recommendation from a set of guidelines into a genuine partnership resting upon a tool plan for the movement, that can be informed by several research and community survey initiatives done over the years, especially around GLAM and Education.

I recognize the value of the CEE Hub model as an illustrative example and applaud the work done by that community, but we believe the recommendation would benefit from a broader range of examples that reflect the diversity of distinct affiliate contexts. The Lusophone Tech Wishlist project, maintained by the Brazilian and Portuguese-speaking Wikimedia community, represents a complementary and equally valid model: it is deeply community-driven, operates with very limited resources, and has successfully engaged contributors through Outreachy. Including it alongside the CEE Hub as an alternative lightweight model would better reflect the reality of affiliates in the Global Majority, where communities often achieve meaningful impact without large coordination structures or significant funding.

The point advising affiliates to "refrain from developing new MediaWiki extensions" needs to be reworded. While I understand the legitimate technical and governance concerns behind this guidance, it is rather discouraging and may demotivate technically capable affiliates who could contribute to the Wikimedia ecosystem under the right conditions. The recommendation should instead outline a clear, public technical development plan and a formal protocol through which affiliates can engage in extension development responsibly.

Regards. Joalpe (talk) 23:31, 5 May 2026 (UTC)

@Joalpe: How is the Lusophone Tech Wishlist different from the overall model followed by CEE Hub model or WMDE TechWishes? I see a tech stewardship committee, I see a way for identifying problems with high impact (the wishlist). I think the only two other things major community-facing things are engagement in village pumps/whereever the community exists (which I assume y'all do to promote the wishlist?) and transparent prioritization. Sohom (talk) 00:26, 6 May 2026 (UTC)

Also, to give a example of what we mean when we say "Find tools that already exist", I see Lista_de_desejos_tecnológicos_da_lusofonia/2025/Propostas/Robô_de_arquivamento_de_referência could easily be solved by trying to reach out to the maintainers of InternetArchiveBot and/or working on the codebase to support the Portuguese language. Sohom (talk) 00:36, 6 May 2026 (UTC)

Thanks for your response. You might be missing a major point about a wishlist: prioritization. The fact that a tool already exists elsewhere or is easy to develop is eventually less relevant than the fact that it was wished for by the community through a community-driven methodology. The wishlist allows us to identify community pains and deploy resources to solve it. This particular archiving tool was also an opportunity for developer training through the outreachy program. The tool that was developed for Wikipedia in Portuguese has indeed relied on existing tools with some adaptations. Joalpe (talk) 10:40, 6 May 2026 (UTC)

@Joalpe The fact that a tool already exists elsewhere or is easy to develop is eventually less relevant - I do not follow how that is less relevant? Why was there a reinvention of a existing bot through outreachy at all? I'm familiar with outreach programs, having come into the movement through GSoC (Outreachy's sister program) and the programs have nothing to do with community prioritization which happens in the wishlist (we are explicitly encouraging community prioritization in our model, only stipulating that it be done in a transparent manner). The fundamental problem that we are trying to solve is that now the ecosystem of archiving bots has been split into two separate pieces doubling the maintenance cost across the movement. Under the PTAC model, the separate bot should not have been developed and the developer training wrt to outreachy should have been spent on building a tool for which no actual alternative existed. Sohom (talk) 11:39, 6 May 2026 (UTC)

@Sohom Datta I believe I have already explained why I believe the Lusophone Tech Wishlist is an interesting example alongside the CEE Hub model. Is there anything in my initial comment that was unclear to you? Joalpe (talk) 10:44, 6 May 2026 (UTC)

@Joalpe, Is there anything in my initial comment that was unclear to you? - I still fail to understand how/why Luusophone Tech Wishlist is fundamentally a different model to the CEE one. Sohom (talk) 11:15, 6 May 2026 (UTC)

@Sohom Datta Is there a CEE wishlist at all within CEE? I'm not familiar with it, I don't see a link to it in the recommendation. I think it might be worth to mention some other solution as examples and WMDE and whislist mentioned by Joalpe seem interesting. I only see a one-time CEE survey, WMDE has been doing whislists for years. Nux (talk) 14:17, 6 May 2026 (UTC)

@Nux: Not that I know of, though I do see the survey, followed by acting on a survey as a "wishlist-like" model (maybe we should have called it that?). CEE Hub's version is probably one of the more/most light weight implementations of it, which is why in my mind, featuring it makes sense, since adopting it is a lot easier than the more formal WMDE TechWishes model. This does not mean that the others implementations are invalid/less preferred (in fact I personally really like how WMDE does TechWishes and they definitely fit into and exceed the recommendations). That being said, I do hear y'all and will talk to other folks on the council about whether to feature other examples! Sohom (talk) 14:51, 6 May 2026 (UTC)

An ode to the status quo?

While this recommendation does seem like a list of somewhat straightforward recommendation for affiliates to be more involved in the technical space, what stands out to me is that it makes no judgment about whether this barrier to entry is appropriate for our movement. PTAC is saying that even for an affiliate of our movement, participating in the development of a mediawiki extension is "an extremely complex and time-consuming process" and that is fine?

We do have an extremely high barrier of entry into our technical spaces, that is the status quo. For PTAC to enshrine that status quo in its recommendations is a very different matter. If this does stay in the final documment, the recommendation must acknowledge the harm a high barrier of entry into technical spaces causes our movement. Chico Venancio (talk) 19:39, 7 May 2026 (UTC)

Agreed, this was my reaction as well. This may be practical for now but long-term it means that zero new affiliates can develop MediaWiki technical capacity and that it'll continue to remain a WMF/WMDE duopoly. It's great that CEE was able to improve Cat-a-lot, but honestly, Cat-a-lot is such a core feature at this point that it shouldn't exist as a gadget and should be in MediaWiki proper.

I would expect a document like this to also include some level of aspiration of where we want affiliates to end up. Legoktm (talk) 18:40, 9 May 2026 (UTC)

Logistics around documenting + finding tools

I like that accessibility and making tools easier to find is a key component of this proposal but I would like there to be more discussion on logistically how this could be achieved. Would it make sense for other regional hubs (if there is one in a region) to lead on this since this proposal is based on a model created by the CEE hub? If not, how would multiple affiliates in the same region align on a single source of truth for the documentation of tools? If every affiliate who is interested ends up working on the components outlined in this model, how do we avoid duplicative work and the solution creating more of the same problem we're trying to solve? This all may have already been discussed but it would be great for us to have a detailed implementation recommendation to review. Pacita (WikiNYC) (talk) 22:38, 7 May 2026 (UTC)

Toolhub is a technical solution that the Wikimedia Foundation worked on in 2018 & 2020-2022 to provide the movement with a central repository for cataloging tools. It provides an ability for tool maintainers and tool users to collaboratively document the existence of tools via both a web interface and a programmatic API. Approximately 4200 tools are currently documented there. This is certainly not the complete breadth of tools created by and for the work of the Wikimedia movement, but it is a more comprehensive effort than I have seen elsewhere to date. Finding ways to increase discoverability and adoption of this technical solution in attempting to solve the social problem of tool discovery would be welcome by many. I have shared some ideas in other forums that I have had about additional technical work that could enhance the current system; the main one for me would be extending mw:Extension:Toolhub to provide additional on-wiki integrations with the catalog. toolforge:toolhub-extension-demo is a live demo of the current Scribunto integration offered by the extension which can be used to fetch data from the Toolhub catalog. I think that adding special pages to make searching and adding content to the catalog available without leaving MediaWiki would be reasonable and useful additions. -- BDavis (WMF) (talk) 20:11, 14 May 2026 (UTC)

Thanks for sharing. Definitely agree with you that discoverability and adoption of this tool would be key. The work around the extension and providing more on-wiki integrations makes sense to me. If the goal is for this to be the main repository of tools and search for tools then I think an investment in the interface of the site would also be ideal to make it more user friendly and easier/faster to find a tool you might need for a problem. I imagine that's quite hard to figure out with over 4,000 tools but I think it's worth putting some time, energy, and resources to and also doing an analysis of how many of the 4,000+ tools might be duplicate solutions that might make more sense for developers to combine forces on and merge into one tool could be good. Pacita (WikiNYC) (talk) 17:54, 15 May 2026 (UTC)

@Pacita (WikiNYC), @BDavis (WMF) Re, imagine that's quite hard to figure out with over 4,000 tools but I think it's worth putting some time, energy, and resources to and also doing an analysis of how many of the 4,000+ tools might be duplicate solutions that might make more sense for developers to combine forces on and merge into one tool could be good. I have personally toyed with the idea of looking through all the tools on Toolforge as a Toolforge standards committee member and trying to find overlaps/unmaintained tools and such, but have always been dissuaded by the realization that I could be accidentally yanking on critical infrastructure by accident. This kind of pruning and consolidation is best done at a community level rather than in a top down manner. Sohom (talk) 01:20, 16 May 2026 (UTC)

I assume quite a lot of the tools are duplicative of tools created by other users. There are many separate workflows that Wikimedians use to do their part of the collective work of the movement. Many of these workflows benefit from assistance by technology currently missing from common platforms like MediaWiki. This commonality leads to many flowers blooming to help try and solve the workflow toil and annoyances.

This is potentially an unpopular opinion, but I think it is actually a good result to have tools with overlapping scope and utility available thanks to the efforts of our volunteer technical communities. The diversity of solutions allows for innovation and some amount of redundancy that would otherwise be difficult to achieve without paid contributions. It turns out that the vast majority of technical volunteers are more interested in what we commonly call greenfield development than they are in investing extra effort in the communication and coordination needed for collaborative software development.

The types of collaboration that the w:en:Wikipedia:BOLD, revert, discuss cycle enable for articles and other content are more difficult to reason about and apply in a technical project where real damage could be done by allowing any and all potential contributors to modify and deploy software changes to commonly used tools. On-wiki we tend to deal with this difference using a combination of protection levels (autoconfirmed, admin, interfaceadmin, etc), casacading protection, and active patrolling. Taking that kind of community care for shared maintenance of off-wiki tools is currently not a trivially solved problem. -- BDavis (WMF) (talk) 16:51, 18 May 2026 (UTC)

@BDavis (WMF) Yes and no, I'm not necessarily against greenfield development (done my fair share of that) and do like it being encouraged at hackathons/would like to encourage it at a individual volunteer level, but at a community level having 5 tools (one of which might even be broken) that do the same thing makes it confusing as a end user. Sohom (talk) 00:30, 19 May 2026 (UTC)

On the other end, (my intuition is that) affiliates are well positioned to do the comms, coordination needed to solve this at a community level, while even collaborating with the individual developer to improve the tool in question. Sohom (talk) 00:32, 19 May 2026 (UTC)

Extending time for feedback

Noting that time for feedback has been extended until May 15th! Sohom (talk) 19:42, 9 May 2026 (UTC)

May 14 is a holiday. Most WMDE staff is not working on May 15. I just learned about this RfC a few days ago via a rather unofficial channel. It really doesn't look like this was properly communicated with the parties at WMDE that will be affected by the surprisingly harsh limitations proposed in this draft. Will these people get another chance to become part of this process? Thiemo Kreuz (WMDE) (talk) 15:42, 13 May 2026 (UTC)

@Thiemo Kreuz (WMDE) Feel free to leave feedback even after the "official" end date. I'm amenable to extending the date further if feedback is incoming. I just learned about this RfC a few days ago via a rather unofficial channel. I did send out a notification through wikitech-l, wikimedia-l and TechNews, my assumption was that folks who are interested in this space would monitor those channels. Sohom (talk) 15:54, 14 May 2026 (UTC)

It appears like I'm misunderstanding something, or do I? The document sounds like it can heavily affect the way WMF and WMDE work together. I don't think this mail made this clear. Nobody is required to read these mailing lists anyway. Do you plan to actively contact at least the affiliates that have active software departments? Thiemo Kreuz (WMDE) (talk) 07:46, 17 May 2026 (UTC)

@Thiemo Kreuz (WMDE): The document sounds like it can heavily affect the way WMF and WMDE work together. I don't think this mail made this clear. The point behind the proposal/RFC is to nudge new/incoming affiliates who want to contribute to the tech space and to provide a set of guidelines surrounding prioritization that are for the most part followed in a ad-hoc manner within the affiliate space. Nothing that the proposal is saying is necessarily radically different from what was already status quo. I think there are legitimate concerns about whether or not the higher barrier of entry is a bug or a feature (and thus whether it should be codified in the recommendation) However, I'm not sure which part you think can heavily affect the way WMF and WMDE work, I'll be interested in hearing more.

Nobody is required to read these mailing lists anyway. Do you plan to actively contact at least the affiliates that have active software departments? I have not gone and individually reached out to affiliates, and I'm not privy to a list of affiliates that do have software departments (If there is a canonical one, feel free to send it to me via Special:EmailUser, I will happily reach out to them). While I agree with the wording of "nobody is required to read these mailing lists" a lot of people do read the list, and I really don't see how I could have better reached out to folks without giving the appearance of en:WP:CANVASSING random affiliates that I happen to know about. Sohom (talk) 22:24, 17 May 2026 (UTC)

At no point does the document mention "new" or "incoming" affiliates. Are we talking about different documents? "Not sure which part you think can 'heavily affect the way WMF and WMDE work'". Again, are we referring to different documents? This presents affiliates as a problem because they would "fragment the tool ecosystem", create "new tools when old ones could be improved", don't focus on "real community-specific problems", and don't do "surveys, listening sessions, direct outreach, and analysis of data". Concluding that they all need to "refrain from" (i.e. stop) "developing new MediaWiki extensions, core MediaWiki code, or production services".

Why you bring up "canvassing" is beyond me. All I'm asking for is to play fair and give known, directly affected parties a realistic chance to notice and respond. Thiemo Kreuz (WMDE) (talk) 06:34, 18 May 2026 (UTC)

@Thiemo Kreuz (WMDE), I think you are connecting more dots than the document was intended to connect ? Specifically, Concluding that they all need to "refrain from" (i.e. stop) "developing new MediaWiki extensions, core MediaWiki code, or production services". - The operative part here is the part that you left out, "without WMF buy-in" (i.e. the WMF knows and is okay with said development). The MediaWiki components/new extensions/production services that WMDE works on is typically (to my understanding) discussed with the WMF through the Annual planning process and as such has "WMF buy-in". The mandate is not to "stop developing MediaWiki extensions" but "ask WMF before working on complex technical features on MediaWiki core/deploying production services/trying to deploy Wikimedia extensions", which I think has been status-quo for a while. Similarly, I don't think the document is saying "all affiliates are doing X, Y and Z and so we will bar them from mediawiki development", rather it is saying "there have been previous problems regarding X, Y and Z wrt to affiliates, so we want to propose this model (model which is mostly a restatement of status quo)". For what's worth, I do believe (as I've said in this page), the WMDE TechnicalWishes program is a model version of what I would expect a well run version of the proposed model to look like.

Regarding "canvassing" I think a better way to phrase this would be "I did not want there to a appearance of bias based on me notifying affiliates I knew about vs the ones I did not". I will go through the list that you have linked and notify all affiliates on that page over this week. Sohom (talk) 16:41, 18 May 2026 (UTC)

Noting that I sent out this email to that correspond to the emails listed for all the orgs under the chapter header. Sohom (talk) 18:58, 18 May 2026 (UTC)

Even with that caveat, its very hard to read the statement as anything other than: affiliates should go away. Bawolff (talk) 16:00, 19 May 2026 (UTC)

I will take some blame for that, that sentence was my addition, the intention was not to read it as "affiliates go away" but rather, "mediawiki dev is hard ask the WMF before doing it" -- which I think is fairly sound advice about the status quo, but yeah the wording is sub-optimal/has come off a fair bit sharper than I anticipated. Sohom (talk) 04:21, 20 May 2026 (UTC)

The sentence I quoted sends a clear signal: That affiliates shouldn't bother touching MediaWiki core because it's way to much hassle for everyone. Which is true in a way, I guess, but something I would love to improve instead of blaming affiliates for. Besides I start wondering why all this focuses so much on the WMF? MediaWiki isn't owned by the WMF. Not even de facto. Approx. 60% of MediaWiki's components and 30% of WMF-deployed extensions aren't officially owned by anyone, neither inside nor outside the WMF. How is the suggested "WMF buy-in" supposed to work for these? Thiemo Kreuz (WMDE) (talk) 17:09, 19 May 2026 (UTC)

WMF owns deployments, so if you want to deploy something new you kind of do need their buy-in (Which is reasonable imo). I think 80% of the time that is what affiliates are trying to do. If an affiliate wants to go do bug fixing or minor feature development, then really they don't need WMF buy-in, just buy-in from someone with +2 (maybe even someone they hire). However in my experience its rare that affiliates ever do that sort of thing. Maybe they should do that type of work. Its a much better starting point to learn how things work, and when something goes down a wrong path, its much easier to course correct in that type of work. Bawolff (talk) 02:50, 20 May 2026 (UTC)

Affiliates don't have the money to go around and hire MediaWiki +2'ers, let alone properly manage them. This proposal seems intended to keep it that way. Nemo 21:45, 20 May 2026 (UTC)

If affiliates want to participate in software development, they are going to have to put in the resources to do so. Otherwise what is the point this entire discussion. Bawolff (talk) 03:13, 21 May 2026 (UTC)

What is even proposed here?

I want to reiterate a few points that have already been made above as well as add my own. Note I'm writing this as an individual long-time technical contributor (10+ years volunteer, 12+ years at WMDE), not as a WMDE representative. I would love to involve my team leads but given the short deadline there is just no time for that left.

1. Doesn't this mostly describe the status quo? Maintaining tools instead of "developing new MediaWiki extensions" or "core MediaWiki code" is exactly what affiliates already do. What is the proposed change?
2. The entry barrier to contribute to e.g. "core MediaWiki code" directly as well as "developing new MediaWiki extensions" is already extremely high. We are discussing this as a problem within the technical MediaWiki community for many, many years. Several parties are desperately trying to lower these barriers, not raise them.
3. The wording is confusing and even contradicts itself. While the text starts with "affiliates […] have expressed interest in contributing to the technical side of Wikimedia projects" the suggested solution is to "refrain" and limit them in what they can do? I'm afraid I don't understand the logic behind that.
4. I would say that a lot of "old tools", "insufficient documentation", "language barriers", and generally duplicated efforts are because of projects WMF historically did, but stopped developing further when e.g. funding stopped, teams got restructured, or simply got the next project assigned. The fact we have e.g. 57,000+ open Phabricator tasks is partially because of that. But the text makes it sounds like this would be a problem that's exclusive to affiliates. This doesn't match the reality I have seen the past years.

I hope this is helpful. Please ask if I wasn't able to explain some of these points clear enough. --Thiemo Kreuz (WMDE) (talk) 16:34, 13 May 2026 (UTC)

The soft-skills gap

In my opinion one of the reasons affiliates fail to make impact in technical spaces is a soft skills gap. They often fail to properly identify and engage with stakeholders, fail to properly understand the problem they are trying to solve, fail to collaborate. I think this is exacerbated by affiliates tending to come from organizational backgrounds where they assume that the tech is the part they dont understand, so are blind to their own limitations when it comes to the mushy-people stuff in the context of software development (WMF's insular culture is also not helping matters and seems to be getting worse as time goes on). I think that is why this document reccomends to invest in tools. Tools are like playing in your own sandbox, you dont have to talk to anyone so you dont have to have people skills. However it also severely limits the type of impact you can make. I think all this is sad. If i had advice to affiliates who want to make a technical impact, i would say invest in high quality product and project managers. Bawolff (talk) 20:30, 13 May 2026 (UTC)

If i had advice to affiliates who want to make a technical impact, i would say invest in high quality product and project managers.

This! So much this. I have tried over the years to help with a number of projects where a few days of planning discussions could have saved both the affiliate and the WMF months of pain. Building something in a way that can be deployed and supported in the Wikimedia production network is not likely to happen by accident. A typical contract developer will make nearly every decision "wrong" from the point of view of our systems if only because the traffic scale and FOSS restrictions we operate with are not "normal" at all. -- BDavis (WMF) (talk) 23:45, 18 May 2026 (UTC)

I respectfully disagree. From my business experience as a "typical contract developer", the industry suffers from lots of project managers that sometimes do not even understand the product they are working on. Getting high quality managers to work on us will be next to impossible. Let's be frank: it is guerilla skunkworks projects that change the world, not the project managed ones. Yes, the architects hate them, since they do not conform to the data protection requirements, performance requirements, authentication requirements, are deployed in a wild way and so on. But we should have gates open to them. We should be able to grow things gradually and let them ripe and become the part of the solution. I see them being deployed in super serious industrial factories. They do not seem to break right away and things cost real money out there if they go down.

We are happy to work with what I think might be the most customizable software in the world, MediaWiki. It is amazing how during the lifetime of this ancient software product it gets localized and enhanced by extensions, skins, user scripts, templates, modules and other stuff that anyone can participate in, without sometimes needing even an "interface admin" flag. That kind of permissionless wild development brought us wonderful tools that keep the community alive. Of course there are natural barriers, such as infrastructure management and security, but those we can overcome with things like WM cloud and I think it is working out pretty good.

We should work towards removing the barriers between the need (the requirement), the code and the infrastructure. The closer you are to the user (ideally if the requirement is a pain point of someone who is qualified enough to code), the less project management, tickets and deployment plans you need.

A tiny example here (I do not write it here to solve that particular issue): I started to experiment with mw:Extension:GuidedTour which might have a pretty good potential in helping to onboard new people that didn't work with the technical side of the software before. The extension page warns be about the potential performance problems with that tool, but the linked phab:T264817 seems to be stuck in some kind of limbo, which makes me think the problem isn't that critical.

Can I use the tool and promote it more widely? If not, what should I do instead? Getting a project manager for the GuidedTour extension is probably not a solution to the problem...  « Saper // talk »  09:57, 19 May 2026 (UTC)

The solution to the guided tour problem would be to fix guided tour. The problem isn't that complicated, the issue is that nobody cares. Getting a PM for guided tour isn't the solution. Getting a PM for the group that wants to use guided tour is. Questions like, can i use a specific dependency or what do i need to do to make a dependency meet requirements so i can use it, are exactly the job description of a PM. (Of course this is a kind of trivial example that anyone can figure out)

To be clear, i'm not just saying get project managers to better comply with WMF requirements (as important as it is). I'm also saying to do it to comply with community requirements. Its one thing if someone from the community makes software, usually they have at least internalized what the community wants on some level. In my experience a big problem is that affiliates often hire an external contractor to do something. The contractor will do exactly what the affiliate asks for but not what they actually need. Affiliates often do not understand their own requirements. And yes, shitty PMs make things shitty, but good PMs are worth their weight in gold.

I do think there is room for permissionless development as you call it - if you can do what you want via a template great. Like anything else though, if you want to make the biggest impacts, you have to cooperate with others because your change will effect others. Even for a template if you are rewriting a popular lua module used on a million pages, you have to coordinate with other editors. In the context of Wikimedia, often there are hidden maintenance assumptions, e.g. affiliate makes some sort of low quality program that is 90% done then expects WMF to finish it and maintain it forever, which is just unreasonable. I think one of the main reasons why WMF is hostile to affiliate development is fear of entrapment, which stems from experience.

One thing i disagree with Bd808 on, is i don't think Wikimedia is special. Most of the failure cases here are exactly the same as they are in the corporate world. Everyone has compliance requirements they have to follow even if the details differ. Everyone has issues where customer requirements can be a bit of a guessing game. Everyone has operational requirements they have to comply with to integrate with the larger system. Everyone has interdependencies they have to take into account. If affiliates acted in the corporate world the same way they acted in Wikimedia, they would fail just as hard. Bawolff (talk) 15:45, 19 May 2026 (UTC)

A modest proposal

Explaining magic words, parser functions and other advanced wikitext features in 2007

I remember back in 2007 when I was explaining to plwikipedia contributors I said we have only two core MediaWiki developers onboard and that we are unlikely to get any significant features into the software at the time, so the user scripts are the way to go (or an extension if we are really really lucky). Today, in 2026, I would say we have 200(300, 400?)+ software developers onboard and we are unlikely to get any significant features in :)

I propose we look at the gigantic red tape we have in our projects right now. I recently had a run across various products (such as outreach dashboard, wm cloud, wikidata, some core extensions) and the feeling of being stuck everywhere was larger than ever. And I work as a consultant to Fortune 500 companies, also dealing with compliance requirements, and sometimes I think we can be worse than them. Even the culture has changed.

To make it more actionable, let's have a look at Phabricator tickets first, especially the processes around it and how various (non)volunteer teams work with it. How things stay there, how things die there, how things get broken up into sometimes tiny items that get pushed through the task boards for ages... We might probably need a qualitative analysis of those processes (not just another(?) quantitative research). I hope that one day "it's on phab" will no longer be a running joke as it is right now.  « Saper // talk »  09:22, 19 May 2026 (UTC)

@Saper Is this WMF you are talking about or Wikimedia Polska ? Sohom (talk) 15:56, 19 May 2026 (UTC)

Although I work together with Wikimedia Polska closely, I speak for myself here only - not quite sure which part do you refer to, so trying this:

"we have 200(300, 400?)" - total number of software developers, mostly WMF - I don't know the exact number plus there is a significant number of the contributors from other organizations like WMDE and volunteers. Wikimedia Polska does not have any developers in their permanent team.

"our projects" - I should probably make a more detailed write up on this one, but this is not the place.

Not sure if that answers your question?  « Saper // talk »  17:24, 19 May 2026 (UTC)  « Saper // talk »  17:24, 19 May 2026 (UTC)

I think there is a mistaken assumption here that phab is where it is determined what people work on. While there is a suggestion box aspect to it, primarily it is a place for people to write down for themselves what they are working on. Bawolff (talk) 15:58, 19 May 2026 (UTC)

Thanks @Bawolff - maybe I have fundamental misunderstanding what the Phabricator is or should be. Most of the tickets I search for are "Open, Need Triage" or otherwise limbo/stalled items which range from minor bugs to wishlist items to architectural improvements. Not sure what to make out of it but maybe this misunderstanding is a problem in itself.  « Saper // talk »  17:26, 19 May 2026 (UTC)

Funding methods

My understanding of this document is that it's supposed to propose ways to distribute additional funding for affiliates to work on software development ("technical projects"). This is where most of Wikimedia Foundation's budget is spent on, often with a dubious return on investment, so it's an important topic to discuss.

The problem statement is:

The Wikimedia Foundation also lacks clarity about which technical projects to fund in the affiliate space that align with volunteer contributors' needs and the Foundation's priorities.

If I understand correctly, the proposal is to sidestep this problem by:

• eliminating the need for alignment with the WMF (by ruling out dependencies on WMF, like code review for MediaWiki code);
• delegating the task of figuring out priorities to a new entity which would be some sort of federation of existing communities.

First, this is a sensible idea for risk-reduction but it clearly can't cover all potential needs (for example, we can't forever postpone figuring out the alignment between the WMF's and the community's priorities, or the priorities for MediaWiki development). Perhaps it would be worth clarifying at the beginning that this is just one of many models we can have, and this is just a proposal for one additional funding method.

Second, given all the ideation work is delegated to a new entity, this will need a substantial initial funding to kickstart the process, even if the project ends up being hosted by some existing affiliate with sufficient budget capacity. (This would be the investment in "soft skills" which Bawolff mentions above.) In other words, there will be a significant overhead at the beginning, but this is nothing new; it would just make the existence of such costs more explicit, while currently they're buried in the WMF's budget or in off-budget externalities thrown onto the shoulders of WMF employees and volunteers. So I would also recommend to clarify that we acknowledge there will be a need for funding which for a certain period may not produce clear deliverables. Nemo 18:02, 19 May 2026 (UTC)