Issue Bankruptcy

[danmoseley]

Hypothesis

There's a substantial backlog of obsolete or stale issues and we could use a heuristic to close a significant number ("issue bankruptcy"). The policy would initially cause a large number to be closed, then stay in place periodically closing issues that meet the criteria. Several major repos including non Microsoft repos have such a policy.

Experiment

We will be trialing an issue bankruptcy experiment in dotnet/runtime focused on area-System.Collections and area-System.Text.Json. There are a number of parameters to be considered for the experiment:

Selection Criteria

• Focus on Future milestone issues that have not been updated in over 6 months.
• Exclude popular issues, e.g. issues that contain a large number of responses or upvotes.
• Possibly exclude issues where the ball is clearly in our court (although that is probably vague and might be impossible to express in a query).

Execution

1. FabricBot applies a no recent activity label to selected issues and writes a post explaining that the issue has been marked for closure, linking to documentation related to this experiment, potentially encouraging users to submit their feedback on the process.
2. If no response has been provided within 14 days, the issue will be closed automatically by FabricBot. Otherwise, FabricBot will remove the no recent activity label from the issue.

Timing

Ideally we would want this experiment to coincide with the planning phase of a next release.

Success criteria

Reduction in the number of open issues in the Future milestone.

[danmoseley]

@eiriktsarpalis suggested trialing in dotnet/runtime first.

We have some data from other repos we can share here.

[eiriktsarpalis]

I have updated the OP with more details on the planned experiment.

[danmoseley]

Suggest to post a sticky issue first in the repo to explain the experiment, what we're going to do and why and encourage folks to help us do it right and learn from it -- and give the community some time (eg., a week) to share their thoughts.

Note that in dotnet/runtime, closed issues currently can be reopened by the original author within 30 days of the last activity -- after that they're locked. We can consider adjusting that automation of course.