OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity

doc: dev_process: Add description about GH labels usage 

There has been some confusion about how GitHub labels
should be used.
This commit adds a new doc page, which tries to clarify this.

Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
This commit is contained in:
Alberto Escolar Piedras 2019-03-30 14:43:41 +01:00 committed by Anas Nashif
parent 1923a04ff0
commit ee194c375a
4 changed files with 146 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

140
doc/development_process/gh_labels.rst Normal file
View File

@ -0,0 +1,140 @@
.. _gh_labels:
Labeling issues and pull requests in GitHub
###########################################
The project uses GitHub issues and pull requests (PRs) to track and manage
daily and long-term work and contributions to the Zephyr project. We use
GitHub **labels** to classify and organize these issues and PRs by area, type,
priority, and more, making it easier to find and report on relevant items.
All GitHub issues or pull requests must be appropriately labeled.
Issues and PRs often have multiple labels assigned,
to help classify them in the different available categories.
When reviewing a PR, if it has missing or incorrect labels, maintainers shall
fix it.
This saves us all time when searching, reduces the chances of the PR or issue
being forgotten, speeds up reviewing, avoids duplicate issue reports, etc.
These are the labels we currently have, grouped by type:
Area:
*****
============= ===============================================================
Labels ``Area:*``
Applicable to PRs and issues
Description Indicates subsystems (e.g., Kernel, I2C, Memory Management),
project functions (e.g., Debugging, Documentation, Process),
or other categories (e.g., Coding Style, MISRA-C) affected by
the bug or pull request.
============= ===============================================================
An area maintainer should be able to filter by an area label and
find all issues and PRs which relate to that area.
Platform
*********
============= ===============================================================
Labels ``Platform:*``
Applicable to PRs and issues
Description An issue or PR which affects only a particular platform
============= ===============================================================
To be discussed in a meeting
****************************
============= ===============================================================
Labels ``API``, ``dev-review``, ``TSC``
Applicable to PRs and issues
Description The issue is to be discussed in the following
`API/dev-review/TSC meeting`_ if time permits
============= ===============================================================
.. _`API/dev-review/TSC meeting`: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Group-Meetings
Minimum PR review time
**********************
============= ===============================================================
Labels ``Hot Fix``, ``Trivial``, ``Maintainer``,
``Security Review``, ``TSC``
Applicable to PRs only
Description Depending on the PR complexity, an indication of how long a merge
should be held to ensure proper review. See
:ref:`review process <review_time>`
============= ===============================================================
Issue priority labels
*********************
============= ===============================================================
Labels ``priority:{high|medium|low}``
Applicable to Issues only
Description To classify the impact and importance of a bug or feature
============= ===============================================================
Note: Issue priorities are generally set or changed during the bug-triage or TSC
meetings.
Miscellaneous labels
********************
For both PRs and issues
=======================
+------------------------+-----------------------------------------------------+
|``Bug`` | The issue is a bug, or the PR is fixing a bug |
+------------------------+-----------------------------------------------------+
|``Coverity`` | A Coverity detected issue or its fix |
+------------------------+-----------------------------------------------------+
|``Waiting for response``| The Zephyr developers are waiting for the submitter |
| | to respond to a question, or address an issue. |
+------------------------+-----------------------------------------------------+
|``Blocked`` | Blocked by another PR or issue |
+------------------------+-----------------------------------------------------+
|``In progress`` | For PRs: is work in progress and should not be |
| | merged yet. For issues: Is being worked on |
+------------------------+-----------------------------------------------------+
|``RFC`` | The author would like input from the community. For |
| | a PR it should be considered a draft |
+------------------------+-----------------------------------------------------+
|``LTS`` | Long term release branch related |
+------------------------+-----------------------------------------------------+
|``EXT`` | Related to an external component (in ``ext/``) |
+------------------------+-----------------------------------------------------+
PR only labels
==============
================ ===============================================================
``DNM`` This PR should not be merged (Do Not Merge).
For work in progress, GitHub "draft" PRs are preferred
``Stale PR`` PR which seems abandoned, and requires attention by the author
``Needs review`` The PR needs attention from the maintainers
``Backport`` The PR is a backport or should be backported
``Licensing`` The PR has licensing issues which require a licensing expert to
review it
================ ===============================================================
Issue only labels
=================
==================== ===========================================================
``Regression`` Something, which was working, but does not anymore
(bug subtype)
``Question`` This issue is a question to the Zephyr developers
``Enhancement`` Changes/Updates/Additions to existing features
``Feature request`` A request for a new feature
``Feature`` A planned feature with a milestone
``Duplicate`` This issue is a duplicate of another issue
(please specify)
``Good first issue`` Good for a first time contributor to take
``Release Notes`` Issues that need to be mentioned in release notes as known
issues with additional information
==================== ===========================================================
Any issue must be clasified and labeled as either ``Bug``, ``Question``,
``Enhancement``, ``Feature``, or ``Feature Request``.

1
doc/development_process/index.rst
View File

@ -15,6 +15,7 @@ Development Model
api_lifecycle
communication
documentation
gh_labels
Terminology
***********

1
doc/development_process/issues.rst
View File

@ -1,4 +1,3 @@
.. _bug_reporting:
Bug Reporting

5
doc/development_process/review_process.rst
View File

@ -14,6 +14,10 @@ GitHub is used to support the standard open source practice of submitting
patches, which are then reviewed by the project members before being applied to
the code base.
Pull requests should be appropriately :ref:`labeled<gh_labels>`,
and linked to any relevant :ref:`bug or feature tracking issues<bug_reporting>`
.
The Zephyr project uses GitHub for code reviews and Git tree management. When
submitting a change or an enhancement to any Zephyr component, a developer
should use GitHub. GitHub automatically assigns a responsible reviewer on a
@ -21,6 +25,7 @@ component basis, as defined in the :zephyr_file:`CODEOWNERS` file stored with th
tree in the Zephyr project repository. A limited set of release managers are
allowed to merge a pull request into the master branch once reviews are complete.
.. _review_time:
Give reviewers time to review before code merge
================================================