"Priority Document" outlining areas of greatest need for Node.js ecosystem

[detrohutt]

I'd like to help out in the Node ecosystem in some capacity and I'm wondering if there is a document somewhere that outlines the areas of the ecosystem/codebase/etc where the most help is needed. If this document exists, please direct me to it.

The closest thing I was able to find was Node Todo but it's not ideal for the scenario I'm imagining for a few reasons:

1. It's very generic. It essentially encourages looking through "random" issues (i.e. no organization by area of expertise, etc.).
2. In order to be useful, it relies on people being vigilant about labeling issues.
3. There's no sense of relative level of importance, and I assume even among issues labeled "help wanted" some are more critical than others.
4. It only pertains to the main nodejs/node repo

If a document like I've described doesn't yet exist, here's my case for it and some thoughts and ideas.

Motivation

The reason I raised this issue in this particular repo is because I think this document would mesh really well with the mentorship program for on-boarding people who want to become regular/frequent contributors.

Encouraging specialization

It would allow them to pick an area to specialize in early on. When you're talking about 6 month duration for mentorship and potentially someone with lots of extra free-time, I think specialization can provide a big productivity boost compared to working on random pre-existing issues. I realize the plan is for the mentor and mentee to work together on a goal, but I can imagine certain mentor/mentee pairings where the mentee has a lot more free time to work than the mentor has time to actively provide guidance, so it'd be useful if there were some form of over-arching guidance (like the proposed document) for what to work on when you either can't or don't want to work on the agreed-upon goal on a given day.

Raising awareness of choices

Some people may come with an existing idea of what they want to work on. Others, like myself, are indifferent about what they work on as long as it's both within their skill-level and they have the needed domain-specific knowledge (or none is required). Generally I just want to be a "force multiplier" and work on whatever will be most appreciated and move the ecosystem along the most per unit of effort.

Even for people who have an idea of what they want to work on, and especially for the others, a document like this might alert someone to an area of interest they hadn't thought of. As a specific example, someone may not have thought of helping out with a Working Group, and aren't likely to have that idea looking through issues in the nodejs/node repo.

As an aside on Working Groups: After watching just a few various WG meetings on YouTube, it seems to me there is a high level of need for new members in multiple WGs. Due to the organization of the Contribute page, this isn't made clear in my opinion. Only four words are dedicated to WG participation.

Potential concerns

Upfront effort

This isn't an "all-or-nothing" situation, but more of a "get-out-what-you-put-in" deal. At a minimum this document could be drawn up in 5 minutes by someone with overall knowledge of the ecosystem's needs. It could just start out as something like the top level sections I describe below with a description or link to the current single highest priority item for each section. It could then potentially evolve over time.

Upkeep/maintenance

I don't think this document necessarily needs to entail a lot of maintenance. There wouldn't be much harm in it being out of date, and as areas of need change or are identified, it'd be quick and simple to modify the list. A minute or two spent updating the document could potentially lead to an outpouring of volunteers to help with a specific priority (A way to subscribe to updates may be useful).

Additionally, some portions of the list could potentially be automated. This could be as simple as linking to specific issue searches like Node Todo does.

Document structure

Top level sections

These would be based on types of contributions. For example:

sublists are just for clarification, not necessarily actual sections

• Contribute to Code
  • Add new features
  • Improve existing code
• Contribute to Documentation
  • Update/improve the Node API docs
  • Create/improve "process documents", README files, etc. across all repos
  • Work on translations
• Contribute to Repo Maintenance
  • Triage/label GitHub Issues/PRs
• Contribute Time
  • Become a mentor
  • Join WGs as a member
  • Become an Observer at WG meetings
  • Offer unofficial assistance within the WG/Repo (like an intern or "gopher")

Ranked subsections

Within the top level sections, specific areas of need could be ranked by greatest need (most understaffed, code that's blocking progress, etc.). These need not be comprehensive. At a minimum, just add things to a section as it becomes clear they are high-priority.

Contribute to Code

Areas of the codebase or modules that most need addressing. This could be as simple as a hand-edited list with a "hard-coded" priority level or as sophisticated as an SPA that uses the GitHub API to dynamically adjust this section based on something like aggregate count of labels on issues/PRs: <module-name> && ("High-Priority" || "Critical").

Contribute to Documentation

Both above approaches could potentially be used but hand-edited is probably best. Also it doesn't necessarily need to be super specific like specific documents (although that could be useful). It could just be a list of repo names to denote repos that have sub-par documentation or need help cleaning up or reviewing specific process documents, etc.

Contribute to Repo Maintenance

Probably just a ranked list of repo names. Similar to above, this could be automated using the GitHub API at some point, listing the number of open Issues and open PRs for each repo, although this isn't necessary.

Contribute Time

This section may need to be organized differently from the others and will probably be edited by hand. It may also not necessarily be ranked. Maybe a list of repos, and the types of help currently needed (possibly a matrix)?

Metrics

These things would be useful throughout the document. Most could also make good use of hyperlinks.

• Repo name
• Priority level
  • Low/Medium/High/Critical (or maybe color-coded?)
  • Items that become low priority could also be removed
• Relevant person(s) to contact for more info
• Icon/emoji denotations
  • Specific domain-knowledge required (Note contact person/mentor in table if applicable)
  • Low-hanging fruit (beginner friendly)
  • Recently added/updated

Conclusion

I see this document being especially useful in conjunction with the mentorship program, but it's likely to be useful to new/existing contributors outside the program too (in case it doesn't fit with this program's goals). For instance, I could see such a document being linked to from the Contribute page.

Incidentally, creating this "document" as an SPA may be a cool mentor/mentee(group?) goal and would give mentees a good high-level understanding of the Node.js ecosystem, especially if you had them interact with representatives from some WGs/repos in the ecosystem to get input on their needs. This could include an "Admin" backend to the frontend to make editing the list easier, etc.

That's all the ideas I've got for now. Sorry for such a long post and I appreciate you taking the time to read it. I have no direct experience with contributing to the Node.js ecosystem as of yet so if this whole thing is totally off-base or infeasible for some reason feel free to close this issue. :)

[detrohutt]

@MylesBorins You seem to be involved in a lot of different areas of the Node.js ecosystem so maybe you'd know this.. was there a more appropriate place to raise this issue?

All taken care of.

[Bamieh]

@detrohutt Thanks for writing this up in great detail.

The mentorship program is in need of these "areas" to be identified in order for us to guide mentees on contributions areas of shared interest.

This initiative is bigger than the mentorship's scope since it could be beneficial to the whole node ecosystem. I believe this could be an initiative under the community committee. If you can attend today's meeting hopefully we'll have time to discuss this (the agenda is super full but this is definitely worth discussing).

nodejs/community-committee#300

[detrohutt]

@Bamieh Thanks for taking the time to read it! I'd be more than happy to attend today's meeting. Do I need to be officially invited or added to an Observers list for this meeting (I know that's the process for the Modules WG) or do I just join when the link shows up?

[Bamieh]

@detrohutt you're welcome to join when the link shows up

[detrohutt]

@Bamieh Sorry I missed the commcomm meeting today. I'll be present at the Mentorship WG meeting tomorrow. Also we made some forward progress on the conceptualization of the priority document in the Security WG meeting today. I'll be opening an issue with commcomm about potentially creating a repo for the document where WG's can raise issues for things they want added/modified. Also I'll be opening an issue with the nodejs.org repo to see if they think the website is an appropriate location for the document.

[dshaw]

Ping @codeekage

[Trott]

If it helps at all, here are the stock answers I give when people ask where help is most needed:

• Windows parity. We have a much higher percentage of Windows users than Windows developers on the project, and Windows tends to lag a bit in terms of attention when tests start failing and stuff like that.

• Documentation. Unfortunately, people often think of this as an "easy" thing. I'm not talking about fixing a typo here and adding a sentence there. I'm talking about looking at the docs holistically and making them a joy to use.

• Website UX. There's an effort to redesign the website, but the website would greatly benefit from continuous UX attention.

• Build. Know devops and cloud? Great! The only other thing you need is to earn the trust of the current maintainers of the project. You can do that by contributing elsewhere and/or participating in a non-member capacity on the build repo. This is basically all about making the CI server be vastly more reliable than it currently is.

• Release. This requires even more trust than Build so you have to work up to it, but it's somewhere that we need more people because our current process burns out people quickly if they can't do it for a month and then take two months off or something.

• Automation. Less of a problem than it once was now that there's an automation team, but still, there's lots to be done there.

[Trott]

As far as looking at stuff in Node.js core that needs attention, it's going to vary from person to person but my top three would be: Windows parity (again), crypto, libuv.

It's not that we don't have people working on these things. We do, and they're great. But I find these are the areas that I have the most difficulty getting timely help because the small number of experts in those areas tend to have lots going on.

Going the other direction, a big meta-ish thing someone can help with: Finding a way to make GitHub notifications manageable for all.

[codeekage]

@Trott, could we get volunteers from this small group who are experts to be on the Mentorship Team as mentors?

If we could find a way to develop folks in these areas that need more help and an urgent assistance, which actually gives the Mentorship Team a more focused purpose and also a medium to helping mentees too, then that will be super great.

I will also love if you could drop the links to this repos and probably WG champions to see how we could collaborate and make the ecosystem more Awesome.

[bnb]

Going the other direction, a big meta-ish thing someone can help with: Finding a way to make GitHub notifications manageable for all.

This is a big one for me as well. I'd love to use something like https://github.com/octobox/octobox but the permissions are a blocker for it as far as I know. The next best solution I can think of is either setting up something that prettily displays GitHub email notifications that are forwarded to it or loading the GitHub notifications page and apply custom scripts/styles in an Electron app or something.

[detrohutt]

@Trott Those are great, thank you! I was struggling to get things moving quickly enough to have actionable items ready for the June 1st Mentorship trial run, so these can probably serve as starting points for projects for the "beta testers" to start work on.

If they're already short on time I imagine asking them to mentor people may not be feasible, but I agree with @codeekage that if any of the people knowledgeable in these areas are interested in mentoring, they'd be a great addition/advantage to the initiative.

@bnb I like those ideas. I'd be willing discuss them in more depth in another issue or privately, and possibly try to rough out some initial implementation of something.

[MylesBorins]

Build and release are huge areas that need help as well

…

On Mon, May 21, 2018, 8:37 PM A.J. Roberts ***@***.***> wrote: @Trott <https://github.com/Trott> Those are great, thank you! I was struggling to get things moving quickly enough to have actionable items ready for the June 1st Mentorship trial run, so these can probably serve as starting points for projects for the "beta testers" to start work on. If they're already short on time I imagine asking them to mentor people may not be feasible, but I agree with @codeekage <https://github.com/codeekage> that if any of the people knowledgeable in these areas are interested in mentoring, they'd be a great addition/advantage to the initiative. @bnb <https://github.com/bnb> I like those ideas. I'd be willing discuss them in more depth in another issue or privately, and possibly try to rough out some initial implementation of something. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAecV0kKgFGovw4N9VUXK3DXVhpcRZ6vks5t013egaJpZM4TpwJ9> .

[codeekage]

Taking notes on this... Really hope collaborators from all round the nodejs project could contribute on this.

Have a collection of collaborators as mentors to help with onboarding.

[Trott]

@Trott, could we get volunteers from this small group who are experts to be on the Mentorship Team as mentors?

@codeekage You mean Windows parity, crypto, and libuv? I can't speak for other people's time, but I guess I can leave a ping here: @nodejs/platform-windows @nodejs/crypto @nodejs/libuv

[ankibalyan]

What about debugging, stacktrack, logging in production?

[Trott]

What about debugging, stacktrack, logging in production?

That would be the Diagnostics working group. They used to be very active, but I actually don't know if they still are or not so much anymore. Let's ping and see if there's a "oh my, yes we'd love to mentor a few people to get more activity going here" or not. @nodejs/diagnostics

[mike-kaufman]

RE Diagnostics, we're looking at establishing a list "strategic initiatives", each with a designated "champion" to help organize & drive. See diagnostics/issues/185.

If someone wants to get involved, best thing is to look through issues, find something interesting, and ping on it. Alternatively, attend the working group meetings (generally bi-weekly, but next one will probably be 2018-06-13 due to collab summit), or reach out to me directly & I can help direct.

And, yes, we'd love to have more ppl involved & doing work. :)

[Qard]

Yep, the diag working group is quite active and I'm sure some of us would be quite happy to be mentors. I volunteer myself, at the least.

[bnb]

Going to remove the cc-agenda label for now, since it's been on since May 3rd and has been discussed to some extent. If there's further things that need to be discussed at the CommComm level, please don't hesitate to add it back 🙌

[detrohutt]

@bnb Actually I'd like to have some further discussion on nodejs/community-committee#322 but didn't bother trying to get that added to the agenda since I figured it more or less fell under this issue since it was already on the agenda.

[detrohutt]

@bnb as far as I know, I don't have the ability to add labels to things.

[bnb]

Gotcha. I'll add that issue to the agenda, then 😅

[bnoordhuis]

crypto, and libuv

Sorry, missed the ping. Speaking for myself, I don't have time to extensively mentor others; not beyond what I already do on the bug tracker(s).