Who is eligible for membership?

[MylesBorins]

Quick proposal, I can make a rough governance file to document if people like it.

---

Membership

The follow individuals are eligible for membership in this group:

• Any Member of the Node.js org
• Any individual currently participating in the following Open Standards groups:
  • TC39 / ECMA
  • whatwg
  • W3C

[joyeecheung]

Before discussing who is eligible, should we discuss what being a member in the open-standards team means?

• Is the membership required for being part of the consensus-seeking process around landing something in core? Or does the team simply make suggestions to other collaborators/TSC, and let them make the ultimate decision?
• Is the membership required for someone to be liaisons that we send to meetings of standard bodies? Or required to be a representative? Do they represent their own opinions in those venues, or are they supposed to be representatives for the outstanding opinions (possibly from others) in Node.js?
• Is the team a team to ping for opinions, or to ping for actions?
• Are we going to have regular meetings? If so, is the membership required to be a regular participant?

[littledan]

This sort of relates to the question, is this team going to be scoped specifically to the interaction between Node Core and standards bodies, or should it also include facilitating the Node ecosystem's interaction with standards bodies? For example, I'd like feedback in TC39 from popular libraries and frameworks in Node (e.g., Express) to be taken into account in TC39. Should I approach this with a separate space from this one?

[dshaw]

@littledan I believe the initial impetus has been to engage the standards bodies as a project. However, I'd love to see this group take broader ecosystem concerns if we can generate interest from those projects. This expanded worldview aligns well with the proposed expand focus of the Foundation.

[mcollina]

I think the overall focus should be on the Node.js ecosystem (core+modules). The role should be advisory only in relation to Node.js core: the responsibility for core is still on core collaborators+TSC. I see this team role as facilitating communication and taking a seat at the table on new specs that matters to Node.js.

I would consider membership as any standard team/wg: if someone makes valuable contributions, they got to participate in the consensus seeking.

[joyeecheung]

I think the overall focus should be on the Node.js ecosystem (core+modules). The role should be advisory only in relation to Node.js core

That would be a great goal going forward, but may I suggest we start small, focus on what gets shipped in Node.js core and/or gets maintained in this organization (that includes "official" npm modules), polish our process along the way, before trying to represent the broader ecosystem?

if someone makes valuable contributions, they got to participate in the consensus seeking.

Do we want this group meant for consensus seeking? - since e.g. in the case of core, whether something can land is up to the collaborators, and the specs have their own consensus seeking process, each specific proposal may also require specific expertise that may not be available within this limited group, what would consensus in this group mean for a specific proposal?

I think a more feasible goal for this group, at least for a start, would be to provide a venue for people working on standards and Node.js core to communicate and gather feedback (instead on the core issue tracker, since it has been a pattern there that users would come with feature requests every now and then, and get stalled without clear conclusions), to develop a practical process for standards participation and implementation, and to consolidate a vision of open standards in Node.js core.

The technical details of implementations still require case-by-case reviews (likely in core or in other code repositories), but it would be good to have a place to propose to implement something, understand the overall sentiment, notify relevant stakeholders and get feedback from other organizations, confirm a path to make progress, before jumping in and doing the work and only later to be blocked because the intent to implement has not been properly discussed. In a sense we could make the group function a bit like W3C TAG.

If we manage to develop a process that work well enough for core, then we can start trying to include the broader ecosystem into discussion - that seems to be a more feasible path, in my opinion.

[joyeecheung]

So, based on my thoughts into this in https://github.com/nodejs/open-standards/issues/9#issuecomment-434357201, to answer my own questions in https://github.com/nodejs/open-standards/issues/9#issuecomment-431272021 :

Is the membership required for being part of the consensus-seeking process around landing something in core?

No, the decision still comes from the core collaborators (personally, I'd say it comes from collaborators with the specific expertise regarding each specific proposal, like from subsystem teams).

Or does the team simply make suggestions to other collaborators/TSC, and let them make the ultimate decision?

That could be a goal of this group - this can be a venue for discussions around the intent to implement something, getting feedbacks and concerns, and working out a path to resolve those concerns, if possible - for example, talk to standards people and see if they can be changed to accommodate Node's needs. So whoever wish to implement a standard in core can use this venue to work out a way to make progress, instead of fearing that the work may be rejected and there is no clear path forward.

Is the membership required for someone to be liaisons that we send to meetings of standard bodies? Or required to be a representative? Do they represent their own opinions in those venues, or are they supposed to be representatives for the outstanding opinions (possibly from others) in Node.js?

I would suggest that the membership is not required for someone to be sent to meetings - but if the person being sent is going to represent Node.js core, they should either not be biased about the most outstanding opinions and should try to present the major concerns and disagreements in those external venues, or should refrain from speaking on behalf of core and make it clear that it's only their opinions if they are particularly vocal about one end of the spectrum.

Is the team a team to ping for opinions, or to ping for actions?

Following my thought process, I'd suggest we make this group a team of facilitators. To ping for the opinions about specific areas we have other handles (e.g. the subsystem teams, tsc), and the ultimate decision on whether a process/suggestion could land comes from the TSC and other collaborators.

In that sense, the proposal in the OP

Any Member of the Node.js org Any individual currently participating in the following Open Standards groups: TC39 / ECMA whatwg W3C

Sounds reasonable to me.

Are we going to have regular meetings? If so, is the membership required to be a regular participant?

I'd suggest that people interested in a particular topic (e.g. WHATWG streams) can decide how they want to have calls, but it's not required that these meetings have to be regular.

In my mind, this group is about helping the Node.js project make informed decisions, and limiting the participants to this small group of people is not going to help with that. But I'd like to see that at least some people in this group are present in these meetings and make sure notes are taken and PR'ed into this repo - so that we do keep track of the standards development in the project. We may also PR monthly reports into this repo collaboratively - without meetings, but on GitHub - to give people a better idea about the progress, and what the major concerns/disagreements are, and help us give constructive feedback to the standard bodies, e.g. seeking help from them to resolve these specific disagreements, instead of having nothing but chaos.

Above are my personal take on these questions, I'd be happy to see what others think and iterate on that.

[joyeecheung]

Another idea that comes up: we can create subteams for this group, for example

• A team for standard body liaisons (not necessarily work in nodejs/node repository but can be pinged for input/notifications/submitting feedback back to standard bodies)
• A team for documentations e.g. on current state of standard implementation in Node (the work may be in nodejs/node or in other separate repos)
• A team for testing, benchmarking and implementing standards in core (in addition to specific subsystem teams, this would be a team that help maintaining the overall framework/architecture of how standards are implemented, e.g. how WPT is run, how WebIDL is implemented, how the files are organized), can be pinged for actual code reviews in nodejs/node.

For the first subtem, the eligible people are

Any individual currently participating in the following Open Standards groups:

• TC39 / ECMA
• whatwg
• W3C

For the second one:

Any Member of the Node.js org

Or maybe after we set up a few actual repos where people can contribute to, we let them govern how they want to give commit access to people, and the union of collaborators in those repo is eligible for membership in this team. Some existing repos that I can think of are: https://github.com/nodejs/node (specifically the documentations there), https://github.com/nodejs/nodejs.org and initiatives under https://github.com/nodejs/community-committee#current-initiatives

And for the last one, Node.js core collaborators i.e. people who have commit access to the nodejs/node repo.

People who are not yet eligible can join by contributing to corresponding organizations/projects, becoming members of those organizations/projects, then becoming a member of this group. This group will defer onboarding newcomers to these projects/organizations who have their own governance model, contributing process, and even mentors, as it's difficult for one group of people to do these all considering the scope of work here.