What is collaborator at npm


(Daijiro Wachi) #1

In order to grow as a community, more people are needed to actually work on the core for improvements because the core size of npm is increasing rapidly and it makes maintenance difficult as like we know the number of reported issues from users on GitHub.

Therefore, a kind of group is necessary to attract active OSS developers which can be a great motivation for continuing to contribute and that’s what I am looking for. That was kind of “collaborators” defined at CONTRIBUTING.md, but it was only about issue handling and even the issue page moved to here from GitHub.

I am pleased if we can discuss the possibility of collaborators in this community here.


Interactive tool to manage audit findings - npm audit resolve
(Kat Marchán) #2

Can you tell me about what kinds of responsibilities/privileges you would like to see from a “collaborator” position? One reason why we haven’t gotten around to giving the commit bit to most people is that, right now, it’s a relatively small step from what contributors can already do: the core CLI team itself puts all our changes through the PR process, and beyond that, the big thing I can think of is that we’re the ones with the actual final commit bit and ability to publish new npm CLI versions.

We’re pretty open to talking more about what a more involved collaborator looks like on the CLI. The last time I talked with @iarna about it, we were waiting for the migration to npm.community to be done, so we could start leaning on the trust level and badge system of this space to help find higher-privilege collaborators. This space also gives us way more leeway in granting piecemeal privileges to various people, instead of giving full write access to, say, someone who’s only around for triage, or only around for support. I think we can definitely have some more tiers/categories of collaborator for sure.

To this day, I think it continues to be important that the core (full-time, salaried) maintainers of the CLI have a certain amount of standing when it comes to decision-making and product stuff. We’re an open source project, though, and I think it’s high time we integrate our development process with the community a bit more, even though we’ve had over 600 collaborators send us patches, some with a certain amount of regularity. One thing that has stopped me -personally- is that I’m uncomfortable dumping a timesink of responsibility on someone who is not being paid for the labor they do for us. That’s more of an ethical thing on my end, so I might lobby for “full collaborator” status to only be grantable to folks who are being paid for their time either by npm, Inc itself, or by a third party who’s offered reserved time for this work. It’s a lot. Please don’t do it for free.

Finally, I think we should talk about a system of grandparenting in collaborators who have already been participating regularly in the npm community and the CLI’s development, like @KenanY, @legodude17, and you, @watilde. I think it’s high time we recognize your contributions a bit more than we already have.

So, what do you think? What are you looking for? What do you think would work best for the community and the project?


(Daijiro Wachi) #3

That is true. Collaborator is actually not necessary in term of just the steps to ship codes if the core team is very active, and the CLI team is actually working hard on it. That can be said in the other community as well. However, despite not making a big difference as a process, I’m thinking that the following two are making a difference:

  • New mindset
  • Scaling by a virtuous cycle

Mindset is about how people can think of a product as their own thing or something special in a life. Once people get this scene, they take over leadership and contribute more actively as like a part of their daily routine.

Once people are on-boarded, they can get a sense of how a community looks like from inside and that can make improvements in the onboarding process and the mindsets. These make scaling of the community. More people join, more improvements happen based on the mindsets which can be something like a philosophy or a culture.

I wrote about how collaborator role could help to grow as the community based on the culture in the above. I’d also like to mention what benefits collaborators can get from free contributions which are mentioned by Kat in the last comment. Personally, as an OSS developer, I really do not care about pay at all, but that is the thing why the role would be a great motivation to contributors. Being an official collaborator helps people’s career because that shows how much leadership they took before in a certain part of an OSS product. It’s true that it’s same with git log --grep, but actually what it makes difference is a big convincing.

Therefore, what collaborators potentially can work efficiently comparing to the full-time team are:

  • Have the same mindset
  • Help people to join this community
  • Take leadership in discussions
  • Make patch
  • Make a better on-boarding process

It does not require release permission, but quick response & feedback on pull requests and issues are very important for the new contributors and a permission to put a label for issues/pull requests would be needed for that. Once this process becomes stable, merge permission on small patches would also work well.

I hope this helps the CLI team to focus on important decision making with stakeholders to continue their business which is necessary for a community.


(Kat Marchán) #4

I’ve started working on a new contributor structure RFC. So far, I’ve only started to lay out the core goals, constraints, and values that we’re shooting for. Please take a look and share any feedback that you have so far. I wanna get this right.

There is intentionally nothing specific yet about organizational structure. I will be working on that in the coming days/week once we know what our shared goals and values are, since they’ll necessarily inform any concrete decisions we make.

Thanks again for bringing this up. I’m glad we’re finally getting around to it!


(Daijiro Wachi) #5

I just read @zkat 's RFC doc and that looks great! It starts with motivation. It’s very sorted already :smiley:

About the big-picture around a structure, decision-making processes and a governance will not be quite changed technically. I think we could take mostly from the current rule, but what we are missing there are processes of nomination and on-boarding which includes basic rules and mindsets. Technical on-boarding documents could be like this size, but apparently, collaborators do not need to merge and ship patches to the codebase. What collaborators should focus on instead is to make a place to promote more contributors and that’s about helping people who are interested in npm development. We have how and what for each role in CONTRIBUTING.md, and we probably can add why to there to describe the purpose of collaborators.


(Kat Marchán) #6

I have another draft I’m floating around internally that has a much more detailed, new structure around specific roles. It’s a pretty fundamental change to how we handle the open source side of npm, and I’ll put it up publicly as soon as I get some internal :+1: for it.


(Daijiro Wachi) #7

80 days passed and we could not make this happen yet. Let me try to push this forward.

Could I ask you how I can support you to finish the RFC together? @zkat


(Kat Marchán) #8

You’ll have to wait a while longer, unfortunately. :\


(Frédéric Harper) #9

A quick follow-up about this. I just joined npm and it’s on my must of things I want to finalize and share with the community. The “bad” news is that since I just started, give me about 1 month before jumping into it.