Clarify that the changelog entry should be in the imperative mood
@@ -19,7 +19,10 @@ If the issue is not fully described in the ticket, add more information here (ju
* ...
<!-- Comment:
-The changelogs will be integrated by the core maintainers after the merge. See the changelog examples here: https://www.jenkins.io/changelog/ -->
+The changelogs will be integrated by the core maintainers after the merge.
+The changelog entry should be in the imperative mood; e.g., write "do this"/"return that" rather than "does this"/"returns that".
+For examples, see: https://www.jenkins.io/changelog/
+-->
### Proposed upgrade guidelines
@@ -28,7 +31,7 @@ N/A
### Submitter checklist
- [ ] (If applicable) Jira issue is well described
-- [ ] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). [Examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)
+- [ ] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. [Examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)
* Fill-in the `Proposed changelog entries` section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
- [ ] Appropriate autotests or explanation to why this change has no tests
- [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadoc, as appropriate.
@@ -50,7 +53,7 @@ Before the changes are marked as `ready-for-merge`:
- [ ] There are at least 2 approvals for the pull request and no outstanding requests for change
- [ ] Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
-- [ ] Changelog entries in the PR title and/or `Proposed changelog entries` are correct
+- [ ] Changelog entries in the PR title and/or `Proposed changelog entries` are accurate, human-readable, and in the imperative mood
- [ ] Proper changelog labels are set so that the changelog can be generated automatically
- [ ] If the change needs additional upgrade steps from users, `upgrade-guide-needed` label is set and there is a `Proposed upgrade guidelines` section in the PR title. ([example](https://github.com/jenkinsci/jenkins/pull/4387))
- [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins-ci.org/issues/?filter=12146)).
