doc/contribute/proposals_and_rfcs.rst - third_party/github/zephyrproject-rtos/zephyr - Git at Google

 .. _rfcs:

 Proposals and RFCs
 ##################

 Many changes, including bug fixes and documentation improvements can be
 implemented and reviewed via the normal GitHub pull request workflow.

 Many changes however are "substantial" and need to go through a
 design process and produce a consensus among the project stakeholders.

 The "RFC" (request for comments) process is intended to provide a consistent and
 controlled path for new features to enter the project.

 Contributors and project stakeholders should consider using this process if
 they intend to make "substantial" changes to Zephyr or its documentation. Some
 examples that would benefit from an RFC are:

 - A new feature that creates new API surface area, and would require a feature
   flag if introduced.
 - The modification of an existing stable API.
 - The removal of features that already shipped as part of Zephyr.
 - The introduction of new idiomatic usage or conventions, even if they do not
   include code changes to Zephyr itself.

 The RFC process is a great opportunity to get more eyeballs on proposals coming
 from contributors before it becomes a part of Zephyr. Quite often, even
 proposals that seem "obvious" can be significantly improved once a wider group
 of interested people have a chance to weigh in.

 The RFC process can also be helpful to encourage discussions about a proposed
 feature as it is being designed, and incorporate important constraints into the
 design while it's easier to change, before the design has been fully
 implemented.

 Some changes do not require an RFC:

 - Rephrasing, reorganizing or refactoring
 - Addition or removal of warnings
 - Addition of new boards, SoCs or drivers to existing subsystems
 - ...

 The process in itself consists in creating a GitHub issue with the :ref:`RFC
 label <gh_labels>` that documents the proposal thoroughly. There is an `RFC
 template`_ included in the main Zephyr GitHub repository that serves as a
 guideline to write a new RFC.

 As with Pull Requests, RFCs might require discussion in the context of one of
 the `Zephyr meetings`_ in order to move it forward in cases where there is
 either disagreement or not enough voiced opinions in order to proceed. Make sure
 to either label it appropriately or include it in the corresponding GitHub
 project in order for it to be examined during the next meeting.

 .. _`RFC template`: https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/003_rfc-proposal.md
 .. _`Zephyr meetings`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups
	.. _rfcs:

	Proposals and RFCs
	##################

	Many changes, including bug fixes and documentation improvements can be
	implemented and reviewed via the normal GitHub pull request workflow.

	Many changes however are "substantial" and need to go through a
	design process and produce a consensus among the project stakeholders.

	The "RFC" (request for comments) process is intended to provide a consistent and
	controlled path for new features to enter the project.

	Contributors and project stakeholders should consider using this process if
	they intend to make "substantial" changes to Zephyr or its documentation. Some
	examples that would benefit from an RFC are:

	- A new feature that creates new API surface area, and would require a feature
	flag if introduced.
	- The modification of an existing stable API.
	- The removal of features that already shipped as part of Zephyr.
	- The introduction of new idiomatic usage or conventions, even if they do not
	include code changes to Zephyr itself.

	The RFC process is a great opportunity to get more eyeballs on proposals coming
	from contributors before it becomes a part of Zephyr. Quite often, even
	proposals that seem "obvious" can be significantly improved once a wider group
	of interested people have a chance to weigh in.

	The RFC process can also be helpful to encourage discussions about a proposed
	feature as it is being designed, and incorporate important constraints into the
	design while it's easier to change, before the design has been fully
	implemented.

	Some changes do not require an RFC:

	- Rephrasing, reorganizing or refactoring
	- Addition or removal of warnings
	- Addition of new boards, SoCs or drivers to existing subsystems
	- ...

	The process in itself consists in creating a GitHub issue with the :ref:`RFC
	label <gh_labels>` that documents the proposal thoroughly. There is an `RFC
	template`_ included in the main Zephyr GitHub repository that serves as a
	guideline to write a new RFC.

	As with Pull Requests, RFCs might require discussion in the context of one of
	the `Zephyr meetings`_ in order to move it forward in cases where there is
	either disagreement or not enough voiced opinions in order to proceed. Make sure
	to either label it appropriately or include it in the corresponding GitHub
	project in order for it to be examined during the next meeting.

	.. _`RFC template`: https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/003_rfc-proposal.md
	.. _`Zephyr meetings`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups