Code Review

Reviewer Guidelines

1. Prioritize. 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.
2. 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.
3. 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.

Patch-author Guidelines

There are some things that make it easier to get a good, prompt review, and to improve the quality of the patch you submit. Help your reviewers help you, and don't be surprised if you get asked about one of the following:

• 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.