One of OpenStack’s unsung heroes recently decided to step into the spotlight.

Tony Breeds was recently voted PTL for Requirements by the community. It’s not the first time he’s been singled out — at the Austin Summit he won a Community Contributor award for his behind-the-scenes contributions.

He talks to Superuser about “gardening” the OpenStack Requirements, how you can get involved and what steps to take to raise your community contributions.

What are the project goals for the Newton release?

For Newton the focus has been on three things:

Verifying that a separate requirements team is viable and energetic
Reducing tech debt in requirements management
Identifying larger multi-release enhancements to the requirements management tools.

We’ve made very good progress on all of these. The third item puts us in a good place for some really focused development in [Ocata.]

What contributions do you need most right now?

The main thing we need from the community is responses to reviews. I’ll explain that a little. Until our gating of requirements changes improves, we’re reaching out to SMEs to help validate specific changes.

We’re trying to strike the right balance between using new libraries while at the same time minimizing the risk. So be on the lookout for pings in Gerrit reviews/IRC. Of course reviews are also good, but beyond that come and talk to us.

If we’re doing something that seems strange it could be strange. The members of the requirements team may not see it without help. Also, if a number of projects all say the same thing that’s a major indicator that we need to change or educate/document.

What’s the best way for people to get involved?

Jump on #openstack-requirements in IRC and say “Hi!” The team there will be very happy to help you get started. Also, review all the things…

Is the work of the requirements team a bit like gardening? If OpenStack were a vegetable garden, you’re making sure the young plants bear fruit and the older ones that have gone to seed get uprooted. What are the most pressing things you’re tending to now?

Oh, definitely mowing the lawn and weeding. We have some awesome tomatoes and we need to make it easier for people to get to them.

You were recognized for your behind-the-scenes contributions – what makes a successful contributor to OpenStack?

That was a really nice surprise! That’s a really tough question to answer as we’re all different. I can explain the mindset I came to OpenStack with:

Respect the community: OpenStack is a very welcoming community and has well established documents around the Code of Conduct, 4 Opens and the TC is also working on describing the underlying principles we share. OpenStack also has it’s own way of doing things. Respect that. Don’t arrive and say “in my $my_project we do X, so I’ll do it that way here”. By all means open a discussion advocating for change but don’t try to force it.
Look for small things you can do: You’ve decided to be a part of the our community. That may because you’re just interested in OpenStack, or it may be because your employer needs OpenStack to be more. Regardless of why, you’re here now. Pick something small to fix to learn how the code and code review works in OpenStack. It’s unrealistic to think you can arrive and land a new major feature in one cycle. As you get more familiar with OpenStack your definition of “small” will get less small…
Help others: FIXME So that pretty much says it all. There are many ways to help. It could be code, re-direction to a better venue to discuss a problem, an introduction to a SME or it could be talking through a bug/issue with someone you don’t know.
Ask for help / admit when you don’t understand. In a similar vein to point 3, but from the other side. If you’re stuck, ask for help or discuss what you do know and ask for help with the parts you don’t. I’ve lost count of the number of times I’ve sent an email along the lines “Hi everyone. I’m seeing this problem. Here are 3 ways I think we can fix it. What have I missed?” and a member of the community has said “Have you thought about this 4th option”. The community benefits as the discussion is public so everyone learns, and you benefit as you get to fix your problem.
Don’t stay in one project: Sure for a while you need to focus, but one of the strengths of our community is the effort invested in keeping things consistent. Once you know how python and gerrit work nothing holds you back from “playing” in other projects.
Don’t stop at OpenStack: If you find a bug and the right place to fix it is in another project. Go fix it, or at the very least file a bug/issue that explains the impact on OpenStack. Doug Hellman and Thierry Carrez gave a [great presentation](http://superuser.openinfra.dev/articles/how-openstack-makes-python-better-and-vice-versa ) that touches on this.
Keep learning: This is really an application of all of the above. There is lots to learn in OpenStack, it keeps things interesting. I guarantee that what you learn today will help you tomorrow. It’ll make something quicker for you (or others) You’ll get cross pollination between projects. An extreme example of this is about a year ago I noticed “Devstack stable/juno fails to install”[1] on openstack-dev. I thought to myself “I don’t know how that works, but how hard can it be.” Now I’m a ‘stable-maint-core’ (Full disclosure I never did get it to work, it was much harder than I thought :D)

That’s a pretty good set of guidelines for any OpenSource project.

Sorry that came across more like a soap-box spiel than I’d intended. Like I said, that’s how I approach it and it seems to have worked for me.

What made you decide to become a PTL – and have a more public role?

With no implied criticism to those before or around me I felt like there is interesting work to be done here and I have the skills and desire to do/direct it!

Cover Photo // CC BY NC

Tags: Interview, Newton