The Node.js project is a sprawling community effort that spans 162 repositories in the Node.js GitHub organization, excluding the Express and libuv GitHub organizations (which are both projects under the Node.js Foundation).
The Node.js project itself has a variety of needs around everything from build infrastructure to automation tooling, to localization of its documentation.
I've gone ahead and put together an in-depth list of everything the project could use help with in hopes of connecting the dev.to community with the Node.js project.
If you do end up contributing, it would be incredible to see your contributions logged back here on dev.to – be that through your own posts, through comments on this one, or by helping others in the community to contribute! ❤️
Node.js has its own set of acronyms that I'm familiar with and will use for shorthand, but y'all may not yet be familiar with. Here's a quick primer:
- TSC: The Node.js Technical Steering Committee, a top-level committee in the Node.js Foundation tasked with technical stewardship of the project as a whole.
- CommComm: The Node.js Community Committee, a top-level committee in the Node.js Foundation tasked with outward facing work and community relations.
- WG: Working Group, a group with independent governance and ownership of a specific task or domain.
- Initiative and Team: These are groups that aren't independently chartered but have some form of ownership over a task or domain. Initiative is used in the CommComm and TSC, while Team is only used by the TSC.
Core: Effectively the
Governance: Node.js leans very heavily on open governance. The project itself has a
GOVERNANCE.mdthat dictates how the project is governed, but there are additional
GOVERNANCE.mdfiles throughout the GitHub organization for different groups – like the CommComm – which have independent governance.
It's also worth noting that Node.js follows a global Code of Conduct, so if you are interested in participating be sure to give it a read.
- The Node.js Foundation is governed by a board consisting of corporate members, an Individual Membership Director, a TSC Director, and a CommComm Director. In total, 5 committees within the Foundation – the TSC, the CommComm, the Legal Committee, the Marketing Committee and the Finance Committee.
- As an open-source contributor this probably won't matter to you, but it's always good to be informed with context rather than lack it 👍
- Working Groups are a concept under the TSC but not the Community Committee. They have formal, independent charters just like the TSC and CommComm. Initiatives and Teams are concepts in both the TSC and CommComm, and are almost identical to Working Groups in practice, with the critical difference of not being independently chartered.
There are various parts of the Node.js project that have fewer contributors than they need and are always looking for additional contributors.
Here are a few WGs/Initiatives/Teams that you could make a significant impact in today:
- Newer team, mostly started by IBM folk, which is taking on helping out with the maintenance of deeply embedded ecosystem modules that aren't well maintained.
i18n – Internationalization
- The i18n team is working on spinning up the process and content for a fully localized Node.js. This process includes translating everything from documentation to guides to error messages, all using a rather simple combination of GitHub automation and CrowdIn. If you know multiple languages and would like to help localizes content or would like to help set up the automation, this is an excellent way to help out people around the globe.
- There's an automation team that focuses on building out and improving existing automation for the project. As a whole, there is a plethora of work currently done by humans that can be automated in Node.js. Building that out is one of the ways you can be most impactful.
- citgm (Canary in the Gold Mine) is a tool Node.js core uses for testing if a build of Node.js breaks the ecosystem. As we rapidly approach 900k modules, it's impossible to test everything, but we can test some of the world's most used modules to get a more holistic picture.
- Few contributors and a lot of flaky checks that could be fixed or improved with some love and attention.
- The Benchmarking WG helps ensure that there aren't significant regressions in Node.js over time. In a few instances, they've spotted massive regressions that were able to be swiftly identified and patched before impacting anyone.
- There are currently just a few active contributors who are doing this work, and they could use your help to continue building out benchmarks and adopting existing ones.
- This team works on benchmarking for Node.js, if you're interested in seeing what the actual benchmarks are like.
- Works on backporting changes to older versions of Node.js (LTS versions) and shipping new releases.
- We've had a severe drought of releasers – for at least a year there was only one. Releasing is far too much work for a single individual to handle, let alone a team of 5. Great way to get technical and involved while making a tremendous difference.
- Generally to become a releaser you'll want to be able to participate heavily in Node.js as a part of your full-time role – very few people can make this happen.
- The Community Committee spans a bunch of different work and is open to starting up more (and needs champions for some of its current initiatives!)
- One of the key initiatives under the CommComm is the Mentorship Initiative. If you're explicitly interested in long-term, sustained mentorship (or being a mentor!) it's worth checking out 🙌
- If you're interested in participating in the Community Committee, please reach out to me so I can help get you on the path to it.
- Upcoming: Website Redesign and i18n
- Website Redesign is a long-term project that's approaching the technical implementation phase.
One of the most significant parts of contributing to Node.js is it's self-driven and voluntary. You can take on basically whatever work you want to and get it landed if there aren't objections. Objections usually aren't hard -1s, but instead requests for changes of various sizes.
There are various areas within the Node.js project that content is needed.
Enhancing documentation is always needed. Many areas don't have code examples or well-documented API surface area. "It's for contributors, not users" is something I've heard a lot, and it's something we should change.
Once the Website Redesign Initiative finishes up, I think there's going to be a lot more room for work on improving the technical documentation + automating checks around it.
The docs live inside of nodejs/node in the
/doc/api directory – this means that any contributions you make will be directly to
nodejs/node. Docs contributions are a fantastic way to get started with contributing to Node.js in general, as they introduce you to both how Node.js Core PRs work and help out everyone who's trying to use Node.js.
Guides are a new concept that the Website Redesign Initiative is working on. There've been discussions (which I've been a heavy participant in) around including guides that aren't required to be vendor agnostic. Real world developers use vendors and tools – AWS, Azure, GCP, Sentry, Gatsby, Electron, npm, yarn, Snyk, Greenkeeper, and so much more.
Shunning that reality to be entirely agnostic is an approach, but in the end it ends up hurting users rather than helping them. Welcoming contributions that center on these topics is helpful to end users trying to deploy Node.js applications with real-world use cases.
As such, there is an open call for this kind of content which will be launched with the new website and further built out as the site rolls out. The Website Redesign Initiative is maintaining a lengthy list of wanted guides, categorized by the type of developer who would be interested in reading them.
The Node.js Collection is a Medium publication maintained by the Node.js Collection team under the Community Committee and the Node.js Foundation.
The intent behind the creation of the Node.js Collection two years ago was to be a central community resource for content around Node.js. It's definitely met that mark, with virtually all of the blog posts coming from various community members. It's open to quality content on any topics around Node.js – we'd love to work with you!
There are a variety of needs around Automation in the Node.js project. I personally often feel that the current workload is more important than improving automation, which leads to that workload continually growing with more process being introduced to try to alleviate it.
A few examples of work that is needed and can be automated:
- Commit Queue for landing PRs
- Automated Releases
- Auto-healing CI
- Cryptography compliance checking automation (U.S. export control)
- Markdown style checks
- Security Vulnerability linting + checking + merging for the Security WG
There's not a central list of what needs to be automated, but there are at least a dozen more enhancements through automation that can be made if that's something you're interested in.
If you're interested in taking one of these on or want to suggest a different form of automation, you can take a peek at the nodejs/automation repo. In this repo, you can feel free to open issues suggesting automation tooling or offering to help build it out!
If you're interested in contributing to Node.js in any of the ways I've described, you should jump right in! Node.js as a project is extremely focused around getting work done, so showing up and doing the work is awesome – I don't know of many cases where work has not been accepted and appreciated.
If you do have questions, I'm 100% happy to answer them! If you're curious where your skill set would fit in (believe me, there's a place for you to contribute to Node.js no matter your skillset) or want to know more about a specific area, don't hesitate to ask here in the comments or on Twitter. More than happy to do whatever I can to help get you ramped up and contributing ❤️