Lines Matching refs:or
18 and linked to any relevant :ref:`bug or feature tracking issues<bug_reporting>`
22 submitting a change or an enhancement to any Zephyr component, a developer
35 or timezone. We have developers and contributors from across the globe. When
41 addressed with general reviews and do not need to be queued for a maintainer or
43 and a decision by the TSC or the Security working group. To summarize the above,
58 should belong to. A project maintainers or TSC member monitoring the inflow of
82 Trivial changes are those that appear obvious enough and do not require maintainer or code-owner
83 involvement. Such changes should not change the logic or the design of a
84 subsystem or component. For example a trivial change can be:
91 - Sample modifications to support additional configuration or boards etc.
96 Any changes that touch the logic or the original design of a subsystem or
97 component will need to be reviewed by the code owner or the designated subsystem
98 maintainer. If the code changes is initiated by a contributor or developer other
112 Changes that introduce new features or functionality or change the way the
113 overall system works need to be reviewed by the TSC or the responsible Working
143 Reviewers shall not 'Request Changes' without comments or justification
162 the request can merge without approving or approve and merge to get to the 2
168 If a reviewer has requested changes in a pull request, he or she should monitor
169 the state of the pull request and/or respond to mention requests to see if his
171 dismissed by the assignee or an owner of the repository. Reviews will be
174 - The feedback or concerns were visibly addressed by the author
177 - The review is unrelated to the code change or asking for unjustified
192 to questions and provide clarifications regarding the issue or the change.
255 All GitHub issues or pull requests must be appropriately labeled.
258 When reviewing a PR, if it has missing or incorrect labels, maintainers shall
261 This saves us all time when searching, reduces the chances of the PR or issue
276 - To classify the impact and importance of a bug or
279 Note: Issue priorities are generally set or changed during the bug-triage or TSC
308 *Feature*, *Feature Request* or *Hardware Support*. More information on how
315 The issue or PR describes a change to a stable API.
344 - The PR is a backport or should be backported.
367 :guilabel:`area: Documentation`, :guilabel:`area: Process`), or other categories (e.g.,
368 …:guilabel:`area: Coding Style`, :guilabel:`area: MISRA-C`) affected by the bug or the pull request.
374 - An issue or PR which affects only a particular platform.
389 - The issue or PR describes a breaking change to a stable API. See additional information
393 - The issue is a bug, or the PR is fixing a bug.
396 - A Coverity detected issue or its fix.
399 - The Zephyr developers are waiting for the submitter to respond to a question, or
403 - Blocked by another PR or issue.
406 - An issue or a PR which seems abandoned, and requires attention by the author.