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)

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 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)

Extending time for feedback

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