How to contribute to MicroCloud

The MicroCloud team welcomes contributions through pull requests, issue reports, and discussions.

Review the following guidelines before contributing to the project.

Code of Conduct

All contributors must adhere to the Ubuntu Code of Conduct.

Pull requests

Submit pull requests on GitHub at: https://github.com/canonical/microcloud.

All pull requests undergo review and must be approved before being merged into the main branch.

Commit structure

  • Use separate commits for each logical change, and for changes to different components.

  • Prefix commits with the affected component, following the code tree structure.

  • Format: <component/subcomponent>: <concise change description>

  • Examples:

    • api/services: Use the authHandlerMTLS func

    • cmd/microcloud: Remove token add command

Depending on complexity, large changes might be further split into smaller, logical commits. This commit structure facilitates the review process and simplifies backporting fixes to stable branches.

Developer Certificate of Origin sign-off

To ensure transparency and accountability in contributions to this project, all contributors must include a Signed-off-by line in their commits in accordance with DCO 1.1:

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Including a Signed-off-by line in your commits

Every commit must include a Signed-off-by line, even when part of a larger set of contributions. To do this, use the -s flag when committing:

git commit -s -m "Your commit message"

This automatically adds the following to your commit message:

Signed-off-by: Your Name <your.email@example.com>

By including this line, you acknowledge your agreement to the DCO 1.1 for that specific contribution.

  • Use a valid name and email address—anonymous contributions are not accepted.

  • Ensure your email matches the one associated with your GitHub account.

Commit signature verification

In addition to the sign-off requirement, contributors must also cryptographically sign their commits to verify authenticity. See: GitHub’s documentation on commit signature verification.

Contribute to the documentation

We strive to make MicroCloud as easy and straightforward to use as possible. To achieve this, our documentation aims to provide the information users need, cover all common use cases, and answer typical questions.

You can contribute to the documentation in several ways. We appreciate your help!

Only use this repository for contributions to the MicroCloud documentation. Submit pull requests to the integrated documentation sets at their respective standalone GitHub repositories:

Ways to contribute

Document new features or improvements you contribute to the code.

  • Submit documentation updates in pull requests alongside your code changes. We will review and merge them together with the code.

Clarify concepts or common questions based on your own experience.

  • Submit a pull request with your documentation improvements.

Report documentation issues by opening an issue in GitHub.

  • We will evaluate and update the documentation as needed.

Ask questions or suggest improvements in the MicroCloud forum.

  • We monitor discussions and update the documentation when necessary.

If you contribute images to doc/images:

  • Use SVG or PNG formats.

  • Optimize PNG images for smaller file size using a tool like TinyPNG (web-based), OptiPNG (CLI-based), or similar.

Documentation framework

The MicroCloud documentation and its integrated documentation sets are built with Sphinx and hosted on Read the Docs. For structuring, all use the Diátaxis approach.

The MicroCloud and LXD documentation sets are written in Markdown with MyST extensions. For syntax help and guidelines, see the MyST style guide and the documentation cheat sheet (source).

The MicroCeph and MicroOVN documentation sets are written in a documentation markup language called reStructuredText (.rst). Differences in functionality are few; however, syntax differs.

Build the documentation

To build the documentation, run make doc from the root directory of the repository. This command installs the required tools and renders the output to the doc/_build/ directory. To update the documentation for changed files only (without re-installing the tools), run make doc-html.

Before opening a pull request, make sure that the documentation builds without any warnings (warnings are treated as errors). To preview the documentation locally, run make doc-serve and go to http://localhost:8000 to view the rendered documentation.

When you open a pull request, a preview of the documentation hosted by Read the Docs is built automatically. To see this, view the details for the docs/readthedocs.com:canonical-microcloud check on the pull request. Others can also use this preview to validate your changes.

Automatic documentation checks

GitHub runs automatic checks on the documentation to verify the spelling, the validity of links, and the use of inclusive language.

You can (and should!) run these tests locally before pushing your changes:

  • Check the spelling: make doc-spelling (use make doc-spellcheck to check without rebuilding)

  • Check the validity of links: make doc-linkcheck

  • Check for inclusive language: make doc-woke