Re: [Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

The voting ended on August 11th with a final vote count of eight +1s and no
-1 votes. I've gone ahead and merged the revisions. Thank you for
everyone's comments, participation, and patience throughout this process.

Now that the revisions are merged, you can see the whole document here:
https://github.com/pulp/pups/blob/master/pup-0001.md

Thanks,
Brian


On Fri, Aug 11, 2017 at 9:11 AM, Michael Hrivnak 
wrote:

> +1
>
> On Fri, Aug 11, 2017 at 4:54 AM, Ina Panova  wrote:
>
>> +1.
>> Thanks Brian for all your effort and commitment.
>>
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>> On Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley  wrote:
>>
>>> +1
>>>
>>> On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban 
>>> wrote:
>>>
 +1

 On Thu, Aug 10, 2017 at 9:21 AM, David Davis 
 wrote:

> +1. I think this is worth trying out.
>
>
> David
>
> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald  > wrote:
>
>> +1
>>
>> Thank you Brian!
>>
>> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse 
>> wrote:
>>
>>> A small language clarification was pushed based on feedback via
>>> comment:  https://github.com/bmbouter/pu
>>> ps/commit/f5b7282b2d2e369b90f149e4cc25226bb093171b
>>>
>>> Voting is open for the PUP1 revisions. Normally the voting window is
>>> longer, but this topic has been discussed for a long time. The core team
>>> earlier this week decided a shorter voting window was appropriate in 
>>> this
>>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
>>> any concerns around this process. Otherwise, please send in votes via 
>>> this
>>> thread. I'll cast mine now.
>>>
>>> +1 to passing the pup1 revisions.
>>>
>>> Thanks to everyone who has contributed comments and energy into this
>>> topic.
>>>
>>> -Brian
>>>
>>>
>>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse >> > wrote:
>>>
 After some in-person convo, the core team wants to open PUP1
 revision voting on Wednesday and close it at midnight UTC on Friday Aug
 11th. We will pass/not-pass according this the voting outlined in PUP1
 itself (a variation on self-hosting [0]). We also want to ask that any
 comments on the PUP1 revisions by posted before midnight UTC tomorrow 
 Aug
 8th.

 [0]: https://en.wikipedia.org/wiki/Self-hosting

 -Brian



 On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse <
 bbout...@redhat.com> wrote:

> I've pushed a new commit [3] to the PR. It includes the following
> changes. Please review and comment. If there are any major/blocking
> concerns about adopting this please raise them. Once the PUP1 
> revisions are
> resolved, PUP2 can also be accepted based on the votes it had 
> previously.
>
> * Adjusts the +1 approvals to come from anywhere, not just core
> devs
> * Explicitly allows for votes to be recast
> * Explains two examples where votes are recast. One is based on
> many other -1 votes being cast. The other is when concerns are 
> addressed
> and a -1 vote is recast.
>
> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
> e1d97ea6fe4aa570066db768
>
> -Brian
>
>
> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse <
> bbout...@redhat.com> wrote:
>
>> From the discussion on the call last week, I've made some
>> revisions [2] to explore the idea of having a lazy consensus model.
>> Comments, ideas, concerns are welcome either on the PR or via this 
>> thread.
>>
>> As @mhrivnak pointed out, the adoption of a lazy consensus model
>> is meaningfully different than the language we have in pup1 today 
>> which
>> uses "obvious consensus". I want to be up front about that change 
>> [2]. If
>> anyone significantly disagrees with this direction, or has concerns, 
>> please
>> raise them.
>>
>> [2]: https://github.com/pulp/pups/pull/5/
>>
>> -Brian
>>
>> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse <
>> bbout...@redhat.com> wrote:
>>
>>> After some in-person discussion, we will have a call to discuss
>>> ideas and options regarding the pup1 process. We will use this 
>>> etherpad [0]
>>> for notes, and we 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Ina Panova]

+1.
Thanks Brian for all your effort and commitment.




Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley  wrote:

> +1
>
> On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban  wrote:
>
>> +1
>>
>> On Thu, Aug 10, 2017 at 9:21 AM, David Davis 
>> wrote:
>>
>>> +1. I think this is worth trying out.
>>>
>>>
>>> David
>>>
>>> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald 
>>> wrote:
>>>
 +1

 Thank you Brian!

 On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse 
 wrote:

> A small language clarification was pushed based on feedback via
> comment:  https://github.com/bmbouter/pups/commit/f5b7282b2d2e369b90f1
> 49e4cc25226bb093171b
>
> Voting is open for the PUP1 revisions. Normally the voting window is
> longer, but this topic has been discussed for a long time. The core team
> earlier this week decided a shorter voting window was appropriate in this
> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
> any concerns around this process. Otherwise, please send in votes via this
> thread. I'll cast mine now.
>
> +1 to passing the pup1 revisions.
>
> Thanks to everyone who has contributed comments and energy into this
> topic.
>
> -Brian
>
>
> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse 
> wrote:
>
>> After some in-person convo, the core team wants to open PUP1 revision
>> voting on Wednesday and close it at midnight UTC on Friday Aug 11th. We
>> will pass/not-pass according this the voting outlined in PUP1 itself (a
>> variation on self-hosting [0]). We also want to ask that any comments on
>> the PUP1 revisions by posted before midnight UTC tomorrow Aug 8th.
>>
>> [0]: https://en.wikipedia.org/wiki/Self-hosting
>>
>> -Brian
>>
>>
>>
>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse 
>> wrote:
>>
>>> I've pushed a new commit [3] to the PR. It includes the following
>>> changes. Please review and comment. If there are any major/blocking
>>> concerns about adopting this please raise them. Once the PUP1 revisions 
>>> are
>>> resolved, PUP2 can also be accepted based on the votes it had 
>>> previously.
>>>
>>> * Adjusts the +1 approvals to come from anywhere, not just core devs
>>> * Explicitly allows for votes to be recast
>>> * Explains two examples where votes are recast. One is based on many
>>> other -1 votes being cast. The other is when concerns are addressed and 
>>> a
>>> -1 vote is recast.
>>>
>>> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
>>> e1d97ea6fe4aa570066db768
>>>
>>> -Brian
>>>
>>>
>>> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse >> > wrote:
>>>
 From the discussion on the call last week, I've made some revisions
 [2] to explore the idea of having a lazy consensus model. Comments, 
 ideas,
 concerns are welcome either on the PR or via this thread.

 As @mhrivnak pointed out, the adoption of a lazy consensus model is
 meaningfully different than the language we have in pup1 today which 
 uses
 "obvious consensus". I want to be up front about that change [2]. If 
 anyone
 significantly disagrees with this direction, or has concerns, please 
 raise
 them.

 [2]: https://github.com/pulp/pups/pull/5/

 -Brian

 On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse <
 bbout...@redhat.com> wrote:

> After some in-person discussion, we will have a call to discuss
> ideas and options regarding the pup1 process. We will use this 
> etherpad [0]
> for notes, and we will recap the information to the list also. In
> preparation, please continue to share ideas, perspectives and 
> concerns via
> this list.
>
> When: June 22nd, 1pm UTC. See this in your local timezone here
> [1]. The call will last no longer than 1 hour.
>
> How to connect:
> video chat:https://bluejeans.com/697488960
> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>
> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
> [1]: http://bit.ly/2rJqegX
>
> -Brian
>
>
> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak <
> mhriv...@redhat.com> wrote:
>
>> Back to where we started, having digested the discussion here and
>> 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Tatiana Tereshchenko]

+1
Thanks, Brian!

Tanya

On Thu, Aug 10, 2017 at 3:21 PM, David Davis  wrote:

> +1. I think this is worth trying out.
>
>
> David
>
> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald 
> wrote:
>
>> +1
>>
>> Thank you Brian!
>>
>> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse 
>> wrote:
>>
>>> A small language clarification was pushed based on feedback via
>>> comment:  https://github.com/bmbouter/pups/commit/f5b7282b2d2e369b90f1
>>> 49e4cc25226bb093171b
>>>
>>> Voting is open for the PUP1 revisions. Normally the voting window is
>>> longer, but this topic has been discussed for a long time. The core team
>>> earlier this week decided a shorter voting window was appropriate in this
>>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
>>> any concerns around this process. Otherwise, please send in votes via this
>>> thread. I'll cast mine now.
>>>
>>> +1 to passing the pup1 revisions.
>>>
>>> Thanks to everyone who has contributed comments and energy into this
>>> topic.
>>>
>>> -Brian
>>>
>>>
>>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse 
>>> wrote:
>>>
 After some in-person convo, the core team wants to open PUP1 revision
 voting on Wednesday and close it at midnight UTC on Friday Aug 11th. We
 will pass/not-pass according this the voting outlined in PUP1 itself (a
 variation on self-hosting [0]). We also want to ask that any comments on
 the PUP1 revisions by posted before midnight UTC tomorrow Aug 8th.

 [0]: https://en.wikipedia.org/wiki/Self-hosting

 -Brian



 On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse 
 wrote:

> I've pushed a new commit [3] to the PR. It includes the following
> changes. Please review and comment. If there are any major/blocking
> concerns about adopting this please raise them. Once the PUP1 revisions 
> are
> resolved, PUP2 can also be accepted based on the votes it had previously.
>
> * Adjusts the +1 approvals to come from anywhere, not just core devs
> * Explicitly allows for votes to be recast
> * Explains two examples where votes are recast. One is based on many
> other -1 votes being cast. The other is when concerns are addressed and a
> -1 vote is recast.
>
> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
> e1d97ea6fe4aa570066db768
>
> -Brian
>
>
> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse 
> wrote:
>
>> From the discussion on the call last week, I've made some revisions
>> [2] to explore the idea of having a lazy consensus model. Comments, 
>> ideas,
>> concerns are welcome either on the PR or via this thread.
>>
>> As @mhrivnak pointed out, the adoption of a lazy consensus model is
>> meaningfully different than the language we have in pup1 today which uses
>> "obvious consensus". I want to be up front about that change [2]. If 
>> anyone
>> significantly disagrees with this direction, or has concerns, please 
>> raise
>> them.
>>
>> [2]: https://github.com/pulp/pups/pull/5/
>>
>> -Brian
>>
>> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse 
>> wrote:
>>
>>> After some in-person discussion, we will have a call to discuss
>>> ideas and options regarding the pup1 process. We will use this etherpad 
>>> [0]
>>> for notes, and we will recap the information to the list also. In
>>> preparation, please continue to share ideas, perspectives and concerns 
>>> via
>>> this list.
>>>
>>> When: June 22nd, 1pm UTC. See this in your local timezone here [1].
>>> The call will last no longer than 1 hour.
>>>
>>> How to connect:
>>> video chat:https://bluejeans.com/697488960
>>> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>>>
>>> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
>>> [1]: http://bit.ly/2rJqegX
>>>
>>> -Brian
>>>
>>>
>>> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak <
>>> mhriv...@redhat.com> wrote:
>>>
 Back to where we started, having digested the discussion here and
 references cited, it seems clear that we have a system based on 
 consensus,
 and that there is strong desire for decisions about process to continue
 being made with consensus. In terms of "obvious consensus", I'll 
 propose
 that if any core member thinks it has not been reached, it has 
 (perhaps by
 definition) not been reached.

 PUP0001 simply states in that case, "If obvious consensus is not
 reached, then the core devs decide." We don't need to over-complicate 
 this.
 We've had reasonable success for many years at making process 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[David Davis]

+1. I think this is worth trying out.


David

On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald 
wrote:

> +1
>
> Thank you Brian!
>
> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse 
> wrote:
>
>> A small language clarification was pushed based on feedback via comment:
>> https://github.com/bmbouter/pups/commit/f5b7282b2d2e369b90f1
>> 49e4cc25226bb093171b
>>
>> Voting is open for the PUP1 revisions. Normally the voting window is
>> longer, but this topic has been discussed for a long time. The core team
>> earlier this week decided a shorter voting window was appropriate in this
>> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
>> any concerns around this process. Otherwise, please send in votes via this
>> thread. I'll cast mine now.
>>
>> +1 to passing the pup1 revisions.
>>
>> Thanks to everyone who has contributed comments and energy into this
>> topic.
>>
>> -Brian
>>
>>
>> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse 
>> wrote:
>>
>>> After some in-person convo, the core team wants to open PUP1 revision
>>> voting on Wednesday and close it at midnight UTC on Friday Aug 11th. We
>>> will pass/not-pass according this the voting outlined in PUP1 itself (a
>>> variation on self-hosting [0]). We also want to ask that any comments on
>>> the PUP1 revisions by posted before midnight UTC tomorrow Aug 8th.
>>>
>>> [0]: https://en.wikipedia.org/wiki/Self-hosting
>>>
>>> -Brian
>>>
>>>
>>>
>>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse 
>>> wrote:
>>>
 I've pushed a new commit [3] to the PR. It includes the following
 changes. Please review and comment. If there are any major/blocking
 concerns about adopting this please raise them. Once the PUP1 revisions are
 resolved, PUP2 can also be accepted based on the votes it had previously.

 * Adjusts the +1 approvals to come from anywhere, not just core devs
 * Explicitly allows for votes to be recast
 * Explains two examples where votes are recast. One is based on many
 other -1 votes being cast. The other is when concerns are addressed and a
 -1 vote is recast.

 [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
 e1d97ea6fe4aa570066db768

 -Brian


 On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse 
 wrote:

> From the discussion on the call last week, I've made some revisions
> [2] to explore the idea of having a lazy consensus model. Comments, ideas,
> concerns are welcome either on the PR or via this thread.
>
> As @mhrivnak pointed out, the adoption of a lazy consensus model is
> meaningfully different than the language we have in pup1 today which uses
> "obvious consensus". I want to be up front about that change [2]. If 
> anyone
> significantly disagrees with this direction, or has concerns, please raise
> them.
>
> [2]: https://github.com/pulp/pups/pull/5/
>
> -Brian
>
> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse 
> wrote:
>
>> After some in-person discussion, we will have a call to discuss ideas
>> and options regarding the pup1 process. We will use this etherpad [0] for
>> notes, and we will recap the information to the list also. In 
>> preparation,
>> please continue to share ideas, perspectives and concerns via this list.
>>
>> When: June 22nd, 1pm UTC. See this in your local timezone here [1].
>> The call will last no longer than 1 hour.
>>
>> How to connect:
>> video chat:https://bluejeans.com/697488960
>> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>>
>> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
>> [1]: http://bit.ly/2rJqegX
>>
>> -Brian
>>
>>
>> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak > > wrote:
>>
>>> Back to where we started, having digested the discussion here and
>>> references cited, it seems clear that we have a system based on 
>>> consensus,
>>> and that there is strong desire for decisions about process to continue
>>> being made with consensus. In terms of "obvious consensus", I'll propose
>>> that if any core member thinks it has not been reached, it has (perhaps 
>>> by
>>> definition) not been reached.
>>>
>>> PUP0001 simply states in that case, "If obvious consensus is not
>>> reached, then the core devs decide." We don't need to over-complicate 
>>> this.
>>> We've had reasonable success for many years at making process changes 
>>> and
>>> agreeing on them. The PUP system should be a tool that helps us define a
>>> proposal as best we can, while providing a focal point for discussion. 
>>> It
>>> should not unduly impede our ability to make decisions.
>>>
>>> So in a 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Austin Macdonald]

+1

Thank you Brian!

On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse  wrote:

> A small language clarification was pushed based on feedback via comment:
> https://github.com/bmbouter/pups/commit/f5b7282b2d2e369b90f149e4cc2522
> 6bb093171b
>
> Voting is open for the PUP1 revisions. Normally the voting window is
> longer, but this topic has been discussed for a long time. The core team
> earlier this week decided a shorter voting window was appropriate in this
> case. Voting will close at midnight UTC on Friday Aug 11th. Please raise
> any concerns around this process. Otherwise, please send in votes via this
> thread. I'll cast mine now.
>
> +1 to passing the pup1 revisions.
>
> Thanks to everyone who has contributed comments and energy into this topic.
>
> -Brian
>
>
> On Mon, Aug 7, 2017 at 10:15 AM, Brian Bouterse 
> wrote:
>
>> After some in-person convo, the core team wants to open PUP1 revision
>> voting on Wednesday and close it at midnight UTC on Friday Aug 11th. We
>> will pass/not-pass according this the voting outlined in PUP1 itself (a
>> variation on self-hosting [0]). We also want to ask that any comments on
>> the PUP1 revisions by posted before midnight UTC tomorrow Aug 8th.
>>
>> [0]: https://en.wikipedia.org/wiki/Self-hosting
>>
>> -Brian
>>
>>
>>
>> On Mon, Jul 31, 2017 at 9:24 AM, Brian Bouterse 
>> wrote:
>>
>>> I've pushed a new commit [3] to the PR. It includes the following
>>> changes. Please review and comment. If there are any major/blocking
>>> concerns about adopting this please raise them. Once the PUP1 revisions are
>>> resolved, PUP2 can also be accepted based on the votes it had previously.
>>>
>>> * Adjusts the +1 approvals to come from anywhere, not just core devs
>>> * Explicitly allows for votes to be recast
>>> * Explains two examples where votes are recast. One is based on many
>>> other -1 votes being cast. The other is when concerns are addressed and a
>>> -1 vote is recast.
>>>
>>> [3]: https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26
>>> e1d97ea6fe4aa570066db768
>>>
>>> -Brian
>>>
>>>
>>> On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse 
>>> wrote:
>>>
 From the discussion on the call last week, I've made some revisions [2]
 to explore the idea of having a lazy consensus model. Comments, ideas,
 concerns are welcome either on the PR or via this thread.

 As @mhrivnak pointed out, the adoption of a lazy consensus model is
 meaningfully different than the language we have in pup1 today which uses
 "obvious consensus". I want to be up front about that change [2]. If anyone
 significantly disagrees with this direction, or has concerns, please raise
 them.

 [2]: https://github.com/pulp/pups/pull/5/

 -Brian

 On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse 
 wrote:

> After some in-person discussion, we will have a call to discuss ideas
> and options regarding the pup1 process. We will use this etherpad [0] for
> notes, and we will recap the information to the list also. In preparation,
> please continue to share ideas, perspectives and concerns via this list.
>
> When: June 22nd, 1pm UTC. See this in your local timezone here [1].
> The call will last no longer than 1 hour.
>
> How to connect:
> video chat:https://bluejeans.com/697488960
> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>
> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
> [1]: http://bit.ly/2rJqegX
>
> -Brian
>
>
> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak 
> wrote:
>
>> Back to where we started, having digested the discussion here and
>> references cited, it seems clear that we have a system based on 
>> consensus,
>> and that there is strong desire for decisions about process to continue
>> being made with consensus. In terms of "obvious consensus", I'll propose
>> that if any core member thinks it has not been reached, it has (perhaps 
>> by
>> definition) not been reached.
>>
>> PUP0001 simply states in that case, "If obvious consensus is not
>> reached, then the core devs decide." We don't need to over-complicate 
>> this.
>> We've had reasonable success for many years at making process changes and
>> agreeing on them. The PUP system should be a tool that helps us define a
>> proposal as best we can, while providing a focal point for discussion. It
>> should not unduly impede our ability to make decisions.
>>
>> So in a case where consensus is not obvious, can we talk it out among
>> the core devs, particularly those with reservations, and make it our
>> collective responsibility to find a path forward? Do we need to define it
>> in more detail than that?
>>
>> On Fri, Jun 16, 2017 at 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

I've pushed a new commit [3] to the PR. It includes the following changes.
Please review and comment. If there are any major/blocking concerns about
adopting this please raise them. Once the PUP1 revisions are resolved, PUP2
can also be accepted based on the votes it had previously.

* Adjusts the +1 approvals to come from anywhere, not just core devs
* Explicitly allows for votes to be recast
* Explains two examples where votes are recast. One is based on many other
-1 votes being cast. The other is when concerns are addressed and a -1 vote
is recast.

[3]:
https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26e1d97ea6fe4aa570066db768

-Brian


On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse  wrote:

> From the discussion on the call last week, I've made some revisions [2] to
> explore the idea of having a lazy consensus model. Comments, ideas,
> concerns are welcome either on the PR or via this thread.
>
> As @mhrivnak pointed out, the adoption of a lazy consensus model is
> meaningfully different than the language we have in pup1 today which uses
> "obvious consensus". I want to be up front about that change [2]. If anyone
> significantly disagrees with this direction, or has concerns, please raise
> them.
>
> [2]: https://github.com/pulp/pups/pull/5/
>
> -Brian
>
> On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse 
> wrote:
>
>> After some in-person discussion, we will have a call to discuss ideas and
>> options regarding the pup1 process. We will use this etherpad [0] for
>> notes, and we will recap the information to the list also. In preparation,
>> please continue to share ideas, perspectives and concerns via this list.
>>
>> When: June 22nd, 1pm UTC. See this in your local timezone here [1]. The
>> call will last no longer than 1 hour.
>>
>> How to connect:
>> video chat:https://bluejeans.com/697488960
>> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>>
>> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
>> [1]: http://bit.ly/2rJqegX
>>
>> -Brian
>>
>>
>> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak 
>> wrote:
>>
>>> Back to where we started, having digested the discussion here and
>>> references cited, it seems clear that we have a system based on consensus,
>>> and that there is strong desire for decisions about process to continue
>>> being made with consensus. In terms of "obvious consensus", I'll propose
>>> that if any core member thinks it has not been reached, it has (perhaps by
>>> definition) not been reached.
>>>
>>> PUP0001 simply states in that case, "If obvious consensus is not
>>> reached, then the core devs decide." We don't need to over-complicate this.
>>> We've had reasonable success for many years at making process changes and
>>> agreeing on them. The PUP system should be a tool that helps us define a
>>> proposal as best we can, while providing a focal point for discussion. It
>>> should not unduly impede our ability to make decisions.
>>>
>>> So in a case where consensus is not obvious, can we talk it out among
>>> the core devs, particularly those with reservations, and make it our
>>> collective responsibility to find a path forward? Do we need to define it
>>> in more detail than that?
>>>
>>> On Fri, Jun 16, 2017 at 9:22 AM, David Davis 
>>> wrote:
>>>
 I like centos model but personally I’m not a fan of the lazy consensus
 option (X=0). Instead, I like the idea of having X be greater than 1
 (preferably 2). I feel like if there’s at least two people driving a change
 (i.e. X=2) then if one person leaves the project, we’ll still have someone
 who is able and motivated to take on the maintenance and evolution of the
 change. That said, I am happy to test out the model where X=0.


 David

 On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse 
 wrote:

> I asked about some of these governance questions to a group of
> community managers from several open source projects that I meet with
> weekly. They said that if you don't have a BDFL (Pulp does not) the other
> very popular model is the lazy consensus model. I think lazy consensus is
> the spirit of pup1. I asked for some examples and they pointed me at the
> CentOS governance model [0][1].
>
> Also @daviddavis and I were talking and codifying the problem as what
> value should X be if X are the number of +1s required to pass a decision
> with zero -1 votes (vetos)? The CentOS governance model sets X = 0 by
> stating "There is no minimum +1 vote requirement". I'm also advocating for
> X=0 for the reasons I wrote in my earlier email. Practically speaking, I
> don't think an X=1, or X=2 will prevent many proposals that would have 
> also
> passed with X=0.
>
> Regardless of the X value, we should continue the discussion so we can
> arrive at a decision on both 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

>From the discussion on the call last week, I've made some revisions [2] to
explore the idea of having a lazy consensus model. Comments, ideas,
concerns are welcome either on the PR or via this thread.

As @mhrivnak pointed out, the adoption of a lazy consensus model is
meaningfully different than the language we have in pup1 today which uses
"obvious consensus". I want to be up front about that change [2]. If anyone
significantly disagrees with this direction, or has concerns, please raise
them.

[2]: https://github.com/pulp/pups/pull/5/

-Brian

On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse  wrote:

> After some in-person discussion, we will have a call to discuss ideas and
> options regarding the pup1 process. We will use this etherpad [0] for
> notes, and we will recap the information to the list also. In preparation,
> please continue to share ideas, perspectives and concerns via this list.
>
> When: June 22nd, 1pm UTC. See this in your local timezone here [1]. The
> call will last no longer than 1 hour.
>
> How to connect:
> video chat:https://bluejeans.com/697488960
> phone only: + 800 451 8679   Enter Meeting ID: 697488960
>
> [0]: http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited
> [1]: http://bit.ly/2rJqegX
>
> -Brian
>
>
> On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak 
> wrote:
>
>> Back to where we started, having digested the discussion here and
>> references cited, it seems clear that we have a system based on consensus,
>> and that there is strong desire for decisions about process to continue
>> being made with consensus. In terms of "obvious consensus", I'll propose
>> that if any core member thinks it has not been reached, it has (perhaps by
>> definition) not been reached.
>>
>> PUP0001 simply states in that case, "If obvious consensus is not reached,
>> then the core devs decide." We don't need to over-complicate this. We've
>> had reasonable success for many years at making process changes and
>> agreeing on them. The PUP system should be a tool that helps us define a
>> proposal as best we can, while providing a focal point for discussion. It
>> should not unduly impede our ability to make decisions.
>>
>> So in a case where consensus is not obvious, can we talk it out among the
>> core devs, particularly those with reservations, and make it our collective
>> responsibility to find a path forward? Do we need to define it in more
>> detail than that?
>>
>> On Fri, Jun 16, 2017 at 9:22 AM, David Davis 
>> wrote:
>>
>>> I like centos model but personally I’m not a fan of the lazy consensus
>>> option (X=0). Instead, I like the idea of having X be greater than 1
>>> (preferably 2). I feel like if there’s at least two people driving a change
>>> (i.e. X=2) then if one person leaves the project, we’ll still have someone
>>> who is able and motivated to take on the maintenance and evolution of the
>>> change. That said, I am happy to test out the model where X=0.
>>>
>>>
>>> David
>>>
>>> On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse 
>>> wrote:
>>>
 I asked about some of these governance questions to a group of
 community managers from several open source projects that I meet with
 weekly. They said that if you don't have a BDFL (Pulp does not) the other
 very popular model is the lazy consensus model. I think lazy consensus is
 the spirit of pup1. I asked for some examples and they pointed me at the
 CentOS governance model [0][1].

 Also @daviddavis and I were talking and codifying the problem as what
 value should X be if X are the number of +1s required to pass a decision
 with zero -1 votes (vetos)? The CentOS governance model sets X = 0 by
 stating "There is no minimum +1 vote requirement". I'm also advocating for
 X=0 for the reasons I wrote in my earlier email. Practically speaking, I
 don't think an X=1, or X=2 will prevent many proposals that would have also
 passed with X=0.

 Regardless of the X value, we should continue the discussion so we can
 arrive at a decision on both pup1 and pup3. Thanks for continuing the 
 convo.

 [0]: https://www.centos.org/about/governance/appendix-glossary/#c
 onsensus-decision-making
 [1]: https://www.centos.org/about/governance/voting/

 -Brian


 On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova 
 wrote:

> And if we would remove all 'shades of grey' and go back just to +1 and
> -1 where people would need to make their mind up *clearly* which would 
> lead
> stronger arguments of doing or not doing this.
>
>
>
> 
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Tue, Jun 13, 2017 at 5:30 PM, David Davis 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

I asked about some of these governance questions to a group of community
managers from several open source projects that I meet with weekly. They
said that if you don't have a BDFL (Pulp does not) the other very popular
model is the lazy consensus model. I think lazy consensus is the spirit of
pup1. I asked for some examples and they pointed me at the CentOS
governance model [0][1].

Also @daviddavis and I were talking and codifying the problem as what value
should X be if X are the number of +1s required to pass a decision with
zero -1 votes (vetos)? The CentOS governance model sets X = 0 by stating
"There is no minimum +1 vote requirement". I'm also advocating for X=0 for
the reasons I wrote in my earlier email. Practically speaking, I don't
think an X=1, or X=2 will prevent many proposals that would have also
passed with X=0.

Regardless of the X value, we should continue the discussion so we can
arrive at a decision on both pup1 and pup3. Thanks for continuing the convo.

[0]:
https://www.centos.org/about/governance/appendix-glossary/#consensus-decision-making
[1]: https://www.centos.org/about/governance/voting/

-Brian


On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova  wrote:

> And if we would remove all 'shades of grey' and go back just to +1 and -1
> where people would need to make their mind up *clearly* which would lead
> stronger arguments of doing or not doing this.
>
>
>
> 
> Regards,
>
> Ina Panova
> Software Engineer| Pulp| Red Hat Inc.
>
> "Do not go where the path may lead,
>  go instead where there is no path and leave a trail."
>
> On Tue, Jun 13, 2017 at 5:30 PM, David Davis 
> wrote:
>
>> In this model of where only -1 votes stop the PUP from passing, wouldn’t
>> it mean that there needn't be any consensus at all? In other words we could
>> effectively strike the language about consensus from PUP-1. This model
>> makes me worried that people other than those casting -1 won’t bother to
>> vote or participate since only -1 votes matter.
>>
>> I personally like the idea of having at least 30% that are +1 or +0. This
>> means that enough -0 votes can still block the vote, and also +0 votes goes
>> towards helping the PUP pass. Thus +0 and -0 would both matter. I think
>> this is a good compromise between the extremes of "broad buy-in" and
>> "default to change."
>>
>>
>> David
>>
>> On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse 
>> wrote:
>>
>>> We should (I thought we did) adopt a process that favors change and does
>>> not have a "broad buy-in requirement". Any change that doesn't harm the
>>> project should be allowed without broad buy-in. This empowers even a single
>>> individual to enact change. This makes Pulp better because:
>>>
>>> * Everyone is empowered. A single individual can have a meaningful
>>> impact.
>>> * Anyone can stop an idea that will negatively affect the project or
>>> community via veto.
>>> * We avoid the tyranny of the majority [0] or supermajority.
>>> * It avoids politics. If we start averaging, or counting votes
>>> for/against in an offsetting way, there will be politics. Counting votes
>>> for/against will create inequality because influential project members will
>>> likely see their ideas adopted but others won't. Having a "default to
>>> change and any core dev can veto" approach creates equality.
>>>
>>> Regarding how "obvious consensus" works with the "veto-or-it-passes"
>>> model, if there are zero -1 votes cast, that means no one wanted to stop
>>> the process. If no wants to stop it, and at least one is for it, then the
>>> most sensible thing to do is to pass it. Since someone took time to write
>>> the PUP there is obviously someone giving it a +1. If one person really
>>> wants to go to place X for dinner (aka a +1), and there are no
>>> counterproposals (aka a -1 with a suggestion) or strong preferences against
>>> (aka -0 or +0) then the group will probably go to place X for dinner by way
>>> of "obvious consensus".
>>>
>>> In summary, adopting a "default to accept or reject with even a single
>>> veto" system creates an equal system. A system where, a single individual
>>> can make a difference, and anyone can stop a bad idea from occurring. To
>>> @mhrivnak's point about a change not meeting a broad range of needs, I
>>> expect -1's to be cast in those cases, so this system is still very safe in
>>> terms of protecting the projects needs and interests.
>>>
>>> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority
>>>
>>> -Brian
>>>
>>> On Mon, Jun 12, 2017 at 7:53 PM, David Davis 
>>> wrote:
>>>
 Not sure this is true. I actually abstained from voting on PUP-3
 because I was somewhere between a +0 and a -0.


 David

 On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova 
 wrote:

> Having at least one  +1 is not impartial approach just because the
> developer who , as you said, found the 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Ina Panova]

And if we would remove all 'shades of grey' and go back just to +1 and -1
where people would need to make their mind up *clearly* which would lead
stronger arguments of doing or not doing this.




Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Tue, Jun 13, 2017 at 5:30 PM, David Davis  wrote:

> In this model of where only -1 votes stop the PUP from passing, wouldn’t
> it mean that there needn't be any consensus at all? In other words we could
> effectively strike the language about consensus from PUP-1. This model
> makes me worried that people other than those casting -1 won’t bother to
> vote or participate since only -1 votes matter.
>
> I personally like the idea of having at least 30% that are +1 or +0. This
> means that enough -0 votes can still block the vote, and also +0 votes goes
> towards helping the PUP pass. Thus +0 and -0 would both matter. I think
> this is a good compromise between the extremes of "broad buy-in" and
> "default to change."
>
>
> David
>
> On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse 
> wrote:
>
>> We should (I thought we did) adopt a process that favors change and does
>> not have a "broad buy-in requirement". Any change that doesn't harm the
>> project should be allowed without broad buy-in. This empowers even a single
>> individual to enact change. This makes Pulp better because:
>>
>> * Everyone is empowered. A single individual can have a meaningful impact.
>> * Anyone can stop an idea that will negatively affect the project or
>> community via veto.
>> * We avoid the tyranny of the majority [0] or supermajority.
>> * It avoids politics. If we start averaging, or counting votes
>> for/against in an offsetting way, there will be politics. Counting votes
>> for/against will create inequality because influential project members will
>> likely see their ideas adopted but others won't. Having a "default to
>> change and any core dev can veto" approach creates equality.
>>
>> Regarding how "obvious consensus" works with the "veto-or-it-passes"
>> model, if there are zero -1 votes cast, that means no one wanted to stop
>> the process. If no wants to stop it, and at least one is for it, then the
>> most sensible thing to do is to pass it. Since someone took time to write
>> the PUP there is obviously someone giving it a +1. If one person really
>> wants to go to place X for dinner (aka a +1), and there are no
>> counterproposals (aka a -1 with a suggestion) or strong preferences against
>> (aka -0 or +0) then the group will probably go to place X for dinner by way
>> of "obvious consensus".
>>
>> In summary, adopting a "default to accept or reject with even a single
>> veto" system creates an equal system. A system where, a single individual
>> can make a difference, and anyone can stop a bad idea from occurring. To
>> @mhrivnak's point about a change not meeting a broad range of needs, I
>> expect -1's to be cast in those cases, so this system is still very safe in
>> terms of protecting the projects needs and interests.
>>
>> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority
>>
>> -Brian
>>
>> On Mon, Jun 12, 2017 at 7:53 PM, David Davis 
>> wrote:
>>
>>> Not sure this is true. I actually abstained from voting on PUP-3 because
>>> I was somewhere between a +0 and a -0.
>>>
>>>
>>> David
>>>
>>> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova  wrote:
>>>
 Having at least one  +1 is not impartial approach just because the
 developer who , as you said, found the time for the research and writing
 down the proposal obviously will vote as +1 :)



 
 Regards,

 Ina Panova
 Software Engineer| Pulp| Red Hat Inc.

 "Do not go where the path may lead,
  go instead where there is no path and leave a trail."

 On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald 
 wrote:

> This reminds me of the concept of a "Do-ocracy".
>
> If developers take the time to research and write up a proposal, they
> have "done". It seems completely reasonable to default to the opinion of
> the people that cared enough to do the work. If it isn't the right
> decision, then someone must actively block it, simple as that.
>
> I think the rule should be "PUP passes if we have at least one +1 and
> no -1s".
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>

 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> 

Re: [Pulp-dev] PUP Process: "obvious consensus"

[David Davis]

In this model of where only -1 votes stop the PUP from passing, wouldn’t it
mean that there needn't be any consensus at all? In other words we could
effectively strike the language about consensus from PUP-1. This model
makes me worried that people other than those casting -1 won’t bother to
vote or participate since only -1 votes matter.

I personally like the idea of having at least 30% that are +1 or +0. This
means that enough -0 votes can still block the vote, and also +0 votes goes
towards helping the PUP pass. Thus +0 and -0 would both matter. I think
this is a good compromise between the extremes of "broad buy-in" and
"default to change."


David

On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse 
wrote:

> We should (I thought we did) adopt a process that favors change and does
> not have a "broad buy-in requirement". Any change that doesn't harm the
> project should be allowed without broad buy-in. This empowers even a single
> individual to enact change. This makes Pulp better because:
>
> * Everyone is empowered. A single individual can have a meaningful impact.
> * Anyone can stop an idea that will negatively affect the project or
> community via veto.
> * We avoid the tyranny of the majority [0] or supermajority.
> * It avoids politics. If we start averaging, or counting votes for/against
> in an offsetting way, there will be politics. Counting votes for/against
> will create inequality because influential project members will likely see
> their ideas adopted but others won't. Having a "default to change and any
> core dev can veto" approach creates equality.
>
> Regarding how "obvious consensus" works with the "veto-or-it-passes"
> model, if there are zero -1 votes cast, that means no one wanted to stop
> the process. If no wants to stop it, and at least one is for it, then the
> most sensible thing to do is to pass it. Since someone took time to write
> the PUP there is obviously someone giving it a +1. If one person really
> wants to go to place X for dinner (aka a +1), and there are no
> counterproposals (aka a -1 with a suggestion) or strong preferences against
> (aka -0 or +0) then the group will probably go to place X for dinner by way
> of "obvious consensus".
>
> In summary, adopting a "default to accept or reject with even a single
> veto" system creates an equal system. A system where, a single individual
> can make a difference, and anyone can stop a bad idea from occurring. To
> @mhrivnak's point about a change not meeting a broad range of needs, I
> expect -1's to be cast in those cases, so this system is still very safe in
> terms of protecting the projects needs and interests.
>
> [0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority
>
> -Brian
>
> On Mon, Jun 12, 2017 at 7:53 PM, David Davis 
> wrote:
>
>> Not sure this is true. I actually abstained from voting on PUP-3 because
>> I was somewhere between a +0 and a -0.
>>
>>
>> David
>>
>> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova  wrote:
>>
>>> Having at least one  +1 is not impartial approach just because the
>>> developer who , as you said, found the time for the research and writing
>>> down the proposal obviously will vote as +1 :)
>>>
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>  go instead where there is no path and leave a trail."
>>>
>>> On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald 
>>> wrote:
>>>
 This reminds me of the concept of a "Do-ocracy".

 If developers take the time to research and write up a proposal, they
 have "done". It seems completely reasonable to default to the opinion of
 the people that cared enough to do the work. If it isn't the right
 decision, then someone must actively block it, simple as that.

 I think the rule should be "PUP passes if we have at least one +1 and
 no -1s".

 ___
 Pulp-dev mailing list
 Pulp-dev@redhat.com
 https://www.redhat.com/mailman/listinfo/pulp-dev


>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Brian Bouterse]

We should (I thought we did) adopt a process that favors change and does
not have a "broad buy-in requirement". Any change that doesn't harm the
project should be allowed without broad buy-in. This empowers even a single
individual to enact change. This makes Pulp better because:

* Everyone is empowered. A single individual can have a meaningful impact.
* Anyone can stop an idea that will negatively affect the project or
community via veto.
* We avoid the tyranny of the majority [0] or supermajority.
* It avoids politics. If we start averaging, or counting votes for/against
in an offsetting way, there will be politics. Counting votes for/against
will create inequality because influential project members will likely see
their ideas adopted but others won't. Having a "default to change and any
core dev can veto" approach creates equality.

Regarding how "obvious consensus" works with the "veto-or-it-passes" model,
if there are zero -1 votes cast, that means no one wanted to stop the
process. If no wants to stop it, and at least one is for it, then the most
sensible thing to do is to pass it. Since someone took time to write the
PUP there is obviously someone giving it a +1. If one person really wants
to go to place X for dinner (aka a +1), and there are no counterproposals
(aka a -1 with a suggestion) or strong preferences against (aka -0 or +0)
then the group will probably go to place X for dinner by way of "obvious
consensus".

In summary, adopting a "default to accept or reject with even a single
veto" system creates an equal system. A system where, a single individual
can make a difference, and anyone can stop a bad idea from occurring. To
@mhrivnak's point about a change not meeting a broad range of needs, I
expect -1's to be cast in those cases, so this system is still very safe in
terms of protecting the projects needs and interests.

[0]: https://en.wikipedia.org/wiki/Tyranny_of_the_majority

-Brian

On Mon, Jun 12, 2017 at 7:53 PM, David Davis  wrote:

> Not sure this is true. I actually abstained from voting on PUP-3 because I
> was somewhere between a +0 and a -0.
>
>
> David
>
> On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova  wrote:
>
>> Having at least one  +1 is not impartial approach just because the
>> developer who , as you said, found the time for the research and writing
>> down the proposal obviously will vote as +1 :)
>>
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>  go instead where there is no path and leave a trail."
>>
>> On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald 
>> wrote:
>>
>>> This reminds me of the concept of a "Do-ocracy".
>>>
>>> If developers take the time to research and write up a proposal, they
>>> have "done". It seems completely reasonable to default to the opinion of
>>> the people that cared enough to do the work. If it isn't the right
>>> decision, then someone must actively block it, simple as that.
>>>
>>> I think the rule should be "PUP passes if we have at least one +1 and no
>>> -1s".
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Michael Hrivnak]

Whatever we decide on, I think it's important to ensure that +0 and -0 mean
something. We want people who are skeptical (-0s) to raise their concerns
and know they will have some influence. We even want those who are
optimists but don't quite see the value yet (+0s) to ask questions and
participate in improving the document. If those folks "in the middle" feel
that their input won't matter, they are much less likely to participate.

And as observed by others, regardless of whether +/- 0 factors into whether
a PUP gets adopted, it does reflect a sentiment in the group that is
important to take seriously. If voting includes lots of -0's, that would
indicate a lot of skepticism, and perhaps even discontent. You can imagine
someone being unhappy about a change, but not wanting to stand up and be
the only person to cast a veto. That person's -0 needs to factor in somehow.

For these reasons, I think a "veto-or-it-passes" model would discourage
participation and make it too easy to end up with processes that don't meet
a broad-enough range of needs.

And this is a good time for a reminder that PUPs are for process changes,
which tend to affect large portions of our community, particularly
developers. Having broad buy-in before making process changes is something
we've strived for in the past, and I think it has served us well. "Obvious
consensus" seems like a good way to describe that goal.

On Mon, Jun 12, 2017 at 1:26 PM, Daniel Alley  wrote:

> We could use the metric that a PUP passes if there are no -1s and more
> than 1/3 of the team considers it an improvement (+0 or +1).  If more than
> 2/3rds the team is voting -0, it probably needs more discussion.
>
>
>
> On Mon, Jun 12, 2017 at 11:49 AM, Bryan Kearney 
> wrote:
>
>> I liked what Brian said, pick the model. Default to change or not. If you
>> guys decide to default to change, I agree with Ina that the proposal is a
>> +1. So, what would all 0s mean?
>>
>> -- bk
>>
>> On 06/12/2017 11:43 AM, Ina Panova wrote:
>>
>>> Having at least one  +1 is not impartial approach just because the
>>> developer who , as you said, found the time for the research and writing
>>> down the proposal obviously will vote as +1 :)
>>>
>>>
>>>
>>> 
>>> Regards,
>>>
>>> Ina Panova
>>> Software Engineer| Pulp| Red Hat Inc.
>>>
>>> "Do not go where the path may lead,
>>>   go instead where there is no path and leave a trail."
>>>
>>> On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald >> > wrote:
>>>
>>> This reminds me of the concept of a "Do-ocracy".
>>>
>>> If developers take the time to research and write up a proposal,
>>> they have "done". It seems completely reasonable to default to the
>>> opinion of the people that cared enough to do the work. If it isn't
>>> the right decision, then someone must actively block it, simple as
>>> that.
>>>
>>> I think the rule should be "PUP passes if we have at least one +1
>>> and no -1s".
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com 
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Daniel Alley]

We could use the metric that a PUP passes if there are no -1s and more than
1/3 of the team considers it an improvement (+0 or +1).  If more than
2/3rds the team is voting -0, it probably needs more discussion.



On Mon, Jun 12, 2017 at 11:49 AM, Bryan Kearney  wrote:

> I liked what Brian said, pick the model. Default to change or not. If you
> guys decide to default to change, I agree with Ina that the proposal is a
> +1. So, what would all 0s mean?
>
> -- bk
>
> On 06/12/2017 11:43 AM, Ina Panova wrote:
>
>> Having at least one  +1 is not impartial approach just because the
>> developer who , as you said, found the time for the research and writing
>> down the proposal obviously will vote as +1 :)
>>
>>
>>
>> 
>> Regards,
>>
>> Ina Panova
>> Software Engineer| Pulp| Red Hat Inc.
>>
>> "Do not go where the path may lead,
>>   go instead where there is no path and leave a trail."
>>
>> On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald > > wrote:
>>
>> This reminds me of the concept of a "Do-ocracy".
>>
>> If developers take the time to research and write up a proposal,
>> they have "done". It seems completely reasonable to default to the
>> opinion of the people that cared enough to do the work. If it isn't
>> the right decision, then someone must actively block it, simple as
>> that.
>>
>> I think the rule should be "PUP passes if we have at least one +1
>> and no -1s".
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com 
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>> 
>>
>>
>>
>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Bryan Kearney]

I liked what Brian said, pick the model. Default to change or not. If 
you guys decide to default to change, I agree with Ina that the proposal 
is a +1. So, what would all 0s mean?


-- bk

On 06/12/2017 11:43 AM, Ina Panova wrote:
Having at least one  +1 is not impartial approach just because the 
developer who , as you said, found the time for the research and writing 
down the proposal obviously will vote as +1 :)





Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
  go instead where there is no path and leave a trail."

On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald > wrote:


This reminds me of the concept of a "Do-ocracy".

If developers take the time to research and write up a proposal,
they have "done". It seems completely reasonable to default to the
opinion of the people that cared enough to do the work. If it isn't
the right decision, then someone must actively block it, simple as that.

I think the rule should be "PUP passes if we have at least one +1
and no -1s".

___
Pulp-dev mailing list
Pulp-dev@redhat.com 
https://www.redhat.com/mailman/listinfo/pulp-dev





___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev



___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Ina Panova]

Having at least one  +1 is not impartial approach just because the
developer who , as you said, found the time for the research and writing
down the proposal obviously will vote as +1 :)




Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald 
wrote:

> This reminds me of the concept of a "Do-ocracy".
>
> If developers take the time to research and write up a proposal, they have
> "done". It seems completely reasonable to default to the opinion of the
> people that cared enough to do the work. If it isn't the right decision,
> then someone must actively block it, simple as that.
>
> I think the rule should be "PUP passes if we have at least one +1 and no
> -1s".
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Austin Macdonald]

This reminds me of the concept of a "Do-ocracy".

If developers take the time to research and write up a proposal, they have
"done". It seems completely reasonable to default to the opinion of the
people that cared enough to do the work. If it isn't the right decision,
then someone must actively block it, simple as that.

I think the rule should be "PUP passes if we have at least one +1 and no
-1s".
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PUP Process: "obvious consensus"

[Ina Panova]

--> - We could score each vote (e.g. -2 for -1, -1 for -0, +1 for +0, +2
for +1) and then add up the votes. An obvious consensus could be something
like a total of 0 or greater.

>From my perspective it complicates the 'consensus'

Why not following: if there is -1 from core dev, then not implement it and
if majority of the votes are +/-0 then maybe revisit the PUP and talk again
since the team is like 'meh, not really motivated'.
For obvious consensus i think most of the votes should be +1, because it
shows that team members are motivated and inspired by the forthcoming
changes, otherwise i don't see sense in pushing forward is there is no
boost from the very beginning.




Regards,

Ina Panova
Software Engineer| Pulp| Red Hat Inc.

"Do not go where the path may lead,
 go instead where there is no path and leave a trail."

On Mon, Jun 12, 2017 at 4:13 PM, David Davis  wrote:

> I wanted to follow up after our meeting about what “obvious consensus"
> means in PUP-1. As a refresher, here’s the relevant section in PUP-1:
>
> https://github.com/pulp/pups/blob/master/pup-0001.md#deciding
>
> The term
> about “obvious consensus” is vague—perhaps intentionally so. I’m wondering
> if we want to clarify what it means. Given that we have numerical votes, we
> could implement an algorithm for deciding what an obvious consensus means.
> A couple examples:
>
> - At least X% of votes are +0 or +1
> - We could score each vote (e.g. -2 for -1, -1 for -0, +1 for +0, +2 for
> +1) and then add up the votes. An obvious consensus could be something like
> a total of 0 or greater.
>
> The other conditions (e.g. no -1 votes from pulp core devs) should still
> apply I think. So even if there is an obvious consensus, the PUP wouldn’t
> necessarily be approved.
>
> Thoughts?
>
> David
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev