<div dir="ltr"><div>Vladimir,</div><div>I think this call is too late to change a structure for now. I suggest that we always respect the policy we've accepted, and follow it.</div><div><br></div>If Component Leads role is under a question, then I'd continue the discussion, hear opinion of current component leads, and give this a time to be discussed. I'd have nothing against removing this role in a month from now if we reach a consensus on this topic - no need to wait for the cycle end.<div><br></div><div>I originally proposed this role in [1], and I've seen this working better than without it: with code reviews; getting a final decision faster with very little involvement of PTL. I would say that we needed to do analysis similar to what I've done in [1], in order to get better understanding of what worked well and what didn't.</div><div><br></div><div>From my high level take here: Fuel is large project, counts 21 repos with code, excluding plugins [2]. While some of subprojects would have a clear leadership, some may get a few people with contradicting opinions but similar weight in the community. In this case, decision on contradicting opinions will be on a shoulders of PTL, which doesn't seem to be very scalable. Volunteering doesn't help in this case, as even two volunteers with different opinions will have to ask PTL for judgement.</div><div>I'd let Dmitry B. to comment, but I don't think that we had too many things which could not be resolved on Component Leads level in the past cycle.</div><div><br></div><div>A few other things answered inline:</div><div>> <span style="font-family:monospace,monospace">Our CL role is rather a mixture of a manager and an architect.</span></div><div>Why manager? Do we have any other Fuel contributors reporting to Component Leads? Yes for an architect. Is it a problem in the community?<br></div><div><br></div><div>> <span style="font-family:monospace,monospace">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.</span></div><div>If you mean contributors, then established workflow with maintainers  [3] should cover this.</div><div>If you mean Component Leads here, then I'd say that CLs have to be self-motivated to ensure on-time review on patches. Otherwise, people will turn out from component(s), and prefer other solutions or a fork. CL has to make a decision, how many blueprints can be taken into work, to ensure that enough time is dedicated to code review and other activities.<br></div><div><br></div><div>Thanks,</div><div></div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html">http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html</a></div><div>[2] <a href="https://github.com/openstack/governance/blob/master/reference/projects.yaml#L593">https://github.com/openstack/governance/blob/master/reference/projects.yaml#L593</a></div><div>[3] <a href="https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow">https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow</a></div><div><br><div>Thanks,</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 25, 2016 at 9:10 AM Vladimir Kozhukalov <<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"></div><div class="gmail_extra"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></div><div class="gmail_extra">
<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><font color="#888888"><br>
--<br>
Dmitry Borodaenko<br>
</font></span><div><div><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" target="_blank">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" target="_blank">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>
__________________________________________________________________________<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>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>