From 7ae2b5033ea12b55d416220dbc70f6a98727c0b6 Mon Sep 17 00:00:00 2001 From: Anas Nashif Date: Mon, 20 Jan 2025 09:28:54 -0500 Subject: [PATCH] doc: review: switch labels to a definition list Move labels docs from headers to a definition list. Signed-off-by: Anas Nashif --- doc/project/dev_env_and_tools.rst | 68 +++++++++++++------------------ 1 file changed, 29 insertions(+), 39 deletions(-) diff --git a/doc/project/dev_env_and_tools.rst b/doc/project/dev_env_and_tools.rst index 2095192d4d57..9485d1520506 100644 --- a/doc/project/dev_env_and_tools.rst +++ b/doc/project/dev_env_and_tools.rst @@ -65,55 +65,45 @@ Categories/Labels ----------------- Hotfix -++++++ + Any change that is a fix to an issue that blocks developers from doing their + daily work, for example CI breakage, Test breakage, Minor documentation fixes + that impact the user experience. -Any change that is a fix to an issue that blocks developers from doing their -daily work, for example CI breakage, Test breakage, Minor documentation fixes -that impact the user experience. - -Such fixes can be merged at any time after they have passed CI checks. Depending -on the fix, severity, and availability of someone to review them (other than the -author) they can be merged with justification without review by one of the -project owners. + Such fixes can be merged at any time after they have passed CI checks. Depending + on the fix, severity, and availability of someone to review them (other than the + author) they can be merged with justification without review by one of the + project owners. Trivial -+++++++ - -Trivial changes are those that appear obvious enough and do not require maintainer or code-owner -involvement. Such changes should not change the logic or the design of a -subsystem or component. For example a trivial change can be: + Trivial changes are those that appear obvious enough and do not require maintainer or code-owner + involvement. Such changes should not change the logic or the design of a + subsystem or component. For example a trivial change can be: -- Documentation changes -- Configuration changes -- Minor Build System tweaks -- Minor optimization to code logic without changing the logic -- Test changes and fixes -- Sample modifications to support additional configuration or boards etc. + - Documentation changes + - Configuration changes + - Minor Build System tweaks + - Minor optimization to code logic without changing the logic + - Test changes and fixes + - Sample modifications to support additional configuration or boards etc. Maintainer -+++++++++++ - -Any changes that touch the logic or the original design of a subsystem or -component will need to be reviewed by the code owner or the designated subsystem -maintainer. If the code changes is initiated by a contributor or developer other -than the owner the pull request needs to be assigned to the code owner who will -have to drive the pull request to a mergeable state by giving feedback to the -author and asking for more reviews from other developers. + Any changes that touch the logic or the original design of a subsystem or + component will need to be reviewed by the code owner or the designated subsystem + maintainer. If the code changes is initiated by a contributor or developer other + than the owner the pull request needs to be assigned to the code owner who will + have to drive the pull request to a mergeable state by giving feedback to the + author and asking for more reviews from other developers. Security -+++++++++++ - -Changes that appear to have an impact to the overall security of the system need -to be reviewed by a security expert from the security working group. + Changes that appear to have an impact to the overall security of the system need + to be reviewed by a security expert from the security working group. TSC and Working Groups -++++++++++++++++++++++ - -Changes that introduce new features or functionality or change the way the -overall system works need to be reviewed by the TSC or the responsible Working -Group. For example for :ref:`breaking API changes `, the -proposal needs to be presented in the Architecture meeting so that the relevant -stakeholders are made aware of the change. + Changes that introduce new features or functionality or change the way the + overall system works need to be reviewed by the TSC or the responsible Working + Group. For example for :ref:`breaking API changes `, the + proposal needs to be presented in the Architecture meeting so that the relevant + stakeholders are made aware of the change. A Pull-Request should have an Assignee =======================================