[X] +1 CTR with documentation guidelines I concur with David. Thanks Anita
--- David Jencks <[EMAIL PROTECTED]> wrote: > > [X] +1 CTR with documentation guidelines > > I'm worried that we will not maintain enough awareness of each others > > work, and think we all need to be very vigilant. I agree with Joe > that we need to review how we are doing in a reasonable amount of > time (2-3 months, less if there are obvious problems) > > thanks > david jencks > > > On Sep 10, 2006, at 9:23 PM, 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 > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
