+1 Cam. I like everything there.
-- Joyce On Tue, Aug 20, 2013 at 11:06 AM, Cameron Goodale <[email protected]>wrote: > Here is the current state of component names: > > Current list we won't change: > ------------------------------------------ > build process > general > metrics > visualization > website > > New Components to Add: > ----------------------------------------- > documentation > dataset > > > The 4 Contentious Components still being discussed: (with my attempt to > please the commenters thus far) > > --------------------------------------------------------------------------------- > rcmed -> data sources > rcmet -> analysis > rcmet ui -> webapp (this would include ui, middleware, etc...) > regridding -> data processing (loosely maps to dataset_processor, but > would encompass ensemble, temporal and spatial regrid) > > I also agree with Mike J. that JIRA has functionality to map components to > Component Leads which might be a nice way to help divide up the work, and I > feel there is a tension between component labels that are Core Developer > Friendly (map to a module of code - dataset_processor) and New User > Friendly (map to a set of functionality they understand - regridding). We > can always have both, but run the risk of too many options. > > We can also setup the new components in the list, put them into use and > revisit this issue in 6 months and see what components are used and which > are not. Call it a "Try and Wait" approach to this. > > > > -Cameron > > > > > On Tue, Aug 20, 2013 at 8:03 AM, Ramirez, Paul M (398J) < > [email protected]> wrote: > > > All, > > > > Seems to me there is a simple high level web-ui, command line, and API. > > Potentially, there is services too but at the moment that would reflect > > the services to support the web UI. There should also be something that > > links issues to build so we can group together updates to any build > > scripts, packaging, and distribution to somewhere like pypi. > > > > I think if we get too specific then if there are shifts we have to go > > change our labels again (imo). > > > > --Paul > > > > On 8/20/13 7:42 AM, "Michael Joyce" <[email protected]> wrote: > > > > >Chris, > > > > > >1) Regridding is far too specific with regards to what dataset_processor > > >actually does in my opinion. Visualization vs plotting, I like > > >visualization better personally. > > > > > >2) Again, "pipeline" seems too generic. Even "rcmet" is too generic in > my > > >opinion. I think it's a sign that something is wrong when the vast > > >majority > > >of our issues are falling under a single component. Too me that says > that > > >we need to break that component into smaller, more specific components. > > >(Unless, of course, all the work is actually being done on just one > > >specific component). > > > > > >I think the more important question is, what are we using these labels > > >for? > > >Are they for accurately describing issues for committers/contributors or > > >are we trying to make it easy for people making JIRAs to label the > > >problem? > > >Most people who don't actively participate on the project are (probably) > > >going to label their issue as "general" since they have no idea what is > > >broken. If that's the case, then our components should be useful for the > > >people on the project and thus specific. We should also exploit > component > > >leads so that issues can be filtered to people on the project who are > most > > >capable of dealing with/delegating the issue. > > > > > >TLDR: I like specific, descriptive component names over generic > > >catch-alls. > > >One generic component is good for people making issues that have no idea > > >what is wrong; These can adjusted once someone has looked at the > problem. > > >Let's exploit component leads to make all of our lives easier! > > > > > >Thoughts? > > > > > > > > >-- Joyce > > > > > > > > >On Mon, Aug 19, 2013 at 7:31 PM, Mattmann, Chris A (398J) < > > >[email protected]> wrote: > > > > > >> Cam, I am +1 for this remapping, with the caveats: > > >> > > >> 1. regridding is much more understood in the community than dataset > > >> processor. > > >> Same goes for viz (compared to plotting). So dunno on those. > > >> > > >> 2. I can see your point about rcmet, but don't we have a concept of > > >> end-to-end > > >> regrid->analysis->viz pipeline? Wouldn't something like pipeline or > > >>maybe > > >> even > > >> analysis make more sense than simply having no component? To me some > > >> component is > > >> better than none. > > >> > > >> Bump it to the top of my list anytime. > > >> > > >> Cheers, > > >> Chris > > >> > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> Chris Mattmann, Ph.D. > > >> Senior Computer Scientist > > >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >> Office: 171-266B, Mailstop: 171-246 > > >> Email: [email protected] > > >> WWW: http://sunset.usc.edu/~mattmann/ > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> Adjunct Assistant Professor, Computer Science Department > > >> University of Southern California, Los Angeles, CA 90089 USA > > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> > > >> > > >> > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: Cameron Goodale <[email protected]> > > >> Reply-To: "[email protected]" > > >> <[email protected]> > > >> Date: Monday, August 19, 2013 7:21 PM > > >> To: "[email protected]" > > >><[email protected]> > > >> Subject: Re: JIRA component names > > >> > > >> >Hey Guys, > > >> > > > >> >I am going to take a crack and the task of mapping A1 -> B1 that > Chris > > >> >mentioned since I have been making JIRAs and wishing for some other > > >> >components in the list. Since the new OCW refactoring introduces > some > > >>new > > >> >software modules/components i think it makes sense to align JIRA > issues > > >> >with each area of the code. This helps map issues to modules in the > > >>code, > > >> >items tasks that touch large sweeping parts of the code should go > under > > >> >'general' and they need a closer look since they are probably taking > on > > >> >too > > >> >much work and need sub-tasks or should be broken into smaller chunks. > > >> > > > >> >rcmed -> data_source (this would also relate to ESG work or > > >>developing an > > >> >interface to OpenDAP moving forward) > > >> >rcmet -> None (just drop this from the OCW issue tracker. RCMET is a > > >>JPL > > >> >project that is built on OCW) > > >> >rcmet ui -> webapp (The 'ui' is basically AngularJS and Bottle. > > >>Webapp is > > >> >generic enough that we can change to Ember.js and CherryPy if we > like) > > >> >regridding -> dataset_processor (map to the module that does this > > >> >function) > > >> >visualization -> plotting (map to the module that does this function) > > >> >documentation -> NEW Component > > >> >dataset -> NEW Component > > >> > > > >> >A note about rcmet above: > > >> > > > >> >Here are 14 open issues with rcmet as the component and what I think > a > > >> >reasonable mapping could be: > > >> > > > >> >(general) CLIMATE-261 Consolidate Code that converts a String into a > > >> >Datetime Object > > >> >(general) CLIMATE-259 Create branch to refactor updates to > > >>ui/services to > > >> >support multiple metrics/plotting > > >> >(documentation) CLIMATE-258 Improve Evaluation documentation > > >> >(dataset) CLIMATE-219 Add name attribute to Dataset > > >> >(metrics) CLIMATE-218 Update metric handling in Evaluation to > coincide > > >> >with new Metric definition > > >> >(general) CLIMATE-217 Add metrics.py for OCW refactoring > > >> >(general) CLIMATE-214 Add evaluation.py to OCW > > >> >(dataset_processor) CLIMATE-179 Add support for Observation/Reference > > >> >option when doing Spatial Regridding > > >> >(general) CLIMATE-137 OCW refactoring code > > >> >(general) CLIMATE-50 RCMET needs to use a logger instead of prints > > >> >(general) CLIMATE-49 Add the 'obs' regrid option into > > >> >toolkit.do_data_prep.prep_data function > > >> >(REMOVE) CLIMATE-47 precipFlag attribute within the Model class > needs > > >>to > > >> >be refactored - Not an issue with OCW Dataset Class > > >> >(general) CLIMATE-8 CLIMATE-7 SubRegions Support > > >> >(metrics) CLIMATE-7 Refactor the metrics.metrics_plots function > > >> > > > >> >Thanks for allowing me to bump this thread to top of your inbox. > > >> > > > >> >-Cam > > >> > > > >> > > > >> > > > >> >On Fri, Aug 16, 2013 at 11:09 AM, Mattmann, Chris A (398J) < > > >> >[email protected]> wrote: > > >> > > > >> >> Perfect > > >> >> > > >> >> Sent from my iPhone > > >> >> > > >> >> On Aug 16, 2013, at 10:49 AM, "Michael Joyce" <[email protected]> > > >>wrote: > > >> >> > > >> >> > If people need to catch up on the refactoring that's been > occurring > > >> >>they > > >> >> > can find the original proposal for refactoring at [1]. The full > > >>thread > > >> >> > where this was discussed can be found in the mail archives at > [2]. > > >>The > > >> >> wiki > > >> >> > entry that Mazi made detailing proposed package layouts > (including > > >>the > > >> >> one > > >> >> > we ultimately went with) is available at [3]. > > >> >> > > > >> >> > To summate: > > >> >> > > > >> >> > The old code (which was called RCMET) is being refactored into > the > > >>ocw > > >> >> > package with the intention of making the code base more > > >>maintainable > > >> >>and > > >> >> > the API nice and pretty. > > >> >> > > > >> >> > Hopefully this is sufficiently verbose. I don't have the time to > go > > >> >>into > > >> >> > more detail at the moment. If anyone is confused feel free to ask > > >>away > > >> >> and > > >> >> > I'll try to elaborate later!! > > >> >> > > > >> >> > Thanks > > >> >> > Mike > > >> >> > > > >> >> > > > >> >> > [1]: http://s.apache.org/RKI > > >> >> > [2]: > > >> >> > > > >> >> > > >> >> > > >> > > >> > > > https://mail-archives.apache.org/mod_mbox/incubator-climate-dev/201306.mb > > >> >>ox/browser > > >> >> > [3]: > > >> >> > > > >> >> > > >> >> > > >> > > >> > > > https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workbenc > > >> >>h+API+summary > > >> >> > > > >> >> > > > >> >> > -- Joyce > > >> >> > > > >> >> > > > >> >> > On Fri, Aug 16, 2013 at 10:12 AM, Mattmann, Chris A (398J) < > > >> >> > [email protected]> wrote: > > >> >> > > > >> >> >> Can you detail "the refactoring" so everyone on the list here > > >>knows > > >> >>what > > >> >> >> you are talking about? > > >> >> >> > > >> >> >> A few paragraphs would be great, Mike, thanks. > > >> >> >> > > >> >> >> Cheers, > > >> >> >> Chris > > >> >> >> > > >> >> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >> Chris Mattmann, Ph.D. > > >> >> >> Senior Computer Scientist > > >> >> >> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >> >> >> Office: 171-266B, Mailstop: 171-246 > > >> >> >> Email: [email protected] > > >> >> >> WWW: http://sunset.usc.edu/~mattmann/ > > >> >> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >> Adjunct Assistant Professor, Computer Science Department > > >> >> >> University of Southern California, Los Angeles, CA 90089 USA > > >> >> >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> -----Original Message----- > > >> >> >> From: Michael Joyce <[email protected]> > > >> >> >> Reply-To: "[email protected]" > > >> >> >> <[email protected]> > > >> >> >> Date: Friday, August 16, 2013 10:07 AM > > >> >> >> To: dev <[email protected]> > > >> >> >> Subject: Re: JIRA component names > > >> >> >> > > >> >> >>> The 3 that caught my eye were: > > >> >> >>> > > >> >> >>> rcmet > > >> >> >>> rcmet ui > > >> >> >>> rcmet > > >> >> >>> > > >> >> >>> As to what they should be instead I don't know. 'rcmet ui' > could > > >> >> easily be > > >> >> >>> 'ocw ui' without loss of clarity. With the refactoring I don't > > >>know > > >> >> what > > >> >> >>> we > > >> >> >>> want to call 'rcmet' and 'rcmed' doesn't seem like it needs to > be > > >> >> there at > > >> >> >>> all, so I don't know if we need to think of an alternative. > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> -- Joyce > > >> >> >>> > > >> >> >>> > > >> >> >>> On Fri, Aug 16, 2013 at 9:46 AM, Mattmann, Chris A (398J) < > > >> >> >>> [email protected]> wrote: > > >> >> >>> > > >> >> >>>> Can you be more specific and propose e.g., : > > >> >> >>>> > > >> >> >>>> A1->B1 > > >> >> >>>> A2->B2 > > >> >> >>>> .. > > >> >> >>>> > > >> >> >>>> Where A is the set of "JPL/RCMES centric" names and B is the > new > > >> >> >>>> proposed one? > > >> >> >>>> > > >> >> >>>> Cheers, > > >> >> >>>> Chris > > >> >> >>>> > > >> >> >>>> > > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >>>> Chris Mattmann, Ph.D. > > >> >> >>>> Senior Computer Scientist > > >> >> >>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > >> >> >>>> Office: 171-266B, Mailstop: 171-246 > > >> >> >>>> Email: [email protected] > > >> >> >>>> WWW: http://sunset.usc.edu/~mattmann/ > > >> >> >>>> > > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >>>> Adjunct Assistant Professor, Computer Science Department > > >> >> >>>> University of Southern California, Los Angeles, CA 90089 USA > > >> >> >>>> > > >>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > > >> >> >>>> > > >> >> >>>> -----Original Message----- > > >> >> >>>> From: Michael Joyce <[email protected]> > > >> >> >>>> Reply-To: "[email protected]" > > >> >> >>>> <[email protected]> > > >> >> >>>> Date: Friday, August 16, 2013 9:31 AM > > >> >> >>>> To: dev <[email protected]> > > >> >> >>>> Subject: JIRA component names > > >> >> >>>> > > >> >> >>>>> Some of our JIRA components are very JPL/RCMES-centric. What > > >>does > > >> >> >>>> everyone > > >> >> >>>>> think of switching these over to something more generic? > Ideas > > >>on > > >> >> >>>> names? > > >> >> >>>>> > > >> >> >>>>> -- Joyce > > >> >> >> > > >> >> >> > > >> >> > > >> > > >> > > > > >
