<div dir="ltr"><div>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.<br><br>* Adjusts the +1 approvals to come from anywhere, not just core devs<br>* Explicitly allows for votes to be recast<br>* 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.<br><br>[3]: <a href="https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26e1d97ea6fe4aa570066db768">https://github.com/pulp/pups/pull/5/commits/959c67f5a4d16a26e1d97ea6fe4aa570066db768</a><br><br></div>-Brian<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 3:33 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br><br></div><div>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.<br></div><div><br>[2]: <a href="https://github.com/pulp/pups/pull/5/" target="_blank">https://github.com/pulp/pups/p<wbr>ull/5/</a><span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">-Brian<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 1:48 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br><br>When: June 22nd, 1pm UTC. See this in your local timezone here [1]. The call will last no longer than 1 hour.<br></div><div><br><div>How to connect:<br>video chat:    <a href="https://bluejeans.com/697488960" target="_blank">https://bluejeans.com/69748896<wbr>0</a><br></div><div>phone only: + 800 451 8679   Enter Meeting ID: 697488960</div></div><div><br>[0]: <a href="http://pad-katello.rhcloud.com/p/Pulp_PUP_Process_Revisited" target="_blank">http://pad-katello.rhcloud.com<wbr>/p/Pulp_PUP_Process_Revisited</a><br>[1]: <a href="http://bit.ly/2rJqegX" target="_blank">http://bit.ly/2rJqegX</a><span class="m_5059272486373094570HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_5059272486373094570HOEnZb"><font color="#888888"><div>-Brian<br><br></div></font></span><div><div class="m_5059272486373094570h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 9:23 AM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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?</div></div><div class="gmail_extra"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537h5"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 9:22 AM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div>
<br></font></span><div class="gmail_quote"><span>On Thu, Jun 15, 2017 at 3:20 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br></span><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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].<br><br>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.<br><br></div><div>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.<br></div><div><br>[0]: <a href="https://www.centos.org/about/governance/appendix-glossary/#consensus-decision-making" target="_blank">https://www.centos.org/about/g<wbr>overnance/appendix-glossary/#c<wbr>onsensus-decision-making</a><br>[1]: <a href="https://www.centos.org/about/governance/voting/" target="_blank">https://www.centos.org/about/g<wbr>overnance/voting/</a><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803HOEnZb"><font color="#888888"><div>-Brian<br></div><div><br></div></font></span></div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803HOEnZb"><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 11:46 AM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br></span><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586h5"><div class="gmail_quote">On Tue, Jun 13, 2017 at 5:30 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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."</div></div><div class="gmail_extra"><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div></font></span><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885h5">
<br><div class="gmail_quote">On Tue, Jun 13, 2017 at 10:36 AM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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:<br><br></div><div>* Everyone is empowered. A single individual can have a meaningful impact.<br></div><div>* Anyone can stop an idea that will negatively affect the project or community via veto.<br>* We avoid the tyranny of the majority [0] or supermajority.<br>* 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.<br><br></div><div>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".<br></div><div><br></div><div>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.<br></div><div><br>[0]: <a href="https://en.wikipedia.org/wiki/Tyranny_of_the_majority" target="_blank">https://en.wikipedia.org/wiki/<wbr>Tyranny_of_the_majority</a><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899HOEnZb"><font color="#888888"><div>-Brian<br></div></font></span></div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899HOEnZb"><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 12, 2017 at 7:53 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not sure this is true. I actually abstained from voting on PUP-3 because I was somewhere between a +0 and a -0.</div><div class="gmail_extra"><span class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026HOEnZb"><font color="#888888"><br clear="all"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026m_7139878958682957914gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div></font></span><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026h5">
<br><div class="gmail_quote">On Mon, Jun 12, 2017 at 11:43 AM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 :)<br></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026m_7139878958682957914m_-742930361298426720gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br></span><div class="gmail_quote"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026m_7139878958682957914h5">On Mon, Jun 12, 2017 at 5:35 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:amacdona@redhat.com" target="_blank">amacdona@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582m_2546853509489725803m_2355285918567569586m_79631578649877885m_-4369157421492994899m_-1201583837991106026m_7139878958682957914h5"><div dir="ltr"><div>This reminds me of the concept of a "Do-ocracy".</div><div><br></div><div>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.</div><div><br></div><div>I think the rule should be "PUP passes if we have at least one +1 and no -1s".</div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span>-- <br><div class="m_5059272486373094570m_-6642034702769296133m_1199131125466837537m_-4385526169452794582gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</span></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>