Jump to: navigation, search

Difference between revisions of "How To Contribute"

(Try not to discriminate project channels that are not prefixed with #openstack)
m (Changes from #openstack-101 to #openstack-dev (FYI: https://review.openstack.org/#/q/topic:remove-openstack-101 ))
Line 124: Line 124:
=== Is there something missing? ===
=== Is there something missing? ===
If you need further guidance about how to contribute or if you are having trouble getting started, you can look at '''#openstack-101''' on [http://webchat.freenode.net freenode.net] as well.
If you need further guidance about how to contribute or if you are having trouble getting started, you can look at '''#openstack-dev''' on [http://webchat.freenode.net freenode.net] as well.

Revision as of 14:35, 13 April 2018

How can I help? Thanks for asking. Let's find a place for you!

First you should join our communication forums:

  • Subscribe to our mailing lists
  • Join us on IRC: You can talk to us directly in #openstack or one of the other channels
  • Answer and ask questions on Ask OpenStack

If you're building clouds

Mentoring and finding mentors

With internship opportunities offered regularly and OpenStack University offered many times during the year, there is a constant need of mentors to help new contributors to OpenStack navigate the intricacies of the projects. Add yourself as as a mentors or find a mentor for yourself if you're getting started on OpenStack.

If you're a developer

Bug fixing

The first area where you can help is bug fixing. Confirmed bugs are usually good targets. Triaged bugs should even contain tips on how they should be fixed. Here is the list of Confirmed and Triaged bugs.

You can contribute instructions on how to fix a given bug, and set it to Triaged. Or you can directly fix it: assign the bug to yourself, set it to In progress, branch the code, implement the fix, and propose your change for merging into trunk !

Some easy-to-fix bugs may be marked with the low-hanging-fruit tag: they also make good targets for a beginner.


Maintaining good code quality is a never-ending effort that is shared across the development team. There are several always-ongoing efforts that need your help, for example: increasing comments in code, reducing pylint violations, increasing code coverage. Those are usually nice ways to get involved in development: easy changes that will let you touch various areas of OpenStack code, and gain respect from your peers. :) It might be also a good idea to check the results of the continuous code quality and test coverage monitoring described here.

You can also try some gardening of this wiki.

Feature development

Once you get comfortable with the code, you can start to scratch your own itch and contribute new features. New features get implemented every 6 months in a development cycle. We use Launchpad Blueprints to track the design and implementation of significant features, and we use Design Summits every 6 months to discuss them in public. Code should be proposed for inclusion before we reach the final feature milestone of the development cycle.


Every patch submitted to OpenStack gets reviewed before it can be approved and merged. We get a lot of contributions and everyone can - and is encouraged to! - review existing patches. Read the the Code Review checklist and Nova guidelines as a starting point, then pick an open review and look at it, test it if possible, and leave a comment with a +1 or -1 vote describing what you discovered. If you're planning on submitting patches of your own, it's a great way to learn about what the community cares about and to learn about the code base.

Contributor License Agreement

For Individuals, See the Contributor License Agreement steps above

Check the FAQ for Contributor License Agreements if you have questions

If you're a tester (and breaker), get started this way:


We need your help in making sure OpenStack components behave correctly. Feel free to install the development version and report any issue:

Triaging bugs

Reported bugs need care: prioritizing them correctly, confirming them, making sure they don't go stale... All those tasks help immensely. If you care about OpenStack stability but are not a hardcore developer, consider helping in that area !

The whole process is described on BugTriage.

If you're into security, we'd love your help

The OpenStack Security Group (OSSG) is a collection of security-minded people working together to broadly improve security across OpenStack. OSSG has people with a wide range of skills (including developers, architects, writers, and more). See Security/How_To_Contribute for more details on how to get involved with OSSG.

If you're into doc, we'd love your help

You can contribute administrative documentation to the openstack-manuals project, or developer documentation to the individual nova, glance, swift etc. projects. See Documentation/HowTo for details, as well as Documentation/HowTo/FirstTimers which has some other info that may be useful.

To fix a documentation bug, or mark a bug as a documentation bug, go to aggregated list of documentation bugs from all OpenStack projects.

You can also start by reading the developer documentation which is created using Sphinx as part of the code in the /doc/source/ directory and published to swift.openstack.org, nova.openstack.org, glance.openstack.org, keystone.openstack.org, or horizon.openstack.org.

To contribute to administrator documentation, get started with git and GitHub as documented in the documentation how-to guide. The openstack-manuals project houses the documentation that is published to docs.openstack.org.

Monitor Ask OpenStack to curate the best answers that can be folded into the documentation.

If you're a designer or usability professional, help shape the UX

You can contribute in many different ways to the User Experience of OpenStack. Whether it's reviewing current features as a user and giving feedback, designing new features, testing designs or features with users, or helping to build use cases and requirements, we'd love to have your help in the UX group!

Take a look at the "Getting Started with Designing for User Experience" section of the UX wiki for details.

Also, feel free to contact fellow designers and folks interested in UX work in #openstack-ux on Freenode if you have any questions or need any guidance on where to jump in.

If you want to help with the openstack.org website

Start by reading the contributing to the website document.

If you're a translator

Join the Internationalisation Team. Read the Translations wiki page (Translation management section) for more information on how translations are managed in OpenStack. We have adopted Zanata, and you can use the translation site as a starting point to translate any of the OpenStack projects. It's easier to start translating directly on the site, as there is no need to download any files or applications to get started.

If you're a community builder

Check out the user group page to learn which communities exist and how to start one. If you're into diversity and making our community more welcoming and diverse, please look at the Women of OpenStack and Outreach Program for Women for ideas.

If you're hoping to contribute in another way, let us know!

Contact one of the OpenStack people and float your idea.

Is there something missing?

If you need further guidance about how to contribute or if you are having trouble getting started, you can look at #openstack-dev on freenode.net as well.