RIOT-OS/RIOT
RIOT-OS/RIOT
1
0
Fork 0
mirror of https://github.com/RIOT-OS/RIOT.git synced 2024-12-29 04:50:03 +01:00
Code Releases Activity

MAINTAINING.md: minor text improvements

Browse Source
This commit is contained in:
jasdeepgill 2019-11-25 15:21:53 -08:00 committed by Alexandre Abadie
parent 353c0e91d0
commit 0b4d463d19
No known key found for this signature in database
GPG Key ID: 1C919A403CAE1405
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
MAINTAINING.md
View File

@ -1,11 +1,11 @@
# RIOT Maintainer Guidelines
This list presents a series of guidelines for maintainers, including technical
and non-technical. The list is not exhaustive, and represents a baseline on
This list presents a series of technical and non-technical guidelines for maintainers.
The list is not exhaustive, it represents a baseline on
things that should be ensured for contributions.
Notes:
- Any of the items in this list might be skipped, if clearly and logically
- Any of the items in this list can be skipped, if clearly and logically
articulated reasons are presented.
- The order of the steps is meant to maximize efficiency and minimize
overhead, with the philosophy that failing in step n makes steps n+x
@ -14,9 +14,9 @@ Notes:
state (for example, due to poor code cleanliness or overall design), it
might be more efficient to give the contributor some broader comments for
improvement before further review.
- This is a working document and any changes, additions, or other discussions
- This is a working document: any changes, additions, or other discussions
are encouraged, via PRs raised against the document. Changes to this
document should however have at least two ACKs, to ensure these guidelines
document should have at least two ACKs, to ensure these guidelines
are well thought out, and that they reflect community consensus.
The [list of maintainers] gives information on the current maintainers and the
@ -54,7 +54,7 @@ the overall validity of the PR.
### 2. - Review the design of the code
The following list is not exhaustive and addresses the coding issues we have
The following list is not exhaustive, it addresses the coding issues we have
regularly seen in the past. In particular, check that the [Best Practices]
are followed. These checks can be aided (but not replaced) by a tool such as
Coccinelle, using the script found in dist/tools/coccinelle.
@ -116,7 +116,7 @@ complete that no input from the original developer or maintainer is required.
means we are investing in our community.
- Be friendly. Respect the original author, bearing in mind that their coding
style or their design may be just as valid as the way you would have done
it. And of course, always follow the [Code of Conduct].
it and of course, always follow the [Code of Conduct].
### Organisation of reviewing between maintainers
@ -130,14 +130,14 @@ Rather, give your verbal ACK and describe what you reviewed. In addition, if you
processed or reasonably stepped over a whole section, mark the PR with the
according label from the "Reviewed:" category. If you set a label by stepping
over a section, please articulate your reasoning for this clearly, as noted in
the [introduction](#introduction). This will help other maintainers help to
the [introduction](#introduction). This will help other maintainers to
better understand your line of thought. If you disagree with the assessment of
a previous review, you may remove a certain "Reviewed:" label. Please state your
reasoning in this case as well.
When all "Reviewed:" labels are set you may give your approval for the PR.
As everything in this document this is a "CAN", not a "MUST": It might help
As for everything in this document this is a "CAN", not a "MUST": It might help
other maintainers to track your work, but if the overhead isn't justified, a
simple approving ACK might suffice.