My RtC standard for Accumulo work

Apache Accumulo uses CtR to govern code changes. I prefer being closer to the RtC end of the spectrum. Accordingly, this is my personal standard that I will attempt to follow, of my own accord. It is a very lazy form of RtC but it is compatible with the way Accumulo is governed at this time.

This "policy" is very very subject to change. I'll try it out and adjust it based on its effectiveness.

Code Changes

• A code change is passed by lazy consensus. A minimum of three business days without review activity must pass before the change is automatically approved. For very minimal / obvious changes that still could use review, two business days is sufficient.
• There must be no open issues in the review (in Review Board, issues not "fixed" or "dropped") for a change to be automatically approved. Marking an issue as resolved counts as activity. :)
• Any -1 from a committer blocks automatic approval. The reasons should be reflected as issues to be worked, so that when they are resolved the -1 is withdrawn.
• A single +1 from a committer "manually" approves a change (regardless of review time), as long as no committer -1 votes remain. Open issues do not block manual approval.
• A committer may not vote +1 to her own changes.

A contributor may opt for a stricter form of the above, e.g., require two +1 votes, or require a longer time span before automatic approval.

A code change may be submitted without review if:

• it is obviously trivial or
• it is direct follow-on work to a recent change already understood to be needed (an "addendum")

Documentation Changes

Same as above, except only two business days is needed for automatic approval.

Committer-Specific Guidelines

As a committer:

• Remember, a committer may not vote +1 to her own changes.
• A committer may commit her own code change if it could have been submitted by a contributor without review, as defined above.
• If a committer votes -1, she must see the issue through to resolution so that either the -1 may be removed or the change / review is canceled.
• (Tentative) If an impasse has been reached where another committer will not resolve a -1, and a committer has tried everything reasonable to help get it resolved normally, she may invoke committer privilege and approve a code change manually, risking the wrath of the other committer.