Mohammed Naser wrote:
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.
Right, the issue is that under a given level of team activity, there is
a lot of state flapping between single-vendor, no tag, and
diverse-affiliation. Some isolated events (someone changing affiliation,
a dozen of infra-related changes) end up having a significant impact.
My current thinking was that rather than apply a mathematical rule to
produce quantitative results every month, we could take the time for a
deeper analysis and produce a qualitative report every quarter.
Alternatively (if that's too much work), we could add a new team tag
(low-activity ?) that would appear for all projects where the activity
is so low that the team diversity tags no longer really apply.
--
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
