How Can I Help?¶
Are you interested in contributing to the keystone project? Whether you’re a software developer, a technical writer, an OpenStack operator or an OpenStack user, there are many reasons to get involved with the keystone project:
You can help shape the direction of the project, ensuring it meets your organization’s needs in the future
You can help maintain the project’s health and get your bugs fixed faster
You can collaborate with other people to find common solutions that will help you and your organization
You can hack on a fun, security-related Python project with interesting challenges
Here are some easy ways to make a big difference to the keystone project and become part of the team:
Read the documentation, starting with the rest of this contributor guide, and try to follow it to set up keystone and try out different features. Does it make sense? Is something out of date? Is something misleading or incorrect? Submit a patch or bug report to fix it.
Monitor incoming bug reports, try to reproduce the bug in a test environment, ask the bug reporter for more information, answer support questions and close invalid bugs. Follow the bug triage guide. New bugs can be found with the “New” status:
You can also subscribe to email notifications for new bugs.
Subscribe to the openstack-discuss@lists.openstack.org mailing list (filter on subject tag
[keystone]) and join the #openstack-keystone IRC channel on OFTC. Help answer user support questions if you or your organization has faced and solved a similar problem, or chime in on design discussions that will affect you and your organization.Check out the low hanging fruit bugs, submit patches to fix them:
Look for deprecation warnings in the unit tests and in the keystone logs of a running keystone installation and submit patches to make them go away.
Look at other projects, especially devstack, and submit patches to correct usage of options that keystone has deprecated. Make sure to let the keystone maintainers know you’re looking at these so that it’s on their radar and they can help review.
Check the test coverage report (
tox -ecover) and try to add unit test coverage.Review new changes. Keep OpenStack’s review guidelines in mind. Ask questions when you don’t understand a change.
Need any help? Reach out to the keystone team.
The Meaning of Low Hanging Fruit¶
This section describes the intent behind bugs tagged as low hanging fruit. Current maintainers should apply the tag consistently while triaging bugs, using this document as a guide. This practice ensures newcomers to the project can expect each low hanging fruit bug to be of similar complexity.
Bugs fit for the low hanging fruit tag:
Should require minimal python experience, someone new to OpenStack might also be new to python
Should only require a basic understanding of the review workflow, complicated changesets with dependencies between repositories coupled with CI testing only raises the cognitive bar for new contributors
Can include documentation fixes so long it doesn’t require an in-depth understanding of complicated subsystems and features (e.g., overhauling the federated identity guide)
Should be something a newcomer can progress through in a week or less, long wait times due to the discussion of complicated topics can deter new contributors from participating
Shouldn’t require a new contributor to understand copious amounts of historical context, newcomers should eventually understand this information but consuming that information is outside the scope of low hanging fruit
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.