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:[email protected]] > Sent: Tuesday, August 02, 2016 11:45 AM > To: OpenStack Development Mailing List (not for usage questions) > <[email protected]> > Subject: Re: [openstack-dev] [tc] persistently single-vendor projects > > Responses inline: > > On 8/2/16, 8:13 AM, "Hayes, Graham" <[email protected]> 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- > [email protected]?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
