> For the complete documentation index, see [llms.txt](https://docs.mulearn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mulearn.org/roles-and-responsibilities/mentor.md).

# Mentor

Mentors are the **bridge between the μLearn ecosystem and the real world.** They bring domain expertise, industry perspective, and lived experience into the community without replacing the peer-driven learning that makes μLearn work.

### <mark style="color:$primary;">Who Can Be a Mentor</mark>

Mentors in μLearn come from two tracks:

**From inside the ecosystem** experienced learners who have reached advanced levels, demonstrated domain expertise, and want to give back to the community that helped them grow.

**From industry directly** working professionals, domain experts, researchers, and practitioners who want to contribute to the next generation's development without going through the full learner journey.

Both are equally valid. Both bring different things. Both are essential.

### <mark style="color:$primary;">What a Mentor Does</mark>

A mentor in μLearn:

* Provides **guidance, feedback, and perspective** not answers
* Validates **advanced PoW** that requires domain-level expertise beyond peer review
* Supports learners through the **μMent program** a structured 30-day mentorship sprint
* Earns **Volunteering Karma** for their contribution to the ecosystem

### <mark style="color:$primary;">What a Mentor Does NOT Do</mark>

Mentors are **not teachers.** They are not responsible for:

* Delivering curriculum or structured lessons
* Completing work on behalf of mentees
* Guaranteeing outcomes jobs, projects, results
* Being available 24/7

The mentee drives the relationship. The mentor responds, guides, and challenges.

### <mark style="color:$primary;">Engagement Expectations</mark>

<table><thead><tr><th width="213.6666259765625">Expectation</th><th>Detail</th></tr></thead><tbody><tr><td><strong>Availability</strong></td><td>Minimum defined touchpoints per cycle e.g. 2 sessions per month</td></tr><tr><td><strong>Responsiveness</strong></td><td>Respond to mentee messages within a defined SLA</td></tr><tr><td><strong>Feedback Quality</strong></td><td>Structured, specific, actionable  not generic</td></tr><tr><td><strong>Boundary Clarity</strong></td><td>Communicate availability and scope clearly at the start</td></tr><tr><td><strong>Reporting</strong></td><td>Flag concerns about mentee progress to the μMent coordinator</td></tr></tbody></table>

### <mark style="color:$primary;">How Mentor Matching Works</mark>

Mentors and mentees are matched based on:

* **Domain alignment** - mentor expertise vs. mentee goal
* **Karma signal** - mentee's demonstrated effort and consistency
* **Availability** - mutual schedule compatibility
* **Stage fit** - mentor's experience level vs. mentee's current stage

Matching is done by the Level Structure coordination team, with input from IG Leads.

> **Manual Intervention:** Mentor applications, matching, and relationship issues are managed by the μMent team. Contact \[μMent coordination form].

### <mark style="color:$primary;">How Mentors Earn Karma</mark>

Mentors earn **Volunteering Karma** through:

* Mentoring sessions completed
* PoW validated at mentor level
* Community contributions and facilitation
* μMent program participation

This Karma is visible on their profile making their contribution to the ecosystem verifiable and permanent.

→ To understand how to participate in μMent, go to [**Section 9 - Initiatives**](/initiatives.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.mulearn.org/roles-and-responsibilities/mentor.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.