hackathon-mentoring

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

你为某一届黑客松设计导师计划：现场需要多大覆盖范围、由谁提供、陷入困境的团队如何获得帮助、导师开始前被告知什么，以及覆盖如何在黑客松窗口期内轮转。

在设计任何内容之前，先阅读已发布的brief。其中两件事驱动了下面的每个选项菜单：

挑战赛道（challenge tracks），指明现场必须具备的专业知识。
赞助商集成深度（sponsor-integration depth），衡量活动已经做出的承诺有多重。

samber/dev-event-organizer-skills@hackathon-brief-design

从它自己的角度说明了边界：它将本skill命名为导师覆盖的负责人，包括对赞助商API的覆盖，并且只限于说明导师存在。

将下面的每一个排序都视为默认值，而非法则。在访谈之后，根据本次活动已经具备的条件重新排序每个菜单：有回归的导师团队、有合同承诺的赞助商员工、只有一个房间的黑客空间、全员都了解赞助商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.

samber/dev-event-organizer-skills@event-volunteers

owns:

Bottom-up roster sizing from posts and hours.
Arrival buffers.
Sign-up confirmation.
The no-show and replacement protocol.
Shift-linked recognition.

This skill owns what that skill has no concept of:

Expertise tagging.
Coverage depth by topic.
The request mechanic.
The help-versus-build briefing.

Judges are not mentors, and

samber/dev-event-organizer-skills@hackathon-judging

already says so from its side, in those words: mentors "help teams build during the hacking window", while "judges evaluate finished projects afterwards". The word "briefing" names two different documents across the two skills: a jury briefing there, a mentor briefing here. Write mentor briefing wherever a reader could confuse them.

Mentor conduct policy and enforcement are not yours. Mentors sit inside

samber/dev-event-organizer-skills@event-code-of-conduct

's existing pipeline like every other named role; do not draft a second one. Yours is narrower and lives inside the mentor briefing: the help-versus-build boundary, and the power dynamic between someone who knows the stack and someone who has been awake for twenty hours.

将导师视为独立的角色，绝不是志愿者的子类型。 MLH 的文件明确说明了这种对等关系：其《行为准则》将“赞助商、评委、导师、志愿者、组织者、MLH 工作人员以及任何其他参与活动的人”列为平行类别，其组织者指南为导师提供了独立的招募渠道、独立的聊天频道和独立的角色标识，而不是让他们通过通用志愿者报名流程。

这是一个身份声明，而不是机制声明。借用人员配置算法，而不是重新构建。

samber/dev-event-organizer-skills@event-volunteers

中的覆盖规则——“在得到替代者确认之前不要离开岗位”——原样适用于导师轮班。

samber/dev-event-organizer-skills@event-volunteers

负责：

从岗位和小时数自下而上地确定名册规模。
到达缓冲。
报名确认。
缺席和替换协议。
与轮班挂钩的认可。

本skill拥有该skill没有概念的内容：

专业知识标签。
按主题的覆盖深度。
请求机制。
帮助与代做（help-versus-build） briefing。

评委不是导师，

samber/dev-event-organizer-skills@hackathon-judging

已经从其角度明确说过：导师在黑客松窗口期内“帮助团队构建”，而“评委之后评估完成的项目”。“Briefing” 一词在这两个skill中指两份不同的文档：那里是评审briefing，这里是导师briefing。在读者可能混淆的地方，请写 mentor briefing（导师briefing）。

导师行为政策和执行不归你负责。 导师与其他所有具名角色一样，处于

samber/dev-event-organizer-skills@event-code-of-conduct

的现有管道之内；不要起草第二套。你的职责更窄，并且存在于导师briefing之内：帮助与代做的边界，以及懂技术栈的人与已经清醒二十小时的人之间的权力动态。

The mentor-judge conflict, stated from one side

导师-评委冲突，从一侧说明

A mentor who materially helped a team, then judges that team, is a conflict samber/dev-event-organizer-skills@hackathon-judging
already owns from its own side. It states that "a mentor who helped a team build cannot score that team neutrally" and routes the case into its existing recusal ladder: "apply the recusal rule to every team that person mentored". That skill owns the rule and the recusal mechanics.

This skill owns only the input data: a mentor-team contact log recording which mentor spent meaningful time with which team, available when the judge pool is assembled.

Keep the log whenever a confirmed mentor is also on the judge list (Q5).
State the rule declaratively: a mentor who materially helped a team recuses from judging that team.
Route the mechanics to that skill rather than deriving a competing ladder here.

One half of the handshake is still missing on that side: the recusal rule reaches for "every team that person mentored" without naming where that list comes from. This log is it, and it should be named there when that skill next revises.

samber/dev-event-organizer-skills@hackathon-judging
已经从自己的角度拥有“一位实质性帮助过某支团队、随后又评审该团队的导师”这一冲突。它指出“帮助过团队构建的导师无法中立地评审该团队”，并将情况纳入其现有的回避阶梯：“对该人指导过的每支团队应用回避规则”。该skill拥有这条规则和回避机制。

本skill只拥有输入数据：一份导师-团队接触日志，记录哪位导师与哪支团队度过了有意义的时光，供组建评委池时使用。

每当已确认的导师也在评委名单上时（Q5），保留日志。
以声明式方式陈述规则：实质性地帮助过某支团队的导师应回避对该团队的评审。
将机制导向该skill，而不是在这里推导一套相互竞争的阶梯。

那次握手的另一半在那一边仍然缺失： 回避规则提到“该人指导过的每支团队”，却没有说明这份名单从何而来。这份日志就是答案，并且当该skill下次修订时，应该在那里被点名。

Quantities to refuse, and the one published ratio

拒绝编造的数量，以及唯一已发布的比率

Never invent quantities for:

Mentor-to-participant ratios.
Evidence linking mentor availability to completion or satisfaction.
Unblock latency targets.
Mentor-to-shift staffing formulas.

These numbers feel safe to invent precisely because nothing on the day contradicts them. Argue from the mechanism instead: a blocked team with no route to help abandons the build.

One published ratio exists. Joshua Tauberer's

hackathon.guide

states (under At Themed Hackathons) "ensure that there is at least one subject matter expert + workable project for about every four non-expert participants". Its purpose is project supply, not mentor staffing.

The ratio scopes narrowly:

Themed hackathons only (one problem domain).
Counts non-expert participants, not teams.
Describes domain experts inside projects, not floating mentors.

Use it as evidence that expertise, not headcount, is the scarce quantity. Never convert it into a mentors-per-participant formula.

绝不要为以下内容编造数量：

导师与参与者比例。
将导师可用性与完成率或满意度联系起来的证据。
解除阻塞延迟目标。
导师轮班人员配置公式。

这些数字之所以让人觉得可以放心编造，正是因为当天没有任何东西会反驳它们。相反，要从机制角度论证：一支被阻塞且没有求助途径的团队会放弃构建。

存在一个已发布的比率。Joshua Tauberer 的

hackathon.guide

在“At Themed Hackathons”下写道：“确保每大约四名非专家参与者至少有一个主题专家 + 可行的项目”。其目的是项目供给，而不是导师人员配置。

该比率的范围很窄：

仅适用于主题型黑客松（一个问题领域）。
统计的是非专家参与者，而不是团队。
描述的是项目内部的领域专家，而不是流动导师。

用它作为证据，说明稀缺的是专业知识，而不是人数。绝不要把它转换成每位参与者配多少导师的公式。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 1-4 and 6-9 exist because the menus turn on them: no default can be picked for the user without those answers.

Is the event in person, digital or hybrid; how many rooms does the hacking space occupy; and does the hacking window run through the night?
Which challenge tracks does the published brief name, and at what sponsor-integration depth - named funder only, optional bonus challenge, required for one track, or the sponsor's technology as sole substrate?
Is the event themed, with organizer-supplied problems, or open, with participants bringing their own?
Who is already committed to mentor: community members and alumni, a sponsor's technical staff, or both - and is any sponsor staffing commitment already written into a signed agreement?
Is any confirmed mentor also on the judge list?
Do prizes carry cash value, and does any sponsor fund one?
Have these mentors mentored before, and is this a one-off edition or a recurring event?
What is the effort ceiling: organizer hours before the event, whether anyone will coordinate mentors live during the window, and whether a shift grid already exists from the volunteer plan.
By what date must the roster close and the request mechanic reach participants? Channels have lead times and the mechanic has to be published before the window opens, so this date constrains both rather than expressing a preference.
What already exists that the default ordering assumes away: last edition's mentor list, a university department or user group that would send several people, a sponsor whose staff are already on site for a booth, an organizing team who has built against this API before.

Name which answer moved which rung as you re-rank:

A close roster date (Q9) promotes community and alumni only, since a warm list answers in days while a sponsor staffing negotiation runs weeks. It demotes the expertise-matched roster, whose tagging and alignment pass are the last work to finish.
A recurring event (Q7) promotes the boundary-plus-scenario-walkthrough briefing, written once and reused across editions rather than paid for again.
A low effort ceiling (Q8) demotes the request channel with organizer routing, whose cost is a standing job for the whole window rather than a one-off setup.

一次问一个问题，尽可能使用选择题。问题 1-4 和 6-9 之所以存在，是因为菜单依赖它们：没有这些答案，就无法为用户选择默认值。

活动是线下、线上还是混合形式；黑客空间占用多少个房间；黑客窗口是否会持续整夜？
已发布的brief列出了哪些挑战赛道，赞助商集成深度如何——仅提及资助方、可选加分挑战、某一条赛道的必要条件，还是赞助商技术作为唯一基底？
活动是主题型（由组织者提供问题），还是开放型（参与者自带项目）？
谁已经承诺担任导师：社区成员和校友、赞助商的技术员工，还是两者都有——赞助商的人员承诺是否已经写入签署的协议？
是否有任何已确认的导师也在评委名单上？
奖品是否带有现金价值，是否有赞助商资助奖品？
这些导师以前是否指导过？这是单次活动还是周期性活动？
投入上限是什么：活动前的组织者工时、是否有人在窗口期现场协调导师、以及志愿者计划中是否已有轮班表。
名册必须何时截止，请求机制必须何时触达参与者？渠道有前置时间，机制必须在窗口开启前发布，因此这个日期同时约束两者，而不是表达一种偏好。
默认排序假设不存在、但实际上已经存在的事物：上一届的导师名单、一个会派多人来的大学院系或用户组、员工已经到场设展位的赞助商、以前基于这个API构建过的组织团队。

在重新排序时，说明哪个答案改变了哪个层级：

较早的名册截止日期（Q9）只会提升“社区和校友”渠道，因为一份温热的名单几天内就能回应，而赞助商人员谈判需要数周。它会降低“按专业匹配的名册”，因为其标签和对齐工作是最后完成的工作。
周期性活动（Q7）会提升“边界 + 场景演练”briefing，因为写一次可以跨届复用，而不是每次都重新付出。
低投入上限（Q8）会降低“带组织者路由的请求渠道”，因为其成本是整个窗口期的常设工作，而不是一次性设置。

Workflow

工作流

Run the interview, after reading the published brief.
Set coverage depth against the tracks, not against a headcount. A sole-substrate sponsor integration raises that track's bar from "a mentor is available" to "a mentor is guaranteed on the floor whenever that track is being worked": the brief's own fallback sentence assumes the platform actually gets support.
Pick the recruitment channels and open them with the lead time the roster deadline demands. Load references/coverage-and-recruitment.md.
Tag every confirmed mentor with what they actually know, in the brief's own vocabulary: one tag per challenge track, plus the sponsor technology by name. A tag nobody can match to a track does no routing work.
Hand the roster to the shift machinery you do not own. Sizing, buffers, confirmation and the replacement protocol belong to
```
samber/dev-event-organizer-skills@event-volunteers
```
. You supply the constraint it schedules against: which expertise must be present in which hours.
Choose the request mechanic and publish it in the same place teams read the brief, before the hacking window opens.
Brief the mentors. Load references/mentor-briefing-and-request-mechanic.md.
Record contacts during the window, meaning which mentor spent meaningful time with which team, whenever a mentor is also judging (Q5). Hand that log to
```
samber/dev-event-organizer-skills@hackathon-judging
```
.
Close out. Record which tracks ran short of coverage and at which hours, then hand the mentor list to whoever recruits next edition.

Present the design section by section for validation before the window opens: coverage depth, recruitment channels, expertise tags, request mechanic, briefing. A request mechanic changed mid-event is a mechanic half the field never learns.

If your harness has persistent memory, record the expertise tags against the tracks they covered, which hours ran short, the request mechanic used and how it failed, and the mentors who would come back.

运行访谈，在阅读已发布的brief之后。
设置覆盖深度，以赛道为基准，而不是以人数为基准。单一基底（sole-substrate）的赞助商集成将该赛道的标准从“有导师可用”提升为“只要该赛道正在被攻关，就保证现场有导师”：brief 自己的后备语句默认该平台确实会得到支持。
选择招募渠道，并按名册截止日期所需的前置时间开启渠道。加载 references/coverage-and-recruitment.md。
为每位已确认的导师打上其真正了解的内容的标签，使用brief自己的词汇：每个挑战赛道一个标签，加上按名称命名的赞助商技术。无法对应到任何赛道的标签不会产生任何路由作用。
将名册交给你不拥有的轮班机制。 规模、缓冲、确认和替换协议属于
```
samber/dev-event-organizer-skills@event-volunteers
```
。你提供它排班所依据的约束：哪些专业知识必须在哪些小时在场。
选择请求机制，并在黑客窗口开启前，把它发布在团队阅读brief的同一位置。
给导师做briefing。 加载 references/mentor-briefing-and-request-mechanic.md。
在窗口期内记录接触，即当导师也在评审时（Q5），记录哪位导师与哪支团队度过了有意义的时光。将该日志交给
```
samber/dev-event-organizer-skills@hackathon-judging
```
。
收尾。 记录哪些赛道在哪些小时覆盖不足，然后把导师名单交给下一届的招募者。

在窗口开启前，逐节展示设计以供验证：覆盖深度、招募渠道、专业知识标签、请求机制、briefing。在活动进行中更改请求机制，等于让一半现场的人永远学不会这个机制。

如果你的运行框架（harness）有持久化记忆，请记录专业知识标签与其覆盖的赛道、哪些小时覆盖不足、使用的请求机制及其失败方式，以及愿意再来的导师。

Mentor coverage depth

导师覆盖深度

Four rungs: no mentor programme, on-call from organizers, rostered mentor shifts, and a roster matched to the brief's tracks by expertise.

value (teams unblocked, the sponsor's technology actually reachable, every track covered):

expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme

effort before the event (recruiting, scheduling, expertise tagging):

expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme

organizer attention consumed during the window:

on-call from organizers > no mentor programme > rostered shifts > expertise-matched roster

efficiency:

rostered shifts > expertise-matched roster > on-call from organizers > no mentor programme

Dominance check: clean only by construction, and by-construction is never a pass. Value and pre-event effort are rank-identical, so one mechanism blocks all six pairs, not some of them: whichever rung of a pair is higher on value is strictly higher on pre-event effort too, and fails the test before the third axis is consulted.

The third axis diverges genuinely and still rescues nothing. A pair needs value ≥ and both costs ≤, and the effort half is already lost in every pair. Zero strict-dominance relations exist, the check catches no misordering here, and the efficiency line rests entirely on the arguments below.

Carry the organizer-attention axis anyway, because it is not rank-identical to inverse effort. Inverse pre-event effort would order these

no mentor programme > on-call > rostered > expertise-matched

; organizer attention orders them

on-call > no mentor programme > rostered > expertise-matched

. The top two swap, and that swap is the finding: on-call is the second cheapest rung to set up and the single most expensive one to live through.

The same swap is why the cheap rung is not the safe one. On-call looks free because nobody is recruited. What it does is route every technical question to the people also running the schedule, at the hour the schedule is hardest to run.

MLH's guide points the other way, asking volunteers to "stay alert on Discord to look for hackers who need help and push them to the above-mentioned mentorship channel", routing questions away from generic staff toward a named mentor pool.

Rostered mentor shifts - the default. Recruiting and a shift grid cost a one-off before the event, and the grid is machinery
```
samber/dev-event-organizer-skills@event-volunteers
```
already provides, so the marginal work is a mentor list rather than a scheduling system. It buys the one thing on-call cannot: a named person who is there because that is what they came to do.
Expertise-matched roster - the starved option: top of value and top of pre-event effort, so efficiency never picks it first. The added work is a tag per mentor and an alignment pass against the track hours. Promotion condition, keyed to Q2 and Q3: the brief commits a sponsor technology at required for one track or deeper, or the event is themed and its problems come from one domain. Below that, general technical coverage is what teams actually consume.
On-call from organizers - legitimate where the organizing team genuinely holds the field's expertise and is small enough to answer without dropping the run of show. Its cost lands during the window, the moment with no slack in it.
No mentor programme - a real, rankable rung rather than a strawman: an open-theme event where participants bring their own projects and no sponsor technology is named may need none, and Tauberer's guide describes exactly that shape of event. Delete it, from this menu and from the axis lines above, as soon as the brief names any sponsor technology at required-for-one-track depth or deeper (Q2). At that point the brief has promised support the event has not staffed, and parking the option at the bottom quietly leaves that promise unfunded.

Coverage arithmetic, expertise-tag vocabulary and the escalation path when no mentor covers a needed skill are in references/coverage-and-recruitment.md.

四个层级：无导师计划、组织者随叫随到、排班导师轮班、以及按专业知识匹配brief赛道（expertise-matched roster）的名册。

价值（团队解除阻塞、赞助商技术真正可触及、每条赛道都有覆盖）：
```
expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme
```

活动前的投入（招募、排班、专业知识标签）：

expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme

窗口期内消耗的组织者注意力：

on-call from organizers > no mentor programme > rostered shifts > expertise-matched roster

效率：

rostered shifts > expertise-matched roster > on-call from organizers > no mentor programme

支配性检查：只是构造上的干净，而构造上的干净永远不算通过。 价值与活动前投入的排序完全一致，因此 一个机制阻挡了全部六对组合，而不是其中一些：一对中价值较高的层级，其活动前投入也严格更高，并且在第三个轴被查看之前就已经失败了。

第三个轴确实发生了分歧，但仍然救不了任何东西。一对需要价值 ≥ 且两项成本都 ≤，而每一对的投入一半已经失败。这里不存在任何严格支配关系，检查没有发现任何排序错误，效率这一行完全依赖于下面的论证。

无论如何都要保留组织者注意力这个轴，因为它与反向投入并不排序相同。 反向的活动前投入会把它们排成

no mentor programme > on-call > rostered > expertise-matched

；组织者注意力把它们排成

on-call > no mentor programme > rostered > expertise-matched

。前两名交换了位置，而这个交换正是结论：随叫随到是第二便宜的搭建层级，却是最昂贵的一种度过方式。

同样的交换也说明了为什么便宜的层级并不安全。随叫随到看起来免费，因为没有人被招募。它所做的，是把每一个技术问题都路由给那些同时也在运行日程的人，而且是在日程最难运行的时刻。

MLH 的指南指向另一个方向，要求志愿者“在 Discord 上保持警觉，寻找需要帮助的hacker，并把它们推送到上述导师频道”，把问题从普通员工路由到具名的导师池。

排班导师轮班（Rostered mentor shifts） - 默认选项。招募和轮班网格在活动前需要一次性成本，而网格是
```
samber/dev-event-organizer-skills@event-volunteers
```
已经提供的机制，因此边际工作是一份导师名单，而不是一套排班系统。它买到了随叫随到买不到的东西：一个具名的人，他之所以在场，是因为这就是他来的目的。
按专业匹配的名册（Expertise-matched roster） - 被忽视的选项：价值最高、活动前投入也最高，所以效率永远不会首先选择它。额外工作是每位导师一个标签，以及一次对照赛道时段的对齐检查。提升条件（与Q2和Q3相关）：brief 承诺了赞助商技术，级别为某条赛道必需或更深，或者活动是主题型且问题来自单一领域。低于这个级别，团队真正消费的是通用技术覆盖。
组织者随叫随到（On-call from organizers） - 当组织团队确实掌握该领域的专业知识，并且规模小到可以在不搞砸流程的情况下回答问题，这是合理的。其成本落在窗口期内，也就是最没有喘息空间的时刻。
无导师计划（No mentor programme） - 一个真实、可排序的层级，而不是稻草人：开放主题的活动，参与者自带项目且没有点名赞助商技术，可能确实不需要导师，而 Tauberer 的指南描述的正是这种形态的活动。只要 brief 点名了任何达到“某条赛道必需或更深”级别的赞助商技术（Q2），就把它从本菜单和上面的轴线上删除。 在那种情况下，brief 已经承诺了活动并未配置人员的支持，而把这个选项停在底部，就是悄悄让这个承诺没有资金支持。

覆盖算法、专业知识标签词汇，以及当没有导师覆盖所需技能时的升级路径，见 references/coverage-and-recruitment.md。

Recruitment source

招募来源

Four rungs: community members and alumni only, a sponsor's technical staff only, a mixed pool, and a mixed pool plus a written engagement rule telling sponsor staff not to pitch or recruit while mentoring.

value, expertise coverage across the brief's tracks:

mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only

value, participant trust that the person helping is not selling:

mixed pool with a written rule > community and alumni only > mixed pool > sponsor staff only

effort (two recruiting channels, negotiating a sponsor commitment, writing the rule):

mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only

compliance cost, as the review each rung triggers and the reversibility it costs:

sponsor staff only > mixed pool > mixed pool with a written rule > community and alumni only

efficiency:

community and alumni only > mixed pool with a written rule > mixed pool > sponsor staff only

Dominance check: clean by care. Exactly one strict-dominance relation exists. The mixed pool with a written rule has equal expertise value, strictly higher trust value, equal effort and strictly lower compliance cost than the bare mixed pool, and the efficiency line honours it by ranking the rule above it.

Community-only never dominates, at the bottom of expertise value; sponsor-only never dominates, at the bottom of trust value and the top of compliance cost. A wrong ordering here would have failed the check, so this pass carries information the other three menus' passes do not.

Both
==
are argued, not dodges.

Expertise. The written rule changes what a sponsor representative may say, never what they know, so the pool's coverage of the brief's tracks is unchanged by it.
Effort. The rule is one paragraph inside a mentor briefing the next menu's default already produces, plus one line handed to
```
samber/dev-event-organizer-skills@event-sponsor-agreement
```
: the same order of magnitude as the mixed pool without it, which is minutes against a channel negotiation measured in weeks.

Why compliance cost re-orders the menu. A sponsor representative who uses mentor access to pitch a product or recruit a participant creates a disclosure problem. Undisclosed, it surfaces after the event, when the only remedies left are an apology and a sponsorship conversation.

Writing the rule triggers a review before the event that costs a paragraph and reverses next edition. Community-only carries no such exposure at all, which is the other half of why it leads the ratio.

Community and alumni only - the efficiency leader. Publish it as a warm-list ask rather than an open call: reach "existing tutors or teaching assistants to mentor because they already find the value out of mentoring", then "alumni from your school, industry professionals, and your professors". The setting is what fails to transfer. That channel assumes a university hackathon with a department behind it, so a corporate or community event substitutes a user group, a past-participant list or a partner company.
Mixed pool with a written engagement rule - the starved option, and the one to promote deliberately: it tops both value axes and the effort axis, so the cheaper community channel wins the ratio at any event with nothing sponsor-specific to support. Promotion condition, keyed to Q2 and Q4: the brief names any sponsor technology, at any depth, because a community mentor cannot be assumed to know it and the sponsor's own staff are the only people who reliably do.
Mixed pool without the rule - the rung the dominance check rules out, kept on the page because it is what happens by default when nobody writes the paragraph. Naming it is how you notice it happened.
Sponsor staff only - delete it, from this menu and from the axis lines above, as soon as the brief carries a general track alongside the sponsor track (Q2) - which is
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
's own default structure. A pool that only knows one platform leaves every general-track team with nobody, and every participant reading a mentor's employer badge as a sales conversation.

Where a sponsor supplies its own staff, that channel is no volunteer sign-up. It is a sponsorship deliverable, negotiated in

samber/dev-event-organizer-skills@event-sponsor-agreement

and delivered against a commitment. Treat a missing sponsor mentor as a fulfilment failure, never as a no-show.

四个层级：仅社区成员和校友、仅赞助商技术员工、混合池、以及混合池加一条书面参与规则（告诉赞助商员工在指导时不得推销或招募）。

价值，对brief各赛道的专业知识覆盖：

mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only

价值，参与者对“帮助者不是在推销”的信任：

mixed pool with a written rule > community and alumni only > mixed pool > sponsor staff only

投入（两个招募渠道、谈判赞助商承诺、写规则）：

mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only

合规成本，即每个层级触发的审查及其付出的可逆性：

sponsor staff only > mixed pool > mixed pool with a written rule > community and alumni only

效率：

community and alumni only > mixed pool with a written rule > mixed pool > sponsor staff only

支配性检查：靠细心才干净。恰好存在一个严格支配关系。 带书面规则的混合池与裸混合池相比，专业知识价值相等、信任价值严格更高、投入相等、合规成本严格更低，效率行通过将规则排在裸混合池之上来认可这一点。

仅社区永不支配，处于专业知识价值的底部；仅赞助商也永不支配，处于信任价值的底部和合规成本的顶部。这里的错误排序会无法通过检查，因此这一轮检查携带了其他三个菜单的检查所没有的信息。

两个
==
都有论证，不是回避。

专业知识。 书面规则改变的是赞助商代表可以说什么，而绝不是他们知道什么，因此池子对brief赛道的覆盖不会因此改变。
投入。 这条规则是下一个菜单的默认选项已经会生成的导师briefing中的一段话，外加一行交给
```
samber/dev-event-organizer-skills@event-sponsor-agreement
```
的内容：与没有它的混合池同属一个数量级，即以分钟计，而渠道谈判要以周计。

为什么合规成本会重新排序菜单。 赞助商代表利用导师身份推销产品或招募参与者，会制造一个披露问题。如果不披露，它会在活动结束后浮出水面，那时剩下的唯一补救措施就是道歉和一次赞助对话。

写下规则会在活动前触发一次审查，成本是一段话，并且可以在下一届撤销。仅社区完全不承担这种风险，这是它在效率上领先的另一半原因。

仅社区成员和校友（Community and alumni only） - 效率领先者。把它发布为对温热名单（warm list）的请求，而不是公开召集：先触达“现有的导师或助教，请他们担任导师，因为他们已经从指导中发现了价值”，然后是“你所在学校的校友、行业专业人士和你的教授”。无法迁移的是场景。该渠道假设的是一个有院系支持的高校黑客松，因此企业或社区活动会用用户组、往届参与者名单或合作公司来替代。
带书面参与规则的混合池（Mixed pool with a written engagement rule） - 被忽视的选项，也是应该刻意提升的那一个：它在两个价值轴和投入轴上都居首，因此在任何没有赞助商特定内容需要支持的活动上，更便宜的社区渠道赢了效率比。提升条件（与Q2和Q4相关）：brief 点名了任何赞助商技术，无论深度如何，因为不能假设社区导师了解它，而赞助商自己的员工是唯一可靠了解它的人。
不带规则的混合池（Mixed pool without the rule） - 支配性检查排除掉的层级，保留在页面上是因为当没人写那段话时，默认就会发生这种情况。给它命名，你才能注意到它已经发生。
仅赞助商员工（Sponsor staff only） - 只要 brief 在赞助商赛道之外还带有通用赛道（Q2），就把它从本菜单和上面的轴线上删除——这是
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
自己的默认结构。一个只知道一个平台的池子，会让每条通用赛道团队无人可找，也会让每位参与者把导师胸牌上的雇主读成一场销售对话。

当赞助商提供自己的员工时，这个渠道不是志愿者报名。它是一项赞助交付物（sponsorship deliverable），在

samber/dev-event-organizer-skills@event-sponsor-agreement

中谈判，并依据承诺交付。要把缺少赞助商导师视为履约失败，而绝不是缺席（no-show）。

The request mechanic

请求机制

How a stuck team reaches a mentor. Five rungs: find someone informally; identifiable mentors and nothing else; a staffed mentor area teams walk up to; a request channel with an organizer routing each request; scheduled office hours.

value, unblock latency (how soon a team that just got stuck is talking to somebody):

request channel with routing > staffed mentor area > identifiable mentors > find someone informally > scheduled office hours

value, expertise match (the person who arrives actually knows the thing):

request channel with routing > scheduled office hours > staffed mentor area > identifiable mentors == find someone informally

effort (setup, standing coordination during the window, mentor hours consumed):

request channel with routing > staffed mentor area > scheduled office hours > identifiable mentors == find someone informally

efficiency:

identifiable mentors > staffed mentor area > request channel with routing > scheduled office hours > find someone informally

Dominance check: clean by care, on one relation out of ten pairs. The two value axes genuinely disagree, since scheduled office hours are the worst rung for latency and the second best for match, and that disagreement is why this menu is no ladder. Exactly one strict-dominance relation survives it: identifiable mentors have strictly better latency than finding someone informally, equal expertise match and equal effort, so they dominate. The efficiency line honours it.

The other nine pairs each trade one axis against another, so the check verifies nothing about them and their ordering rests on the arguments below.

Both
==
are argued.

Expertise match. A visible marker tells a participant who is a mentor and nothing about what that mentor knows, so it buys exactly zero match over asking a stranger.
Effort. Both rungs are near-zero and within the same order of magnitude: one is a stationery decision and a role assignment, the other is nothing at all.

The five rungs, in the efficiency order above:

Identifiable mentors - the default, and the cheapest real intervention on this page. Give mentors a marker a participant can spot across a room and a name in the event's channels; MLH does both, with an "@mentor role" so "hackers can easily differentiate mentors".
```
samber/dev-event-organizer-skills@event-volunteers
```
documents the same mechanic working as wayfinding for a different population, which is why the marker survives a budget cut a perk would not. The relation that puts it above informal collapses at exactly one kind of event: one small enough that every participant already knows every mentor by face. Treat that as the re-rank hook, never as an exception to write into the plan.
Staffed mentor area - "a dedicated mentor area that hackers can walk up to with questions". Promotion condition, keyed to Q1: the hacking space runs to more than one room, or the mentor crew is larger than the organizing team, at which point "find one" stops being a reliable instruction.
Request channel with organizer routing - the starved option: it tops both value axes and the effort axis, because the routing is a standing job somebody works for the whole window. The published shape is a channel where "mentors know where to look for requests", with organizers "active on chat" connecting hackers to mentors. Promotion condition, keyed to Q1 and Q2: the event is digital or hybrid, so there is no floor to walk; or the hacking space spans several rooms; or a sponsor track's questions have to reach one named person.
Scheduled office hours - published as a supplement rather than a mechanic: "mentorship office hours: A peer group type of experience where people can ask questions during the assigned time". Excellent expertise match, worst possible latency. Delete it as the sole route, from this menu and from the axis lines above, when the hacking window runs through hours the office-hour blocks do not cover (Q1). A blocker at three in the morning does not wait for a ten o'clock slot.
Find someone informally - last on efficiency because the dominance check ruled it out, not because a constraint did. It is what an event with no mentor programme actually does.

Deleted outright: routing every request through one named organizer's direct messages. Delete it from this menu and from the axis lines above. It looks like the cheapest possible queue, and it is a single point of failure that fails at the exact hour a hackathon needs it, because that person is asleep.

陷入困境的团队如何联系到导师。五个层级：非正式地找人；可识别的导师，仅此而已；有专人值守的导师区，团队可以走过去；带组织者逐条路由请求的请求渠道；定时 office hours。

价值，解除阻塞延迟（刚刚卡住的团队多快能跟人对话）：

request channel with routing > staffed mentor area > identifiable mentors > find someone informally > scheduled office hours

价值，专业匹配（到来的人确实懂那件事）：

request channel with routing > scheduled office hours > staffed mentor area > identifiable mentors == find someone informally

投入（设置、窗口期内的常驻协调、消耗的导师工时）：

request channel with routing > staffed mentor area > scheduled office hours > identifiable mentors == find someone informally

效率：

identifiable mentors > staffed mentor area > request channel with routing > scheduled office hours > find someone informally

支配性检查：靠细心才干净，十对关系中只有一对。 两个价值轴确实存在分歧，因为定时 office hours 在延迟上是最差层级，在匹配上是第二好，而这种分歧正是这个菜单不是阶梯的原因。恰好一个严格支配关系存活下来：可识别导师的延迟严格优于非正式找人，专业匹配相等、投入相等，因此它们支配后者。效率行认可了这一点。

其他九对各自在一个轴与另一个轴之间权衡，因此检查无法验证它们，它们的排序依赖于下面的论证。

两个
==
都有论证。

专业匹配。 一个可见的标识告诉参与者谁是导师，但不告诉参与者这位导师知道什么，因此与问陌生人相比，它带来的匹配恰好为零。
投入。 两个层级都接近零，且在同一数量级内：一个是文具决定加角色分配，另一个则什么都不是。

五个层级，按上面的效率顺序：

可识别的导师（Identifiable mentors） - 默认选项，也是本页面最便宜的真实干预。给导师一个参与者能隔着房间认出的标识，以及在活动频道中的名字；MLH 两者都做了，用一个“@mentor role”，这样“hackers 就能轻松区分导师”。
```
samber/dev-event-organizer-skills@event-volunteers
```
记录了同样的机制为不同人群充当导路标识，这就是为什么标识能在预算削减中存活，而福利不能。让它高于非正式找人的关系，只在一种活动上失效：活动小到每位参与者已经能凭脸认出每位导师。把它当作重新排序的钩子，而不是写进计划的例外。
有专人值守的导师区（Staffed mentor area） - “一个专门的导师区，hackers 可以带着问题走过去”。提升条件（与Q1相关）：黑客空间不止一个房间，或者导师团队规模大于组织团队，此时“找一个”不再是可靠的指示。
带组织者路由的请求渠道（Request channel with organizer routing） - 被忽视的选项：它在两个价值轴和投入轴上都居首，因为路由是一项常驻工作，有人在整个窗口期工作。已发布的形态是一个渠道，“导师知道去哪里找请求”，组织者“在聊天中保持活跃”，把 hackers 连接到导师。提升条件（与Q1和Q2相关）：活动是线上或混合形式，因此没有可以走过去的场地；或者黑客空间横跨多个房间；或者赞助商赛道的问题必须到达一个具名的人。
定时 office hours（Scheduled office hours） - 作为补充而不是机制发布：“导师 office hours：一种同伴小组式体验，人们可以在指定时间内提问”。专业匹配极好，延迟却可能最差。当黑客窗口覆盖了 office hours 时间段没有覆盖的时段（Q1）时，把它作为唯一路径从本菜单和上面的轴线上删除。 凌晨三点的阻塞者不会等到十点的时段。
非正式找人（Find someone informally） - 效率上垫底，因为支配性检查排除了它，而不是因为约束排除了它。没有导师计划的活动实际就是这样。

直接删除：把所有请求路由到一位具名组织者的私信。 从本菜单和上面的轴线上删除它。它看起来是最便宜的队列，但它是单点故障，而且会在黑客松最需要的时刻失败，因为那个人睡着了。

Mentor briefing depth

导师Briefing深度

Four rungs: no briefing; logistics only; logistics plus the help-versus-build boundary stated explicitly; boundary plus a scenario walkthrough with rehearsed responses.

value (teams learn rather than get carried, and the submission stays defensible at prize time):
```
boundary plus scenario walkthrough > boundary stated > logistics only > none
```

effort (preparation, briefing length, written material):

boundary plus scenario walkthrough > boundary stated > logistics only > none

compliance cost, as the review each rung triggers and the reversibility it costs:
```
boundary plus scenario walkthrough > none > logistics only > boundary stated
```

efficiency:

boundary stated > logistics only > none > boundary plus scenario walkthrough

Dominance check: clean only by construction, and by-construction is never a pass. Value and effort are rank-identical here too, so again one mechanism blocks all six pairs: the higher-value rung of every pair is strictly more effort, and no pair survives to be tested against compliance at all.

The compliance axis is non-monotonic and genuinely re-orders the efficiency line. Re-ordering and rescuing are different jobs, and it does only the first. Zero dominance relations exist, the check verifies nothing, and the ordering rests on the argument below.

The compliance axis is authorship contamination, and it mirrors
samber/dev-event-organizer-skills@hackathon-judging
's conflict-of-interest pattern deliberately. A mentor who writes code into a team's repository with no stated boundary creates a contestable-authorship problem. It surfaces at the ceremony, with prizes on the table and nothing published to point at: the least reversible moment there is.

That is why "none" is cheapest on effort and second-highest on compliance cost, and why the default is not the cheapest rung. The exposure is real rather than theoretical:

samber/dev-event-organizer-skills@hackathon-brief-design

cites a published requirement that submitted code be public and stay public to remain prize-eligible, so the commits are readable and so is whose they are.

The walkthrough tops the same axis for the opposite reason. It is a written standard the event can then be held to, so it triggers a review before it ships and is the hardest rung to withdraw once mentors have been briefed on it. That is the same shape as

samber/dev-event-organizer-skills@hackathon-judging

's disclosure-registry rung, which tops its own compliance axis for exactly that reason.

Boundary stated explicitly - the default, and the lowest compliance cost of the four. Decide the line once, before the event, while it costs a sentence and a mid-window reminder can still correct it. The boundary is a line you set rather than a standard to cite, and its wording, with the worked positive and negative pair, is in references/mentor-briefing-and-request-mechanic.md.
Logistics only - where to be, when, which channel, who to escalate to. Necessary and never sufficient: it leaves the one question mentors actually face unanswered. MLH's guide sits close to this rung, asking for a mentor guide covering "questions to ask hackers, how to troubleshoot with the hacker, and useful beginner tools/resources" and for "a set of guidelines for mentors on what to do during mentorship, giving them a process", while leaving the help-versus-build line to the organizer.
None - delete it, from this menu and from the axis lines above, as soon as any prize carries cash value or any sponsor funds one (Q6). This mirrors
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
's deletion of its own minimal rules rung on the same trigger and for the same reason: a prize with value turns a disagreement into a claim, and an unbriefed mentor's commit becomes an eligibility question nobody can answer.
Boundary plus scenario walkthrough - the starved option: top of value, effort and compliance cost. Promotion condition, keyed to Q7 and Q4: most mentors have never mentored before, or sponsor staff are mentoring on a codebase their employer has a commercial interest in, or the event recurs and the walkthrough is written once and reused across editions.

The briefing's non-negotiable content regardless of rung, the power-dynamics guidance, and the escalation pointer into the code-of-conduct pipeline are in references/mentor-briefing-and-request-mechanic.md.

四个层级：无 briefing；仅后勤；后勤加明确陈述的帮助与代做边界；边界加带演练应答的场景走查。

价值（团队学到东西而不是被代做，提交在颁奖时依然站得住脚）：
```
boundary plus scenario walkthrough > boundary stated > logistics only > none
```

投入（准备、briefing长度、书面材料）：

boundary plus scenario walkthrough > boundary stated > logistics only > none

合规成本，即每个层级触发的审查及其付出的可逆性：

boundary plus scenario walkthrough > none > logistics only > boundary stated

效率：

boundary stated > logistics only > none > boundary plus scenario walkthrough

支配性检查：只是构造上的干净，而构造上的干净永远不算通过。 这里价值与投入的排序也完全一致，所以同样是 一个机制阻挡了全部六对组合：每对中价值更高的层级严格更费投入，没有一对能幸存下来接受合规检验。

合规轴是非单调的，并确实重新排序了效率行。重新排序和拯救是两件不同的事，而它只做了前者。不存在任何支配关系，检查验证不了什么，排序依赖于下面的论证。

合规轴是作者身份污染（authorship contamination），并且它有意镜像了
samber/dev-event-organizer-skills@hackathon-judging
的利益冲突模式。一位导师在没有声明边界的情况下把代码写进团队的仓库，会制造一个作者身份可争议的问题。它会在颁奖仪式上浮出水面，奖品摆在桌上，却没有任何已发布的东西可以指向：这是最不可逆的时刻。

这就是为什么 “无briefing”在投入上最便宜，在合规成本上却第二高，也为什么默认选项不是最便宜的层级。这种风险是真实而非理论上的：

samber/dev-event-organizer-skills@hackathon-brief-design

引用了一项已发布的要求：提交的代码必须公开并保持公开才能保持获奖资格，因此提交历史可读，提交是谁的也可读。

场景走查出于相反的原因在同一轴上居首。它是一份书面标准，活动之后可以据此被追责，因此它在发布前会触发审查，并且一旦导师已经据此接受briefing，它就是最难撤回的层级。这与

samber/dev-event-organizer-skills@hackathon-judging

的披露登记层级形状相同，后者正因为这个原因在其自己的合规轴上居首。

明确陈述边界（Boundary stated explicitly） - 默认选项，也是四个层级中合规成本最低的。在活动之前一次性决定这条线，此时它只花一句话，而且窗口期中的提醒仍然可以纠正它。这条边界是你设定的一条线，而不是可引用的标准，其措辞连同完整的正反对照示例，见 references/mentor-briefing-and-request-mechanic.md。
仅后勤（Logistics only） - 在哪里、什么时间、哪个频道、向谁升级。必要但绝不充分：它让导师实际面对的那个问题得不到回答。MLH 的指南接近这个层级，要求一份导师指南涵盖“要问 hackers 什么问题、如何与 hacker 一起排查、以及有用的初学者工具/资源”，并给出“一套导师在指导期间该做什么的准则，给他们一个流程”，而把帮助与代做的界线留给组织者。
无briefing（None） - 只要任何奖品带有现金价值，或任何赞助商资助奖品（Q6），就把它从本菜单和上面的轴线上删除。 这镜像了
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
以相同触发条件和相同原因删除其自身最小规则层级的做法：有价值的奖品会把分歧变成索赔，而未经briefing的导师的一个 commit 会变成无人能回答的资格问题。
边界加场景走查（Boundary plus scenario walkthrough） - 被忽视的选项：价值、投入和合规成本都居首。提升条件（与Q7和Q4相关）：大多数导师以前从未指导过，或赞助商员工正在指导其雇主有商业利益的代码库，或活动会重复举办，走查写一次即可跨届复用。

无论层级如何，briefing中不可协商的内容、权力动态指导，以及指向行为准则管道的升级指针，都见 references/mentor-briefing-and-request-mechanic.md。

Rotation by expertise

按专业轮转

Shift length, arrival buffers, sign-up confirmation and no-show backfill are

samber/dev-event-organizer-skills@event-volunteers

' arithmetic; re-derive none of it here. Your contribution to the grid is one constraint: the expertise the schedule needs present, hour by hour. That means the sponsor-API specialist rostered onto the hours that track is actually being worked, not merely somebody rostered onto the floor.

Take the slot from the mentor at sign-up. Two published mechanics support this: "a form to get the interested people to register, asking them to pick a timeslot", and "give slots to each mentor so that they know their timings better, though encouraging them to be present throughout the hackathon". The source leaves a tension there, assigned slots alongside an ask to be around anyway. Resolve it in the grid rather than in the briefing: a slot is a commitment, presence beyond it is a courtesy, and only one of the two can be scheduled against.

Stagger specialty coverage against when teams need each one, rather than rostering every specialty for the same uniform hours. A track that opens with problem-definition work needs its early-stage mentors soonest. A track that only becomes buildable once a team has a direction needs its technical mentors later. Read the brief's own sequencing wherever the grid allows it, never a flat everyone-from-open-to-close roster.

Opportunity Hack's mentor guide publishes the same staggering against build progress: validation mentors early, debugging mentors mid-event, completion mentors once a team "should already be writing code," and presentation mentors in the final stretch. It staffs each stage with a named specialization (Product, GitHub, cloud deployment, Software Engineering) rather than one undifferentiated pool.

Give each assigned mentor a checkable visit cadence for their own slice of the roster, not just a presence window. A minimum check-in frequency per assigned team, a number this event sets for itself, turns "be available" into something a mentor can satisfy and an organizer can verify. Stop scheduled visits ahead of the final stretch, so teams get an uninterrupted run-in rather than a last-minute redirect competing with their own finishing work.

Two decisions the grid leaves to you:

The overnight hours. A hackathon window can run through the night where a conference day does not, so a rotation built on daytime assumptions leaves the hours with the most blocked teams uncovered. Decide deliberately whether those hours are staffed, thinly staffed, or published as unstaffed, and publish whichever it is.
The uncovered skill. When no mentor on the roster covers a needed skill, the escalation is a published route rather than an improvisation. Name in advance who is asked, and what a team is told when the answer is nobody.

轮班长度、到达缓冲、报名确认和缺席补位都是

samber/dev-event-organizer-skills@event-volunteers

的算法；这里不重新推导任何一项。你对网格的贡献是一个约束：排班每小时需要哪些专业知识在场。 也就是说，赞助商API专家要排到该赛道实际被攻关的小时，而不仅仅是排一个人到现场。

在报名时从导师那里获取时段。 两个已发布的机制支持这一点：“用表格让感兴趣的人注册，请他们选择一个时间段”，以及“给每位导师分配时段，让他们更好地知道自己的时间安排，同时鼓励他们在整个黑客松期间都在场”。来源在这里留下了一个张力：分配时段的同时又要求大家尽量在场。要在网格中解决，而不是在 briefing 中解决：一个时段是一项承诺，时段之外到场是一种礼貌，两者之中只有一样可以用于排班。

错开专业覆盖，按照团队何时需要每一类专业来安排，而不是让每个专业都排同样的统一时段。 以问题定义工作开场的赛道需要其早期导师最先到场。只有当团队确定方向后才变得可构建的赛道，其技术导师需要晚一些。只要网格允许，就阅读 brief 自己的时序，绝不要使用一份从开始到结束所有人都在的扁平名册。

Opportunity Hack 的导师指南发布了同样的按构建进度错开的做法：早期是验证导师，活动中期是调试导师，一旦团队“应该已经在写代码”就是完成导师，最后冲刺阶段是演示导师。它用具名的专业方向（Product、GitHub、云部署、软件工程）来配置每个阶段，而不是一个无差别的池子。

给每位被分配的导师一个可核查的访问节奏，用于他们自己的名册切片，而不仅仅是一个在场时间窗。 为每支被分配的团队设定一个最低检查频率——这个数值由活动自己设定——把“随时可用”变成导师可以满足、组织者可以核查的事情。在最后冲刺之前停止计划中的访问，让团队有一段不被打断的冲刺，而不是在最后一刻被一个与他们自己的收尾工作争抢注意力的改道打断。

网格留给你两个决定：

通宵时段。 黑客松窗口可以持续整夜，而会议日不会，因此基于白天假设的轮转会留下阻塞团队最多的小时无人覆盖。要刻意决定这些小时是有人值守、稀少值守，还是公布为无人值守，并公布其中的一种。
未被覆盖的技能。 当名册上没有导师覆盖所需技能时，升级路径是一条已公布的路径，而不是临时发挥。提前说明会去问谁，以及当答案是“没人”时，团队会被告知什么。

Interruption discipline

中断纪律

Push coverage means mentors roaming rather than waiting for a request, and it is the coverage teams consistently prefer: nobody has to notice they are stuck before getting help. Left uncoordinated, it delivers the opposite of what it promises: a team re-pitching its project to every mentor who wanders past, minutes lost each time, and a mentor pool with no record of who already visited whom.

Keep push coverage rather than replacing it with the request mechanic above, since the two solve different problems. Rate-limit the push instead:

A per-visit time cap, with a timer the team can see, relaxed only for genuinely hands-on work that cannot be boxed.
A "do not disturb" signal the team controls itself, visible from across the room.
A published list of what each present mentor actually knows, so a team using the request mechanic above reaches the right person by name.
A shared, live view of which teams are currently blocked and on what, so an idle mentor finds the team that needs them next instead of re-visiting one that does not.

The failure signature to watch for: several mentors with overlapping expertise visiting the same team inside one short window while another team goes untouched for hours. That is a coordination gap rather than a coverage-depth gap. The coverage-depth menu above cannot fix it, and only a shared view of who has been where can.

推送式覆盖（push coverage）意味着导师四处走动，而不是等待请求，这也是团队一贯更喜欢的覆盖方式：没有人必须先意识到自己卡住了才能获得帮助。如果缺乏协调，它就会交付与承诺相反的结果：一支团队向每一位路过导师重新推销自己的项目，每次都损失几分钟，而且导师池没有任何记录表明谁已经访问过谁。

保留推送式覆盖，而不是用上面的请求机制替换它，因为两者解决的是不同的问题。相反，要对推送进行限速：

每次访问设置时间上限，并配一个团队能看到的计时器，只有真正无法装箱的动手协作才能放宽。
一个由团队自己控制的“请勿打扰”信号，隔着房间就能看到。
一份已发布的清单，列出每位在场导师真正了解什么，这样使用上面请求机制的团队可以按名字找到对的人。
一个共享的实时视图，显示哪些团队当前被阻塞、被什么阻塞，这样空闲的导师能找到下一个需要他们的团队，而不是重访一个不需要的团队。

要警惕的失败特征：多位专业重叠的导师在一个短时间窗口内访问同一支团队，而另一支团队数小时无人问津。这是协调缺口，而不是覆盖深度缺口。上面的覆盖深度菜单无法修复它，只有“谁去过哪里”的共享视图才能。

Failure modes

失败模式

Turning the themed-event expert ratio into a mentor-staffing formula. The one figure that exists counts domain experts embedded in projects at themed events, per non-expert participant, and it is a project-supply target rather than a staffing one. It counts neither mentors nor teams, and it transfers to no open-theme or sponsor-track event. Fix: size coverage against the brief's tracks and the hours they are worked.
A sponsor track promised in the brief and unstaffed on the floor. The brief's fallback sentence assumes the platform gets support; a sole-substrate integration with an available-if-you-find-them mentor is the promise breaking quietly. Fix: read the integration depth (Q2) before setting coverage depth.
Mentors nobody can identify. The cheapest failure on this page: mentors present, participants unable to tell who they are, and a room that concludes there is no help. Fix: a marker and a named role, before anything more elaborate.
A mentor who takes the keyboard. It resolves the bug and it contaminates the authorship of a submission that will be judged and possibly paid. Fix: state the boundary in the briefing, and say what a mentor does instead.
Rebuilding the shift grid here. Sizing, buffers and backfill already exist next door and are better derived there. Fix: hand over the expertise constraint and let that skill schedule against it.
Briefing a mentor as if they were a judge. Two documents, two audiences, one word. Fix: say "mentor briefing" every time.
A mentor who judges a team they carried. Fix: keep the contact log whenever a mentor is also judging, and hand it over before the judge pool is fixed.
Office hours as the whole mechanic on an overnight event. Fix: office hours supplement a latency mechanic; they never replace one.
Roaming mentors with no shared record of who visited whom. Coverage exists and nobody can tell which teams still need it, so mentors cluster on whichever team pitched loudest last while another goes untouched for hours. Fix: rate-limit the visits and share a blocked-team view, not just recruit more mentors.

把主题活动的专家比率变成导师人员配置公式。 存在的唯一数字统计的是主题活动中嵌入项目的领域专家，按非专家参与者计算，它是一个项目供给目标，而不是人员配置目标。它统计的既不是导师也不是团队，也无法迁移到任何开放主题或赞助商赛道活动。修复方法：根据 brief 的赛道及其被攻关的小时来确定覆盖规模。
brief 中承诺了赞助商赛道，现场却没有配置人员。 brief 的后备语句默认该平台会得到支持；单一基底集成配上一个“找到才算有”的导师，就是承诺在悄悄破裂。修复方法：在设置覆盖深度之前，先阅读集成深度（Q2）。
没人能认出的导师。 本页面最便宜的失败：导师在场，参与者无法分辨他们是谁，整个房间得出结论：没有帮助。修复方法：在做任何更复杂的事情之前，先给标识和具名角色。
夺过键盘的导师。 它解决了 bug，却污染了一份将被评审、甚至可能获奖的提交的作者身份。修复方法：在 briefing 中说明边界，并说明导师应该做什么。
在这里重新构建轮班表。 规模、缓冲和补位在隔壁已经存在，而且在那里推导更好。修复方法：移交专业约束，让那个 skill 据此排班。
像给评委一样给导师做 briefing。 两份文档、两类受众、一个词。修复方法：每次都说明是“导师 briefing（mentor briefing）”。
导师评审自己带过的团队。 修复方法：当导师同时担任评委时保留接触日志，并在评委池确定之前移交。
在通宵活动中把 office hours 当作全部机制。 修复方法：office hours 补充延迟机制；它们从不替代延迟机制。
四处走动的导师没有共享的“谁访问过谁”记录。 覆盖存在，但没人能分辨哪些团队仍然需要它，于是导师们聚集在刚才推销得最响亮的团队周围，而另一支团队数小时无人问津。修复方法：对访问限速并共享阻塞团队视图，而不是仅仅招募更多导师。

Measurement

度量

Every threshold below is self-set rather than an industry standard. Say so when presenting it, and compare it only against this event's own previous edition.

Pass threshold (structural, one only): before the hacking window opens, all five exist in writing with zero blanks. Iterate until the count is five.

The expertise tags mapped onto the brief's tracks.
The coverage commitment per track.
The request mechanic as teams will read it.
The mentor briefing including the boundary sentence.
The escalation route for a skill no mentor covers.

Signals worth recording during the window (self-set):

Requests that waited longest and which track they came from.
Hours where a track had no tagged mentor present.
Requests that found nobody at all.
If any mentor judges, the contact log itself.

Pick two or three, write down the revision each would trigger, and record them live rather than reconstructing them afterwards.

下面的每个阈值都是自设的，而不是行业标准。呈现时要说明这一点，并且只与本次活动自己的往届比较。

通过阈值（结构性，只有一个）：在黑客窗口开启前，以下五项全部书面存在，零空白。 迭代直到数量为五。

映射到 brief 赛道的专业知识标签。
每条赛道的覆盖承诺。
请求机制，按团队会读到的形式。
导师 briefing，包括边界语句。
没有导师覆盖的技能所需的升级路径。

窗口期内值得记录的信号（自设）：

等待最久的请求，以及它们来自哪条赛道。
某条赛道没有带标签导师在场的小时。
完全没有找到人的请求。
如果有导师担任评委，接触日志本身。

挑两到三个，写下每个信号会触发的修订，并实时记录，而不是事后重建。

Invocation examples

调用示例

"We have 200 hackers and a sponsor API track. How many mentors, and who?"
"How does a stuck team actually get hold of a mentor at 2am?"
"Write the mentor briefing - what are they allowed to do to someone's repo?"
"Our sponsor wants to send four engineers as mentors. What do we agree in writing?"
"One of our mentors is also judging. Is that a problem?"

Expected output: a mentor plan with:

Coverage depth per challenge track with its rung named.
The recruitment channels and their lead times.
The expertise tags mapped onto the brief's tracks.
The expertise constraint handed to the shift plan.
The request mechanic as participants will read it.
The mentor briefing including the boundary and the escalation pointer.
The contact log decision.
The interruption rate-limit mechanics, where coverage is push-based.

Present it section by section for validation before the window opens.

“我们有 200 名 hacker 和一个赞助商 API 赛道。需要多少导师，以及谁？”
“凌晨 2 点，一支卡住的团队到底怎么联系到导师？”
“写导师 briefing——他们可以对别人的 repo 做什么？”
“我们的赞助商想派四名工程师担任导师。我们在书面上约定什么？”
“我们的一位导师同时也是评委。这有问题吗？”

预期输出：一份导师计划，包含：

每条挑战赛道的覆盖深度，并标明其层级。
招募渠道及其前置时间。
映射到 brief 赛道的专业知识标签。
交给轮班计划的专业约束。
请求机制，按参与者会读到的形式。
导师 briefing，包括边界和升级指针。
接触日志决策。
推送式覆盖下的中断限速机制。

在窗口开启前，逐节展示以供验证。

References

参考

references/coverage-and-recruitment.md - coverage sizing against tracks rather than headcount, the themed-event ratio with its full scoping, expertise-tag vocabulary, the recruitment channels with their lead times and the sponsor-deliverable framing, and the escalation route when no mentor covers a skill.
references/mentor-briefing-and-request-mechanic.md - the mentor briefing contents with the help-versus-build boundary written out, a positive and negative worked pair, power-dynamics guidance, the sponsor-rep engagement rule, and the request mechanic published as participants read it.