geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: [VOTE] Geronimo Development Process
Date Tue, 12 Sep 2006 08:12:29 GMT
[X] +1 CTR with documentation guidelines

I agree with Joe that we need to work hard at this for it to work and 
should review its effectiveness in a few months.

Regards,
John

Joe Bohn wrote:
> > [X] +1 CTR with documentation guidelines
>
> We'll have to work extra hard to ensure that we hold each other to the 
> communication standard ... but I think if we are diligent then this 
> makes the most sense.
>
> If the change is approved, I also recommend that we hold a public 
> review of how we feel it is working after some reasonable amount of 
> time (perhaps 2-3 months) to ensure that we're not drifting back into 
> old habits.
>
> Joe
>
> 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
>>
>>
>


Mime
View raw message