<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Mike,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Inline comments.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Sure, there is no need to rush. I'd also like to see current CL opinions.</div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div><span style="font-family:monospace,monospace">My opinion here is that if a component is generic enough and could be treated as independent project, then this project should be brought out of Fuel and have its own PTL. If a component is a part of Fuel then final decision should be up to a Fuel PTL. That is how OpenStack works. <div class="gmail_default" style="font-family:monospace,monospace;display:inline">​If a project is so huge that requires kind of hierarchy, then it is a good reason to decouple this project into a set of independent projects. What I don't like in our current approach is that we have 21 repos and only 3 components. Why shouldn't we treat fuel-astute or fuel-agent or fuel-nailgun-agent, etc. as valid components with their own CLs?</div></span></div><div><span style="font-family:monospace,monospace"><div class="gmail_default" style="display:inline">​</div>  ​</span><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>A few other things answered inline:</div><span class=""><div>> <span style="font-family:monospace,monospace">Our CL role is rather a mixture of a manager and an architect.</span></div></span><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?</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​OpenStack has a role 'Core Reviewer' and it is a matter of the whole core team to review patches in a repository. I see no reasons to have yet another community supervisor who will poke core team to review patches. If Mirantis or any other third party contributor wants to have a dedicated person who reminds other people about patches that need to be reviewed it is a matter of a particular company not of Fuel community. Such enterprise role should not be exposed to Fuel as a community. </div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Architect (who has expertise over the whole Fuel) is also a role that should not be exposed to Fuel. In community we have core reviewers and all decisions should be a matter of consensus. If a company forces people to support one opinion or another, then again it should be a matter of the internal company hierarchy. Being a core reviewer in the community does not mean a particular person can not be an architect or a manager inside a company.   ​</div> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><span class=""><div></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></span><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. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">​​Yes, I like very much our MAINTAINERS approach. It works well, it is easy to know who is SME in a particular repository. IMO people who are mentioned in MAINTAINERS should​ be volunteers. E.g. if I feel I'm an expert in fuel-web, I send a patch that adds my name to MAINTAINERS file. Fuel-web team then decides whether my feeling has something common with reality. But real motivation behind the voluntary should NOT be exposed to the community. For the community it does not matter why a person wants to review or write the code. It does not matter if it is self-motivation or an order of a manager. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The same approach could be used for reviewing specs. I.e. if we want to make sure that a spec does not contradicts to the whole Fuel architecture, then we just need trusted people to be mandatory reviewers. This could be done using "Avengers" approach described above.</div><div class="gmail_default" style="font-family:monospace,monospace">​<span style="font-family:arial,sans-serif"> </span></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>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></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace">​Nope. A component team makes decisions (consensus). If a team wants to delegate their voice to a particular person (a member of the team), it is ok. Consensus is a sum of arguments, not a sum of opinions. Opinions could depend on many things (including salary, career). What you are describing is a manager role. And it is ok to have managers (fuel-web or fuel-ui manager) who help to coordinate resources. I'm only against this practice of exposing enterprise roles to the community.</div></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"> </span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></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" target="_blank">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" target="_blank">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" target="_blank">https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow</a></div><div><br><div>Thanks,</div><div><div class="h5"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="font-family:monospace,monospace">Dear all,</div><div style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"> 1) improve review process (CL are responsible for review SLA)</div><div style="font-family:monospace,monospace"> 2) introduce review of overall architecture and avoid cross-feature, cross-component conflicts.</div><div style="font-family:monospace,monospace">These two points, in fact, mean the following:</div><div 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 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">avengers:</div><div style="font-family:monospace,monospace">  fuel-web:<br></div><div style="font-family:monospace,monospace">    Hawkeye</div><div style="font-family:monospace,monospace">    Captain America</div><div style="font-family:monospace,monospace">  fuel-ui:</div><div style="font-family:monospace,monospace">    Black Widow</div><div style="font-family:monospace,monospace">  fuel-library</div><div style="font-family:monospace,monospace">    Hulk</div><div style="font-family:monospace,monospace">    Ironman </div><div style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div 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 style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">  </div><div style="font-family:monospace,monospace"> </div><div style="font-family:monospace,monospace">    </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">  </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"> </div><div style="font-family:monospace,monospace"><br></div><div 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></div><span class=""><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>
</font></span><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></blockquote></div><br></div></div>