Open Stack

> On 02 Aug 2016, at 17:13, 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.
> 
> 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.
> 
> - Graham
> 
> 

Interesting thread… it raises some questions for me

- Some projects in the big tent are inter-related. For example, if we identify a need for a project in our production cloud, we contribute a puppet module upstream into the openstack-puppet project. If the project is then evicted, does this mean that the puppet module would also be removed from the puppet openstack project ? Documentation repositories ? 

- Operators considering including a project in their cloud portfolio look at various criteria in places like the project navigator. If a project does not have diversity, there is a risk that it would not remain in the big tent after an 18 month review of diversity. An operator may therefore delay their testing and production deployment of that project which makes it more difficult to achieve the diversity given lack of adoption.

I think there is a difference between projects which are meeting a specific set of needs with the user community but are not needing major support and one which is not meeting the 4 opens. We’ve really appreciated projects which solve a need for us such as EC2 API and RDO which have been open but also had significant support from a vendor. They could have improved their diversity by submitting less commits to get the percentages better...

Tim

> __________________________________________________________________________
> 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