When we (@golang/osp-team) triage the issues labeled with release-blocker prior to a release, we often end up sorting them into a finer granularity:

• “blocking the next beta” (issues that will need broad testing before the release),
• “blocking the release candidate” (known regressions with limited impact and clear testing steps),
• “blocking the final release” (documentation, certain kinds of test flakiness).

We end up repeating that classification for each pre-release build, and we spend time discussing the classifications when they could often be made by smaller numbers of people ahead of time.

Furthermore, it's probably useful for folks in the community to be able to see that classification, so that they can set expectations appropriately (and so that they can point out issues that might need more testing than we thought).

I propose that we do one of the following:

a. Create milestones for each pre-release (Go1.13-beta.1, Go1.13-rc.1, and so on).

• These pre-releases are conceptually before the main miletone (Go1.13), so a release-blocker on Go1.13 would indicate the “blocking the final release” category.

b. Or, create labels for each pre-release (next-beta, next-rc), with the expectation of zero next-beta issues open when we cut a beta release and zero next-rc issues open for a given milestone when we cut the corresponding pre-release for that milestone.

• We would need to decide whether to have GopherBot ensure that next-* issues are also labeled release-blocker, or have GopherBot remove the release-blocker label as redundant.