Skip to content

Commit

Permalink
nix-mark-stale-issues: First draft
Browse files Browse the repository at this point in the history
  • Loading branch information
Ericson2314 committed Apr 18, 2022
1 parent 5c9b38a commit 0c9732f
Showing 1 changed file with 82 additions and 31 deletions.
113 changes: 82 additions & 31 deletions rfcs/0000-nix-mark-stale-issues.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
feature: (fill me in with a unique ident, my_awesome_feature)
start-date: (fill me in with today's date, YYYY-MM-DD)
author: (name of the main author)
feature: nix-mark-stale-issues
start-date: 2022-04-18
author: John Ericson (@Ericson2314)
co-authors: (find a buddy later to help out with the RFC)
shepherd-team: (names, to be nominated and accepted by RFC steering committee)
shepherd-leader: (name to be appointed by RFC steering committee)
Expand All @@ -11,48 +11,99 @@ related-issues: (will contain links to implementation PRs)
# Summary
[summary]: #summary

One paragraph explanation of the feature.
Do not auto-close Nix issues and PRs.

Make the policy clear, and harmonize Nix's with Nixpkgs's, which was approved by
[RFC 51](https://github.com/NixOS/rfcs/blob/master/rfcs/0051-mark-stale-issues.md).

# Motivation
[motivation]: #motivation

Why are we doing this? What use cases does it support? What is the expected
outcome?
## Background

# Detailed design
[design]: #detailed-design
In 2019, after much discussion,
[RFC 51](https://github.com/NixOS/rfcs/blob/master/rfcs/0051-mark-stale-issues.md) was approved to mark old Nixpkgs issues and PRs as stale,
but not close anything.

In 2021, @garbas contributed [Nix PR 4526](https://github.com/NixOS/nix/pull/4526),
which initially just made a stale bot configuration in line with Nixpkgs.
But @edolstra [specifically requested](https://github.com/NixOS/nix/pull/4526#discussion_r571687438) that stale items do be closed.
To be clear, there *is* no formal violation, as that RFC was just about Nixpkgs, but we should reconsider whether this was a good idea.

## Clear policy

Firstly, whatever the policy is, it should be clearly announced.

Without a big announcement of this decision, many of us were caught of guard when issues were closed the other day.
Anyone that just saw the previous stale bot "marking stale" messages probably assumed stale bot was configured like Nixpkgs.
Without knowing that auto-closing was enabled, people who might have bothered to aggressively triage stale issues before the auto-close deadline didn't.
For the social aspects of the stale bot auto-closing to work as intended, it is very important people *do* know the policy, because incentivizing that triaging by the threat of auto-closing is precisely the point!

This RFC, no matter the outcome, can help make the policy clear and known to all.

## Consistent policy

All things equal, it is probably not a good idea to pick a different policy for Nix than the one decided by the community for Nixpkgs.
The strong opinions in RFC 51 attest do attest that the community doesn't like auto-closing in that context.
Many of those strong opinions apply to issue tracking for open source project in general, not just for Nixpkgs in particular.

## Nix's particular backlog

This is the core, normative part of the RFC. Explain the design in enough
detail for somebody familiar with the ecosystem to understand, and implement.
This should get into specifics and corner-cases. Yet, this section should also
be terse, avoiding redundancy even at the cost of clarity.
Still, we might ask whether the situation in Nix is different from Nixpkgs in ways that would motivate a different decision.
We would in fact argue the opposite: that Nix is an especially *poor* candidate for auto-closing.
Nix's backlog in particular reflects a long history of the community being able to raise issues without being empowered to address their own issues.
This asymmetry inevitably led an ever-growing backlog.

# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions
We are doing somewhat better now, but have been busy just trying to keep up with new issues, and not yet working retroactively through the backlog as a team.
To finish turning a new leaf, it would be very healthy gesture to go through that backlog, atoning for the prior state of affairs.
Closing the backlog without review forfeits that opportunity.

This section illustrates the detailed design. This section should clarify all
confusion the reader has from the previous sections. It is especially important
to counterbalance the desired terseness of the detailed design; if you feel
your detailed design is rudely short, consider making this section longer
instead.
## Summary

For these reasons, we advocate in priority order:

1. Making the policy, whatever it may be, loud and clear.

2. Making the Nix policy match the Nixpkgs policy, for simplicity.

3. Making the Nix policy not auto-close, in light of the special situation of how the backlog arose in the first place.

# Detailed design
[design]: #detailed-design

Apply this diff to the `.github/stale.yml` configuration file:

1. ```diff
diff --git a/.github/stale.yml b/.github/stale.yml
index fe24942f4..539720b6d 100644
--- a/.github/stale.yml
+++ b/.github/stale.yml
@@ -1,10 +1,9 @@
# Configuration for probot-stale - https://github.com/probot/stale
daysUntilStale: 180
-daysUntilClose: 365
+daysUntilClose: false
exemptLabels:
- "critical"
staleLabel: "stale"
markComment: |
I marked this as stale due to inactivity. → [More info](https://github.com/NixOS/nix/blob/master/.github/STALE-BOT.md)
-closeComment: |
- I closed this issue due to inactivity. → [More info](https://github.com/NixOS/nix/blob/master/.github/STALE-BOT.md)
+closeComment: false
```

2. Reopen recently auto-closed items, either automatically *en masse*, or manually allowing some triage.
The route will be chosen based on human resourcing constraints; it is unclear which is less work.

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this?
Manually combing through the backlog takes time.

# Alternatives
[alternatives]: #alternatives

What other designs have been considered? What is the impact of not doing this?

# Unresolved questions
[unresolved]: #unresolved-questions

What parts of the design are still TBD or unknowns?

# Future work
[future]: #future-work
1. Align Nixpkgs's and Nix's configs some other way.

What future work, if any, would be implied or impacted by this feature
without being directly part of the work?
2. Leave config as-is.

0 comments on commit 0c9732f

Please sign in to comment.