My Haskell will
I hate it when maintainers become unreachable. At the same time, I’m not immune to that myself (if nothing else, I could be hit by a bus tomorrow).
So I contacted a few people with a request to become backup maintainers (BM) for some of my more popular Haskell packages, and they kindly agreed.
- Oliver Charles is now BM for all my testing-related packages: tasty and its add-ons, smallcheck, obsolete test-framework add-ons, and ansi-terminal (a dependency of tasty)
- Adam Bergmark is now BM for the haskell-suite projects: haskell-names, haskell-packages, hse-cpp, and traverse-with-class (a dependency of haskell-names)
- Sjoerd Visscher is co-BM for traverse-with-class
- Oleksandr Manzyuk is now BM for ariadne and bert (a dependency of ariadne)
Being a backup maintainer comes with very light responsibilities:
- should I become unreachable (temporarily or permanently), and a change has to be made to a package to keep it usable, the BM is supposed to review, apply, and release that change.
- if I am unreachable for a long time or permanently, and there’s a person/people who want to take over maintenance/development of all or some of the packages, and the BM has no objections to them doing so, the BM is supposed to give them the necessary privileges. (Of course, that person may be the BM him/herself!)
The BM for a package is added as a maintainer of that package on hackage and as a collaborator for the package’s github repository.
To make it clear, there’s no obligation for the BM to fix bugs or continue the development after I disappear. It would be unreasonable to request a person to commit to such a responsibility at an indefinite point in the future.
I assume that if a project is important, there will be people willing to take care of it; and if it isn’t, then it doesn’t matter anyway. The main responsibility of the BM is thus to make it easy for such a hypothetical person to take over.
As to what it means to be «unreachable», I completely trust my BM’s judgement here. I don’t want them to follow any bureaucratic procedures. The risk of something going wrong is very low and easily outweighed by the benefits of timely response to problems.
One package that doesn’t have a BM yet is standalone-haddock. If you use it and would like to become a BM, please get in touch.
I also encourage other package maintainers to follow this example and appoint BMs for their popular packages.