Repository navigation
Identifying core initiatives + Find Champions #390
Description
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.
Activity
mhdawson commentedon Oct 19, 2017
+1 from me, and other ideas of areas we should consider focusing initiatives around: #278
ktrott commentedon Oct 20, 2017
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 commentedon Oct 20, 2017
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.
@ktrott +1
mcollina commentedon Oct 20, 2017
SGTM
jasnell commentedon Oct 20, 2017
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 commentedon Oct 23, 2017
@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 commentedon Oct 23, 2017
For completeness we should include N-API as it is an ongoing inititiative.
Fishrock123 commentedon Oct 24, 2017
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 commentedon Oct 24, 2017
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
.gypfiles which are not only used in core, but also in almost all native addons in the ecosystem.And there's
gyp.jsthat needs love.fhinkel commentedon Oct 25, 2017
@refack Are you saying the Chromium code-review and CI are broken? Can you elaborate?
mhdawson commentedon Oct 26, 2017
@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 commentedon Oct 26, 2017
@fhinkel Just for
GYPe.g. https://chromium-review.googlesource.com/c/external/gyp/+/492046 -ninjacan't be located on the LUCI bots + varied regressionsBuidBot log - https://build.chromium.org/p/client.gyp/console
MylesBorins commentedon Nov 17, 2017
Initial implementation landed 🎉