Community Tech/Maintenance Decision

Current Decision

Status: Done

Goal

As we as a team serve the community of technical contributors. Our focus is to implement features they would like to see. Some of our time we can spent on maintenance, that time is limited. That’s why we are discussing here to find ways to find most needed tools to maintain, so we can decide which ones we can offer to other teams or the community to maintain. The desired outcome of this conversation is not to find a list of projects we really care about as a team, although that’s very important. The goal is to think of metrics to measure which tools are important/popular and we depend on them. These metrics will be imperfect and that’s ok, but we’ll still try, we could add our findings to the maintenance table and make it transparent so people can comment on it.

Context

We do want to provide maintenance for our work, but want more structure for how we provide it. Maintenance has a high cost for us that is not transparent to the community. As it is unlikely that we can completely handover maintenance of the tools we build to volunteers we need to find a way that is sustainable for us. Though some of the problems that some of our tools might fix might not exist in the same way anymore, so regular review is required. A current risk is that finding maintainers of our work might be tricky, but that should not mean that we keep saying yes to work that we can not handle. We might not be able to just vote which projects to focus on but can decide on an approach together that allows us to decide. These are some thoughts of people on the team:

potentially if you can’t maintain a project you shouldn’t have build it in the first place
we could be consulted but can’t maintain all of our work forever
we feel responsible for our work so we want to find a way that keeps us accountable towards the community
we keep losing focus by all new request coming in

Updates

6th June 2022

During prioritization stage we are considering maintenance
If we can estimate that a feature will require an immense amount of maintenance we might have reduce the prioritization score, as we might not be capable of keeping all functionalities intact in the future
We will consult with other teams about implementation details
Our hope is that it makes it more likely that other teams continue maintaining our work, if we implement it in a way that matches the expectations of other teams for example regarding code style or standards
We will agree about how long we will maintain future wishes as a team
We will work hard on finding maintainers for our work and make it clear who continues maintaining our work, it can be teams or any interested members of the community. We do not maintain all tools we have implemented forever by default as we are not able to handle the load of bug requests. We want to be honest with ourselves about what we can achieve. A default maintenance time will be between 6–12 months
We encourage to resubmit wishes or propose maintenance requests.
We will make transparent what the maintenance status is
Besides active and passive maintenance, there is also "Unmaintained by CommTech”

14th June 2022

some tools have a high number of dependencies, we consider we need to keep maintaining them in any case, because that’s a sign of their importance
number of issues reported and patches committed are not sufficient as a metric, but still interesting to look at so I would suggest we still track them where available
if we can not maintain a tool within our work hours that means it’s not maintained by CommTech, this is important to show in our table as this can show volunteers there’s help needed, that doesn’t mean a project is abandoned, a tool getting abandoned means we couldn’t find another team to take care of a project and no volunteer volunteered
this kind of review is required on a regular basis, maybe once a year, I would suggest 6 months away from grand undertaking
if we want to maintain work we should be able to proof why should we keep maintaining this with some data

Options

Caption
Option	Collective thoughts	Votes
Analyse the number of incoming tickets in the last year?	this shows us which tools have the least bugs, as they're probably some of the best candidates to consider handing over a low number of tickets means a low maintenance burden high number of tickets might mean that project is more popular and therefore gets more attention and bugs not all tickets are necessarily our responsibility as some projects are worked on by other communities .i.e. TemplateWizard and CodeMirror more tickets will naturally be created while a project is actively being worked on if we don't maintain a project, the number of new tickets will possibly decrease but it doesn't mean there are fewer bugs
Analyse number of patches in the last year?	maybe worth working backwards from the oldest tool, and only consider supporting it if there have been active tasks/work/requests in the last 6 months? actual contributions seem to be a good way to track if a tool is to be maintained components within MediaWiki don't have their own repo and it might be tricky to track
Check for dependencies, what other projects depend on our work?	some projects have an API and we would like to be able to track this indirect usage as well
Check Maintenance duration alone?	this seems to make sense for new projects
Keep all current projects and apply new maintenance approach only for new projects?	if we would keep the number of existing projects we wouldn’t be able to add new ones and we are currently implementing various new ones would we be providing poor support by dropping certain projects this is only possible we can argument for the need to maintain them driven by data it is unreasonable to think that our team will be forever responsible for the things we've built authorship shouldn't be the only criteria for keeping things in our radar
Combined Tracking, check tickets when available, usage for some, patches and commits for some?	the tricky part of these metrics is that they are hardly comparable and not all metrics are available for all projects, so a mix of metrics might make sense
Find a way to measure maintenance burden and stability of our projects using existing data?	we still need to research this
Measure usage, and only maintain if the project is actively used	can be difficult for projects (e.g. CopyPatrol) that are used by few people but have big impact maybe most useful when comparing similar projects (e.g. IA Upload and SVG Translate can both be measured by looking at their numbers of uploads)
Other	feel free to describe something else you came up with

Further Inspiration

How does Wikimedia Deutschland's wishlist maintain their work?
How do other teams at the foundation handle maintenance? i.e. Growth team: https://phabricator.wikimedia.org/project/profile/1114/ and Language team: https://phabricator.wikimedia.org/project/profile/18/

Additional Questions

Can we stop maintaining things that are deployed to production if we find maintainers?
Would it make sense to let data decide what a stable project means so we can keep maintaining it as maintenance burden is low?
Should we consider adjusting our requirements for proposals to attract more work that we can surely maintain? It seems like Wikimedia Deutschland, who inspire our Wishlist does that? i.e. no extensions or only Mediawiki

Data Tracking Solutions

Learnings for our Future Dev Process

create tickets and tag correctly for all work we take in
what we maintain as volunteers shouldn't be in the list of our maintained projects