Okay so here goes the vote results :-)
Lets turn this thread now to a discussion that should end up with all
down voted points clarified and cast to vote again.
Another question right now do we want to add +1 points already to
Guidelines or wait for all list to clarify? Some fine tuning of the
text will be part of PR review :-)
Remember we do this to make our life easier and improve code quality /
stability / self-compatibility :-)
Things that are all voted +1 and we agree with no neutral or blocking votes:
1. Contributing Guidelines with hints for Reviewers.
2. PR and git commits must adhere to Guidelines or rejected.
3. Git commit messages as important as PR description.
4. Proper description details requirements.
6. Git commit message must adhere to description requirements.
7. Git commit message mandatory fields (topic, desctiption, signature).
13. Breaking changes build and runtime test logs are mandatory.
Things that need redefinition had 0 or -1 votes:
5. PR must adhere to description requirements (one 0).
8. Changes must come with documentation (1:-1 vs 11:+1).
9. Zero trust approach to user testing (1:-1 vs 11:+1).
10. Breaking changes not welcome. (5:-1, 1:0, 6:+1).
11. Respect for long term maintenance and self-compatibility (1:-1, 1:0, 11:+1).
12. Breaking changes handling process (1:0, 11:+1).
14. Minimum code reviews 2 -> 4 (5:-1 vs 7:+1).
15. Reviews must come from independent organizations (1:-1, 1:0, 10:+1).
16. Self company commit/review/merge not allowed (1:0, 11+1).
17. Self commit and merge not allowed (1:-1 vs 11:+1).
18. REDO: PR as small as possible and single change only, no bundles (1:0, 3+1).
19. REDO: Lazy Consensus (3:-1, 3:+1).
Last remarks - another vote of this kind will be performed on Google
Forms so we have results presented and counted automatically with a
list of remarks auto generated too.. xls file will be attached to
result vote.. is that okay? ;-)
Thanks everyone!! :-)
Tomek
### 1. Contributing Guidelines with hints for Reviewers.
1. In Contributing Guidelines we are adding additional section for
Reviewers in order to provide complementary set of rules that should
filter out breaking code as much as possible also on our side.
+1: 12
0: 0
-1: 0
### 2. PR and git commits must adhere to Guidelines or rejected.
2. Each PR (including git commits) _must_ adhere to requirements
presented in Contributing Guidelines or will be auto-rejected until
fixed / updated.
+1: 11
+0.5: 1
0: 0
-1: 0
Remarks:
* Nathan: Sometimes we may need to override the Contributing
Guidelines in special circumstances. Consider, for example, how
nxstyle has given false positives on occasion, such as when we have to
relax our capitalization rules because of 3rd party code we're
interfacing with. So, I would suggest that while PRs _must_ adhere to
the requirements, there should also be a way to relax this requirement
if appropriate due to legitimate reasons.
### 3. Git commit messages as important as PR description.
3. Git commit messages are as important as PR descriptions. These
provide in-code descriptions of each change and are git interface
independent.
+1: 12
0: 0
-1: 0
### 4. Proper description details requirements.
4. 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
where mandatory. 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: 12
0: 0
-1: 0
### 5. PR must adhere to description requirements.
5. Proper description in PR is mandatory, or change is auto-rejected
until fixed / updated. Build and real world hardware runtime logs are
mandatory.
+1: 11
0: 1
-1: 0
Remarks:
* Ville: 0 Description for PR and commit are a given, how is anyone
expected to understand what you are trying to do (and why), without a
description? That is what the commit text field is for.
### 6. Git commit message must adhere to description requirements.
6. Proper description in Git commit message 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.
+1: 12
0: 0
-1: 0
Remarks:
* Matteo: +1 definitely shouldn't put runtime logs in the commit description.
### 7. Git commit message mandatory fields (topic, desctiption, signature).
7. Each git commit message must consist of topic, description, and
signature, which are mandatory, or change is auto-rejected until fixed
/ updated. Topic consists of functional prefix, ":" mark, and short
self-explanatory context. Description is separated from topic with a
single blank line. Example already presented in Contributing
Guide
