Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
108 lines (76 loc) · 5 KB

CONTRIBUTING.md

File metadata and controls

108 lines (76 loc) · 5 KB

How to contribute

This document explains the processes and practices recommended for contributing enhancements to the content-cache charms.

Overview

  • Generally, before developing enhancements to these charms, you should consider opening an issue explaining your use case.
  • If you would like to chat with us about your use-cases or proposed implementation, you can reach us at Canonical Matrix public channel or Discourse.
  • Familiarizing yourself with the Juju documentation will help you a lot when working on new features or bug fixes.
  • All enhancements require review before being merged. Code review typically examines
    • code quality
    • test coverage
    • user experience for Juju operators of this charm.
  • Once your pull request is approved, we squash and merge your pull request branch onto the main branch. This creates a linear Git commit history.
  • For further information on contributing, please refer to our Contributing Guide.

Code of conduct

When contributing, you must abide by the Ubuntu Code of Conduct.

Releases and versions

Please ensure that any new feature, fix, or significant change is documented by adding an entry to the CHANGELOG.md file.

To learn more about changelog best practices, visit Keep a Changelog.

Submissions

If you want to address an issue or a bug in this project, notify in advance the people involved to avoid confusion; also, reference the issue or bug number when you submit the changes.

  • Fork our GitHub repository and add the changes to your fork, properly structuring your commits, providing detailed commit messages and signing your commits.
  • Make sure the updated project builds and runs without warnings or errors; this includes linting, documentation, code and tests.
  • Submit the changes as a pull request (PR).

Your changes will be reviewed in due time; if approved, they will be eventually merged.

Describing pull requests

To be properly considered, reviewed and merged, your pull request must provide the following details:

  • Title: Summarize the change in a short, descriptive title.

  • Overview: Describe the problem that your pull request solves. Mention any new features, bug fixes or refactoring.

  • Rationale: Explain why the change is needed.

  • Juju Events Changes: Describe any changes made to Juju events, or "None" if the pull request does not change any Juju events.

  • Module Changes: Describe any changes made to the module, or "None" if your pull request does not change the module.

  • Library Changes: Describe any changes made to the library, or "None" is the library is not affected.

  • Checklist: Complete the following items:

Signing commits

To improve contribution tracking, we use the Canonical contributor license agreement (CLA) as a legal sign-off, and we require all commits to have verified signatures.

Canonical contributor agreement

Canonical welcomes contributions to the Discourse charm. Please check out our contributor agreement if you're interested in contributing to the solution.

The CLA sign-off is simple line at the end of the commit message certifying that you wrote it or have the right to commit it as an open-source contribution.

Verified signatures on commits

All commits in a pull request must have cryptographic (verified) signatures. To add signatures on your commits, follow the GitHub documentation.

Develop

Please refer to the charm specific guides: