oslo-specs/specs/policy/contributing.rst
Ben Nemec ec8c81fb07 Add contributor doc policy
This is the first step of completing the contributor doc goal[0] from
the Ussuri cycle. It adds a contributing.rst policy which uses the
cookiecutter template created for the goal.

The expectation is that this is a central location for all of this
information, and the contributing.rst in each Oslo project will
simply refer to it so we aren't maintaining it in 40+ repos.

0: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-contrib-docs.html

Change-Id: I3347d553b50a52ae96186e60b729360b159d8df5
2020-04-28 16:35:28 -05:00

2.5 KiB

So You Want to Contribute...

For general information on contributing to OpenStack, please check out the contributor guide to get started. It covers all the basics that are common to all OpenStack projects: the accounts you need, the basics of interacting with our Gerrit review system, how we communicate as a community, etc.

Below will cover the more project specific information you need to get started with Oslo, which includes all of the projects listed on the Oslo wiki.

Communication

IRC: #openstack-oslo on Freenode

Mailing list: Messages tagged with [oslo] on openstack-discuss

Meeting: Weekly. Full details on eavesdrop

Contacting the Core Team

See The Oslo Team on the wiki.

New Feature Planning

Oslo uses a spec process for major new features. See details on the wiki.

Task Tracking

We track our tasks in Launchpad.

https://bugs.launchpad.net/oslo

Each individual library also has its own Launchpad project.

If you're looking for some smaller, easier work item to pick up and get started on, search for the 'low-hanging-fruit' tag.

Reporting a Bug

You found an issue and want to make sure we are aware of it? You can do so on Launchpad.

Getting Your Patch Merged

In general, Oslo requires 2 +2's in order to merge a patch. Under some circumstances a single +2 may be sufficient. This is generally reserved for repetitive patches such as trivial tox changes that have been pre-approved by the team. Some other circumstances (such as gate blocking bugs) may call for single approval at the discretion of the core team.

Unit tests are preferred for changes that are not already covered by existing unit tests, and will usually help patches merge more quickly.

Project Team Lead Duties

PTL duties are documented in the Oslo PTL Guide.

All common PTL duties are enumerated in the PTL guide.