Open Stack

On 07/31/2016 05:59 PM, Fox, Kevin M wrote:
> This sounds good to me.
> 
> What about making it iterative but with a delayed start. Something like:
> 
> There is a grace period of 1 year for projects that newly join the big tent. After which, the following criteria will be evaluated to keep a project in the big tent, evaluated at the end of each OpenStack release cycle to keep the project for the next cycle. The project should not have active cores from one company in the amount greater then 45% of the active core membership. If that number is higher, the project is given notice they are under diverse and have 6 months of remaining in the big tent to show they are attempting to increase diversity by shifting the ratio to a more diverse active core membership. The active core membership percentage by the over represented company, called X%, will be shown to be reduced by 25% or reach 45%, so max(X% * (100%-25%), 45%). If the criteria is met, the project can remain in the big tent and a new cycle will begin. (another notification and 6 months if still out of compliance)
> 
> This should allow projects that are, or become under diverse a path towards working on project membership diversity. It gives projects that are very far out of wack a while to fix it. It basically gives projects over represented:
>  * (80%, 100%] -  gets 18 months to fix it
>  * (60%, 80%] - gets 12 months
>  * (45%, 60%] - gets 6 months
> 
> Thoughts? The numbers should be fairly easy to change to make for different amounts of grace period.
> 
> Thanks,
> Kevin

I strongly disagree with this kind of procedure. A project with a single
vendor can still be a very good addition to the big tent. The tagging
which we already have in place is IMO enough.

Also, rating projects by the % of commits from a single vendor wont cut
it: it's very bad metrics. Let me attempt to take an example to explain
my thoughts.

Let's say company Alice does the biggest majority of patches in project
Bob, which makes her company the top committer by far. If Alice leaves
the project (maybe for personal reasons, or because her company assigned
her to something else), then maybe suddenly, we get the diversity
percentages correct, just because she left and her company's
contribution ratio dropped. Does that makes project Bob healthier just
because she left? I don't think it does. And that's not what our ruleset
should enforce. Our rules should push for more contributions, not less. [1]

If we want to make collaboration going better, it's going to be a social
thing. Attempting to add rules will only make things more complicated
for new projects.

Cheers,

Thomas Goirand (zigo)

[1] I'm not sure I made myself clear here, if I was not, let me know and
I'll attempt to write in a better way.