MediaWiki Product Insights/Artifacts/Cross-Wiki Code Collaboration

This document describes the reasoning behind the planned experiment to improve the cross-wiki code collaboration experience and the challenges of the problem space.

Co-author: Mateus Santos Co-author: Subbu Sastry

Code collaboration

One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.

While wikis operate independently for the most part, there have always been cross-wiki collaboration needs. Meta-Wiki enables strategizing, planning, documentation and coordination across wikis. Commons and Wikidata let wikis share media and structured data across all wikis. But, there is no such ability for code - gadgets (JS), templates (wikitext), modules (Lua), styles (CSS) - even while wiki-based code is core to the authoring, rendering, curating, and administrative needs of every single Wikimedia wiki.

Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.

Here are some of the main problem areas.

Template usability and discoverability

It is well understood that wikitext templates are hard to read, write, and maintain - they were not designed for all the uses that they have been put to over the years. The introduction of Lua (as part of Scribunto) as a real programming language significantly mitigated this problem. While Lua improves some of the usability issues, the conflation of data processing and output formatting still impacts usability and reduces module & template reusability across wikis.

Similarly, discoverability of templates when editing articles is a known problem. The community wishlist team is tackling template discoverability right now with template favouriting.

Templates as workarounds for missing features

Templates are used for a lot of workflows and use cases that ideally MediaWiki would provide intentional and well-designed support for. There have been various ideas floated over the last decade to address this to reduce the proliferation of template-based solutions including but not limited to:

• extensions for certain popular templating use cases like infoboxes and navboxes
• more generic no-code page components that editors could use to compose an article
• first-class MediaWiki platform features for workflows and other use cases that are currently handled by templates

MediaWiki platform features to replace some templating use cases deserves product exploration. But, fundamentally, as long as programming language support for writing code is present, the collaboration concerns do not go away. There is no getting away from the fact that when possible, users are going to use the full power and features available in programming languages to do what they need to do. They will always be some steps ahead in building tools for what they need compared to what the MediaWiki platform can provide customized features for. This will be a faster solution for them and so, on-wiki code and code collaboration needs will continue to exist independent of any bespoke platform features.

Absence of a shared template ontology

Another problem is the absence of identical templates across wikis to represent the same idea / concept / knowledge-unit / what-have-you (ex: “infobox”). This complicates products (internally and externally) as well as makes it harder for multi-wiki editors when they need to handle a potentially identical concept across wikis (ex: “infobox”). Taking the Content Translation tool as an example, when an article is translated from one wiki to another, often, it is not possible to easily migrate a template used in the source wiki to something equivalent on the target wiki.

However, unless all wikis agree to and collaborate on the same underlying conceptual knowledge model off which templates are based, products (internal or external) will have to grapple with this complexity. Even if one starts with a perfectly unified set of templates, there will be forks and local customizations to meet the needs of specific groups - there is nothing (technical, social, policy, or governance) stopping this. And, wikis want these abilities to copy, modify and customize (“fork”). So, while a unified template could prevent premature new forks to a certain degree, any successful wiki, once it reaches a certain scale is likely to diverge in small and big ways to meet the unique needs of their wikis (see this report). So, that brings us back to the original problem.

Challenge bootstrapping new wikis

Whenever a new wiki is launched, if its volunteers have to write their own templates from scratch, this task hampers their ability to work on encyclopedic content. While wikis sometimes copy templates from other wikis, this is not very well supported right now. More importantly, when these copies go unmaintained, that degrades the quality and usability as the original templates and the underlying MediaWiki platform evolves.

Code duplication and divergence

As discussed above, new wikis often tend to copy code (templates & modules) from other wikis as part of their bootstrapping. But, copying is definitely not limited to small wikis. Copying code across wikis and subsequent customization and divergence is not uncommon. As discussed in the shared template ontology section, it is not possible to prevent customization and divergence of copies.

Note that even if we provide a centralized code repository (without the ability to create local versions), customized modules and templates that are specific to a single wiki can and will still be created in the centralized repository. So, a centralized repository cannot prevent code duplication and divergence, but it can facilitate code reuse across copies.

How about global templates?

The idea of global templates has been proposed as a strategy to broadly address cross-wiki code collaboration and effectively championed by Amir Aharoni. However, it might be useful to distinguish between code sharing and global code usage.

Templates are used on wikis today for a number of different use cases. Wikis legitimately have different policies and workflows, and templates used for those are unlikely to ever be global, even as they might be shared / reused to different degrees. But, certain kinds of content templates (ex: citation related templates) are likely to be more universally useful and shared a lot more widely.

When users advocate for "global templates", they may care more about shared code availability rather than global usage of any particular piece of code, which is hard to guarantee and also runs into thorny cross-wiki governance issues. While cross-wiki code sharing overlaps with global templates as an idea, it doesn’t aim to solve all the motivating use cases for global templates. Code can still be duplicated and diverge; wikis can share as much or as little code as they wish; there will not be a common template ontology across wikis. Content Translation and other products will still need to deal with template divergence across wikis. We believe this narrower framing simplifies the social and technical implementation challenges while avoiding some cross-wiki governance questions.

Given this, we think it is better to use a “cross-wiki code collaboration” framing rather than global templates for approaching this problem space. But the fundamental intent behind the global templates proposal – the need for a shared code repository – is sound and is going to be part of any solution that attempts to tackle cross-wiki code collaboration. But, what is less clear is what form this shared code repository should take: a centralized module & template wiki, wikifunctions wiki, shared module libraries shipped with Scribunto, git-based collaboration with a supported solution to sync to wikis, some hybrid of these?

It is also worth pointing out that even this simplified framing comes with a number of technical implementation challenges and would need to be worked through carefully.

Summary and way forward

Based on the discussion above, the following considerations emerge:

• Cross-wiki code collaboration is a problem worth tackling.
• No single solution can address all these (and other code collaboration) problems.
• Wiki-specific code customization and divergence is inevitable.
• We will not arrive at a global data / knowledge model across wikis.
• While global code usage cannot be guaranteed or enforced, code sharing will likely be embraced and can mitigate (even if not solve) some of these problems.

This is an initial attempt to acknowledge the existence of a significant problem that has persisted for many years. The resolution will need deeper exploration with stakeholders across communities, engineering staff, and movement bodies like the PTAC. Solving problems in this space will require a shared understanding around priorities that will be most impactful.

Next steps

With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.