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

[Anthony Whyte]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130823/5205a2ff/attachment.html