Skip to content
This repository was archived by the owner on Feb 26, 2022. It is now read-only.
This repository was archived by the owner on Feb 26, 2022. It is now read-only.

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

@detrohutt

Description

@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. :)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions