any interest in an RFC process?

[boneskull]

Hi,

As seen in this blog post, at least some of the Rust team has felt their RFC process has had a positive impact. Contributing to Node.js can suffer from "endless discussions," and could benefit from such a process, which would mitigate some of the frustrations people have around contribution.

While it will certainly be no silver bullet, an RFC process may be a step in the right direction. Yes, it will be "more process", but part of the idea here is having an explicit order of work and guardrails around discussion.

I'm looking for one or more collaborators (especially TSC members) who think this is worth exploring, and hopefully someone (other than myself) to champion such a project.

I believe this idea has been thrown around in the past, and did not receive much traction. Just checking the temperature of the room...

[mcollina]

I generically think that we should aim for less process rather than more process. More importantly, an RFC process requires folks writing down huge quantities of text that take a lot of time to digest. It didn't work in the past, mainly because the party that is interested in adding a feature is often not interested for the long and gruesome process that is an RFC.

I won't oppose adding one, however I would not make it mandatory as I fear it would bring development to a halt.

[boneskull]

long and gruesome process

We already have this, it's just chaotic too. 😄

[boneskull]

I wonder what the @nodejs/modules team thinks of this idea.

I would also like it if someone from a project having an RFC process (like a Rust team member) could speak to velocity. From an outsider's perspective, it seems like Rust is humming along nicely.

[hybrist]

For reference, this is the old node RFC process: https://github.com/nodejs/node-eps. It does have a modules entry and I don't think it worked very well on that front (not putting blame on the author or on anybody else). The rewrite of the CLI debugger started as an EPS (nodejs/node-eps#42) before I abandoned the EPS system.

It would be interesting to figure out why an RFC process didn't work for nodejs but without that kind of post mortem, I'd be hesitant to try again. From my experience with node-inspect, it's not just that people may not want to write an RFC but "nobody" seemingly read them. Part of the problem may be that nodejs has quite a few collaborators but only very few if any maintainers. From what I've seen, that may be a bit different for Rust.

[MylesBorins]

@boneskull TBH, I think what we have is a cultural problem that is related to the age of the platform, the cost of making broad changes, and a historical leaning towards "small core". I'm not 100% convinced that process is the solution to said problem... although I do admit that I am not offering alternatives here.

If we wanted to introduce structure that could be followed by folks, that is not required, I think that could be helpful. There are issues that have been opened to discuss potential improvements that might have been more successful if there was more structure e.g. nodejs/node#19393

It is also possible that we could explore discussions as a vehicle for broader discussions / debate about ideas we are working on. In general though an RFC does need to be implemented, and it isn't like we have a line up of folks ready to do implementation work for an RFC they are not passionate about.

[bmeck]

I wonder what the @nodejs/modules team thinks of this idea.

Well as @jkrems said, I don't think it worked well at all. There was a lot of investigation and a lot of blame passing, ultimatums, and even some very bad personal life experiences. I do think for all the problems of the WG situation, they allow for less aggressive mode of interaction due to social involvement that we did not see in @nodejs/node-eps .

I think design documentation works quite well but even if we produce them (which we did a lot during the ESM implementation) that won't lead towards consensus resolution often. When they do resolve that leads toward PRs. Once you get out of a WG you get into more conflict with aggression from the core since only a subset of design constraints are given within a single WG.

One thing I do think Rust benefits from is an open approach to expansion that is not present in Node. A lot of the tensions with RFC I believe would be on the resistance of not wanting Node to become something that doesn't fit some kind of ideal such as a small core <-> implementing web APIs.

If an RFC process could be created that actually prevented tension I would be for it. However, PRs have been lower tension than such repeated process in my experience in the JS community. Heck, I experienced that just documenting what situations ASI can have non-local effects (not taking a stance on if they should be used) faced huge pushback for TC39.

I believe a big issue is how Node runs consensus based upon unanimous lazy consensus. The more design participants the less likely something is to get consensus. We did see things like this where proposals within the Modules WG were stated as contentious and thus completely removed rather than being able to resolve them over time. I do fear that re-adopting the RFC-like approach of node-eps would repeat this stalemate which is already brutal once you get to the PR phase. See nodejs/node#21128 where producing such documents had little to no effect in the face of general pushback against even the concept of modification to core based upon not having personal need for the proposal and/or claims that changes should be done in userland not in core.

[boneskull]

@bmeck from the article,

The RFCs have another effect on the organization. The process seeks a consent-based environment, not a consensus-based one. If some people care about a topic a lot and come up with a written document that explains many things in detail, everyone can (and should) trust them. The authors shouldn't wait for everyone's confirmation of their proposal.

I really like this. As @MylesBorins wrote, Rust is much more "wide-open". I'd have to be convinced that there's something preventing Node.js from being more "wide-open" other than project culture and its leadership. We have constraints, sure--all software does. Rust remains open while also having adopted a strict process; Node.js is light on process, but contributing an impactful change can be soul-crushing due to what @bmeck wrote:

I believe a big issue is how Node runs consensus based upon unanimous lazy consensus. The more design participants the less likely something is to get consensus.

Yes! Part of the "just make a PR" culture exacerbates this. Separating the proposal from the implementation may also avoid huge, confused conversations--e.g., is there a problem with this implementation or is there a problem with the idea? Great ideas die because the someone didn't like a parameter name.

In the RFC process as described in the post, discussions are time-boxed. You know if you wanna boil the ocean with a proposal, instead of spending months at each others' throats about it, you know you will only need to run the gauntlet for a couple weeks. If it needs to get done, give someone else a shot at writing the proposal until you find one that works.

---

There's a lot of fear in Node.js' culture. Fear of process, fear of changing a process, fear of maintenance burden, fear of breaking APIs, fear of introducing incompatibilities with web--and due to lazy consensus, we also fear our collaborators. We want to merge code fast or else someone will snipe it.

We need more trust and empathy for our fellow collaborators. We say we want people to succeed, but our actions betray that. I mean... if I didn't find the contribution process a distinctly negative experience, or if I didn't care a lot about the project, I wouldn't be writing any of this. Empathy allows us to read my experience--even though it may be wildly different than our own--and be moved to change the status quo. And trust means we can make a change and know we can iterate on it until we get it right. The process itself doesn't break the web. 😄

[bmeck]

We want to merge code fast or else someone will snipe it.

I don't think speed is a priority here, nor "sniping" more that constraints will be asserted that cannot be fixed and/or no guidance on what is considered relevant, the same likely seems it would be true for the RFC parts you mention above.

Need, followed by Approach, Benefits, and lastly, Competitors

I think as shown in a couple of things linked above reaching unanimous consensus is hard. We generally argue about all of the NABC in PRs and generally cannot move forward because of unresolvable disagreement from one of those. I still think if we could form an RFC process that differed in such a way that it would allow resolution it would be good, but I am unclear on what exactly is being proposed that would actually solve the issues seen in things mentioned here.

Great ideas die because the someone didn't like a parameter name.

Too true.

you know you will only need to run the gauntlet for a couple weeks

I'm unclear on how timeboxed RFCs would actually allow resolution for things that take more than a few weeks to agree upon. This seems like it would effectively prevent any large scale effort like fetch() from being approached. Without fetch() we don't need the components to make fetch work in that time frame.

If it needs to get done, give someone else a shot at writing the proposal until you find one that works.

I'm not sure I understand how this helps. It seems you would continually propose new RFCs and lose context if people from previous discussions don't participate?

we also fear our collaborators

To some extent, but active collaborators are not the vocal side of things in my personal experience.

Empathy allows us to read my experience--even though it may be wildly different than our own--and be moved to change the status quo

I don't understand this sentence.

we can make a change and know we can iterate on it until we get it right

This sounds reasonable to continually iterate until we find some path towards less aggression in core.

[boneskull]

would be nice if someone could tag this tsc-agenda. if there is no interest from a TSC member to champion this, I'll reach out to the collaborators.

[GeoffreyBooth]

I believe a big issue is how Node runs consensus based upon unanimous lazy consensus.

This. My experience with the modules group is that the need for unanimous consent was taken advantage of by team members who were not invested in the team’s success. In an ideal world, where everyone on the team acts in good faith and shares the goal of shipping the best product possible, lone objections would force the team to think harder and find better solutions. Unfortunately that didn’t happen in our case, because our team lacked fundamental cohesion that we were actually working together to achieve the same goal; we didn’t have a consensus that we had to ship, much less that we had to ship in any reasonable timeframe. Ultimately we failed to reach consensus on several crucial points and needed to use votes and TSC overrides.

Like with legislation, arguably it should be hard to implement change; Node is very mature at this point and significant changes should require substantial support. That’s one way in which Node and Rust differ, which might steer us away from fully following their lead. I think we need something in between the current “any collaborator can veto anything, only subject to TSC override” and the opposite end of the spectrum, where consent is assumed unless certain conditions are met. I think this is really a separate concern from an RFC process; adopting RFCs won’t necessarily solve this issue (and might make it worse) if we don’t find a governance model to replace unanimous consent.

[Trott]

I am very interested in the issue of making the implementation of significant things in Node.js core something that doesn't take a personal toll on people. Whether the solution involves an RFC process or not, this is something that is overdue for discussion and action.

@boneskull I'll send you an email to see what you think about you and I chatting about this some time soon. I want to make sure my understanding of the issue aligns with yours.

Some thoughts:

• The EPs process was sensible to try, but an abject failure in implementation. I don't think anyone wants to repeat the mistakes of the EPs process, but that doesn't necessarily mean we should throw out the entire idea of a process for Big Stuff altogether.

• The observation from @jkrems that Node.js has many collaborators but few maintainers is, to me, the key observation here.

• Getting to "no" faster would be good. It's not that the RFC process should lead to success all the time or even necessarily most of the time. It's that it should never lead to a years-long process which never arrives at a clear resolution one way or the other.

• Opening a PR with a minimal implementation could be part of the process. Putting this in there for the "but I can't say anything for certain until I see how it will work in practice" folks. (I'm often one of those folks.)

[jasnell]

Generally speaking I'm not a fan of RFC processes in other projects, but I fully recognize that my working style is quite a bit different from others. For me, when it comes to implementing big things (url, http2, quic, web crypto, etc) I'm much happier going off and working on my own (but still in the open) and getting an initial implementation working than trying to hash out all of the details in advance in committee. The details can be figured out after that. My key challenge with RFC processes is that it's often a whole lot of discussion, shed painting, and navel gazing that often goes nowhere while Simply Writing Code(tm) tends to work wonders. Again, however, I'm fully ready to recognize that my approach is different and I may be in the minority.

[Trott]

Generally speaking I'm not a fan of RFC processes in other projects, but I fully recognize that my working style is quite a bit different from others. For me, when it comes to implementing big things (url, http2, quic, web crypto, etc) I'm much happier going off and working on my own (but still in the open) and getting an initial implementation working than trying to hash out all of the details in advance in committee. The details can be figured out after that. My key challenge with RFC processes is that it's often a whole lot of discussion, shed painting, and navel gazing that often goes nowhere while Simply Writing Code(tm) tends to work wonders. Again, however, I'm fully ready to recognize that my approach is different and I may be in the minority.

In addition, you are also in a unique position in the project. You have spent years neck-deep in the code and culture. You are the closest thing the project has to the proverbial 800-pound gorilla. Had someone else come along and tried to get quic added the way you did, it would have either been rejected or would still be in limbo now. And that makes some sense. You understand both the code and the project culture more than anyone. But that means that a big factor in quic landing was that it was authored by James Snell. Other decision makers were comfortable with it because of who the author was.

It will always be the case that people who have spent years being neck-deep in project code and project governance have an easier time adding/changing things they want. There's trust that gets established. It's why they have the commit bit and others don't. I'm not saying we can change that narrow fact, and I'm not sure we'd want to if we could. But as you imply, "works for James" is perhaps necessary, but definitely not sufficient.

[jasnell]

Oh, I'm definitely not saying that the process should be tuned for me, not by any means! I struggled on whether to even respond to this discussion for exactly the reasons you mention @Trott. My experience with stuff is definitely way different than others. That said, there is absolutely a very real risk with an RFC process for it to turn into Endless Discussion That Just Frustrates Everyone -- if only because it's happened many times before. If an RFC process is introduced, there needs to be a bias given towards running code that works and away from endless bikeshedding and picking apart edge cases.