Lightweight RFC Process

Technical leaders in Apache Geode have struggled with slow consensus on design decisions, causing delays and friction. This guide introduces a lightweight RFC process that formalizes how proposals are submitted, discussed, and approved, giving teams a clear path from idea to implementation. The core insight is that a minimal, well-defined workflow can accelerate agreement without adding unnecessary bureaucracy.

The process defines six lifecycle states-Draft, Discussion, Development, Active, Dropped, and Superseded-each with explicit actions. Authors create a wiki page, send a [DISCUSS] email to the dev list, and set a deadline (typically one to three weeks). Comments must be addressed by the deadline, and once the deadline passes the RFC moves to Development and then Active once work is complete. If a proposal is abandoned or replaced, it is marked Dropped or Superseded and moved to an Icebox grouping. The body of an approved RFC is immutable; any later changes are captured in an Errata section to preserve the original decision record.

By making the review timeline explicit, separating technical content from formatting concerns, and treating the RFC as a living contract rather than a mutable draft, teams can make faster, more predictable decisions. The process is voluntary, so small changes can still go straight to a pull request, while larger, impactful changes benefit from early community feedback. This structure reduces endless debate, clarifies expectations, and keeps the project's design evolution transparent and accountable.