Dear Greg: Thanks a lot for your detailed guidance on Apache style.
I have a quick question...you mentioned that "Code from school projects should be submitted to Apache by the author and committed to the Apache repo by a CMDA committer." Do you mean that we should identify a couple of CMDA committers to be gateway (QA controller), who will take student submission, check them, and then check into Apache CMDA repo? Thanks a lot. Best regards, Jia On Wed, Jul 6, 2016 at 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 >
