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

Thu Aug 10 12:54:13 UTC 2017

+1

Thank you Brian!

On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse <bbouters at redhat.com> 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 <bbouters at redhat.com>
> 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 <bbouters at 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 <bbouters at 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 <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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170810/7e48b918/attachment.htm>