open-telemetry / opentelemetry-dotnet

The OpenTelemetry .NET Client
https://opentelemetry.io
Apache License 2.0
3.23k stars 765 forks source link

Proposal for Stale issue automation #5776

Closed TimothyMothra closed 3 months ago

TimothyMothra commented 3 months ago

This repo has had automation to close stale PRs for a few years now. I'm opening this issue to discuss managing issues with the same stale automation.

What is the expected behavior?

I'm proposing expanding the existing Stale automation to also manage Issues in this repo.

  1. Issues older than X days will be marked Stale.

    • Currently 342 open issues (Aug 20, 2024).
    • older than 300 days (Oct 25 2023) = 174 issues
    • older than 600 days (Dec 29 2022) = 83 issues
    • older than 900 days (Mar 4 2022) = 33 issues
    • older than 1000 days (Nov 24 2021) = 17 issues
    • older than 1100 days (Aug 16 2021) = 8 issues
    • older than 1200 days (May 8 2021) = 0 issues

    I would work with maintainers to gradually lower this to 300 days. As this is a new process, we want to avoid being too aggressive while we work through the backlog and fine tune the automation. First priority is getting through the oldest issues.

  2. Exempt specific issues.

    The automation gives us multiple options to control which issues are marked as stale. These are the two that I think are most applicable for this repo:

    • exempt-all-issues-milestones Any issue assigned to a milestone would be exempt.
    • exempt-issue-labels Any issues assigned to a set of labels would be exempt. I'll need some input from maintainers to capture this list. The short list I would start with is; need-runtime-change,await-spec,help wanted
  3. Stale issues with no additional activity will be closed after 7 days. This is the same policy we use for PRs.

Additional context

Current Stale automation: https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/.github/workflows/stale.yml

Stale workflow api: https://github.com/actions/stale?tab=readme-ov-file#all-options

vishweshbankwar commented 3 months ago

Thanks @TimothyMothra!. This looks good to me. One additional thing I think we need to do is to remove the questions tag from issues, we should direct users to discussion section for that.

CodeBlanch commented 3 months ago

I like this! One suggestion. I think it would be a bad look for us to close things as stale which never had a response or anyone looking at them at all. Not sure if it is possible to do that OOB?

One idea to make it work...

The idea would be someone would need to at least look at the thing once and remove needs-triage before it becomes eligible to become stale.

TimothyMothra commented 3 months ago

@CodeBlanch, ~It looks like there are only 4 issues that have never been triaged.~ I think your proposal is fair, but I'm reluctant to add extra processes. Also note that adding a "needs-triage" label today will count as activity and reset the clock on all those issues.

Would it be sufficient to increase the time period that stale issues are closed (2-3 weeks)? That would give maintainers extra time to triage those issues and possibly respond.

-- Edit, actually most issues get a label when opened. Many of the issues without comments have 2+ labels. I would count this as having been triaged.

vishweshbankwar commented 3 months ago

is it possible to only set the needs-triage label for the new ones?

CodeBlanch commented 3 months ago

Ya sorry for the confusion. What I meant was we would edit the templates to add "needs-triage" only on new issues going forward. For everything that already exists we could just implement the stale rules as proposed. Essentially everything out there would go stale. But new stuff we would have this new process where it wouldn't go stale until someone "triages" it at least once.

TimothyMothra commented 3 months ago

Ya sorry for the confusion. What I meant was we would edit the templates to add "needs-triage" only on new issues going forward. For everything that already exists we could just implement the stale rules as proposed. Essentially everything out there would go stale. But new stuff we would have this new process where it wouldn't go stale until someone "triages" it at least once.

I'm good with this!