>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 >> 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 <davidda...@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 <bbout...@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 <ipan...@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 <davidda...@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 <bbout...@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 <davidda...@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 <ipan...@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 < >>>>>>>>> amacd...@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@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