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. __________________________________________________________________________ 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
