A newcomer’s guide to navigating OpenStack Infrastructure

New contributors to OpenStack are welcome, but having a road map for navigating within this maturing, fast-paced open source community doesn't hurt. At OpenStack Summit in Austin, Paul Belanger (Red Hat, Inc.), Elizabeth K. Joseph (HPE), and Christopher Aedo (IBM) will lead a session on OpenStack Infrastructure for Beginners. In this interview, they offer tips and resources to help onboard new OpenStack contributors.

Elizabeth K. Joseph (EKJ): We don't use GitHub for OpenStack patches. This is something that trips up a lot of new contributors because we do maintain mirrors of all our repositories on GitHub for historical reasons. Instead we use a fully open source code review and continuous integration (CI) system maintained by the OpenStack Infrastructure team. Relatedly, since we run a CI system, every change proposed to OpenStack is tested before merging.

Paul Belanger (PB): A lot of passionate people in the project, so don't get discouraged if your patch gets a -1.

Christopher Aedo (CA): The community wants to help you succeed, don't be afraid to ask questions or ask for pointers to more information to improve your understanding.

PB: Definitely our OpenStack Project Infrastructure documentation. At lot of effort has been taken to keep it up to date as much as possible. Every system used in running OpenStack as a project has a dedicated page, even the OpenStack cloud the Infrastructure teams is bringing online.

EKJ: I'll echo what Paul said about the Infrastructure documentation, and add that we love seeing patches from folks who are learning. We often don't realize what we're missing in terms of documentation until someone asks. So read, learn, and then help us fill in the gaps. You can ask questions on the openstack-infra mailing list or in our IRC channel at #openstack-infra on Freenode.

CA: I love this detailed post about building images, by Ian Wienand.

EKJ: Contributing is not just about submitting new code and new features; the OpenStack community places a very high value on doing code reviews. If you want people to look at a patch you submitted, consider reviewing some of the work of others and providing clear and constructive feedback. The more your fellow contributors know about your work and see you doing reviews, the more likely you'll get your code reviewed in a timely manner.

CA: I see a lot of newcomers getting tripped up with Gerrit. Read through the developer workflow in the Developers Guide, and then maybe read through it one more time. If you're not used to Gerrit, it can seem confusing and overwhelming at first, but walking through a few code reviews usually makes it all come together. Also, I'm a big fan of IRC. It can be a great place to get help, but it's best if you can maintain a persistent presence so people can answer your questions even if you're not "there" at that particular moment. (Read IRC, the secret to success in open source.) You don't need to be "always on," but the ability to easily scroll back in a channel and catch up on a conversation can be invaluable.

PB: I agree with both Elizabeth and Chris—Gerrit is what to look out for. It is going to be the hub of your development effort. Not only will you be submitting code for people to review, but you'll also be reviewing other contributors' code. Watch out for the Gerrit UI; it can be confusing at times. I'd recommend trying out Gertty, which is a console-based interface to the Gerrit Code Review system, which happens to be a project driven by OpenStack Infrastructure.;