Solving the problem of not knowing what to do in the project

[ErickWendel]

Problem

Today @ruyadorno and I had a session on https://github.com/nodejs/tooling/issues/164 and we've spoken about a situation that has been happening all over the Node.js project and WGs.

I saw some posts of people about they don't know how to keep contributing to the project or how to contribute even more:

"I want to contribute to Node.js more, but I can’t find a good issue to start with. Is there anybody feeling the same? Would any of the Node.js contributors want to give me a hand?" - Link

"I feel the same. Every issue is too hard or not enough interesting" - Link

or even @Ethan-Arrowood who has been active for a long time said:

"I’d really like to improve my C++ skills enough to make more lower level contributions to @nodejs. Does anyone have tips for me? I’ve tried diving head first into Node source, but I always wind up getting lost and confused lol. Maybe some resources folks regularly use?" - Link

I feel the same way. I usually go weekly through issues, PRs, and docs trying to go grab something to do but sometimes I don't find anything that I'd be able to work on and get a bit frustrated.

Solution

I know that a lot of Node.js collaborators have some ideas of implementing Proof of Concepts, adding ideas, or coding new modules but they don't find time to implement it themselves, and those ideas get lost in time.

If they document it and let other people implement the ideas would make people more willing to keep working on those things and we still improve the project faster.

Starting on @nodejs/tooling, I think if we had a Todo list every month about What people would implement or contribute on (not only the first-good-issue ones) would help new people to get involved and for people like me that have been working in the project for a while keep contributing with a goal in mind.

In the end, the monthly call we have in the WGs would focus not only on reviewing what's blocked in the project but also to review those monthly tasks and congratulate new contributions so people keep motivated to deliver valuable things.

I know that it seems like a lot of effort however my idea is to start small, let's say 5-10 tasks monthly and we monitor how people start interacting with it.

WDYT?

[khaosdoctor]

I find this extremely helpful, and I'm willing to be a part of this effort. Not only to help organize it but also do the tasks and help improve the project.

I find myself in the same situation, I'm a long time contributor but I used to contribute more to translation and docs, now I wanted to expand a bit and dive more into features and got quite lost, especially after a long time away.

@ruyadorno @ErickWendel you can definitely count (and contact) me for this

[Trott]

I wish this all the success imaginable. Here are the pitfalls that often don't get discussed:

• Is having 100 more contributors good for Node.js? Or does that primarily create a ton of maintenance overhead for the maintainers with minimal or no ROI for end users?
• Do we need to distinguish between "people who say they want to contribute" and "people who have the time and will want to put in the necessary effort"? (Why or why not?)
• The thing that doomed the mentorship program was hundreds of applicants for every willing mentor. For this to work, it probably has to be done in a way that minimizes the need for investment on the end of existing collaborators.
• I mentor some folks privately, but it's a very small number of people and I select them. If that's the model, how does it scale?
• What is the most important of the many possible goals? Is it to get more skilled contributors? To get more issues closed? To get more features developed? To help people level up their skills in general? To give people a good feeling about Node.js? Is it a failure if someone does one small contribution and never comes back? If so, why? If not, why not?

Not trying nay-say as much as make the pitfalls clear. These conversations tend to generate a ton of enthusiasm from people who aren't long-time contributors to the project. The contributors will sometimes respond enthusiastically and then have a 90% attrition rate within weeks (which is what happened with mentorship, at least in my opinion/recollection). I'm trying to answer "Why is that?" above and offer things to think about that might change that.

I sincerely want to encourage this kind of initiative. For it to be successful, it needs to be designed with these things in mind (in my opinion).

[Trott]

One thing I recommend is make sure there's a step early on where the person wishing to contribute can explain clearly what their existing strengths are and/or what elements of Node.js they want to contribute to. A lot of people "want to contribute" but then can't specify what they're interest in. Security? OS-level internals? Web features? Cryptography? Test reliability? Documentation? Node.js is sprawling and "wanting to contribute to Node.js" is not sufficiently actionable.

Even better if you can figure out a sort of decision tree so that people who don't know what they are interested in might be able to figure it out. Like, maybe they are interested and/or expert in something specific but don't know the Node.js-specific terminology to be able to articulate it.

[khaosdoctor]

One thing I recommend is make sure there's a step early on where the person wishing to contribute can explain clearly what their existing strengths are and/or what elements of Node.js they want to contribute to. A lot of people "want to contribute" but then can't specify what they're interest in. Security? OS-level internals? Web features? Cryptography? Test reliability? Documentation? Node.js is sprawling and "wanting to contribute to Node.js" is not sufficiently actionable.

Even better if you can figure out a sort of decision tree so that people who don't know what they are interested in might be able to figure it out. Like, maybe they are interested and/or expert in something specific but don't know the Node.js-specific terminology to be able to articulate it.

Nice comments @Trott! I think you're right. My thinking on this can be explained by using myself as an example. I like Node a lot, I love JavaScript and I really want to contribute to the language and runtime that gave me so much, but I fall into the second part of your comment, I don't know where to contribute, and the repository doesn't state clearly what are the possible ways of contributing. I think if we had a single place where people could look to contribute (a contributing repository, perhaps? Or like @ErickWendel said a simple to-do list) where its README would essentially be an awesome list of issues grouped by tag and repo in a first glimpse.

Iterations on that could be that we added new tags for difficulty, the time required, effort, and so on, so we can better label the errors and automate the process in the future. Starting with a sub-repository of the whole organization first and expanding it further.

[khaosdoctor]

Now on the first comment, I'll try to give my impressions on the questions:

• Is having 100 more contributors good for Node.js? Or does that primarily create a ton of maintenance overhead for the maintainers with minimal or no ROI for end users?

I'd say that the idea is to have people working on ongoing initiatives that would NOT get in the way of current efforts. This way, everyone could work together and make the ecosystem better. Like, if we have a significant initiative that doesn't require more contributors, we can say, "Hey, thanks, but this issue is already taken care of" the same goes otherwise, where we could label issues that would need more help with such tags and encourage people to work on them

• Do we need to distinguish between "people who say they want to contribute" and "people who have the time and will want to put in the necessary effort"? (Why or why not?)

I think the measure of contribution is the contribution itself. The person shouldn't need to say, "Hey, I want to contribute." They can just contribute, then add a comment and a draft PR for what they're trying to accomplish. Also, facilitating contact with the maintainers asynchronously could also improve the experience (but would create overhead for maintainers).

If there are people who have spare time and will put necessary effort, they will show this quality ASAP because of the number of contributions they made.

• The thing that doomed the mentorship program was hundreds of applicants for every willing mentor. For this to work, it probably has to be done to minimize the need for investment on the end of existing collaborators.

I don't think current collaborators need to be actively involved. They'll be there, of course, but I don't think we need an active response from every collaborator in every collaboration other than PR reviews and stuff like that (I may be wrong)

• I mentor some folks privately, but it's a very small number of people and I select them. If that's the model, how does it scale?

I don't think we should privately mentor anyone; this would create a considerable overhead on collaborators. It's probably better to collaborate async using only GitHub as a platform

• What is the most important of the many possible goals? Is it to get more skilled contributors? To get more issues closed? To get more features developed? To help people level up their skills in general? To give people a good feeling about Node.js?

I'd say from my POV that we get more issues/features developed and help people to understand the runtime, either by leveling up their skills in general, which would create more skilled contributors, but we can't decide for them, so the objective needs to be something related to the project itself, so I think it's better to focus on the issues and features. The rest will be a side effect

• Is it a failure if someone does one small contribution and never comes back? If so, why? If not, why not?

I wouldn't say so. The objective is to facilitate for new and existing contributors to find and contribute to the issues, but not to keep them as long-time members, it's going to be amazing if they do, but for that, we need first to provide a good collaboration platform where people will feel that they belong and want to stay