I can see why cutting the time window might lead to a faster release cadence, but what I don’t get is why this is a desirable goal. Generally speaking, we try to encourage users to get involved in development, ostensibly by vetting release candidates as a zeroth order thing they can do to help the project.
The net effect of reducing opportunities for user participation in the release process would lead me to guess that the opposite flow will happen- that surplussed users will stop following dev and go back to the user lists. If I’m right, then why is this a good and desirable effect for an Apache project? On Feb 10, 2014, at 3:30 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > On Monday, 10 February 2014, Upayavira <u...@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.conno...@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
