Ildikó Váncsa wants to help you become a better OpenStack contributor.

At the OpenStack Summit taking place this month in Austin, Texas, Ildikó aims to do just that. In her talk, How to Become an Advanced Contributor, she will guide attendees through the steps of navigating the community, including some of the principles, best practices and unwritten rules of contributing to OpenStack.

We caught up with Ildikó before her talk to learn a little bit more about some of the barriers to becoming an effective contributor and how to overcome them.

What do you think the biggest challenge is to turning someone into an OpenStack contributor?

I think this is a complex process and depends on both the person and the project he or she is trying to contribute to. When someone is new to open source, and starts working in a large community like this, there are many skills needed and many lessons to learn. In this sense, I think the biggest challenge in most cases is to make people understand that it is a step-by-step process and they need to be patient with themselves and the community as well and they should not give up trying after the first “bad day.”

After getting through the first obstacles, people are less shy the next big step is to teach them the processes and creating value behind the tools we are using. It is a long way between knowing which button to push in Gerrit, and giving good and valuable reviews.

What is the OpenStack community doing to reduce friction and obstacles for contributors?

There are innumerable amounts of documentation, blog posts, and email threads about best practices, processes, issues, and proposed solutions. Beyond this, it is even more important that the community members are open and available on various forums—IRC, mailing lists, and so forth—to answer any sorts of questions and help. We are also continuously improving the materials available to help the newcomers to find their way to engage.

Are there any examples of best practices which would be helpful for new contributors to know which may not be immediately obvious?

I already mentioned that learning how the tools are working technically is the smaller part of the lesson. I think the list of best practices is almost endless, and you can always add a new item when you ask another person about their experience. In my view, for a new contributor who would like to join a project team in OpenStack, it is very important to understand that we all work on producing a complex software package. It needs maintenance and dirty work, like bug fixes and documentation. We all take part of this and we expect new members to do the same.

Another important part is code reviews. When someone joins a project, the best time spent is doing code reviews and not just checking small patches, but rather choosing larger and more complex changes. By understanding the new code and how it fits they will get a really good overview of the code base of the module. I would also encourage people to check how the patch works, whether it really fixes the bug or implements the planned feature; Devstack provides a really good environment for this. And don’t be afraid to ask questions!

The contributor process for OpenStack is still very much oriented towards a developer’s workflow (git, gerrit, CI processes, etc). Do you think this is a barrier to non-code contributors (for example, documentation)? Does it make sense for everyone to use the same process?

In my view the emphasis is on communication and automation here. As this is a large community, where finding the most efficient ways to provide people the possibility to work together is mostly about finding the right media to collaborate. All our tools and processes are for accelerating team work in a continuously changing environment. You can learn the basics to use Git and Gerrit in a day and you will get a more flexible process than, for instance, sharing Word documents or having the whole team editing the same wiki page in parallel.

I’m participating in another open source community, where we established similar processes as well and in my experience people adapted quite fast as they saw the advantages these tools can offer. I’m not saying that I like resolving merge conflicts on a documentation patch, but I still rather do that in Git and review it in Gerrit than trying to fix a broken Word document without proper change history. So to summarize, I would call this an opportunity to learn something new as opposed to a barrier.

Are there projects where it is “easier” to land a commit than others? What do you think accounts for this difference?

Smaller projects are usually easier to approach. I can tell this by experience, but I also don’t think it will surprise anyone. Larger and more complex projects can easily be overloaded, which introduces delays in review turn around times and makes it harder to land a patch.

On the other hand, it can be just as easy if one chooses task wisely. There are plenty of bugs to fix in every project, there are higher priority activities where more hands are always welcome to join and so forth. I can only encourage people to choose a project that matches their area of interest and find an activity there to join and get involved in the team’s daily life, like IRC discussions or weekly meetings, as well as code reviews and contribution. There is nothing to be afraid of!

Aside from attending your talk, what’s the easiest way for a potential contributor to understand the contribution process and get started?

There are several documentation options available about tools and workflows. People can find information about the first steps to setup their environment and join the OpenStack Foundation. There is also material about How To Contribute on the wiki which provides a good reading to start with. I also found the guidelines of the Nova team very useful. Even if it’s written for Nova you can easily adapt the most parts for other projects as well. I also had a joint talk with Jay Pipes a few Summits back, Tales from the Ship: Navigating the OpenStack Community Seas, which is about contributions as written on paper and in real life. And when someone is finished with all the reading and initial preparation, just jump into the middle and start doing.