+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
