+1 Your expanded description of the proposed short release vote process addresses all of my concerns, thanks for taking the time to expand on this further.
I think that perhaps saying I am unavailable for the vote but want to vote should not necessarily be an automatic -1 and perhaps be a 0 instead. 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 and a PMC may not want certain peoples expressed intention to vote at some point in the future to block the ability to move ahead with the release. However I see this as being something each project would decide upon, smaller projects may want it to be a -1 while a larger project may want it to either be a 0 or not count as a vote. Also I think that projects will need to have some mechanism to say that certain releases will still be subject to the longer 72hr vote window regardless of whether they normally use a shorter window e.g. those that include known breaking changes or integrate major feature branches. In general I think it is important to emphasise as you have done that all aspects of this should be discussed and tailored on a per-project basis to account for the PMC and community of specific projects. Rob On 10/02/2014 10:35, "Stephen Connolly" <stephen.alan.conno...@gmail.com> wrote: >Well I see this as something that a PMC wanting to move faster would have >to weigh up and justify to the board. > >What I would like to see come out of this debate is a set of concerns that >a PMC should find a way to address before they start a fast cadence >process... > >I would expect that a proposed fast cadence process would have the support >of a significant majority of both the PMC and committers. > >I would expect that a proposed fast cadence process would have a mechanism >whereby interested parties could signal that they want to vote and will >need an additional time window to have the opportunity... to my mind, such >a signal would count as a -1 vote pending the actual vote. > >I would expect that a short window vote would only be allowed to proceed >if >there are at least 3 +1 votes and no -1 votes... if there are -1 votes I >would expect the vote to have to go to 72h > >Thus if I know there will be a vote tomorrow, but I will be out of >communication due to a trans-pacific flight say, I could notify my intent >to vote... that gets treated as a -1 until I actually cast my vote... thus >the 12h shortcut is "vetoed" until my vote is cast. > >Things go wrong when I arrive at my destination, and it is 3 days before >they return my laptop and let me connect to the outside world... in the >interim, 3 other PMC members have voted +1 and the release went ahead >after >72h with 3x+1 and my -1 > >That is how I could see a short vote working for a scheduled release >process... > >It would me more that the PMC says "as long as everyone is happy with >running short releases, we will make short releases... but if anyone yells >'stall the ball' then it's a 72h vote until they say 'nah it's grand go >ahead'... and any contentious votes have to go 72h anyway" > > > > >On 10 February 2014 09:52, Rob Vesse <rve...@dotnetrdf.org> wrote: > >> Realistically I have rarely been involved in a project where the vote >> comes out of the blue. Projects have typically already discussed >>whether >> to move ahead with a release on the dev list in advance of the vote so >> I've always known the vote was coming. While any project member can >> propose a release candidate and call a vote I'd expect a well managed >> project to do some level of advance coordination on this. >> >> However regardless of whether the vote is scheduled/known in advance or >> not the fact still remains that the window is very short. It makes the >> assumption that the schedules of the people voting are regular which is >> almost certainly untrue, the amount of time people can give to a project >> varies over time due to everyone's unique personal circumstances. There >> are also various ways I could imagine completely missing a 12hr voting >> window regardless of timezone and usual availability in the scheduled >> window e.g. being on a long haul flight with no internet access (or >>costly >> internet access). >> >> It also assumes that all a reviewer does is the basics of checking >> signatures, LICENSE, NOTICE and builds. What about people who already >> carry out more substantial reviewing? e.g. running the release >>candidates >> against their companies internal products. This is a process that may >> take substantial time and potentially involve coordinating with various >> parts of a reviewers work organisation that the reviewer may have no >> control over how long it takes for this to happen. Now maybe if an >> organisation is already doing internal builds against SNAPSHOTs and >> keeping close tabs on development this issue goes away but perhaps I >>work >> in an organisation that does not have sufficient infrastructure to >>support >> doing this on a regular basis, management refuses to use development >> builds etc. >> >> Certainly I agree that there are things that can be done to make parts >>of >> the review process much easier on reviewers e.g. tools for automatically >> checking signatures, comparing source distributions with the VCS tags >>etc. >> but they don't necessarily solve all the issues. >> >> The 12hr window idea also assumes that there will be no contention over >> the release candidate and that the person who is acting at the release >> manager is able to be awake & accessible for the entire 12hr window to >> take account of any issues raised and cancel/release as appropriate at >>the >> end of the window. >> >> The basic issue here is ultimately one of volunteer time, even if I knew >> that the vote was always coming at the same time each >>week/month/arbitrary >> interval there is no way that I could always guarantee I had the time to >> review it given only a 12hr window. So to repeat Upayavira's point I >>end >> up being excluded from the votes, maybe that is not the end of the world >> if the next vote is only a week away but it ultimately removes the >> flexibility and inclusiveness that the current 72hr window gives me. >> >> >> Rob >> >> >> On 10/02/2014 08:30, "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 >> >> >> >> >>
