Common Review Checklist
- The code should comply with everything in HACKING.
- The code should be 'pythonic' and look like the code around it, to make the code more uniform and easier to read
- When adding a new file:
- If it's not installed by setup.py, but should be included in the tarball, be sure to add it to `MANIFEST.in`.
- Commit Message and Change break-up
- Follow the advice of Sahara/GitCommits
- If the patch fixes a bug, it should reference a bug report
- If the patch implements a feature, it should reference a blueprint. The blueprint should be approved before the patch is merged
- When to approve:
- Most of the patches need two +2s before being approved, please, don't hurry to make other contributors able to look at the patch
- If a patch has already been approved but requires a trivial/simple rebase to merge, you do not have to wait for a second +2, since the patch has already had two +2s
Notes for Non-Core Developers
- When you are reviewing, you may notice a review that has several +1's from other reviewers, passes the functional tests, etc. but the code still has not been merged. As only core developers can approve code for merging, you can help things along by getting a core developer's attention and letting them know there is a review with lots of positive reviews and needs final approval.