<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Dear all,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Let me raise my hand here. We introduced this role CL a while ago for two major reasons:</div><div class="gmail_default" style="font-family:monospace,monospace"> 1) improve review process (CL are responsible for review SLA)</div><div class="gmail_default" style="font-family:monospace,monospace"> 2) introduce review of overall architecture and avoid cross-feature, cross-component conflicts.</div><div class="gmail_default" style="font-family:monospace,monospace">These two points, in fact, mean the following:</div><div class="gmail_default" style="font-family:monospace,monospace"> 1) CL ask other developers (including cores) to help to review patches if there any that did not get enough attention</div><div class="gmail_default" style="font-family:monospace,monospace"> 2) CL spend 50% of their time reviewing specs and we don't merge specs w/o their +2 </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I think that is not exactly what we meant. Our CL role is rather a mixture of a manager and an architect. Both these roles are enterprise roles. I think in community having Core Reviewers is more than enough. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Real motivation (salary, career, etc.) of a particular contributor should NOT be a matter of community. If a particular manager wants to have a person who is to be responsible for asking people to review patches, then it is a matter of this manager to motivate a particular person. In community a team of core reviewers is responsible for review, not a person.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">To prevent cross-feature and cross-component conflicts we can use CI gate that will put -1 to a spec that is merged without necessary +2 from trusted people from various components. For example, we could create a yaml file</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">avengers:</div><div class="gmail_default" style="font-family:monospace,monospace"> fuel-web:<br></div><div class="gmail_default" style="font-family:monospace,monospace"> Hawkeye</div><div class="gmail_default" style="font-family:monospace,monospace"> Captain America</div><div class="gmail_default" style="font-family:monospace,monospace"> fuel-ui:</div><div class="gmail_default" style="font-family:monospace,monospace"> Black Widow</div><div class="gmail_default" style="font-family:monospace,monospace"> fuel-library</div><div class="gmail_default" style="font-family:monospace,monospace"> Hulk</div><div class="gmail_default" style="font-family:monospace,monospace"> Ironman </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">and CI gate will check if there is +2 from at least one superhero from every project and fail if not. Superheros should be volunteers (no matter what their real motivation is). </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I propose to get rid of official CL role in Fuel. Instead it should be totally up to a particular component team to decide if they want CL or other roles. What do you guys think?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"> </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Serg,<br>
<br>
Thanks for agreeing to officiate this cycle's component lead elections<br>
for us!<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dmitry Borodaenko<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:<br>
> Hi folks,<br>
><br>
> I'd like to announce that we're running the Component Leads elections.<br>
> Detailed information is available on wiki [0].<br>
><br>
> Component Lead: defines architecture of a particular module or<br>
> component in Fuel, resolves technical disputes in their area of<br>
> responsibility. All design specs that impact a component must be<br>
> approved by the corresponding component lead [1].<br>
><br>
> Fuel has three large sub-teams, with roughly comparable codebases,<br>
> that need dedicated component leads:<br>
><br>
> * fuel-library<br>
> * fuel-web<br>
> * fuel-ui<br>
><br>
> Nominees propose their candidacy by sending an email to the<br>
> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a> mailing-list, with the subject:<br>
> "[fuel] <component> lead candidacy"<br>
> (for example, "[fuel] fuel-library lead candidacy").<br>
><br>
> Timeline:<br>
> * March 25 - March 31: Open candidacy for Component leads positions<br>
> * April 1 - April 7: Component leads elections<br>
><br>
> References<br>
> [0] <a href="https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016</a><br>
> [1] <a href="https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html</a><br>
><br>
> --<br>
> Serg Melikyan, Development Manager at Mirantis, Inc.<br>
> <a href="http://mirantis.com" rel="noreferrer" target="_blank">http://mirantis.com</a> | <a href="mailto:smelikyan@mirantis.com">smelikyan@mirantis.com</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>