Hello all
Let's talk again about commit and reviewing guidelines.
Commit messages:
Please write a good commit message explaining what you're doing, why you're
doing it and how you're doing it. You don't have to describe the change line-
by-line (we can read diffs), but you need to explain why this solves the
problem you had. You may need to explain what the problem was too. If you've
considered other solutions, explain them. If you know of potential impacts,
you should list them.
If you have not considered impacts and drawbacks, do not submit. Stop and
consider everything in your solution.
The commit message starts with a single line, up to 72 characters, that is the
subject of the change. I recommend using a verb in the imperative ("fix",
"implement", "correct", "optimize", etc.)
Commits:
Commits should be atomic as much as possible. Make *one* self-contained change
per commit and make other changes in other commits. If you have to push 10
commits, then do so.
If you have to write "also", "too", "and" too much in your commit message, you
probably need to split.
Reviews:
If you get a -1 review from anyone, take the time to analyse the feedback. If
you disagree with the suggestion, say so. Clicking Done is not required if you
have done what was suggested. But if you did not do anything, say why.
After you submitted your updated change, please *wait* for the reviewers who
gave a -1 to have the chance to review again. You don't have to seek their
replies, but you have to give them a chance. I'd say at least one 24 hours
cycle (not including weekends) due to our timezones involved.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4447 bytes
Desc: not available
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150415/9b1351b9/attachment.p7s>
