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

classic Classic list List threaded Threaded
13 messages Options
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

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 | [hidden email] | 517-980-0228



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Sam Ottenhoff Sam Ottenhoff
Reply | Threaded
Open this post in threaded view
|

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

+1


On Fri, Aug 23, 2013 at 3:08 PM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 517-980-0228



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1

anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


Begin forwarded message:

From: Anthony Whyte <[hidden email]>
Date: August 23, 2013 3:08:23 PM EDT
To: sakai2-tcc Committee <[hidden email]>
Subject: PROPOSAL: switch to lazy consensus when considering community release proposals (VOTE)

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 | [hidden email] | 517-980-0228




_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Berg, Alan Berg, Alan
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1

Anthony Whyte <[hidden email]> 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 | [hidden email] | 517-980-0228



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1


On Sat, Aug 24, 2013 at 5:08 AM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 517-980-0228



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1.

/Chuck

On Aug 23, 2013, at 3:08 PM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 517-980-0228


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Aaron Zeckoski-3 Aaron Zeckoski-3
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1
-AZ

On Fri, Aug 23, 2013 at 3:08 PM, Anthony Whyte <[hidden email]> 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 |
> [hidden email] | 517-980-0228
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Matthew Buckett-2 Matthew Buckett-2
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1

On 23 August 2013 20:08, Anthony Whyte <[hidden email]> 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 |
> [hidden email] | 517-980-0228
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
  Matthew Buckett, VLE Developer, IT Services, University of Oxford
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
May, Megan Marie-2 May, Megan Marie-2
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Aaron Zeckoski-3
+1

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Aaron Zeckoski
Sent: Friday, August 23, 2013 9:31 PM
To: Anthony Whyte
Cc: sakai2-tcc Committee
Subject: Re: [sakai2-tcc] PROPOSAL: switch to lazy consensus when considering community release proposals (VOTE)

+1
-AZ

On Fri, Aug 23, 2013 at 3:08 PM, Anthony Whyte <[hidden email]> 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 |
> [hidden email] | 517-980-0228
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>



--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile _______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Seth Theriault Seth Theriault
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1.

Seth
_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

[sakai2-tcc] PROPOSAL: switch to lazy consensus . . . release proposals (VOTING ENDS TUES 27 AUG)

In reply to this post by Anthony Whyte
Voting on the lazy consensus proposal ends on tomorrow, Tuesday, 27 Aug 2013, 23:59 UTC.  For those who have yet to vote please do so now.

Votes so far [1]:

In favor = 9
Opposed = 0
Abstained = 0


Cheers,

Anth



anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


Begin forwarded message:

From: Anthony Whyte <[hidden email]>
Date: August 23, 2013 3:08:23 PM EDT
To: sakai2-tcc Committee <[hidden email]>
Subject: PROPOSAL: switch to lazy consensus when considering community release proposals (VOTE)

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 | [hidden email] | 517-980-0228




_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: [sakai2-tcc] PROPOSAL: switch to lazy consensus . . . release proposals (VOTING ENDS TUES 27 AUG)

+1

I guess I was just being lazy. :-)

Thanks,
-Noah

On Aug 26, 2013, at 11:31 AM, Anthony Whyte wrote:

Voting on the lazy consensus proposal ends on tomorrow, Tuesday, 27 Aug 2013, 23:59 UTC.  For those who have yet to vote please do so now.

Votes so far [1]:

In favor = 9
Opposed = 0
Abstained = 0


Cheers,

Anth



anthony whyte | its and mlibrary | university of michigan | [hidden email] | 517-980-0228


Begin forwarded message:

From: Anthony Whyte <[hidden email]>
Date: August 23, 2013 3:08:23 PM EDT
To: sakai2-tcc Committee <[hidden email]>
Subject: PROPOSAL: switch to lazy consensus when considering community release proposals (VOTE)

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 | [hidden email] | 517-980-0228



_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc


_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
Kirschner, Beth Kirschner, Beth
Reply | Threaded
Open this post in threaded view
|

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

In reply to this post by Anthony Whyte
+1

On Aug 23, 2013, at 3:08 PM, Anthony Whyte <[hidden email]> 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 | [hidden email] | 517-980-0228
>
>
> _______________________________________________
> sakai2-tcc mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

_______________________________________________
sakai2-tcc mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc