Create nodejs/standards-positions repository

[jasnell]

This repository would serve much the same purpose as Mozilla's standards positions repository seen here: https://github.com/mozilla/standards-positions ... that is, it would effectively serve as the repository for the Node.js project's official thoughts for various specifications relevant to Node.js.

Background

Node.js implements support for multiple internet and web standards (TCP, HTTP, TLS, WHATWG URL, Streams, Encoding, fetch, etc). Historically, the Node.js project has never maintained any official position favorable or unfavorable towards any particular specification. Instead it has relied mostly on the individual opinions and perspectives of individual contributors. Some of these individual contributors have participated in various standards bodies such as TC-39 or WHATWG representing their own personal points of view. That participation, however, often becomes confusing when it is not clear if they are speaking on behalf of the project representing a consensus opinion among the contributors or merely their own individual opinions. This repository would seek to eliminate that confusion by providing an authoritative source for consensus agreements.

Process

Following the model of the Mozilla repository, we will apply one of three labels to new specifications: (I've borrowed the language here from Mozilla's documentation)

• positive - Node.js regards this work as a potential improvement to the Node.js ecosystem.
• neutral - Node.js is not convinced of the merits of this work, but does not see any significant negative potential.
• negative - Node.js believes that pursuing this work in its current form would not be good for the Node.js ecosystem.

These positions will be based on our best assessment of the current state of the specification and the potential for it to benefit our users and the ecosystem as a whole. We consider the intended purpose and the design fundamentals of each specification. Incomplete documentation, minor issues, or lack of interoperability testing are not reasons for a negative position, provided that intent is clear.

We might also use the following labels for specifications where we have not formed a position:

• defer - Node.js takes no position on this work.
• under consideration - Node.js has not taken a position on this work and is gathering more information.

An already published position that, for whatever reason, becomes no longer relevant can be marked obsolete.
 
A proposal to publish an opinion towards a particular specification would come in the form of a new issue in the nodejs/standards-position repository. The issue should identify the spec and the rationale for seeking a position. It should not argue a particular position label one way or the other but simply ask that the spec be considered. If there are no objections raised to the proposal after seven calendar days, then the proposal is considered accepted and work can start to publish a position.

Each position itself would be published as a separate markdown file in the repository, originating with a pull request whose process for acceptance follows the same process as landing semver-major changes in the core Node.js repository. That is, a position paper cannot land without approval from at least two TSC members and without all relevant feedback having been addressed. Collaborators will be encouraged to follow the respository and actively weigh in where they feel necessary.

Positions are living documents that can be revisited and altered as necessary when new information is received or project requirements evolve. We will use the git history to track any changes in position over time.

Template for position proposals

<!-- Please use only the specification title as the issue title. -->

## Request for Node.js Position on an Emerging Specification

* Specification title: 
* Specification or proposal URL (if available): 
* Explainer URL (if available):
* Proposal author(s) (`@`-mention GitHub accounts): 
* Node.js collaborators or ecosystem members who can provide input (optional): 

### Other information

Which specifications

Again, borrowing language from the Mozilla repository:

Specifications that are relevant to JavaScript and WebAssembly runtimes like Node.js are in-scope here; specifications that are specific to Web Browsers but not Node.js (e.g. specifications involving Web platform features that are unlikely to ever be implemented directly by Node.js) are not, and will be marked invalid.

To be considered, a specification needs to be published under well-understood IPR terms. This currently includes:

• Ecma TC39 proposals
• IETF RFCs and Internet-Drafts
• W3C drafts, Recommendations and Notes (including Community Group documents, e.g. WICG, WinterCG)
• WHATWG Living Standards (typically we consider change proposals)

If a specification has been abandoned, deprecated, or obsoleted by its publishing body, this generally indicates that it is not under consideration.

If a specification is already implemented by Node.js (or is in the development process), it typically won't be necessary to determine a position on it, since we're already devoting resources to it.

Why now?

This was discussed at length at the Collaborator Summit held during the NodeConf.eu event this past week in Kilkenny Ireland. The core of the discussion was around how the project can come to consensus on support for new specifications and standards that may impact Node.js development moving forward. Newer efforts such as WinterCG increase the need for a more formalized process of determining the consensus opinion of the project.

[jasnell]

@nodejs/tsc @nodejs/web-standards @nodejs/collaborators @littledan

[panva]

Question is if the organizations mentioned even care about our position. More often than not they dismiss anything but the browser positions.

[joyeecheung]

Question is if the organizations mentioned even care about our position. More often than not they dismiss anything but the browser positions.

This proposal was motivated specifically because we were asked by standards participants (TC39 and WinterCG, at least).

[joyeecheung]

I think something like this would be quite valuable for any standards seeking Node.js’s opinions and in turn helps making our needs and constraints heard. +1 to at least creating a repo and giving this a try.

Some thoughts about the process part: positive, neutral and negative sounds a bit too static/decisive to me. For Mozilla it might make more sense because they are speaking about their opinions about the Web , that’s one of their mission, and the opinions can be more generic. Node.js on the other hand usually reach consensus based on our own circumstances and I think we rarely (or never) have consensus about whether a proposal is good/bad for the ecosystem in general. The disagreement we have, if any, are usually more nuanced (if this is implementable or optimizable for our codebase, whether this can be an attack vector for us, etc) and we don’t come to consensus about what would happen if other runtimes implement these as they might just have entirely different architecture or threat model. Maybe we can start small and to formulate opinions like “asking for modification”, “no concerns so far”, “strong concerns” (and if possible, list of concerns) “integration/implementation planned” “integration/implementation in progress” etc.

[jasnell]

I think those alternative categories make sense @joyeecheung ... I don't have strong reasons for the initial proposal other than modeling after the existing Mozilla process... but I don't see any particular need to follow theirs precisely.

[ShogunPanda]

I agree with @joyeecheung, let's have some intermediate categories between "under consideration" and "positive"/"negative" etc.
But I do also think this might very valuable and remove some dust from our external relationships.

Question is if the organizations mentioned even care about our position. More often than not they dismiss anything but the browser positions.

I don't have an answer but... do we really care? I mean, if they do it's good and we all benefit from it. Otherwise, remember that our target are the users. Giving a clear decision to them is what matters the most, IMHO.

[bnb]

+1, I also initially had the same thought that positive/negative/neutral was a bit too... binary (trinary?) where from what I've experienced in the project, there's much more detail that will make choosing between those hard to do. I like @joyeecheung's proposed options.

[littledan]

The simple positive/negative (or support/oppose from WebKit) make a lot of sense for the context they are working within: a situation where other browsers need to determine a quick, simple understanding of the overall position. Historically, there have been misunderstandings about this high level view when more subtle indications were made, and the high-level view is often needed for determining whether there is multi-browser buy-in, or strong opposition from a browser (key for WHATWG standards and things which operate analogously). In particular: when a rare negative position comes up, it is important that everyone can see it very clearly.

For Node.js, I think we could go either way, on James vs Joyee’s ideas above. There aren’t currently any standards bodies which work WHATWG-style and are waiting for Node’s position, but I hope we will have some of those in the future. It is important that Node be able to give feedback which is more subtle than these three possibilities.

How about we let a position include two fields: one is the ternary judgement (personally I prefer support/neutral/oppose of WebKit), and the other field could be “notes”: the rationale, points of feedback to address, or implementation status—whatever is relevant to that case. This is sometimes present in practice with issue comments on the Mozilla/WebKit positions, but we can point more concretely to a summary in our table. Maybe, over time, some patterns in notes will occur, and these can become categories, but it might be easiest to start out free-form.

For Node, I think these positions can be useful for documenting where the project is open to contributions, since that is often the limiting factor in shipping web standards. “Contributions welcome!” could be a note attached to a “supports” position.

[GeoffreyBooth]

Not sure if there's already a place for this, but it would be good to categorize somewhere whether we feel that Node would likely want to implement a particular proposal. If we express interest in supporting an API, presumably that would encourage the API champions to prioritize Node's needs in developing the proposal.

[jasnell]

How about:

• Neutral (no position taken) -- This would be for specifications that we generally have no specific interest or intention of implementing support for and therefore have no need to take a position. Most of the time this like won't need to be explicit. If we don't have a position, or have no interest in implementing, then we just simply won't have a position document for it.
• Changes requested -- This would cover specifications that we potentially have an interest implementing but would like to see changes made before we ultimately decide. The position document should detail the changes that are being requested.
• Favorable -- This would cover specifications that we have an interest in implementing as is. This does not guarantee implementation, as someone would still need to decide to go do that work.
• Unfavorable -- This would cover specifications that we not only have no interest in implementing, but we also think are detrimental to the overall Node.js ecosystem if it is adopted by anyone.

I think this strikes a nicer balance between the Firefox categories and the more nuanced categories @joyeecheung is suggesting.

[legendecas]

If there are no objections raised to the proposal after seven calendar days, then the proposal is considered accepted and work can start to publish a position.

How do we publish positions that are not "favorable" regarding the process mentioned above? If all positions have to wait for seven calendar days to be published, I wonder if "changes requested" can be addressed actively by working with the proposal champions and doesn't have to be published as a position. If "changes requested" can not be ultimately worked out as "favorable", I didn't find the gist here to distinguish it from "unfavorable".

[jasnell]

How do we publish positions that are not "favorable" regarding the process mentioned above

That initial 7 days only covers the Issue that proposes that a specification be considered for a position, not the work necessary to actually determine, write, and land the position document into the repo. In other words, let's say I wanted the project to consider a position on the socket api spec that I'm working on, the process would be:

1. I open an issue in the repo asking the project to consider publishing a position on the socket api.
2. If after 7 days there are no objections raised in that issue, then I can consider there to be consensus that a position should be published. This gives more than enough time for any collaborator to object if they feel it would not be necessary or appropriate for node.js to offer any position at all.
3. At the completion of that 7 days, I can open a PR that proposes a specific position. Landing that PR follows the same rules as landing a semver-major change in the main Node.js repo. That is, it requires at least two TSC members signing off and must stay open for at least the requisite 48 hours, etc. Changes/edits are handled as we would any PR.

If "changes requested" can not be ultimately worked out as "favorable", I didn't find the gist here to distinguish it from "unfavorable".

For this kind of situation, the decision would generally fall to the TSC to resolve. That is, if we cannot form a consensus naturally through regular conversation for any particular reason, it would be up to the TSC to decide the position -- during which time it could choose to fall back to deciding that no position should be taken at all. Perhaps we need another category here to indicate "No Consensus" to describe the case where no consensus position could be established?

[mhdawson]

Overall I'm +1 to creating the repo and implementating a process were we can capture the discussion and position of the project. A few specific comments:

At the completion of that 7 days, I can open a PR that proposes a specific position. Landing that PR follows the same rules as landing a semver-major change in the main Node.js repo. That is, it requires at least two TSC members signing off and must stay open for at least the requisite 48 hours, etc. Changes/edits are handled as we would any PR.

I'm not sure that 48 hours is appropriate for a standards position. I think there should be less rush to land PRs for a position and we should favor making sure those who have opinions have time to add them versus landing quickly. I would suggest someting like 2 weeks as a minimum time from the initial PR being opened. Unlike code PRs, giving more time does not mean the PR becomes stale, needs to be rebased etc.

Instead of pre-defined neutral, favorable, unfavorable, and alternative might be a paragraph which summarizes the projects position which could include the general take like favorable/unfavorable as well as more explanation of the concerns/comments that were made during the discussion. More specifically the position would be a paragraph which explains the position versus a simple tag type position. My thought is that it wouldbe a better fit than trying to fit into the predefined categories, but I'm not too worried about this part as we can figure out what works over time.

[jasnell]

Sounds reasonable. So far it is looking like there are no objections to setting up the repository but obviously let's let the requisite 7 days pass. Assuming there are no objections by next monday I'll create the repository and will create a new @nodejs/standards-positions team. I know we have the web-standards team already but given the specific purpose of this repo it warrants having it's own team.

Once the repository is created, I will open an PR with a proposed process document crafted based on the discussion here.

I will also reach out to various folks, such as the WHATWG, to give them a heads up that we are creating this repo and that they should feel free to use it as a means of either notifying us of proposed new specs, changes to existing specs, or whatever else they would like to get the project to weigh in on.