+1. I think this is worth trying out.
David On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald <amacd...@redhat.com> wrote: > +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/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 <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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
