Who would have a vote? PMCs only? Active Committers only? Everyone?
LieGrue, strub > Am 09.07.2017 um 03:11 schrieb David Blevins <david.blev...@gmail.com>: > > 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. >
