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

[Aaron Zeckoski]

+1
-AZ

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
>



-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile