Dave's suggestions sound good. Another piece of code that runs both client and server is the comms protocols. Let's either roll that into model "Wave Model & Protocols" or add a new component for "Protocols".
On 23 March 2011 20:20, David Hearnden <hearn...@google.com> wrote: > -1 for "Logic". > > Grouping by service/component and roughly aligning with the code's package > structure makes a lot of sense to me. > > James' categories SGTM. I'd add two more: > > Web Client > > Federation > > Server (i.e., serving the wave protocol) > > Extensions > > + Wave Model > > + Search/Indexing > > "Wave Model" is for components in wave.model.* (like OT, documents, etc) > that are both client and server, and don't fit any of the other categories. > > I think that "Search/Indexing" also should be separated from the wave > protocol part of the server. > > I'd anticipate possible further breakdown of some parts, e.g. > > Web Client - Editor > > Web Client - Wave Panel > > or > > Server - Front End > > Server - Wave Storage > > Server - Concurrency Control > > but those are fine-grained enough that it makes sense to create them on > demand if that's relatively painless in JIRA. > > -Dave > On Wed, Mar 23, 2011 at 3:16 PM, James Purser <jamesrpur...@gmail.com > >wrote: > > > Sure, > > > > I'd probably suggest something like the following then: > > > > Web Client > > Federation > > Server > > Extensions > > > > > > On Wed, Mar 23, 2011 at 3:13 PM, Michael MacFadden < > > michael.macfad...@gmail.com> wrote: > > > > > 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 > > > > > > > > > > > > -- > > James Purser > > Collaborynth > > http://collaborynth.com.au > > Mob: +61 406 576 553 > > Wave: ja...@collaborynth.com.au > > >
