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

Tue Jun 27 19:33:58 UTC 2017

>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 <bbouters at 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 <mhrivnak at 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 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 <daviddavis at redhat.com>
>> 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 <bbouters at redhat.com>
>>> 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 <ipanova at redhat.com>
>>>> 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 <daviddavis at redhat.com>
>>>>> 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 <bbouters at redhat.com
>>>>>> > 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 <daviddavis at redhat.com>
>>>>>>> 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 <ipanova at redhat.com>
>>>>>>>> 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 <
>>>>>>>>> amacdona at redhat.com> 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 at redhat.com
>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pulp-dev mailing list
>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pulp-dev mailing list
>>>>>>>> Pulp-dev at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>>
>>
>>
>> --
>>
>> Michael Hrivnak
>>
>> Principal Software Engineer, RHCE
>>
>> Red Hat
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170627/9dc6b105/attachment.htm>