Lessons from maintaining Mocha, an open source project
summary
Maintaining Mocha involves ~2–3 GitHub notifications per day, many issues that take 20–30 minutes or more each to reproduce, and a core team of about ten volunteers juggling jobs. Concrete tools and changes include requiring MCVE repros, using Probot to auto-lock stale threads, and adding then reverting a bail option. One merged PR around this complexity takes ~10–11 months, reviewers often request labeled context, and decisions hinge on compatibility with Node LTS and ecosystem constraints.
AI-written summary · about
chapters (14)
- 0:00Maintaining Mocha introduction
- 1:14Becoming a Mocha maintainer
- 3:50Open source community maintenance
- 6:21Daily maintainer workload
- 9:38Handling issues and PRs
- 12:10Avoiding maintainer burnout
- 14:17Open source obligations
- 16:03Contributing within limits
- 17:46Open source competition
- 18:49Language barriers in maintenance
- 20:13Locking old issues
- 21:41Mocha prioritization
- 23:25Roadmap and Node.js LTS
- 24:51Final thoughts
related talks
44mWhat its like to be a full time open source maintainer
31mMaintaining a big open source project: lessons learned
56mMeet the Maintainers BoF
31mMaintain Less, Mentor More: Community Building Techniques from Open Source
39mMaintaining a big open source project: lessons learned
20mManaging In The Open, Managing Contributions: The challenges of OSPO developers management
27mManaging A Healthy GitHub Community
30mOut of Maintenance Mode: Refactoring a Community