[Pulp-dev] PUP Process: "obvious consensus"

David Davis daviddavis at redhat.com
Tue Jun 13 15:30:42 UTC 2017

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."


On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse <bbouters at redhat.com>

> 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 <daviddavis at 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 <ipanova at 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 <amacdona at 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 at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170613/47e5a46f/attachment.htm>

More information about the Pulp-dev mailing list