Non-trivial patches on Zilla will invariably be ignored until someone gives them some peer-review. If you've got a spare half-hour you could spend it reviewing patches submitted by your peers!
When reviewing a patch, look out for bugs such as logic reversal, code regression (that is, when the patch breaks some other bit of code), security problems (such as introducing user-supplied data into SQL queries unescaped) and any other issues you can see which would prevent the patch from committing to CVS and performing the desired function.
If it is your opinion that the code is correct, add the 'reviewed' keyword to the bug, and also mark the particular patch file(s) you reviewed with the 'reviewed' checkbox, so we can see what you reviewed. When doing the first of these, also leave a comment stating that you have reviewed the patch and any comments you may have about it. This ensures that the name of the person who did the review is available, and also allows multiple people to review a single patch if they wish. There's no harm in multiple reviews: in fact, with several reviews the patch is more likely to get committed with speed.
If you find a problem in the code, note that in a comment on the bug while removing the patch keyword. Removing the patch keyword will take the patch out of the "patches waiting" list, and then the assignee of the bug can add it back again when a fixed patch is ready. Please be as specific as possible when noting problems with patches — treat it like a bug report and give all relevant information that the assignee might need to work out what you are talking about.
If you have access to a private LJ installation, you can go one step further and actually test patches. They still must be reviewed before commiting to CVS, but also testing is good for larger patches. You can mark individual patch attachments as 'tested' and note in the bug that you have tested them.
There are lots of patches sitting in Zilla waiting to be committed. Please help review!