Modernize Technical Contributor Tooling

Q 1 What is your Recommendation?

Invest into modern and efficient developer tooling for technical contributors maintaining community tooling (such as Toolforge tool authors, Cloud VPS project owners, bot and power user app authors, gadget developers, template and module editors, AbuseFilter managers), possibly by coordinating and expanding existing capacities (such as the WMF Cloud Services, Technical Engagement and Developer Productivity teams) and adding new where needed (such as on-wiki tool support).

This effort should encompass areas where we already provide technical support but it falls short of the developer experience contributors are used to outside the Wikimedia world (such as our community infrastructure and platform offerings, or editing interfaces for on-wiki code) and areas where contributors are largely on their own today (such as code sharing and localization, code review, continuous integration and code deployment for on-wiki code, or logging and monitoring for hosted code), and have the mandate and resourcing to review past design choices through the lens of developer experience (e.g. replace home-grown or uncommon languages with popular ones, allow using common tools, paradigms and libraries, interactive computing for bots), and through the lens of identifying capability gaps for our knowledge as a service aspirations (e.g. can our execution platforms such as Scribunto and gadgets enable maintenance work in a scalable and robust manner, or allow for delivering quality experiences for niche reader needs in a secure way?).

Q 2-1 What assumptions are you making about the future context that led you to make this Recommendation?

Becoming the infrastructure of free knowledge is a vast undertaking and will require a large increase of technical capacity. It will especially require us to address the capacity blindspot we currently have around power user tooling - power users heavily rely on decentralized tools (gadgets, templates and Lua modules, Toolforge tools, bots, desktop apps) built by members of their own community who are expert in their problems, workflows and use cases (and this is especially true for machine-readable and largely machine-maintained projects like Wikidata, which are particularly important for knowledge as a service), but we don’t understand and support these tool maintainer communities, and the development environments we provide them are substandard and frustrating to use (and in some cases, expose tool users to risk due to the lack of sufficient decoupling). If we expect them to be able to scale up to the challenges of the strategic direction, we need to provide them with adequate tooling.

Q 2-2 What is your thinking and logic behind this recommendation?

This recommendation aims at building technical capacity for the niches - user groups which are currently poorly served by the large movement organizations which are mainly concerned with the core reader and editor experiences shared among many projects and demographics. To attract, retain and enable the technical contributors who are well-positioned to serve these niches, we need to invest in giving them the development platforms they need, closer to parity with the tooling they have come to expect outside Wikimedia. Having to deal with non standard tooling and complicated workflows to get the work done will alienate many of those contributors; we would like to see a sustainable and coherent way of supporting and attracting them.

Q 3-1 What will change because of the Recommendation?

The direct impact will be better tooling for technical contributors, leading to higher efficiency, better engagement and retention, and a gentler learning curve. The indirect impact is a larger and more diverse pool of technical contributors doing more efficient work, and thus better tooling support for power users (who form the heart of our projects), for low-key / early-phase partnerships, more capacity to adapt tooling across project types and languages, and increased resilience to local breakage or problems.

Q 3-2 Who specifically will be influenced by this recommendation?

Tool developers (and probably volunteer developers as a whole), whose development and operations workflows will be improved. Since the tools they build benefit editors as well by giving them more options to do their work they are also a stakeholder in this process.

Q 4-1 Could this Recommendation have a negative impact/change?

Implementing the recommendation would require some investment, or rearranging, or resources. It might turn out to not be the most efficient use of those resources.

Empowering our tool authors might give them capabilities that can (via broken or malicious code) expose end-users to harm and movement entities to legal risks.

Q 4-2 What could be done to mitigate this risk?

Monitor and analyse the current and potential impact of the various tool environments, and survey whether developer tooling is indeed the biggest bottleneck to their growth.

Ensure technical contributor communities follow privacy and security best practices and self-police, via outreach and training. Where feasible without crippling the capabilities of the potential tools, limit access to security- and privacy-sensitive functionality.

Q 5 How does this Recommendation relate to the current structural reality?

The recommendation would be implemented by building or increasing some organization’s capacity to work on technical contributor tooling. Presumably this would be the WMF which does some of that work already (via Cloud Services, Technical Engagement, Developer Productivity, to some extent the Platform Evolution program’s API usability enhancements), although there are some areas (especially around on-wiki technical contributor tooling) where no formal supporting group currently exist so another organization could be just as well positioned to pick up the work.

Q 6-1 Does this Recommendation connect or depend on another of your Recommendations? If yes, how?

The recommendation has strong ties to Technical Contributor Engagement Models, as they are the two sides of increasing technical capacity by growing and empowering the technical contributor community. It might be related to Developing an Evolving Technology Vision and Strategy as our execution platforms might need an overarching vision.

Q 6-2 Does this Recommendation connect or relate to your Scoping Questions? If yes, how?

It attempts to answer the following scoping questions:

How can we encourage and embrace volunteer and third-party contributions to product and technology work?

How can we better support contributors in doing technical work (such as development of MediaWiki and other Wikimedia software, operating tools or bots, bug reporting, performing tech support or tech ambassador roles)?

Q 7 How is this Recommendation connected to other WGs?

Enabling technical contributors is a form of capacity building, so it relates to that working group.

One of the effects of modernizing this tooling could be increasing the diversity of the technical contributors, and increase the tool support for a diverse userbase and audience, so it potentially relates to the Diversity Working Group.

Movement Strategy/Recommendations/Iteration 2/Product & Technology/6B

Contents