On 01/06/18 12:18, Doug Hellmann wrote:
Excerpts from Zane Bitter's message of 2018-06-01 10:10:31 -0400:
Crazy idea: what if we dropped the idea of measuring the diversity and
allowed teams to decide when they applied the tag to themselves like we
do for other tags. (No wait! Come back!)
Some teams enforce a requirement that the 2 core +2s come from reviewers
with different affiliations. We would say that any project that enforces
that rule would get the diversity tag. Then it's actually attached to
something concrete, and teams could decide for themselves when to drop
it (because they would start having difficulty merging stuff otherwise).
I'm not entirely sold on this, but it's an idea I had that I wanted to
throw out there :)
cheers,
Zane.
The point of having the tags is to help consumers of the projects
understand their health in some capacity. In this case we were
trying to use measures of actual activity within the project to
help spot projects that are really only maintained by one company,
with the assumption that such projects are less healthy than others
being maintained by contributors with more diverse backing.
(Clarification for readers: there are actually 3 levels; getting the
diverse-affiliations tag has a higher bar than dropping the
single-vendor tag.)
Does basing the tag definition on whether approvals need to come
from people with diverse affiliation provide enough project health
information that it would let us use it to replace the current tag?
Yes. Project teams will soon drop this rule if it's the only way to get
patches in. A single-vendor project by definition cannot adopt this rule
and continue to... exist as a project, really.
It would tell potential users that if one organisation drops out it
there is at least somebody left to review patches, and also guarantee
that the project's direction is not down to the whim of one organisation.
How many teams enforce the rule you describe?
I don't know.
I do know that in Heat we never enforced it - at first because it was a
single-vendor project, and then later because it was so diverse (and not
subject to any particular cross-company animosity) that nobody
particularly saw the need to change, and now that many of those vendors
have pulled out of OpenStack because it would be an obstacle to getting
patches approved again.
I was kind of under the impression that all of the projects used this
rule prior to Heat and Ceilometer being incubated. That may be
incorrect. At least Nova and the projects that have a lot of vendor
drivers (and are thus susceptible to suspicions of bias) - i.e. Cinder &
Neutron mainly - may still follow this rule? I haven't yet found a
mention of it in any of the contributor guides though, so possibly it
was dropped OpenStack-wide and I never noticed.
Is that rule a sign of a healthy team dynamic, that we would want
to spread to the whole community?
Yeah, this part I am pretty unsure about too. For some projects it
probably is. For others it may just be an unnecessary obstacle, although
I don't think it'd actually be *un*healthy for any project, assuming a
big enough and diverse enough team (which should be a goal for the whole
community).
For most projects with small core teams it would obviously be a
showstopper, but the idea would be for them to continue to opt out.
cheers,
Zane.
__________________________________________________________________________
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
