On Mon, Feb 10, 2014 at 1:05 PM, Upayavira <u...@odoko.co.uk> wrote: > > > On Mon, Feb 10, 2014, at 01:48 PM, Benson Margulies wrote: >> On Mon, Feb 10, 2014 at 8:36 AM, Jim Jagielski <j...@jagunet.com> wrote: >> > >> > On Feb 10, 2014, at 6:50 AM, Rob Vesse <rve...@dotnetrdf.org> wrote: >> >> With a large enough PMC likely there will be enough active people to >> >> obtain the necessary +1's in the 12hr window regardless of a few people >> >> being unavailable >> > >> > A concern is that if the same person is RM, and the vote is always >> > done at the same time (and so the 12 hour window never shifts, time- >> > wise) then the vote will *always* favor those who are in the >> > timezone of that vote. >> > >> > One reason for the 72hour rule is to ensure that no PMC >> > member feels disenfranchised... not all PMC members are in >> > the same timezone and not all PMC members should be assumed >> > to be paid to work on the code (and thus available 24/7 >> > as it were). Longer vote times handle those cases. >> > >> > PMCs are *inclusive*. The processes and procedures are >> > designed to maintain that inclusivity. >> > >> >> A PMC will only adopt this procedure if it *inclusively* decides to >> adopt this procedure. if PMC members feel excluded from the release >> decision-making process, they can bring it to a halt at the process >> level. A project can adopt a policy rotating the RM role around the >> globe. Any PMC member can add any automated test that stops the >> process if his or her testing concerns are not met. >> >> In other words, an automated process can still allow for completely >> inclusive participation. > > What you are proposing is inclusive of current PMC members, but > potentially exclusive of future PMC members. It could create a > self-selecting system that quietly excludes folks who are unfortunate > enough to live in the wrong timezone, or work the wrong hours. Any > voting mechanism needs to be sufficiently flexible to suit current and > future PMC members, regardless of timezone/etc.
A dev participates in the community, including in the care and feeding of the release infrastructure. He or she is added to the PMC. He or she can watch all the commits, and veto if one is really upsetting. He or she can add a test to the process that will stop the automated cycle if it fails to meet some desirable criterion. He or she might sleep through a vote, once. At which point, he or she can address the larger group and ask a change in the schedule. However, I agree that no schedule on earth will allow for people who contribute part time. If it takes more than 72 hours for all the PMC members to wander by, then the slow ones will be left out. So, from that point of view, we have an unsolvable dilemma here. If the time from the last commit to the release push is less than N hours, then anyone who does not routinely show up every N hours is out. Someone could commit a monster and the machine could push a release before this hypothetical person could stop in. So, I could ask, what's special about 72 hours? A 72-hour system excludes those who only have time to participate every 84 hours. Is 72-hour attention a global requirement for PMC membership? So, I could try out the following argument: if a PMC includes a diverse group of individuals who are reliably watching every N hours, can that be the release cycle, even if it's less that 72, and even if it excludes some from the release process? How about the following lateral idea: What if a community had two kinds of releases -- fast ones and slow ones. Both could be advertised to the world at large (because both would be voted on), but the advertisement would have to make clear that the fast ones are subject to revision and revocation by the slow ones. > > Upayavira
