Proposal: Disable the Github stale bot after backlog cleanup; rely on explicit triage labels

[zhijun42]

What would you like to be added?

See details below.

Why is this needed?

Hi maintainers 👋

First of all, thank you for all the work you do on etcd — especially given how demanding infra maintenance is.

Issue

I wanted to share a perspective on the current stale bot setup. It seems clear that the stale bot has already delivered significant value:

• it helped close a large historical backlog
• it reduced open issue count to a much more manageable level
• it lowered cognitive load for maintainers

In that sense, it worked well as a one-off house-cleaning tool.

However, now that the repository has down to ~100 active open issues, I think the cost/benefit has shifted.

At this stage:

• many remaining issues are high-signal (bugs, design questions, infra edge cases)
• inactivity often reflects maintainer bandwidth constraints (we all know how maintainers are heavily overloaded), not lack of value
• auto-closing due to time alone can silently discard useful context and insights. As a curious contributor looking for meaningful work to do, I've found many good issues (I say good because the maintainer indicated it's worth addressing or at least triaging) lost due to auto-close, e.g. Guarantee progress notification to synchronized watch #20242, Campaign watch cancel causes adapter/in-process watch stream permanent blocking #20716, LeaseKeepAlive Unavailable #13632, etc.

I’ve also noticed cases where maintainers removed the stale label added by the bot, and then the bot reapplied the label again after 21 days of inactivity, and then maintainers had to remove once again, and this goes on and on. This is a strong indication that this feature is hurting the project.

Many etcd issues involve distributed systems edge cases, need careful reproduction and require maintainer switch context to even triage. So apparently, Silence ≠ low value.

Proposal

• Treat the stale bot as a completed one-off cleanup mission
• Fully disable it going forward
• Rely instead on explicit human intent via labels such as:
  • to-be-triaged
  • to-be-assigned
  • no-plan
• Acknowledge the fact that some of the current issues might be silent for a long-time, because even adding labels (let alone writing code to fix the bug, etc) to issues requires maintainer's energy and attention. And silence is okay, and we shouldn't rely on any bot to auto remove it.

This keeps the issue tracker:

• honest (closed = decision made)
• information-preserving
• aligned with etcd’s pace and depth as a foundational system
• makes maintainers' life easier - don't need to fight with the bot anymore

Happy to hear thoughts — and thanks again for maintaining such an important project.

And happy Christmas everyone!

[serathius]

Closed issue can always be re-opend, there is no information lost as issues don't disappear. Reason to auto-close is that the author or contributors stopped caring about the issue enough to address it.

[zhijun42]

Thanks for the reply — I understand the intent behind auto-closing and agree that, in some cases, inactivity does reflect a lack of follow-up interest.

However, I think there are important counter-examples in etcd itself that show why time-based auto-closure can distort signal, even when no information is technically deleted.

Let me use the concrete cases mentioned above to explain what I mean.

---

Example 1: Guarantee progress notification to synchronized watch

This issue was opened by a maintainer and contains a detailed, thoughtful feature proposal.

The stale bot marked it stale twice; the label was removed once, but not the second time, and the issue was eventually closed.

I don’t think it’s accurate to interpret this as “the author stopped caring.”

More importantly, regardless of current prioritization, this is high-quality design content that is valuable to potential contributors.

I personally only found it by scanning closed stale issues — it’s effectively invisible if one looks only at open issues.

You might say: “contributors should look for work in open issues.”

The problem is that this artificially constrains the search space. If someone doesn’t find meaningful work in the current open list, the correct response shouldn’t be “there is no meaningful work,” but “we shouldn’t hide historically valuable issues behind time-based closure.”

---

Example 2: LeaseKeepAlive Unavailable

In this case, a maintainer removed the stale label multiple times, which clearly indicates ongoing interest or at least recognition of value. Eventually, the stale bot closed the issue anyway.

Even if the maintainer is no longer actively pursuing it, the users involved in the discussion clearly still care. They cannot reopen the issue because they are not the author.

From a user’s perspective:

• they reached out for help
• maintainers are understandably overloaded
• community contributors who could help are unlikely to ever see the issue once it’s closed

Here, auto-closure didn’t reflect “lack of care” — it reflected lack of maintainer bandwidth.

---

Example 3: Campaign watch cancel causes adapter/in-process watch stream permanent blocking

This issue includes a detailed analysis and a Go reproducer and is directly related to an earlier unsolved issue. It received no response before being marked stale and closed.

From the author’s perspective:

• they never received technical feedback
• they received an automated stale notification
• they may not even realize that commenting again is required to keep the issue open

Even if they do realize this:

• should they repeatedly “ping” just to fight automation?
• will they reliably notice every bot notification?
• should sustained interest require ongoing manual defense against time windows?

This is not about people “not caring” — it’s about how much friction we place on caring.

---

Closed issue can always be re-opend, there is no information lost as issues don't disappear

This is true in theory, but not in practice. Closed issues send a strong social signal:

• “this is resolved”
• “this is not active”
• “don’t touch unless you’re the author”

In the third example above, the only person likely to reopen the issue is the original author. For everyone else, the information is practically lost unless they already know exactly what to search for.

There’s a large body of evidence (and everyday experience) in behavior science showing that humans default to the path of least resistance. Requiring people to:

• notice a stale warning,
• understand the mechanism,
• act within a time window,
• and repeat this indefinitely until someone finally replies

filters out real signal — not because people don’t care, but because the system makes caring expensive.

---

The stale bot clearly helped with historical backlog cleanup, and that was valuable.

But now that the issue list is relatively small and high-signal, I believe the cost/benefit has flipped:

• auto-closure optimizes for short-term cleanliness
• but degrades long-term signal, discoverability, and contributor entry points

That’s why I’m suggesting we consider disabling it at this stage and rely more on explicit maintainer intent rather than time.

Happy to defer to maintainer judgment — I mainly wanted to explain why the “lack of activity = lack of care” assumption doesn’t consistently hold in etcd’s context.