This is great advice I recommend folks read it carefully. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Director, Information Retrieval and Data Science Group (IRDS) Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA WWW: http://irds.usc.edu/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On 7/6/16, 9:38 AM, "Greg Reddin" <[email protected]> wrote: >Hi CMDA, > >It is my goal for this project to succeed at Apache, but I think there >is a disconnect that needs to be addressed. I want to raise some of >the specific issues that I have seen that need to be addressed and >give some practical tips on how to address them. Please understand >that I don't mean to offend anyone by this message. My goal is to help >you understand what is needed to get on the right path. Please let me >know if any clarity is needed. > >First, the project seems to be too dependent on school projects. It >appears that much of the project's work and direction are decided by a >few people who are preparing for the next semester of school. The CMDA >community on the dev list do not have any visibility into these >decisions until after the fact. This may be something that makes the >project incompatible with Apache. If the project revolves around the >agenda of a few people driven by their teaching needs, it is by >definition, not a community led project. For us to succeed at Apache, >the school projects must become ancillary to the core of the project. >CMDA should be able to continue on in its own direction without >dependencies on student work that has specific requirements and >timeframes. I'll offer below some advice on how to incorporate student >projects. > >Second, code is not developed in Apache repositories. Instead it is >imported in bulk. For CMDA to be a community-driven project code must >be committed directly to the Apache repo first. If some folks need to >maintain a fork for their own uses elsewhere, including for student >projects, that's fine. But individual commits, not bulk commits need >to be taking place in Apache repos, not external ones. > >Third, decisions are not made by the community. They appear to be made >by a few people separate from the dev list and presented here after >the fact. We see meeting minutes where things have been decided and >assignments made. If I want to contribute to the Docker container, how >can I do that? If I want to contribute to improving the HTML front >ends how would I go about that? How can someone from the outside of >your core group help decide what the next step will be and contribute >code? That's the essence of the Apache Way. > >Now, here are some specific things I need to see before I can say the >project is making progress in the right direction. > >1. Code from school projects should be submitted to Apache by the >author and committed to the Apache repo by a CMDA committer. It can be >submitted through a Jira attachment, GitHub pull request, etc. > >2. Discussion regarding school projects should take place on the CMDA dev list. > >3. We must see commits of code to the Apache CMDA repository. These >are not imports of large blocks of code worked on for a long time, but >individual changes submitted one at a time directly to the Apache >project. The Apache repo must be the primary source code repository. > >4. Make decisions regarding code and project direction on the CMDA dev >list. Offlist face-to-face meetings are ok, but no decisions can be >made, only recommendations. If someone on list offers an alternative >solution to any of those recommendations it must receive equal weight >and the community decides collectively how to proceed. > >Discussions regarding project direction, features, releases, who's >working on what, etc. must take place on the CMDA dev list. > >Finally, please understand that if the project is not compatible with >the Apache style of development, it's not a failure. It would not be a >bad mark on your "resume'." It would simply mean that the project >relies on some tenets of development that are not driven by the >community. Perhaps it is better for this project to be presented to >the community after work is done, as opposed to allowing the community >broad input as to its direction. If so that's fine. But if you want to >be at Apache that broad input from the community is an absolute >requirement. > >Please let me know if any clarification of these points is needed. > >Thanks, >Greg
