joshuakgoldberg/rfcs

ESLint is a widely used tool that helps developers catch mistakes and enforce consistent coding style in JavaScript projects. The rfcs repository is where anyone can propose big, structural changes to how ESLint itself works, things like new command-line options, major refactors, or anything that would break existing behavior. Small fixes and documentation tweaks go through the normal pull request flow, but substantial changes need a more formal design discussion first. The process is straightforward but deliberate. You start by opening an issue in the relevant ESLint repository to gauge community interest. If there's enough support, you fork this repo, copy a template, and write up a detailed proposal describing what you want to change and why. You submit that as a pull request, which kicks off a two-phase review. First, there's an initial commenting period lasting 21 to 90 days where anyone can give feedback and the author refines the proposal. After that, the ESLint Technical Steering Committee (TSC) has a final seven-day window to approve or reject it. If the TSC reaches consensus, the RFC gets merged and the feature can move toward implementation. This matters because ESLint is used by a huge number of developers, and even small changes can have ripple effects. The RFC process exists to make sure significant shifts in direction are transparent and debated openly rather than quietly slipping in. Anyone from a casual contributor to a core maintainer can participate, you just need to care enough about a feature to write it up and respond to feedback. One notable aspect is that having an RFC accepted doesn't mean it gets built automatically. The original author is encouraged but not obligated to implement it, and anyone else can pick it up. The RFC then serves as a durable record of why a particular design decision was made, which is useful for future contributors trying to understand the reasoning behind existing behavior.