Skip to content
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.

Sign up for GitHub

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

Merged
merged 8 commits into from
Oct 24, 2022
Merged

Stalled RFCs RFC #130

Changes from 3 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
ba25848
Stalled RFCs RFC
kevincox Jul 12, 2022
0338d1a
Rename with PR number
kevincox Jul 12, 2022
1b485ff
Spelling fix.
kevincox Jul 13, 2022
ae65c3c
Spelling and Grammar Fixes
kevincox Jul 27, 2022
8a2bf4a
Update shepherds.
kevincox Sep 10, 2022
5c53fcb
Fix diagram rendering.
kevincox Sep 23, 2022
eb5dbdd
Add reference to https://github.com/NixOS/rfcs/pull/51
kevincox Oct 11, 2022
1a89c46
Fix brain-typo.
kevincox Oct 11, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
145 changes: 145 additions & 0 deletions rfcs/0130-stalled-rfcs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,145 @@
---
feature: stalled-rfcs
start-date: 2022-06-01
author: kevincox
co-authors: spacekookie
shepherd-team: (names, to be nominated and accepted by RFC steering committee)
kevincox marked this conversation as resolved.
Show resolved Hide resolved
shepherd-leader: (name to be appointed by RFC steering committee)
kevincox marked this conversation as resolved.
Show resolved Hide resolved
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 sufficent time or motivation to keep iterating on the RFC and sometimes the community doesn't have enuogh interested members to staff a shepherd team.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

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
kevincox marked this conversation as resolved.
Show resolved Hide resolved
graph TD
Start((Start)) --> Draft
Draft -->|Ready for Review| Discuss
style Draft fill:#008,color:#FFF

Discuss[Discuss and Refine]
Discuss --> |On Hold| Draft
kevincox marked this conversation as resolved.
Show resolved Hide resolved
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 fashon and would like to indicate that the RFC should not continue to be pushed forward for the time being.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

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 adaqite number of shepherds in 2 months it will be considered "low interest". The RFC will be closed to indicate that there is no expection of continuous forward progress.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

After 1 month of being open the following message will be added to the PR to suggest ways to find more support:
kevincox marked this conversation as resolved.
Show resolved Hide resolved

> 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/), [taking in Matrix](https://matrix.to/#/#community:nixos.org) or reaching out to people that you know.
kevincox marked this conversation as resolved.
Show resolved Hide resolved
>
> 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 sufficent accepted nominations the following message will be posted, the `status: insufficent interest` label will be added and the issue will be closed.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

> 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 sufficent interest it can be reopened and the `status: insufficent interest` label removed. The RFC will then continue through the RFC process as normal.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

# 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.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

This is already done 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.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

## Can't Find Shepherds

If an RFC is opened but a team of shepherds can't be assembed the RFC will now be closed.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

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.

Strugging to find shepherds for an RFC may already be demotivating and having the RFC closed can be an aditional flag that the RFC is strugging. This may be demoralizing to the RFC author.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

This issue is mitigated by having clear and well-thought-out messages to make it clear what is occuring 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.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

## 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 acceptable cost. The addition of the `status: insufficent interest` label may also help to bring attention to these RFCs that could benifit from would-be shepherds.
kevincox marked this conversation as resolved.
Show resolved Hide resolved

# 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.
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

@kevincox kevincox Sep 21, 2022 •
edited
Loading

Choose a reason for hiding this comment

The 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.

Copy link
Member

@7c6f434c 7c6f434c Sep 21, 2022 •
edited
Loading

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for issues

I would say RFCs are also proposed as a reaction to a perceived issue with something we are doing!

maybe I'm over-valuing the "browsing" use case.

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).

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.

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…).

Do you feel strongly?

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(reposted from where I previously put it, which was the wrong place)
I think an important distinction between auto-closing issues and this where the responsibility for getting it out of that state lies; with automatically closed issues, only people with write access to the repo can reopen them. In the case of RFCs, any group of people with enough interest can pick the RFC up and get it moving again, and the RFC Steering Committee will see and apply the administrivial changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
# 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.