Basic guidelines

If you submit a change, you can mark as verified unless you specifically want others to test it.
If you're the first reviewer, you can +1 or +2 a commit.
If you're reviewing something that's already +1, you cannot just give it another +1. You must take the other review into consideration and give it a +2 or you directly invite another person to review and give a +1.

Misc stuff

A few things which don't fit in the other categories but are important to keep in mind:

Coding guidelines should be followed unless there's a good reason not to.
Curl: don't use directly, use htdocs/lib/web.php:mahara_http_request() instead
No magic numbers: use constants instead of hard-coded numbers as much as possible
No DIRECTORY_SEPARATOR: always use the UNIX path separator when opening files (it works on Windows NT too)

The commit message is part of what we review. This article about great git commit messages is a good start. Other things to watch for:

If the commit fixes a user-visible bug, it should have a bug on the tracker and the bug number should be included somewhere (doesn't have to be the summary line) in the commit message like this: "bug #123456" or "Bug #123456"
Think of the reviewer: your "commit message + the diff" needs to tell a story: why you changed the code in that way. The reviewer may need to go back to the bug on the tracker to see how to reproduce exactly the original problem, but your solution should be clearly explained in the commit message if it's not obvious from the code.
When you fix a bug something introduced in a previous (recent-ish) commit, mention the commit hash in your commit message.
If adding a new feature, briefly describe the feature, don't assume the reviewer will know all about the fancy Web 2.0 service you're adding a plugin for (at the very least in this case, you should include the URL of the service).

Check for cross-site scripting problems:
- watch out for |safe in templates
- templates should be escaped by default

Check for cross-site request forgeries
- forms should ideally use pieforms which has a built-in session key check
- other operations that change the state of the application need to check the session key before doing anything

SQL injections
- use placeholders in queries
- ideally, do the validation of the parameters close to where they're used so that it's obvious that it's validated

our patches are maintained but not mixed in with upstream code
upstream doesn't add new dependencies
check if there are new copyright statements (which could lead to GPL-incompatible code being added to our codebase)