<div dir="ltr"><div><div><div><div><div>I observe that the main things that aren't working for the lazy consensus method right now are:<br></div>1. Technically, our PUPS don't cover how a new feature or major design change would go through a process:<br> - our process is really just PUP for process changes, not actual use of proposing features, right?<br> - Need a way to enforce sticking to the process like ensuring time frames are included in initial proposals and how to get better "substantive arguments" accompanying a "-1" vote. I think we need some skills development in the area of communication here, but the process being more rigid would help set better expectations and allow us to focus on the technical discussions.<br></div><div> - We have allowed some issues (Jeremy's example) to go on far too long - the length and way that it dragged could be alleviated by a more rigid process<br></div><div> - we are sort of working in this way already, so this is not a urgent need. Just important. I would like us to work on the actual working through these.<br></div>2. Looks like the "-1" vote is something people feel less comfortable with.<br></div> - Not sure if this is because we've tried this out a few times and the team now feels that this is too powerful? There needs to be a way to move forward when we do not have 100% consensus? (ala team lead or tie breaker or some other vote counting)<br></div> - Or if we need some accountability here - like what do you do if you have a voter who is often voting "-1" or not following the substantive argument requirement?<br></div><div> - There is something here that feels a bit wrong here to me in that if someone has come up something that they are going to own and implement - how do we weigh the input of others of various levels of involvement against someone who as spent the most time investment on an idea in a fair way that balances the responsibility of the owner and the team that will own it going forward? <br></div><div><br></div><div>Another thought I have here is what Brian mentioned but actually a different tact. The responsibility to act as a technical lead is quite time consuming. Spreading this out to all the parts of the team and expecting that everyone with a commit bit for the Pulp Core team is dedicating the time to act in this capacity is not happening and leading to proposals stalling or taking a long time to be worked out.<br><br>Here is a proposal with some compromises:<br>1. Come up with some guidelines on times for proposals. Small bug fix (2 days), large feature (1 week). After -1, rinse & repeat proposal or withdrawal/be done.<br></div><div> NOTE: We are in a weird spot with a major re-write, we have constraints and not all the time in the world. And I could see net new features vs major change to existing functionality might require different levels of arguments.<br></div><div>2. For core, everybody continues to vote. But if there is any -1 vote(s), then we go to a 3 people to settle the vote by majority. I'll put it out there that I think this should be Jeff, Brian, and David. This also means that these folks need to take greater responsibility in evaluating and dedicating themselves to getting to consensus.<br></div><div><br>Let's recognize that there is great opportunity in putting Pulp 3 together but that this also leads to a lot of pressure to make it perfect and capitalize on the opportunity to change things that we wouldn't be able to change in Pulp 2, but we all want to put the best solution forward and we can't take forever to figure out what that is. It will not lead to us getting feedback from usable software if we take too long to make decisions.<br></div><div><br></div><div>Robin<br></div><div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 9:26 AM, Dana Walker <span dir="ltr"><<a href="mailto:dawalker@redhat.com" target="_blank">dawalker@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>I agree with Austin that whether we choose a tie-breaking individual or simply a voting system, we need an official process to prevent punting decisions forever down the road. Discussion and community involvement are great and still happening. Dissenters are not getting ignored and overruled. Making a decision does not mean we can't pivot and code up a different solution down the road if the user feedback says that needs to happen. But we *do* need to make decisions and move sooner rather than later ("Release early, release often"), not only so that QE and others downstream have time to plan and act on that knowledge and provide feedback but also simply to devote more time to work and less to repetitive meetings that don't end in a decision. This does not mean we will rush decisions, and we should still have other discussions on standards of process and quality and whatnot, but time boxing is necessary.<br><br></div>--Dana<br></div><div class="gmail_extra"><br clear="all"><div><div class="m_4726478968132261496gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>
<p style="font-weight:bold;margin:0;padding:0;font-size:14px;text-transform:uppercase;margin-bottom:0"><span>Dana</span> <span>Walker</span></p>
<p style="font-weight:normal;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>Associate Software Engineer</span><span style="font-weight:normal;color:#aaa;margin:0"></span></p>
<p style="font-weight:normal;margin:0;font-size:10px;color:#999"><a style="color:#0088ce;font-size:10px;margin:0;text-decoration:none;font-family:'overpass',sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span><br><br></span></a></p>
<table border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a> </td>
</tr></tbody></table>
</div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Wed, Apr 4, 2018 at 5:57 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@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 class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Apr 4, 2018 at 12: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>The lazy model is lazy, but I don't think it's ineffective. If there are issues with the lazy consensus model, let's talk about what those are.</div></div></blockquote><div><br></div></span><div>I dub this problem the "lazy veto". If there is a choice is between "do something" and "don't do something" anyone who is -1 does not have an incentive to engage in discussion. "Default to punt" is the opposite of our intention, which we agreed was "default to change".</div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> Adding a new, second process to-the-side I think will only muddy the water.<br></div></div></blockquote><div><br></div></span><div>The idea is that a good tech lead would only act when there is a stalled decision. How could that muddy the water?</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div>I believe in the benefit of asynchronous decision making for open source projects. Moving to a single-person role moves us to a centralized decision making model. There is some related content in this video [0] from fosdem: "Asynchronous Decision Making -- why and how. How Asynchronous Decision Making works and why it's essential"<br><br>[0]: <a href="https://fosdem.org/2018/schedule/event/community_decision_making_why_how/" target="_blank">https://fosdem.org/2018/schedu<wbr>le/event/community_decision_ma<wbr>king_why_how/</a></div></blockquote><div><br></div></span><div>I watched the video, and it was interesting. Whether we move forward with a tech lead, or a voting system, or whatever, we must have an official process. </div><div><div class="m_4726478968132261496h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331HOEnZb"><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331h5"><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 4, 2018 at 12:27 PM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@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"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div>My opinion is that we have stalled and punted several very
important issues when lazy consensus was too lazy. This has slowed our
progress enough that I am interested in fleshing out alternatives.</div><div><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827gmail-adm"><div id="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827gmail-q_16291581b0453ae8_7" class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827gmail-ajR m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827gmail-h4"><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827gmail-ajT"></div></div></div></div></blockquote></span><div><br>+1 <br></div></div><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161HOEnZb"><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 4, 2018 at 11:14 AM, Austin Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Apr 4, 2018 at 9:01 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>I'm not ready to pursue a single decision maker model for Pulp's technical decisions or community leadership. </div></div></blockquote><div><br></div></span><div>OpenStack tech leads aren't "single decision makers", they are a fallback for when consensus isn't reached. In theory the role <i>could </i>scope creep to "single decision makers" depending on the style of the individual, but elections prevent that if the voters are responsible.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I also have concerns about those positions being rotating roles since typically they require much experience. This would also be a departure from the lazy consensus decision making model we use for community decisions (the pup process itself).</div></div></blockquote><div><br></div></span><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">A "rotating role" is different than an elected position. I'm not sure what Milan meant by "time boxed", but I imagine this would just be another election, not a term limit. I think if this is done well, it would augment the lazy consensus model, not replace it.</div></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>There would need to be a lot of discussion with input from many people around what the issues currently are so we can be sure that changes would resolve those issues.<br></div></div></blockquote><div><br></div></span><div>+1 We should set this up carefully. I think a PUP is the right way to do that.</div><div><br></div><div>My opinion is that we have stalled and punted several very important issues when lazy consensus was too lazy. This has slowed our progress enough that I am interested in fleshing out alternatives.</div><div><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827m_7006260551619598968h5"><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 4, 2018 at 4:54 AM, Milan Kovacik <span dir="ltr"><<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh I'd forget that we actually don't really have a formal process to<br>
recognize and retire active contributors yet;<br>
how about the technical lead proposes both the recognition and<br>
retirement anytime they find reason to do so, for the former<br>
situation, with a pre-approval of other active contributors, propose<br>
folks publicly, for the latter situation, try reaching out to the<br>
retiring contributor before going public to avoid frustration.<br>
Folks of course would ideally announce their intention to retire, the<br>
formal process would be conducted by the technical lead.<br>
The insignia of an active contributor would be the commit bit on any<br>
of the Pulp projects.<br>
The first ever technical and community leads would be elected by folks<br>
with the commit bit, the election would be organized by our current<br>
community representatives.<br>
<br>
Unless there are objections, I'd file a PUP to summarize these points.<br>
<br>
<br>
Cheers,<br>
milan<br>
<div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827m_7006260551619598968m_8713653741509894036m_5081277825330021241HOEnZb"><div class="m_4726478968132261496m_7364037761389496653m_7603732020734478864m_6615035819354778065m_-6077159134760555806m_-6577093484126385386m_5743216548030870290m_-4039997697346180758m_-8254522018474405704m_615911725464856829m_5766204318702051331m_8371681988791624161m_4022756252605810827m_7006260551619598968m_8713653741509894036m_5081277825330021241h5"><br>
On Tue, Apr 3, 2018 at 6:02 PM, Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>> wrote:<br>
> On Tue, Apr 3, 2018 at 3:47 PM, Austin Macdonald <<a href="mailto:austin@redhat.com" target="_blank">austin@redhat.com</a>> wrote:<br>
>> Interesting proposals Milan!<br>
>><br>
>> I am forking Brian's email so that thread can focus on communication,<br>
>> redmine, etc.<br>
><br>
> Thanks, I guess it would best go hand-in-hand with the process update<br>
> proposal for the Technical specifications/blue-prints PUP:<br>
><br>
>>> I'd add that many a time, an e-mail based technical discussion gets<br>
>>> messy and unfolds in multiple branches over multiple months.<br>
>>> I'd like to propose we adopt a Technical Specification concept, living<br>
>>> in a separate GitHub repo, similar to the PUP process.<br>
>>> This would take advantage of our review process, preferably requiring<br>
>>> multiple (core) reviewers acks before merging, allowing Redmine to be<br>
>>> used for planning/tracking the (design) work.<br>
>>> I think it's easier to manage the life-cycle of a larger Technical<br>
>>> Specification in a revision system document than an e-mail thread and<br>
>>> a single Redmine issue.<br>
>>> It also helps (feature) documentation and provides context.<br>
><br>
>><br>
>> On Tue, Apr 3, 2018 at 8:13 AM, Milan Kovacik <<a href="mailto:mkovacik@redhat.com" target="_blank">mkovacik@redhat.com</a>> wrote:<br>
>>><br>
>>> I'd also like to propose formal Project Technical Lead and a formal<br>
>>> Project Community Lead roles to be able to decide in case of competing<br>
>>> (technical) ideas or planning priorities.<br>
>>> These would have to be time-boxed (half a year) and folks would elect<br>
>>> the leader for a period based on leader's program, such as focus on<br>
>>> particular goals for instance testing or refactoring.<br>
>>> Any single person would be able to perform either the Community or the<br>
>>> Technical Lead role in any given period but not both at the same time.<br>
>>> The Community Lead role would take care for organizing the Technical<br>
>>> Lead elections and vice versa, the Technical Lead would take care<br>
>>> about organizing the Community Lead elections.<br>
>>> The electorate would be the active contributors for both the roles.<br>
>>> The candidates would be the active contributors too.<br>
>>><br>
>>> This would open up the decision making process for anyone from the<br>
>>> community, would encourage transparency, accountability and<br>
>>> responsibility and would allow us to come to a decision on competing<br>
>>> (technical) ideas or planning issues in case we'd got stuck.<br>
>>><br>
>>> Cheers,<br>
>>> milan<br>
>>><br>
>>> On Mon, Apr 2, 2018 at 8:38 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>><br>
>>> wrote:<br>
>>> > I agree the decision process for core itself needs discussion. For now,<br>
>>> > I'm<br>
>>> > only able to offer facilitating a convo that focuses on the<br>
>>> > communication<br>
>>> > aspects not the decision process. I would like to improve the<br>
>>> > transparency<br>
>>> > into the features that will and won't be in any given release for our<br>
>>> > stakeholders. I hope we do discuss decision process as its own<br>
>>> > discussion;<br>
>>> > it's certainly deserving of a pup of its own.<br>
>>> ><br>
>>> > For the communication issues, soon I will share a basic outline of one<br>
>>> > way<br>
>>> > we could use Redmine for release planning. This would be a starter idea<br>
>>> > towards a solution for us to modify together.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald <<a href="mailto:austin@redhat.com" target="_blank">austin@redhat.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> I agree with the problems that Brian listed, but I hope we can focus on<br>
>>> >> the decision making process itself in addition to how those decisions<br>
>>> >> are<br>
>>> >> communicated.<br>
>>> ><br>
>>> ><br>
>>> ><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>
>><br>
>><br>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div></div></div><br></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></div></div><br></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>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>