community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: How can we support a faster release cadence?
Date Mon, 10 Feb 2014 08:30:51 GMT
On Monday, 10 February 2014, Upayavira <uv@odoko.co.uk> wrote:

>
>
> 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 <javascript:;>> 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.


But this is a *scheduled* vote... If you know that it is something you
*want* to have a chance to vote on, you have sufficient time to ensure the
vote is extended in order for you tiger your say.

IMHO 72h is needed *when you don't know that there will be a vote*... This
would be a different case... Though I ack that I had only thought this and
not articulated it prior


> 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
>


-- 
Sent from my phone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message