Epic: Testing Ad-Hoc Mentorship Flow

[nora-weisser]

Business Rules

Mentor profile statuses: PENDING (just registered, awaiting team review) → ACTIVE (approved, visible on the website and selectable by mentees) or REJECTED (not shown, rejection email sent).

Mentee application statuses: PENDING (just submitted, awaiting team review) → ADMIN_APPROVED (team approved, mentor can now see it) → MENTOR_ACCEPTED (mentor agreed, awaiting team confirmation) → MATCHED (team confirmed). Side branches: MENTOR_DECLINED (mentor said no, cascade fires), REJECTED (team rejected up-front, or auto-rejected because the mentee was matched with someone else), PENDING_MANUAL_MATCH (all priority mentors declined), DROPPED (mentee withdrew), NO_MATCH_FOUND (manual queue closed without a match — terminal). EXPIRED exists in the enum but is not used in this release.

Match statuses: ACTIVE (the mentor-mentee pairing is live for the cycle), plus COMPLETED and CANCELLED once the lifecycle ends.

Business rules:

• A mentor signs up once and chooses what they are available for: long-term mentorship, ad-hoc mentorship, or both. The choice is part of the registration form. The mentor record starts in PENDING.
• Long-term commitment must be at least 2 hours per mentee. A mentor cannot sign up to take 5 mentees for 4 hours total — that registration is rejected up-front.
• Every new mentor is reviewed by the mentorship team before becoming visible to mentees. While PENDING, the mentor is invisible on the website. Team accept moves them to ACTIVE and they appear on the site; team reject moves them to REJECTED, they are not shown, and they receive a rejection email.
• The mentorship team opens one cycle at a time — either the long-term cycle or the ad-hoc cycle. When a cycle is open, it sets the type of applications the site accepts. The cycle window for ad-hoc is meant to be the 1st–10th of each month (enforcement date-wise still to be added).
• Mentees see all ACTIVE mentors on the website. The Apply button is only enabled for mentors who offer the type of mentorship that matches the currently open cycle (and is disabled or hidden when no matching cycle is open).
• A mentee can apply to up to 5 mentors per cycle, in priority order. They cannot list the same mentor twice and cannot reuse priority numbers. Every application starts in PENDING.
• A long-term mentee who later wants ad-hoc keeps the same profile — the system does not create a second mentee record. Past applications in the long-term cycle stay in their final status (typically MATCHED or REJECTED) and are not affected by the new ad-hoc submissions.
• Every mentee application is first reviewed by the mentorship team before the mentor sees it. The team can reject an application up-front while still PENDING (it moves to REJECTED without ever being shown to the mentor) or approve it (it moves to ADMIN_APPROVED and surfaces in the mentor's queue).
• Once ADMIN_APPROVED, the application is offered to the mentee's first-choice mentor.
  • If the mentor accepts → application moves to MENTOR_ACCEPTED. The mentorship team then confirms the pairing → application moves to MATCHED and a match record is created in ACTIVE. At the moment of MATCHED, every other open application for this mentee in this cycle is automatically moved to REJECTED with reason "mentee matched with another mentor".
  • If the mentor declines → application moves to MENTOR_DECLINED and the system automatically forwards the request to the second-choice mentor, then third, and so on.
• If every mentor on the mentee's list ends up MENTOR_DECLINED (or REJECTED), the mentee's case lands in a "manual match" queue: a new application row is created in PENDING_MANUAL_MATCH. The mentorship team can then hand-pick another suitable mentor (a fresh PENDING application is created against that mentor and follows the standard path), or close the case as NO_MATCH_FOUND (terminal).
• A mentee who withdraws their own application moves it to DROPPED. This is final for that application; other applications in the same cycle are unaffected.
• A mentor cannot be matched with more mentees in a cycle than the cycle's per-mentor cap allows. The cap is checked at the confirm-match step, so over-cap mentors cannot be moved to MATCHED.
• Calendly is required on the mentor profile at registration and used when the mentee is matched. Google Meet links are created by the mentorship team ad-hoc, around the time the match is confirmed — they are not stored on the mentor profile.
• Mentors are not on a clock. There is no automatic expiry of an application if a mentor does not respond — applications stay in ADMIN_APPROVED until the mentor acts. The EXPIRED status is reserved for a future scheduler.
• The mentorship team are the only people who can move a mentor between PENDING / ACTIVE / REJECTED, approve mentee applications (PENDING → ADMIN_APPROVED), confirm matches (MENTOR_ACCEPTED → MATCHED), and run the manual-match queue. Today this permission is shared with platform admins and community leaders, which is acceptable.