improve/define procedure for tagging new releases

[miabbott]

I would like to suggest that we define the process and, more imprtantly, the criteria required for tagging new releases.

Since we have a group of maintainers that not only span time zones, but also have different motivations and requirements for this FDO implementation, it is crucial that we are able to reach agreement not only when a release is needed but also what we require before cutting a release.

I would start by suggesting that if a release is desired, an issue or discussion should be started to explain the need for a new release. (Perhaps this could be handled in a release PR itself, but that feels like overloading that mechanism). Empty PRs to faciliate the release without context are not useful, especially if discussion about a new release has happened in private chats/DMs, etc.

Additionally, I would like to suggest that we should enforce a level of quality on releases: minimally if CI jobs are failing for some reason, we should be addressing those failures before finalizing any releases. But perhaps we need more evidence provided that a release is stable enough.

We could go even further by documenting the mechanical process of making a new release, so that non-maintainers have the ability to contribute in that way.

I believe this would ultimately improve the quality of this project and increase the ability for others to contribute and follow along with development.