Code Review: Difference between revisions

Jump to navigation Jump to search
no edit summary
(Created page with "== Reviewer Guidelines == # Prioritize. Realize that reviewing code is more valuable than writing code as it results in higher overall project activity. If you find you can't...")
 
No edit summary
Line 2: Line 2:


# Prioritize. Realize that reviewing code is more valuable than writing code as it results in higher overall project activity. If you find you can't write code anymore due to prioritizing reviews over coding, grow more reviewers.
# Prioritize. Realize that reviewing code is more valuable than writing code as it results in higher overall project activity. If you find you can't write code anymore due to prioritizing reviews over coding, grow more reviewers.
# Communicate. If you are an active contributor, you should not leave r? patches sitting in your queue without feedback. "I will review this next week because I'm (busy reviewing ___ this week|away at conference). I think bugzilla could use some improvements there. If you think a patch is lower priority than your other work communicate that.
# Communicate. If you are an active contributor, you should not leave r? patches sitting in your queue without feedback. "I will review this next week because I'm (busy reviewing ___ this week|away at conference). If you think a patch is lower priority than your other work communicate that.
# Silence is not an option. If you think saying nothing is better than admitting than you wont get to the patch for a while(Holding back bad code is a feature, not a bug, do it politely), that's passive aggressiveness (https://en.wikipedia.org/wiki/Passive-aggressive_behavior). This is not a good way to build a happy coding community.  
# Silence is not an option. If you think saying nothing is better than admitting than you wont get to the patch for a while(Holding back bad code is a feature, not a bug, do it politely), that's passive aggressiveness (https://en.wikipedia.org/wiki/Passive-aggressive_behavior). This is not a good way to build a happy coding community.  


Line 10: Line 10:


* small patches, functionally divided;
* small patches, functionally divided;
== Bugzilla Improvements ==
* In addition to r+/r- add eta flag to specify when the patch will get reviewed. Bugzilla should send reminder emails based on that flag.
Confirmed users
381

edits

Navigation menu