+1. Thanks Brian for all your effort and commitment.
-------- 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 Thu, Aug 10, 2017 at 9:58 PM, Daniel Alley <[email protected]> wrote: > +1 > > On Thu, Aug 10, 2017 at 3:04 PM, Dennis Kliban <[email protected]> wrote: > >> +1 >> >> On Thu, Aug 10, 2017 at 9:21 AM, David Davis <[email protected]> >> wrote: >> >>> +1. I think this is worth trying out. >>> >>> >>> David >>> >>> On Thu, Aug 10, 2017 at 8:54 AM, Austin Macdonald <[email protected]> >>> wrote: >>> >>>> +1 >>>> >>>> Thank you Brian! >>>> >>>> On Thu, Aug 10, 2017 at 5:33 AM, Brian Bouterse <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected] >>>>>>> > 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Pulp-dev mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Pulp-dev mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Pulp-dev mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Michael Hrivnak >>>>>>>>>> >>>>>>>>>> Principal Software Engineer, RHCE >>>>>>>>>> >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >> _______________________________________________ >> Pulp-dev mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
