doc: introduce RFC process #37953
doc: introduce RFC process #37953
Conversation
|
This will probably give people more chances and places to block. It will also encourage discussion on pros/cons of features before we experiment and gather feedback on them effectively "waterfall"ing our process. I think the things that make changes hard at the moment are:
I think an RFC is kind of the opposite of what I'd want - I think it should instead be significantly easier to add experimental features as long as we're absolutely fine with removing them. It should also be easier to ask people for reviews and help when working on features - currently the process is "reach out to people I know on social media and beg for reviews" which isn't a great process. |
|
|
||
| The request for comments (RFC) process is intended to provide a consistent and | ||
| controlled path for new features to enter Node.js. The process helps find | ||
| consensus among Node.js community and collaborators on substantial changes to |
There was a problem hiding this comment.
I think consensus among the Node.js community which is very diverse in ideas and opinions is not really attainable for most features. I cannot name a single Node.js feature with consensus among the community :)
Consensus among collaborators (who we also try to make sure is a diverse group of many opinions) is already a very high bar.
There was a problem hiding this comment.
I guess it depends on your definition of consensus. Which means that maybe I ought to define the term in the doc so it's clear how I mean it.
|
|
||
| Examples that may have benefited from an RFC process: | ||
|
|
||
| * [Implement window.fetch into core][] |
There was a problem hiding this comment.
I... think window.fetch has been blocked on the same thing all along - someone actually doing all the work to get window.fetch into core.
When we had the half-formal process (of talking about it in 2 collaborator summits) we were always in agreement (mostly). I am happy to dig up the notes from those meetings if that's helpful.
The thing blocking fetch in core has always been the fact that providing a reasonable implementation is a lot more work than it seems and we didn't actually want to ship a broken one that doesn't actually behave like browser fetch in many cases (like Deno's). If someone feels strongly about shipping a broken fetch and fixing things as we go along later - that is also something collaborators were OK with.
That said - we've landed thousands of lines of code in core already to enable fetch in core including things (like AbortController) that don't actually work in Deno or other runtimes (yet, I'm sure they'll fix it! At least I'm rooting for it). Users have always had a reasonable workaround (use a polyfill).
There was a problem hiding this comment.
Other ideas that could benefit from an RFC process though:
- Switching our API defaults (somehow, eventually) to promises.
- Modules, the module team governance and process ended up being very frustrating to many and several collaborators quit the project.
- The whole
unhandledRejectionthing and discussion that eventually only happened (after endless discussion) through Mary's hard work and diplomacy. - Promise APIs (everywhere)
- Stuff like HTTP3/QUIC
That said, I believe in most of them it's important the RFC process happens swiftly and after we have an initial implementation landed.
|
|
||
| ## Drawbacks | ||
|
|
||
| * This approach means a formal process for substantial features where we do not |
There was a problem hiding this comment.
What if we only go through this process if there is no consensus on a feature? I'd hate to have to fill out an RFC form whenever I want to make a consistency API change (like adding AbortSignal support to another API)
There was a problem hiding this comment.
What if we only go through this process if there is no consensus on a feature?
I'll move "When to use the RFC process?" to the "Unresolved questions" section.
I'd hate to have to fill out an RFC form whenever I want to make a consistency API change (like adding
AbortSignalsupport to another API)
One RFC does not have to correspond to just one PR. You could do a single RFC for AbortSignal support generally and then add it to multiple APIs over time.
There was a problem hiding this comment.
Is that different from what we've done in collaborator summits for project-wide initiatives in the past?
There was a problem hiding this comment.
Perhaps not, but it removes the necessity of attendance at a summit to propose something. (Perhaps that's not a good thing?)
|
Thanks for all the thoughtful comments, @benjamingr. I opened this as a draft because it is definitely not in any sort of final useable form yet, but it is also complete enough for people to react to and improve. So those are exactly the kinds of comments I was hoping to get. |
|
Thanks for opening this Rich :) While I don't think an RFC process as outlined here is a good way to solve the fact it's hard to add things but it doesn't mean an RFC process can't work at any configuration. I appreciate the willingness to engage with these important and unpleasant issues for the good of the project <3 |
|
I'm generally a strong -1 on any new formalized rfc process. It's not needed and won't solve the issues we have with existing process. |
@jasnell In your opinion, what are the issues we have with the existing process? |
|
Best illustrated through example... For simple changes, we have no issues. For complex changes (say, QUIC) where only one person is driving it forward, it's also simple. For complex issues where there's more than one opposing view, having a more formal way of arguing is not going to help. It does back to what @mcollina said in the nodejs/tsc issue -- that it incentivizes just writing a long detailed argument that no one has time or context to evaluate. An RFC process needs to emphasize how we reasonably advance (or not) in light of those kinds of intractable issues where there's no clear right or wrong goalpost and I'm not seeing that here. When I say that I'm opposed to an RFC process I specifically mean any RFC process that does not also address this specific problem. |
|
@jasnell You made a comment here and another one in the original TSC issue and I think they are both great food for thought. But they are also leading me in opposite directions and I want to know what you think is the right way to go. The snapshot interaction is a pretty good example of something to aim to solve. But the whole TC39-inspired process doesn't seem to suit it well. Snapshots weren't a thing where a lot of people were working on it and had ideas. It was basically two people who had different ideas. By the time it was apparent that there was a problem to solve, we already had two competing implementations. Do we start the RFC process at that point? I suppose we could and leave those implementations to sit until we work some stuff out. Might be challenging to identify a champion in this situation when there are two people with different ideas, and not many other people with a lot of knowledge that are engaging. I guess the RFC process could/should be tailored to try to get that engagement/participation, but I'm not sure how in a situation like this. I'm kind of thinking out loud more than asking a question, but the purpose is to prompt a response from you or others, so give me your thoughts! |
|
Short answer: I don't know. I just know I don't want to just add process that trades one set of problems for another |
That is always going to be hard. The more effort that has been invested, the harder it will be to compromise/find a way forward. While it does not solve the problem the only thing I can think of is catching potential differences in approach earlier so that there is less invested. That's were I think an RFC process can help. If we all develop our own silo then submit a large PR we are more likely run into conflict after we have invested significant effort. If we have an RFC process that allows other people to know what is being worked on, what's already been discussed and agreed it will hopefully encourage joining an existing effort versus starting a parallel one. |
|
I think I'm going to close this and the TSC issue and regroup a bit. |
Refs: nodejs/TSC#962