Simplify the Release Notes tracking process

[AMZN-daimini]

Compiling release notes is a manual, long and tedious process which, at its core, consists of analyzing all PRs for changes submitted to development and stabilization since the last release and looking for relevant changes to highlight.
Whether it is centralized on sig-release or delegated to be broken up per-sig, it is usually hard to retroactively compile this list after months of development to highlight the relevant changes.

A current mechanism to try and minimize the hassle of this process has been to introduce labels to mark PRs containing relevant changes. This has the downside of not being a known or enforced process, though, so it only covers a portion of the changes and reverts to the manual process for the rest of the areas.

It would be valuable to have a system in place, either an established workflow or an automation, to simplify this process for future release in order to make them easier to execute and make it harder to miss relevant features in our communications.

[AMZN-daimini]

An idea that was discussed during sig-release meetings was to introduce a bot that would remind users to mark the PR as relevant for release notes if appropriate, and possibly to add a short description to aid the process.

One of the big points during the conversation was to make this as frictionless as possible. Being an open-source project, O3DE relies on contributions from all sort of sources, which may not have the bandwidth to jump through multiple hoops to get their changes to be even considered for review; as such, the consensus was that this automation should trigger after the change has been submitted.

Here is a first draft of what the process could look like:

• After a change has been merged into the o3de repo (either the development or stabilization branch), a bot could post an automated message detailing the release note process.
• One way to incentivize adoption could be to specify that contributors whose changes are added to the release notes can elect to be named alongside the description if they want (opt-in process).
• If the user determines that the change should be added to the pool for consideration as a release note, there should be a streamlined process to allow them to do so. Not all contributors have the permissions to add labels to their PRs, so the bot could provide a button, accessible to only the author of the PR and maintainers, that when clicked would automatically add the relevant labels to the PR.
• As an extra, optional step, the user should be directed to add a short comment about the extents of the change that can be used to compile the release notes.

[tonybalandiuk]

I support going down this path. Another benefit here is that at any point in time, the community can easily see the new features (with notes) that are in the dev branch since the last release. This will be really helpful for those trying to understand the true functional difference in the branches. (Ongoing release notes was a suggestion from the 22.10 feedback #101 (comment) )

For the above bot-driven process I think it would be useful to keep it label-driven (or something similar) that is easy for everyone to understand that also enables the use case:
"As a community member who want to help compile release note, I want to see all of the PR that have not yet had a decision made around a release note. In other words, the PRs that the bot picked up and posted a message but no action was taken."
I can see myself with an extra few minutes here and there going in and "Resolving" the ones where a release note is clearly not warranted.

[chanmosq]

I think this is a feasible and effective idea. It makes good use of the flexible infrastructure GitHub's web interface provides (which has many examples we can pull from to help with development) and appears to integrate into a contributor's workflow with little overhead. Most importantly, this would significantly lessen the overhead put on all teams to track down PRs for release notes.