RRReviewers

== What's a Round Robin Reviewer (RRR)? ==
Round Robin Reviewers are hackers who volunteer to be assigned random patches (usually according to their level of ability) to review during a commitfest by the CommitFest Manager. They generally have at least good C skills and a general knowledge of PostgreSQL, but some are accomplished PostgreSQL hackers.
== What do I need to do to become an RRR? ==
# Subscribe to the pgsql-hackers and the pgsql-rrreviewers mailing lists.
# Volunteer to review on pgsql-rrreviewers.
# Sign up for an account on this wiki.
# Read the Reviewing a Patch page, and the pages & docs they links to.
== What happens next? ==
# The CommitFest Manager will assign you a patch by e-mail.
# Visit commitfest.postgresql.org, edit the patch, and put your name down as a reviewer. This will confirm that you have set up the community account needed to make entries into the web app, and that you have accepted the assigned patch.
# If you can't or don't want to review that patch, you should reject it within 24 hours (and you will be assigned a new patch if appropriate).
# Read the information on the patch and search the mailing list archives for other comments related to the patch. If you find threads related to the patch which are not yet referenced from the web app entry, please add Comment entries with the ID of a message from the thread.
# Review the patch within 4 days.
# Reply to mail thread on -hackers with comments; make sure the submitter is cc'd.
# Put a summary of your comments on commitfest.postgresql.org by clicking on the patch, setting Comment Type to Review, pasting in the message ID of your email to the -hackers list, and putting in a brief (one or two line) summary of the review.
# Unless this was a preliminary review, and you intend to post an additional review very soon (perhaps after a brief on-list discussion), the status of the patch should change:
## If the patch needs work, and it seems reasonable that the author could complete that work within the current CommitFest, change the status to "Waiting on Author".
## If the patch seems to you ready to accept, change the status to "Ready for Committer".
## If the purpose of the patch is something the community wants, and the overall approach is viable, but more work is needed than is reasonable to expect that the author can complete within the CF, change the status to "Returned with Feedback" and enter "Date Closed".
## If the purpose of the patch is not something the community wants, or the overall approach is not appropriate, change the status to "Rejected" and enter "Date Closed".
# In any case, please e-mail the CommitFest Manager that you are ready to work with another patch.
Note that, if you are assigned a "WIP" patch, it is unlikely to be ready for committing. Instead, you should test the patch as best you can, and report on it to pgsql-hackers.
== Guidelines for Review ==
* Be polite to the patch submitters. You'll probably be one yourself someday.
* Raise any questions you have on pgsql-hackers mailing list.
* Don't hesitate to ask for help; a poorly done review will slow down the CommitFest far more than not reviewing at all.
* You are helping out in order to reduce the workload on the committers. Do as much as you can, then stop.
* Contact the CommitFest Manager immediately if you won't be able to complete a review.
* When reading from the mail archives, make sure to read the entire thread about the patch.
Category:CommitFest