[openstack-dev] [tc] Organizational diversity tag

Rico Lin rico.lin.guanyu at gmail.com
Fri Jun 8 12:31:56 UTC 2018


IMO, the goal is that we try to encourage the good, not to get in the way
to those who can't reach that goal.

A tag is a good way to encourage, but it also not a fair way for those
projects who barely got enough core member to review (Think about those
projects got less than four active cores). Wondering if anyone got ideas on
how we can reach that goal (tag can be a way, just IMO need to provide a
fair condition to all).

How about we set policy and document to encourage people to join core
reviewer (this can join forces with the Enterprise guideline we plan in
Forum) if they wish to provide diversity to project.

On the second idea, I think TC (or people who powered by TC) should provide
(or guidance project to provide) a health check report for projects. TCs
have been looking for Liaisons with projects ([1]). This definitely is a
good report as a feedback from projects to TC. (also a good way to
understand what each project been doing and is that project need any help).
So to provide a guideline for projects to understand how they can do
better. Guideline means both -1 and  +1 (for who running projects for long
enough to be a core/PTL, should at least understand that -1 only means
since this project is under TC's guidance, we just try to help.). Therefore
a -1 is important.

As an alternative, we can also try to target problem when it occurred, but
personally wonder who as a single core reviewer in team dear to speak out
in this case.

I think this is a hard issue to do, but we have to pick one action from all
actions and try to run and see. And it's better than keep things the way
they are and ignore things.


[1] https://wiki.openstack.org/wiki/Technical_Committee_Tracker#Liaisons

Michael Johnson <johnsomor at gmail.com> 於 2018年6月7日 週四 上午2:48寫道:

> Octavia also has an informal rule about two cores from the same
> company merging patches. I support this because it makes sure we have
> a diverse perspective on the patches. Specifically it has worked well
> for us as all of the cores have different cloud designs, so it catches
> anything that would limit/conflict with the different OpenStack
> topologies.
>
> That said, we don't hard enforce this or police it, it is just an
> informal policy to make sure we get input from the wider team.
> Currently we only have one company with two cores.
>
> That said, my issue with the current diversity calculations is they
> tend to be skewed by the PTL role. People have a tendency to defer to
> the PTL to review/comment/merge patches, so if the PTL shares a
> company with another core the diversity numbers get skewed heavily
> towards that company.
>
> Michael
>
> On Wed, Jun 6, 2018 at 5:06 AM,  <amrith.kumar at gmail.com> wrote:
> >> -----Original Message-----
> >> From: Doug Hellmann <doug at doughellmann.com>
> >> Sent: Monday, June 4, 2018 5:52 PM
> >> To: openstack-dev <openstack-dev at lists.openstack.org>
> >> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
> >>
> >> Excerpts from Zane Bitter's message of 2018-06-04 17:41:10 -0400:
> >> > On 02/06/18 13:23, Doug Hellmann wrote:
> >> > > Excerpts from Zane Bitter's message of 2018-06-01 15:19:46 -0400:
> >> > >> On 01/06/18 12:18, Doug Hellmann wrote:
> >> > >
> >> > > [snip]
> >> > Apparently enough people see it the way you described that this is
> >> > probably not something we want to actively spread to other projects at
> >> > the moment.
> >>
> >> I am still curious to know which teams have the policy. If it is more
> >> widespread than I realized, maybe it's reasonable to extend it and use
> it as
> >> the basis for a health check after all.
> >>
> >
> > A while back, Trove had this policy. When Rackspace, HP, and Tesora had
> core reviewers, (at various times, eBay, IBM and Red Hat also had cores),
> the agreement was that multiple cores from any one company would not merge
> a change unless it was an emergency. It was not formally written down (to
> my knowledge).
> >
> > It worked well, and ensured that the operators didn't get surprised by
> some unexpected thing that took down their service.
> >
> > -amrith
> >
> >
> >
> __________________________________________________________________________
> > 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
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180608/a23a1be3/attachment.html>


More information about the OpenStack-dev mailing list