Open Stack

amrith.kumar at gmail.com wrote:
>> -----Original Message-----
>> From: Doug Hellmann <doug at doughellmann.com>
>> Sent: Saturday, June 2, 2018 4:26 PM
>> To: openstack-dev <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
>>
>> Excerpts from amrith.kumar's message of 2018-06-02 15:06:27 -0400:
>>> Every project on the one-way-trip to inactivity starts with what some
>>> people will wishfully call a 'transient period' of reduced activity.
>>> Once the transient nature is no longer the case (either it becomes
>>> active or the transient becomes permanent) the normal process of
>>> eviction can begin. As the guy who came up with the maintenance-mode
>>> tag, so as to apply it to Trove, I believe that both the diversity tag
>>> and the maintenance mode tag have a good reason to exist, and should
>>> both be retained independent of each other.
>>>
>>> The logic always was, and should remain, that diversity is a measure
>>> of wide multi-organizational support for a project; not measured in
>>> the total volume of commits but the fraction of commits. There was
>>> much discussion about the knobs in the diversity tag measurement when
>>> Flavio made the changes some years back. I'm sorry I didn't attend the
>>> session in Vancouver but I'll try and tune in to a TC office hours
>>> session and maybe get a rundown of what precipitated this decision to
>> move away from the diversity tag.
>>
>> We're talking about how to improve reporting on diversity, not stop doing it.
> 
> Why not just automate the thing that we have right now and have something kick a review automatically if the diversity in a team changes (per current formula)?

That is what we did: get the thing we have right now to propose changes. 
But we always had a quick human pass to check that what the script 
proposed corresponded to a reality. Lately (with lower activity in a 
number of teams), more and more automatically-proposed changes did not 
match a reality anymore, to the point where a majority of the proposed 
changes need to be dropped.

Example: a low-activity single-vendor project team suddenly loses the 
tag because one person pushes a patch to fix zuul jobs and another 
pushes a doc build fix.

Example 2: a team with 3 core reveiwers flaps between diverse 
affiliation and single-vendor depending on who does the core reviewing 
on its 3 patches per month.

Hence the suggestion to either improve our metrics to better support 
low-activity teams, or switch to a more qualitative/prose report instead 
of quantitative/tags.

-- 
Thierry Carrez (ttx)