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/ > 959c67f5a4d16a26e1d97ea6fe4aa570066db768 > > -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
