{"id":94621,"date":"2026-03-19T11:00:00","date_gmt":"2026-03-19T18:00:00","guid":{"rendered":"https:\/\/github.blog\/?p=94621"},"modified":"2026-03-19T09:26:02","modified_gmt":"2026-03-19T16:26:02","slug":"rethinking-open-source-mentorship-in-the-ai-era","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/maintainers\/rethinking-open-source-mentorship-in-the-ai-era\/","title":{"rendered":"Rethinking open source mentorship in the AI era"},"content":{"rendered":"\n

Let me paint a picture for you.<\/p>\n\n\n\n

A polished pull request lands in your inbox. It looks amazing at first glance, but then you start digging in, and a few things seem off. Forty-five minutes later, you’ve crafted a thoughtful, encouraging response with a few clarifying questions. Who knows: Maybe this person might be a great new person to mentor, so it’s worth your time if they put in theirs.<\/p>\n\n\n\n

And then…nothing. Or the follow-up makes it clear the contributor doesn’t have the context needed to explain the change, often because AI made it easy to submit something plausible before they were ready to maintain it. Or you realize you’ve just spent your afternoon debugging someone’s LLM chat session.<\/p>\n\n\n\n

This is becoming more common. Not because contributors are acting in bad faith, but because it’s never been easier to generate something that looks plausible. The cost to create has dropped. The cost to review hasn’t.<\/p>\n\n\n\n

Open source is experiencing its own “Eternal September<\/a>”: a constant influx of contributions that strains the social systems we rely on to build trust and mentor newcomers.<\/p>\n\n\n\n

The signals have changed<\/h2>\n\n\n\n

Projects across the ecosystem are seeing this same occurrence. tldraw closed their pull requests<\/a>. Fastify shut down their HackerOne program<\/a> after inbound reports became unmanageable at scale.<\/p>\n\n\n\n

The overall volume keeps climbing. The Octoverse 2025 report<\/a> notes that developers merged nearly 45 million pull requests per month in 2025 (up 23% year over year). More pull requests, same maintainer hours.<\/p>\n\n\n\n

The old signals, like clean code, fast turnaround, and handling complexity, used to mean someone had invested time into understanding the codebase. Now AI can help users generate all of that in seconds, so these signals aren’t as telling.<\/p>\n\n\n\n

To reduce noise and bring more trust back into open source contributions, platforms, including GitHub, are building longer-term solutions. In fact, our product team just published an RFC for community feedback<\/a>. If you have thoughts on what we can do, we’d love to hear from you.<\/p>\n\n\n\n

But platform changes take time. And even when they arrive, you’ll still need strategies for figuring out how mentorship looks today when signals aren’t as easy to read. Here’s what’s working.<\/p>\n\n\n\n

Why this is urgent<\/h2>\n\n\n\n

Mentorship is how open source communities scale.<\/strong><\/p>\n\n\n\n

If I asked a room of open source contributors how they got started, they’d all say it began with a good mentor.<\/p>\n\n\n\n

When you mentor someone well, you’re not just adding one contributor. You’re multiplying yourself. They learn to onboard others who do the same. That’s the multiplier effect.<\/p>\n\n\n\n

Year<\/strong><\/th>Broadcast (1,000\/year)<\/strong><\/th>Mentorship (2 every 6 months, they do the same)<\/strong><\/th><\/tr><\/thead>
1<\/td>1,000<\/td>9<\/td><\/tr>
3<\/td>3,000<\/td>729<\/td><\/tr>
5<\/td>5,000<\/td>59,049<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

But maintainers are burning out trying to mentor everyone who sends a pull request. If we lose mentoring newcomers, we lose the multiplier entirely.<\/p>\n\n\n\n

We can’t abandon mentorship, especially as many long-time maintainers step back from active contribution. (I wrote more about this generational challenge in Who will maintain the future?<\/a><\/em>) So, we need to be strategic about who we invest in.<\/p>\n\n\n\n

The 3 Cs: A framework for strategic mentorship at scale<\/h2>\n\n\n\n

So how do you decide where to invest your mentorship energy when contribution signals are harder to read? Looking at what’s working across projects, I see three filters maintainers are using. I call them the 3 Cs<\/strong>: Comprehension, Context, and Continuity.<\/p>\n\n\n\n

1. Comprehension<\/h3>\n\n\n\n

Do they understand the problem well enough to propose this change?<\/em><\/p>\n\n\n\n

Some projects now test comprehension before code is submitted. Codex and Gemini CLI, for example, both recently added guidelines: contributors must open an issue and get approval before submitting a pull request. The comprehension check happens in that conversation.<\/p>\n\n\n\n

I’m also seeing in-person code sprints and hackathons thriving in this area, where maintainers can have real-time conversations with potential contributors to check both interest and comprehension.<\/p>\n\n\n\n

I’m not expecting contributors to understand the whole project. That’s unrealistic. But you want to make sure they’re not committing code above their own comprehension level. As they grow, they can always take on more.<\/p>\n\n\n\n

2. Context<\/h3>\n\n\n\n

Do they give me what I need to review this well?<\/em><\/p>\n\n\n\n

Comprehension is about their understanding. Context is about your ability to do your job as a reviewer.<\/p>\n\n\n\n

Did they link to the issue? Explain trade-offs? Disclose AI use?<\/p>\n\n\n\n

The last one is becoming more common. ROOST<\/a> has a simple three-principle policy. The Processing Foundation added a checkbox. Fedora<\/a> landed a lightweight disclosure policy after months of discussion.<\/p>\n\n\n\n

Disclosing AI is about giving reviewers context. When I know a pull request was AI-assisted, I can calibrate my review. This might mean asking more clarifying questions or focusing on whether the contributor understands the trade-offs, not just whether the code runs.<\/p>\n\n\n\n

There’s also AGENTS.md<\/code><\/strong>, which provides instructions for AI coding agents, like robots.txt for Copilot. Projects like scikit-learn<\/a>, Goose<\/a>, and Processing<\/a> use AGENTS.md<\/code> to tell agents instructions, like follow our guidelines, check if an issue is assigned, or respect our norms. This can help to place the burden of gathering the context needed for a review to the contributor (or their tools).<\/p>\n\n\n\n

3. Continuity<\/h3>\n\n\n\n

Do they keep coming back?<\/em><\/p>\n\n\n\n

This is the mentorship filter.<\/p>\n\n\n\n

Drive-by contributions can be helpful but limit your mentorship investment to people who come back and engage thoughtfully.<\/p>\n\n\n\n

Your mentorship can scale up over time:<\/p>\n\n\n\n