If you want to be an awesome OpenStack contributor, there’s a formula for that.

So says Adrian Otto, who should know. Otto is a distinguished architect at Rackspace, chairman of the OpenStack containers team, current project team lead (PTL) for Magnum and launched the Solum project back in 2013.

Offering a “money-back guarantee” in his recent talk at the OpenStack Summit Vancouver, where two-thirds of the participants who came to hear him hadn’t contributed yet, Otto outlined these seven habits that distinguish the best from the rest in the community.

If you incorporate these habits, he says, you have a shot at becoming a core reviewer and will “have a whole new level of influence over where the project goes.” You can watch his 40-minute talk here.

Use Internet Relay Chat (IRC)

Get the software and set yourself up for IRC to fire up every time you turn on or log into your computer. That way, if someone is trying to get your attention, you’ll know. “Your chat client is how people are going to interact with you,” Otto says. “We really don’t use a lot of email back-and-forth.” He broke participation down further into four simple steps: idle, greet, ask and answer.

Attend meetings

Every team in OpenStack, which includes every project in OpenStack, has a regularly recurring meeting, usually weekly. “You need to show up to these meetings, religiously, every single time.”

Participate in the meeting, pay attention to what’s going on. “That’s your most up-to-date, reliable way to learn what’s happening.” The agendas are published ahead of time online, too. All the project announcements are made there, and, he adds, if you have patches that require team discussion, that’s where the discussion is going to happen. “Treat that meeting time as a priority, block that time out on your calendar.”

Use mailing the lists

There’s another habit that is make or break, Otto says: “You have got to read the mailing list.” Start with the OpenStack Development Mailing List. Any project that you’re involved with has a topic tag, usually the name of the project in brackets like this: [Neutron] He recommends filtering the lists, so you only subscribe to messages that interest you. “I would set up a filter in my mailman configuration when I subscribe to the mailing list, so that I only see stuff about Magnum and Solum and Keystone and other things that happen to be working on right now.” He further filters the messages with his email client by using keywords to put the topics that interest him directly in his inbox. Again, remember to go beyond lurking. “If you have something meaningful to say, don’t just think it to yourself. Make sure you make a reply on there, that your input is recorded.”

Do code reviews

“It doesn’t have to be two hours a day, it can be 10 minutes a day. Whatever it is, allocate some time where you look at reviews every day,” Otto advises.

The reason for spending your time daily? It’s not just so you’re helping with the voting to indicate what should be merged and what shouldn’t be merged. You’ll become a better programmer by seeing what all the other awesome developers are doing and you’ll see almost everything that goes into the project, so “you’ll have a very, very acute picture in your mind of the current state of the code.” Otto reckons he spent about an hour a day on the two projects he’s overseen as PTL – overseeing a combined 4,000 commits or patchsets. “If you could allocate 30 minutes a day to do code reviews, that would be huge.”

Use bug tickets

Bug tickets are not necessarily defects, he says, but a bug ticket is something that “needs to be worked on, a task-level thing.” Bug tickets can also be tagged for defects, tech debt or “wish list,” and that’s a good place to go for new contributors who want to make an impact right away.

Remember to tie your commit to something — by using the word “blueprint” and the project name in the commit message, so you’re linked to a bug or a blueprint, every single time. “If you do that, getting credit for to your work will be very easy,” he says. “It makes it very easy to quantify your contribution. If you just have something coming out a left field and you make a a patch for it and it’s not linked back to anything, chances are people will ask, ‘What is this’?” The whole process takes about 45 seconds, he says, adding that you don’t have to wait for a bug to be triaged to link it to your commit.

Use blueprints

Got an idea for feature? Open a blueprint: the blueprint has a title, a description, a place to tie a specification document, and it has workflow information (status, implementation etc.) You can also check out the blueprints looking for something to do when you’re just getting started, Otto says. When someone “owns” the blueprint, it means they’re responsible for reporting back during meetings on the status of that blueprint, they don’t need to do all the work, sometimes four or five people can be working on the same one.

Write code

Last but definitely not least: write code!

“Write code and consistently write code,” Otto says. “Your code does not need to be Python code, it does not need to be Go code. It can be as simple as documentation that improves the setup instructions for the software,” he says. “Those kinds of contributions, in my opinion, are equally valuable.”

This is one daily habit, Otto says, that distinguishes the superstars from everyone else. It doesn’t have to be a big thing – pick out a bug, do a quick fix, and depending on how fast they’re merging, some of the OpenStack all-stars can have four or five patches in flight. Whether you’re working on OpenStack full or part-time, find a cadence that works for you and stick to it.

“You want to have your commits rolling on a regular basis,” he says. “The best OpenStack contributors I’ve ever seen make at least one commit, every single day.”

Cover Photo by Ludosphere // CC BY NC