Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines On 9/10/06, Kevan Miller [EMAIL PROTECTED] 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 -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines Jan
Re: [VOTE] Geronimo Development Process
Keep the votes coming... The vote has been active for 2 1/2 days. I'll plan on giving it 2 more days. Unless there are objections, I'll end the vote on Friday, Sept 15 at 9 AM EDT. --kevan 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
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines -dain
Re: [VOTE] Geronimo Development Process
[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
Re: [VOTE] Geronimo Development Process
On Sep 11, 2006, at 9:27 PM, Matt Hogstrom wrote: On Sep 11, 2006, at 10:17 PM, David Blevins wrote: [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. Since this is a VOTE thread I think the vote needs to be unqualified. So the +1 is for 3 as stated or it should be a -1 with qualifications. Otherwise the vote gets very hard to tally. Sorry if I wasn't clear. My vote is for 3 without qualifications. Was simply adding (unsuccessfully) that my proposal didn't make it into the list of options. -David 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 Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Geronimo Development Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote: 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. - -1 on that last sentence. You don't hold discussions in JIRA.. * 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). - -1 on the parenthetical clause. It would be nice, but 'should' is too strong I think. That's calling for someone who vetoed a change for technical reasons to help resolve his own veto whether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. - -1. A veto is a veto. The above implies that the PMC can override a valid veto. It cannot. 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. - -1 on the JIRA means again. 3. CTR with documentation guidelines * 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. It's useful for historical reasons for most of that to be in the commit log. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6Ej sIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4 /XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhO qTKykt6U02U= =rwwV -END PGP SIGNATURE-
Re: [VOTE] Geronimo Development Process
On Sep 12, 2006, at 10:56 AM, Rodent of Unusual Size wrote:-BEGIN PGP SIGNED MESSAGE-Hash: SHA1Kevan Miller wrote: 1. Relaxed RTCGeronimo 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. - -1 on that last sentence. You don't hold discussions in JIRA..Why? This to me is the ideal place to append comments. If a contributer opened a JIRA and attached a patch, I'd expect comments on the patch to be appended to the JIRA. This is the most ideal place to discuss details of a particular work item. * 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). - -1 on the parenthetical clause. It would be nice, but 'should'is too strong I think. That's calling for someone who vetoeda change for technical reasons to help resolve his own vetowhether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. - -1. A veto is a veto. The above implies that the PMC canoverride a valid veto. It cannot. 2. RTC with Lazy ConsensusGeronimo 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. - -1 on the JIRA means again. 3. CTR with documentation guidelines* 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. It's useful for historical reasons for most of that to bein the commit log.- --#ken P-)}Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/Author, developer, opinionist http://Apache-Server.Com/"Millennium hand and shrimp!"-BEGIN PGP SIGNATURE-Version: GnuPG v1.2.4 (MingW32)Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6EjsIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4/XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhOqTKykt6U02U==rwwV-END PGP SIGNATURE- -sachin
Re: [VOTE] Geronimo Development Process
On Sep 12, 2006, at 4:26 AM, David Blevins wrote: On Sep 11, 2006, at 9:27 PM, Matt Hogstrom wrote: On Sep 11, 2006, at 10:17 PM, David Blevins wrote: [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. Since this is a VOTE thread I think the vote needs to be unqualified. So the +1 is for 3 as stated or it should be a -1 with qualifications. Otherwise the vote gets very hard to tally. Sorry if I wasn't clear. My vote is for 3 without qualifications. Was simply adding (unsuccessfully) that my proposal didn't make it into the list of options. David, Apologies if I failed to capture the proposal, properly. Was hoping the SUMMARY thread would iron out any mis-interpretations... I haven't re-read the thread, however my recollection was that the process wasn't being interpreted as discretionary... While there may have been a fuzzy line on when CTR or RTC w/ lazy consensus would be applied, it seemed that there would be cases where RTC w/ lazy consensus was expected/required... --kevan
Re: [VOTE] Geronimo Development Process
Hi Ken, General question: Why is it bad to hold a discussion in a JIRA since the whole of the discussion is archived in the issues mailing list. Seems like the JIRA is the ideal place to hold the discussion because its archived and organized for all to follow. If the JIRA magically or mysteriously disappears then we still have the issues mailing list log to look to. If we hold the discussion about a JIRA in the mail list it seems to me we'd have two places to look at to understand the JIRA, and that IMO is bad. TTFN, -bd- On Sep 12, 2006, at 8:56 AM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevan Miller wrote: 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. - -1 on that last sentence. You don't hold discussions in JIRA.. * 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). - -1 on the parenthetical clause. It would be nice, but 'should' is too strong I think. That's calling for someone who vetoed a change for technical reasons to help resolve his own veto whether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. - -1. A veto is a veto. The above implies that the PMC can override a valid veto. It cannot. 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. - -1 on the JIRA means again. 3. CTR with documentation guidelines * 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. It's useful for historical reasons for most of that to be in the commit log. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6Ej sIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4 /XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhO qTKykt6U02U= =rwwV -END PGP SIGNATURE-
Re: [VOTE] Geronimo Development Process
Ken,Understand your concerns about communication occurring on the mailing lists. I think these can be addressed in the proposals. I don't think they fundamentally change the nature of the proposals. Do you agree? If we're uncomfortable with the vote, as stands. I can respin...Finally, would prefer not to turn this vote thread into a discussion. The proposals were discussed on the mailing list and summarized in the "[SUMMARY] Proposed Geronimo Development Processes" thread. Perhaps we can move there?--kevanOn Sep 12, 2006, at 10:56 AM, Rodent of Unusual Size wrote:-BEGIN PGP SIGNED MESSAGE-Hash: SHA1Kevan Miller wrote: 1. Relaxed RTCGeronimo 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. - -1 on that last sentence. You don't hold discussions in JIRA.. * 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). - -1 on the parenthetical clause. It would be nice, but 'should'is too strong I think. That's calling for someone who vetoeda change for technical reasons to help resolve his own vetowhether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. - -1. A veto is a veto. The above implies that the PMC canoverride a valid veto. It cannot. 2. RTC with Lazy ConsensusGeronimo 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. - -1 on the JIRA means again. 3. CTR with documentation guidelines* 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. It's useful for historical reasons for most of that to bein the commit log.- --#ken P-)}Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/Author, developer, opinionist http://Apache-Server.Com/"Millennium hand and shrimp!"-BEGIN PGP SIGNATURE-Version: GnuPG v1.2.4 (MingW32)Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6EjsIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4/XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhOqTKykt6U02U==rwwV-END PGP SIGNATURE-
Re: [VOTE] Geronimo Development Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sachin Patel wrote: -1 on that last sentence. You don't hold discussions in JIRA.. Why? This to me is the ideal place to append comments. If a contributer opened a JIRA and attached a patch, I'd expect comments on the patch to be appended to the JIRA. This is the most ideal place to discuss details of a particular work item. Those -1s are opinions, not vetoes. Here are the reasons I feel this way: 1. It's a departure. That's not bad in itself, but it can violate the Principle of Least Astonishment among other things. Development discussions take place on the publicly accessible and archived development mailing list. Anyone in the least familiar with anything at Apache is going to look at those archives -- and probably be baffled by the absence of discussion. 2. It sharply compartmentalises the flow of ideas and participation. Look at any discussion thread we have. Selective quoting is the norm, and pulling in excerpts from other threads is not uncommon. Do you see that happening in JIRA comments? I don't. 3. It adds an axis of complication relative to other projects. With the mailing list, anyone can get involved, even when they're not online, using the same tool they use for all other discussions. They have to use a different tool -- a browser -- and be online in order to use JIRA. Perhaps they even need to sign onto JIRA in order to not be anonymous (not sure). Tracking something down is no longer a matter of looking at the repository and the dev list; it's the repository, the dev list (maybe!), and JIRA (or its list archive). 4. It limits the ability to fork. So much context would be stored in the bowels of a proprietary package that forking would be made much more difficult. But that's all IMHO. If the project wants to go that way, no problem -- but doing so carries the burden of proving that it's a better/more efficient/more accessible solution than the legacy methods. JIRA is not a hammer, and project interactions are not nails. :-) - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRQbhCZrNPMCpn3XdAQKH9wP9FjLjyinlKF1jIw/IWpF0RvkFrepUzEit LEgvx4GZ82+iFJSmD4SHrHBmW/c+T+lThZ78EU1KBwFdYnZsVgRJD9eYEgmi1BYD yW0QWvxuSZ3KcFiuwM7GQrLQtHHzdJgaZn8NbISOD4WSDR7Bp00rXxCJfa9RG65S R72C8Y9tzis= =FrXI -END PGP SIGNATURE-
Re: [VOTE] Geronimo Development Process
On Sep 12, 2006, at 4:26 AM, David Blevins wrote: Sorry if I wasn't clear. My vote is for 3 without qualifications. Was simply adding (unsuccessfully) that my proposal didn't make it into the list of options. I didn't mean to come across too strongly. I was noticing on this vote and others that people are +1 ing with comments. So far its not an issue but I think this leaves room for confusion later on. Thanks Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Geronimo Development Process
On Sep 12, 2006, at 7:56 AM, Rodent of Unusual Size wrote: 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. - -1 on that last sentence. You don't hold discussions in JIRA.. FYI, all JIRA changes turn into emails to the dev list. And based on that fact, I don't see any reason why JIRA can or should not be used to facilitate vote-related comments... but when it comes to full blow discussion I think that JIRA comments are not the right place. --jason
Re: [VOTE] Geronimo Development Process
I hadn't really thought about this issue so here is my 2c. The only potential issue I see is that I (and others) often see and issue and reply to the e-mail generated from JIRA and do not automatically go into JIRA to add the comments. So, those comments are in the e-mail and are not in the JIRA. At best, JIRA will be a possibly (perhaps most likely) partial record of the activity and e- mail will be the full record. I'm fine with that. I'm against mandating the use of JIRA or chastising people for not following the process. For instance, for some people who travel and do their e-mail on a plane they would have to wait for JIRA to be available to post their comments which I think puts an undo burden on the community member. So, I think as a convention of mostly complete JIRA is fine, as a project mandate I think I would agree with Ken that its too heavy. On Sep 12, 2006, at 3:41 PM, Jason Dillon wrote: On Sep 12, 2006, at 7:56 AM, Rodent of Unusual Size wrote: 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. - -1 on that last sentence. You don't hold discussions in JIRA.. FYI, all JIRA changes turn into emails to the dev list. And based on that fact, I don't see any reason why JIRA can or should not be used to facilitate vote-related comments... but when it comes to full blow discussion I think that JIRA comments are not the right place. --jason Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines Regards, Alan
Re: [VOTE] Geronimo Development Process
On Sep 12, 2006, at 8:06 AM, Kevan Miller wrote: On Sep 12, 2006, at 4:26 AM, David Blevins wrote: On Sep 11, 2006, at 9:27 PM, Matt Hogstrom wrote: On Sep 11, 2006, at 10:17 PM, David Blevins wrote: [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. Since this is a VOTE thread I think the vote needs to be unqualified. So the +1 is for 3 as stated or it should be a -1 with qualifications. Otherwise the vote gets very hard to tally. Sorry if I wasn't clear. My vote is for 3 without qualifications. Was simply adding (unsuccessfully) that my proposal didn't make it into the list of options. David, Apologies if I failed to capture the proposal, properly. Was hoping the SUMMARY thread would iron out any mis-interpretations... No, it's my bad. I didn't get my feedback into the SUMMARY. Option 3 is a fine starting place and I think it's AOK to evolve a group sense of where we'd like to encourage (not require) the use of RTC w/ lazy consensus as one possible means to communicate change (the documentation guidelines are also fine). -David
Re: [VOTE] Geronimo Development Process
[ +1] CTR with documentation guidelines 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
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines Jacek On 9/11/06, Kevan Miller [EMAIL PROTECTED] 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 -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Geronimo Development Process
On 9/11/06, Kevan Miller [EMAIL PROTECTED] wrote: [ ] +1 Relaxed RTC[ ] +1 RTC with Lazy Consensus[X] +1 CTR with documentation guidelines-- Cheers,Guillaume Nodet
Re: [VOTE] Geronimo Development Process
[ ] +1 Relaxed RTC [ ] +1 RTC with Lazy Consensus [X ] +1 CTR with documentation guidelines TTFN, -bd-
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines
Re: [VOTE] Geronimo Development Process
[ X ] +1 CTR with documentation guidelines
Re: [VOTE] Geronimo Development Process
[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
Re: [VOTE] Geronimo Development Process
[ ] +1 Relaxed RTC [ ] +1 RTC with Lazy Consensus [X] +1 CTR with documentation guidelines Cheers! Hernan 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
Re: [VOTE] Geronimo Development Process
[X] +1 CTR with documentation guidelines 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
Re: [VOTE] Geronimo Development Process
My non-binding vote - [X] +1 CTR with documentation guidelines Cheers Prasad On 9/10/06, Kevan Miller [EMAIL PROTECTED] 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
Re: [VOTE] Geronimo Development Process
+1 CTR with documentation guidelines --jason On Sep 10, 2006, at 6: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
Re: [VOTE] Geronimo Development Process
[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
Re: [VOTE] Geronimo Development Process
+1 CTR with documentation guidelines Thanks, Gianny
Re: [VOTE] Geronimo Development Process
[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
Re: [VOTE] Geronimo Development Process
On Sep 11, 2006, at 3:45 PM, David Jencks 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) [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. -David 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
Re: [VOTE] Geronimo Development Process
On Sep 11, 2006, at 10:17 PM, David Blevins wrote: [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. Since this is a VOTE thread I think the vote needs to be unqualified. So the +1 is for 3 as stated or it should be a -1 with qualifications. Otherwise the vote gets very hard to tally. 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 Matt Hogstrom [EMAIL PROTECTED]
Re: [VOTE] Geronimo Development Process
What, no write ins? I vote Donald Duck for president. --jason On Sep 11, 2006, at 9:27 PM, Matt Hogstrom wrote: On Sep 11, 2006, at 10:17 PM, David Blevins wrote: [X] +1 CTR with documentation guidelines And to clarify, my proposal was actual for CTR w/optional RTC with Lazy Consensus, where we as a community agree RTC with Lazy Consensus is encouraged in the following situations: On Aug 23, 2006, at 1:14 PM, David Blevins wrote: I'm inclined to say at your discretion where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline fixes to a stable branch This is still my preferred verbiage. Since this is a VOTE thread I think the vote needs to be unqualified. So the +1 is for 3 as stated or it should be a -1 with qualifications. Otherwise the vote gets very hard to tally. 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 Matt Hogstrom [EMAIL PROTECTED]
[VOTE] Geronimo Development Process
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
Re: [VOTE] Geronimo Development Process
[ +1] CTR with documentation guidelines thanks, -- dims On 9/10/06, Kevan Miller [EMAIL PROTECTED] 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 -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
