Plain-English Explanation: Electron RFCs

This repository is a formal process for proposing and discussing big changes to Electron, which is a framework for building desktop applications. Think of it as a structured way to say "here's a feature I think Electron needs" before anyone writes the actual code.

The core idea is simple: some changes to Electron are too big or important to just submit as code and hope for approval. For example, adding a whole new API module, overhauling how the app starts up, or bringing in major new dependencies need buy-in from the community and maintainers first. Straightforward improvements like bug fixes, documentation updates, or performance tweaks can skip this process and go straight to a code pull request. But substantial changes get a dedicated RFC (Request for Comments) to work through the design and get consensus.

The process has six stages. You start by forking this repository, filling out a template document that explains what you want to build and why, and opening a pull request. This marks your proposal as "Proposed" and opens it up for feedback. If the Electron maintainers think it's worth pursuing, it enters a two-week final comment period called "Pending Comment." After that, if no blockers come up, it gets merged and marked "Active," meaning the team agrees the idea is worth exploring and you can start writing the actual implementation code. Eventually, once your code is merged into Electron itself, the RFC is marked "Completed." Along the way, proposals can also be "Declined" if there's no consensus, or "Abandoned" if the owner stops pushing it forward.

Anyone in the community can submit an RFC—it's not just for Electron's core team. However, Electron maintainers sometimes do publish RFCs after they've already experimented with a feature internally and decided to ship it. The difference is mainly timing: community RFCs are often submitted early in the design phase to gather feedback, while maintainer RFCs come later when the direction is already clear.

The README doesn't specify exact timelines for how long the whole process takes, only that maintainers aim to review submissions within a few weeks. The key takeaway is that this isn't a rubber-stamp process—marking an RFC as "Active" means the team thinks it's worth building, but doesn't guarantee it will ship or that it's anyone's current priority.