Re: [openstack-dev] [tc] [summary] Organizational diversity tag

[Jean-Philippe Evrard]

I think PTLs would naturally like to have those updated, and for me a
TC +w would make sense.
But we need to have guidelines, so that's it's more tangible, and the
subtlety stays impartial.

__
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] [tc] [summary] Organizational diversity tag

[Doug Hellmann]

Excerpts from Jean-Philippe Evrard's message of 2018-06-13 11:04:51 +0200:
> > - Drop tags, write a regular report instead that can account for the
> > subtlety of each situation (ttx). One issue here is that it's obviously a
> > lot more work than the current situation.
> 
> That's what I'd prefer personally.

Who would do that work?

Doug

__
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] [tc] [summary] Organizational diversity tag

[Jean-Philippe Evrard]

> - Drop tags, write a regular report instead that can account for the
> subtlety of each situation (ttx). One issue here is that it's obviously a
> lot more work than the current situation.

That's what I'd prefer personally.

We have a website with a nice project navigator now [1].
This is somewhat a reference IMO, and should always be up to date for
the published releases.

The information is generated, but it could now as well be a static
file/source of truth that we update and peer review manually after a
cycle.
It could allow more flexible and case by case data.

This also make the information easy to find: that's naturally where
I'd go (if I was an end-user) to see information about a project, not
the governance repo.
Although now I have learnt, and I am not sure this is worth spending
much effort.

[1]: https://www.openstack.org/software/project-navigator/

__
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] [tc] [summary] Organizational diversity tag

[Neil Jerram]

On Tue, Jun 12, 2018 at 1:07 PM Thierry Carrez 
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
> 


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
__
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] [tc] [summary] Organizational diversity tag

[Tom Barron]

On 12/06/18 11:44 +0200, Thierry Carrez wrote:

Hi!

We had a decently-sized thread on how to better track organizational 
diversity, which I think would benefit from a summary.


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 wonder if there's a succint way to present the history rather than 
just the most recent tag value.  As a deployer I can then tell the 
difference between a project that consistently lacks 
diverse-affiliation and a project that occasionally or only recently 
lacks diverse-affiliation.




Suggestions included:

- Drop tags, write a regular report instead that can account for the 
subtlety of each situation (ttx). One issue here is that it's 
obviously a lot more work than the current situation.


- Creating a "low-activity" tag that would clearly exempt some teams 
from diversity tagging (mnaser). One issue is that this tag may drive 
contributors away from those teams.


- Drop existing tags, and replace them by voluntary tagging on how 
organizationally-diverse core reviewing is in the team (zaneb). This 
suggestion triggered a sort of side thread on whether this is actually 
a current practice. It appears that vertical, vendor-sensitive teams 
are more likely to adopt such (generally unwritten) rule than 
horizontal teams where hats are much more invisible.


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.


Thoughts on those suggestions? Other suggestions?

--
Thierry Carrez (ttx)

__
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] [tc] [summary] Organizational diversity tag

[Thierry Carrez]

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.


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


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.


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


--
Thierry Carrez (ttx)

__
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] [tc] [summary] Organizational diversity tag

[Neil Jerram]

FWIW, as an outside observer of this conversation:

On Tue, Jun 12, 2018 at 10:46 AM Thierry Carrez 
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.


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

Regards,
 Neil
__
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] [tc] [summary] Organizational diversity tag

[Thierry Carrez]

Hi!

We had a decently-sized thread on how to better track organizational 
diversity, which I think would benefit from a summary.


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.


Suggestions included:

- Drop tags, write a regular report instead that can account for the 
subtlety of each situation (ttx). One issue here is that it's obviously 
a lot more work than the current situation.


- Creating a "low-activity" tag that would clearly exempt some teams 
from diversity tagging (mnaser). One issue is that this tag may drive 
contributors away from those teams.


- Drop existing tags, and replace them by voluntary tagging on how 
organizationally-diverse core reviewing is in the team (zaneb). This 
suggestion triggered a sort of side thread on whether this is actually a 
current practice. It appears that vertical, vendor-sensitive teams are 
more likely to adopt such (generally unwritten) rule than horizontal 
teams where hats are much more invisible.


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.


Thoughts on those suggestions? Other suggestions?

--
Thierry Carrez (ttx)

__
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