I believe the current workflow has inhibited progress and caused tension. Although I've been more of an observer than contributor it seems to me that when your community is small that the emphasis should be on allowing as Chris states for people to "scratch their own itch." Additionally, I've seen at times that reviews have focused on minor items and that discussions often took longer than either side reaching out to the other to help get the patch in and build community and camaraderie amongst all those that are already committers. This has gone on to the extent that appears detrimental to the project.
I would actively support CTR at this point so that energy and progress can be infused. Sure this could cause some technical debt to build up but community over code would seemingly once again come to the forefront which appears to be lacking at the moment. --Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Ramirez, M.S. Technical Group Supervisor Computer Science for Data Intensive Applications (398M) Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 158-264, Mailstop: 158-242 Email: paul.m.rami...@jpl.nasa.gov<mailto:paul.m.rami...@jpl.nasa.gov> Office: 818-354-1015 Cell: 818-395-8194 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On May 12, 2015, at 9:33 AM, "Mattmann, Chris A (3980)" <chris.a.mattm...@jpl.nasa.gov<mailto:chris.a.mattm...@jpl.nasa.gov>> wrote: I don’t think we should dictate everything be code reviewed. I’ve seen this directly lead to conversations that are relevant to development being buried in Github. Take for example your and Whitehall’s conversation(s) with Kyo that I doubt anyone here has ever seen since they aren’t even commenting on the Github. Yes, Github emails are sent to the dev list, my guess is that people ignore them. On the code review issue - Kyo (or others) shouldn’t have to endlessly debate or discuss the advantages or disadvantages of this or that before simply pushing code, and pushing tests. My general rule of thumb is that there are CTR and RTC workflows and use cases for both. RTC works great when it’s possibly controversial or when you really want someone’s eyes on your code for review. However it’s also overhead that I do not believe is needed if a developer wants to push forward and scratch his or her itch, in an area of the codebase that they are working on. The codebase is factored out enough reasonably well so that people can work on things in parallel and independently. When in doubt, ask. I’m also pretty worried since anyone that looks at the Git and project history over the last year can easily see that Mike has pretty much been doing the bulk load of the pushing and code committing here. Kim’s stepped up recently as has Kyo, which is 3 people, which is great, but I’m worried about a project with a small number of active developers (really 1 major) imposing RTC - I don’t have time to look up citations but you are free to scope these out over the ASF archives. RTC on smaller projects just leads to barriers. We need to be flexible and make it inviting for at the very least, our own developers to contribute to the project, let along attracting new people. Ross was elected in December 2014, which is great, but we need to do better. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov<mailto:chris.a.mattm...@nasa.gov> WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Michael Joyce <jo...@apache.org<mailto:jo...@apache.org>> Reply-To: "dev@climate.apache.org<mailto:dev@climate.apache.org>" <dev@climate.apache.org<mailto:dev@climate.apache.org>> Date: Tuesday, May 12, 2015 at 8:55 AM To: "dev@climate.apache.org<mailto:dev@climate.apache.org>" <dev@climate.apache.org<mailto:dev@climate.apache.org>> Subject: Project Workflow Hi folks, Since this has been brought up a few times on various tickets I thought now would be a good time to go over our project workflow and make sure it's working for us. A general overview of the workflow that we use is available at [1]. A brief overview is that: - ALL changes are pushed up to Github for code review before being merged. - If no issues are raised within a reasonable amount of time (usually 72 hours is what I stick with) those changes can be merged. In general, I've been quite happy with this workflow. We have a low enough throughput that this isn't overwhelming and I think it's great that we can get together and review each other's code. I know I appreciate the opportunity for people to find issues with my code before we merge it. I think it would be beneficial to flesh out the docs a bit more on the workflow (for instance, how to run tests should be included in there, how long to wait for a merge, etc.). So community, what do we think of our workflow? Do we like it so far? Is it working for us? Are there pain points? What don't we like? Etc. [1] https://cwiki.apache.org/confluence/display/CLIMATE/Developer+Getting+Star ted+Guide -- Jimmy
