Maintaining a big open source project: lessons learned

on YouTube ↗39m

" summary

Takes a dormant Ruby gem Devise from ~150 open issues and 51 PRs down to a much smaller backlog by focusing on issue triage (ask for reproducible apps/tests, close no-response issues after two weeks), systematic PR review (require tests, run changes against real apps), debugging with pry and git bisect, and automation like issue templates and stale bot to reduce noise. Emphasizes documenting rationale in commit messages, conservative API changes, and asking for help when unsure.

AI-written summary · about

" chapters (44)

1. 0:00Start
2. 2:42YOU'RE GOOD ENOUGH
3. 2:55WHERE DO I START?
4. 3:44The process of examining problems in order to decide which ones are the most serious and must be dealt with first
5. 3:55Ensure that issues follow the recommendations from the project's contribution guide
6. 4:58Include a title and a clear description, as much relevant information as possible and either a test case or a sample Rails app that replicates the issue -Devise's contribution guide
7. 5:17IT'S HARD TO FIX BUGS WITHOUT ENOUGH INFORMATION
8. 5:36TRY TO REPRODUCE THE ISSUE IN ISOLATION
9. 7:47WHY CLOSE THE ISSUE?
10. 8:25EVERY OPEN ISSUE IS A WORKING IN PROGRESS
11. 8:59IT'S IMPORTANT TO ASK QUESTIONS
12. 10:26IT'S HARD TO ASK QUESTIONS
13. 11:52ISSUE TRIAGE IS A GREAT WAY TO START
14. 13:4415 MINUTES PER DAY
15. 14:04BUT I'M NOT A MAINTAINER!
16. 14:34THERE ARE OTHER WAYS TO START
17. 14:46ASK FOR TESTS
18. 15:18REPRODUCE AN ISSUE
19. 16:11OPEN SOURCE IS MORE THAN CODE
20. 16:56REGRESSION
21. 17:27UNKNOWN ISSUES
22. 17:51DIVE INTO THE CODE
23. 19:11YOU FOUND THE CODE THAT'S CAUSING THE ISSUE
24. 19:43WHAT WERE THEY THINKING?
25. 20:06trackable
26. 21:25WE HAVE A LIMITED VISION OF THE WORLD
27. 22:42ASK FOR ADVICE
28. 24:02#2. IT'S OK TO MAKE MISTAKES
29. 24:24WHAT SHOULD I HAVE DONE?
30. 25:25DOCUMENT THE DECISIONS
31. 26:08GIT COMMIT MESSAGES
32. 27:06CODE IS EXPENSIVE
33. 27:22DEPRECATION CYCLES
34. 27:41IS IT REUSABLE FOR OTHER APPLICATIONS?
35. 27:57IS IT FLEXIBLE?
36. 28:13BE NICE
37. 29:20RESPECT OTHER OPINIONS
38. 29:59HAVE EMPATHY
39. 31:29GIVE IT A DAY
40. 32:42#6. TAKE CARE OF YOURSELF
41. 33:03RELY ON AUTOMATED TOOLS
42. 34:14ASK FOR HELP
43. 35:36SHOW YOUR COMPANY WHY OSS IS IMPORTANT
44. 37:09YOU DON'T NEED TO CODE TO HELP

" related talks

• 31mMaintaining a big open source project: lessons learnedLeonardo Tegon · RailsConf 2019
• 26mFrom 9-to-5 to Pull Requests: Sustainable Open Source ContributionJoshua Young · RubyConf TH 2026
• 37mOpen Source MaintenanceEric Hodel · Ruby on Ales 2014
• 35mTending Your Open Source GardenBrandon Keepers · Red Dot Ruby Conference 2014
• 23mScaling Open Source CommunitiesFelix Krause · try! Swift Tokyo 2017
• 27mWhy I'm Closing Your GitHub IssueHenning Koch · RailsConf 2021
• 29mTaking over Someone Else's Open-Source ProjectsDaniel Doubrovkine · GoGaRuCo 2014
• 30mFrom no OSS experience to the core team in 15 minutes a dayAndre Arko · RubyConf 2016