We’d encourage everyone to vote, but it would be only committers who have binding votes.
On your offline feedback about the “Immediate 3 +1s and no -1s” option, I had added that in hopes that would “sell” the idea and make RTC more palatable. It would addresses the “it will slow us down” issue. What could we do to refine the idea? Throwing out some options, but let me know if you see others: Option 1: reduce the votes required - Immediate 2 +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. Option 2: add a slight delay - 3 +1 votes from committers on the project with no outstanding -1 votes and no ongoing discussion. 24 hour vote period is required to ensure space for minimum participation. Option 3: both option 1 and 2 - 2 +1 votes from committers on the project with no outstanding -1 votes and no ongoing discussion. 24 hour vote period is required to ensure space for minimum participation. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com > On Jul 9, 2017, at 1:40 AM, Mark Struberg <strub...@yahoo.de.INVALID> wrote: > > 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. >> >
