Agreed, without a team dedicated to move the RFCs forward it looks like they are going to stall.

I have merged those who had good positive consensus but haven't invested nearly enough time to groom the others so that they either bloom or die. It is also not fair to those invested in the RFCs to not have an outcome from the effort they invested in.

The Swift RFC process, particular the review section, might be relevant for inspiration: https://github.com/apple/swift-evolution/blob/master/process.md#review-process

Two takeaways for Nix IMO:

1. Proposals come up for debate and to gather consensus for a specific amount of time. A core team member is responsible for making the announcement and determining consensus among the core team and community.

2. Proposals are required to come with a prototype implementation or demo of some sort to ensure that they are feasible and that the proposal solves the problems it is meant to solve.

The prototype idea would definitely be useful in more complicated RFCs.

Right now we are missing a notion of "core team" so everything is a bit ad-hoc. I think that's the biggest issue, we don't have that authority to lean on when things are undecided.

I can see a simple definition of “core team” right now: people with push access to the nixpkgs repository.

These are already the most trusted people in the community, for they can do anything with nixpkgs. As such, it would make sense to designate them as the core team.

Then, it would also mean an increased weight on their shoulders, but if it is shared among all of them, maybe...? Also, giving this work to someone less trusted would mean giving them quite a lot of power, as when things are really undecided they would be allowed to pick their choice. And when the choice is obvious it shouldn't take long anyway, so it wouldn't save much time by offloading the “easy RFCs” to non-core-team-members.

That would work for the nixpkgs repo. Maybe we can establish that rule and then have another "core team" for the other NixOS repos.

I assumed it is the co-authors that are "responsible for" (and interested in) pushing their RFC forward. Of course, in practice there will be cases when there's no (strong) argument to reject and at the same time there aren't enough interested people to make the change happen...

@zimbatm Oh indeed, I didn't think of the fact that the nix repo likely has another set of people-allowed-to-push.

Also, I don't think it's possible to list people with push rights on a repository from the outside. (or at least I haven't found out how) So anyway this RFC, in its final form, should either include the list of people in the core team(s) or point out how to obtain the current one. (I'd rather have the second option)

Then, having two core teams sounds like an issue to me: what about changes that would require changes to both nixpkgs and nix, for example? (I'm only considering nix and nixpkgs, as these are the only two targets of RFCs currently, afair)

I'd think having a single core team would be better, although then the choice of “who” is no longer obvious.

Maybe there would be a not-too-short list of people with push access to both repositories? Or maybe considering the fact that nix and nixpkgs are currently quite coupled both teams could be merged?

@7c6f434c I guess other RFC processes have the same issue, so... I was thinking would be giving explicitly any member of the core team the explicit (via this RFC) right to decide, and then for too-controversial issues the choice can just be made by someone who 1/ isn't a PR author or co-author, and 2/ is present when the RFC expires (that is, with the current draft, 2 weeks after the last comment)

Stating that for all the RFCs, either the discussion must go on or the choice must be made, would allow arguments to keep going and when nothing happens the RFC is not stuck in limbo. Any member of the core team should feel authorized to make the choice, regardless of the ideas of X who maybe knows better... because X, who maybe knows better, should have answered before the expiration of the 2 weeks, if he was actually interested in the outcome of the RFC.

I don't know whether my point of view over this issue is clear, or if maybe I misunderstood your comment? Basically, I think that people who haven't reacted before the RFC expires are assumed to have no opinion on the subject, thus all arguments are assumed to have been exposed when the RFC expires, and thus any member of the core team is allowed to make a final choice on the RFC based on community consensus and exposed arguments.

@vcunat Well, I assumed that too at first, but even after now 7 months of pushing up #12 through various means (bumping the PR, a mail on the mailing list and a few times pasting the link on IRC), I still don't know what is the current state of the PR (waiting for some information? ready to be accepted? ready to be rejected? waiting for some change from me I didn't see?)

That's the reason why I've raised this RFC, and also because my tentative implementation of #12 is currently bitrotting on my local nixpkgs.

I think I get what you mean, but is not having any RFCs better? In the current state of affairs sending an RFC is completely pointless, given as soon as there is even a bit of discussion the RFC is not going to be merged.

Honestly, I think waiting indefinitely for the right person to answer is worse than sometimes pushing something wrong and then reverting the decision once someone states the choice was wrong. Especially with RFCs, where a new round of discussion can still be triggered when the implementation PR comes.

I'm not saying to expect people to react on 3 days' notice (maybe i'm underestimating the required “expiration” time by stating 2 weeks?), btw, if someone's opinion is actually required for a RFC to go forward one of the decisions of the core team member after the expiration time is passed do already include “Waiting for information from anyone” in the current draft. Then at least the RFC is not stuck in limbo, but rather explicitly blocked on a missing piece of information from either anyone (eg. benchmarks?) or from someone specific (eg. X who actually knows better according to everyone's opinion). And this would be an explicit request for comment, unlike the current state where noone knows whose turn it is to answer or decide next.

The main point here being to not have a “what-to-do-now?” state, which is currently I believe the prevalent state in open RFCs.

Been enjoying reading the discussion 😃

The main point here being to not have a “what-to-do-now?” state, which is currently I believe the prevalent state in open RFCs.

Hear hear. Let me put it another way: once an RFC's written, the prototype's ready, all that's left to do is merge it, there should be a limited period for discussion that's blasted out widely (IRC, email, etc). At the end of which it's either merged, or rejected (for now). The "core team member" above is in practice just designating someone to do the email blast and the final merge, and maybe facilitate any discussion although as pointed out up-thread, co-authors would be doing that in an ideal world.

Oh, I didn't get your 1., thanks for the clarification!

As for the finalization of RFCs, I had understood the RFCs as evaluating whether we want to make the “value” tradeoffs, and then once the decision has been reached discussion on the “value” tradeoffs in the implementation PR should be inexistent -- because all arguments would already have been exposed in the RFC debate, and repeating again the same argumentation would be pointless. If additional arguments are brought up during the implementation PR, well, that's a breach of the expected RFC process (so hopefully should be rare enough), and I guess it should be handled on a case-by-case basis anyway?

As for the utility of finalizing RFCs, I think at least #5 and #12 (the two I'm personally most interested in, most likely other RFCs do too) have an almost-complete implementation that is waiting for the RFC “seal of approval” before being PR'd or merged. Having had a debate and everyone now agreeing (like these two look like to me, though I'm likely biased for wanting to see them merged), I believe they could now be merged. But without merging them there is always the question, for the RFC author, of “did I miss something that is the reason for it not being ready for merge yet? should I wait more before pushing forward the implementation?”

For another example, #9 is completely about the RFC being merged, as the implementation of the RFC would be a change in behaviour. I seem to remember there was still a debate on this one, so maybe it is not ready yet (then, the work of the RFC team would be to identify the points that are still in debate so as to get to a consensus on these points too), but accepting or rejecting it is a choice of policy in itself.

Actually I think maybe the point on which we disagree is whether RFCs are binding? To me, a merged RFC means “today, with regard to the arguments exposed, the community wants this merged, and if a technically correct implementation is put forward it will be accepted”, while rejecting means “this feature is not a good way to go”. Now speaking with my stuck-in-translation-RFC-author hat, I feel having an RFC open with no clue whether it is wanted or not is the worse possible state for the RFC, hence my trying to change this via this new RFC, so that each RFC is in a clean and well-defined state, and people wanting to go through non-negligible changes can go through the RFC process to know whether this is a good idea or not, without fearing their idea to just be forgotten :)

It's now been almost two months since the last comment on this RFC (especially this one among all others), which is mine; and once again I've got a pending RFC that's waiting in limbo. I'm personally giving up on spending any energy in pushing forward RFCs beyond replying if asked something.

RFCs were a nice attempt, but seem to have failed.

Leaving this open as I'll fix things if asked to and still hope this gets merged in the current form or in any other one the community feels right for RFCs to move forward, but without much hope from now on.

@edolstra Is this a more appropriate venue for the process discussion we were having on #23 ?

@shlevy Yes, thanks!

@edolstra Any suggestions on how to address the stall in this thread?

Just picking up #23 (comment) about the IETF: the chairman at the IETF is equivalent to the “team of people […] designated as “responsible for pushing RFCs forward”” from the current draft, I think.

That said, I don't know how to address the stall in this thread, so I'll raise this question: do you think it'd be better to have a single chairman instead of a core team? This would mean more work and responsibility on the shoulders of a single person, but could make things move faster, as I seem to have noticed when a single person is in charge things generally move better than when a team is in charge, so long as the said person has enough time to handle it and/or a volunteer can be found.

There's an easy way to solve some of the above problems: change the RFC policy to default to merging after a certain period of time unless they are rejected by whoever has authority to do so. The reviewer(s) can't delay the decision by saying "We need to gather more information" or "This needs changes". If the information they need hasn't been gathered by the specified time or the changes haven't been made then they have to explicitly speak up and reject the proposal or it goes through.

The risk is minor (if a bad RFC is merged by accident you can just open a new RFC to undo it) and it incentivizes people with authority to accelerate the discussion if they have doubts rather than leaving proposals to rot on the vine.

The risk is minor (if a bad RFC is merged by accident you can just open a new RFC to undo it) and it incentivizes people with authority to accelerate the discussion if they have doubts rather than leaving proposals to rot on the vine.

Not everyone has interest, time and knowledge to discuss all RFC's. Expecting "people with authority" to actively participate in all RFC is not realistic. The team/board that is proposed in this RFC should decide based on all (community) input presented/gathered. If they think certain feedback is needed before a decision can be made, then they should of course ask for it. And that may mean asking "people with authority" for feedback. If these "people with authority" don't give feedback, then the team/board should accept or reject the RFC with as reason "not enough feedback" was received.

Not all RFC's are equally large in scope or impact. For example, declarative virtual machines (#12) is relatively minor in scope and separated as it is "just another module". Musl (#23) may require effort from much more people, whether they want it or not. And rapid release of Nix (#9) is an example of something that really should be discussed among the main authors of Nix instead of pushing it as an RFC. Yes, it's good to show a discussion on the topic is happening, but it's not realistic to expect that an RFC would lead to a result.

Expecting "people with authority" to actively participate in all RFC is not realistic

If none of the core reviewers have the time to review the proposal they can always still explicitly reject the proposal with a clear admission that they didn't have time to properly review it. If they don't even have the time to even reject the proposal then they should step down and no longer be core reviewers. Similarly, if they repeatedly reject proposals due to lack of time then they also should step down. There isn't a shortage of trustworthy people who are interested and qualified to review these proposals.

The key thing I'm driving at is that greater privilege should always entail greater responsibility. I want to avoid the scenario where core reviewers try to preserve their privilege as core reviewers without accepting the responsibility that the privilege entails.

@FRidh Well, if musl failures after version update are always acceptable, it won't be much of an effort until musl gets a user base larger than Darwin and gets promoted. Unlike Darwin, I at least have an option to debug musl failures. And if there is no decision, then the entire picture is «a set of patches that fix false assumptions in the code are added — it is said that there should be a discussion in RFC — the discussion doesn't really work».

@Gabriel439 I think calling people to step down is rarely constructive, not having time to consider some topics doesn't say anything about the value people do provide by their work. And I hope you don't really mean «stepping down»: if no one with authority to accept is interested in reviewing a specific topic, what we want is selecting more people to grant authority so that the topic can be at least properly rejected (and hopefully actually steered into a direction acceptable for the core team), not someone stepping down.

@edolstra given that you did answer at least some parts of some meta-discussion questions in #23 and has not stated any position here in #18, I find it is unsurprising that in an RFC that depends on both object-level and meta-level issues there were attempts to discuss both at once.

Yeah, I guess I was operating under the assumption that the set of core reviewers would have a fixed size, but if it can grow then just delegating authority to more people is fine

Ironic how this is not approved. This is needed now more than ever.

@Ekleog I'd propose closing this as it is superseded by #36

It is indeed, thank you for reminding me this was still open!