Open Stack

On Tue, May 29, 2018 at 5:51 AM, Mohammed Naser <mnaser at vexxhost.com> wrote:

> On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
> > 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.
>
> I like this idea, however...
>
> > 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.
>
> I think as a first step, it would be better to look into adding a
> low-activity team that so that anything under X number of commits
> would fall under that tag.  I personally lean towards this because
> it'll be a useful indication for consumers of deliverables of these
> projects, because I think low activity is just as important as
> diversity/single-vendor driven projects.
>
> The only thing I have in mind is the possible 'feeling' for projects
> which are very stable, quiet and functioning to end up with
> low-activity tag, giving an impression that they are unmaintained.  I
> think in general most associate low activity = unmaintained.. but I
> can't come up with any better options either.
>

This seems like my cue. It's unfortunate that I could not be in Vancouver
last week to discuss this, and I don't want to give the wrong impression,
but here goes. Putting my own interests up front: if openstack-chef, a
relatively quiet subproject, with a reasonably stable codebase and
measurable user base, were to be suddenly be labeled with 'low-activity',
then openstack-chef, and I imagine others in a similar situation, surely
would be considered as dead as some perceptions have suggested in the past.
The wrong perceptions can make open source contributions increasingly more
difficult to obtain and maintain over time, making 'low-activity' a
self-fulfilling prophecy and not a particularly helpful metric. For the
record, openstack-chef has no tags at all, even though we may have at some
point qualified for organizational diversity on paper.

The problem with any label close to the idea of things declining is that
the perception would be more overt than it is if we were to put our
collective heads in the sand, unable to come to an accord. Hearken to
Glance (a core project!) being barely able to make a release due to rapid
developer decline over a cycle. Consider the more recently talked about
people-formerly-known-as-docs-team, or the lesser known projects with
contributors from a couple of companies struggling to get and maintain
exposure, and the ones that lag behind core by a release (hi!) just because
it takes that long to get to the next one. Brand any or all of them
'low-activity' with the best of intentions of identifying the ones that
need love, and that's more or less signaling their end of life, since
'nobody' wants to touch that janky, unmaintained abandonware with 'no
activity'.

The moniker of 'low-activity' does give the very real, negative perception
that things are just barely hanging on. It conveys the subconscious,
officiated statement (!!!whether or not this was intended!!!) that nobody
in their right mind should consider using the subproject, let alone develop
on or against it, for fear that it wind up some poor end-user's support
nightmare. Having quietly served as PTL for four cycles -- sometimes not as
quietly as others -- I've struggled with the notions of contributorship
versus maintainership. After this long at it, experience says a bunch of
well-intended contributors does not a maintained project make, unless their
heads can be in the right place (or wrong, depending on how salty you get
by reading this far) to consider it as such.

I really wish I had a good label for projects like openstack-chef, but
labels can be extremely caustic if misinterpreted, even applied with the
best of intentions. Things like 'needs-volunteers' come to mind, but that's
still casting things somewhat negatively, more akin to digital panhandling.
The end result should be a way of identifying the need for more investment
with a more positive inference in the public view, instead of the negative
connotations of 'low-activity'. Even 'maintenance-mode' paints negative
perceptions. Do YOU want to touch that janky, unmaintained stuff? Neither
do I.

To back down off my soapbox, the fact that projects are losing the
organizational diversity tag seems more a symptom of unwellness in what is
being measured, not necessarily irrelevance of the metric. Measuring in
terms of throughput and number of contributors is one thing, but the
outcome of the measure needs to feed back into better maintainership for
the overall health of OpenStack as a collection of open source projects.
Some of the destined 'low-activity' projects would do quite well with an
extra couple of part-timers if they aren't framed as being on the
proverbial junk pile.

Best,
Samuel Cassiba (scas)



> > --
> > Thierry Carrez (ttx)
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.op
> enstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180529/76fb802e/attachment.html>