[SUMMARY] Proposed Geronimo Development Processes

[Kevan Miller <ke...@gmail.com>]

Three models have been proposed for the Geronimo development process.  
I've attempted to summarize the proposals, below. Assuming that I've  
capture the essence of the proposals accurately, I'd like to put them  
to a vote.

If I've misrepresented a proposal, my apologies, and let's fix it  
here. I'd like a vote thread to be, well, a vote thread... ;-)

1. Relaxed RTC
2. RTC with Lazy Consensus
3. CTR with documentation guidelines

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 (1 of these committers  
needs to be a member of the PMC) with no outstanding -1 votes.

* Any -1 votes need to be accompanied by a reason and 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 

Re: [SUMMARY] Proposed Geronimo Development Processes

[Matt Hogstrom <ma...@hogstrom.org>]

Jason Dillon wrote:
> Thanks Kevan for the summary, I think this really helps.
> 
> More comments below inline...
> 
> On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
>> 1. Relaxed RTC
>>
>> ...
>>
>> * 3 +1 votes from committers on the project (1 of these committers 
>> needs to be a member of the PMC) with no outstanding -1 votes.
> 
> I don't think that we need a requirement of a PMC vote here.  The PMC 
> can provide enough oversight w/o a required vote.  IMO, a vote is a vote 
> is a vote... I don't put any weight over a committers vote to a PMC 
> members vote.  I value them both equally.  Forcing a PMC vote here is 
> artificial and promotes separatism rather than unity.
>

I'm fine with removing the PMC requirement.

> 
>> 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.
> 
> This feels a whole lot like common-sense for how to participate on an 
> open-source project.  In most cases, I think this is also the best model 
> to run under... though I do believe that RTC has some merit as well.
>

Common sense and decency is what I would like to see ;-)

> If it was up to me (which it isn't, but here is my opinion anyways), I 

I think everyone's input counts.

> would use a hybrid model, which would default to CTR (with emphasis on 
> common sense and communication) and for non-trivial or potentially 
> controversial changes follow the RTC with Lazy Consensus as described in 
> #2 (with the addition of inclusion of development branches or patches, 
> depending on the complexity).  I actually think that this is 
> common-sense too.
> 

I concur.

> 
> But Jason... I think you are on crack... and I want to smoke some too!
> 
> Okay, you are on your own there... just make sure you clean your pipe, 
> cause their ain't nuthing worse than a dirty ole crack pipe. :-P
> 

Your knowledge of controlled / illegal substances boggles my mind.  I'm wondering if there aren't 
dark secret times in your life where you secretly are in love with Windows as a primary OS ;-0

> --jason
> 
> 
> 

Re: [SUMMARY] Proposed Geronimo Development Processes

[David Jencks <da...@yahoo.com>]

I think the overwhelming need is that more than the author  
understands and agrees with the main thrust of a major change.  I  
think that the apply-and-test RTC requirement we've been struggling  
under has severely inhibited thorough review, but that's just my  
experience.

I'm in favor of (3) for trunk and (2) for bug-fix branches and also  
in favor of reviewing this change in a month or two to see if we are  
actually reviewing changes sufficiently and in a sufficiently timely  
manner.

thanks
david jencks



On Sep 7, 2006, at 12:59 PM, Kevan Miller wrote:

> Thanks Matt and Jason.
>
> I'll update the proposals to remove the PMC requirement from  
> Relaxed RTC.
>
> I'm also going to update to make clear that the focus of this vote  
> is trunk development. Initially, it would apply to branches, also.  
> If we feel that branches need special controls, we should handle by  
> refining our general process. I don't wan't to get hung up fixing  
> *everything*...
>
> Any other comments?
>
> More inline...
>
> On Sep 6, 2006, at 7:27 PM, Jason Dillon wrote:
>
>> Thanks Kevan for the summary, I think this really helps.
>>
>> More comments below inline...
>>
>> On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
>>> 1. Relaxed RTC
>>>
>>> ...
>>>
>>> * 3 +1 votes from committers on the project (1 of these  
>>> committers needs to be a member of the PMC) with no outstanding  
>>> -1 votes.
>>
>> I don't think that we need a requirement of a PMC vote here.  The  
>> PMC can provide enough oversight w/o a required vote.  IMO, a vote  
>> is a vote is a vote... I don't put any weight over a committers  
>> vote to a PMC members vote.  I value them both equally.  Forcing a  
>> PMC vote here is artificial and promotes separatism rather than  
>> unity.
>
> Totally agree. I almost made that change, but was consciously  
> trying *not* to edit the proposals as I pulled them out of the  
> various discussion threads.
>
>>
>>
>>> 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.
>>
>> For the most part I like this model... but only for non-trivial  
>> changes, see below.
>
> It's not bad and I think we can operate quite reasonably using  
> this. However, I don't think it's necessary. I'd prefer to see the  
> benefits of this approach handled by more up-front communication  
> using CTR. By the time something is committed, it's not much of a  
> surprise...
>
>>
>>
>>> 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.
>>
>> This feels a whole lot like common-sense for how to participate on  
>> an open-source project.  In most cases, I think this is also the  
>> best model to run under... though I do believe that RTC has some  
>> merit as well.
>>
>> If it was up to me (which it isn't, but here is my opinion  
>> anyways), I would use a hybrid model, which would default to CTR  
>> (with emphasis on common sense and communication) and for non- 
>> trivial or potentially controversial changes follow the RTC with  
>> Lazy Consensus as described in #2 (with the addition of inclusion  
>> of development branches or patches, depending on the complexity).   
>> I actually think that this is common-sense too.
>>
>> IMO... this is the best of both worlds, without being too  
>> overbearing on policy and process, leveraging the trust of the  
>> developers and fostering our community with sufficient oversight  
>> and freedom to allow real progress to be achieved.
>
> I think RTC w/ lazy consensus is always available under a CTR  
> model. However, I'd prefer it be self-imposed rather than expected.  
> I wouldn't be upset if someone didn't follow RTC for a significant  
> change. I would be upset if they failed to adequately communicate  
> and discuss with the community...
>
>>
>>  * * *
>>
>> But Jason... how do I know what is non-trivial or controversial?
>
> Jason, Perhaps it's time for a little holiday...  ;-)
>
> --kevan

Re: [SUMMARY] Proposed Geronimo Development Processes

[Kevan Miller <ke...@gmail.com>]

Thanks Matt and Jason.

I'll update the proposals to remove the PMC requirement from Relaxed  
RTC.

I'm also going to update to make clear that the focus of this vote is  
trunk development. Initially, it would apply to branches, also. If we  
feel that branches need special controls, we should handle by  
refining our general process. I don't wan't to get hung up fixing  
*everything*...

Any other comments?

More inline...

On Sep 6, 2006, at 7:27 PM, Jason Dillon wrote:

> Thanks Kevan for the summary, I think this really helps.
>
> More comments below inline...
>
> On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
>> 1. Relaxed RTC
>>
>> ...
>>
>> * 3 +1 votes from committers on the project (1 of these committers  
>> needs to be a member of the PMC) with no outstanding -1 votes.
>
> I don't think that we need a requirement of a PMC vote here.  The  
> PMC can provide enough oversight w/o a required vote.  IMO, a vote  
> is a vote is a vote... I don't put any weight over a committers  
> vote to a PMC members vote.  I value them both equally.  Forcing a  
> PMC vote here is artificial and promotes separatism rather than unity.

Totally agree. I almost made that change, but was consciously trying  
*not* to edit the proposals as I pulled them out of the various  
discussion threads.

>
>
>> 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.
>
> For the most part I like this model... but only for non-trivial  
> changes, see below.

It's not bad and I think we can operate quite reasonably using this.  
However, I don't think it's necessary. I'd prefer to see the benefits  
of this approach handled by more up-front communication using CTR. By  
the time something is committed, it's not much of a surprise...

>
>
>> 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.
>
> This feels a whole lot like common-sense for how to participate on  
> an open-source project.  In most cases, I think this is also the  
> best model to run under... though I do believe that RTC has some  
> merit as well.
>
> If it was up to me (which it isn't, but here is my opinion  
> anyways), I would use a hybrid model, which would default to CTR  
> (with emphasis on common sense and communication) and for non- 
> trivial or potentially controversial changes follow the RTC with  
> Lazy Consensus as described in #2 (with the addition of inclusion  
> of development branches or patches, depending on the complexity).   
> I actually think that this is common-sense too.
>
> IMO... this is the best of both worlds, without being too  
> overbearing on policy and process, leveraging the trust of the  
> developers and fostering our community with sufficient oversight  
> and freedom to allow real progress to be achieved.

I think RTC w/ lazy consensus is always available under a CTR model.  
However, I'd prefer it be self-imposed rather than expected. I  
wouldn't be upset if someone didn't follow RTC for a significant  
change. I would be upset if they failed to adequately communicate and  
discuss with the community...

>
>  * * *
>
> But Jason... how do I know what is non-trivial or controversial?

Jason, Perhaps it's time for a little holiday...  ;-)

--kevan

Re: [SUMMARY] Proposed Geronimo Development Processes

[Jason Dillon <ja...@planet57.com>]

Thanks Kevan for the summary, I think this really helps.

More comments below inline...

On Sep 6, 2006, at 1:34 PM, Kevan Miller wrote:
> 1. Relaxed RTC
>
> ...
>
> * 3 +1 votes from committers on the project (1 of these committers  
> needs to be a member of the PMC) with no outstanding -1 votes.

I don't think that we need a requirement of a PMC vote here.  The PMC  
can provide enough oversight w/o a required vote.  IMO, a vote is a  
vote is a vote... I don't put any weight over a committers vote to a  
PMC members vote.  I value them both equally.  Forcing a PMC vote  
here is artificial and promotes separatism rather than unity.


> 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.

For the most part I like this model... but only for non-trivial  
changes, see below.


> 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.

This feels a whole lot like common-sense for how to participate on an  
open-source project.  In most cases, I think this is also the best  
model to run under... though I do believe that RTC has some merit as  
well.

If it was up to me (which it isn't, but here is my opinion anyways),  
I would use a hybrid model, which would default to CTR (with emphasis  
on common sense and communication) and for non-trivial or potentially  
controversial changes follow the RTC with Lazy Consensus as described  
in #2 (with the addition of inclusion of development branches or  
patches, depending on the complexity).  I actually think that this is  
common-sense too.

IMO... this is the best of both worlds, without being too overbearing  
on policy and process, leveraging the trust of the developers and  
fostering our community with sufficient oversight and freedom to  
allow real progress to be achieved.

  * * *

But Jason... how do I know what is non-trivial or controversial?

Well, if you have to ask this... either common sense has failed you  
( :-P ) or you should consider your changes to be non-trivial/ 
controversial and propose the change under RTC w/LC.

But Jason... what if someone commits something that I think should  
have been RTC w/LC?

Well, you communicate that to the group, explaining why you think the  
change was non-trivial/controversial and then we work together as a  
community to resolve the issue, potentially educating the developer  
if the change should have been RTC w/LC or educating why it was not  
and if needed backing out the change and re-proposing it via RTC w/ 
LC. This too feels like common sense.

But Jason... I think you are on crack... and I want to smoke some too!

Okay, you are on your own there... just make sure you clean your  
pipe, cause their ain't nuthing worse than a dirty ole crack pipe. :-P

--jason