There at least two different concepts at play here: PRs and releases. Your first point makes me think that your internal PRs not only commit new code to master but also prepare a release. Decoupling the two may help.
I don't know the details of your project but I'd suggest the following start point:
- Define the roadmap for the repos. A roadmap is a sequence of releases along with conditions for making the release. An example roadmap item may look like "Version 1.2: implement features F1 and F2. Fix bugs B1 and B2.".
- Use two types of PRs: enhancements (new features, bug fixes, etc.) and releases (bumping version numbers, etc.).
- Require enhancement PRs to always update the CHANGELOG. The top entry in the CHANGELOG can simply say "Next version".
- Release PRs should bump version numbers, prepare the CHANGELOG for another release (e.g. rename "Next version" to "Version 1.2" and add a new empty "Next version" section at the top), ensure READMEs are up-to-date, etc.
- Add a PR template containing a basic checklist: Is CHANGLOG up-to-date? Does the CHANGELOG reference the PR/commit (just pick one and stick with it)?
Let me emphasise that it's important to work on the strategy level (roadmap, releases) and tactical level (enhancements, etc.) separately. A similar distinct needs to be made in product development where PRs, deployments, and releases are three different beasts and should be treated differently.