+1 Thanks, Brian! Tanya
On Thu, Aug 10, 2017 at 3:21 PM, 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/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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
