I think one is a bottom-up way of doing things the other is top-down, where top down is do your design mocking first in a design JIRA and the actual coding second and use that JIRA during commits.
In my experience what I called bottom-up sometimes has the danger that peeps code without version control until they gold plated their feature. That means until gold plating it's impossible to do integration testing and once gold plating has finished a large junk of code needs to be integration tested. Cheers Daniel On Fri, Jan 20, 2012 at 7:23 PM, David Blevins <[email protected]> wrote: > Big features don't come in one commit. That's the thing to remember. I'll > come back to that thought shortly.... > > Here are some stats from beta-1 to beta-2: > > - There were 436 commits total. (whoo hoo!!) > - Only 69 of those commits had JIRAs (eek!) > > So first, totally awesome to see all the activity. Second, lets find some > way to improve our JIRA usage. > > Back to the original thought; big features don't come in one commit. > > Over the course of years I've noticed that most the new feature JIRAs are > filed at the end of the release. I've also noticed that most of the changes > without JIRA numbers go to these new features or enhancements. > > That makes sense as big changes don't come in one commit. But that doesn't > mean there shouldn't be a JIRA issue. We could file a JIRA for the overall > change and just keep reusing it on each of the many tiny commits that relate. > > Seems like a good middle ground. Having to create a new JIRA for every > commit is annoying and noisy, having no JIRAs makes for some empty release > notes (or an incredible amount of time spent picking through commits looking > for potential JIRAs). > > > Thoughts? > > > -David >
