{"id":15020771,"url":"https://github.com/electron/rfcs","last_synced_at":"2025-10-19T16:32:46.840Z","repository":{"id":222208761,"uuid":"710035518","full_name":"electron/rfcs","owner":"electron","description":null,"archived":false,"fork":false,"pushed_at":"2024-09-20T15:35:52.000Z","size":37,"stargazers_count":7,"open_issues_count":2,"forks_count":4,"subscribers_count":8,"default_branch":"main","last_synced_at":"2024-10-29T17:15:02.849Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/electron.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-10-25T22:02:49.000Z","updated_at":"2024-09-20T15:35:53.000Z","dependencies_parsed_at":"2024-05-28T01:46:10.504Z","dependency_job_id":"d4a0c2b7-596e-4555-aa09-0c1c06dcd2da","html_url":"https://github.com/electron/rfcs","commit_stats":{"total_commits":24,"total_committers":6,"mean_commits":4.0,"dds":"0.33333333333333337","last_synced_commit":"94ccffc1f285b1ff0fa301fa8796df2e9697c282"},"previous_names":["electron/rfcs"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/electron%2Frfcs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/electron%2Frfcs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/electron%2Frfcs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/electron%2Frfcs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/electron","download_url":"https://codeload.github.com/electron/rfcs/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":237172225,"owners_count":19266633,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-09-24T19:55:35.665Z","updated_at":"2025-10-19T16:32:46.835Z","avatar_url":"https://github.com/electron.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# RFCs for Electron\n\nIn Electron, the Request for Comments (RFC) process is designed to provide a consistent and\ncontrolled path for “substantial” proposals to be incorporated into future releases of Electron.\n\nMany changes to Electron can be directly introduced via pull requests to the\n`electron/electron` repository. However, some changes need additional process to ensure that\nstakeholders can achieve consensus on their benefits for the present and future of Electron.\n\nSuch “substantial” changes should be introduced via the RFC process.\n\n**The RFC process is open to anyone in the community.**\n\n## When to use this process\n\nThe RFC process is intended to be used to introduce “substantial” changes to the core Electron\nproject. This type of change may require a significant amount of coordination effort in the\ndesign process or be time-consuming enough to build that consensus should be found prior to feature\nimplementation.\n\nThe categorization of “substantial” changes is subjective and evolves with project norms,\nbut may include:\n\n- a new feature that requires a large amount of patches or new Chromium dependencies\n- a new module in Electron’s API surface\n- or a refactor of Electron’s core startup code\n\nHowever, more straightforward changes can be instead addressed directly with a PR. This type of\nchange includes:\n\n- updates to documentation\n- objective quality improvements (performance, platform support, better error handling, etc.)\n- refactors invisible to end-users\n- fixes for objectively incorrect behavior\n\nIf you submit a pull request to implement a new feature without going through the RFC process,\nit may be closed with a polite request to submit an RFC first.\n\n## Stages\n\nAn RFC can exist in six different stages:\n\n- **Proposed:** An RFC is Proposed if it has an open pull request with a spec document forked from\n  the RFC template. At this point, community feedback can be gathered to drive consensus on the spec.\n  Maintainers can approve and merge into the `rfcs` repo to move the RFC to the Active stage or close\n  the pull request to mark it as Declined.\n- **Pending Comment:** An RFC is Pending Comment if it has received approval from maintainers but has\n  yet to be merged. Proposed RFCs that are approved will be marked as Pending Comment for 2 weeks\n  before being merged and marked as Active if no blocking objections are made during this time.\n  If an objection during the final comment period blocks merging of the PR, the RFC status is moved\n  to Proposed until all feedback is addressed.\n- **Active:** An RFC is Active once it is merged into the `electron/rfcs` repository. An\n  implementation PR(s) can be opened in `electron/electron` as a technical reference.\n  **An Active RFC means that the idea is worth being implemented and explored, not that the\n  maintainers are committing to adding it to Electron.** If a new development causes an Active\n  RFC to become unnecessary in any way, maintainers can choose to ultimately decline it.\n- **Abandoned:** An RFC will be closed as Abandoned if it has no owner actively pushing it forward.\n  The original owner may reopen the PR, or a new owner may open a new PR if they are interested in pursuing it.\n  Maintainers will check interest in pursuing the RFC prior to labeling it abandoned and closing\n  the PR.\n- **Completed:** Once the implementation for an Active RFC is merged into Electron’s `main` branch\n  and is slated for an upcoming release, it is marked as Completed with a PR to `electron/rfcs`\n  containing the status change and a link to the `electron/electron` commit and target Electron release.\n- **Declined:** A Proposed RFC can be marked as Declined by maintainers after public discussion. When\n  a proposal is declined, a maintainer should add a comment summarizing the reasons for the decision\n  and close out the pull request.\n\n```mermaid\nflowchart TD\n  P[Proposed] --\u003e PC[Pending Comment];\n  PC --\u003e A[Active];\n  A --\u003e C[Completed];\n  PC --\u003e P;\n  P --\u003e D[Declined];\n  A --\u003e D;\n  P --\u003e AB[Abandoned];\n  AB --\u003e P;\n  style D fill:darkred;\n  style A fill:darkorange;\n  style C fill:darkgreen;\n  style PC fill:yellow;\n  style AB fill:gray;\n```\n\n## Process\n\n### Adding a new RFC proposal\n\n- **Fork** the `electron/rfcs` repo.\n- **Copy the template** markdown file (`0000-template.md`) into the `text` folder, and rename it\n  after your feature (e.g. `text/0000-my-cool-electron-feature.md`).\n- **Fill out the RFC template.** Put care into the details: RFCs that do not present convincing\n  motivation, demonstrate understanding of the impact of the design, or are disingenuous about the\n  drawbacks or alternatives tend to be poorly-received.\n- **Open a pull request.** Once the pull request is open, the RFC is considered Proposed and is\n  open to general feedback. RFC authors are expected to engage with this feedback to arrive at a\n  consensus with community stakeholders.\n- Eventually, Electron’s API WG will decide if the RFC is a candidate for inclusion in Electron.\n  The RFC should be reviewed by at least two WG members, and presented to a quorum of the group at a\n  synchronous meeting. If consensus is achieved, then the RFC will be a candidate for acceptance.\n- This will trigger a two-week final comment period for the RFC. Unless any issues come up that\n  the WG consider to block the implementation of the RFC, it will be merged and marked as Active.\n\n### Working on an Active RFC\n\n- Once the RFC is marked as Active, the author can open an implementation PR on `electron/electron`\n  and attach it to the RFC document in this repository.\n- If a tracking issue does not exist on `electron/electron`, it will also be created and attached\n  to the RFC document.\n- Modifications to active RFCs can be done in followup PRs. We strive to write each RFC in a manner\n  that it will reflect the final design of the feature; but the nature of the process means that we\n  cannot expect every merged RFC to actually reflect what the end result will be at the time of the\n  next major release; therefore we try to keep each RFC document somewhat in sync with the language\n  feature as planned, tracking such changes via followup pull requests to the document.\n- If the implementation PR gets merged into `electron/electron`, the RFC will be marked as Completed.\n\n### Details on Active RFCs\n\n- An Active RFC is not a guarantee that the feature will be approved and merged. Rather, it means that\n  Electron’s maintainer team has agreed to it in principle and is amenable to merging it.\n- Furthermore, the fact that a given RFC has been accepted and is 'active' implies nothing about what\n  priority is assigned to its implementation, nor whether anybody is currently working on it.\n\n## RFC review\n\n**Feedback on Proposed RFCs is open to the community**, although Electron’s API working group will make\nthe ultimate decision regarding their accepting or declining the proposed RFC. Depending on the nature of the proposal,\nadditional working groups in Electron Governance may be tagged to review the RFC as well.\n\nThe API WG cannot commit to a timeline for reviewing all RFC proposals, but will try to read each\nsubmission within a few weeks of submission.\n\n## Community vs maintainer RFCs\n\nElectron's RFC process is designed to open up substantial change contributions to Electron to all\ndevelopers in the community.\n\nHowever, Electron maintainers often design and build features internally outside of the\nRFC process. In this case, RFCs from maintainers may be published once feature experimentation is\nalready done and consensus for the feature is established among maintainers. They serve primarily as\na period of community feedback for things that the core team already intends to ship.\n\nWe apply the same level of rigour both to maintainer RFCs and RFCs from the community. The primary\ndifference between them is in the design phase: maintainer RFCs tend to be submitted at the end of\nthe design process whereas community RFCs tend to be submitted at the beginning as a way to\nkickstart it.\n\n## Credits\n\nElectron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas\nand bits of copywriting go to:\n\n- [emberjs/rfcs](https://github.com/emberjs/rfcs)\n- [reactjs/rfcs](https://github.com/reactjs/rfcs)\n- [rust-lang/rfcs](https://github.com/rust-lang/rfcs)\n- [tauri-apps/rfcs](https://github.com/tauri-apps/rfcs)\n- [vuejs/rfcs](https://github.com/vuejs/rfcs)\n- [yarnpkg/rfcs](https://github.com/yarnpkg/rfcs)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Felectron%2Frfcs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Felectron%2Frfcs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Felectron%2Frfcs/lists"}