[openstack-dev] [tc] persistently single-vendor projects

Flavio Percoco flavio at redhat.com
Wed Aug 3 09:15:44 UTC 2016


On 02/08/16 15:13 +0000, Hayes, Graham 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.
>
>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.
>
>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.
>
>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.
>
>Making grand statements about "work harder on community" without any
>guidance about what we need to work on do not help the community.

Zaqar has had the same issue ever since the project was created. The team has
been actively mentoring folks from the Outreachy program and Google Summer of
code whenever possible.

Folks from other teams have also contributed to the project but sometimes these
folks were also part of the same company as the majority of Zaqar's
contributors, which doesn't help much with this.

It's not until recently that Zaqar has increased its diversity but I believe
it's in the edge and it's also related to the amount (or lack there of) of
adoption it's gotten.

To me, one of the most important items is engaging with mentees from other
programs. I see this also as a way to give back to the communities and the rest
of the world.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160803/8bb8b9eb/attachment.pgp>


More information about the OpenStack-dev mailing list