[X] +1 CTR with documentation guidelines
Kevan Miller wrote: >> >> This is a vote to determine the development process the Geronimo >> community wishes to use for "trunk" development. If any modifications >> are needed for a "branch" development process, then a separate vote >> will be held. >> >> All votes are important. This is a community-wide issue. Please let >> your voice be heard... >> >> Choose the development process which you think will best serve the >> Geronimo community. I'd like to limit voting to a single process, >> rather than using a poll/ranking system (i.e. 1,2,3). If a clear >> consensus does not emerge, then we'll need to refine and hold another >> vote. >> >> [ ] +1 Relaxed RTC >> [ ] +1 RTC with Lazy Consensus >> [ ] +1 CTR with documentation guidelines >> >> These development processes are summarized below: >> >> 1. Relaxed RTC >> >> Geronimo follows a Review-Then-Commit (RTC) model. Patches for new >> function are provided by developers for review and comment by their >> peers. Feedback is conducted through JIRA comments. The goal of this >> interaction is to solicit suggestions from the community and >> incorporate their feedback as appropriate. In order for a patch to be >> accepted it requires the following: >> >> * Needs to be reviewed by committers on the project. Others may >> comment but their comments are not binding. The review may, but does >> not have to, include application and testing. The goal of the review >> is to understand the technical attributes of the change as well as the >> assess other impacts to the project as a whole. >> >> * 3 +1 votes from committers on the project with no outstanding -1 votes. >> >> * Any -1 votes need to be accompanied by a reason (the parties should >> then attempt to reach a mutually agreed upon solution to the issue >> raised). >> >> * If the issues can't be resolved then the PMC can be called upon to >> settle the dispute and make a recommendation. >> >> * Issues are generally of a technical nature. However, issues may >> include other items like usability, project cohesiveness or other >> issues that impact the project as a whole. >> >> The goal of these guidelines is to facilitate timely communication as >> well as the fostering of ideas and collaboration as well as innovation. >> >> 2. RTC with Lazy Consensus >> >> Geronimo follows a Review-Then-Commit model with Lazy consensus. >> Patches for new function are provided by developers for review and >> comment by their peers. Feedback is conducted through JIRA comments. >> The goal of this interaction is to solicit suggestions from the >> community and incorporate their feedback as appropriate. A patch is >> accepted if: >> >> * 3 +1 votes from committers on the project with no outstanding -1 >> votes and no significant, ongoing discussion >> >> * 72 hours pass with no outstanding -1 votes and no significant, >> ongoing discussion. A 24 hour warning should be sent to the dev list. >> >> 3. CTR with documentation guidelines >> >> Geronimo follows a Commit-Then-Review model. There should be an >> emphasis of community communication. Community-based policing and >> persuasion will be used to remedy any problem areas. Guidelines are >> not strict dogma -- common sense should prevail. Community >> communication is the key, not a process. General guidelines are: >> >> * Non-trivial changes (and certainly potentially controversial >> changes) should be announced on the dev list. This announcement should >> be well in advance of the change being committed. The community should >> be given the opportunity to understand and discuss the proposal. >> >> * Concurrent with the commit of a significant change, the committer >> should document the change on the dev list. You should describe what >> you are doing, describe why you are doing it, and provide an overview >> of how you implemented it. >> >> --kevan >>
