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

Michael Hrivnak mhrivnak at redhat.com
Mon Jun 12 21:41:31 UTC 2017


Whatever we decide on, I think it's important to ensure that +0 and -0 mean
something. We want people who are skeptical (-0s) to raise their concerns
and know they will have some influence. We even want those who are
optimists but don't quite see the value yet (+0s) to ask questions and
participate in improving the document. If those folks "in the middle" feel
that their input won't matter, they are much less likely to participate.

And as observed by others, regardless of whether +/- 0 factors into whether
a PUP gets adopted, it does reflect a sentiment in the group that is
important to take seriously. If voting includes lots of -0's, that would
indicate a lot of skepticism, and perhaps even discontent. You can imagine
someone being unhappy about a change, but not wanting to stand up and be
the only person to cast a veto. That person's -0 needs to factor in somehow.

For these reasons, I think a "veto-or-it-passes" model would discourage
participation and make it too easy to end up with processes that don't meet
a broad-enough range of needs.

And this is a good time for a reminder that PUPs are for process changes,
which tend to affect large portions of our community, particularly
developers. Having broad buy-in before making process changes is something
we've strived for in the past, and I think it has served us well. "Obvious
consensus" seems like a good way to describe that goal.

On Mon, Jun 12, 2017 at 1:26 PM, Daniel Alley <dalley at redhat.com> wrote:

> We could use the metric that a PUP passes if there are no -1s and more
> than 1/3 of the team considers it an improvement (+0 or +1).  If more than
> 2/3rds the team is voting -0, it probably needs more discussion.
>
>
>
> On Mon, Jun 12, 2017 at 11:49 AM, Bryan Kearney <bkearney at redhat.com>
> wrote:
>
>> I liked what Brian said, pick the model. Default to change or not. If you
>> guys decide to default to change, I agree with Ina that the proposal is a
>> +1. So, what would all 0s mean?
>>
>> -- bk
>>
>> On 06/12/2017 11:43 AM, Ina Panova 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
>>> <mailto: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 <mailto:Pulp-dev at redhat.com>
>>>     https://www.redhat.com/mailman/listinfo/pulp-dev
>>>     <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
>>
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170612/95d87ec2/attachment.htm>


More information about the Pulp-dev mailing list