Identifying core initiatives + Find Champions

[MylesBorins]

Hey all. So I think that it is important that the TSC identify a number of "Core Initiatives" and find champions to own the process / keep the committee up to date.

What is a "Core Initiative"... I'll make up a definition right now 🎉

A "Core Initiative" is a large scale project that will require the effort of multiple collaborators coordinating over a non-trivial period of time. The success of "Core Initiatives" are integral in the ongoing health of the Node.js project. "Core Initiatives" will have an identified "Champion", an individual responsible for project management of the initiative and keeping the TSC up to date with progress.

Examples:

• promise based APIs in core
• ESM + CJS interop
• Names ESM exports form core modules
• SSL for Node.js 10.x
• Double-Click Installers
• Operations + Site Reliability
• Time-Travel Debugging
• FFI
• Gyp vs GN

---

Identifying "Core Initiatives" should make it easier for first time contributors to get involved in the project.

If the TSC prioritizes core initiatives it will make it easier for organizations to make decisions regarding headcount they are allocating to work on the project

We do have prior art with the NAPI and HTTP2 work that was done in a somewhat similar model.

edit: to clairfy, prioritization is in regards to how important the initiatives are, not prioritizing them over current work being done.

For example figuring out an SSL story for 10.x has a 6 month windows, it is very high priority. Fixing the installer, while important, is lower priority.

[mhdawson]

+1 from me, and other ideas of areas we should consider focusing initiatives around: #278

[ktrott]

Another possible benefit: A clear set of core initiatives may also give the community a better sense of the roadmap, direction, and vision for the project.

[joyeecheung]

SGTM, also we can consider using the Github team and project to organize things better. These initiatives should be less formal than working groups but can make meetings when neccesary.

Another possible benefit: A clear set of core initiatives may also give the community a better sense of the roadmap, direction, and vision for the project.

@ktrott +1

[mcollina]

SGTM

[jasnell]

I would not necessarily use the term "roadmap" for these. They are areas that need coordinated attention in order to make progress. A roadmap implies that the resources are being officially dedicated and assigned to address those but that's not necessarily the case.

The idea would be to identify these areas, identify who the champions are, and identify some reasonable path for how to get actively involved.

I will put my name in as the "champion" for the Promise-based APIs in Core initiative as I have already started work on that.

I'm also going to add a couple more initiatives:

• Improved Diagnostics and Measurement Primitives in Core (this covers things like perf_hooks, async_hooks, trace events, etc). I will continue to be actively involved in these but this may have multiple champions.

• Improved Streams API. This is something that a handful of us have been discussing recently (handful being @mcollina, @Fishrock123, @trevnorris, myself, and @addaleax to a lesser extent but we need to get her more looped in). This is new and details should be forthcoming relatively soon(ish). Feel free to attach my name as the "champion" for this effort.

• Mentoring. While not a technical initiative, it's a critical one. Independent of everything else that we may end up doing with regards to the governance discussion, developing a functional mentorship program within core should be considered a priority initiative that we should not simply expect CommComm to figure out.

[bnb]

@jasnell +1 on mentoring and the idea that it's not JUST a goal of CommComm. We can and should work together on this - please let the CommComm know how we can help the TSC in further enabling this, if we can. ❤️

[mhdawson]

For completeness we should include N-API as it is an ongoing inititiative.

[Fishrock123]

Improved "Streams" API.

See nodejs/node#16414 & https://github.com/Fishrock123/bob

I'm quite set on seeing this one through to the end one way or other.

[refack]

RE GYP, seems to me more then ever we should fork. The main benefit of upstreaming to Chromium was the code-review & CI setup, but that has recently became broken (also code-review eyeballs has reduced to 2 people)
Besides bug fixes and expanding to new platforms, I keep a backlog of features that will improve our build & CI process, and enable better traceability & "debugging" of .gyp files which are not only used in core, but also in almost all native addons in the ecosystem.
And there's gyp.js that needs love.

[fhinkel]

@refack Are you saying the Chromium code-review and CI are broken? Can you elaborate?

[mhdawson]

@bnoordhuis has been looking at cmake as an alternative for build Node.js itself but I know that does not solve the overall GYP issue.

[refack]

@refack Are you saying the Chromium code-review and CI are broken? Can you elaborate?

@fhinkel Just for GYP e.g. https://chromium-review.googlesource.com/c/external/gyp/+/492046 - ninja can't be located on the LUCI bots + varied regressions
BuidBot log - https://build.chromium.org/p/client.gyp/console

[MylesBorins]

Initial implementation landed 🎉