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 <amr...@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:std...@cisco.com] > Sent: Tuesday, August 02, 2016 11:45 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [tc] persistently single-vendor projects > > Responses inline: > > On 8/2/16, 8:13 AM, "Hayes, Graham" <graham.ha...@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- > 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 __________________________________________________________________________ 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
