@ -9,24 +9,25 @@ Loki uses GitHub to manage reviews of pull requests:
## Pull Request Prerequisites/Checklist
1. Your PR title is in the form `<Feature Area>: Your change`.
a. It does not end the title with punctuation. It will be added in the changelog.
b. It starts with an imperative verb. Example: Fix the latency between System A and System B.
c. It uses Sentence case, not Title Case.
d. It uses a complete phrase or sentence. The PR title will appear in a changelog, so help other people understand what your change will be.
e. It has a clear description saying what it does and why. Your PR description will be present in the project' commit log, so be gentle to it.
2. Your PR is well sync'ed with main
3. Your PR is correctly documenting appropriate changes under the CHANGELOG. You should document your changes there if:
* It adds an important feature
* It fixes an issue present in a previous release
* It causes a change in operation that would be useful for an operator of Loki to know
You can skip this step for documentation changes, build related changes and simple bug fixes or enhancements. Rationale being we are attempting to curate the CHANGELOG entries with most relevant and important changes that end users of Loki care about.
4. Your PR documents upgrading steps under `docs/sources/upgrading/_index.md` if it changes:
* Default configuration values
* Metric names or label names
* Changes existing log lines that may be used in dashboard or alerts. e.g: logs lines in any `metrics.go` files might be getting used in building dashboards or alerts.
* Configuration parameters
* Any breaking changes to HTTP or gRPC API endpoints
* Any other change that would require special attention or extra steps to upgrade
1. It does not end the title with punctuation. It will be added in the changelog.
1. It starts with an imperative verb. Example: Fix the latency between System A and System B.
1. It uses Sentence case, not Title Case.
1. It uses a complete phrase or sentence. The PR title will appear in a changelog, so help other people understand what your change will be.
1. It has a clear description saying what it does and why. Your PR description will be present in the project' commit log, so be gentle to it.
1. Your PR is well sync'ed with main
1. Your PR is correctly documenting appropriate changes under the CHANGELOG. You should document your changes there if:
* It adds an important feature
* It fixes an issue present in a previous release
* It causes a change in operation that would be useful for an operator of Loki to know
* You can skip this step for documentation changes, build related changes and simple bug fixes or enhancements. Rationale being we are attempting to curate the CHANGELOG entries with most relevant and important changes that end users of Loki care about.
1. Your PR documents upgrading steps under `docs/sources/upgrading/_index.md` if it changes:
* Default configuration values
* Metric names or label names
* Changes existing log lines that may be used in dashboard or alerts. e.g: logs lines in any `metrics.go` files might be getting used in building dashboards or alerts.
* Configuration parameters
* Any breaking changes to HTTP or gRPC API endpoints
* Any other change that would require special attention or extra steps to upgrade
Please document clearly what changed AND what needs to be done in the upgrade guide.