Review Checklist

This is a checklist that can be consulted when authoring or reviewing a patch.

Read the patch

The patch should apply cleanly on top of the latest development release. "cleanly" in particular means without "fuzz".
There should be no trailing whitespace on any line touched by the patch.
The patch should be generated by Mercurial (preferably using hg export tip) and have a sensible commit message. A multi-line commit message is allowed and in fact encouraged. The first line (which will be shown by hg log) should make sense by itself.
make ptestlong should pass with the patch applied.
If the patch could impact any optional packages or tests, install those optional packages and run the optional tests using sage -t -only_optional=package. See #6329 for what *not* to do.
Run an interactive sage session, and manually exercise the affected code. Try in particular some corner cases or stuff not mentioned in the EXAMPLES section.

Documentation should be formatted according to the developer's guide
Run sage --docbuild reference html to rebuild the reference docs. View any affected pages. You can use the extra option --warn-links as in sage --docbuild --warn-links reference html to see if all links are properly resolved.
View affected documentation from within a sage session.
All variables in documentation should be enclosed in backticks.

All new code should be doctested. Use sage --coverageall to make sure the doctest coverage has not gone down.
If the patch fixes a defect, there should be a doctest checking that the defect is fixed, and the comment should mention the trac ticket number. You can use the special sphinx markup :trac:`12314` for that.
Add a TESTS section to test corner cases or (for a bugfix ticket) cases fixed by the patch.
Also doctest exceptions. For example, when writing a function for division, test that dividing by zero yields a reasonable exception (as opposed to a crash of Sage)

All new functions should have INPUT, OUTPUT, EXAMPLES, and TESTS sections where applicable. .. SEEALSO:: section is highly recommended.
New files should have a heading as shown in the developer's guide