On 8/1/16, 8:38 AM, "Doug Hellmann" <d...@doughellmann.com> wrote:
>Excerpts from Adrian Otto's message of 2016-08-01 15:14:48 +0000: >> 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. > >Membership in the big tent comes with benefits that have a real >cost born by the rest of the community. Space at PTG and summit >forum events is probably the one that's easiest to quantify and to >point to as something limited that we want to use as productively >as possible. If 90% of the work of a project is being done by a >single company or organization (our current definition for >single-vendor), and that doesn't change after 18 months, then I >would take that as a signal that the community isn't interested >enough in the project to bear the associated costs. > >I'm interested in hearing other reasons that we should keep these >sorts of projects, though. I'm not yet ready to propose the change >to the policy myself. Doug, As a community, we need to carefully consider this action. The costs to OpenStack are high for single vendor projects but they do add value if they behave with community in mind. I don't think removal from Big Tent is all that big of a deal as long as the projects can still participate in the openstack namespace and use gerrit/ci and still be part of OpenStack as you have previously stated. My biggest concern is some projects are really trying hard to increase their diversity while others are not trying so much. Unfortunately measuring intent objectively is difficult. I severely dislike exceptions, but perhaps projects could apply for exceptions to this policy change if they are actively digging out of single vendor by their activities. Forgive me for singling out a single project, but deployment is where I've spent the last 3 years of my life and have an intimate understanding of what is happening in these communities. For example tripleo is single-vendor, but is doing all the right things to dig out of single vendor by doing actual community building. They aren't just trying, but are trying *very* hard with their activities. They have the right intent but how to measure intent objectively? That would be my major concern. There are more single vendor projects then non-single-vendor projects (the last time I looked which was several months ago) covering many areas, so tripleo is just one example of many that may be doing the right things to build more diverse affiliations. I don't have any insight into the community building going on in various communities outside of deployment - perhaps some of those teams PTLs could weigh in on this thread? All that said the proposal for 18 months is super generous; Nearly any project can dig out of single vendor in a 18 month window if they prioritize it. It would be better for these projects in the long run to prioritize moving to more diversity for a whole slew of reasons. In my 20 years of training, team affiliation diversity is _more_ important than starting from an empty repository and is a best practice. To fix the problem, perhaps another tag is needed - something between single-vendor and diverse-affilliation (spitball - single-vendor-with-diverse-affiliation. Single-vendor would have an 18 month window associated with it, while the new tag would guarantee big tent as long as the objective 90% percentages were maintained. The only problem there is that could put OpenStack back on an incubation/integration track which from my experience with founding Heat was a serious hurdle for OpenStack in general and Ceilometer and Heat specifically. Regards, -steve > >Doug > >> >> -- >> 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_d >>iv >> >>> 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 __________________________________________________________________________ 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