Hunchworks patch review process

This page outlines the review process for Hunchworks code. Each commit proposed for inclusion in Hunchworks should be reviewed by at least one developer other than the author. Some developers, referred to in this document as core committers, may commit directly to the Hunchworks repository without waiting for review. Their changes are still subject to review, and may be reverted if they fail any of the Review Criteria.

A related process is Improvement Proposals. While patch review protects code quality in the Hunchworks project at a small granularity, the Improvement Proposal process is intended to promote coordinated design and feedback for larger modifications such as new features or architectural changes.

##Goals

By requiring a review of code coming into Hunchworks, we aim to maintain code quality within the Hunchworks project while still allowing contributions from the Hunchworks community.

##Review Criteria

Patch reviews should adhere to the standards set in the Review Criteria, a Project Steering Committee approved set of criteria for the inclusion of new code.

##Process

For contributors who do not have commit access to the Hunchworks repository, the review process is as follows:

1. Find or create a ticket describing the feature or bug to be resolved.
2. Create changes to Hunchworks code addressing the ticket.
3. Publish those changes and request a review from the Hunchworks committers. The recommended format is a GitHub pull request. If you are unable or unwilling to provide a change as a branch on GitHub, please consult the developer's list for advice.
4. At least one Hunchworks committer should review the submitted changes. If he finds the patch acceptable, the changes will be pulled into Hunchworks. If problems are found, then he should list them clearly in order to allow the original author to update the submission (at which point we return to point 2 in this process.) In the case of a feature idea which is simply not suitable for inclusion as core Hunchworks functionality, the patch may be rejected outright.

##Code Review Flow

The general workflow for code patches coming into Hunchworks.

Note: If after a few days your patch has not been reviewed by any Hunchworks committer, please feel free to bring it up either in the Hunchworks mailing list or the IRC channel. The Hunchworks community (and it's committers) try to respond quickly and give adequate feedback to maintain the interest of new potential members. However, sometimes other responsibilities prevent us from responding quickly.

##Core Committers

It is assumed that core committers are familiar with the quality guidelines and capable of producing acceptable patches without the need for waiting on review. Therefore, core committers may make changes without requesting review first (although they are welcome to request review for code if they feel it is appropriate.) For commits made without prior review, committers should review the changes and revert them if they are in violation of the project quality guidelines.

##Becoming a Core Committer

In order for a developer to become a core committer, he must demonstrate familiarity with the quality guidelines for the Hunchworks project by producing at least two patches which successfully pass review and are merged without requiring modification. A candidate for core committer-ship must be nominated by a member of the Project Steering Committee, and approved via Apache consensus voting among PSC members.