James, I suggest, we break the conversation in to two parts. If setting up the components to be the same allows an easier import, then lets do that as part of the import exercise, which we will talk about next. Even if we do that, the next question would be, what do we really want the components to be. I would like to focus on that for the moment. When we discuss the import was can talk about using the existing components as a start.
Of course there is nothing that saw we can't use the existing components as the to-be-state as well. ~Michael On Mar 22, 2011, at 9:04 PM, James Purser wrote: > Sounds like a good start. Then we can look at changing things to make a bit > more sense with regards to WIAB. > > On Wed, Mar 23, 2011 at 3:02 PM, Michael MacFadden < > michael.macfad...@gmail.com> wrote: > >> James, >> >> I looked and it seems like the Google Issue Tracker has: >> >> UI >> Logic >> Persistence >> Scripts >> Docs >> >> Is this what you are suggesting? >> >> ~Michael >> >> >> On Mar 22, 2011, at 8:55 PM, James Purser wrote: >> >>> For the moment, might be best to replicate what the Google Issues tracker >>> has so that we can import the old issues and then take it from there. >>> >>> On Wed, Mar 23, 2011 at 2:53 PM, Michael MacFadden < >>> michael.macfad...@gmail.com> wrote: >>> >>>> We can redefine them as we see fit, and it fairly easy to do bulk >> changes >>>> on existing issues to re-assign components. >>>> >>>> >>>> On Mar 22, 2011, at 8:05 PM, David Hearnden wrote: >>>> >>>>> Are those components something that can be refined later? i.e., could >> we >>>> start with high-level categories, and later refine them as needed? Or >> are >>>> those categories set in stone at setup time? That might strongly >> influence >>>> the component list. >>>>> >>>>> (I've never used JIRA) >>>>> >>>>> -Dave >>>>> >>>>> On Wed, Mar 23, 2011 at 2:02 PM, Michael MacFadden < >>>> michael.macfad...@gmail.com> wrote: >>>>> All, >>>>> >>>>> I am starting to set up Jira. Typically one of the first things to be >>>> done is to define the components. These components would be ones that >> we >>>> would want to target issues to. I would like to get some input on what >> the >>>> components should be. Things to keep in mind: >>>>> >>>>> 1) How granular do we want to be. Would "server" and "web client" >>>> suffice, or do we need things like the wave panel vs the wave list vs >> the >>>> profile management section etc. >>>>> >>>>> 2) What naming convention would we use? There is only really one >> level >>>> of components, no nesting. So we might have things like Web Client - >> Wave >>>> Panel and Server - Mongo DB Persistence, etc. >>>>> >>>>> 3) The point of defining components is so that the groups of people >> who >>>> typically work on those components can filter the issue list based on >> those >>>> components. While the architecture might logically be broken down in to >>>> certain components, if it doesn't improve our ability to manage the >> issues, >>>> then they don't have to line up 1 to 1. >>>>> >>>>> >>>>> Suggestions and input would be great. One small request, lets try to >>>> stay at a high level here and not go down rabbit holes discussing a >>>> particular possible component as nauseum. Thanks. >>>>> >>>>> ~Michael >>>>> >>>> >>>> >>> >>> >>> -- >>> James Purser >>> Collaborynth >>> http://collaborynth.com.au >>> Mob: +61 406 576 553 >>> Wave: ja...@collaborynth.com.au >> >> > > > -- > James Purser > Collaborynth > http://collaborynth.com.au > Mob: +61 406 576 553 > Wave: ja...@collaborynth.com.au
