Movement Strategy/About/Initiative/Cross-project tool development and reuse

Links to descriptions of related projects

The description of this initiative, as it appears at Strategy/Wikimedia movement/2018-20/Transition/Discuss/Improve User Experience, has three parts. In this section, I'll give links to relevant projects about each part.

Tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry.

The first thing to do here is to build the Global templates repository (more precisely, templates and modules. This has been requested by hundreds of people since 2004. Templates are the most important kind of community-developed tool, and the one whose lack of sharing hurts our projects the most, both the bigger and the smaller ones. It's the blocker for practically everything else in the "Improve User Experience" cluster (see the section #Dependency for everything right here on this page. See also mw:Global templates/Relationship to strategy for a detailed discussion of how global templates are related to various strategic plans.

Wikidata is also basically a thing that helps connect cross-project and cross-language functionalities, although it needs a lot of improvements: Better integration with the client projects (a global templates repository will go a long way in achieving that), better performance for the query tool, etc.

Abstract Wikipedia is also such a tool, and it's already in development, but it's very unclear at this point how will the current templates will transition to Abstract Wikipedia. Making a global templates repository will answer this question well.

Clear pathways for advancing new wiki proposals (including new language versions) and for reusing community-developed software features on them.

How to Improve the Incubator, Amir Aharoni, Celtic Knot 2020

The first thing for this is addressing task T228745 in Phabricator: Allow creating an independent "incubator wiki" instead of hosting all new wikis in one Incubator wiki with prefixes. You may also watch the video in which I explain the background and the proposal. It's totally doable and not too complicated, and there's a lot of support for it. It just requires a bit of commitment from the Technology department in the WMF to do this project.

Developer tooling and high-quality documentation to allow technical contributors to create and maintain tools with usability and efficiency.

The main tooling for on-wiki developers are templates, modules, gadgets. The first step to improving them is making a global repository for them, where developers from different wikis will collaborate with each other and work efficiently, instead of working in 900 different wikis separately. --Amir E. Aharoni (talk) 13:13, 27 November 2020 (UTC)

Dependency for everything

This initiative, "14. Cross-project tool development and reuse", is the dependency for all the other initiatives in the "Improve User Experience" cluster:

The "project tools" in question are mostly templates, modules, and gadgets. Unless noted otherwise, when I use "tools" in this section, I refer to all of these.

9a. Methodology to improve the Wikimedia platform UX research, design, testing and community engagement

The design of each of our wiki is modified locally by tools. Without a way to share tools across projects, it's impossible to have an efficient discussion about a methodology to improve them.

9b. Community engagement around product design and UX

When the community members from different projects come to discuss such things, they talk about issues in their home wiki, with their own templates and gadgets. It's impossible to have an efficient discussion about that without sharing them, and trying each tool in different wikis. People who are used to the experience in one wiki won't even understand what the community members from other wikis are talking about.

9c. Adaptable UX to various devices

This is a very important thing, but if the tools aren't shared across projects, adapting them to various devices will have to be done in every wiki separately. This is so inefficient that it's essentially impossible. The tools must become shareable first.

10. Compatibility with Accessibility Guidelines

Another important initiative to make the dream in which we will be the ecosystem of free knowledge, and anyone who shares our vision will be able to join us. But as with 9c, if the tools aren't shared across projects, this will have to be done separately in each project, without interconnection.

11. Resources for newcomers

This is one of the biggest issues, indeed. But being a newcomer in each project is quite different currently, and most of the differences are not inherent to the culture of the particular language or wiki. The reason for them is simply the technical division between the templates and the gadgets in each wiki. If at least some of them could be shared, it would be possible to develop most resources for newcomers together, just once. This is demonstrated by the work of the WMF Growth team in the last year+: every time they deploy their tools for newcomers to a new wiki, they have to go through several weeks of talking to community members in that wiki and finding links to disparate policy pages, discussion pages, and templates. This is necessary given the current state of the technology, but it's extremely inefficient, slow, and wasteful. If tools could be shared across wiki, these deployments would be much faster and easier for everyone.

12. Peer-to-peer spaces

Peer-to-peer spaces are "Spaces that allow finding peers with specific interests, roles, and objectives along with communication channels to interact, collaborate and mentor each other." This is an excellent idea, whose time is long overdue. However, it must be implemented according to the current community practices: There are such spaces on the wikis already, as wiki projects, "barns", etc., and they are now mostly defined by templates and categories. Or worse, they function as external Facebook, Discord, WhatsApp, or Telegram groups. Every language community is distinct, but the tools for creating the spaces could be shared. And the primary on-wiki tools are still templates and talk pages. Making the templates shared across wikis will be an organic transition to efficient peer-to-peer spaces, without introducing completely new technology that the experienced editors will reject.

13. Platform functionality and documentation standards

This actually goes together with the next point. #13 is the social, written part, the policy; #14 is the technical implementation of it.

15. Partnerships to develop Wikimedia API

Even this part is affected by the lack of Cross-project tool reuse, more than people imagine. A lot of the data that external users want to access through APIs is in the templates, and as long as the templates' code is not shared, the APIs cannot provide complete solutions.

So there. The dependency is not obvious, and I hope that this section explains why is it important to work on implementing initiative #14 as early as possible. If it's done, doing everything else in this cluster will subsequently be much more efficient. --Amir E. Aharoni (talk) 09:20, 27 November 2020 (UTC)