+1 for CTR which I believe is accurately summarized in its most common
manifestation by Kevan's #1.
Joe
Kevan Miller wrote:
>
> On Aug 22, 2006, at 7:02 PM, Rodent of Unusual Size wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Apache Geronimo has been operating mostly under the
>> Review-Then-Commit model for a couple of months now,
>> and I think the issues the change was intended to
>> highlight have been .. well, highlighted.
>>
>> How do people feel about the idea of switching back
>> to Commit-Then-Review at this point?
>
>
> I'm certainly in favor of switching back. However, RTC has put an
> improved focus on communication within the community. I definitely want
> that to continue.
>
> Possible options would include:
>
> 1) Follow CTR. Document best practices and use community-based
> persuasion to keep things working well.
> 2) Follow CTR. Follow a strict procedure for documenting enhancements.
> 2) Follow RTC. Relax the reviewed/merged/tested aspect of RTC
> 3) Follow RTC. Institue a lazy consensus policy
> 4) 2 & 3
> 5) etc.
>
> IMO, 1) is the way a healthy community should be operating and I think
> that's the process we should be following.
>
> The best practices/guidelines should not be strict dogma -- common
> sense should prevail. It's communication that's important, not process.
> Guidelines are something along the lines of:
>
> 1) For larger changes (or potentially controversial changes), announce
> your intentions. Give the community an indication of what you're
> planning. You should allow enough time (and detail) to allow the
> community to understand and discuss.
> 2) Before you commit your changes, document your change. Describe what
> you are doing, why you are doing it, and provide an overview of how you
> did it (or a roadmap on how you plan on doing it).
>
> --kevan
>
>
|