community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@odoko.co.uk>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 08:22:39 GMT


On Sun, Feb 9, 2014, at 06:40 AM, Marvin Humphrey wrote:
> On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly
> <stephen.alan.connolly@gmail.com> wrote:
> > 72h for a vote is not a hard and fast rule (you just need a good reason for
> > why you are going shorter and from what I have seen, the board would
> > probably be ok as long as protections are put in place to safeguard the
> > community)
> 
> By now, I think that we've demonstrated in this thread that scheduled
> votes with a small window (12-24 hours) are practical.

Have we?

I don't believe anyone has expressed the real justification for a 72hr
window, which is to enable the vote to be *inclusive*. That is,
inclusive of people who don't live in the same timezone, and who perhaps
don't work on the codebase full time.

Yes, a 12hr window might make it possible for everyone to have at least
4 waking hours in that window, but what if that is your 4hrs of taking
your kids to school, or cooking dinner for the family. Or if they
contribute in their spare time, and that 4hrs is whilst they are at
work. If the project chooses that particular 12hr window as a fixed
thing, it effectively excludes you from the vote.

I am in no way attempting to argue that 72hrs votes is the only way to
achieve this particular aim, but I do not consider this issue as
addressed in any way in this thread yet. So:

If we are going to shorten release vote durations, how do we ensure
inclusivity, both of current, and potential future contributors,
irrespective of timezone, work pattern, etc?

Upayavira

Mime
View raw message