amrith.ku...@gmail.com wrote:
-----Original Message-----
From: Doug Hellmann <d...@doughellmann.com>
Sent: Saturday, June 2, 2018 4:26 PM
To: openstack-dev <openstack-dev@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)
__________________________________________________________________________
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
