[openstack-dev] [fuel] Component Leads Elections

Vladimir Kozhukalov vkozhukalov at mirantis.com
Fri Mar 25 16:08:49 UTC 2016


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160325/e70de794/attachment.html>


More information about the OpenStack-dev mailing list