Use of the milestones

The way we use milestones is somewhat arbitrary. There's always a single milestone for the next version and we add PRs to that when we want a PR merged for the next release, or just before merging. We sometimes end up having to remove PRs from the milestone. It's a manual process, and a merged PR may accidentally be left out of the milestone.

I was thinking about what the purpose of this system is. The milestone's supposed to tracks progress, but isn't indicative of anything if we may add something to it at any time. It can be used to check for what to review, but you could also filter PRs by approved review, and all the results are in need of a second review to be merged for the next release, which is basically the same.

It can be used to see what changes were made between releases in a cleaner format than a list of commits. Is there another way to see which PRs were merged between releases?

If there's an easy way to create release notes without the milestones, we can consider not using the milestones for releases.

If we keep the milestones and want to keep track of the PRs merged, we could add them to the milestone just before merging, or maybe just keep doing things the way we are currently doing. Let me know what you think.

Relates to #1514, where a maintainer's guide is being added, where the resolution of this issue should be placed.

Review the maintainer's guide work in #1514 and the current GitHub milestone and release-note workflow. Compare milestone-based tracking with available ways to identify pull requests merged between releases, then document the agreed process and place the resolution in the maintainer's guide.