<div dir="ltr"><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="gmail-adm"><div id="gmail-q_16291581b0453ae8_7" class="gmail-ajR gmail-h4"><div class="gmail-ajT"></div></div></div></div></blockquote><div><br>+1 <br></div></div><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 class="">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 class=""><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 class=""><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="h5"><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_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_7006260551619598968m_8713653741509894036m_5081277825330021241HOEnZb"><div class="m_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">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>