How To Contribute
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
- 1 If you're building clouds
- 2 Mentoring and finding mentors
- 3 If you're a developer
- 4 If you're a tester (and breaker), get started this way:
- 5 If you're into security, we'd love your help
- 6 If you're into doc, we'd love your help
- 7 If you're a designer or usability professional, help shape the UX
- 8 If you want to help with the openstack.org website
- 9 If you're a translator
- 10 If you're a community builder
- 11 If you're hoping to contribute in another way, let us know!
- 12 Is there something missing?
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 git 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 contributing to a working group, or adding a use case.
Mentoring and finding mentors
With internship opportunities offered regularly and Upstream Training 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
- 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.
- Before we can accept your patches, you'll have to agree to a contributor license agreement (you can preview the full text of the OpenStack Individual Contributor License Agreement here first if you want)
- Review code - you don't need to be a "core reviewer", anyone can review :)
- Pycharm Open Source developer licences are available for people who are contributing to OpenStack. If you are contributing to OpenStack and you need a licence drop a mail to Swapnil Kulkarni with your launchpad id.
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.
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
- 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 with appropriate signing authority also needs to sign the Corporate Contributor License Agreement providing a list of people authorized to commit code to OpenStack. Request a printable copy by emailing the OpenStack Foundation. 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 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:
- 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 Heat or python-heatclient
- Report a bug in Ceilometer or python-ceilometerclient
- 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 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-101 on freenode.net as well.