Hi,
Voting again (my previous e-mail was discarded in the voting process):
1. Contributing Guidelines with hints for Reviewers.
> We are adding additional section for Reviewers to Contributing
> Guidelines in order to provide checklist and complementary set of
> rules that should filter out breaking code as much as possible also on
> our side.
+1 Tomek
+1 Alin
+1 Tiago
2. PR and GIT COMMITS must adhere to Contributing Guidelines or rejected.
> Each PR and GIT COMMIT **must** adhere to requirements presented in
> Contributing Guidelines or will be auto-rejected until fixed /
> updated. Both code authors and reviewers/committers must follow the
> rules. Special cases are defined in a separate dedicated rules.
+1 Tomek
+1 Alin
+1 Tiago
3. Git commit messages as important as PR description.
> Git commit messages are as important as PR descriptions. These
> provide in-code descriptions of each change and are git interface
> independent.
+1 Tomek
+1 Alin
+1 Tiago
4. Proper description details requirements.
> Proper description of change is mandatory. Description must contain
> explanation on what proposed change do, why it is necessary, what if
> fixes, and how things are changed / fixed / updated, what is the
> impact (build / runtime / api / what area), how it was tested. Local
> code build and real world hardware runtime test logs must be provided
> (for code related changes). Description can be single..several
> sentences long or bullet points but enough for anyone to understand
> change goals and details. Usually it will look similar for PR and git
> commit message.
+1 Tomek ( However I understand this PR template is separate from the rule
and will be updated / voted independently.)
+1 Alin
+1 Tiago
6. Git commit message must adhere to description requirements.
> Proper GIT COMMIT message according to template is mandatory, or
> change is rejected until fixed / updates. Build and runtime logs are
> optional here if these are too long and already provided in PR.
Git commit message consists of:
1. Topic with functional name prefix, ":" mark, and short
> self-explanatory context.
> 2. Blank line
> 3. Description on what is changed, how, and why. May use several
> lines, short sentences, or bullet points.
> 4. Blank line.
> 5. Signature (created with `git commit -s`).
> GIT COMMIT TEMPLATE / EXAMPLE:
> net/can: Add g_ prefix to can_dlc_to_len and len_to_can_dlc.
> Add g_ prefix to can_dlc_to_len and len_to_can_dlc to
> follow NuttX coding style conventions for global symbols,
> improving code readability and maintainability.
> * you can also use bullet points.
> * to note different thing briefly.
+1 Tomek
+1 Alin
+1 Tiago
7. Git commit message mandatory fields (topic, desctiption, signature).
> Each git commit message must consist of topic, description, and
> signature (git commit -s), as presented in GIT COMMIT TEMPLATE, which
> are mandatory, or change is auto-rejected until fixed / updated.
+1 Tomek
+1 Alin
+1 Tiago
8. Changes must come with documentation.
> Changes must come with with documentation update where applicable. For
> maintenance reasons code and documentation should be split into two
> separate PR with the same name marked [1/2 CODE] for code and [2/2
> DOC] for documentation. If change presents new functionality a
> documentation must be provided along with the code (not in future). If
> change requires documentation update it must be contained along with
> the code (not in future). Successful documentation build log shortcut
> is welcome.
> See: https://github.com/apache/nuttx/blob/master/INVIOLABLES.md
0: Tomek (Having documentation in a single PR (same pr separate commit) is
easier to perform and review, otherwise we may get out of code/doc
sync? But if this is the only way and better for release manager then
okay.)
0 Alin (Having documentation in a single PR (same pr separate commit) is
easier to perform and review. The release process can use it)
0 Tiago. Yes, documentation should be provided, but I don't see any reason
for
splitting it into two different PRs. We keep our documentation in the same
repository and - for the sake of traceability - it should be updated in the
same PR (separate commit, not PR). We should make reviewers' and committers
lives easier. Alternative writing would be:
"*Changes must come with a documentation update where applicable. For*
*maintenance reasons, code and documentation should be split into two*
*commits in the same PR. If change presents new functionality,
documentation*
*must be provided along with the code (not in the future). If change*
*requires a documentation update it must be contained along with the code*
*(not in the future).*"
9. Zero trust approach to user testing.
> We implement zero trust approach to user provided testing. It is the
> commit author duty to provide real world hardware build and runtime
> logs for at least one device. Remember that any code change may break
> things for others, please avoid
