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.