How do you add a contributor to a GitHub repo?

It is a Tuesday morning, and the pull request has been sitting there since Friday. Someone named dev-priya, a developer you have never met, quietly fixed a bug in acme/rocketdb that you kept meaning to get to yourself. Her code is clean. You want to keep her close, and the first instinct is the obvious one: hand her a key to the house.

Handing over that key takes about a minute, as long as you hold admin access to the repository yourself. Open acme/rocketdb on github.com, click the Settings tab across the top, and find Collaborators in the left sidebar. If the project lives inside an organization rather than your own account, that same item reads Collaborators and teams, tucked under the Access group. GitHub, wary of anything that changes who can touch your code, may pause here to ask for your password or a 2FA code. That is normal. Wave it through.

Then click Add people. Type her GitHub username, or her full name, or the email attached to her account, wait for her to appear in the dropdown, and confirm with the button that reads Add dev-priya to this repository. Here is the part everyone forgets: she is not in yet. GitHub emails her an invitation she has to accept, and until she clicks it she sits on your Collaborators list marked Pending, a name in limbo. Those invitations quietly expire after 7 days, so if the week gets away from you, you will simply have to send it again.

A key to the house, though, is a blunt instrument, and whether you can offer anything subtler depends on where the repository lives. On a personal, user-owned repo there is exactly one tier of trust. A collaborator gets write access, meaning she can push commits, open and merge pull requests, and manage most of what the project holds, while you, the owner, stay the only admin. There is no dial to turn. It is nearly all or nothing.

Move the repo into an organization and that single tier fans out into five distinct roles, and this is where you get to be precise. Read is the quiet end: view and clone the code, open issues, leave comments, and little else. Triage sits a step above it, letting someone shepherd issues and pull requests, applying labels, assigning people, closing threads, all without pushing a single line of code. Write is the working role most contributors actually want, adding the power to push commits and merge. Maintain hands over most of the repository's settings while holding back the genuinely destructive actions. And Admin is the whole house, keys and deed together, including secrets, visibility, and the power to delete the repo outright.

The instinct worth keeping through all five is restraint. Reach for the lowest role that still lets a person do the job in front of them. A community moderator herding issues rarely needs more than Triage. A steady contributor like dev-priya rarely needs more than Write. Admin you give to almost no one.

For a while, granting access one person and one repository at a time is perfectly fine. Past a handful of each, it quietly becomes a chore, then a liability, a sprawling list nobody remembers to prune. Organizations answer this with teams, and the shift is worth making early. Instead of adding a person, you create a team, add members to it, and grant the team a role, anywhere from Read through Admin, on one repository or across many at once. Everyone on the team inherits that access, and if you nest teams inside other teams, the children inherit from their parent, so trust flows downhill the way an org chart does. Owners who want a floor under everything can set a base permission that applies to every member across every repo, then layer team and individual grants on top. The lesson is the same as the permission dial: once a project starts to grow, moving it into an organization and leaning on teams beats hand-tending a long collaborator list that slowly drifts out of sync with who actually belongs.

Here is the quiet truth that reframes the whole question: most of the people who will ever improve your project are people you never add at all. The open source world does not run on invitations. It runs on forks. Which is, incidentally, exactly what dev-priya already did before her pull request landed on your Tuesday. She clicked Fork, copied acme/rocketdb into her own account, committed her fix on a branch over there, and opened a pull request back to you. She never had push access. She never appeared on your Collaborators list. She simply proposed, and the decision to review, to ask for changes, and to merge stayed entirely yours.

Once you do merge her work, GitHub records it. She turns up under Insights > Contributors, credited for what she built, and this is where two words that people tangle together finally come apart. A collaborator is someone you granted access to, an invited account holding a permission level. A contributor is someone whose work has actually been merged into the project. One is about permission. The other is about accepted output, and the gap between them is real. You can hold write access to a repo for a year and never merge a single line, which makes you a collaborator and no contributor at all. You can land ten merged pull requests through forks alone, a contributor ten times over who was never once a collaborator. That is why you add a collaborator but you cannot add a contributor. The second word is earned by contributing, and no button on the settings page can grant it.

So you merge dev-priya's pull request, and by Wednesday she is a name on your Insights > Contributors graph, a stranger turned collaborator turned contributor over the course of a single week. That is a satisfying little arc. It is also, if you look up from it, a tiny one. For every developer who forks your repo and opens a pull request, there are many more who watch quietly, try the thing, star it, and never once introduce themselves. The Insights tab shows you contributors, traffic, and forks, but the group that often matters most to an open source maintainer is the one that leaves the faintest trace: your stargazers, the people who found the project worth bookmarking and then went silent.

That silent group is where WarmStars comes in. Point it at a public repo like acme/rocketdb and it takes that quiet list of stargazers and turns it into named people, with their company, their role, and a public email where one exists, so the developers paying real attention to your work stop being anonymous stars and start being someone you can actually understand. It works from public data only, honors do-not-contact requests, and never sends a message on your behalf. Think of it less as outreach and more as finally seeing the room. The contributors and collaborators build the project alongside you, in plain view. The stargazers built the audience, and until now you could not see their faces. The Tuesday pull request was the easy part. The harder, more interesting question is who else has been quietly watching all along.