Yeah in general component leads for me have worked on smaller projects just for the auto-assign feature alone -- but in general I am not a huge fan b/c it tends to imply to newcomers that components have ownership over them instead of the entire code base having shared ownership by the PMC.
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: <Ramirez>, "Paul M (398J)" <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, August 20, 2013 11:49 AM To: "[email protected]" <[email protected]> Subject: Re: JIRA component names > >+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+Workbe >>>>n >>>>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 >>>> >> >> >> >>>> >> >> >> >>>> >> >> >>>> >> >>>> >> >>>> >>>> >> >
