Open Stack

On Tue, Jun 12, 2018 at 1:07 PM Thierry Carrez <thierry at openstack.org>
wrote:

> Neil Jerram wrote:
> >>     The issue is that the current method (which uses a formula to apply
> >>    single-vendor and diverse-affiliation tags) is not working so well
> >>    anymore, with lots of low-activity projects quickly flapping between
> >>    states.
> >
> > I think you need to explore and state much more explicitly why this is a
> > problem, before you will be able to evaluate possible changes.
>
> Right, this was just a summary, we discussed it in more details in the
> thread and during that Forum session.
>

Honestly - FWIW - I do not recall much (any?) discussion of what the actual
problem is, in the recent message thread.  (But I wasn't at the Forum, and
I may well have missed or forgotten some of the discussion, of course.)


> For example, a single-vendor project would suddenly lose the tag due to
> a combination of low activity and infra people pushing boilerplate
> change to their test jobs. Yet the project is still very much
> single-vendor (and not seeing much activity).
>

That is just a restatement of the presumed-problematic observation.  It
doesn't take us any further in understanding whether it's an actual problem
for anyone.


>
> The way we ended up working around that in past cycles is by doing a
> human pass on the calculated results and assess whether the change is
> more of a data artifact due to low activity, or a real trends. If it was
> deemed an artifact, we'd not commit that change. But lately most of the
> changes had to be filtered by a human, which basically makes the
> calculation useless.
>
> >>     One important thing to remember is that the diversity tags are
> supposed
> >>    to inform deployers, so that they can make informed choices on which
> >>    component they are comfortable to deploy. So whatever we come up
> with,
> >>    it needs to be useful information for deployers, not just a badge of
> >>    honor for developers, or a statement of team internal policy.
> >
> > It sounds like this might be part of that 'why'.  How sure are you about
> it?
>
> How sure am I about... what? That tags are meant to be useful to
> deployers and the rest of our downstream consumers ? That is part of the
> original definition[1] of a tag. The template to define tags even
> includes a "rationale" section that is meant to justify how the
> ecosystem benefits from having this tag defined.
>

I meant: how sure are you that your intended audience (deployers)
substantially cares about this organizational diversity tag?  Enough to
justify all the cycles that OpenStack's core brains are spending on this
topic.

I'm sorry that I'm probably sounding so negative; please consider that I'm
taking a devil's advocate position here in an attempt to clarify the real
problem.


> [1]
>
> https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.hsubstantially tml#provide-a-precise-taxonomy-to-help-navigating-the-ecosystem
> <https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html#provide-a-precise-taxonomy-to-help-navigating-the-ecosystem>


Please note: that governance text on its own is not sufficient to mandate
concern about this particular organizational diversity tag, if I am reading
it correctly.  Or to put it another way, it looks like it would be entirely
consistent with that text if you said "we're not sure if anyone actually
cares much about this particular tag; let's stop generating it and see if
any of our deployers complain."

Regards,
     Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180612/be938872/attachment.html>