+1 On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban <dkli...@redhat.com> wrote:
> +1 > > On Thu, Aug 10, 2017 at 9:21 AM, David Davis <davidda...@redhat.com> > wrote: > >> +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/g >>>>>>>>>>> overnance/appendix-glossary/#consensus-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 >> >> > > _______________________________________________ > 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