[RFC 0018] Moving forward RFCs #18
Conversation
|
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:
|
|
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 think you don't understand the problem: for many decisions there is not consensus _among committers_ who should give a go-ahead, and most chains of «not me because X knows better» get stuck when the most trusted people on the topic never respond.
(Of course, this reflects the fact that for many complicated issues the initial opinions of the committers do not naturally form a consensus, even if you take only people who have been contributing for years)
|
|
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. |
|
... 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 did see an exchange (in commit comments) which was basically «Why was this pushed in this form? — Because we tagged you and everyone who did react were in favour?», then there was a new round of discussion. And for highly cross-cutting issues people sometimes expect that outcome, no matter what policy says.
|
|
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. |
|
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.
1. I was answering to «we could simply declare the set of Nixpkgs committers the core team». I do not even say that it is a bad direction to go, but I want to say that a lot of work is needed to achieve anything useful in this direction; this work would be useful beyond the RFC process. But trying to quickly get consensus behind the declaration as stated will not be sufficient.
2. I am not sure that spending extra effort on finalizing RFCs will bring any utility via the fact that RFCs get finalized (again, you could improve the internal processes while working on making RFCs work, but actually using the improved processes for RFCs will be a waste). If you immediately get complete support from everyone, decision-making procedure is irrelevant. If there are split opinions, RFC can be merged but it is not binding in any real sense, so the opinions expressed are more valuable than the single bit «merge or not». I see the value of design discussions before full-scale implementation. But if there are «values» tradeoffs being discussed (suitability for different use-cases etc.), well, there will be the same discussion on the actual PR. Making a symbolic decision on an RFC won't help.
|
|
Been enjoying reading the discussion 😃
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. |
|
@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. |
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. |
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. |
|
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. |
|
It is indeed, thank you for reminding me this was still open! |
* 166: Nix formatting Create 0101-nix-formatting.md WIP Go through a large part and agree on it Co-Authored-By: @piegamesde Update 0101-nix-formatting.md Rework a lot of things Update 0101-nix-formatting.md Move around some sections Reword the detailed section Minor updates Slight header changes again Updates Update 0101-nix-formatting.md Update after today's meeting Update 0101-nix-formatting.md Further updates in the meeting Update 0101-nix-formatting.md After todays meeting Update after meeting Rename to probably the right number Only use anchor links Improvements and additions - The sub-expression rule is now reworded and its own section with examples and rationale - Line length limit is now specified as we agreed-upon in the meeting - The operator section is rewritten to align more with the consensus Redo and explain operator special case Also remove the special case for non-chainable operators, barely any benefit in Nixpkgs * Operator chains outside bindings can also have a compact form * Make the operator compact form specific to binders * Fix accidentally formatted semicolons in alternatives * Minor changes * Light copy editing * Fix .git-blame-ignore-revs * Improve assert/with wording * Be more flexible with single-line element count * binder -> binding * unindent inherit semicolon, reshuffle binding/inherit sections (#14) * unindent inherit semicolon, reshuffle binding/inherit sections * fixup! Stuff * Give alternatives to `in` formatting * Expand on line break preservation * Add editorconfig * Expand argumentation against leading commas * Add @dasJ to the formatter team * Add shepherd team Co-authored-by: Linus Heckemann <git@sphalerite.org> * Various improvements (#15) * Various improvements - Remove unnecessary **Description** headers - Rename **Rationale and Alternatives** to just **Alternatives** - Insert must/may/should more diligently - Add some TODOs where things are unclear - Remove numberings from examples when not needed - Minor clarity improvements and simplifications throughout * Apply suggestions from code review Co-authored-by: Ryan Hendrickson <ryan.hendrickson@alum.mit.edu> --------- Co-authored-by: Ryan Hendrickson <ryan.hendrickson@alum.mit.edu> * Address TODOs and rework with/assert * Minor adjustments * Mention formatting Nix code in documentation * Working towards finalization (#16) - Defined absorption and absorbable terms - Adapted the existing RFC text to make use of these definitions, resulting in simplications of the text in many cases. - Updated `with` section to match the implementation - Updated the function declaration section to match the implementation - Sometimes, the function body may get absorbed - This used to be a special case scoped to bindings only, so it got removed there - Updated the operators section to match the implementation - Specify the format of non-chainable operators (somehow those got lost in the past) - Reworked bindings section. It should now be clear and specific enough. - Minor wording fixes * String section * Specify assert conditions * More absorption for multi-line arguments * How to update the standard format * Fix minor typos * Less lines for common function call patterns * Specify comments * Specify that the formatter should be as pure as possible With some exceptions * nit: fix list concatenation example (#17) * Update rfcs/0166-nix-formatting.md Co-authored-by: Doron Behar <doron.behar@gmail.com> * Add good indentation examples (#18) * Add another chainable operators example * justify difference in semicolon placement * Allow different parenthesized argument style * Clarify non-vertical alignment rule * Improved clarity of bindings rule * Improve bindings semicolon alternatives section --------- Co-authored-by: Silvan Mosberger <github@infinisil.com> Co-authored-by: Silvan Mosberger <silvan.mosberger@tweag.io> Co-authored-by: Ryan Hendrickson <ryan.hendrickson@alum.mit.edu> Co-authored-by: Yuriy Taraday <yorik.sar@gmail.com> Co-authored-by: Linus Heckemann <git@sphalerite.org> Co-authored-by: Janne Heß <janne@hess.ooo> Co-authored-by: Doron Behar <doron.behar@gmail.com>
Rendered