Open Stack

Vladimir,
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.

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.

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.

>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.
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.

A few other things answered inline:
> Our CL role is rather a mixture of a manager and an architect.
Why manager? Do we have any other Fuel contributors reporting to Component
Leads? Yes for an architect. Is it a problem in the 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.
If you mean contributors, then established workflow with
maintainers  [3] should cover this.
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.

Thanks,

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
[2]
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L593
[3]
https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow

Thanks,

On Fri, Mar 25, 2016 at 9:10 AM Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:

> Dear all,
>
> Let me raise my hand here. We introduced this role CL a while ago for two
> major reasons:
>  1) improve review process (CL are responsible for review SLA)
>  2) introduce review of overall architecture and avoid cross-feature,
> cross-component conflicts.
> These two points, in fact, mean the following:
>  1) CL ask other developers (including cores) to help to review patches if
> there any that did not get enough attention
>  2) CL spend 50% of their time reviewing specs and we don't merge specs
> w/o their +2
>
> 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.
>
> 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.
>
> 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
>
> avengers:
>   fuel-web:
>     Hawkeye
>     Captain America
>   fuel-ui:
>     Black Widow
>   fuel-library
>     Hulk
>     Ironman
>
> 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).
>
> 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?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Vladimir Kozhukalov
>
> On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <
> dborodaenko at mirantis.com> wrote:
>
>> Serg,
>>
>> Thanks for agreeing to officiate this cycle's component lead elections
>> for us!
>>
>> --
>> Dmitry Borodaenko
>>
>>
>> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:
>> > Hi folks,
>> >
>> > I'd like to announce that we're running the Component Leads elections.
>> > Detailed information is available on wiki [0].
>> >
>> > Component Lead: defines architecture of a particular module or
>> > component in Fuel, resolves technical disputes in their area of
>> > responsibility. All design specs that impact a component must be
>> > approved by the corresponding component lead [1].
>> >
>> > Fuel has three large sub-teams, with roughly comparable codebases,
>> > that need dedicated component leads:
>> >
>> > * fuel-library
>> > * fuel-web
>> > * fuel-ui
>> >
>> > Nominees propose their candidacy by sending an email to the
>> > openstack-dev at lists.openstack.org mailing-list, with the subject:
>> > "[fuel] <component> lead candidacy"
>> > (for example, "[fuel] fuel-library lead candidacy").
>> >
>> > Timeline:
>> > * March 25 - March 31: Open candidacy for Component leads positions
>> > * April 1 - April 7: Component leads elections
>> >
>> > References
>> > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016
>> > [1]
>> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
>> >
>> > --
>> > Serg Melikyan, Development Manager at Mirantis, Inc.
>> > http://mirantis.com | smelikyan at mirantis.com
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160329/ed79035f/attachment.html>