The Apache Geode project has built up a development process and community standards since its initial start as an Apache podling in 2014 with the purpose of releasing software of the highest quality developed by engineers who believe in the project and its future. Our DOD (Definition of Done) may be sparse and loose, but it captures some of the most important points that have been discussed on the dev-list and agreed upon by this community. Its essence is a focus on quality, both for users of Geode and developers who will contribute and maintain the code base.
Our DOD [1] includes the following on developing code to be released: CONTINUOUS DEVELOPMENT ACTIVITIES + Design reviewed on Wiki, especially for larger features + Implemented according to specification in the ticket + Unit tested + Integration tested + Public/ Peer-reviewed + Merged into 'develop' + JIRA Ticket marked 'resolved' All committers must understand and follow our "development process and community standards" [2] as discussed on the dev-list or captured on the Apache Geode Wiki. Contributors who hope to actively contribute must learn and follow this process. It's the responsibility of all committers to help educate and guide these contributors in both our process and Code of Conduct [3]. Everyone should be encouraged to ask questions and discuss how we can best deliver high-quality software that will be easy to maintain by all Apache Geode developers in the years to come. Quality impassioned, Kirk Lund [1] https://cwiki.apache.org/confluence/display/GEODE/Definition+of+Done [2] https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer [3] https://cwiki.apache.org/confluence/display/GEODE/Code+of+Conduct
