Stalled RFCs RFC

[kevincox]

Rendered RFC

Discussion notice: please try to attach all discussions to a thread by using the code review feature. Even if your comment doesn't refer to a particular line or section just pick any one (maybe the first header?)

[ryantm]

Some spelling and grammar fixes. I volunteer to shepherd this RFC.

[kevincox]

Thanks @ryantm! I second your shepherdness.

I would also like to nominate @spacekookie as a shepherd.

[kevincox]

Also nominate @LunNova and @kamadorueda as shepherds.

[ryantm]

I nominate @7c6f434c who has a good sense for RFC rules.

[7c6f434c]

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.

[kevincox]

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.

[7c6f434c]

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.

[kevincox]

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?

[7c6f434c]

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)

[kevincox]

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?

[7c6f434c]

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.

[kevincox]

Attempted to solicit more feedback here: https://discourse.nixos.org/t/stalled-rfcs-proposing-rfcs-with-no-interest/21952

[lheckemann]

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

[kevincox]

@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

[7c6f434c]

I hope there are enough shepherds without me… (time constraints etc.)

I will try to pay attention to the discussion at least from time to time and apply «consistency» view to it.

I guess if there are not three accepted nominations in a month I could be (a pretty bad in terms of not always predictable scheduling constraints) a shepherd…

I would also like to nominate @spacekookie as a shepherd.

Are co-authorship and shepherding compatible? From a quick skimming of #36 it looks like no.

[kevincox]

Oops, good point.

[tomberek]

I nominate myself as a shepherd.

[edolstra]

This RFC is now in discussion with the following sheperds: @kevincox, @tomberek and @7c6f434c (if you're still available and willing). Thank you!

[7c6f434c]

I still literally fail to predict my availability three hours in advance, but I also still try not to disappear completely.

I hope we won't need to discuss much fully synchronously here, so it should be fine.

[ryantm]

@edolstra the steering committee minutes say I'm a shepherd too. Kevincox can't be a shepherd since he is the author. Could you clarify? Also, who did you decide is the shepherd leader?

[kevincox]

Probably a mistake. Sounds like he meant to say @ryantm, @tomberek and @7c6f434c

Can anyone volunteer as the lead shepherd?

[ryantm]

I can be the leader.

[kevincox]

Shall we try to set up an initial meeting in https://matrix.to/#/#nix-rfc130:matrix.org?

[Profpatsch]

It’d be fun if this RFC stalled ;)

[kevincox]

I was told that dogfooding is a good practice 😛

[ryantm]

As it currently stands, I'd call for an FCP vote if that diagram were fixed. The only person I see lightly objecting to this RFC is @7c6f434c. Do you feel this RFC needs to be substantially changes to be acceptable to you?

[7c6f434c]

Well, accepting my request would not change the diagram, so the changes I asked for are not massive. I do think that given the precedents on auto-closing vs. labelling there is a significant burden of justification for going in the other direction. As currently no argument is given, I assume the precedent was not considered because realistically nobody can keep track of everything that gets discussed somewhere in the community.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/stalled-rfcs-proposing-rfcs-with-no-interest/21952/1

[7c6f434c]

OK, as 10 days have passed: I was clearly wrong. I expected some reaction, but indeed this doesn't seem to cause controversy.

I think a reference to #51 would be nice just to write down that this issue was considered and situation is apparently different enough. (I am a proponent of RFCs containing the decision records in themselves, without relying on GitHub comments)

I agree that «closed + status: open for nominations » forms a clear and searchable indication for all RFCs closed for lack of interest (so no need to add a special label if the PRs are closed).

[ryantm]

Thanks for pushing this forward (without much help from me). I re-read the RFC. It looks like the diagram is fixed and some additional community outreach was done, so I think this is ready to go!

As a shepherd of this RFC, I formally propose starting the Final Comment Period with disposition to accept.

As usual, the FCP will start as soon as all the other shepherds (@tomberek and @7c6f434c) confirm agreement and the FCP is announced here and on Discourse.

[tomberek]

As usual, the FCP will start as soon as all the other shepherds... confirm agreement and the FCP is announced here and on Discourse.

Agreed. I have no objections.

[ryantm]

@7c6f434c, are you comfortable proceeding to FCP with the understanding that this mention of RFC 51 will be wrapped up during that?

[7c6f434c]

I do find slightly regrettable the tendency to start FCP while the rendered version does not have any version of some point known to be coming before merge. Meaning-preserving polishing is of course fine.

Do we have any specific time pressure here or is the cost of doing things properly relatively low this time around?

[7c6f434c]

I now support starting the FCP with the disposition to accept.

[ryantm]

The Final Comment Period for #130 has started with disposition to merge and, barring any blocking issues, will be merged after 10 calendar days (2022-10-22). Your opinions, comments, approvals, and objections are welcome!

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfc-0130-fcp-stalled-rfcs/22415/1

[ryantm]

@NixOS/rfc-steering-committee, the FCP has passed, and there is nothing blocking this RFC. Please merge it!