<div dir="ltr">Interesting proposals Milan!<div><br></div><div>I am forking Brian's email so that thread can focus on communication, redmine, etc. </div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 3, 2018 at 8:13 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">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>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Apr 2, 2018 at 8:38 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>> wrote:<br>
> I agree the decision process for core itself needs discussion. For now, I'm<br>
> only able to offer facilitating a convo that focuses on the communication<br>
> aspects not the decision process. I would like to improve the 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 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 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">austin@redhat.com</a>> 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 are<br>
>> communicated.<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<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>
</div></div></blockquote></div><br></div></div>