+1, I'd recommend addition of command line interface (cli). Here is a stab at component leads too:
Build Process (Mike) Metrics (Kyo) Viz (Alex) Website (Andrew) Data Sources (Mazi) Analysis (Cameron/Mike) Webapp (Andrew/Shakeh/Mike) Documentation (Paul - volunteering myself but really this is an all) CLI (Mazi) This somewhat seems aligned with what has already been going on from my perspective. Component leads is cool but too many could make a diffused team (i.e. Ignoring issues because its someone else's problem). That said, +1 to give it a whirl. --Paul On 8/20/13 11:35 AM, "Mattmann, Chris A (398J)" <[email protected]> wrote: >LGTM.. > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >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: Tuesday, August 20, 2013 11:06 AM >To: "[email protected]" <[email protected]> >Subject: Re: JIRA component names > >>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.m >>>b >>> >> >>ox/browser >>> >> >> > [3]: >>> >> >> > >>> >> >> >>> >> >> >>> >> >>> >> >>> >>>https://cwiki.apache.org/confluence/display/CLIMATE/Open+Climate+Workben >>>c >>> >> >>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 >>> >> >> >> >>> >> >> >> >>> >> >> >>> >> >>> >> >>> >>> >
