How Open Fotros Manages RFC-Driven Development
We adopted an RFC process for all breaking changes six months ago. Here's what worked, what didn't, and why it has made our releases more predictable.
Six months ago we introduced a formal RFC (Request for Comments) process for any change that would alter a public API, remove a feature, or change default behavior. Here's what we learned.
Why We Needed a Process
Before RFCs, breaking changes were often debated in GitHub issues that grew to hundreds of comments with no clear resolution. Decisions were made by whoever was loudest or most persistent, not necessarily whoever had the best technical argument.
"An RFC is a design document that provides information to the community, or describes a new feature, process, or environment change. The RFC process is intended to provide a consistent and controlled path for new features and breaking changes."
— Open Fotros RFC-0001