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

[Sam Ottenhoff]

+1


On Fri, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130823/858cf810/attachment.html