On 02/08/2016 16:48, Steven Dake (stdake) wrote: > 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.
My point is that we are close to being single vendor - it is a real possibility over then next few months, if a big contributor was to leave the project, which may happen. The obvious solution to avoid this is to increase participation - which is what we are struggling with. >> >> 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. As would I. > 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
