any interest in an RFC process? #962
Comments
|
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. |
We already have this, it's just chaotic too. 😄 |
|
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. |
|
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 |
|
@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. |
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. |
|
@bmeck from the article,
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:
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. 😄 |
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.
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.
Too true.
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
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?
To some extent, but active collaborators are not the vocal side of things in my personal experience.
I don't understand this sentence.
This sounds reasonable to continually iterate until we find some path towards less aggression in core. |
|
would be nice if someone could tag this |
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. |
|
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:
|
|
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 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. |
|
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. |
|
I talked with @boneskull about this yesterday. This doesn't capture everything we talked about, but some key points:
Things that are being discussed right now that would benefit from a process for making decisions around ideas before asking for an implementation:
|
|
@Trott that would be a good distinction from what was tried in the earlier eps process. The eps process covered both the idea and at least high level implementation. Limiting to just the first might help. |
|
Based on some conversation with @bengl, @bmeck, @boneskull and others on twitter I'd definitely like to make sure we keep iterating forward on this discussion. My key concern around most RFC processes is that most that I've seen over emphasize achieving consensus in the initial discussion points before making progress. After stewing on it for a while and just letting the ideas marinate in my head for a while, I keep coming back to the TC-39 stage process as a good model here. Here's a good introduction if you're not familiar: https://tc39.es/process-document/ The TC-39 stages are straightforward:
What's key about this process is not only the stages but the requirements necessary for moving through them.
Also important is the process by which review and feedback is processed... Specifically with regards to reviewers:
And then ...
Now, I'm not suggesting that we adopt the TC-39 process exactly as is, but a variant of it may be worthwhile if we can get the engagement from the core contributors to review and provide feedback on proposals. |
Oh well. It was a pretty compelling idea until then. No, just kidding. Sort of. I mean, yes, that's a challenge, but also a challenge any RFC proposal is going to face, and also arguably one of the problems the RFC process can seek to solve, or at least make more solvable. |
|
I find the comments on If I understand correctly it narrows the approvers for the later stages. This makes sense to me because as the discussion moves from "should we do this at all" to "is it fleshed out well enough to land" there would be a lot of context, prior discussion etc which only those involved in the earlier stages would have. I think this might address one of the challenges we've seen with more complex/larger changes where adding people later in the process requires the champion to re-negotiate what they felt had already been agreed by those involved. Not that we don't want people pointing out issues that may not have been thought of, but it could make sense to have those filtered by the designated reviewers versus the new participant having the ability to block/request changes directly. Thinking out loud, in the context of the Node.js project, maybe that could mean that once a proposal gets to a certain stage, the related PRs could only be blocked by the designated approvers? |
|
@mhdawson Good point that the RFC process should have more commenters at the outset and less as the proposal moves to implementation. We tend to do the opposite--RFCs and RFC-like processes are tucked away in non-core repos, for example--and then there is an explosion of attention when it shows up in the core repo as a PR or issue, and everything needs to be re-discussed. That sucks. |
Exactly, we want broadest input at the start, everybody has the ability/opportunity to contribute, but as things move forward it seems reasonable to narrow down who/how people can get involved. Doing that would hopefully also motivate people getting involved up front versus waiting until the code is about to land. I also think up front is likely were we can get the most value from a broader set of contributors. Refining the concept, high level approach etc. is likely going to be more impactful that more people |
|
One thing that will be really important for a new process that will help fix problems with our current process will be carving out space for dissent without blocking progress. While the TC39 process does a good job of creating this space by making clear stages and not allowing a stage-3 blocker to stop a proposal from getting stage-1, I have still experience frustration (both personal and group) with the way a lone dissenting opinion can halt progress. TL;DR we need to find a cordial and consistent way to not allow objections to stop progress or it won't matter how much structure we have |
|
I'll also add that the IETF has a great guide on rough consensus... although even with this being the decision making process over at IETF I have experienced an RFC take over 3 years and we continue to have feedback on our .mjs mimetype proposal from a variety of different groups. My gut feel at IETF is that if the current RFC authors were more embedded in IETF and we were associated with a particular working group this process may have been less painful, but I think it is important to keep in mind that any process we create will become a burden that outsiders need to navigate. So with that in mind I think it is important that any process we land on be as light weight as possible AND we commit to cultural changes around decision making or we are going to end up with even more process than we already have and little |
|
I want to try a bit more to clearly frame the constituents and the problem that we all want solved. Here are the three groups of constituents:
|
|
One important conclusion of the above is that while broader input on RFCs from the at-large Node.js community may be a nice-to-have, it is not necessary. As long as the process results in a better Node.js, that is sufficient. We should not have a goal (in this context) of having broader input. If it happens, great. But if not, that's OK too, as it would be very likely to work against the goals of reducing the cost of maintenance and improving the experience of contributors who are currently invested but contribute infrequently. To be clear, this doesn't mean that we should necessarily reduce the at-large community input we currently get formally (e.g., in the GitHub issue tracker) and informally (e.g., on Twitter). It means (1) that the current level of input is likely sufficient, (2) that increasing it is a laudable goal but not necessary at this time, and (3) that increasing it makes meeting the essential goals here harder. |
|
So given all the above, what would be a process that could reduce friction for invested-but-infrequent contributors without increasing the burden for maintainers? I'm thinking that it might be something that, for any particular significant feature idea, facilitates the easy the formation of a GitHub team that works out the issues around it, hopefully with a TSC member or and experienced-and-frequent contributor potentially as lead, or at least shepherd/facilitator. Any other ideas? I wonder if there's a possibility to unify the strategic initiatives and the working groups processes. Both processes sort of work, but also pretty much don't work as well. The working groups might benefit from less friction in the formation and ending. For something like what I'm talking about here, it's too much work to start a working group, especially if you're not already a frequent contributor. And strategic initiatives are too TSC-driven and don't really have explicit accommodations for anyone else. Maybe something in between the two and that could potentially replace one or even both processes if we see it working well. |
|
I have thought that we should figure out a way so that strategic initiatives don't need to be led by TSC members so that part resonates with me. |
Maybe people leading strategic initiatives can regularly attend TSC meetings as guests to give updates, get feedback, etc. Would probably make things more focused to have someone designated as The Person Who Is Going To Frame And Facilitate The Discussion On Topic X For The Next 10 Minutes. |
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. Refs: nodejs/TSC#962 (comment)
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. In the process, I made the text less wordy. I moved the Build Resources initiatve out of the active list, as discussed at the most recent TSC meeting. I alphabetized the table entries. (Chronological order isn't obvious to a reader if no dates are provided.) Refs: nodejs/TSC#962 (comment)
As a first step on this path, I've opened nodejs/node#39394 to move the strategic initiatives out of this repository and into the main repository where they will have more visibility. |
|
+1 on inviting those leading strategic initiatives to the TSC meetings to cover them. |
It could provide a good natural onramp to TSC membership that we currently lack. (We need a better offramp too, but we can ponder that separately if necessary.) |
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. In the process, I made the text less wordy. I moved the Build Resources initiatve out of the active list, as discussed at the most recent TSC meeting. I alphabetized the table entries. (Chronological order isn't obvious to a reader if no dates are provided.) Refs: nodejs/TSC#962 (comment) PR-URL: nodejs#39394 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Zijian Liu <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. In the process, I made the text less wordy. I moved the Build Resources initiatve out of the active list, as discussed at the most recent TSC meeting. I alphabetized the table entries. (Chronological order isn't obvious to a reader if no dates are provided.) Refs: nodejs/TSC#962 (comment) PR-URL: #39394 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Zijian Liu <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. In the process, I made the text less wordy. I moved the Build Resources initiatve out of the active list, as discussed at the most recent TSC meeting. I alphabetized the table entries. (Chronological order isn't obvious to a reader if no dates are provided.) Refs: nodejs/TSC#962 (comment) PR-URL: #39394 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Zijian Liu <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
This (along with a corresponding PR for the TSC repo) moves the strategic initiatives from the TSC repository to the main core repo. This will increase visibility for strategic initiatives. It will also facilitate the proposed reduced centrality of TSC champions to strategic plans. In the process, I made the text less wordy. I moved the Build Resources initiatve out of the active list, as discussed at the most recent TSC meeting. I alphabetized the table entries. (Chronological order isn't obvious to a reader if no dates are provided.) Refs: nodejs/TSC#962 (comment) PR-URL: #39394 Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Tobias Nießen <[email protected]> Reviewed-By: Zijian Liu <[email protected]> Reviewed-By: Michael Dawson <[email protected]>
|
The last comment was almost a year ago. The last actions where the list of strategic initiatives were moved to node core is complete and we now have a number led by non TSC members. @Trott any objection to me closing out this issue? |
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...
The text was updated successfully, but these errors were encountered: