Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-13 Thread Flavio Percoco

On 28/01/15 14:25 +0100, Thierry Carrez wrote:

Hi everyone,

When we first introduced the cross-project specs (specs for things that
may potentially affect all OpenStack projects, or where more convergence
is desirable), we defaulted to rather simple rules for approval:

- discuss the spec in a cross-project meeting
- let everyone +1/-1 and seek consensus



I don't mind having the TC leading the direction of cross-project
specs. However, I think giving +1/-1 to the rest of the community has
some extra value.

Besides being able to express opinion easily, it makes it clear at a
first glance what the general feeling about a spec is. Furthermore, in
very active reviews, there's a chance that some comments could be,
unintentionally, skipped due to the activity on the spec.

Having an explicit, but not definitive, vote for the community is
important and also inclusive.

Flavio


- wait for the affected PTLs to vote
- wait even more
- tally the votes (and agree a consensus is reached) during a TC meeting
- give +2/Worflow+1 to all TC members to let them push the Go button

However, the recent approval of the Log guidelines
(https://review.openstack.org/#/c/132552/) revealed that those may not
be the rules we are looking for.

Sean suggested that only the TC chair should be able to workflow+1 to
avoid accidental approval.

Doug suggested that we should use the TC voting rules (7 YES, or at
least 5 YES and more YES than NO) on those.

In yesterday's meeting, Sean suggested that TC members should still have
a -2-like veto (if there is no TC consensus on the fact that community
consensus is reached, there probably is no real consensus).

There was little time to discuss this more in yesterday's TC meeting, so
I took the action to push that discussion to the ML.

So what is it we actually want for that repository ? In a world where
Gerrit can do anything, what would you like to have ?

Personally, I want our technical community in general, and our PTLs/CPLs
in particular, to be able to record their opinion on the proposed
cross-project spec. Then, if consensus is reached, the spec should be
approved.

This /could/ be implemented in Gerrit by giving +1/-1 to everyone to
express technical opinion and +2/-2 to TC members to evaluate consensus
(with Workflow+1 to the TC chair to mark when all votes are collected
and consensus is indeed reached).

Other personal opinions on how you'd like this repository reviews to be
run ?

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


pgpMnOREag89a.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-13 Thread Thierry Carrez
James E. Blair wrote:
 [...] 
 I think in general though, it boils down to the fact that we need to
 answer these questions for each of the repos:
 
 A) Should the broader community register ±1 or simply comments? (Now
that we may distinguish them from TC member votes.)
 B) Should individual TC members get a veto?
 
 I personally think the answer to A is votes and B is no in both
 cases.  I'm also okay with sticking with comments for the governance
 repo.  I fell pretty strongly about not having veto.

I'd answer the same. Votes and no veto.

 [...]
 ==
 
 Since upgrading to Gerrit 2.8, we have some additional tools at our
 disposal for configuring voting categories.  For some unique
 repositories such as governance and cross-project specs, we may want
 to reconfigure voting there.
 
 Governance Repo Requirements
 
 
 I believe that the following are requirements for the Governance
 repository:
 
 * TC members can express approval or disapproval in a way that
   identifies their vote as a vote of a member of the TC.
 * TC members may not veto.
 * Anyone should be able to express their opinion.
 * Only the TC chair may approve the change.  This is so that the chair
   is responsible for the procedural aspects of the vote (ie, when it
   is finalized).
 
 Current Governance Repo Rules
 -
 
 These are currently satisfied by the following rules in Gerrit:
 
 * Anyone may comment on a change without leaving a vote.
 * Only TC members may vote +1/-1 in Code-Review.
 * Only the TC chair may vote Code-Review +2 and Workflow +1.
 
 Unsatisfied Governance Repo Requirements
 
 
 This does not satisfy the following potential requirements:
 
 * The TC chair may vote -1 and still approve a disputed change with 7
   yes votes (the chair currently would need to leave a comment
   indicating the actual vote tally).
 * Non-TC members may register their approval or disapproval with a
   vote (they currently may only leave comments to that effect).

Agreed.

 Cross-Project Repo Requirements
 ---
 
 * TC members can express approval or disapproval in a way that
   identifies their vote as a vote of a member of the TC.
 * TC members may not veto.  (This requirement has not achieved
   consensus.)
 * Non-TC members may register their approval or disapproval with a
   vote (we must be able to easily see that PTLs of affected projects
   have weighed in).
 * Only the TC chair may approve the change.  This is so that the chair
   is responsible for the procedural aspects of the vote (ie, when it
   is finalized).
 
 Current Cross-Project Repo Rules
 
 
 These are currently satisfied by the following rules in Gerrit:
 
 * Anyone may comment on a change and leave a vote.
 * Only TC members may vote +2 in Code-Review.
 * Only the TC chair may vote Workflow +1.

My understanding is that currently, any TC member can Workflow+1 (which
lead to the accidental approval of the previous spec).

 Unsatisfied Governance Repo Requirements
 
 The following potential requirements are not satisfied:
 
 * TC members may veto with a -2 Code-Review vote.  (This requirement
   has not achieved consensus.)
 
 Potential Changes
 =
 
 To address the unsatisfied requirements, we could make the following
 changes, which would only apply to the repos in question:
 
 To address this requirement:
 * The TC chair may vote -1 and still approve a disputed change with 7
   yes votes (the chair currently would need to leave a comment
   indicating the actual vote tally).
 
 We could change the Code-Review label function from MaxWithBlock to
 NoBlock, so that the votes in Code-Review are ignored by Gerrit, and
 only enforced by the chair.
 
 Additionally, we could write a custom submit rule that requires at
 least 7 +1 votes in order for the change to be submittable.

Our voting rules are slightly more complex than that, as you can see here:

http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77

The rule actually is more positive votes than negative votes, and a
minimum of 5 positive votes. The 7 YES rule is just a shortcut: once
we reach it, we can safely approve (otherwise we basically have to wait
for all votes to be cast, which with asynchronous voting, and the
difficulty to distinguish +0 from not voted yet, is not so easy to
achieve).

So unless you can encode that in a rule, I'd keep it under the
responsibility of the chair to properly (and publicly) tally the votes
(which I do in the +2 final comment) according to our charter rules.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-13 Thread James E. Blair
Thierry Carrez thie...@openstack.org writes:

 Current Cross-Project Repo Rules
 
...
 * Only the TC chair may vote Workflow +1.

 My understanding is that currently, any TC member can Workflow+1 (which
 lead to the accidental approval of the previous spec).

I think that was instachanged by Doug after the TC meeting:

  https://review.openstack.org/#/c/150581/

So the immediate problem is abated, and we can deliberate about any
other changes.

 Additionally, we could write a custom submit rule that requires at
 least 7 +1 votes in order for the change to be submittable.

 Our voting rules are slightly more complex than that, as you can see here:

 http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77

 The rule actually is more positive votes than negative votes, and a
 minimum of 5 positive votes. The 7 YES rule is just a shortcut: once
 we reach it, we can safely approve (otherwise we basically have to wait
 for all votes to be cast, which with asynchronous voting, and the
 difficulty to distinguish +0 from not voted yet, is not so easy to
 achieve).

 So unless you can encode that in a rule, I'd keep it under the
 responsibility of the chair to properly (and publicly) tally the votes
 (which I do in the +2 final comment) according to our charter rules.

The mechanism for such a change is Prolog.  I suspect that encoding that
rule is possible, though I am not familiar enough with Prolog to say for
sure.  The part of me that loves learning new programming languages
wants to find out.  But part of me agrees with you and thinks we should
just leave it to the Chair.

Actually, I think I may have missed a requirement that would preclude
the use of that rule.  We may consider Chair is able to approve trivial
administrative changes to the governance repo without a full vote as a
requirement, in which case we want the status quo.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-13 Thread Doug Hellmann


On Fri, Feb 13, 2015, at 11:33 AM, James E. Blair wrote:
 Thierry Carrez thie...@openstack.org writes:
 
  Current Cross-Project Repo Rules
  
 ...
  * Only the TC chair may vote Workflow +1.
 
  My understanding is that currently, any TC member can Workflow+1 (which
  lead to the accidental approval of the previous spec).
 
 I think that was instachanged by Doug after the TC meeting:
 
   https://review.openstack.org/#/c/150581/
 
 So the immediate problem is abated, and we can deliberate about any
 other changes.
 
  Additionally, we could write a custom submit rule that requires at
  least 7 +1 votes in order for the change to be submittable.
 
  Our voting rules are slightly more complex than that, as you can see here:
 
  http://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst#n77
 
  The rule actually is more positive votes than negative votes, and a
  minimum of 5 positive votes. The 7 YES rule is just a shortcut: once
  we reach it, we can safely approve (otherwise we basically have to wait
  for all votes to be cast, which with asynchronous voting, and the
  difficulty to distinguish +0 from not voted yet, is not so easy to
  achieve).
 
  So unless you can encode that in a rule, I'd keep it under the
  responsibility of the chair to properly (and publicly) tally the votes
  (which I do in the +2 final comment) according to our charter rules.
 
 The mechanism for such a change is Prolog.  I suspect that encoding that
 rule is possible, though I am not familiar enough with Prolog to say for
 sure.  The part of me that loves learning new programming languages
 wants to find out.  But part of me agrees with you and thinks we should
 just leave it to the Chair.
 
 Actually, I think I may have missed a requirement that would preclude
 the use of that rule.  We may consider Chair is able to approve trivial
 administrative changes to the governance repo without a full vote as a
 requirement, in which case we want the status quo.

Yes, indeed. We also recently agreed to let the Chair rebase changes
that were approved but can't be merged to avoid needing another vote
just because git is confused.

Doug

 
 -Jim
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-12 Thread James E. Blair
Thierry Carrez thie...@openstack.org writes:

 So what is it we actually want for that repository ? In a world where
 Gerrit can do anything, what would you like to have ?

 Personally, I want our technical community in general, and our PTLs/CPLs
 in particular, to be able to record their opinion on the proposed
 cross-project spec. Then, if consensus is reached, the spec should be
 approved.

 This /could/ be implemented in Gerrit by giving +1/-1 to everyone to
 express technical opinion and +2/-2 to TC members to evaluate consensus
 (with Workflow+1 to the TC chair to mark when all votes are collected
 and consensus is indeed reached).

Thanks for starting this.  Despite the fact that I was explicitly
looking for this thread, I still missed it.

I think in general though, it boils down to the fact that we need to
answer these questions for each of the repos:

A) Should the broader community register +/-1 or simply comments? (Now
   that we may distinguish them from TC member votes.)
B) Should individual TC members get a veto?

I personally think the answer to A is votes and B is no in both
cases.  I'm also okay with sticking with comments for the governance
repo.  I fell pretty strongly about not having veto.

Below I am including a whole bunch of text which is both my analysis of
all of the requirements and potential requirements, the current state,
and technical implementations of changes we might want.  Sorry it's so
long and complicated, but the gist is that we do have options, and if we
can agree on the above 2 questions, I think the next steps are fairly
obvious.

-Jim

==

Since upgrading to Gerrit 2.8, we have some additional tools at our
disposal for configuring voting categories.  For some unique
repositories such as governance and cross-project specs, we may want
to reconfigure voting there.

Governance Repo Requirements


I believe that the following are requirements for the Governance
repository:

* TC members can express approval or disapproval in a way that
  identifies their vote as a vote of a member of the TC.
* TC members may not veto.
* Anyone should be able to express their opinion.
* Only the TC chair may approve the change.  This is so that the chair
  is responsible for the procedural aspects of the vote (ie, when it
  is finalized).

Current Governance Repo Rules
-

These are currently satisfied by the following rules in Gerrit:

* Anyone may comment on a change without leaving a vote.
* Only TC members may vote +1/-1 in Code-Review.
* Only the TC chair may vote Code-Review +2 and Workflow +1.

Unsatisfied Governance Repo Requirements


This does not satisfy the following potential requirements:

* The TC chair may vote -1 and still approve a disputed change with 7
  yes votes (the chair currently would need to leave a comment
  indicating the actual vote tally).
* Non-TC members may register their approval or disapproval with a
  vote (they currently may only leave comments to that effect).

Cross-Project Repo Requirements
---

* TC members can express approval or disapproval in a way that
  identifies their vote as a vote of a member of the TC.
* TC members may not veto.  (This requirement has not achieved
  consensus.)
* Non-TC members may register their approval or disapproval with a
  vote (we must be able to easily see that PTLs of affected projects
  have weighed in).
* Only the TC chair may approve the change.  This is so that the chair
  is responsible for the procedural aspects of the vote (ie, when it
  is finalized).

Current Cross-Project Repo Rules


These are currently satisfied by the following rules in Gerrit:

* Anyone may comment on a change and leave a vote.
* Only TC members may vote +2 in Code-Review.
* Only the TC chair may vote Workflow +1.

Unsatisfied Governance Repo Requirements

The following potential requirements are not satisfied:

* TC members may veto with a -2 Code-Review vote.  (This requirement
  has not achieved consensus.)

Potential Changes
=

To address the unsatisfied requirements, we could make the following
changes, which would only apply to the repos in question:

To address this requirement:
* The TC chair may vote -1 and still approve a disputed change with 7
  yes votes (the chair currently would need to leave a comment
  indicating the actual vote tally).

We could change the Code-Review label function from MaxWithBlock to
NoBlock, so that the votes in Code-Review are ignored by Gerrit, and
only enforced by the chair.

Additionally, we could write a custom submit rule that requires at
least 7 +1 votes in order for the change to be submittable.

Additionally, we could change the name of the review category from
Code-Review to something else, for instance, TC 

Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-02-12 Thread Doug Hellmann


On Wed, Jan 28, 2015, at 08:25 AM, Thierry Carrez wrote:
 Hi everyone,
 
 When we first introduced the cross-project specs (specs for things that
 may potentially affect all OpenStack projects, or where more convergence
 is desirable), we defaulted to rather simple rules for approval:
 
 - discuss the spec in a cross-project meeting
 - let everyone +1/-1 and seek consensus
 - wait for the affected PTLs to vote
 - wait even more
 - tally the votes (and agree a consensus is reached) during a TC meeting
 - give +2/Worflow+1 to all TC members to let them push the Go button
 
 However, the recent approval of the Log guidelines
 (https://review.openstack.org/#/c/132552/) revealed that those may not
 be the rules we are looking for.
 
 Sean suggested that only the TC chair should be able to workflow+1 to
 avoid accidental approval.
 
 Doug suggested that we should use the TC voting rules (7 YES, or at
 least 5 YES and more YES than NO) on those.
 
 In yesterday's meeting, Sean suggested that TC members should still have
 a -2-like veto (if there is no TC consensus on the fact that community
 consensus is reached, there probably is no real consensus).

In the past we've shown -1 votes to be a sign of a lack of consensus,
and I'm not aware of any cases where a close vote went through. In fact,
the only close vote I can remember since we started voting in gerrit was
the Zaqar graduation vote, and that outcome kept the status quo in the
face of no clear consensus.

Given that, I'm not sure we need a true veto but I could accept it if
that's the consensus.

 
 There was little time to discuss this more in yesterday's TC meeting, so
 I took the action to push that discussion to the ML.
 
 So what is it we actually want for that repository ? In a world where
 Gerrit can do anything, what would you like to have ?
 
 Personally, I want our technical community in general, and our PTLs/CPLs
 in particular, to be able to record their opinion on the proposed
 cross-project spec. Then, if consensus is reached, the spec should be
 approved.
 
 This /could/ be implemented in Gerrit by giving +1/-1 to everyone to
 express technical opinion and +2/-2 to TC members to evaluate consensus
 (with Workflow+1 to the TC chair to mark when all votes are collected
 and consensus is indeed reached).
 
 Other personal opinions on how you'd like this repository reviews to be
 run ?
 
 -- 
 Thierry Carrez (ttx)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] What should openstack-specs review approval rules be ?

2015-01-28 Thread Morgan Fainberg
I am of the opinion that the +1/-1 from non tc members can be valuable, but
similarly it would be easy to get just comments. The TC is the body I
expect to help determine the direction of cross project initiatives such as
the logging guidelines. As a PTL I feel confident the TC is the right body
to do the voting and the same rules as the governance repo (with chair +1
workflow) seems to be a great idea. Communicating the topics via the ML and
the cross project meeting should help to get the PTLs and CPLs involved in
the process, which is highly important. The ML can help to bring in other
views.

I would rather trust the TC (who has not shown any reason to question their
ability to determine community consensus) to help make sure we don't stall
on these specs than have endless waiting. I like the proposal to use the TC
voting rules.

--Morgan

On Wednesday, January 28, 2015, Thierry Carrez thie...@openstack.org
wrote:

 Hi everyone,

 When we first introduced the cross-project specs (specs for things that
 may potentially affect all OpenStack projects, or where more convergence
 is desirable), we defaulted to rather simple rules for approval:

 - discuss the spec in a cross-project meeting
 - let everyone +1/-1 and seek consensus
 - wait for the affected PTLs to vote
 - wait even more
 - tally the votes (and agree a consensus is reached) during a TC meeting
 - give +2/Worflow+1 to all TC members to let them push the Go button

 However, the recent approval of the Log guidelines
 (https://review.openstack.org/#/c/132552/) revealed that those may not
 be the rules we are looking for.

 Sean suggested that only the TC chair should be able to workflow+1 to
 avoid accidental approval.

 Doug suggested that we should use the TC voting rules (7 YES, or at
 least 5 YES and more YES than NO) on those.

 In yesterday's meeting, Sean suggested that TC members should still have
 a -2-like veto (if there is no TC consensus on the fact that community
 consensus is reached, there probably is no real consensus).

 There was little time to discuss this more in yesterday's TC meeting, so
 I took the action to push that discussion to the ML.

 So what is it we actually want for that repository ? In a world where
 Gerrit can do anything, what would you like to have ?

 Personally, I want our technical community in general, and our PTLs/CPLs
 in particular, to be able to record their opinion on the proposed
 cross-project spec. Then, if consensus is reached, the spec should be
 approved.

 This /could/ be implemented in Gerrit by giving +1/-1 to everyone to
 express technical opinion and +2/-2 to TC members to evaluate consensus
 (with Workflow+1 to the TC chair to mark when all votes are collected
 and consensus is indeed reached).

 Other personal opinions on how you'd like this repository reviews to be
 run ?

 --
 Thierry Carrez (ttx)

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev