chore(docs): update contributing guidelines (charmkeeper)

.github/pull_request_template.md

@@ -0,0 +1,26 @@
+#### What this PR does
+
+#### Why we need it
+
+#### Checklist
+
+- [ ] I followed the [contributing guide](https://github.com/canonical/is-charms-contributing-guide)
+- [ ] I added or updated the documentation (if applicable)
+- [ ] I updated `docs/changelog.md` with user-relevant changes
+- [ ] I used AI to assist with preparing this PR
+- [ ] I added or updated tests as needed (unit and integration)
+- [ ] **If integration test modules are used:** I updated the workflow configuration  
+      (e.g., in `.github/workflows/integration_tests.yaml`, ensure the `modules` list is correct)
+- [ ] **If this PR involves a Grafana dashboard:** I added a screenshot of the dashboard
+
+<!--  
+You can adjust the checklist to match the project.
+
+If you are an AI assistant (e.g., GitHub Copilot, ChatGPT, Claude), follow these instructions when generating or completing PR descriptions:
+
+1. Add a **Test plan** section explaining how the changes were tested, including any manual, unit, integration, or workflow tests.
+2. Add a **Review focus** section highlighting tricky parts, important decisions, or areas needing human attention.
+3. Identify and document any **potential breaking changes**.
+4. Highlight any **new dependencies, APIs, modules, or workflow changes** introduced by this PR.
+-->
+

CHANGELOG.md

@@ -1,64 +1 @@
-# Changelog
-
-All notable changes to this project will be documented in this file.
-
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
-
-Each revision is versioned by the date of the revision.
-
-## 2025-05-06
-
-### **Changed**
-
-- Updated CONTRIBUTING.md and the documentation.
-
-## 2025-01-13
-
-### **Added**
-
-- Support for healthcheck-valid-status configuration.
-- Support for healthcheck-ssl-verify configuration.
-
-## 2024-12-18
-
-### **Added**
-
-- Add grafana dashboard for the displaying metrics from COS integration.
-
-## 2024-12-16
-
-### **Added**
-
-- Support for active health checks using LUA scripts. Configured through healthcheck-interval and healthcheck-path.
-
-## 2024-12-11
-
-### **Fixed**
-
-- A issue where content-cache charm integrated with multiple content-cache-backends-config charms causing some configuration to not work correctly.
-
-## 2024-12-05
-
-### **Added**
-
-- Support for COS integration. Integrating with charms that provides cos-agent will cause the charm to forward logs to COS.
-
-## 2024-11-28
-
-### **Added**
-
-- Support for TLS certificate integration. Integrating with charms that provides tls-certificates will enable HTTPS for the content cache.
-
-## 2024-10-17
-
-## **Added**
-
-- Support for fail-timeout, backends-path, proxy-cache-valid configuration options from integration with Content Cache Backends Config charm.
-
-# 2024-10-07
-
-## **Added**
-
-- Changelog for tracking user-relevant changes.
-- Basic content cache functionality with nginx.
-- Support for hostname, path, backends, protocol configuration options from integration with Content Cache Backends Config charm.
+docs/changelog.md

CONTRIBUTING.md

@@ -1,6 +1,6 @@
-# How to contribute
+# Contributing
 
-This document explains the processes and practices recommended for contributing enhancements to the `content-cache` charms.
+This document explains the processes and practices recommended for contributing enhancements to the Content Cache Operators.
 
 ## Overview
 
@@ -9,26 +9,27 @@ This document explains the processes and practices recommended for contributing
 - If you would like to chat with us about your use-cases or proposed implementation, you can reach
   us at [Canonical Matrix public channel](https://matrix.to/#/#charmhub-charmdev:ubuntu.com)
   or [Discourse](https://discourse.charmhub.io/).
-- Familiarizing yourself with the [Juju documentation](https://documentation.ubuntu.com/juju/latest/howto/manage-charms/index.html)
+- Familiarizing yourself with the [Juju documentation](https://documentation.ubuntu.com/juju/3.6/howto/manage-charms/)
   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.
+  - user experience for Juju operators of these charms.
 - 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](https://github.com/canonical/is-charms-contributing-guide).
+  [Contributing Guide](https://github.com/canonical/platform-engineering-contributing-guide).
 
 ## Code of conduct
 
 When contributing, you must abide by the
 [Ubuntu Code of Conduct](https://ubuntu.com/community/ethos/code-of-conduct).
 
-## Releases and versions
+## Changelog
 
 Please ensure that any new feature, fix, or significant change is documented by
-adding an entry to the [CHANGELOG.md](https://github.com/canonical/content-cache-operator/blob/main/CHANGELOG.md) file.
+adding an entry to the [CHANGELOG.md](docs/changelog.md) file. Use the date of the
+contribution as the header for new entries.
 
 To learn more about changelog best practices, visit [Keep a Changelog](https://keepachangelog.com/).
 
@@ -39,7 +40,7 @@ notify in advance the people involved to avoid confusion;
 also, reference the issue or bug number when you submit the changes.
 
 - [Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)
-  our [GitHub repository](https://github.com/canonical/content-cache-operator/)
+  our [GitHub repository](https://github.com/canonical/content-cache-operator)
   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;
@@ -49,35 +50,31 @@ also, reference the issue or bug number when you submit the changes.
 
 Your changes will be reviewed in due time; if approved, they will be eventually merged.
 
-### Describing pull requests
+### AI
 
-To be properly considered, reviewed and merged,
-your pull request must provide the following details:
+You are free to use any tools you want while preparing your contribution, including
+AI, provided that you do so lawfully and ethically.
 
-- **Title**: Summarize the change in a short, descriptive title.
+Avoid using AI to complete issues tagged with the "good first issues" label. The
+purpose of these issues is to provide newcomers with opportunities to contribute
+to our projects and gain coding skills. Using AI to complete these tasks
+undermines their purpose.
 
-- **Overview**: Describe the problem that your pull request solves.
-  Mention any new features, bug fixes or refactoring.
+We have created instructions and tools that you can provide AI while preparing your contribution: [`copilot-collections`](https://github.com/canonical/copilot-collections)
 
-- **Rationale**: Explain why the change is needed.
+While it isn't necessary to use `copilot-collections` while preparing your
+contribution, these files contain details about our quality standards and
+practices that will help the AI avoid common pitfalls when interacting with
+our projects. By using these tools, you can avoid longer review times and nitpicks.
 
-- **Juju Events Changes**: Describe any changes made to Juju events, or
-  "None" if the pull request does not change any Juju events.
+If you choose to use AI, please disclose this information to us by indicating
+AI usage in the PR description (for instance, marking the checklist item about
+AI usage). You don't need to go into explicit details about how and where you used AI.
 
-- **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:
-
-  - The [charm style guide](https://juju.is/docs/sdk/styleguide) was applied
-  - The [contributing guide](https://github.com/canonical/is-charms-contributing-guide) was applied
-  - The changes are compliant with [ISD054 - Managing Charm Complexity](https://discourse.charmhub.io/t/specification-isd014-managing-charm-complexity/11619)
-  - The documentation is updated
-  - The PR is tagged with appropriate label (trivial, senior-review-required)
-  - The changelog has been updated
+Avoid submitting contributions that you don't fully understand.
+You are responsible for the entire contribution, including the AI-assisted portions.
+You must be willing to engage in discussion and respond to any questions, comments,
+or suggestions we may have. 
 
 ### Signing commits
 
@@ -87,7 +84,7 @@ we use the [Canonical contributor license agreement](https://assets.ubuntu.com/v
 
 #### Canonical contributor agreement
 
-Canonical welcomes contributions to the Discourse charm. Please check out our
+Canonical welcomes contributions to the Content Cache Operators. Please check out our
 [contributor agreement](https://ubuntu.com/legal/contributors) if you're interested in contributing to the solution.
 
 The CLA sign-off is simple line at the

content-cache-backends-config/CONTRIBUTING.md

@@ -2,105 +2,7 @@
 
 This document explains the processes and practices recommended for contributing enhancements to the `content-cache-backends-config` charm.
 
-## Overview
-
-- Generally, before developing enhancements to this charm, you should consider [opening an issue
-  ](https://github.com/canonical/content-cache-operator/issues) 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](https://matrix.to/#/#charmhub-charmdev:ubuntu.com)
-  or [Discourse](https://discourse.charmhub.io/).
-- Familiarizing yourself with the [Juju documentation](https://canonical-juju.readthedocs-hosted.com/en/latest/user/howto/manage-charms/)
-  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](https://github.com/canonical/is-charms-contributing-guide).
-
-## Code of conduct
-
-When contributing, you must abide by the
-[Ubuntu Code of Conduct](https://ubuntu.com/community/ethos/code-of-conduct).
-
-## Releases and versions
-
-This project uses [semantic versioning](https://semver.org/).
-
-Please ensure that any new feature, fix, or significant change is documented by
-adding an entry to the [CHANGELOG.md](https://github.com/canonical/content-cache-operator/blob/main/CHANGELOG.md) file.
-
-To learn more about changelog best practices, visit [Keep a Changelog](https://keepachangelog.com/).
-
-## 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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)
-  our [GitHub repository](https://github.com/canonical/content-cache-operator/)
-  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)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).
-
-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:
-
-  - The [charm style guide](https://juju.is/docs/sdk/styleguide) was applied
-  - The [contributing guide](https://github.com/canonical/is-charms-contributing-guide) was applied
-  - The changes are compliant with [ISD054 - Managing Charm Complexity](https://discourse.charmhub.io/t/specification-isd014-managing-charm-complexity/11619)
-  - The documentation is updated
-  - The PR is tagged with appropriate label (trivial, senior-review-required)
-  - The changelog has been updated
-
-### Signing commits
-
-To improve contribution tracking,
-we use the [Canonical contributor license agreement](https://assets.ubuntu.com/v1/ff2478d1-Canonical-HA-CLA-ANY-I_v1.2.pdf)
-(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](https://ubuntu.com/legal/contributors) 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](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits).
+Please read the [main contributing guide](/CONTRIBUTING.md) first.
 
 ## Develop