Lines Matching +full:feature +full:- +full:specific
1 .. _contributor-expectations:
10 - Reviewed more quickly and reviewed more thoroughly. It's easier for reviewers
14 - Less wasted work if reviewers or maintainers reject the direction of the
17 - Easier to rebase and merge. Smaller PRs are less likely to conflict with other
20 - Easier to revert if the PR breaks functionality.
32 - Smaller PRs should encompass one self-contained logical change.
34 - When adding a new large feature or API, the PR should address only one part of
35 the feature. In this case create an :ref:`RFC proposal <rfcs>` to describe the
36 additional parts of the feature for reviewers.
38 - PRs should include tests or samples under the following conditions:
40 - Adding new features or functionality.
42 - Modifying a feature, especially for API behavior contract changes.
44 - Fixing a hardware agnostic bug. The test should fail without the bug fixed
47 - PRs must update any documentation affected by a functional code change.
49 - If introducing a new API, the PR must include an example usage of the API.
62 the PR into multiple commits targeting these specific changes:
65 #. Update driver implementation X, with driver specific devicetree bindings
82 - Submitting a new feature.
83 - Submitting a new API.
84 - :ref:`treewide-changes`.
85 - Other large changes that can benefit from the RFC proposal process.
93 - Each commit in the PR must provide a commit message following the
94 :ref:`commit-guidelines`.
96 - The PR description must include a summary of the changes and their rationales.
98 - All files in the PR must comply with :ref:`Licensing
101 - Follow the Zephyr :ref:`coding_style` and :ref:`coding_guidelines`.
103 - PRs must pass all CI checks. This is a requirement to merge the PR.
107 - When breaking a PR into multiple commits, each commit must build cleanly. The
111 - When major new functionality is added, tests for the new functionality shall
118 - :zephyr_file:`Kernel timer tests <tests/kernel/timer/timer_behavior>`
121 - Emulators for off-chip peripherals are an effective way to test driver
127 - Code coverage reports for the Zephyr project are available on `Codecov`_.
129 - Incompatible changes to APIs must also update the release notes for the
133 - Changes to APIs must increment the API version number according to the API
136 - PRs must also satisfy all :ref:`merge_criteria` before a member of the release
142 .. _`Codecov`: https://app.codecov.io/gh/zephyrproject-rtos/zephyr
147 - Unless they applied the reviewer's recommendation exactly, authors must not
153 - Respond to comments using the "Start Review" and "Add Review" green buttons in
158 - As GitHub does not implement |git range-diff|_, try to minimize rebases in the
163 .. |git range-diff| replace:: ``git range-diff``
164 .. _`git range-diff`: https://git-scm.com/docs/git-range-diff
185 - After 1 week of inactivity, ping the Assignee or reviewers on the PR by adding
188 - After 2 weeks of inactivity, post a message on the `#pr-help`_ channel on
191 - After 2 weeks of inactivity, add the `dev-review`_ label to the PR. This
213 - Resolve in the PR among assignee, maintainers and reviewer.
215 - Assignee to act as moderator if applicable.
217 - Optionally resolve in the next `Zephyr Dev Meeting`_ meeting with more
220 - The involved parties and the Assignee to be present when the issue is
223 - If no progress is made, the assignee (maintainer) has the right to dismiss
240 - Escalate to the `Architecture Working Group`_ by adding the `Architecture
246 - If all avenues of resolution and escalation have failed, assignees can escalate
250 - The Assignee is expected to ensure the resolution of the escalation and the
253 .. _#pr-help: https://discord.com/channels/720317445772017664/997527108844798012
255 .. _dev-review: https://github.com/zephyrproject-rtos/zephyr/labels/dev-review
257 …ev Meeting: https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups#…
259 .. _Architecture Project: https://github.com/zephyrproject-rtos/zephyr/projects/18
261 …hitecture Working Group: https://github.com/zephyrproject-rtos/zephyr/wiki/Architecture-Working-Gr…
264 .. _reviewer-expectations:
269 - Be respectful when commenting on PRs. Refer to the Zephyr `Code of Conduct`_
272 - The Zephyr Project recognizes that reviewers and maintainers have limited
281 - Reviewers shall strive to advance the PR to a mergeable state with their
284 - Try to provide feedback on the entire PR in one shot. This provides the
287 - Partial reviews are permitted, but the reviewer must add a comment indicating
291 - Domain specific reviews (e.g. Devicetree).
292 - Code style changes that impact the readability of the PR.
293 - Reviewing commits separately when the requested changes cascade into the
296 - Avoid increasing scope of the PR by requesting new features, especially when
300 to work on a feature once the minimum implementation has merged.
302 - When using the "Request Changes" option, mark trivial, non-functional,
303 requests as "Non-blocking" in the comment. Reviewers should approve PRs once
304 only non-blocking changes remain. The PR author has discretion as to whether
305 they address all non-blocking comments. PR authors should acknowledge every
308 - Reviewers shall be *clear* and *concise* what changes they are requesting when the
313 - Reviewers shall not close a PR due to technical or structural disagreement.
318 .. _Code of Conduct: https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md
320 .. _Zephyr Release Plan: https://github.com/orgs/zephyrproject-rtos/projects/13