Proposal + Brainstorm: Mentor Pool + GitHub Action Auto-Assignment (Issues + optional PR Reviews)

[DonnieBLT]

Supporting contributors effectively is one of the most important parts of building a healthy open-source community. As more people get involved, ensuring that each contributor has access to timely guidance can become challenging. To address this, we’re exploring a mentor pool system that distributes mentorship more evenly while still encouraging meaningful mentor–contributor relationships.

This post is a request for ideas and feedback—especially around the workflow, fairness, edge cases, and how we should implement it in our GitHub Action.

---

Why a Mentor Pool?

In many open-source programs, contributors often need help:

• getting started with issues,
• understanding project expectations,
• receiving feedback and review guidance.

When mentorship responsibilities fall on a small group of maintainers, it can quickly become overwhelming.

A mentor pool approach helps balance this workload while ensuring contributors still receive the support they need.

---

How the Mentor Pool Might Work (Initial Idea)

For Issues

When a contributor picks up an issue (or when an issue is labeled as “needs mentor”), the system automatically assigns a mentor from a shared pool using a round-robin approach.

Benefits:

• Balanced workload: mentorship is spread across the pool
• Faster support: less waiting for feedback
• Consistent experience: every contributor has access to guidance

For PRs (Optional / Future)

We’re also considering whether mentors should be auto-assigned to:

• review PRs from new contributors,
• provide guidance rather than strict “maintainer review,”
• act as a first reviewer before maintainer approval.

This could be implemented either as:

• assigning a mentor as a reviewer, or
• leaving a structured comment tagging a mentor, or
• applying a label + auto-requesting mentor review.

---

What We Need Input On (Questions)

1) Who counts as a “mentor”?

• Should mentors be GitHub team members, a YAML list in the repo, or opt-in via issue/PR comments?
• Should we support multiple “mentor groups” (e.g., frontend, backend, docs)?

2) When should a mentor be assigned?

Pick the trigger(s) you think are best:

• When an issue gets a label like needs-mentor
• When an issue is assigned to a contributor (first-time contributor especially)
• When someone comments something like /claim or /assign-me
• Only when the contributor explicitly asks for mentorship (/mentor)

3) Round-robin vs other assignment strategies

Round-robin is simple, but we want ideas:

• Round-robin across all mentors
• Weighted rotation (mentors set capacity: 1–5)
• Availability-based (mentor can set “active/inactive”)
• Skill/tag matching (mentor specialties mapped to labels)
• Timezone-friendly matching (if we collect timezone info)

4) How do we avoid mentor overload / burnout?

• Should mentors be able to “pause” themselves?
• Should we cap active mentees per mentor?
• Should we auto-skip mentors with too many open assignments?
• What should happen if nobody is available?

5) What should the GitHub Action do exactly?

For Issues:

• Assign the mentor directly?
• Add them as an assignee or mention them in a comment?
• Apply a label like mentor-assigned?
• Post a welcome + next steps comment template?

For PRs:

• Add mentor as a requested reviewer?
• Tag mentor in a comment and apply needs-mentor-review?
• Only do PR mentor assignment if the PR is linked to a mentored issue?

6) Visibility and transparency

• Should we log assignments in a pinned issue or discussion?
• Should mentors be able to “handoff” a mentee to another mentor?
• Should reassignment be automatic after X days of inactivity?

7) Edge cases we should plan for

• Mentor is OOO / unresponsive
• Contributor unassigns themselves / issue becomes stale
• Multiple contributors want the same issue
• Mentors are maintainers (should we treat them differently?)
• Security-sensitive issues (should not auto-assign?)

---

Suggested Data Model (for discussion)

We’re considering keeping mentor pool configuration in-repo, for example:

• .github/mentors.yml with GitHub usernames
• optional metadata: specialties, capacity, active/inactive, timezone
• action persists

[aryanghai12]

​1) Who counts as a “mentor”?
Honestly, keeping a .github/mentors.yml file is the way to go. It keeps things version-controlled and super easy to update via standard PRs.
We definitely need mentor groups (frontend, backend, etc.) so we aren't pairing a Go/Docker backend dev with a UI issue. Also, mentors should strictly be active, heavy contributors to the project—not just anyone who volunteers.

​2) When should a mentor be assigned?
Let's keep it trigger-based so we aren't spamming people. Two scenarios make the most sense:
​If a tough issue has a needs-mentor label, auto-assign a mentor the second a contributor picks it up.
​For normal issues, let the contributor just drop a /mentor comment if they feel stuck.

​3) Round-robin vs other assignment strategies
Round-robin is definitely my vote—it's simple and robust.
To make it even better, we could do a capacity-aware round-robin. The bot just checks the next person in line; if their mentee slots are full, it skips to the next. Skill-matching sounds cool but usually turns into a huge headache to maintain in fast-moving repos.

​4) How do we avoid mentor overload / burnout?
Open-source burnout is real, so mentors absolutely need a way to pause. We can let them toggle active: false in the YAML or just use a /mentor-pause command.
We also need a hard cap on active mentees (like max 3). If everyone is full, the bot can just drop a polite comment saying, "All mentors are currently at capacity, please drop your questions in the main discussion!"

​5) What should the GitHub Action do exactly?
If a mentor is in the YAML and under their mentee limit, they’ve already opted in. No need to ask them—just assign them.
​Issues: Auto-assign the mentor, slap a mentor-assigned label on it, and have the bot drop a quick "Welcome" comment tagging both of them.
​PRs: If the PR is linked to a mentored issue, just auto-add the mentor as a requested reviewer.

​6) Visibility and transparency
​Logs: Let's not clutter a pinned issue. We can just filter GitHub issues by the mentor-assigned label to see what's active.
​Handoffs: A must-have. If a mentor gets slammed with work, a simple /handoff command to throw the issue back into the queue would be a lifesaver.
​Stale stuff: If an issue is dead for 14 days, auto-unassign the mentor to free up their slot.

​7) Edge cases we should plan for
​Ghosting: If a mentor goes MIA, let the contributor drop a /rematch comment to get someone else.
​Contributor drops off: If the issue goes stale or they unassign themselves, instantly remove the mentor so their capacity opens back up.
​Security stuff: Hard pass on auto-assigning these. Anything labeled security should bypass the queue and go straight to core maintainers.

[dev-sanidhya]

I think the mentor pool and auto-assignment idea is a solid direction overall. Distributing mentorship through a pool and using something like round-robin or capacity-aware assignment makes sense for scaling the community and preventing mentor overload.

One thing that might be worth considering, however, is the transition from the earlier process.

Previously, contributors were encouraged to actively find mentors themselves by reaching out, discussing ideas, and building mentor–mentee relationships. Many contributors invested real effort into engaging with the community in this way. With the shift to an auto-assignment model, those contributors may feel that the effort they put into building those relationships no longer carries any weight.

A possible middle ground could be a hybrid approach:

• Default behavior: mentors are assigned automatically from the mentor pool (round-robin / capacity-aware).
• Exception: if a contributor has already connected with a mentor who is part of the mentor pool and both sides are comfortable continuing that mentorship, that pairing could be honored for the GSoC cycle.

This way the system still benefits from automation and balanced mentor workload, while also respecting the initiative contributors showed under the earlier guidance.

From a community perspective, acknowledging those early mentor–mentee relationships can also encourage contributors to proactively engage with mentors and the project rather than waiting passively for assignments. Preserving that incentive might help maintain the collaborative spirit that many open-source communities value.

In short, auto-assignment can remain the default, but an opt-in mentor pairing mechanism could allow existing collaborations to continue when appropriate.

Curious to hear what others think about supporting something like a “preferred mentor pairing” before the auto-assignment step.

[ojaswa072]

Skill/tag matching seems really useful — like if an issue is related to Cloudflare Workers or backend, it'd make more sense to assign a mentor who knows that area rather than just round-robin. Also weighted rotation sounds good so active mentors don't get overloaded.

[arnavkirti]

A few ideas from my side:

1. Mentor definition and groups

   • Keeping a .github/mentors.yml file in-repo sounds good to me as well, especially with metadata like specialties, capacity, active, and timezone so the Action can make smarter decisions over time.
   • I’d also lean towards explicit mentor groups (e.g. frontend, backend, infra, docs) so that we avoid mismatches and can later plug in simple label → group routing instead of full-blown complex skill-matching.

2. Triggers and contributor agency

   • I like a hybrid trigger model:
     • label-based (needs-mentor) for “hard” or security-adjacent issues where we know guidance is important, and
     • comment-based (/mentor) so contributors can explicitly opt in when they feel stuck.
   • This keeps the system from being too noisy while still making mentorship easy to request when needed.

3. Assignment strategy

   • Capacity-aware round-robin feels like a good default: go in order, skip mentors who are inactive or at capacity, and fall back to a generic “ask in discussion” message if nobody is available.
   • If we already have specialties and groups in the YAML, we could do a “round-robin within group” approach instead of global round-robin (e.g. for a backend-labeled issue, only rotate among backend mentors).

4. Avoiding overload and burnout

   • +1 to letting mentors pause themselves via YAML (active: false) or a /mentor-pause command, and to a hard cap on concurrent mentees.
   • It might also help to have an automatic “cooldown”: if a mentor has X active mentees, they’re temporarily skipped even if they’re technically under their absolute max, just so load doesn’t spike for one person.

5. Preserving existing mentor–mentee relationships

   • I really like the idea mentioned above about honoring existing pairings for this GSoC cycle.
   • Maybe the YAML could support an optional preferred_mentees or we could have a /lock-mentor @username command that tells the Action to keep that pairing for issues/PRs related to a specific proposal.

6. GitHub Action behavior (concrete flow)

   • For issues:
     • Trigger on needs-mentor or /mentor.
     • Pick a mentor using capacity-aware round-robin within the right group.
     • Assign them, add a mentor-assigned label, and drop a short “welcome + next steps” comment tagging both mentor and contributor.
   • For PRs:
     • Only auto-assign if the PR is linked to a mentored issue, and only as a guidance reviewer (not replacing maintainer review).

7. Edge cases and reassignments

   • A /handoff command for mentors and a /rematch command for contributors both sound useful so people aren’t “stuck” if something changes.
   • For stale issues, auto-unassigning after N days and freeing capacity makes sense, as long as the bot leaves a small note explaining what happened.

Overall, I’m strongly in favor of the mentor pool + Action approach, especially if we keep:

• contributor agency (/mentor, honoring existing pairings),
• mentor safety valves (pause, caps, handoff), and
• a simple but extensible config model in .github/mentors.yml.

Happy to help iterate on the YAML schema or action logic if we decide to move forward with this.

[SatishKumar620]

I'm applying for GSoC 2026 with OWASP BLT and would love if someone could mentor me through the proposal process 🙏

[Pritz395]

1.Mentors can be anyone elected to be mentors by the lead maintainer DonnieBLT, since he’s the most familiar with each contributor’s history with BLT, how they work, and where their expertise lies. That way mentors are people who actually understand the project and the contributors.

2.Labels + requests could work well. For example a needs-mentor label or commands like /mentor or /claim. Before assigning, the system should first ask the mentor if their schedule is clear enough to take up the issue/PR and see it through end-to-end (start → PR submission). The mentee should also clearly state how long they expect to need help for (a day, a week, longer, etc.). Mentors could earn BACON based on the time and effort spent mentoring the issue/PR.

3.Availability + weighted rotation could work well so mentors with more capacity or experience can take slightly more, while still balancing the workload.

4.Mentors should only commit if they can actually fulfill the mentorship. Pausing midway or dropping the ball suddenly hurts development speed and quality — not just for the mentee but also for the organization’s weekly/monthly/yearly goals.

5.For the GitHub Action, I think it should detect when mentorship is requested (label or command), pick a mentor from the pool based on availability/weight, ask them to confirm they can take it, and then assign them once confirmed. It could also add something like a mentor-assigned label and leave a structured comment outlining expectations and the estimated mentorship duration.

For PRs, if the PR is linked to a mentored issue, the mentor could automatically be requested as a reviewer so they can guide the contributor before the final maintainer review.

6.For visibility, it might be useful to log mentor assignments in a discussion or pinned issue so everyone can see who is mentoring what. Mentors should also be able to hand off a mentee if needed, and reassignment could happen automatically if there’s prolonged inactivity.

7.Edge cases to plan for would be things like mentors going inactive/OOO, contributors abandoning the issue, multiple contributors trying to claim the same issue, mentors who are also maintainers, and security-sensitive issues where mentors probably shouldn’t be auto-assigned.

[Nachiket-Roy]

One thought I had is to structure mentorship around repositories rather than a single global mentor pool.

Since BLT has multiple repositories, we could assign 1–2 primary mentors per repo. If a repo has higher traffic, additional mentors could be added gradually.

This has a few advantages:

1. Better expertise alignment
Mentors focusing on the same repository repeatedly will naturally become more familiar with its patterns, architecture, and recurring issues. When similar problems arise later, they can reference previous discussions or solutions more easily.

2. Reduced mismatch
Instead of routing issues globally, contributors would first reach mentors who already understand that specific repo.

3. On-demand mentorship instead of automatic assignment
Rather than assigning mentors automatically, contributors could explicitly request help using a command such as /mentor.

Example flow:

Issue claimed
→ Contributor runs /mentor
→ Repo mentor is notified
→ Mentor responds with guidance

4. Escalation if no response
If the mentor does not respond within a certain time window (for example ~6 hours), the same command could notify another available mentor or a broader pool.

5. Flexible mentor pool
We could still keep a group of versatile mentors who are not tied to a specific repo. They can step in when:

• a repo mentor is unavailable
• traffic spikes
• cross-repo issues appear

6. Incentives
Since mentorship is voluntary and time-consuming, contributors who regularly help others could receive BACON rewards or similar recognition.

[mdkaifansari04]

1. Who counts as a “mentor”?

The person registered for this gsoc 

- It should be in the yaml list in order to mentioned by github action in various places so yes

• No the idea separating mentors is good, like Project A (mentor 1 and mentor 2)

2. When should a mentor be assigned?

when the issue is label as need-mentor, and that label can only be added my administrator

3. Round-robin vs other assignment strategies

round robin is good for issue mentoring not complete project allocation
Why? Because some mentor should be super good in frontend and some in backend, asking mentor and assigning project based on interest/ compatibility would work best.

but when it comes to issues, ig mentors can help with issues it’s not a big deal.


4. How do we avoid mentor overload / burnout?

we should auto-skip mentors with too many open assignments

5. What should the GitHub Action do exactly?

• Assign mentor directly for the open issues label as “need-mentor” where the label is added my administrator of the org, so mentor dont just get spammed by contributors.


• Add mentor as a requested reviewer?

only for those issue he is marked as reviewer

• Tag mentor in a comment and apply needs-mentor-review?
> yes, one time not spamming every hour

• Only do PR mentor assignment if the PR is linked to a mentored issue?> yes


6. Visibility and transparency

• Should we log assignments in a pinned issue or discussion?

in issue it’s good

• Should mentors be able to “handoff” a mentee to another mentor?

if the another mentor is free and wanted to take it over only then, else he can talk to maintainer, what else could be the another option for it

• Should reassignment be automatic after X days of inactivity?

yeah, there should be kind of tracking after X days whether is it stale, or WIP. 


7) Edge cases we should plan for

• Contributor unassigns themselves / issue becomes stale

if contributor wont able to complete then it should be passed to another
contror.

• Multiple contributors want the same issue

not possible, someone who has better understanding of issue and good implementation plan would be get assigned

• Mentors are maintainers (should we treat them differently?)
 > yes, as he is not committed like a contributor so, their should be some boundries aligned for them.
• Security-sensitive issues (should not auto-assign?) 
> yes

yes we can keep finalized mentors in yaml file for accesss for the github app

[karunarapolu]

A few thoughts on this from my side:

Who counts as a “mentor”?
Anyone signing up for this GSoC season as temporary mentors in the YAML file. If they are interested in being a permanent mentor after GSoC as well, they can continue.
Separating mentors based on projects is good, based on their expertise. I they are interested/have expertise in many projects, by letting them chose.

Ideally, it should be one mentor per project, on a long term basis rather than round robin, since every time they are assigned a new project, they heave to go through the project which might negatively affect productivity and increase burden. Long term basis and 1-2 mentors per project sounds like a better alternative.

When should a mentor be assigned?
Instead of assigning mentors, we can make them check all the PRs and issues to their assigned project and review them and help/guide the contributors accordingly if they tag them.

How do we avoid mentor overload / burnout?
Mentors should be able to pause themselves, but for a reasonable time during active development phase like GSoC with a clear reason, since they can get burned out or get sudden commitments. But during non-active development time, they can take it lighter, more frequent breaks etc since they have other full time commitments.

Edge Case and other issues
If a mentor goes MIA, then another mentor can be assigned or help with that project. If a contributor goes MIA, others can pick it up.
Security-sensitive issues should go directly to core maintainer-DonnieBLT.

And we can incentivize them like Rosai mentioned through BACON rewards.

[e-esakman]

One thought I had while reading the proposed triggers (/claim, /assign-me, etc.) is that for many smaller issues, contributors might first need basic clarification about what the issue involves or the expected direction. In those cases, maintainers or the issue discussion itself might already provide enough initial guidance.

Because of that, automatically tagging a mentor for every claim might sometimes create unnecessary notifications. Perhaps mentorship could follow a layered approach:

• Initial clarification through issue comments or Slack discussions
• Peer guidance from other contributors where possible
• Mentor assignment only when deeper guidance is needed (for example through /mentor or a needs-mentor label)

This could help keep the mentor pool focused on situations where contributors genuinely need mentorship while avoiding excessive mentor pings.

It might also help if mentors could indicate the areas or projects they are most interested in guiding. Based on that, mentors could be associated with specific repositories or issue categories.

Keeping mentor information in a .github/mentors.yml file also seems like a good approach. For round-robin assignment, it might also be useful to check whether mentors are currently available or willing to take on the issue before assigning them.

Additionally, the idea of incentives mentioned by Rosai sounds interesting.

[DevalPrime]

One potential improvement could be introducing a "cold-start shield" before assigning a mentor.

In many open-source projects a large number of issues get claimed but never worked on. If a mentor is assigned immediately, their capacity may be consumed by inactive contributors.

A possible workflow could be:

1. Contributor claims an issue
2. Bot waits until a first meaningful activity occurs (e.g., PR opened or commit linked)
3. Mentor is assigned only after that signal

This keeps mentor capacity focused on contributors who actually start working on the issue.

Also, instead of limiting mentor capacity purely by number of mentees, it might be useful to measure load based on activity velocity.

For example:

mentor_load = open_pr_reviews + active_issue_threads

Some mentees require significantly more interaction than others. Using activity signals (comments, open reviews, etc.) could provide a more realistic measure of mentor workload and produce better assignment balancing.

[DonnieBLT]

What if the mentor could help prevent the cold start issue?

[DevalPrime]

That's a good question, let me improve upon my idea then:

Introducing two different mentor states instead of delaying assignment entirely:

1. Lightweight mentor ping (early stage)
   When the issue is claimed, a mentor could be mentioned automatically with a short introduction comment which would be encouraging for the contributor.

2. Active mentor assignment (after activity signal)
   Once the contributor opens a PR or shows meaningful progress, the mentor becomes formally assigned and counted toward their capacity.

This way the mentor can still help prevent the cold start problem, but mentor capacity accounting would only begin once the contributor is actively working on the issue.

It might also make sense for the bot to trigger a short “getting started” template message from the mentor, which could further reduce early confusion for new contributors.

[swaparup36]

One possible extension to the mentorship system could be allowing optional mentor pairing for certain issues. Some issues span multiple areas, and having a primary mentor with a secondary mentor could help provide better guidance while also allowing newer mentors to learn from more experienced ones.

It might also be useful to add a lightweight feedback system after a mentored issue or PR is completed (for example reactions or a short response from the contributor). Over time this feedback could help highlight mentors who consistently help contributors and support some form of mentor recognition or reputation within the community.

Not necessary for the first version, but it might be interesting as the mentor pool grows.

[snk-git-hub]

A few thoughts from my side
-On mentor assignment triggers, I think a hybrid approach works best — auto-assign only when a contributor shows real activity (like opening a draft PR or pushing a commit), not just when they comment /claim. This avoids wasting mentor capacity on contributors who claim issues but never start.
-On round-robin vs skill matching skill matching sounds great in theory but gets hard to maintain. A simpler middle ground could be grouping mentors by broad areas (frontend, backend, infra) and doing round-robin within that group based on the issue label.
-On burnout prevention a hard cap on active mentees combined with an auto-pause after X inactive days seems practical. Mentors should also be able to handoff via a simple command without needing maintainer approval every time.
Overall the .github/mentors.yml approach is clean and easy to version control. Happy to help implement parts of this if it moves forward!

[DonnieBLT]

Thank you all for the feedback, this feature is now being implemented