Open Stack

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.