WHATWG Participation Policy

[benjamingr]

Hey, raised in whatwg/url#377 (comment) :

I'd love clarifications about what's the current relationship between Node.js and standards bodies - as well as understand what's the correct way to pursue changes we'd like in WHATWG specs :)

So... what's our WHATWG policy?

[joyeecheung]

whatwg/url#377 (comment)

In terms of standards development WHATWG talks about participants: https://whatwg.org/workstream-policy. Node does not appear to be listed in https://github.com/whatwg/participant-data/blob/master/entities.json so they have not signed up at https://participate.whatwg.org/agreement (yet).

I think we can do this if we want to keep working on bringing WHATWG standards into Node.js core / maintaining the implemented standards. We are probably going to need some help from the board regarding signing/legal issues. cc @nodejs/tsc

[mhdawson]

This was discussed in the last TSC meeting @MylesBorins can you comment here to provide an update?

Removing TSC agenda tab since it was covered.

[mhdawson]

@MylesBorins ping

[MylesBorins]

TLDR; there is no policy. I opened #535 to start a strategic initiative around general standards engagement.

At the end of the day whatwg is a "no meetings" org that we can choose to participate in as individuals (@TimothyGu for example does a bunch of stuff).

If the project itself has an agenda we can definitely co-ordinate around engagement.

[benjamingr]

@MylesBorins

Quoting Anne:

Node does not appear to be listed in https://github.com/whatwg/participant-data/blob/master/entities.json so they have not signed up at https://participate.whatwg.org/agreement (yet).

One thing Node.js can do is sign up as a participant and sign the participant agreement.

[MylesBorins]

@benjamingr as the majority of us are not employees of the foundation I do not believe that signing the agreement would mean much, the majority of us who do not work for listing companies in that json file would likely have to sign as individuals either way.

That being said the foundation signing it would likely be a good gesture /cc @mrhinkle
I can bring this to the board next month

[Fishrock123]

I don't think we'd want to implement all of the standards - some of them are much less relevant to us than web browsers. (Or at least, I am not for implementing all of it for the sake of it.)

Having representation in these bodies would be useful, though.

[benjamingr]

Having representation in these bodies would be useful, though.

Yeah, that's mostly the idea - if we're an implementor of any DOM APIs (like URL) we should probably make an effort to contribute to the design process and represent our interests.

[mcollina]

I think we should partecipate. We might not implement those API straight away, but we could also implement them later on. We could also help part of the process by adding them early on in experimental, depending to what it is.

[mhdawson]

@MylesBorins, @benjamingr is there a next step on this issue or can it be closed?

[benjamingr]

Would still love some clarification about how Node.js is involved with WHATWG and how do we express concerns with APIs we might adopt.

[joyeecheung]

I don't think we have to get that much involved with WHATWG if all we want to do is to implement the existing standards. But we need to get involved if we want to make sure when they are proposing new standards they will have our use cases in mind.

[benjamingr]

But we need to get involved if we want to make sure when they are proposing new standards they will have our use cases in mind.

This is exactly the point I'm trying to raise here - thank you.

[joyeecheung]

Setting legal stuff aside, a good starting point would be to WebIDL-ify our APIs and automate the WPT synchronization process in core. Browsers automatically upstream their test modifications to WPT, and it would be great if we do the same for our implementation. I have a rough WIP git node wpt for automating the downstreaming process, but may need to modify some parts of WPT first. I've been told that most browser devs do not have a clear idea what does not work in Node.js so it falls on us to make sure the tests and the standards work for us.

[devsnek]

@Joyee you might be interested in the discussion here: web-platform-tests/wpt#11277

i would be quite interested in the opportunity to push new spec through whatwg

[mhdawson]

I think what we need is somebody to propose what we should be doing/lead our efforts on this front. @benjamingr is that something you are interested in?

[benjamingr]

I don't have a lot of WHATWG experience. I was supposed to meet with Domenic in Berlin to discuss but we ended up missing each other.

I'd prefer it if someone who participates in whatwg and Node.js to a higher degree (like @TimothyGu ) could weigh in.

[TimothyGu]

(Sorry, this thread got buried in my notifications.)

I am happy to act as a liaison between WHATWG and Node.js, especially since I will be working directly with several people active in the WHATWG over the summer. I believe what @MylesBorins mentioned in #532 (comment) is spot-on – signing the Participant Agreement probably doesn't have much practical effect as most Node.js Collaborators are not Foundation employees, but would be a nice gesture. It is definitely up to the individuals who participate in both communities that allow conversations to happen.

Myles, have you gotten a chance to raise signing the agreement to Board? I am willing to be a Contact for Node.js for purposes of the agreement.

@joyeecheung Is there a work-in-progress of your git node wpt command? I'm very interested in possibly collaborating on it.

[joyeecheung]

@TimothyGu The WIP lives in https://github.com/joyeecheung/node-core-utils/tree/wpt , it currently just grabs the files in a whitelist from the latest commit, extracts the JS code out of HTML, writes the JS and the JSON files to a hard coded path (.ncu/cache) for testing but you can easily make the path a CLI/config argument.

For now I plan to store them as fixtures to avoid the eslint-disable and license header hassle, but we need to figure our how to run them with a sandbox (I am thinking about a vm), that may require some changes in the upstream (e.g. move the bits that needs a XMLHttpRequest into a harness, or mock the calls somehow). Storing them as fixtures probably also makes automatic upstreaming easier - we just need to reverse the process.

[joyeecheung]

I just noticed that WPT started to move the non-browser bits into .any.js now:
web-platform-tests/wpt#11495
web-platform-tests/wpt#11492

[TimothyGu]

@joyeecheung I've actually used the VM module for WPT testing in another project

https://github.com/jsdom/whatwg-url/blob/4a073d8641307c377ef736d320616018c17c25e4/test/web-platform.js#L16-L62

and it works pretty well other than the occasional addition in shimming, so I'm definite excited to see that. I'll be sure to take a look at ncu over the next few days.

[MylesBorins]

In thinking about this I don't think that the foundation should be signing anything with WHATWg,

it is a nice gesture, but it wouldn't cover anyone from the technical project. I'm concerned that this may be confusing for individuals and result in people thinking they are legally covered when they are not.

thoughts?

[benjamingr]

I think this is a big decision for the project roadmap:

• if we decide web platform API adoption where it makes sense (URL, module compatibility with browsers, etc) is important - Node.js should have a seat at the table similarly to Chrome/Firefox/Safari/Edge etc and we should track and participate in web APIs the same way we do with TC39.
• If we decide web platform API adoption isn't a goal and if it happens it happens - we should say so about APIs and then Node.js having official capacity at WHATWG should be a non-goal.

[MylesBorins]

@benjamingr to be explicit. I think web platform adoption is an important thing for the project, I also think that is independent of the board signing anything or coming up with an official policy.

I think I perhaps conflated "participation as a whole" with "board / foundation signing something".

Would it make sense to focus this issue on how we can engage?

[benjamingr]

Would it make sense to focus this issue on how we can engage?

Well, I'd like to seek consensus on what our participation policy with WHATWG is really as a project.

[joyeecheung]

@benjamingr Do you mean you want to see a policy being written down or things being signed?

I am not sure if it’s a good time to start writing things down, but maybe it is now that we have implementation of a few standards and part of WPT in our code base, and they (mostly from bocoup?) have started doing work in the upstream as well. But it is also in the same situation as TC39 since we do collaborate but nothing has been written down on paper. I am not sure having a policy on our end alone would help or not.

[benjamingr]

Do you mean you want to see a policy being written down or things being signed?

Well, I want to have a policy and then write it down - but having one is the most important. Currently I don't know if WHATWG API adoption and usage is a project goal.

[benjamingr]

That is, it's great that Myles thinks that web platform adoption is an important thing for the project and I want this to either be a project policy or for us to decide against it. If we decide it's important - I think we should explore taking an active role in shaping these APIs (as the Node.js project or foundation rather than individuals involved in both bodies).

[joyeecheung]

Currently I don't know if WHATWG API adoption and usage is a project goal.

@benjamingr Maybe an appropriate next-step would be at-mentioning collaborators here or opening a new issue in the core repo (this looks like something that worth spamming people's inboxes for), as this is not something that TSC should make a decision alone.

[MylesBorins]

So perhaps there is a bigger question... Specifically if aligning with the web platform is a goal of the project , and considered part of small-core. This is imho part of a larger question regarding core values of the project. We do need to reach consensus on this, and likely document it... But I'm unsure that specific policy is a solution here. We engage in tc39 with people representing the project without explicit policy... And I don't think there would be need for policy unless the project were to join ecma and have attendance rules. There is nothing in our bylaws or the rules of whatwg stopping anyone from participating in whatwg, and we currently have people who do. It seems like what we really need clarity from the technical project that adopting these standards is something we want to do. Which is a bit different from a policy regarding whatwg. We have talked about values in the past, perhaps it is time for us to dig in a bit more

…

On Sat, Jun 23, 2018, 1:19 AM Joyee Cheung ***@***.***> wrote: Currently I don't know if WHATWG API adoption and usage is a project goal. @benjamingr <https://github.com/benjamingr> Maybe an appropriate next-step would be at-mentioning collaborators here or opening a new issue in the core repo (this looks like something that worth spamming people's inboxes for), as this is not something that TSC should make a decision alone. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#532 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV1YQLYf2Ukz4HJ79Ru8iQ42SxfbHks5t_c_vgaJpZM4TjFoA> .

[benjamingr]

@MylesBorins exactly!

[benjamingr]

@MylesBorins given #532 #583 - does it make sense to close . this issue?

[TimothyGu]

@benjamingr did you mean to link to some other issue?

[benjamingr]

@TimothyGu thanks! Sorry. I meant to link to #583

[TimothyGu]

I would keep this open until we either reach a conclusion or decide to delegate investigation of this issue to a web standards team when it's created.

[MylesBorins]

Closing in lieu of nodejs/open-standards#4