-
-
Notifications
You must be signed in to change notification settings - Fork 161
Stalled RFCs RFC #130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stalled RFCs RFC #130
Changes from all commits
ba25848
0338d1a
1b485ff
ae65c3c
8a2bf4a
5c53fcb
eb5dbdd
1a89c46
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,147 @@ | ||
| --- | ||
| feature: stalled-rfcs | ||
| start-date: 2022-06-01 | ||
| author: kevincox | ||
| co-authors: spacekookie | ||
| shepherd-team: @ryantm, @tomberek, @7c6f434c | ||
| shepherd-leader: @ryantm | ||
| related-issues: (will contain links to implementation PRs) | ||
| --- | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| This defines two alternate "end states" for RFCs. | ||
|
|
||
| The "Awaiting Author" state defines an RFC that isn't ready to be pushed forward and is intentionally stalled. The NixOS RFC Steering Committee will not ping or push this RFC until it returns to the main workflow. These RFCs will be put into a draft status until they are ready to re-enter the process. | ||
|
|
||
| The "Lacking Interest" state defines an RFC that can not gather a shepherd team. This is taken to indicate that there is not enough interest in the Nix community. These RFCs will be Closed until more interest is gathered. | ||
|
|
||
| # Motivation | ||
| [motivation]: #motivation | ||
|
|
||
| The NixOS RFC process describes a process with a focus on moving RFCs toward completion. This is where an engaged author and community push an RFC to a decision, either to accept or reject the proposal. | ||
|
|
||
| However things don't always work like this. Sometimes the author doesn't have sufficient time or motivation to keep iterating on the RFC and sometimes the community doesn't have enough interested members to staff a shepherd team. | ||
|
|
||
| It is important that these "alternate exits" are well defined to avoid wasting effort trying to push a stalled RFC forward and to set clear expectations for all participants. | ||
|
|
||
| TL;DR timeouts are critical in distributed systems. | ||
|
|
||
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| Here is an updated diagram for the RFC process. | ||
|
|
||
| ```mermaid | ||
| graph TD | ||
| Start((Start)) --> Draft | ||
| Draft -->|Ready for Review| Discuss | ||
| style Draft fill:#008,color:#FFF | ||
|
|
||
| Discuss[Discuss and Refine] | ||
| Discuss ---> |On Hold| Draft | ||
| Discuss --> |Can't Find Shepherds| NoShepherds | ||
| Discuss --> |Motion for FCP| FCP | ||
|
|
||
| NoShepherds[Closed - Lack of Interest]:::closed | ||
| NoShepherds --> |Renewed Interest| Discuss | ||
|
|
||
| FCP[Final Coment Phase] | ||
| FCP --> |FCP Canceled| Discuss | ||
| FCP --> |Accept| Merged | ||
| FCP --> |Reject| Rejected | ||
|
|
||
| Merged | ||
| style Merged fill:#080,color:#FFF | ||
|
|
||
| Rejected[Closed - Rejected]:::closed | ||
|
|
||
| Withdrawn[Closed - Withdrawn]:::closed | ||
| Discuss & Draft --->|Author Withdraws| Withdrawn | ||
|
|
||
| classDef closed fill:#800,color:#FFF | ||
| ``` | ||
|
|
||
| There are 3 new transitions in this diagram. | ||
|
|
||
| ## On Hold | ||
|
|
||
| This is for cases where the author is unable or unwilling to update the RFC in a timely fashion and would like to indicate that the RFC should not continue to be pushed forward for the time being. | ||
|
|
||
| The author can [mark the PR as a Draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#converting-a-pull-request-to-a-draft) and the existing label [status: on hold](https://github.com/NixOS/rfcs/pulls?q=is%3Apr+label%3A%22status%3A+on+hold%22+is%3Aclosed) can be applied to the PR by the NixOS RFC Steering Committee for tracking reasons. | ||
|
|
||
| RFCs in this status will be completely ignored by the NixOS RFC Steering Committee. It is also expected that community members will largely refrain from review until the author has indicated that the RFC is again ready for review. | ||
|
|
||
| ## Can't Find Shepherds | ||
|
|
||
| If an RFC is unable to find adequate number of shepherds in 2 months it will be considered "low interest". The RFC will be closed to indicate that there is no expectation of continuous forward progress. | ||
|
|
||
| After 1 month of being open, the following message will be added to the PR to suggest ways to find more support: | ||
|
|
||
| > This RFC has not acquired enough shepherds. This typically shows lack of interest from the community. In order to progress [a full shepherd team is required](https://github.com/NixOS/rfcs/#shepherd-team). Consider trying to raise interest by [posting in Discourse](https://discourse.nixos.org/), [talking in Matrix](https://matrix.to/#/#community:nixos.org) or reaching out to people that you know. | ||
| > | ||
| > If not enough shepherds can be found in the next month we will close this RFC until we can find enough interested participants. The PR can be reopened at any time if more shepherd nominations are made. | ||
| > | ||
| > [See more info on the Nix RFC process here](https://github.com/NixOS/rfcs/blob/master/README.md) | ||
|
|
||
| If another month has elapsed since the warning without sufficient accepted nominations the following message will be posted, the `status: insufficient interest` label will be added and the issue will be closed. | ||
|
|
||
| > This RFC is being closed due to lack interest. If enough shepherds are found this issue can be reopened. If you don't have permission to reopen please [open an issue for the NixOS RFC Steering Committee](https://github.com/NixOS/rfc-steering-committee/issues/new) linking to this PR. | ||
|
|
||
| ## Renewed Interest | ||
|
|
||
| If an RFC that was closed due to lack of interest finds sufficient interest it can be reopened and the `status: insufficient interest` label removed. The RFC will then continue through the RFC process as normal. | ||
|
|
||
| # Examples and Interactions | ||
| [examples-and-interactions]: #examples-and-interactions | ||
|
|
||
| ## More Research Required | ||
|
|
||
| If an RFC is opened and discussion reveals that more research is required, the author may now return their RFC to draft status to indicate that they are working on an update. | ||
|
|
||
| This is already frequently done today, but this RFC codifies this process. The alternative, which is sometimes seen is that the NixOS RFC Steering Committee keeps pinging the RFC for months trying to move the RFC forward which is annoying and unproductive. | ||
|
|
||
| ## Can't Find Shepherds | ||
|
|
||
| If an RFC is opened but a team of shepherds can't be assembled the RFC will now be closed. | ||
|
|
||
| Currently there is no process here and the NixOS RFC Steering Committee is unsure what to do and tends to annoyingly ping these RFCs with no positive outcome for a few months then improvise. This RFC proposes a well-defined process to ensure that everyone understands the process. | ||
|
|
||
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| ## Closing a PR may be demotivating. | ||
|
|
||
| Struggling to find shepherds for an RFC may already be demotivating and having the RFC closed can be an additional flag that the RFC is struggling. This may be demoralizing to the RFC author. | ||
|
|
||
| This issue is mitigated by having clear and well-thought-out messages to make it clear what is occurring at this stage of the process. This is hopefully better overall than the previously poorly defined state of forever waiting for more shepherds to appear. | ||
|
|
||
| ## Closing a PR may reduce visibility for the RFC. | ||
|
|
||
| Leaving PRs open may increase the chance that a potential shepherd finds the RFC. Closing RFCs that can't find shepherds may worsen the thing that ails them. | ||
|
|
||
| It is the author's opinion that having dozens of open RFCs will also reduce visibility from the ones that do have more interest and are more likely to find a full shepherd team. Therefore this is considered an acceptable cost. The addition of the `status: insufficient interest` label may also help to bring attention to these RFCs that could benefit from would-be shepherds. | ||
|
|
||
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| ## Do Nothing | ||
|
|
||
| Doing nothing leaves the behaviour to be taken when an RFC can not find a shepherd team undefined. This leads to inconsistent handling by the NixOS RFC Steering Committee and leaves community members unable to understand what to expect. | ||
|
|
||
| ## Leave the PR open and add a label | ||
|
|
||
| This can reduce the burden from the NixOS RFC Steering Committee however it still clutters the list of "Open" RFCs with these RFCs that are not seeing forward progress. Ultimately it is a decision of definition of what "Open" means and this RFC takes the stance that if an RFC is stalled for too long it makes sense to remove it from the default search for "Open" RFCs. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Argument in favour of this approach: we have had two separate discussions about stale PR handling, with the end result being «label but don't close». I think consistency is good. Note that we have few enough RFCs that a round of RFC SC pings ensures that probably-live ones are indeed on top in the list sorted by last-updated.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The main tangible difference I see is if we want these to appear in the default search which on GitHub is "where open order by created descending". The current proposal will hide these whereas this alternative will interleave these with other open and active PRs. RFC SC can easily pin the right search to see what they want so it doesn't really matter to them. Personally I have a small preference for hiding them to focus attention on "active" PRs but I definitely see the argument for trying to get more attention to these PRs that need attention most, even if that thins out the attention for other PRs a bit. But I don't have a strong opinion either way. I avoided responding to this comment earlier in hopes that others would add their opinion but it seems like there isn't that much debate here.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We have #51 where various «clean list» argument were presentde but ended up rejected, and #124 seems to show that sometimes there is a lot of support to make policy similar to #51. It is true that RFC proposals are slighlty different, but then I guess we need a detailed argument why it is better to pick a different policy than for Nixpkgs and Nix repos here, and I guess a dedicated large announcement. Otherwise it would be natural to expect that things get labeled not closed. I would expect people look for «what is active» and sort by activity, or «what discussions have I missed» (sorting by creation time) and then it is not always clear if RFCs lacking shepherds are out of scope. It does look like right now «draft» label seems to mix waiting-on-author and lacking-shepherds right now… making this available at glance will surely be useful. For closing clearly-not-going-anywhere… maybe add a transition where force closing can be done if some person bothers to ask the author what's the plan and does not get any response at all in a month? I guess switch of authorship requires resubmission in any case.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm usually against "clean list" arguments. But that is more because for issues it is helpful to find the existing ones. For RFCs I'm not as sure, but maybe I'm over-valuing the "browsing" use case. I think if we do the label approach then we end up where the author may give up after a while and close. Or we may have lots of open PRs where the author gave up and forgot. Do you feel strongly?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I would say RFCs are also proposed as a reaction to a perceived issue with something we are doing!
I am making an even weaker objection: it is unclear how this use case is split among a few plausible variants (which are better served by different decisions).
Author withdrawing is fine. As I said, human-judgement-driven (without recommended timeline) check if author went missing is also fine and maybe it could be added as a text-only clarification (if authors are nowhere to be found, I guess it counts as the authors withdrawing themselves from the process, so it's just a footnote for an existing transition…).
I feel strongly that fixed-delay-based closing of discussions within NixOS namespace at GitHub needs a very public announcement of intent and justification which explicitly shows that arguments from #51 are not applicable here (and then, well, lack of strong pushback in replies to that announcement). But my position is more process-based: I have nothing against this decision if the heads-up announcement is there, stresses the difference, and is well received. (I guess I would prefer uniformity, but that's a weak preference and people mostly agreeing this case is separate would override it)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd be happy to get more eyes on this but am not sure of the best avenue to get more eyes and opinions than this RFC What would you recommend?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe a Discource heads-up announcement that one part of the current RFC might be surprising for some? If you think it is a good idea, we could mention-ping the other shepherds to check for reasonability, maybe in the non-line-tied part of the discussion.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Attempted to solicit more feedback here: https://discourse.nixos.org/t/stalled-rfcs-proposing-rfcs-with-no-interest/21952
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (reposted from where I previously put it, which was the wrong place)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @7c6f434c and others. I have proposed a note to codify this check in the RFC document. Does this sound good to you? https://github.com/NixOS/rfcs/pull/130/files#r990635602 |
||
|
|
||
kevincox marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Due to similarity with [RFC 51 - Mark stale nixpkgs issues](https://github.com/NixOS/rfcs/pull/51) which settled on labeling without closing after a lot of discussion, extra effort was made to ensure that this was not too controversial. Notably a forum post at https://discourse.nixos.org/t/stalled-rfcs-proposing-rfcs-with-no-interest/21952. It appears that to the Nix community this is in fact a substantially different case so closing is acceptable. | ||
|
|
||
| # Unresolved questions | ||
| [unresolved]: #unresolved-questions | ||
|
|
||
| None | ||
|
|
||
| # Future work | ||
| [future]: #future-work | ||
|
|
||
| The ony work that needs to be done is updating documentation and informing the NixOS RFC Steering Committee. | ||
Uh oh!
There was an error while loading. Please reload this page.