Pulp

I have a PR that just checks for the file if it finds an issue in the commit. I didn't have time unfortunately to do all the requirements but I think this'll be a good stopgap until we do.

https://github.com/pulp/plugin_template/pull/89

I think the logic should be:
If it's a story ensure there is a CHANGES/<num>.feature OR CHANGES/<num>.misc
If it's an issue ensure there is a CHANGES/<num>.bugfix OR CHANGES/<num>.misc
If it has the documentation tag ensure there is a CHANGES/<num>.doc OR CHANGES/<num>.misc
If

This gives the devs the ability to decide that any particular issue should not be a line item in the changelog. Here are a few use cases:

1. A story is broken out into multiple stories. There is no reason to add more than one changelog line item if a feature is added and expanded in the same release. Example: add an endpoint, and then add a flag to that endpoint. This would be easier to consume for users as a single line item.

2. A bugfix for an unreleased feature should not have a changelog entry, because the users could never have experienced that issue.

3. A typo fix for documentation could be mentioned, but is overly verbose.

@asmacdo that sounds fine to me with the exception of one problem: I see a significant number of tasks in redmine that impact users or plugin writers (here's a recent example[0]). I wonder if we should just validate that all changes to the codebase have CHANGES entries.

[0] https://pulp.plan.io/issues/5227