Open Stack

Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400:
> On 26/05/18 17:46, Mohammed Naser wrote:
> > Hi everyone!
> > 
> > During the TC retrospective at the OpenStack summit last week, the
> > topic of the organizational diversity tag is becoming irrelevant was
> > brought up by Thierry (ttx)[1].  It seems that for projects that are
> > not very active, they can easily lose this tag with a few changes by
> > perhaps the infrastructure team for CI related fixes.
> > 
> > As an action item, Thierry and I have paired up in order to look into
> > a way to resolve this issue.  There have been ideas to switch this to
> > a report that is published at the end of the cycle rather than
> > continuously.  Julia (TheJulia) suggested that we change or track
> > different types of diversity.
> > 
> > Before we start diving into solutions, I wanted to bring this topic up
> > to the mailing list and ask for any suggestions.  In digging the
> > codebase behind this[2], I've found that there are some knobs that we
> > can also tweak if need-be, or perhaps we can adjust those numbers
> > depending on the number of commits.
> 
> Crazy idea: what if we dropped the idea of measuring the diversity and 
> allowed teams to decide when they applied the tag to themselves like we 
> do for other tags. (No wait! Come back!)
> 
> Some teams enforce a requirement that the 2 core +2s come from reviewers 
> with different affiliations. We would say that any project that enforces 
> that rule would get the diversity tag. Then it's actually attached to 
> something concrete, and teams could decide for themselves when to drop 
> it (because they would start having difficulty merging stuff otherwise).
> 
> I'm not entirely sold on this, but it's an idea I had that I wanted to 
> throw out there :)
> 
> cheers,
> Zane.
> 

The point of having the tags is to help consumers of the projects
understand their health in some capacity. In this case we were
trying to use measures of actual activity within the project to
help spot projects that are really only maintained by one company,
with the assumption that such projects are less healthy than others
being maintained by contributors with more diverse backing.

Does basing the tag definition on whether approvals need to come
from people with diverse affiliation provide enough project health
information that it would let us use it to replace the current tag?

How many teams enforce the rule you describe?

Is that rule a sign of a healthy team dynamic, that we would want
to spread to the whole community?

Doug