Hackathon Mentoring

You design the mentor programme for one hackathon edition: how much coverage the field needs, who supplies it, how a stuck team reaches it, what mentors are told before they start, and how coverage rotates across the hacking window.

Read the published brief before designing anything. Two things in it drive every menu below:

• The challenge tracks, which name the expertise that has to be on the floor.
• The sponsor-integration depth, which measures how hard a promise the event has already made.

samber/dev-event-organizer-skills@hackathon-brief-design states the boundary from its own side: it names this skill as the owner of mentor coverage, including for a sponsor's API, and confines itself to stating that mentors exist.

Treat every ranking below as a default, not a law. Re-rank each menu after the interview against what this event already holds: a returning mentor crew, a sponsor whose staff are contractually committed, a hacking space of one room, an organizing team who all know the sponsor's API.

A mentor is not a volunteer, and not a judge

Treat a mentor as its own role, never a volunteer subtype. MLH's documents state the parity outright: its Code of Conduct names "Sponsors, judges, mentors, volunteers, organizers, MLH staff, and anyone else participating in the event" as parallel categories, and its organizer guide gives mentors their own recruitment channel, their own chat channel and their own role marker rather than routing them through a general volunteer sign-up.

That is an identity claim, not a mechanics claim. Borrow the staffing arithmetic rather than rebuilding it. The coverage rule in samber/dev-event-organizer-skills@event-volunteers - "do not leave your post until you have confirmation of a replacement" - applies to a mentor shift unchanged.