Rails core team panel
summary
Rails core members describe concrete contribution paths: use a failing app on master/edge to capture reproducible bugs, add minimal test cases, follow the Rails contributing guide, and focus on one method or area (ActiveRecord or ActionPack) rather than the whole codebase. They highlight the new system test framework as an opt‑in feature people like, name performance work (faster ActiveRecord) as quietly impactful, and argue removing Spring and Sprockets and trimming a 40‑minute test suite would improve contributor experience.
AI-written summary · about
chapters (14)
- 0:00Introduction and panelists
- 2:21Why contribute to open source
- 4:12How we started in open source
- 6:46Tips for new Rails contributors
- 9:56Finding bugs in Rails
- 10:21Hardest parts of maintaining Rails
- 12:51Handling rejected pull requests
- 13:55Managing time for open source
- 18:32Parts of Rails we work on
- 20:23Most impactful contributions
- 23:45What we’d remove from Rails
- 26:17Exciting Rails developments
- 28:48Frameworks we’d borrow from
- 32:19Languages we’re learning
