[sakai2-tcc] PROPOSAL: switch to lazy consensus when considering community release proposals (VOTE)

[Beth Kirschner]

+1

On Aug 23, 2013, at 3:08 PM, Anthony Whyte <arwhyte at umich.edu> wrote:

> It has been observed that roll call votes on community release proposals add little value to the release process, especially so given the number of TCC/PMC members actively engaged in release work.  In addition, the voting period, which can range between three and five calendar days depending on when a vote is called, often delay final release preparations without any discernible benefits accruing to either contributors engaged in release work or community members waiting for the distributions we produce.
> 
> The chair proposes that we cease requiring a formal roll call vote for approving a release and instead switch to "lazy consensus" approval as outlined in the proposal below.  In short, those actively engaged in final release preparations can assume community support unless a valid objection is raised by a PMC member or committer within a specified (and expedited) time period.
>   
> Community members are free to indicate support for a proposal with a reply of +1; however, recall that under lazy consensus such votes--and the associated email traffic--are superfluous since under the terms of "lazy consensus" silence equals consent.
> 
> 
> Proposal
> 
> 1. Proposals for issuing a community release will operate under the "lazy consensus" model.
> 
> 2. Release proposals are considered public statements of intent.  The sakai-dev mailing list will serve as the designated channel for all community-release proposals, discussion and objections.
> 
> 3. It is expected that release proposals will be authored by contributors who are both active in release work and best informed as to the status of the proposed release.
> 
> 4. Release proposals will provide an explicit date when the release work will commence and provide a minimum 48-hour review window--measured in calendar time,
> not "working day" time--for TCC/PMC members and committers to raise a material objection before consent can be assumed (e.g., X intends to release Y commencing on date Z unless a valid objection is raised within Z - 48 hours).
> 
> 5.  Objections to a release proposal must include an explanation describing why the proposal should be rejected.  In general, objections should be sent via the sakai-dev mailing list; any objections made without an accompanying explanation or raised on lists other than sakai-dev (security issues excepted) will be ignored.  Security-related objections must NOT be raised on any public list but instead be forwarded directly to the Sakai Security Working Group for review.
> 
> 6.  Valid objections raised by TCC/PMC members or committers will block a release; objections raised by other community members will be taken under advisement but will not be considered blocking unless supported by a TCC/PMC member or committer. 
>  
> 7. Contributors engaged in release work must roll back any work associated with a valid objection.
> 
> 
> Polls open
> Voting on the question is now OPEN and will conclude no later than Tuesday, 27 August 2013, 23:59 UTC.
> 
> As a reminder, this is a public, on-list vote with a "+1" signifying approval. Per our governance documents, a -1 vote must be accompanied by a detailed explanation. A single -1 vote based on a material objection will block action. However, -1 blocking votes can be overridden by a 2/3 majority roll call vote of active TCC members.
>  
> 
> Cheers,
> 
> Anth
> 
> 
> anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228
> 
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc