VMR issue management

[mmitche]

We have been using the source-build repository as the catch all for VMR issues that don't fit neatly into another repository. This might mean, for instance:

• A runtime specific VMR issue would go in dotnet/runtime
• An issue specific to signing in the VMR would go into dotnet/arcade
• Epics about VMR versioning go in dotnet/source-build
• An issue about incremental builds would go in dotnet/source-build.

There is a strong desire to stop using the source-build repo for general VMR issues. This is largely because the VMR is not source build, source-build is not the VMR, and the additional issue load in the repo increases the tax on the source-build team. They would reasonably like issues in that repo to reflect the scenarios they care about.

The rough background is that we used source-build because we didn't want to enable issues in the VMR repo (dotnet/dotnet). Doing so would invite external contributors to file product issues in this repo while the VMR was still in heavy development. Even so, product issues do get filed in common shared locations (dotnet/core, for instance). A team is responsible for triaging and transferring these.

This epic is about finding a way forward that works for .NET as a whole.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.