Rails Core AMA
summary
Ten core members answer how Rails actually evolves: features must solve general web problems, be validated in real apps or gems, and have a clean API before merging; start by contributing to the triage team, then issues, then committers, then core. Security reports go via HackerOne. Active Record is the trickiest code area; Active Record encryption already supports key rotation with reinc and old_keys. Release cadence is moving toward predictable timelines; submit PRs only after you’ve tried the change in your app and proven it works.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 2:38Matthew
- 3:47PostgreSQL or MySQL
- 5:36Stand Up
- 6:45How to join the Rails Core team
- 10:00How does Rails Core decide which features to abstract
- 13:04How do you balance 37 Signals and Green Field
- 14:19What criteria makes a feature worthy of joining the Rails Core team
- 16:53Key rotation in ActiveRecord encryption
- 20:01Future of Rails Core
- 22:41How does a team evaluate an idea
- 26:07How many lines of code does a core team have
- 27:20Who amongst the like is like in the last month
- 28:24How much pressure does David put on you
- 30:39Most crucial evolution of Rails in the next 5 years
- 33:09Ideas for making Rails more appealing to new developers
- 35:42Bringing new developers to the community
- 36:48Rails is dying
- 37:28Rapid Fire Questions
- 44:56Most Intimidating Areas
- 46:35Career
