Ok, how would this look as a proposal? Note this is not a vote, we are still in discussion. Do suggest changes.
Whatever we come up with, I’ll swing it by the Board before we vote so we don’t feel we need to argue the rules. Let’s focus primarily on what we want to do. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Discussion Before Action - New features - Significant changes - Backwards incompatable changes To avoid excessive vetos in the RTC process, discussion prior to coding is encouraged for the above situations. # RTC with Lazy Consensus Changes should occur in a fork on Github. A Github Pull Requests (PR) should be submitted to the dev list for review. The email to the dev list should stand on its own and use a descriptive subject and contain a complete description in the body. The body must contain a link to the PR. The following is an example of an acceptable dev list PR submission: Subject: [PR] AutoConfig::firstMatching sorting issue with java 8 Fix the sorting issue, by removing the sorting operation. We are not interested in the order of the elements, but only in the smallest element. Two improvements: 1. Do not unnecessary allocate a new array list 2. Collections.min() is O(n) vs O(nLog(n) for sort() (well without counting indexOf() in the comparator) https://github.com/apache/tomee/pull/84 The following email subjects should be discouraged as they drive discussion off of the list from the very start. Subject: [PR] https://github.com/apache/tomee/pull/84 Subject: [PR] #84 Subject: [PR] https://issues.apache.org/jira/browse/TOMEE-2085 Subject: [PR] TOMEE-2085 Subject: [PR] Fixed TOMEE-2085 PR numbers and JIRA ids are allowed in the subject, but cannot be the subject exclussively. PR numbers and JIRA ids are allowed in the body, but cannot be the body exclussively. Reviewers are not required to read the Gitub Comments nor the JIRA Comments. The dev list is considered the only mandatory source of truth. Answers of "read my comment in the PR" or "read my comment in the JIRA" are not acceptable means to veto or vote in a code review. Vetos that cannot be resolved without reading comments off the dev list are non-binding. A PR submitted to the dev list is considered approved if any of the two conditions are met: - Immediate 3 +1 votes from committers on the project with no outstanding -1 votes and no ongoing discussion. No 72 hour vote period is required to intentionally to encourage obtaining speed throught active list participation. - Lazy 72 hours pass with no outstanding -1 votes and no ongoing discussion. A committer cannot vote on his or her own PR. A 24 hour warning email, "I will commit this tomorrow if no one objects" is considered best practice for larger changes.
