Community Tech/Maintenance Decision
Current Decision
[edit]Goal
[edit]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
[edit]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
[edit]6th June 2022
[edit]- 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
[edit]- 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
[edit]Further Inspiration
[edit]- 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
[edit]- 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
[edit]- https://phabricator.wikimedia.org/maniphest/report/project/?project=PHID-PROJ-kws2wih774dwaclxs2qy&window=12%20AM%207%20days%20ago&order=-oldest-all
- https://wikimedia.biterg.io (Docs: https://www.mediawiki.org/wiki/Community_metrics)
- https://toolviews.toolforge.org/api/
Learnings for our Future Dev Process
[edit]- 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