<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 29, 2018 at 5:51 AM, Mohammed Naser <span dir="ltr"><<a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, May 29, 2018 at 7:59 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br>
> Mohammed Naser wrote:<br>
>><br>
>> During the TC retrospective at the OpenStack summit last week, the<br>
>> topic of the organizational diversity tag is becoming irrelevant was<br>
>> brought up by Thierry (ttx)[1].  It seems that for projects that are<br>
>> not very active, they can easily lose this tag with a few changes by<br>
>> perhaps the infrastructure team for CI related fixes.<br>
>><br>
>> As an action item, Thierry and I have paired up in order to look into<br>
>> a way to resolve this issue.  There have been ideas to switch this to<br>
>> a report that is published at the end of the cycle rather than<br>
>> continuously.  Julia (TheJulia) suggested that we change or track<br>
>> different types of diversity.<br>
>><br>
>> Before we start diving into solutions, I wanted to bring this topic up<br>
>> to the mailing list and ask for any suggestions.  In digging the<br>
>> codebase behind this[2], I've found that there are some knobs that we<br>
>> can also tweak if need-be, or perhaps we can adjust those numbers<br>
>> depending on the number of commits.<br>
><br>
><br>
> Right, the issue is that under a given level of team activity, there is a<br>
> lot of state flapping between single-vendor, no tag, and<br>
> diverse-affiliation. Some isolated events (someone changing affiliation, a<br>
> dozen of infra-related changes) end up having a significant impact.<br>
><br>
> My current thinking was that rather than apply a mathematical rule to<br>
> produce quantitative results every month, we could take the time for a<br>
> deeper analysis and produce a qualitative report every quarter.<br>
<br>
</span>I like this idea, however...<br>
<span><br>
> Alternatively (if that's too much work), we could add a new team tag<br>
> (low-activity ?) that would appear for all projects where the activity is so<br>
> low that the team diversity tags no longer really apply.<br>
<br>
</span>I think as a first step, it would be better to look into adding a<br>
low-activity team that so that anything under X number of commits<br>
would fall under that tag.  I personally lean towards this because<br>
it'll be a useful indication for consumers of deliverables of these<br>
projects, because I think low activity is just as important as<br>
diversity/single-vendor driven projects.<br>
<br>
The only thing I have in mind is the possible 'feeling' for projects<br>
which are very stable, quiet and functioning to end up with<br>
low-activity tag, giving an impression that they are unmaintained.  I<br>
think in general most associate low activity = unmaintained.. but I<br>
can't come up with any better options either.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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'.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Best,</div><div>Samuel Cassiba (scas)<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_8104775012652467817HOEnZb"><div class="m_8104775012652467817h5"><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>