+1 Thank you Brian!
On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse <bbout...@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 <bbout...@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 <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 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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev