On Wed, Jul 2, 2008 at 9:15 AM, Evan Gilbert <[EMAIL PROTECTED]> wrote:
> Hi all - wanted to know if we have an official guideline on when to create > a JIRA issue vs. just committing a change. > > My instinct is that you should open a JIRA issue for changes that have a > significant design portion or that affect APIs that are exposed by a > library, and to commit when you are making minor changes or refactorings. > That's mostly what we've been doing. Minor changes (bug fixes, documentation fixes, etc.) that aren't going to impact other users can be committed without much issue. Larger changes (API changes, significant refactoring, new classes, and pretty much any change of more than 100 lines) should have a JIRA ticket associated with it, or at least an email discussion. When the commit is made, that discussion is usually referenced so that we know what the change was for. It's a poor man's code review system, but it seems to work out pretty well because we get lots of scrutiny post-commit. I'll comment on the patch itself once I get a chance to really look at it later :) > > > For discussion purposes, I've attached a patch that I would think is well > below the JIRA threshhold. > > Evan >
