Re: [openstack-dev] [fuel] Component Leads Elections

[Vladimir Kozhukalov]

Dear colleagues,

Looks like we have consensus (lazy, but still consensus)
on this topic: we don't need this role CL exposed to Fuel
project. I have prepared a change [1] for our team structure
policy.

My suggestion is to make Fuel is an aggregator
of independent components. Component teams could have their
formal or informal leads (i.e. component PTL) if needed
but it is irrelevant to Fuel as a whole.

As far as Fuel features usually require coordinated changes
in multiple components, we need all Fuel specs to be reviewed
by engineers from different backgrounds.

"Avengers" approach (described above) has been rejected
by Openstack Infra team, but we can use more traditional
core group approach. I.e. Fuel-specs core team is responsible for
reviewing and merging specs and in the proposed patch [1]
it is explicitly written down that each spec must be
approved by at least Puppet, UI, REST SMEs.
It is also a responsibility of Fuel-specs core group
to involve other SMEs if needed.

[1] https://review.openstack.org/#/c/301194/



Vladimir Kozhukalov

On Thu, Mar 31, 2016 at 6:47 PM, Serg Melikyan 
wrote:

> Hi fuelers,
>
> only few hours left until period of self-nomination will be closed, but so
> far we don't have neither consensus regarding how to proceed further nor
> candidates.
>
> I've increased period of self-nomination for another week (until April 7,
> 23:59 UTC) and expect to have decision about how we are going to proceed
> further if no one nominate himself or candidates for each of the three
> projects.
>
> I propose to start with defining steps that we are going to take if no one
> nominate himself by April 7 and move forward with separate discussion
> regarding governance.
>
> P.S. I strongly believe that declaring Component Leads role as obsolete
> require agreement among all members of Fuel team, which may take quite a
> lot of time. I think we should propose change-request to existing spec with
> governance [0], and have decision by end of Newton cycle.
>
> References:
> [0]
> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
>
> On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L  wrote:
>
>> Hi,
>>
>> I'm not sure if it's a right place to continue this discussion, but if
>> there are doubts that such role is needed, we should not wait for another
>> half a year to drop it.
>>
>> Also I'm not sure if a single engineer (or two engineers) can handle
>> majority of upcoming patches + specs + meetings around features. Sergii and
>> Igor put a lot of efforts to make it work, but does it really scale?
>>
>> I think it would be better to offload more responsibilities to core
>> groups, and if core team (of specific project) wants to see formal or
>> informal leader, let them decide.
>>
>> I would be really interested to see feedback from current component leads.
>>
>> Thanks,
>>
>>
>> On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dmitry,
>>>
>>> "No need to rush" does not mean we should postpone
>>> team structure changes until Ocata. IMO, CL role
>>> (when it is exposed to Fuel) contradicts to our
>>> modularization activities. Fuel should be an aggregator
>>> of components. What if we decide to use Ironic or
>>> Neutron as Fuel components? Should we chose also
>>> Ironic CL? NO! Ironic is an independent
>>> project with its own PTL.
>>>
>>> I agree with Mike that we could remove this CL
>>> role in a month if have consensus. But does it
>>> make any sense to chose CLs now and then
>>> immediately remove this role? Probably, it is better
>>> to make a decision right now. I'd really like to
>>> see here in this ML thread opinions of our current
>>> CLs and other people.
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
>>> dborodae...@mirantis.com> wrote:
>>>
 On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
 > > 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.
 >
 > Sure, there is no need to rush. I'd also like to see current CL
 opinions.

 Considering that, while there's an ongoing discussion on how to change
 Fuel team structure for Ocata, there's also an apparent consensus that
 we still want to have component leads for Newton, I'd like to call once
 again for volunteers to self-nominate for component leads of
 fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
 nomination period is over, and no 

Re: [openstack-dev] [fuel] Component Leads Elections

[Serg Melikyan]

Hi fuelers,

only few hours left until period of self-nomination will be closed, but so
far we don't have neither consensus regarding how to proceed further nor
candidates.

I've increased period of self-nomination for another week (until April 7,
23:59 UTC) and expect to have decision about how we are going to proceed
further if no one nominate himself or candidates for each of the three
projects.

I propose to start with defining steps that we are going to take if no one
nominate himself by April 7 and move forward with separate discussion
regarding governance.

P.S. I strongly believe that declaring Component Leads role as obsolete
require agreement among all members of Fuel team, which may take quite a
lot of time. I think we should propose change-request to existing spec with
governance [0], and have decision by end of Newton cycle.

References:
[0]
https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html

On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L  wrote:

> Hi,
>
> I'm not sure if it's a right place to continue this discussion, but if
> there are doubts that such role is needed, we should not wait for another
> half a year to drop it.
>
> Also I'm not sure if a single engineer (or two engineers) can handle
> majority of upcoming patches + specs + meetings around features. Sergii and
> Igor put a lot of efforts to make it work, but does it really scale?
>
> I think it would be better to offload more responsibilities to core
> groups, and if core team (of specific project) wants to see formal or
> informal leader, let them decide.
>
> I would be really interested to see feedback from current component leads.
>
> Thanks,
>
>
> On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dmitry,
>>
>> "No need to rush" does not mean we should postpone
>> team structure changes until Ocata. IMO, CL role
>> (when it is exposed to Fuel) contradicts to our
>> modularization activities. Fuel should be an aggregator
>> of components. What if we decide to use Ironic or
>> Neutron as Fuel components? Should we chose also
>> Ironic CL? NO! Ironic is an independent
>> project with its own PTL.
>>
>> I agree with Mike that we could remove this CL
>> role in a month if have consensus. But does it
>> make any sense to chose CLs now and then
>> immediately remove this role? Probably, it is better
>> to make a decision right now. I'd really like to
>> see here in this ML thread opinions of our current
>> CLs and other people.
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
>>> > > 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.
>>> >
>>> > Sure, there is no need to rush. I'd also like to see current CL
>>> opinions.
>>>
>>> Considering that, while there's an ongoing discussion on how to change
>>> Fuel team structure for Ocata, there's also an apparent consensus that
>>> we still want to have component leads for Newton, I'd like to call once
>>> again for volunteers to self-nominate for component leads of
>>> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
>>> nomination period is over, and no volunteer so far :(
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [fuel] Component Leads Elections

[Evgeniy L]

Hi,

I'm not sure if it's a right place to continue this discussion, but if
there are doubts that such role is needed, we should not wait for another
half a year to drop it.

Also I'm not sure if a single engineer (or two engineers) can handle
majority of upcoming patches + specs + meetings around features. Sergii and
Igor put a lot of efforts to make it work, but does it really scale?

I think it would be better to offload more responsibilities to core groups,
and if core team (of specific project) wants to see formal or informal
leader, let them decide.

I would be really interested to see feedback from current component leads.

Thanks,


On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dmitry,
>
> "No need to rush" does not mean we should postpone
> team structure changes until Ocata. IMO, CL role
> (when it is exposed to Fuel) contradicts to our
> modularization activities. Fuel should be an aggregator
> of components. What if we decide to use Ironic or
> Neutron as Fuel components? Should we chose also
> Ironic CL? NO! Ironic is an independent
> project with its own PTL.
>
> I agree with Mike that we could remove this CL
> role in a month if have consensus. But does it
> make any sense to chose CLs now and then
> immediately remove this role? Probably, it is better
> to make a decision right now. I'd really like to
> see here in this ML thread opinions of our current
> CLs and other people.
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
>> > > 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.
>> >
>> > Sure, there is no need to rush. I'd also like to see current CL
>> opinions.
>>
>> Considering that, while there's an ongoing discussion on how to change
>> Fuel team structure for Ocata, there's also an apparent consensus that
>> we still want to have component leads for Newton, I'd like to call once
>> again for volunteers to self-nominate for component leads of
>> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
>> nomination period is over, and no volunteer so far :(
>>
>> --
>> Dmitry Borodaenko
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Component Leads Elections

[Vladimir Kozhukalov]

Dmitry,

"No need to rush" does not mean we should postpone
team structure changes until Ocata. IMO, CL role
(when it is exposed to Fuel) contradicts to our
modularization activities. Fuel should be an aggregator
of components. What if we decide to use Ironic or
Neutron as Fuel components? Should we chose also
Ironic CL? NO! Ironic is an independent
project with its own PTL.

I agree with Mike that we could remove this CL
role in a month if have consensus. But does it
make any sense to chose CLs now and then
immediately remove this role? Probably, it is better
to make a decision right now. I'd really like to
see here in this ML thread opinions of our current
CLs and other people.



Vladimir Kozhukalov

On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:

> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
> > > 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.
> >
> > Sure, there is no need to rush. I'd also like to see current CL opinions.
>
> Considering that, while there's an ongoing discussion on how to change
> Fuel team structure for Ocata, there's also an apparent consensus that
> we still want to have component leads for Newton, I'd like to call once
> again for volunteers to self-nominate for component leads of
> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
> nomination period is over, and no volunteer so far :(
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Component Leads Elections

[Dmitry Borodaenko]

On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
> > 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.
> 
> Sure, there is no need to rush. I'd also like to see current CL opinions.

Considering that, while there's an ongoing discussion on how to change
Fuel team structure for Ocata, there's also an apparent consensus that
we still want to have component leads for Newton, I'd like to call once
again for volunteers to self-nominate for component leads of
fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
nomination period is over, and no volunteer so far :(

-- 
Dmitry Borodaenko

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Component Leads Elections

[Vladimir Kozhukalov]

Mike,

Inline comments.

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

​Sure, there is no need to rush. I'd also like to see current CL opinions.




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

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


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

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

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



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

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

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

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

​Nope. A component team makes decisions (consensus). 

Re: [openstack-dev] [fuel] Component Leads Elections

[Mike Scherbakov]

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 <
vkozhuka...@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 <
> dborodae...@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 

Re: [openstack-dev] [fuel] Component Leads Elections

[Vladimir Kozhukalov]

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 <
dborodae...@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@lists.openstack.org mailing-list, with the subject:
> > "[fuel]  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 | smelik...@mirantis.com
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Component Leads Elections

[Dmitry Borodaenko]

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@lists.openstack.org mailing-list, with the subject:
> "[fuel]  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 | smelik...@mirantis.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] Component Leads Elections

[Serg Melikyan]

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@lists.openstack.org mailing-list, with the subject:
"[fuel]  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 | smelik...@mirantis.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] Component Leads elections

[Dmitry Borodaenko]

Fuelers,

Please remember that the open candidacy period for Fuel Component Leads
nominations is now open. It closes in two days, on October 15. [0]

[0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015

We already have one nomination for fuel-python lead [1], thank you Igor
for volunteering!

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/076763.html

We have no nominations for fuel-library lead. Library developers, please
don't be shy and self-nominate yourselves!

Thank you,

-- 
Dmitry Borodaenko

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev