<div dir="ltr"><p dir="ltr"><br>
Le 20 févr. 2016 18:12, "Steven Dake (stdake)" <<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>> a écrit :<br>
><br>
> Hey folks,<br>
><br>
> Mirantis has been developing a big footprint in the core review team, and Red Hat already has a big footprint in the core review team.  These are all good things, but I want to avoid in the future a situation in which one company has a majority of core reviewers.  Since core reviewers set policy for the project, the project could be harmed if one company has such a majority.  This is one reason why project diversity is so important and has its own special snowflake tag in the governance repository.<br>
><br>
> I'd like your thoughts on how to best handle this situation, before I trigger  a vote we can all agree on.<br>
><br>
> I was thinking of something simple like:<br>
> "1 company may not have more then 33% of core reviewers.  At the conclusion of PTL elections, the current cycle's 6 months of reviews completed will be used as a metric to select the core reviewers from that particular company if the core review team has shrunk as a result of removal of core reviewers during the cycle."<br>
><br>
> Thoughts, comments, questions, concerns, etc?</p><p dir="ltr"><br></p>
<p>I think that introducing this policy would not be fair and would even be counter-productive. For example, my motivation would be low if I knew I couldn't be accepted as a core reviewer because my company already has "too many" core reviewers.  So this policy would close the doors to developers who could potentially be great contributors to the success of the project.  If anything, a policy where "2 people from the same company should not approve a third person from that same company's patch" (as stated by Sam Yaple) would sound more acceptable to me.<br></p><p dir="ltr"><br></p><p dir="ltr"><br></p>
</div>