I am struggling to understand why we would want to remove projects from our big tent at all, as long as they are being actively developed under the principles of "four opens". It seems to me that working to disqualify such projects sends an alarming signal to our ecosystem. The reason we made the big tent to begin with was to set a tone of inclusion. This whole discussion seems like a step backward. What problem are we trying to solve, exactly?
If we want to have tags to signal team diversity, that's fine. We do that now. But setting arbitrary requirements for big tent inclusion based on who participates definitely sounds like a mistake. -- Adrian > On Aug 1, 2016, at 5:11 AM, Sean Dague <s...@dague.net> wrote: > >> On 07/31/2016 02:29 PM, Doug Hellmann wrote: >> Excerpts from Steven Dake (stdake)'s message of 2016-07-31 18:17:28 +0000: >>> Kevin, >>> >>> Just assessing your numbers, the team:diverse-affiliation tag covers what >>> is required to maintain that tag. It covers more then core reviewers - >>> also covers commits and reviews. >>> >>> See: >>> https://github.com/openstack/governance/blob/master/reference/tags/team_div >>> erse-affiliation.rst >>> >>> >>> I can tell you from founding 3 projects with the team:diverse-affiliation >>> tag (Heat, Magnum, Kolla) team:deverse-affiliation is a very high bar to >>> meet. I don't think its wise to have such strict requirements on single >>> vendor projects as those objectively defined in team:diverse-affiliation. >>> >>> But Doug's suggestion of timelines could make sense if the timelines gave >>> plenty of time to meet whatever requirements make sense and the >>> requirements led to some increase in diverse affiliation. >> >> To be clear, I'm suggesting that projects with team:single-vendor be >> given enough time to lose that tag. That does not require them to grow >> diverse enough to get team:diverse-affiliation. > > The idea of 3 cycles to loose the single-vendor tag sounds very > reasonable to me. This also is very much along the spirit of the tag in > that it should be one of the top priorities of the team to work on this. > I'd be in favor. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
