I've worked on teams who had perpetually open tickets like "Solve warnings" or "Fix typos". Those issues could be referenced in commits just say they were involved with some changes.
>From your list, I think #1 is fine, and that #3 is preferable to #2. I don't feel strongly to be honest, as the trivialness of the changes don't pose a large QA risk either way. Do we realistically see the scenario of, "I need to hunt down the commit where this spelling mistake was corrected and it's hard to do because it's lumped in with a different patch set" posing some great roadblock to us? Not to nitpick too much, but I think the significance of git in this discussion is minimal-- the same problem could be had w/ any VCS. On Wed, Jan 6, 2016 at 3:28 PM, Christopher <ctubb...@apache.org> wrote: > Accumulo Devs, > > We typically create a JIRA for every change, and then explicitly reference > that JIRA in the git commit log. Sometimes, this seems like a lot of work > (or, at the very least, a big distraction) for *really* trivial changes[1]. > > My question(s): > > What are the pros and cons of being strict about this for trivial issues? > What value does creating a JIRA actually add for such things? Is the > creation of a JIRA issue worth the distraction and time in ALL cases, or > should developer discretion apply? How strict to we want to be about JIRA > references? > > * * * > > For additional consideration, I've noticed that trivial fixes tend to get > addressed in the following ways: > > 1. "Drive-by" - rolled into another, unrelated, commit (will get > reviewed/reverted/merged along with a non-trivial issue, simply due to its > vicinity in space or time) > 2. "One-JIRA-to-rule-them-all" - a JIRA without much of a description, > created "just so we have a ticket to reference" for several (perhaps > unrelated) trivial fixes > 3. "One-JIRA-each" - each trivial issue gets its own JIRA issue, its own > commit, and its own description (many of each are nearly identical) > > In each case, it seems like it would have been sufficient to simply > describe the trivial change in a separate git commit which is included in > the next push. > > * * * > > [1]: By "*really* trivial changes", I mean small typos, > spelling/grammar/punctuation/capitalization issues in docs, formatting, > String literal alignment/wrapping issues, perhaps even missing @Overrides > annotations, extra semicolons, unneeded warnings suppressions, etc. > Essentially, things that are typically one-off changes that don't change > the behavior or substance of the code or documentation, or that are > self-contained, easily-understood, can be reasonably expected to be > non-controversial, and which couldn't be further elaborated upon with a > description in JIRA. Such changes would not include trivial bug fixes or > feature enhancements, and are more likely to be described as style or typo > fixes. >
