Open Stack

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.

-amrith

> -----Original Message-----
> From: Jeremy Stanley <fungi at yuggoth.org>
> Sent: Tuesday, May 29, 2018 5:43 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] Organizational diversity tag
> 
> On 2018-05-29 13:17:50 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > We have the status:maintenance-mode tag[3] today. How would a new
> > "low-activity" tag be differentiated from the existing one?
> [...]
> 
> status:maintenance-mode is (as it says on the tin) a subjective indicator
that
> a team has entered a transient period of reduced activity. By contrast, a
low-
> activity tag (maybe it should be something more innocuous like low-churn?)
> would be an objective indicator that attempts to make contributor
diversity
> assertions are doomed to fail the statistical significance test. We could
> consider overloading status:maintenance-mode for this purpose, but some
> teams perhaps simply don't have large amounts of code change ever and
> that's just a normal effect of how they operate.
> --
> Jeremy Stanley