Update dotnet/runtime issue management guide

[eiriktsarpalis]

This draft is an attempt to document and formalize an issue management workflow/guide/playbook intended for reference by both repo maintainers and community members. The guide aspires to

1. Provide a common set of triage guidelines for reference by area owners.
2. Make issue management decisions more transparent and accessible to the wider community.
3. Be used as a basis for further automation of common issue management policies.

This document is being developed by the responsiveness working group as part of the experiment outlined in #1. TL;DR we hypothesize that a well-documented issue management workflow backed by automation of common policies can positively impact responsiveness-related metrics of an OSS repo (e.g. "time to triage", "time to resolution", etc.) by

1. Aiding area owners adopt more efficient triage workflows.
2. Using automation to catch any stagnating issues.
3. Letting maintainers more effectively identify issues where "the ball is in their court".

This document uses triage practices and terminology drawn specifically from dotnet/runtime repo, since we intend to use this document as a basis for conducting responsiveness-related experiments in the dotnet/runtime repo. That being said, many of the concepts described here do transfer to other similar OSS repos as well.

The contents are intended as a supplement to the existing dotnet/runtime issue guide, drawing inspiration from the triage guidelines published by the VS Code and aspnetcore repos.

This is by no means intended to be a definitive or exhaustive guide, however it does aspire to cover most issues (the 20% of known workflows accounting for 80% of all issues). Finally, do note that this draft intentionally omits pull requests, as they are currently not the focus of our experimentation.

[JulieLeeMSFT]

@eiriktsarpalis I added more text yesterday in my repo. Please feel free to take texts from there.

https://github.com/JulieLeeMSFT/contributor-community-experiments/commit/1a38805215aac50cb08682b8f4fb3a164e7d4dba

[danmoseley]

Thanks for working on this.

I like that we're couching this as an example of (something we hope to iterate towards) an effective guide might look like, and NOT as a reference-quality triage process (I have no reason to believe that dotnet/runtime has an excellent process worth others modeling, or even that it's relevant to others, and wouldn't know how to prove it was)

Is there any reason you didn't make this a PR in dotnet/runtime? That's where the community is, so they can see it and give feedback. Once we have something we can merge, and proven (by surveys or other means) that it is worthy of becoming an example, we can put it in this repo.

I do suspect the most interesting part here would be policy and philosophy, rather than mechanics. how we make our decisions. what communication we will do. how others can provide input into the decisions. etc. That is the part that's least codified (even internally, arguably)

[eiriktsarpalis]

I added more text yesterday in my repo. Please feel free to take texts from there.

@JulieLeeMSFT I seem to have permission issues with your fork: that particular link 404's. If you've added more text I'm not able to see it. I have also enabled edits by maintainers, so feel free to push any changes directly to my branch.

[eiriktsarpalis]

Is there any reason you didn't make this a PR in dotnet/runtime? That's where the community is, so they can see it and give feedback. Once we have something we can merge, and proven (by surveys or other means) that it is worthy of becoming an example, we can put it in this repo.

I felt that getting an "Issue management guide" approved for dotnet/runtime would require a substantially wider scope and review than what might be necessary for the purposes of running a localized experiment. I'm certainly hoping that feedback from the experiment could contribute to both a repo-wide guide being incorporated in dotnet/runtime, as well as incorporating repo-agnostic recommendations here.

[JulieLeeMSFT]

permission issues with your fork

It was marked as private. I made it public just now. You would be able to see it now.

[eiriktsarpalis]

@JulieLeeMSFT I incorporated the contents of your draft, essentially verbatim. Following feedback from @danmoseley I renamed my section "Issue Workflows" and integrated it as a section in your text which is establishing a broader scope. There is a slight amount of duplication, particularly in defining our triage process but I thought I'd merge the two documents first and refine later.

[Pilchie]

I took a look at this, and I definitely like it.