Wikimedia Technical Engagement/Practices to support maintainers and high-impact tools

This page concerns a pilot project to develop practices to support maintainers and high-impact at-risk tools. This project will be prototyped in the tools ecosystem, and practices/programs should apply to other parts of the technology ecosystem. The proposal follows up on the two experimental team projects: Tool Impact Metrics; and Newcomer Support.

The situation
Data insights Today we have data on Gerrit contributors through the community metrics dashboard (Bitergia). We know which parts of MediaWiki and extensions have not been touched for 5-10 years and which projects don’t have active code maintainers. We need similar insights and data on tool developers and maintainers, their areas of focus, the impact of their tools, which resources they use, or if their projects use up-to-date programming languages, frameworks, libraries, etc. This makes it difficult for us to decide how/where to best support these developers and maintainers or advocate for their needs.

Tool maintainers and high-impact tools at risk A key challenge for any open-source project is that a single maintainer is often responsible for a project. When a tool is widely used, this presents a double challenge: It is a challenging decision for maintainers to pause or stop their engagement. Once they leave the project or move on to other work, communities would lose a critical tool for their work and projects. At the same time, it is challenging for maintainers to find someone to whom they can hand over a project. Communities’ workflows or projects, therefore, are at permanent risk. The abandoned tool policy ensures that taking over a project is generally possible. However, Wikimedia lacks people and consistent practices to enable maintainers to share the work with others or to hand over a tool to someone else. (Ad-hoc) support exists for some tools: For example, other people than the maintainer might respond to questions from tool users on a talk page or improve documentation, or tool users might give presentations or design tutorials for a tool they want to recommend to others.

Project scope
The focus of the pilot project is scoped around Toolforge tools that perform edits on a wiki. In alignment with the WMF's annual plan commitment, the selected tool for the pilot should be critical for Wikimedia Commons or Wikidata. The path to narrow this down could look as follows:


 * Tools that run on Toolforge -> shared data source (includes tools and bots)
 * Tools that run on Toolforge and perform edits/augment editing on the wikis -> aligned with the metrics: "wikis a tool is active on + number of edits" (includes tools and bots)
 * Tools that run on Toolforge, perform edits/augment editing on either Wikidata or Wikimedia Commons (includes tools and bots)
 * A specific tool that runs on Toolforge, performs edits/augments editing on Wikimedia Commons, has a high number of edits (either a tool or a bot)
 * A specific tool that runs on Toolforge, augments editing on Wikimedia Commons, has a high number of edits, and a single maintainer (or otherwise underserved)
 * A specific tool that runs on Toolforge, augments editing on Wikimedia Commons, has a high number of edits, a single maintainer (or otherwise underserved) and additional evidence that this tool is critical for the Commons community
 * A specific tool that runs on Toolforge, augments editing on Wikimedia Commons, has a high number of edits, a single maintainer (or otherwise underserved), additional evidence that this tool is critical for the Commons community, and the maintainer would like to work with us.

Note: "high number of edits" isn't the sole indicator for high impact - i.e., tools might be critical for curation workflows that don't necessarily translate into an increased number of edits.

Practices to support tool maintainers and high-impact tools at risk
There are multiple layers of how we can think about addressing this problem:
 * Provide data insights: How can we leverage data about tool maintainers and their work to inform Wikimedia’s programs, project focus, advocacy work, and decisions on the support that Technical Engagement or others in the movement could give to these tools and their maintainers? How could we inform developers about risk factors (i.e., outdated library)?
 * Avoid single maintainer burnout: There might be better ways to address this challenge than having one busy tool maintainer take over an abandoned tool or supporting the work from another busy tool maintainer.
 * Focus on newcomers: If the ones who are already doing a lot of work on other tools shouldn’t become co-maintainers of even more tools, the target audience for building more sustainable structures around tools is newcomers.
 * Diversify our thinking on technical contributions: Developing and maintaining a tool requires more than just code and programming skills. However, we tend to primarily think about code and the challenge of finding developers to co-maintain a tool in question. Today a tool maintainer often takes care of all aspects of the tools’ lifecycle: Design and product management, developing and maintaining code, writing admin and end-user documentation, gathering and addressing bug reports, communication, etc. Shifting our thinking from a one-does-it-all model and primary focus on code to an approach where people with diverse interests and skill sets are empowered to contribute to a tool would unlock our potential as a community. This would open the path for shared responsibilities and increased sustainability.
 * Effective temporary and casual contributions: Supporting a tool doesn’t have to be a tool-life-cycle-long commitment. What type of contributions could be attractive and suitable for newcomers/casual contributors to support tools and maintainers looking for contributors (code, docs, translation, etc.)? What would need to be in place to enable that? What type of initiatives can empower people to contribute effectively temporarily? What type of contribution would make a good fit for the pilot project?
 * Build support networks: The ultimate goal might be to build support networks around a critical and high-impact tool: A network of people who care about a tool, contribute to it in various ways, and with a set of practices that enable others to contribute effectively occasionally and temporarily. What (existing) initiatives could we support or bootstrap to help distribute the work required to maintain and evolve a tool on more shoulders?

The role of casual/temporary contributions
Casual/temporary contributions are one way of contributing. Thinking about this might also help us explore how best to break down tasks and ways of providing support. Casual contributions play a significant role in open-source projects. At Wikimedia, some of these come from editors with technical skills; some come from other open communities who join through specific initiatives (i.e., GLAM datathon, Ionian Hackathon in 2022, Google-Code-In, etc.). How can we enable and amplify casual/drive-by or temporary contributions so that they add value to the ecosystem/for a specific tool as part of the pilot project?


 * [In scope for the pilot] What might enable casual/temporary contributions? How can a tool maintainer identify and unlock such contributions?
 * [Out of scope for the pilot] What type of project enables one-time participants of a hack event/initiative to contribute immediately? How do regular/temporary contributors intersect?
 * [Out of scope for the pilot] What type of projects should we not recommend for casual contributions? (i.e., build a tool, deploy it to Toolforge, and leave ;))
 * [Out of scope for the pilot] What does a path from casual to regular contributor look like? What hooks people in?

Note: For the pilot project, it's recommended to narrow the focus down to 1-2 types of casual/temporary contributions that might make a good fit to support tools and maintainers at risk.

Milestones & timeline

 * Improved tool data insights (engineering)
 * Q2 & Q3: Metric for up-to-dateness or resources used is computed
 * Q3 stretch: Up to 2 additional metrics needed by the community are available
 * Increased tool ecosystem insights (research)
 * What support mechanisms already exist for a tool and its developers (e.g., for monitoring a tool's activity and health, bot approval practices)?
 * What are things that tool developers would like to have support on (including, but not limited to, code)?
 * What support tool could users imagine providing to a tool they frequently use?
 * How - and in which fields - could casual/temporary contributions be effective and support a tool? What might enable such contributions?
 * Stretch: What kind of metrics tool developers or users would love to have about tools? (correlated to the stretch goal above)
 * Initiated (Q2)/strengthened (Q3) connections (outreach)
 * Q2: Connect with others working in this field or might be interested (WMSE + Sandra Founconnier, Open Refine group, Jean-Fred …) - explore if setting up a shared project page is something they'd be interested in.
 * Q2: Explore how to identify a tool/maintainer to run the pilot with - which Commons or Wikidata-related tool might be a good fit? Where do communities or maintainers see a critical need?
 * Q2/early Q3: Connect their needs/ideas to the research/work done in the team to prepare this project
 * Q3: Continue to work with identified partners
 * Q3: Develop and conduct the pilot together
 * Path from pilot to a set of practices
 * Q3/4: Evaluation, including distilling practices that are agnostic to specific technical areas
 * Q4: Define the next steps

Intended outcomes

 * Recommendations on three key practices that might help support contributors and tools at risk and a plan on how to implement these as part of the pilot
 * Metrics for up-to-dateness and resources used are computed
 * One pilot initiative completed jointly with maintainers/supporters of a high-impact/at-risk tool
 * Stretch: Up to 2 additional metrics needed by the community are available
 * Evaluation

Example implementation

 * The project team has identified the following:
 * user-facing docs
 * someone willing to serve as a backup for restarting the web service in case it’s down,
 * a group of people monitoring and triaging bug reports would help the tool maintainer.


 * Project team develops an outreach plan and supporting guidelines jointly with the maintainer and helps recruit the support group. This could include:
 * Landing page and call to action
 * Communication across multiple platforms and channels
 * Meet-the-maintainer-meeting with brainstorming & mix-match of interests, skills, and needs
 * a sprint with small tasks around this tool
 * Setting up a workboard
 * Tutorials for certain aspects