1.. _rfcs: 2 3Proposals and RFCs 4################## 5 6Many changes, including bug fixes and documentation improvements can be 7implemented and reviewed via the normal GitHub pull request workflow. 8 9Many changes however are "substantial" and need to go through a 10design process and produce a consensus among the project stakeholders. 11 12The "RFC" (request for comments) process is intended to provide a consistent and 13controlled path for new features to enter the project. 14 15Contributors and project stakeholders should consider using this process if 16they intend to make "substantial" changes to Zephyr or its documentation. Some 17examples that would benefit from an RFC are: 18 19- A new feature that creates new API surface area, and would require a feature 20 flag if introduced. 21- The modification of an existing stable API. 22- The removal of features that already shipped as part of Zephyr. 23- The introduction of new idiomatic usage or conventions, even if they do not 24 include code changes to Zephyr itself. 25 26The RFC process is a great opportunity to get more eyeballs on proposals coming 27from contributors before it becomes a part of Zephyr. Quite often, even 28proposals that seem "obvious" can be significantly improved once a wider group 29of interested people have a chance to weigh in. 30 31The RFC process can also be helpful to encourage discussions about a proposed 32feature as it is being designed, and incorporate important constraints into the 33design while it's easier to change, before the design has been fully 34implemented. 35 36Some changes do not require an RFC: 37 38- Rephrasing, reorganizing or refactoring 39- Addition or removal of warnings 40- Addition of new boards, SoCs or drivers to existing subsystems 41- ... 42 43The process in itself consists in creating a GitHub issue with the :ref:`RFC 44label <gh_labels>` that documents the proposal thoroughly. There is an `RFC 45template`_ included in the main Zephyr GitHub repository that serves as a 46guideline to write a new RFC. 47 48As with Pull Requests, RFCs might require discussion in the context of one of 49the `Zephyr meetings`_ in order to move it forward in cases where there is 50either disagreement or not enough voiced opinions in order to proceed. Make sure 51to either label it appropriately or include it in the corresponding GitHub 52project in order for it to be examined during the next meeting. 53 54.. _`RFC template`: https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/003_rfc-proposal.md 55.. _`Zephyr meetings`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings 56