How To Contribute
- 1 How can I help?
- 1.1 If you're building clouds
- 1.2 If you're a developer
- 1.3 If you're a tester (and breaker), get started this way:
- 1.4 If you're into security, we'd love your help
- 1.5 If you're into doc, we'd love your help
- 1.6 If you're a designer or usability professional, help shape the UX
- 1.7 If you want to help with the openstack.org website
- 1.8 If you're a translator
- 1.9 If you're hoping to contribute in another way, let us know!
- 1.10 Is there something missing?
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 one of the #openstack channels
- Answer and ask questions on Ask OpenStack
If you're building clouds
- Read the official OpenStack documentation, which is intended for cloud deployers and operations professionals who are standing up OpenStack clouds. Each page offers comments and the documentation can be edited by cloning a GitHub repository, see Documentation/HowTo.
- If you find problems with content on the official OpenStack documentation, log a bug against the openstack-manuals project with the page that contains the bug.
- Hint: you can just dump useful text into a bug report, and the documentation team will format it and update the docs for you.
- Join the openstack-operators mailing list to ask and answer questions specific to deployments large and small.
- Fill out the user survey, where you can influence the community and software direction and anonymously provide feedback about your OpenStack experience.
- Consider volunteering to work with the user committee
If you're a developer
- Join the OpenStack developers mailing list
- Join the #openstack-dev IRC channel
- Check out how we work:
- Get the code
- Learn how to work with our Gerrit review system. Some useful tips are in this video.
- Before we can accept your patches, you'll have to sign the Contributors License Agreement
- Review code - you don't need to be a "core reviewer", anyone can review :)
Contributors License Agreement
There are some steps you need to go through before we can accept your contributions:
- All Individuals (except employees of US government --see below)
- You'll need a Launchpad account, since this is how the Web interface for the Gerrit Code Review system will identify you. This is also useful for automatically crediting bug fixes to you when you address them with your code commits.
- If you haven't already, join The OpenStack Foundation (it's free and required for all code contributors). Among other privileges, this also allows you to vote in elections and run for elected positions within The OpenStack Project. When signing up for Foundation Membership, make sure to give the same E-mail address you'll use for code contributions, since the Primary Email Address in your Foundation Profile will need to match the Preferred Email you set later in your Gerrit contact information.
- Visit https://review.openstack.org/ and click the Sign In link at the top-right corner of the page. Log in with your Launchpad ID. You can preview the text of the Individual CLA.
- Because Gerrit uses Launchpad OpenID single sign-on, you won't need a separate password for Gerrit, and once you log in to one of Launchpad, Gerrit, or Jenkins, you won't have to enter your password for the others.
- Unless you are an U.S. Government Employee (see below), agree to the Individual Contributor License Agreement and provide contact information. Your full name and E-mail address will be public (since they also appear in project commit logs) and the latter needs to match the user.email in your Git configuration. The other contact information (postal address, phone numbers) will be kept confidential and is only used as a fallback record in the unlikely event The OpenStack Foundation needs to reach you directly over code contribution related matters. This contact information can also be easily updated later if desired, but make sure the primary E-mail address always matches the one you set for your OpenStack Foundation Membership--otherwise Gerrit will give you an error message and refuse to accept your contact information.
- If you are contributing on behalf of a company or organization, you still need to sign the Individual CLA above but someone at your company or organization also needs to sign the Corporate Contributor License Agreement providing a list of people authorized to commit code to OpenStack. Check How to update the CCLA to provide changes to such list.
- US Government employees
- Employees of the the U.S. Government do not sign the Individual CLA. Instead, someone with authority to sign on behalf of your agency should sign the U.S. Government Contributor License Agreement. Individual developers still need to create a Launchpad account, join the OpenStack Foundation and click the Sign In link on Gerrit. Please contact the OpenStack Foundation to initiate this process.
Check the FAQ for Contributors License Agreements if you have questions
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 :)
You can also try some gardening of this wiki.
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 review checklist 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.
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:
- Report a bug in Nova or python-novaclient
- Report a bug in Swift or python-swiftclient
- Report a bug in Glance or python-glanceclient
- Report a bug in Keystone or python-keystoneclient
- Report a bug in Neutron or python-neutronclient
- Report a bug in Cinder or python-cinderclient
- Report a bug in Horizon
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 Transifex, and you can use the OpenstackHub as a starting point to translate any of the OpenStack projects. It's easier to start translating directly on the Transifex's site, as there is no need to download any files or applications to get started.
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-101 on freenode.net as well.