+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/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

Reply via email to