Contributing to OpenStack’s self-healing SIG

If you would like to participate in discussions or contribute in any way to the design and development of self-healing in OpenStack, please first see the following wiki to understand the SIG’s mission, scope, and other supporting information:

Many forms of contribution are valuable to the community, including but not limited to the following:

Everyone is warmly encouraged to get involved in whatever capacity you see fit.

Discussions

Discussions take place:

Links to all resources can also be found in the SIG wiki section on community.

Use cases

The SIG serves to facilitate the discussion and documentation of self-healing use cases at all stages of development from a seed idea to a fully tested use case.

To call attention to a use case, please start the discussion in one of the established communication channels.

Alternatively, directly submit a patch to document the use case, following the format laid out in the template file in the use-cases/ directory of the self-healing-sig repository.

See Submitting a change for more information.

Design specs

Design specs are proposed implementations of self-healing functionality across projects. To author a new design spec, please follow the format laid out in the template file in the specs/ directory of the self-healing-sig repository.

See Submitting a change for more information.

Code

The self-healing-sig repository also holds any relevant cross-project code, tests, and documentation that do not naturally belong in a single project repository.

See Submitting a change for more information.

Submitting a change

To submit a change to this repository, please follow the steps in this page:

If you already have a good understanding of how the system works and your OpenStack accounts are set up, you can skip to the development workflow section of this documentation to learn how changes to OpenStack should be submitted for review via the Gerrit tool:

Pull requests submitted through GitHub will be ignored.