On Mon, Feb 10, 2014 at 5:36 AM, Jim Jagielski <j...@jagunet.com> wrote:
> 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.
Fair point. Thanks for making it.
Shifting the window regularly might conceivably compensate, but it would be
inconvenient and chaotic, disadvantaging everyone except for the most highly
engaged inner core of developers.
It may be that voting times under 24 hours are inherently unstable and
difficult to implement fairly.
> 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.
I see a predictable schedule as the key attribute which allows the shorter
time. IMO it's OK to for a community to ask people to make time on a specific
day so long as that day is known well in advance.
But I am concerned once again about what happens when a vote fails. If
there's another vote held right away, to my mind it would *also* have to be
predictably scheduled in order to justify the shorter window. I can imagine
two options:
* Only one vote per week. If it fails, the cycle is missed and we're on to
the next.
* A series of daily votes each beginning at the same hour, until one passes.
Possibly each release cycle could have a max of two or three votes.
Marvin Humphrey
