diff --git a/rfcs/0000-nix-mark-stale-issues.md b/rfcs/0000-nix-mark-stale-issues.md index 43569cf57..3a8bc34da 100644 --- a/rfcs/0000-nix-mark-stale-issues.md +++ b/rfcs/0000-nix-mark-stale-issues.md @@ -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) @@ -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.