Open Stack

Hi,

As current PTL of one of the projects that has the team:single-vendor tag,
I have following thoughts/questions on this issue.

- Is the need for periodically deciding membership in the big tent primarily stemming
from the question of managing resources (for the future design summits and cross-project work)?
If so, have we thought about alternative solutions such, say, using the team:diverse-affiliation
tag for making such decisions? For instance, we could say that a project will get
space at the design summit only if it has the team:diverse-affiliation tag? That way, projects
are incentivized to purse this tag/goal if they want to participate in the design summit.
Also, adding/removing tag might be simpler than trying to get into big tent again (say, after a project
has been removed and then gains diverse affiliation afterwards and wants to participate in the
design summit, would they have to go through big tent application again?).

- Another issue with using the number of vendors as a metric 
to decide membership in big tent is that it rules out any project which may be 
independently started in the open (not by any specific vendor, but by a team of independent contributors),
and which is following the 4 opens, to be a part of the big tent.

- About diversity -- as Flavio has suggested on this thread, participating in Outreachy is a good option.
We have done it in Solum. However, that does not necessarily help with obtaining the diverse-affiliation
tag as defined currently (since Outreachy participants are students and not necessarily affiliated with
any vendor).

Regards,
Devdatta


________________________________________
From: Amrith Kumar <amrith at tesora.com>
Sent: Wednesday, August 3, 2016 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] persistently single-vendor projects

To Steven's specific question:

> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.

I would like to participate and help get this kind of a group going.

-amrith


> -----Original Message-----
> From: Steven Dake (stdake) [mailto:stdake at cisco.com]
> Sent: Tuesday, August 02, 2016 11:45 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc] persistently single-vendor projects
>
> Responses inline:
>
> On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.hayes at hpe.com> wrote:
>
> >On 02/08/2016 15:42, Flavio Percoco wrote:
> >> On 01/08/16 10:19 -0400, Sean Dague wrote:
> >>> On 08/01/2016 09:58 AM, Davanum Srinivas wrote:
> >>>> Thierry, Ben, Doug,
> >>>>
> >>>> How can we distinguish between. "Project is doing the right thing,
> but
> >>>> others are not joining" vs "Project is actively trying to keep people
> >>>> out"?
> >>>
> >>> I think at some level, it's not really that different. If we treat
> them
> >>> as different, everyone will always believe they did all the right
> >>> things, but got no results. 3 cycles should be plenty of time to drop
> >>> single entity contributions below 90%. That means prioritizing bugs /
> >>> patches from outside groups (to drop below 90% on code commits),
> >>> mentoring every outside member that provides feedback (to drop below
> >>>90%
> >>> on reviews), shifting development resources towards mentoring / docs /
> >>> on ramp exercises for others in the community (to drop below 90% on
> >>>core
> >>> team).
> >>>
> >>> Digging out of a single vendor status is hard, and requires making
> that
> >>> your top priority. If teams aren't interested in putting that ahead of
> >>> development work, that's fine, but that doesn't make it a sustainable
> >>> OpenStack project.
> >>
> >>
> >> ++ to the above! I don't think they are that different either and we
> >>might not
> >> need to differentiate them after all.
> >>
> >> Flavio
> >>
> >
> >I do have one question - how are teams getting out of
> >"team:single-vendor" and towards "team:diverse-affiliation" ?
> >
> >We have tried to get more people involved with Designate using the ways
> >we know how - doing integrations with other projects, pushing designate
> >at conferences, helping DNS Server vendors to add drivers, adding
> >drivers for DNS Servers and service providers ourselves, adding
> >features - the lot.
> >
> >We have a lot of user interest (41% of users were interested in using
> >us), and are quite widely deployed for a non tc-approved-release
> >project (17% - 5% in production). We are actually the most deployed
> >non tc-approved-release project.
> >
> >We still have 81% of the reviews done by 2 companies, and 83% by 3
> >companies.
>
> By the objective criteria of team:single-vendor Designate isn't a single
> vendor project.  By the objective criteria of team:diverse-affiliation
> your not a diversely affiliated project either.  This is why I had
> suggested we need a third tag which accurately represents where Designate
> is in its community building journey.
> >
> >I know our project is not "cool", and DNS is probably one of the most
> >boring topics, but I honestly believe that it has a place in the
> >majority of OpenStack clouds - both public and private. We are a small
> >team of people dedicated to making Designate the best we can, but are
> >still one company deciding to drop OpenStack / DNS development from
> >joining the single-vendor party.
>
> Agree Designate is important to OpenStack.  But IMO it is not a single
> vendor project as defined by the criteria given the objective statistics
> you mentioned above.
>
> >
> >We are definitely interested in putting community development ahead of
> >development work - but what that actual work is seems to difficult to
> >nail down. I do feel sometimes that I am flailing in the dark trying to
> >improve this.
>
> Fantastic its a high-prioiirty goal.  Sad to hear your struggling but
> struggling is part of the activity.
> >
> >If projects could share how that got out of single-vendor or into
> >diverse-affiliation this could really help teams progress in the
> >community, and avoid being removed.
>
> You bring up a fantastic point here - and that is that teams need to share
> techniques for becoming multi-vendor and some day diversely affiliated.  I
> am a super busy atm, or I would volunteer to lead a cross-project effort
> with PTLs to coordinate community building from our shared knowledge pool
> of expert Open Source contributors in the wider OpenStack community.
>
> That said, I am passing the baton for Kolla PTL at the conclusion of
> Newton (assuming the leadership pipeline I've built for Kolla wants to run
> for Kolla PTL), and would be pleased to lead a cross project effort in
> Occata on moving from single-vendor to multi-vendor and beyond if there is
> enough PTL interest.  I take mentorship seriously and the various single
> vendor (and others) PTL's won't be disappointed in such an effort.
>
> >
> >Making grand statements about "work harder on community" without any
> >guidance about what we need to work on do not help the community.
>
> Agree - lets fix that.  Unfortunately it can't be fixed in an email thread
> - it requires a cross-project team based approach with atleast 6 months of
> activity.
>
> If PTLs can weigh in on this thread and commit to participation in such a
> cross-project subgroup, I'd be happy to lead it.
>
> Regards
> -steve
>
>
> >
> >- Graham
> >
> >
> >_________________________________________________________________________
> _
> >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
>
>
> __________________________________________________________________________
> 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

__________________________________________________________________________
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