[openstack-dev] [tc] persistently single-vendor projects
Doug Hellmann
doug at doughellmann.com
Mon Aug 1 15:38:32 UTC 2016
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
>
> --
> Adrian
>
> > On Aug 1, 2016, at 5:11 AM, Sean Dague <sean at 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-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list