Next-10 Keeping the Project Healthy  ## Metadata - Author: [[OpenJS Foundation]] - Full Title: Next-10 Keeping the Project Healthy - Category: #articles - Document Note: --- tags: - #Nodejs - #OpenSourceHealth - #ContributorSustainability Author: Node.js Collaborators & Community Source: YouTube Session: [Next-10 Keeping the Project Healthy](https://www.youtube.com/watch?v=Qw31NVxByRA) Reference: Transcript timestamps 0:00–51:00 date created: 2025-08-22 19:45 --- # Title: Next-10 Keeping the Project Healthy: Sustaining Contributors and Project Growth ## Table of Contents: - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis Prompt](#-darvo-analysis-prompt) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary: The Node.js Next-10 session “Keeping the Project Healthy” centered on sustainability, contributor engagement, and corporate support. Participants highlighted **mentorship programs, automation, non-code contributions, and recognition** as key drivers for long-term contributor retention. Major debates included balancing **automation vs. human review**, using **dependencies outside core** to reduce maintenance, exploring **WASM integration**, and enhancing **case-driven documentation**. The group emphasized the importance of **rewarding all contributions** (code and non-code), aligning company support with project needs, and building intentional pathways for contributors. --- ## 📖 Main Content: The discussion focused on identifying strategies for maintaining a healthy OSS ecosystem. Contributors stressed the need to: - Develop intentional pipelines for **new and long-term contributors**. - Improve **automation** (PR tagging, CI workflows) while recognizing its limits. - Address **PR review bottlenecks**—an issue of bandwidth, not just tooling. - Explore **project size reduction** via external dependencies like Undici. - Investigate **WASM as a performance path**, balancing maintainer burden vs. end-user experience. - Provide **reliable case-driven documentation** and **examples/recipes** to counter misinformation. - Elevate **non-code contributions** (docs, discussions, training) with recognition and dashboards. - Align **company involvement** with sustainability and reward contributors financially or socially. --- ### 🗒️ Notes - [00:04](https://www.youtube.com/watch?v=Qw31NVxByRA&t=4): Framing—healthy projects depend on long-term contributors and company support. - [06:48](https://www.youtube.com/watch?v=Qw31NVxByRA&t=408): Themes raised: automation, paying maintainers, mentorship, company contributions, rewarding contributors, knowledge transfer. - [12:08](https://www.youtube.com/watch?v=Qw31NVxByRA&t=728): Idea—automated PR review reminders, but tension: “automation doesn’t create reviewer time.” - [19:34](https://www.youtube.com/watch?v=Qw31NVxByRA&t=1174): Proposals to trust tests/coverage → reduce reviewer load; introduce dependencies outside core (Undici). - [28:41](https://www.youtube.com/watch?v=Qw31NVxByRA&t=1721): WASM as faster than C++; potential for re-architecting parts of Node. - [33:18](https://www.youtube.com/watch?v=Qw31NVxByRA&t=1998): Recognition: pay/acknowledge contributors, especially new ones. - [42:01](https://www.youtube.com/watch?v=Qw31NVxByRA&t=2521): Highlighting non-code contributions—leaderboards/dashboards needed. - [44:05](https://www.youtube.com/watch?v=Qw31NVxByRA&t=2645): Non-code contributions (docs, training) undervalued but crucial. - [48:20](https://www.youtube.com/watch?v=Qw31NVxByRA&t=2900): Proposal—case-driven documentation, bridging gap between API docs and real-world tasks. - [50:16](https://www.youtube.com/watch?v=Qw31NVxByRA&t=3016): Call for deeper future session focused solely on long-term contributor engagement. --- ## 📖 References: - Node.js Next-10 initiative - [Undici](https://github.com/nodejs/undici) project - WebAssembly / WASI specs - Node.js Collaborator Summit materials --- ## 🗣️ Paraphrase: 1. Original: *“Automation helps, but the real bottleneck is reviewer time.”* **Paraphrase:** While tools can automate tagging and reminders, they can’t solve the lack of skilled reviewers available for PRs. 2. Original: *“Non-code contributions need recognition equal to code contributions.”* **Paraphrase:** Contributions in documentation, discussions, and training are vital for project health and should be valued alongside code. --- ## 📰 Newsletter: 🚀 **Node.js Health Check: Next-10 Insights** At the Next-10 summit, maintainers dug deep into what keeps Node.js healthy for the long haul. Big takeaways: **mentorship, automation, and better docs**. But here’s the kicker—contributors want recognition for *all* their work, not just code. Think dashboards for docs writers, shoutouts for trainers, and financial support for long-haulers. Discussions also explored **leaner core dependencies (Undici)**, the promise of **WASM performance**, and the need for **case-driven docs** to squash outdated tutorials. Want to shape Node’s next decade? Tune into the [session replay](https://www.youtube.com/watch?v=Qw31NVxByRA). --- ## ✅ Action Items: - Use Node.js’s struggles with review bottlenecks as a case study in **WordPress contributor retention**. - Advocate for **recognition of non-code contributions** in WordPress (parallels The WPCC’s funding advocacy). - Integrate **automation ideas** (PR tagging, dashboards) into contributor onboarding for WP. - Highlight **mentorship and structured contributor growth** as OSPO director-level priorities. - Frame **WASM/Undici debates** as examples of balancing end-user vs. maintainer experience—translatable to WP governance. --- ## 🧪 Hypotheses: - Recognizing non-code contributions increases long-term contributor retention. - Trust-based automation reduces maintainer burnout. - Corporate sponsorship correlates with healthier OSS ecosystems. ### 📊 Methodology: - Comparative retention studies across OSS projects (Node.js, WordPress, Kubernetes). - Data collection on contributor activity pre- and post-recognition initiatives. - Surveys on contributor motivation and company support. ### ❓ Questions: - How can WordPress better recognize non-code contributions? - What governance structures reduce PR review bottlenecks? - Should OSS projects adopt “thinner cores” to reduce maintenance? ### 🔮 Future Research: - Effectiveness of **case-driven documentation** across OSS ecosystems. - Measuring long-term impacts of **financial support for maintainers**. - Exploring **WASM integration** models in OSS beyond Node. ### 💡 Implications: - Stronger contributor retention → healthier OSS sustainability. - Recognition and financial incentives → reduced burnout. - Improved documentation → wider adoption and fewer downstream issues. --- ## 🧠 Learning Styles Assessment: - **Visual**: Absent—should add contributor journey flowcharts. - **Aural**: Limited—session transcript supports audio but no podcast. - **Verbal**: Strong—rich dialogue, examples. - **Kinesthetic**: Weak—few actionable exercises. - **Logical**: Strong—structured debate on automation/maintenance. - **Social**: Present—summit collaborative format. - **Solitary**: Weak—few reflection prompts. - **Naturalistic**: Absent—no analogies to ecosystems. --- ## 📊 Accessibility Assessment: - Transcript provides baseline screen reader support. - No alt-text or structured visual aids. - Limited guidance for color contrast/keyboard navigation. --- ## 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: - **Cultural Relevance - Summary: The team discussed keeping the project healthy and identified two areas of focus: identifying, helping, and maintaining long-term contributors, and encouraging companies and people to support the project. They used an easy retro brainstorm to gather ideas, and also talked about reducing the size of the project, supporting non-code contributions, and improving the review process for pull requests. They considered systems that could reduce the burden of maintenance and ensure that tests are passing before merging. - URL: https://www.youtube.com/watch?v=Qw31NVxByRA&list=PLyspMSh4XhLO15jJD9Sj069fN18j12AbQ&index=5&ab_channel=OpenJSFoundation uh our second session today uh thinkingabout the next 10 side of things iskeeping the Project Healthy which Ithink iswhere a lot of the topics that we weretalking about were headingum so that's a good starting pointsowe thought that uh the structure of whatwe have for this section section is tohave again like we we like our easyretro brainstorm so we're gonna haveanother one like what do we think isimportant for a healthy project so we want everybody to think about that putthem into the easy retro we can reviewand prioritize like we did beforeand then we have some initial areas andwe can adjust this you know we wantthese to be dynamic based on what wethink is the most important well we hada couple of ones we thought that wouldbe interesting to dive into in terms ofyou know what is important for keepingyour project healthy one is like how doI identify help and build maintainlong-term contributors we've had lots ofyou know we've tried many things in thepast like we've had code learns um mentorship program the what thementorship program and so forth and theymay Target different types ofcontributors like you know the the codeand learn is like hey get your first onein and I think our long-term goal wasmaybe longer term contributors but wecan think about like this not the bestway so basically what should we be doingto help identify help and bring in andmay sort of maintain long-termcontributors because I think that's oneof the key things at least in my mindthat's important to the health project and then the other one is like how do weencourage companies and people tosupport the project as wella lot of the long and I think they'renot necessarily uncoupled like peoplewho are long-term contributors oftenhave more support from their companiesuh and able to to enable them to be ableto do those kinds of things so thosewere two we thought we could dive intounless we find one on the list that'slike so much more interesting that wewant to go for that oneso again similarlyuh uh it to the um the last one on the agenda if you go tothe uh the the collaborator sub agendayou look linked to the issue for thissession you'll get the link to that easyretro boardand I guess I didn't really rename thesewhich I meant to I think but uh so I would say in terms of using theeasy retro let's just put all of ourideas into that to discuss columnbasically you know what is it you thatyou think is important for maintaining ahealthy projectand we'll start so go aheadit's it's that long URL but if you soright so if you go to the GitHub productif you go to the GitHub project for thesummit oh it's on slack as well okay okay sothat's uh somebody posted it therethat's even betterno problem foreign good okay I'm sitting settings yeah where's your account would be the first one yeah okay so maximizing automation yeahthat's good paying maintaining computeryeah long-term contributors if you wantto go through with the mic Michael and Iwill yep I will murder okay you'll merge them okay great sojust going through the list maintainingautomate I mean maximizing automationyeah that definitely is good payingmaintainers contributorslong-term contributors clearavailability of mentorsuh contribution from companiesgovernmentsencourage and simplify contributiontransfer knowledgeuh align the company needs with projectneeds as a vendor for contributors supporting non-core contributions isvaluablereward contribution low politicslow barrier entry for new contributorsthe ability to move things forward at areasonable pacehow to do introduce newcomer in node.jscoreDefine goals on the project companiesfor companies to jump in onmitigating interpersonal conflicts avoidabusers of power abuses of power money more actively involved in on-ramp notjust for new contributors people toJoint areas they aren't familiar withsupport for key operational aspectsbuild really security triage fixesreleasesa healthy package ecosystemhow to reduce size of project frequentperiodically recertify all people'sstatuses so collab TSC moderation withsubjective rubricsuh sorry I'm uh update commit message rule followconventional commituh recognition for the contributors ofthe contributions collaboratorshow to improve consolidate therelationship with the sponsors thatprovide us infrastructure sometimes it'shard to know how to manage lead therelationship from the build workinggroupmore good first issues roadmap to dothis to do the issue not having to askWhat's blocking this a visual tool tosee progress of node.js so I guess the first thing would be likewhich ones can we combine together thereand are there any sort of clear themesthat we would group togetherto merge them okay yep so yeahyepyeah sounds goodbecause I think there's a bunch aboutnew contributors for sure yes is there any multiple one on thatwhatno uh so this one was a joke based onthe last conference in Dublin where weall took the same busso yeahyeswe we had this talk like last time yet yet is a keyworddo we see other car that should bemergedemerging a few the mentors I think he'sall sort of fit in withhow you get new contributors howyou make long-term contributors to sortofyou know obviously people are importantthing in a healthy process yeahyeah I think that that likeit's a little bit like contributors andpeople who are happyprobably thethere was another one herelike even supporting non-co code I guessI guess also the last one not having to ask what is blocking thislike I don't know but this one but Iunderstand it as like pull requeststaking a long time to be merged but ifsome I don't know who wrote this oneno onelike the lastso if someone want to explain you're not having to ask what is blocking this isit linked to time for pull requests tobe merged there's something we can do thereum to summarize with the microphonebasically for that last uh ticket of nothaving to ask what is blocking this thisshort is justum when a PR is up and the CI is passingum it shouldn't necessarily be on thecontributors uh responsibility to like ask for reviews and ask for things likewe should the system should be you knowif the pr is open not in draft and ifthings are passing someone should begetting tagged for it um it kind ofreminds me of the definitively typedrepo that does a really good job of justlike letting maintainers know hey reviewthis like it's been there's you knowthere hasn't been a review in one weekhere's another ping has been reviewingtwo weeks okay here are more pings likeit's automated in that sense yeah I'm not sure I would lump that inwith like getting more contributors Ibecause it seems it's definitely a thingsomething I think we should talk aboutbecause likeit's not necessarily anybody's job toreview thoseso how do we that's why I think thatfalls into like if they happenyou can you can have I see a couplepatterns where like if you'renewyou get people who see it because it's kind of on the top of the list but ifyou get into the point where like heyyou get a whole bunch of comments and itgoes back and forth and it's now droppeddownthen it's much harder for people to comeback later and sort of see it and why isthat andthe Affinity type doesn't really workwellno so it's it I wouldn't I wouldn't pickthat as a good example okay the factthatum I ended up being one of the peoplereviewing the product the types for node should tell you that things are notgoing really well[Laughter]yeahbut the thepoint the problem of wish are the peoplethat are actually reviewing it itdoes not help it does not solve thatlike all that automation while working very well does not solve the problem ofthe right the people with the rightskills to review that code are actuallytag are actually doing the job ofreviewing it okay which is a little bitmore profound than just automation likeyou can it's to be honest it's a problemthat is very hard to fix with automationand because we already have automationlike if I am tagged in all the PRS thatare issues that are HTTP and we already have all of that and that gives you anotification and a ping so and so you wehave that Automation in place and it'snot like tagging people by name does notnot necessarilyit doesn't make more time for me to doagain it's the problem is more of timeokay we have 400 issues open 400 PR'sopen and every time we do a securityrelease We Gather maybe 250 to 100 of PRS open that we are not Landing so it'swell 200 of those PR's if I ever getaround to it like are ones that werethat have not been that are over a yearoldand have not had a comment in six monthsso I don't think again we should weshould just bunker them like I'm goingto be uh we should just bankrupt them Ioh sorry no I don't need the microphoneyou don't want you want to talk okayyeah okay I was just making the pointthat then I wonder if some of thatautomation question is also connected tothe reducing the size of the project orat least maybe likeyou know kind of separating out concernssuch that Mateomaybe does have more time 36 hours I was wondering what that one meantlike what would reducing the size of theproject meanI'd whoever I don't know who I didn'twrite that one I was going to bringsomething else I'm just curious becauseI I I'm not quite sure like is that lessapis is it lessI mean I I just wondering why should we reduce the size of the project nobodysays that everybody should know everypart of not I only work on HTTP I onlywork on net I have no idea how cryptoworks and I don't want to know about itso I'll just ignore his existence that'sitplain and simpleyeah I was just curious that I don'tknowtrying to understand that that one whatit is there's I mean there's lots ofdifferent things it could mean yeah I'lljust talk about one that I added that isrelated here is the non-code non-corecode contributions as important I actually think that we could do a lotbetter job getting people to reviewthingslike if we could onboard people strictlyas likereviewers right like that's a veryvaluable jobum and I and I don't knowlike I feel like that's not somethingwe've we've had before like I thinkthat's kind of like the triage effortthat we did on Express is kind ofsimilar like the if we can if we can getpeople not forcing them way into the deep end we don't need to reduce thesize of the project we don't need themto know the HTTP stack to just likestart reading the code and commentingand asking some questions and trying topush things forward with to save Mateotime so when it finally gets to it thethe person who's going to be the one orwhoever right like the the person who'sgoing to be the one giving the like verytechnical deep understanding feedbackthere's already been a lot of theroadblocks removed rightsustainability yeah I think to follow that up there's athere's a a more bullish kind ofpractice of like if the re if we trustthe systems that we build in the repothen it takes less onus of the reviewersum that's something that at least um Ipractice at for cell and our repos islike we is one of those like uh like thefacebookism of like move fast breakthings there's a way you can do that even in a slower Pace in like node.js'scontext of if we can if our systems areset up in such a way that we can trustthem more than we trust the people thenum or as much as the people then thereviews are less important or don't needto be as strenuous if tests are passingif code coverage is there if we canquickly fix things as we merge themrather than like putting all of thesesteps in in front of merging stuffthat's a yeah exactly yes safer failure is agreat way to put it[Music]well we have a little issue that peoplefrom Zoom remote attending can't reallyspeak so uh reply so yagis has a replyuh to the maintenance burden of node.jsuh his answer is adding new dependenciesand replacing the existing ones reducethe effort of maintaining the node.js such as Sim D UTF and otherI'm just saying what it was writingit's a suggestion that we pull more outof node core itself andinterdependencies as the sizehe's typing yeah okayas synchronousyes okay so that makes sense like youcould say we reuse dependencies so thatwe don't have to maintain that codeourselves right like we pull in a componentso in that context I understandumuh I would just add for this one we hadthe opposite discussion like 20 minutesbefore that we wanted to add like tolink like stuff like somewhere orindigee to be in order if we because italso guarantees a community that it'sbeing maintained and follow up withversion and stuff like that so I'm notsure ifremoving complete part to external lies everything would be the best wayuh theundichi has brought in more peoplethat areum especially all the fetch stuffwas done by people without thecommitment on coreand chorus fetchso I'm just flagging it as a as a pathwaylike following that kind of approach canhelp in that senseum if contributing to those repos issimpler than contributing to core likecontinuing to chord that needs to followa lot of rulesand if you take the same rules elsewherethen it's Hazard but with with unichi wehad the more relaxed there is a thetooling is more familiar to them so that it's not there's no python it's all npmbased it's it's it's it's way simpler onthat side there are hard complex stuffin there but especially on the fat sideswas mostly JavaScriptI would like to add thatall the web ideal conversion that wehave in in inundichi is better than theone that is in coreand it's it's a and yeah just I just wildly mentioning it because we evenhave uh parts that are and and thenpeople are like the question of oh butwe should just add certain things on onundichi but even though they are notfetch based because it's so much easierto to to do web standards in undichiitself rather than uh I think that's areally interesting thing from myperspective because it more it matchesour use of teams where the teams like our smaller group that work on aparticular area and I've seen that workreally well for bringing new people upand focused on an areaso yeah it's an interesting model wherelike hey instead of something new incore it's like a new dependency thatgets then dependent on in core yeah Ithink we talked about like uh like thevendoring or adding hooks or just havinglike you know the fetch stuff has madeits way in we have parsags that getsadded in another way I think if we canif we can solidify that process a little bit better and maybe it's just we haveto do it more other pieces of node.jscan live outside of it let's pretend wewant to redo the the file system API innode.js who's to say that that has tolive in core anymore could we create asuch just like undichi just create anode.js fs and then that thing caniterate quickly outside of core and thenthere's some way that we re-expose it incore I think the larger question thoughis like also what's facing unichi right now is zundichi has fantastic networkingPrimitives but only fetch is availablein core where's the rest of it how canwe get the rest of it into core how canwe expose the rest of it withoutbreaking the existing like stuff andalso I you know these I mean I'm I'masking these questions yeah these arelike please no one no one try to answerthis like even even later it's these arelike very long discussion points but thepoint being is there's probably a reallycool path there that if investigated could lead to some of that um what we'veall been saying of like uh easier toiterate faster to maintain moreexperiments fail saferum etc etc but yeah there's more to togo through thereokay so you just basically re likereiterated back to version 0.2 to becompletely honest wherenode.js was going to be a thin rapperover liby well Libby V didn't exist at that point but a thin wrapper over anative layer that'll and then userscould extend that via their ownJavaScript apis that's originally whatwas supposed to happen and it's becomevery bloated since thenbut now we're seriously we're justending right back there because one ofthe big factors you cannot have anexternal Library like the fs stuff youcan't do that because you need nativebindings right now undishi doesn't sothat works there's a lot of stuff thatdoesn't need native Bindings that we cando that FS though requires native bindings soeither we redo the API in node so thatit's just a very thin fast layer overlibuv and then we let users iterate overthat however they wantum or we just bring it like man this wasforever ago but the joke was codecore is where code goes to dierightumand and so do we want to discuss like if wedo this is a massive change but do wewant to discuss the idea of going backto the old idea of a thinner fasterlayer to allow users to iterate morequickly over their own apisso I think we want to maintain the enduser experiencethat is easy that we have today byhaving such a bloated I'm not I'm not saying it's actually bloated I just youknow I think that gives a lot of powerto the end user and that drives adoptionand and makes things easy but I thinkwhat we're talking about here and why II mentioned vendoring earlier is themaintainer experience is what suffers bythat design right so I think we can haveour cake and eat it too by by then bycommitting to things like undichi andparsargs where the development happensoutside but what the end user sees is not that we don't want the end userhaving to care about these things wewant that to be really smooth for themum so I think yes I think we should begoing to a world where these thingsmaybe we revisit that idea but we're notdoing it in such a way that we sacrificethe great end user experience of like areally solid standard Library the way we were able to ship this ininundichi is by using guazoso it's uhumdichi bundledthe HTTP LL httpand this is even the funniest bitsit's actually fasterthan the the Double C plus plus wrapper so it's it's a to be clear on theI'm going these challenges certainassumptions of of how we do things incoreum I just want you to point it out okaythatum we haveumif we want to do some experiments andradically re-architect certain parts ofnode it might be possible to essentially export certain parts ofLiberty via VIA wasmthat we are Wazi even now that we haveit it's one of the the second top orthird top most performance wasimplementation out there for withouteven trying okay so I'm justit's a um and there is a few reasons whyit'sum so the boundary between wasm andJavaScript is thinner than the one to Cplus plusand and so certain things are faster sohowever there are certain other stuffthat we do that's not possible so itworks fordoes thingsbut possibly it would not work like youcannot expose a full-blown object right now from wasm to to JavaScript butagain I think it would be massivebenefit if we uh like that's theapproach that we've done and it hasworked well for us apart fromsynchronous so there are a few problemsthat we'd have to work throughit's so this isexists so the asynchronous stuff can bedone right now it's I think is the theHDL HP is fully synchronous so that's not that's also saying this we could buttoday's implementation is synchronous sowhat officeno no Wazi is uh yes I think ourimplementation is synchronous but intheir shipping the the asynchronousstuff too so I'm just and to be honest Ithink they have done recently somereleases on that regard V8s added somenew stuff yeah recently but just starting to like it's it if it meets theuse case today you're good like with uhyou be sorry with uh indichi but thereare other use cases where we'd have tosay oh yeah we want to go here and nowlet's actually look at ourimplementation of UV Wazi and can wemake it asynchronous yeah I I I I don'tknow specifically but The Primitives arethe Primitive Primitives ofum Wazi are all moving in that direction okay so I'm notum I'm not going to say it's not it'sit's just going to happen okay withouteven us doing it to some extent apartfrom keeping up to date with the spec soit's just a matter of keeping up to datewith the spec and theneventually it will it will happen andthere are people really interested inmaking that happen so to be honest it'salmost uh it will be a solved problem inin a year from now or or so from my point of view so it's uhum and that actually like there is onlyone downside I just wanted to mention tothat approach is that building thatwasn't doneit's I I put it in its own littlenightmare boxand I I know the folks of read that havebeen uh fighting against that problemfor a bit so it's it's an it'snightmarish to the point distro is a heartache so yeahbut like to compile together wasn'tthing we spin up uh a Docker image withall the tool chain installedbecause installing and configuring allthat tool chain on your machineis closed to Impossible I was it wassimpler to get a Docker machine with allof it than installing it on my machinejust I could I would not able to figureit out so I think we're going down uh a particular path here so we shouldprobably pull back on that but I thinkwhat what uh Mateo's key point was islike there may be some challenges butthere are some alternative ways of doingthings so we shouldn't shouldn'tnecessarily say it's impossible I thinkis where he was going yeahso okay so I mean I don't know if we canpull this list down any more likecombining anything more but we kind ofhave the uh the the the sort of company contributionones which are all grouped together herewe have this sort of reward so like youknow paying maintainers rewardingcontribution recognition you know thoseare all ways to sort of reward people wehave a whole bunch about maintainers interms of like bringing in newmaintainers and encouraging them to stayI thinkum there's ones which I think are maybea little related to that but I left them separate and that like the ability tomove things forward at a reasonable PaceI think that fit in with the like What'sblocking thisum you know it's great if we attractpeople to come and do work but like ifthey can't actually accomplish anythingthat's where I think you you tend tolose people so I think that one's kindof an interesting one on its own and theautomation I think fits in there wetalked about like you could automate thewhole processthere's a couple around conflict abusesof powerrecertifying people in different uh roles like the TSC moderationEtcand then the rest uh I don't know if anyof those people think any of those fitinto any of the other uh grouped ones Ididn't see any natural fitI'm just wondering for the last one avisual tool to see the progress ofnode.js are we talking about pages andcurrent like initiative or is itsomething else yeahdid whoever put that one on wannaadd to the contextthank you yeah so I don't I don't know if but ifanybody else wants to expand on whatthat one might be it it's from sorry goahead it's from slack and Augustine waswriting about it yeah Tom Augustine hebut he's still writing on itum so so yeah um so so why don't we just take a fewminutes then and we can do sort of thelike everybody put in their votes let'sput in like how many do we have herelikeI would say likethree because we don't have such a biglist you know put your top threeum then we can take a quick look at thatand then dive into the more detailed uhdiscussions that we hadon the list would be sitting also in a second onethe second one on the list Michael[Music] oh it's inside okayokay so just for the last one aboutthe visual visual representation ofnode.js a visual tool to see theprogress of node.js sotechnically would be to have some kind of way to display what features arebeing currently developed and if it'slinked to some ecma standard or someother stuff or if we will likelike which feature we will adopt or notadopt like navigate object or somethingaround it so I guess like some kind ofcan I usekind of that that one makes me think ofwe didn't come up with like a clear direction for the project as somethingthat's needed to keep it healthy whichthat might fit in with right you know ifyou had a direction then you can seelike are the things in line with thatdirection or notokay so has everybody added their theirvotesokayokay so it was something like a reverse can I use that would be linked only tonode.jsbut with better accessibilityso I think we head till 1 15 right wasthat uh weightswe do have seven minutes technicallyokay on the official planning but Ithink we started a big a bit late soyeah true yeah I was gonna try I'm notgoing to extend the way of people in lunch so umso I think you know obviously it lookslike you know again contributors are oneof the key things in people's minduh even related to that is like makingsure we reward contributionand you know consider how we could wepay maintainers and contributorsand making sure they get enoughrecognition and then the third one iskind of thesupporting I think that through corporate involvements and so forthover then to what we had now we don'thave a lot of time left so I don't thinkwe'll haveumenough time to go through everythingso I think the the one thatwhich was at the top there which was the contributors and so forthyep I'm just wondering like the umyou know maybe we can start a brainstormwe don't have enough time but likehow do we start to build like be intentI think somebody was saying maybe it wasMateo earlier we want to be moreintentional about how we grow long-termcontributors in the project uh gettingstarted like a Newcomer's guide could bepart of thatbut what's the overall like what wouldsomebody's top thing be to say heywhat's going to keep somebody in theproject contributing over the longer term uh[Laughter]it's very much that it's you need tokeep them engaged with reviews with uhthe fuzzy feeling of Landing their firstcontributions uh you know startcelebrating a little bit more on the uh start celebrating them a little bit moreokay it's uhum something that as an example we coulddo whenever there is somebody new thathas been a contribution to node when wedo a release add a little paragraphsaying thanks for foruh thanks for Michael to his firstcontribution to uh to node.js orsomething that GitHub does it now on automaticallyto that point though I think that so wealready kind of do that we do liketweets about when we add onboard newpeople and that's I think awesome but Ithink we need to be doing that for noncode contributions to get more people onboard we you you don't jump like so Ithink I've actually submitted one PR tothe node project my in my life right but I've donetons of other non-code relatedactivitiesand the dopamine hit only lasts so longwhen you're notI don't need the dopamine hit toparticipate here obviously like I getpaid I'm on a team that's called node.jsplatform team like so you know and I'veI've slowed down my non-codecontributionsindependently of that stuff but what I'msaying is I'm not trying to make it about me Idon't need more dopamine is what I wastrying to say thereum I'm good but I think for a lot ofpeople if we can really get thatlike maybe a board that we you knowmaybe tweets maybe like a board that hasthose non-code contributions in a waythatstarts lifting them up maybe you knowa dashboard I don't know where's uhDarcy likes to always bring up the thedashboard thing that um that we did forExpress which just brought all of it together I think I made like one thattries to do like a leaderboard kind ofapproach of like who's the most activeand and I specifically made it notuh weight code contributions more thanthings like comments and issues andparticipating injust threads of discussions right and soI think if we can figure out a way tolike lift those thingsup and and those people who are doingthe the the conversation Parts more Ithink that would really help when I add to that we've beenum looking at ways more specifically atour company of getting more peopleengaged in open source they're talkingabout non-code extending that evenfurther like discussions are great butlike documentation contributionstraining contributions like kind ofelevating of that that stuff is just asimportant if not sometimes moreimportant than the actual codeum we don't have a lot of success for itright now but we're kind of looking likewe haven't really done much of it butwe're I'm hoping we're hoping for maybelike a that elevation will help get some of that engagement and encourage somepeople who are like I don't want tocontribute because I'm not very good atcode great but you can write in Englishso that sounds greatsomarketingso they um talking about that that islike one of the problems that I've seenI have seen all with all the time withnode we that we to some extent partially sold with the node certification andstuff and the and the trainingassociated with it it's there is a hugeload ofum blog posts courses that essentiallyteach you teach the wrong thingand it's and the reason why I know itand where I to some extent I canbacktrack to certain individuals andcertain blog posts the fact that uhissues are open Downstream on on my on my on my repositories because the thereis a lack of um kind of source of Truthon how to use on how to structureanother application on how to do certainthings or you know or a blessed way atleast by the project to do certainthings and if you do want to do whateveryou want you can do whatever you want ofcourse it's just a tool but if you uh ifyou try to uh you know if you need to toput in a screw and you have a numberprobably you're not using the right tool for the job right so and from time totime I see people all the time trying toput in screws with with numbers or viceversa and it doesn't it's not a good youknow and they have a massive amount ofproblems with it because it's of coursethey read that that are supposed to workfrom somebody and that's yeahso do we think that maybe one of the keyissue is we provide runtime that is widely used without necessarilyproviding like good practice foreveryone like newcomer not necessarilycontributor but to use it and everyoneneed to and rely on like like you saidmaterial blog posts that are maybe sixyears old not really useful but on thesame time if you go to the currentnode.js website except for maybe 10pages on the get started which providessome stuff you won't have a good way tohow to import map or to I don't know use CGS esm or something like thatabsolutely so this is that's exactly thekind of stuff that and we have no goodway to Value those contributions to someextent but also there is thatinformation is actually missing fromfrom my point of viewone of the discussion in the next 10 afew weeks months back which was also linked to the documentation part will beto try to revive the example project Idon't remember the exact name but justto provide a list of basic examples onhow to use node.js around multipletopics that could then be linked andbeing easily accessible on a new websiteso maybe that is something that could benice to work onI mean that for sure would help but thething is that of course we can easilyprovide example on let's say how to start an HTTP server pretty and easyright or let's say use fastify versusExpress versus anything else but thething is that when it comes for muchmore complexumtopics I don't know like Mater will sayhow to structure an application we needan extensive blog post for that becausewe cannot live anywhere in the notdocumentation because that does notbelong to http nor to FS or somethinglike that we need more structuredCommunity effort blog YouTube twitchwhatever for this for that so this is actually a problem I've beenthinking a little bit aboutum with the documentation I thinkthere'sI don't think a blog post is the rightthing either necessarily I actuallythink what we need is probably someattention to the likecase driven docs so we have thetechnical docs really well covered but Ithink what we're missing here is thelike like you said I may I want to startan HTTP server the right answer is probably not use the HTTP package rightthe right answer is probably use fastifyit's definitely not use expressumrecipes maybe is anyway sorry I had Ihad to say it uhI'm just kidding but uh so uh so I thinkwe need yeah maybe recipesexamples but I think there is a maybe Idon't even know if I like recipesbecause I think it's a little bitbroader than that right it's not even just about the code which is when I uhmaybe I'm just thinking of the wordrecipes differently than you areum but likeit's not quite gets getting startedright it's it's here's a specific taskI'm trying to yeah I'm trying to achievebut it's not even examples necessarilybecause an example to me reads is likea here's a script like here's dump thisin your index.js and run it that's anexample to me it's like let's walk youthrough what does it mean to run an HTTP serverin node we're gonna we're gonna talk alittle bit about you know uh how do youset the proper caching headers that'snot really something that node quarterlike how do you set cookies how do youdo the cookies like all of those thingsare lumped under it and but it's notlike just one recipe and that's why I'msaying maybe recipe or example it'sbigger than that so I think we're attimeumso I assume people want to go for lunchI see one handsure all rightthat's kind of the guide sectionokay and I think we'll schedule likeanother deep dive on like basically how we how we build long-termcontributors and how we're moreintentional about that because we've hada few ideas but I think we we need tohow much we need like a whole hour juston that one topic to be able to makeprogress so thanks for everybody comingto these two sessions a lot of greatfeedback and discussion, Next-10 Keeping the Project Healthy, OpenJS Foundation, 01h3j5ycb1ehm86bgwc8p8wwhv.