hackathon-judging

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Hackathon Judging

Hackathon 评审

You design how a hackathon decides who won: the rubric, the scale, who scores what, how scores combine, how ties break, how conflicts of interest resolve, and how the result is announced and challenged.

Two inputs arrive already decided. Consume them, never re-open them:

The demo/judging structure (Expo Table, Stage Pitch, Video Only, or the two-stage hybrid) belongs to
```
samber/dev-event-organizer-skills@event-format-selection
```
. It fixes per-team judge-contact time, live or async judging, and whether judges rotate in parallel or sit as one panel.
The evaluation categories named in the published challenge document belong to
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
. Weight them and build the mechanics on top.

Never set a prize amount or its legal structure.

samber/dev-event-organizer-skills@hackathon-cash-prize

turns the ranked outcome into a payout.

Judges are not mentors:

Mentors help teams build during the hacking window (
```
samber/dev-event-organizer-skills@hackathon-mentoring
```
).
Judges evaluate finished projects afterwards.

Small events reuse the same people for both. That is a staffing convenience, not one role.

Every ranking below is a default, not a law. Re-rank each menu after the interview. Any of these overturns a default rung:

A returning jury.
Last edition's rubric.
A sponsor contract already signed.
A ceremony start time that cannot move.

你设计 hackathon 如何决定谁获胜：评分细则、量表、谁给什么打分、分数如何合并、平局如何打破、利益冲突如何解决，以及结果如何公布和质疑。

有两个输入已经确定。接受它们，不要重新讨论：

演示/评审结构（Expo Table、Stage Pitch、Video Only，或两阶段混合）属于
```
samber/dev-event-organizer-skills@event-format-selection
```
。它确定每支队伍与评委的接触时间、是现场评审还是异步评审，以及评委是并行轮转还是作为一个评审团集中就座。
已发布的挑战文档中点名的评估类别属于
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
。为它们分配权重，并在此基础上构建机制。

绝不要设定奖金金额或其法律结构。

samber/dev-event-organizer-skills@hackathon-cash-prize

会把排名结果转化为实际支付。

评委不是导师：

导师在 hackathon 期间帮助团队构建（

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

）。

评委在结束后评估已完成的项目。

小型活动会让同一批人兼任两者。这是人员安排的便利，不是同一个角色。

下面的每一个排序都是默认值，不是铁律。访谈后重新排序每个菜单。以下任何一项都会推翻默认档位：

有往届评审团回归。
上一届的 rubric。
已签署的赞助合同。
无法移动的典礼开始时间。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 3-6 exist because the menus below turn on them, and no default can be picked without those answers.

Which demo/judging structure is already chosen, and what per-team judge-contact time does it assume? (Fixed input. Do not re-decide it here.)
Which evaluation categories does the published brief already name? (Also fixed. Weight them, never replace them.)
How many teams are expected to submit, and how many minutes run between submission close and ceremony start? Minutes, not "an afternoon". The allocation menu is arithmetic and needs both numbers.
How many judges are confirmed, and can they all be in one room at the same time?
Which prizes and tracks exist, does any sponsor fund one, and does any signed sponsorship agreement require that sponsor's own representative to judge its track?
Will teams receive per-team feedback, and is there a window after the ceremony to write it in?
What did the published rules already promise about criteria, tie-breaking and disputes, and is this a one-off edition or a recurring event whose rules should still hold next year? Read the rules first. The process executes what was published, not what is convenient.
What is the effort ceiling: organizer hours before the ceremony, volunteers for a pre-screen round, and who holds authority to break a tie on the record?

一次只问一个问题，尽量使用选择题。问题 3-6 之所以存在，是因为下面的菜单依赖它们，没有这些答案就无法选择默认项。

已经选择了哪种演示/评审结构，它假定的每队评委接触时间是多少？（固定输入。不要在这里重新决定。）
已发布的 brief 已经点名了哪些评估类别？（也是固定的。给它们加权，绝不替换。）
预计有多少队伍提交，从提交截止到典礼开始有多少分钟？要分钟数，不要“一个下午”。分配菜单是算术，需要这两个数字。
已确认多少名评委，他们能否同时都在一个房间里？
存在哪些奖品和赛道，是否有赞助商资助其中一条，是否有已签署的赞助协议要求该赞助商自己的代表评审其赛道？
团队是否会收到每队反馈，典礼后是否有窗口可以写入这些反馈？
已发布的规则已经承诺了哪些关于标准、平局和争议的内容？这是一次性活动还是规则明年仍应有效的周期性活动？先读规则。流程执行的是已经发布的内容，而不是方便的内容。
工作量上限是什么：典礼前组织者可投入的小时数、用于预筛选轮的志愿者，以及谁有权在记录中打破平局？

Workflow

工作流

Run the interview. Read the published rules (Q7) and the brief's categories (Q2) before designing anything.
Compute the allocation band from Q1, Q3 and Q4 first, before the rubric. It deletes rungs from every other menu, and it is the one step that can make a plan impossible rather than merely expensive. Load references/judge-allocation-math.md.
Weight the brief's categories and pick the scale. Write both down before anyone scores. A rubric changed mid-round re-scores whichever teams were seen first.
Fix the combination rule - raw average, per-judge normalization, or consensus - against the allocation band from step 2, never independently of it.
Write the tie-break ladder as a deterministic list, and publish it before submissions close.
Brief judges before scoring opens: criteria and weights, scale, conflict-of-interest rule, their own slice of the allocation map, and what to do if they fall behind.
Build the allocation map as a named list: judge, teams, order, start time. An unassigned judge wanders, and an unvisited team is a dispute.
Score, combine, and check the arithmetic feasibility gate before the ceremony (see Measurement).
Announce from a prepared list, and hold the contest path open for the window the rules stated. Load references/coi-and-results-policy.md.
Record what happened: teams visited, recusals fired, challenges received. Hand the ranked outcome per track to
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
.

Present the design for validation section by section, before judging opens:

Allocation
Rubric
Combination rule
Tie-break ladder
Conflict rule
Announcement plan

Once scoring starts, changing the rules invalidates whatever was already scored.

If your harness has persistent memory, record the weights, the allocation band and its inputs, the tie-break ladder, and the specific complaint each would need to hear to change next edition.

进行访谈。在设计任何东西之前，先阅读已发布的规则（Q7）和 brief 的类别（Q2）。
在 rubric 之前，先根据 Q1、Q3 和 Q4 计算分配区间。它会从其他每个菜单中删除一些档位，并且它是唯一可能让计划变得不可能（而不仅仅是昂贵）的步骤。加载 references/judge-allocation-math.md。
给 brief 的类别加权并选择量表。在任何人打分之前把两者写下来。评审中途修改 rubric 会重评最先被看到的队伍。
根据第 2 步的分配区间确定合并规则——原始平均、按评委归一化或共识——绝不能脱离它独立决定。
将平局打破阶梯写成确定性列表，并在提交截止前公布。
在评分开始前向评委做简报：标准和权重、量表、利益冲突规则、他们自己的分配图切片，以及如果他们落后了该怎么做。
将分配图构建为具名列表：评委、队伍、顺序、开始时间。未分配任务的评委在游荡，未被访问的队伍就是争议。
在典礼前评分、合并并检查算术可行性门槛（见测量）。
从准备好的列表宣布结果，并按照规则声明的窗口保持争议路径开放。加载 references/coi-and-results-policy.md。
记录发生了什么：访问了哪些队伍、触发了哪些回避、收到了哪些异议。将每个赛道的排名结果交给
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
。

在评审开始前，逐节呈现设计以供验证：

分配
Rubric
合并规则
平局打破阶梯
冲突规则
公告计划

一旦评分开始，更改规则会使已经评过分的内容失效。

如果你的 harness 有持久记忆，记录权重、分配区间及其输入、平局打破阶梯，以及每个问题要听到什么具体投诉才会在下一版修改。

Judge allocation depth

评委分配深度

Recruiting more judges does not let full coverage reach more teams. The cap is

N ≤ W / t

, and no

appears in it: under full coverage each judge personally traverses all

teams, so the judge count cancels out of the inequality. What the cap limits is the team count, never the judge count and never the window.

This menu bends on arithmetic rather than taste. Four quantities drive it:

```
N
```
- teams expected to submit (Q3).
```
t
```
- minutes of judge time per team, fixed by the format (Q1).
```
W
```
- minutes of judging window (Q3).
```
J
```
- confirmed judges (Q4).

Timing inputs for

10 minutes per team at a live multi-team demo handoff: 3 minutes demo, 1-2 minutes Q&A, 5-6 minutes setup and swap. MLH gives this figure for ceremony demo slots, not for a judging round, so what carries over is the setup and swap tax, not the audience. A judging block holds no crowd and can run tighter.
3-5 minutes per team at an Expo Table.
2-5 minutes plus Q&A at a Stage Pitch.
4 minutes per project, 3 rounds of judging per project at MLH's own science-fair judging round: 2 minutes presentation and demo, 1 minute questions and score compilation, 1 minute judge travel. That is MLH's published judges-per-project default, close to the Expo Table figure above.

The 3-5 and 2-5 minute figures allow nothing for setup or swap, so every ceiling built on them is an optimistic upper bound rather than a capacity promise. Say so when presenting the number.

Two crossovers, computed from those inputs:

A 120-minute window at 10 minutes per team caps full coverage at 12 teams.
The same window at 5 minutes per team caps it at 24 teams.

Halving

doubles the teams full coverage reaches. It changes nothing about the judge count or the window.

Ranking (default, not a law - Q3, Q4 and Q8 re-rank it):

value (comparability of the projects that actually get ranked, judge calibration, defensibility of the podium):
```
full coverage > sampled panel > triage-then-finals > single judge per team
```

effort (judge-hours, plus the routing and rounds an organizer has to run):

full coverage > triage-then-finals > sampled panel > single judge per team

The two axes genuinely disagree, so efficiency is published per band rather than as one line. The order flips at an arithmetic boundary, never on preference:

Band 1,
N ≤ W / t
: efficiency
```
full coverage > sampled panel > single judge per team > triage-then-finals
```
. Full coverage needs no allocation map at all and buys maximum comparability. Triage is pure overhead when everyone already fits.
Band 2,
W / t < N ≤ (J × W) / t
: full coverage is deleted here, from this menu and from the axis lines above - it is arithmetically impossible, not merely expensive. Efficiency:
```
sampled panel > single judge per team > triage-then-finals
```
. Coverage per team is
```
k = floor((J × W) / (N × t))
```
judges.
Band 3,
N > (J × W) / t
: sampled panel and single-judge are both deleted from this menu and from the axis lines above - even one judge per team does not fit. Triage-then-finals is the only live-window allocation left. Where the format is still open, hand back to
```
samber/dev-event-organizer-skills@event-format-selection
```
instead: async video judging is a format change, and that skill decides it.

Dominance check, re-derived: clean by care. One strict-dominance relation exists: sampled panel has higher value and lower effort than triage-then-finals. Every band's efficiency line honours it. A wrong ordering would have failed the check, so this pass means something.

Full coverage never dominates (top of the effort axis).
Single-judge never dominates (bottom of the value axis).
Triage never dominates sampled panel on either axis.

What the efficiency order starves:

Full coverage - top of both axes, so efficiency abandons it the moment Band 1 ends. Promotion condition, keyed to Q3: a team count that fits
```
W / t
```
. Check the arithmetic rather than the feeling that "we're small".
Triage-then-finals - cheap on nothing, and justified only in Band 3. Promote it earlier only when Q8 confirms a volunteer crew for a published pass/fail pre-screen.

Worked allocation maps, the

computation, and the band boundaries with numbers are in references/judge-allocation-math.md.

**招募更多评委并不能让全覆盖触达更多队伍。**上限是

N ≤ W / t

，其中没有

：在全覆盖下，每位评委亲自遍历所有

支队伍，所以评委数量从这个不等式中消掉了。这个上限限制的是队伍数量，而不是评委数量，也不是评审窗口。

这个菜单由算术而非品味决定。四个量驱动它：

```
N
```
- 预计提交的队伍数（Q3）。
```
t
```
- 每队评委时间分钟数，由格式确定（Q1）。
```
W
```
- 评审窗口分钟数（Q3）。
```
J
```
- 已确认的评委数（Q4）。

的时间输入：

现场多队演示交接时每队 10 分钟：3 分钟演示，1-2 分钟问答，5-6 分钟设置和切换。MLH 给出的是典礼演示时段的数据，不是评审轮次，因此可迁移的是设置和切换成本，而不是观众。评审段没有人群，可以运行得更紧凑。
Expo Table 每队 3-5 分钟。
Stage Pitch 2-5 分钟加问答。
MLH 自己的科学展评审轮中，每个项目 4 分钟，每个项目进行 3 轮评审：2 分钟展示和演示，1 分钟提问和分数汇总，1 分钟评委移动。这是 MLH 已发布的每项目默认评委数，接近上面的 Expo Table 数字。

3-5 和 2-5 分钟的数字没有为设置或切换留时间，所以基于它们构建的每个上限都是乐观上界，而不是容量承诺。在呈现这个数字时说明这一点。

根据这些输入计算两个交叉点：

120 分钟窗口、每队 10 分钟，将全覆盖上限设为 12 支队伍。
同一窗口、每队 5 分钟，将其上限设为 24 支队伍。

将

减半会使全覆盖触达的队伍数翻倍。它不会改变评委数量或窗口。

排序（默认，不是铁律——Q3、Q4 和 Q8 会重新排序）：

价值（实际被排名的项目之间的可比性、评委校准、领奖台的可辩护性）：
```
full coverage > sampled panel > triage-then-finals > single judge per team
```
工作量（评委小时数，加上组织者必须运行的路线和轮次）：
```
full coverage > triage-then-finals > sampled panel > single judge per team
```

这两个轴确实不一致，因此效率按区间发布，而不是一行。顺序在算术边界处翻转，而不是基于偏好：

区间 1，
N ≤ W / t
：效率
```
full coverage > sampled panel > single judge per team > triage-then-finals
```
。全覆盖根本不需要分配图，并能带来最大的可比性。当每个人都已经装得下时，triage 纯粹是额外开销。
区间 2，
W / t < N ≤ (J × W) / t
：全覆盖在这里被删除，从这个菜单和上面的轴线上删除——它在算术上不可能，而不仅仅是昂贵。效率：
```
sampled panel > single judge per team > triage-then-finals
```
。每支队伍覆盖的评委数为
```
k = floor((J × W) / (N × t))
```
。
区间 3，
N > (J × W) / t
：sampled panel 和 single-judge 都从这个菜单和上面的轴线上删除——即使每队一位评委也装不下。triage-then-finals 是唯一剩下的实时窗口分配方式。如果格式仍然开放，交回给
```
samber/dev-event-organizer-skills@event-format-selection
```
代替：异步视频评审是格式变更，由那个 skill 决定。

支配关系检查，重新推导：因小心而干净。 存在一个严格支配关系：sampled panel 在价值上更高，在工作量上更低，均优于 triage-then-finals。每个区间的效率行都遵守它。错误的顺序会违反检查，所以这一遍是有意义的。

Full coverage 从不支配（工作量轴顶端）。
Single-judge 从不支配（价值轴底端）。
Triage 在任一轴上都不支配 sampled panel。

效率顺序让什么饿死：

Full coverage —— 两个轴的顶端，所以区间 1 一结束，效率就抛弃它。晋升条件，与 Q3 挂钩：满足
```
W / t
```
的队伍数量。检查算术，而不是“我们很小”的感觉。
Triage-then-finals —— 什么都便宜不了，只在区间 3 中合理。只有当 Q8 确认有一组志愿者执行已发布的 pass/fail 预筛时，才可以提前晋升它。

实际的分配图、

的计算以及带数字的区间边界在 references/judge-allocation-math.md。

Rubric depth and weighting

Rubric 深度与加权

Weight the categories the brief already named (Q2). Ranking (default, not a law - Q1 and Q6 re-rank it):

value (defensibility to teams and sponsors, dispute resistance, usable tie-break input):

weighted criteria plus written per-criterion comment > weighted criteria > named criteria unweighted > single overall score

effort (judge briefing, per-team time consumed inside the slot, organizer setup):

weighted criteria plus written per-criterion comment > weighted criteria > named criteria unweighted > single overall score

efficiency:

weighted criteria > named criteria unweighted > single overall score > weighted criteria plus written per-criterion comment

Dominance check, re-derived: clean only by construction, and this is not a pass. Value and effort run in the same order, so no pair exists where one option has value >= another and effort <= it. With no dominance relation to violate, the check cannot catch a misordering here. The ordering rests on the argument below, not on the check.

Weighted criteria - the default. Deciding the weights is a one-off cost paid before the event, and the scoring sheet does the arithmetic, so the marginal cost inside a 3-5 minute slot is zero. It buys the two things unweighted criteria cannot:
- A sponsor can see its challenge is actually valued.
- A tie has a principled first tiebreaker.
Named criteria, unweighted - cheaper by one decision, and the decision does not disappear. Each judge applies private weights instead, so a technical judge and a business judge silently score different competitions. Legitimate only where the categories are genuinely equal in the organizers' minds.
Single overall score - cheapest, and it buys nothing defensible, because a bare number cannot say why. Delete it, from this menu and from the axis lines above, as soon as more than one track awards a prize (Q5). One number cannot separate track winners, and parking it at the bottom quietly reintroduces the problem at the ceremony.
Weighted criteria plus mandatory written per-criterion comment - the starved option: top of value, top of effort, so efficiency never picks it. The effort lands in the one place a hackathon has none, inside the live slot. Judges have minutes per team, not days.
- Promotion condition, keyed to Q1 and Q6: judging is Video Only or otherwise async, or teams are promised per-team feedback and a post-event window exists to write it in. In both cases the comment costs no live minutes.

Scale shape is a separate decision from weighting. Two shapes:

A numeric 1-5 or 1-10 scale per criterion - the default, and the one a judge can hold in their head between two tables.
A named capability ladder with explicit point deltas, including a negative delta for the trivial path. Use it on a criterion that should actively discourage the cheapest route rather than merely fail to reward it: the ladder states a reward structure a plain numeric scale leaves implicit. Normalize the open-ended ladder total to the published scale with a cohort min-max pass, so the internal rubric stays expressive while judges and teams see one comparable number.

The ladder pattern, the normalization formula, scale choice, weighting worked examples, and a positive and negative scoring pair are in references/rubric-and-scoring-mechanics.md.

为 brief 已经点名的类别加权（Q2）。排序（默认，不是铁律——Q1 和 Q6 会重新排序）：

价值（对团队和赞助商的可辩护性、抗争议性、可用的平局打破输入）：

weighted criteria plus written per-criterion comment > weighted criteria > named criteria unweighted > single overall score

工作量（评委简报、时段内消耗的每队时间、组织者设置）：

weighted criteria plus written per-criterion comment > weighted criteria > named criteria unweighted > single overall score

效率：

weighted criteria > named criteria unweighted > single overall score > weighted criteria plus written per-criterion comment

支配关系检查，重新推导：仅靠构造干净，这不是通过。 价值和工作量按相同顺序运行，因此不存在一个选项在价值上 >= 另一个且工作量 <= 它的情况。没有可违反的支配关系，检查就无法在这里捕捉到错误排序。这个排序依据的是下面的论证，而不是检查。

加权标准 —— 默认。决定权重是在活动前支付的一次性成本，评分表完成算术，因此 3-5 分钟时段内的边际成本为零。它买到了未加权标准买不到的两样东西：
- 赞助商可以看到自己的挑战确实被重视。
- 平局有一个有原则的第一平局打破器。
点名标准但未加权 —— 少一个决定更便宜，但那个决定并没有消失。每位评委改为应用私人权重，因此技术评委和商业评委悄悄地在评不同的比赛。只有在组织者真心认为这些类别完全相等时才合理。
单一总分 —— 最便宜，但它买不到任何可辩护的东西，因为一个光秃秃的数字无法说明原因。一旦超过一个赛道颁发奖品，就从本菜单和上面的轴线上删除它（Q5）。一个数字无法区分各赛道的获胜者，把它放在底部会在典礼上悄悄重新引入问题。
加权标准加每个标准的强制书面评语 —— 被饿死的选项：价值最高、工作量最高，所以效率永远不会选它。工作量落在 hackathon 最没有的地方：实时时段内。评委每队只有几分钟，而不是几天。
- 晋升条件，与 Q1 和 Q6 挂钩：评审是 Video Only 或异步的，或团队被承诺每队反馈，并且存在活动后的窗口来写入反馈。在两种情况下，评语都不消耗实时分钟数。

量表形状是与加权分开的决定。两种形状：

每个标准一个 1-5 或 1-10 数字量表 —— 默认，也是评委在两张桌子之间能在脑中保持的量表。
带有明确分数增量的命名能力阶梯，包括对最廉价路径的负增量。在某个标准上使用它，应主动劝阻最便宜的路线，而不仅仅是拒绝奖励它：阶梯陈述了普通数字量表保持隐含的奖励结构。通过 cohort 最小-最大归一化将开放式阶梯总分归一化到已发布的量表，这样内部 rubric 保持表现力，而评委和团队看到一个可比较的数字。

阶梯模式、归一化公式、量表选择、加权示例，以及一对正负评分示例，都在 references/rubric-and-scoring-mechanics.md。

Elimination criteria

淘汰标准

A rubric scores degree. An elimination gate answers yes or no, disqualifying a submission whatever its weighted score. Keep the two as separate artifacts: a knockout condition folded into a rubric line reads as merely low-scoring instead of disqualifying.

Write elimination rules against the specific ways this event's own theme invites gaming, never a generic list copied from another event:

A hacked or circumvented tool.
The required technology present but not central to the project - "we could have done without it."
A technology generation too old or too simple to meet the brief's stated ambition.
A design file with no working build, where the brief required at least code or no-code.
Code that never went public, where the brief's submission checklist required it.

Publish the full list alongside the category names in the brief. Write the rules here;

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

prints them next to the eligibility text.

Publishing the category names and the elimination list satisfies disclosure. The numeric weight does not have to. The failure named below is a team entering blind to what is judged at all, and named categories plus a full knockout list already prevent it. Withholding the weight itself, once those are public, is a legitimate anti-gaming choice: it stops a team optimizing to the decimal place against a figure that was never theirs to see.

Rubric 对程度打分。淘汰门槛回答是或否，无论加权分数如何都取消提交资格。将两者作为独立产物：折叠进 rubric 一行的淘汰条件会被读作仅仅是低分，而不是取消资格。

针对本次活动主题本身特有的作弊方式编写淘汰规则，绝不是从另一个活动复制的通用列表：

被破解或绕过的工具。
所需技术存在但并非项目核心——“没有它我们也行。”
技术代际太旧或太简单，无法达到 brief 声明的雄心。
只有设计文件没有可运行的构建，而 brief 要求至少是代码或无代码。
代码从未公开，而 brief 的提交清单要求公开。

在 brief 中与类别名称一起发布完整列表。规则写在这里；

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

会把它们打印在资格文本旁边。

发布类别名称和淘汰列表即满足披露要求。数字权重不一定要公开。 下面命名的失败是团队在比赛时完全不知道会被评什么，而命名类别加完整的淘汰列表已经防止了这种情况。一旦这些公开，隐藏权重本身是合理的反作弊选择：它阻止团队针对一个本就不该他们看到的数字优化到小数点。

Combining scores across judges

跨评委合并分数

Normalization buys nothing under full coverage and buys back the whole ranking under a sampled panel. The mechanism is one line of arithmetic: a uniformly harsh judge adds the same constant to every team they score.

Full coverage - that judge scores every team, the constant lands on all of them equally, and the order is untouched. Normalizing is pure overhead.
Sampled panel - the constant lands on that judge's slice only, so the final rank partly records which panel a team drew. Normalizing removes exactly that artifact.

Pick this menu against the allocation band, never independently of it.

Ranking (default, not a law - Q1 and Q4 re-rank it):

value (rater-effect correction - how far the final rank reflects the projects rather than which judge happened to see them):
```
synchronous consensus > per-judge normalization > raw average
```
effort (setup, judge briefing, and convening every judge against a fixed ceremony start):
```
synchronous consensus > per-judge normalization > raw average
```

efficiency under full coverage (Band 1):

raw average > per-judge normalization > synchronous consensus

efficiency under a sampled panel or single-judge allocation (Bands 2-3):
```
per-judge normalization > raw average > synchronous consensus
```

Dominance check, re-derived: clean only by construction, and this is not a pass. Value and effort run in the same direction, so there is no pair to check and no error the check could catch. The ordering rests on the arithmetic above.

Synchronous consensus is the starved option in both bands. One discussion round instead of combined independent scores needs every judge in one room at once, with no pressing schedule waiting. A hackathon jury meets against a ceremony start time that cannot move.

Promotion condition, keyed to Q4: a judge pool small enough to sit in one room, with window slack left after the visits. Delete it, from this menu and from the axis lines above, when judging is async or when judges leave straight after their slot (Q1, Q4) - a meeting nobody will attend parked at the bottom silently becomes a plan.

An organizer override of the judges' combined result is not a rung on this menu; it is deleted outright. A rejected submission was never promised a skill-based rank, and a losing team competing for a prize was. An override is the exact mechanic that makes a result contestable, and weeks after the ceremony is the wrong moment for a team to discover one was reversed.

在全覆盖下，归一化什么也买不到；在 sampled panel 下，它买回整个排名。 机制是一行算术：一个普遍严格的评委给他们打分的每支队伍加上同一个常数。

Full coverage —— 该评委给每支队伍打分，常数均匀落在所有队伍上，顺序不变。归一化纯粹是额外开销。
Sampled panel —— 常数只落在该评委的切片上，因此最终排名部分记录了队伍抽到了哪个小组。归一化正好移除这个假象。

对照分配区间选择这个菜单，绝不脱离它。

排序（默认，不是铁律——Q1 和 Q4 会重新排序）：

价值（评分者效应校正——最终排名在多大程度上反映项目而不是哪个评委碰巧看到它们）：
```
synchronous consensus > per-judge normalization > raw average
```
工作量（设置、评委简报，以及让所有评委在固定典礼开始时间前齐聚）：
```
synchronous consensus > per-judge normalization > raw average
```

全覆盖（区间 1）下的效率：

raw average > per-judge normalization > synchronous consensus

sampled panel 或 single-judge 分配（区间 2-3）下的效率：
```
per-judge normalization > raw average > synchronous consensus
```

支配关系检查，重新推导：仅靠构造干净，这不是通过。 价值和工作量方向相同，因此没有成对可检查，也没有检查能捕捉的错误。排序依据的是上面的算术。

Synchronous consensus 在两个区间都是被饿死的选项。一轮讨论而不是合并独立分数，需要所有评委同时在一个房间里，且没有紧迫的日程在等。Hackathon 评审团要在无法移动的典礼开始时间前碰面。

晋升条件，与 Q4 挂钩：评委池小到可以坐在一个房间里，且访问后还有窗口余量。当评审是异步的，或评委在自己的时段后立即离开时，从本菜单和上面的轴线上删除它（Q1、Q4）——一个没人参加的会议被放在底部，会悄悄变成计划。

组织者对评委合并结果的覆盖不是本菜单的档位；它被直接删除。 被拒绝的提交从未被承诺基于技能的排名，而争夺奖品的失败队伍被承诺了。覆盖正是让结果可被质疑的机制，而典礼后数周不是团队发现自己被反转的正确时机。

Conflict of interest and disclosure

利益冲突与披露

Doing nothing is not the cheap option here. Compliance cost measures the review a rung triggers and the reversibility it costs, and on that axis "no formal process" ranks high rather than low. That is why the default is not the cheapest rung:

No formal process triggers no review before the event, so it defers the whole review to the least reversible moment: after prizes are handed over, when the only moves left are re-running a judged round or living with the result.
Self-declared recusal triggers one line in the judge brief. A missed conflict is quietly fixable by reassigning that judge's slice while no result exists yet.
A written registry triggers a governance review every edition and is the hardest to unwind, because withdrawing a published policy next edition reads as a retreat.

Ranking (default, not a law - Q5 re-ranks it):

value (sponsor-relationship risk avoided, credibility of the announced result):

written policy with disclosure registry and escalation path > declared recusal plus assigned replacement judge > self-declared recusal > no formal process

effort (judge-briefing time, organizer tracking during the window, formality):

written policy with disclosure registry and escalation path > declared recusal plus assigned replacement judge > self-declared recusal > no formal process

compliance cost:

written policy with disclosure registry and escalation path > no formal process > declared recusal plus assigned replacement judge > self-declared recusal

efficiency:

self-declared recusal > declared recusal plus assigned replacement judge > no formal process > written policy with disclosure registry and escalation path

Dominance check, re-derived: clean only by construction on value/effort, and this is not a pass. Those two axes run in the same order, so no dominance relation exists there to violate. The compliance axis, not the check, is what re-orders this menu.

Self-declared recusal - the default. Tell judges to abstain from scoring a team they are close to rather than score it and disclose. The honour-system convention works only with fast reassignment: a CFP reassigns a reviewer over days, a hackathon reassigns inside the window. Name the fallback in advance, for a team that loses so many judges to recusal that its scores stop being comparable.
Declared recusal plus assigned replacement. Promotion condition, keyed to Q5: any sponsor funds a track and any judge is tied to that sponsor. Track judge-sponsor ties and rebalance the allocation map live.
No formal process. Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a track prize (Q5). A party then holds a financial interest in the outcome with no stated rule about it.
Written policy with registry and escalation - the starved option, top of value, effort and compliance cost. Promotion condition, keyed to Q5 and Q7: a multi-edition event whose published rules already promise a dispute process, or a prize pool large enough that a losing team will ask who decided and on what basis.

The hard case the ladder cannot rank away. A signed sponsorship agreement can require the sponsor's own representative to judge its own challenge track. That conflict was accepted at contract time, so it overrides this whole menu.

Confine the sponsor judge to that track and keep them off the overall prize.
Pair them with at least one neutral judge.
Check whether the track rank survives dropping their scores.
Disclose the composition in the published rules before submissions close.

Full handling, including what to do when the rank does not survive, is in references/coi-and-results-policy.md. Where the clause is not signed yet, the wording belongs to

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

, not here.

在这里什么都不做并不是便宜的选项。 合规成本衡量的是某档位触发的审查以及它造成的可逆性损失，在这个轴上，“无正式流程”排名高而不是低。这就是默认不是最便宜档位的原因：

无正式流程 在活动前不触发审查，所以它把全部审查推迟到最不可逆的时刻：奖品交付后，此时唯一剩下的动作是重跑一次评审轮次或接受结果。
自我声明回避 在评委简报中触发一行。错过的冲突可以在还不存在结果时通过重新分配该评委的切片悄悄修复。
书面登记册 每届都触发治理审查，并且最难撤销，因为下一届撤回已发布政策看起来像退步。

排序（默认，不是铁律——Q5 会重新排序）：

价值（避免的赞助商关系风险、已宣布结果的可信度）：

written policy with disclosure registry and escalation path > declared recusal plus assigned replacement judge > self-declared recusal > no formal process

工作量（评委简报时间、窗口期间组织者的跟踪、形式性）：

written policy with disclosure registry and escalation path > declared recusal plus assigned replacement judge > self-declared recusal > no formal process

合规成本：

written policy with disclosure registry and escalation path > no formal process > declared recusal plus assigned replacement judge > self-declared recusal

效率：

self-declared recusal > declared recusal plus assigned replacement judge > no formal process > written policy with disclosure registry and escalation path

支配关系检查，重新推导：价值/工作量上仅靠构造干净，这不是通过。 这两个轴按相同顺序运行，所以那里不存在可违反的支配关系。重新排序这个菜单的是合规轴，而不是检查。

自我声明回避 —— 默认。告诉评委对自己亲近的队伍弃权打分，而不是打分后披露。荣誉制度约定只有配合快速重分配才有效：CFP 会用几天重新分配审稿人，hackathon 在窗口内重新分配。提前为这样一支队伍命名后备方案：由于回避失去太多评委，其分数不再可比较。
声明回避并指派替补评委。 晋升条件，与 Q5 挂钩：任何赞助商资助一个赛道，且任何评委与该赞助商有关联。跟踪评委-赞助商关联并实时重新平衡分配图。
无正式流程。 一旦任何赞助商资助赛道奖品，就从本菜单和上面的轴线上删除它（Q5）。那时有一方对结果拥有经济利益，却没有关于它的规定。
带登记册和升级路径的书面政策 —— 被饿死的选项，价值、工作量和合规成本都最高。晋升条件，与 Q5 和 Q7 挂钩：已发布规则已经承诺争议流程的多届活动，或奖品池大到失败团队会问谁决定的、依据什么决定的。

阶梯无法排序掉的硬案例。 已签署的赞助协议可以_要求_赞助商自己的代表评审自己的挑战赛道。这个冲突在签约时已被接受，所以它覆盖整个菜单。

将赞助商评委限制在该赛道，并让他们远离总奖。
至少搭配一名中立评委。
检查去掉他们分数后赛道排名是否仍然成立。
在提交截止前，在已发布规则中披露这种构成。

完整处理，包括排名不成立时该怎么做，见 references/coi-and-results-policy.md。如果条款尚未签署，措辞属于

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

，而不是这里。

Tie-breaking

平局打破

Publish the tie-break ladder in the brief before submissions close, rather than inventing one at the podium. Walk it in order and stop at the first rung that separates the teams.

Highest score on the highest-weighted criterion. The weights already state what the event values most; weights that cannot break the tie were the wrong weights.
Highest count of judges who placed the project first among the teams they personally saw.
A named tie-break judge decides, on the record, in one sentence.
A co-award, only where the prize is divisible and the published rules said so in advance.

Published rules converge on the same shape: a deterministic score cascade, then a follow-up tally or panel vote, then a named decider, with a divisible-prize co-award reserved for the rare case the rules promised it.

Devpost's rules template, reused across dozens of Devpost-hosted hackathons, cascades through the listed judging criteria before falling back to a judges' vote.
MLH's own contest terms give the judge sole and final discretion, with no criterion cascade at all.
HackMIT sidesteps numeric ties structurally: it ranks projects by pairwise comparison instead of scoring them independently, so there is no tie to break.
Salesforce is the one documented case of abandoning score-based resolution outright. After a 2013 judging controversy it declared co-champions and split its Salesforce1 Hackathon grand prize. That was crisis management after the fact, not a published rule.

Full precedent, including the WildHacks three-tier scoring fallback, is in references/coi-and-results-policy.md.

Two moves to refuse, for unrelated reasons:

Re-scoring. The demos are over, so a second pass scores a memory rather than a project.
A coin flip or any random draw. Some jurisdictions treat a prize contest differently depending on whether the outcome is demonstrably skill-based. Confirm that with
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
before relying on any legal constraint.

在提交截止前把平局打破阶梯发布在 brief 中，而不是在领奖台上临时发明。按顺序走，停在第一个把队伍分开的档位。

最高权重标准上的最高分。权重已经说明了活动最看重什么；无法打破平局的权重就是错误的权重。
在自己亲眼看到的队伍中把项目排第一的评委人数最多。
指定的平局打破评委在记录上用一句话决定。
共同获奖，只在奖品可分割且已发布规则提前说明时才使用。

已发布规则收敛到相同形状：先确定性分数瀑布，然后是后续计票或评审团投票，再是指定决策者，而可分割奖品的共同获奖保留在规则承诺过的罕见情况下。

Devpost 的规则模板，在数十个 Devpost 主办的 hackathon 中复用，先沿列出的评审标准瀑布，然后回退到评委投票。
MLH 自己的比赛条款给评委唯一且最终的自由裁量权，完全没有标准瀑布。
HackMIT 从结构上绕过数字平局：它通过两两比较而不是独立打分来排名项目，所以没有平局可破。
Salesforce 是文档记载中唯一直接放弃基于分数解决的情况。2013 年评审争议后，它宣布共同冠军并平分 Salesforce1 Hackathon 大奖。那是事后的危机管理，不是已发布规则。

完整先例，包括 WildHacks 三层评分回退，见 references/coi-and-results-policy.md。

两个要拒绝的动作，原因无关：

重新评分。 演示已经结束，第二遍评的是记忆而不是项目。
抛硬币或任何随机抽取。 某些司法管辖区会根据结果是否可证明基于技能来不同对待奖品竞赛。在依赖任何法律约束之前，请与
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
确认。

Results announcement and a contested result

结果公告和有争议的结果

Collect the winner list, sponsor tracks included, before the ceremony rather than live. Announce from slides rather than narration.
Do not schedule live demos at the closing ceremony while judging is still concluding. Demo slots and the judging window draw on the same minutes.
Call judges into the room a full hour before the ceremony for the briefing. Attach the scoring grid to their calendar invite as soon as it exists rather than handing it out cold at check-in.
Stage the deliberation room in advance - seating, something to drink, something to write on - rather than assembling it once judges are already inside.
Where the combination rule above lands on synchronous consensus, run the deliberation as two timed passes rather than one open discussion:
- A short fixed slot per team first, then a longer pass on the shortlist only.
- A timekeeper named before the round starts.
- Every networked device in the room taken off the network for the duration. A result that leaks before the announcement is a result nobody trusts.
Announce the rank and the criteria. Withhold per-judge and per-team raw scores, and the numeric weights unless the event already published them before submissions closed: publishing either turns a decision into a leaderboard teams audit at a precision the rubric was never built for, and raw scores additionally expose individual judges by name.
State one contest path in the published rules before submissions close:
- Who receives a challenge.
- The window, closing before prizes change hands, since reversal after payout is
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
  's problem.
- What can actually change. An arithmetic or eligibility error can change a result; a judge's opinion cannot.
That contest path is this skill's own design. Code-of-conduct sanction appeals are a different subject that some events do publish; judging appeals are not.

在典礼前收集获胜者名单，包括赞助商赛道，而不是现场收集。从幻灯片宣布，而不是口头叙述。
在评审仍在进行时，不要在闭幕典礼安排现场演示。演示时段和评审窗口占用的是同样的分钟。
在典礼前整整一小时把评委叫进房间进行简报。评分网格一存在就附加到他们的日历邀请上，而不是在签到时冷冰冰地分发。
提前布置审议室——座位、喝的东西、可以写的东西——而不是在评委已经进入后才组装。
当上面的合并规则落在同步共识上时，把审议跑成两轮定时通过，而不是一场开放讨论：
- 先为每支队伍留一个短的固定时段，然后只在入围名单上跑更长的第二遍。
- 在轮次开始前指定计时员。
- 房间里所有联网设备在整个期间断网。在公布之前泄露的结果是没人信任的结果。
公布排名和标准。隐藏每位评委和每队的原始分数，也隐藏数字权重，除非活动在提交截止前已经公开过它们：公布其中任何一个都会把一个决定变成团队以 rubric 从未构建过的精度审计的排行榜，原始分数还会按名字暴露个别评委。
在提交截止前，在已发布规则中说明一条争议路径：
- 谁可以提出异议。
- 时间窗口，截止于奖品易手之前，因为反转发生在支付之后是
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
  的问题。
- 什么实际上可以改变。算术或资格错误可以改变结果；评委的意见不能。
这条争议路径是本 skill 自己的设计。行为准则制裁申诉是不同的主题，有些活动会发布；评审申诉则不会。

Failure modes

失败模式

Re-deciding the demo format here. Expo versus Stage versus Video was settled upstream, and it arrives as the
```
t
```
input rather than as a choice. Reopening it invalidates the allocation already computed.
Recruiting judges before computing the window. Judge count is the last input the arithmetic needs, not the first. Ask for
```
N
```
,
```
t
```
and
```
W
```
first.
Adding judges to rescue full coverage. The cap
```
N ≤ W / t
```
has no
```
J
```
in it. More judges buy a sampled panel, never a longer full-coverage reach.
Averaging raw scores across a sampled panel. The harsh-judge constant only cancels when every judge scored every team. Under sampling it lands on one slice and moves the rank.
A sponsor judge discovered at the ceremony. Same fact, opposite outcome, on timing alone:
- Disclosed in the rules in advance, it is a rule.
- Disclosed after the announcement, it is a scandal.
Inventing a tie-break at the podium. Two teams tied with no published ladder means whoever speaks first decides, live, in front of both.
Categories that never reach the brief that teams read. Teams optimize for what they were told counts. Undisclosed categories score a competition nobody entered. The numeric weight behind each category is a separate, legitimate anti-gaming withhold (see § Elimination criteria) - do not confuse the two.
Judges also competing. Organizers, volunteers, judges and sponsors are barred from competing as hackers. Check the entrant list against the judge list before scoring, not after.

在这里重新决定演示格式。 Expo 与 Stage 与 Video 在上游已定，它以
```
t
```
输入的形式到达，而不是一个选择。重新打开它会使用已计算的分配失效。
在计算窗口之前招募评委。 评委数量是算术需要的最后一个输入，而不是第一个。先要
```
N
```
、
```
t
```
和
```
W
```
。
增加评委来拯救全覆盖。 上限
```
N ≤ W / t
```
中没有
```
J
```
。更多评委买到的是 sampled panel，绝不是更长的全覆盖触达。
在 sampled panel 上平均原始分数。 严格评委常数只在每位评委给每支队伍打分时抵消。在抽样下它落在一个切片上并移动排名。
在典礼上才发现赞助商评委。 同一个事实，相反结果，仅因时机：
- 事先在规则中披露，它是规则。
- 在公告后披露，它是丑闻。
在领奖台临时发明平局打破。 两支队伍并列且没有已发布阶梯，意味着谁先说话谁就在两队面前现场决定。
类别从未到达团队阅读的 brief。 团队会针对他们被告知重要的东西优化。未披露的类别评的是一个没人参加的比赛。每个类别背后的数字权重是另一个合理的反作弊隐瞒（见淘汰标准一节）——不要混淆两者。
评委同时参赛。 组织者、志愿者、评委和赞助商被禁止以黑客身份参赛。在评分前而不是评分后，对照评委名单检查参赛者名单。

Measurement

测量

Everything below is a self-set gate; say so when presenting it.

Pass threshold (structural, one only): before scoring opens, all six of these exist in writing, with zero blanks.

Criteria with weights.
The scoring scale.
The allocation map naming which judge sees which team.
The conflict-of-interest rule and its recusal fallback.
The tie-break ladder.
The contest path.

Iterate until the count is six.

Feasibility gate (arithmetic, checked before the day): compute

k = floor((J × W) / (N × t))

```
k ≥ 1
```
: the confirmed judges reach every team at the format's contact time, and the plan is feasible as it stands.
```
k < 1
```
: they do not. That is Band 3, not a failed plan. Recompute the gate against the triage round the allocation menu prescribes there. The pre-screen is a pass/fail check that consumes part of
```
W
```
, so the finals slate must satisfy
```
k ≥ 1
```
on the surviving finalist count
```
N₂
```
and the remaining window
```
W₂
```
. If it fails again there, the only legitimate responses left are a longer window or a format change, both decided before the event.

Never absorb

k < 1

by shortening

on the day. That re-scores whichever teams were seen first.

Signals to record for next edition:

Judges who finished their slice inside the window.
Teams that got fewer judges than the map promised.
Recusals that fired.
Challenges received.

Pick two or three, write down the revision each would trigger, and record them before the ceremony rather than after.

下面都是自我设定的门槛；呈现时说明这一点。

通过阈值（结构性，只有一个）：在评分开始前，以下六项全部以书面形式存在，零空白。

带权重的标准。
评分量表。
命名哪位评委看哪支队伍的分配图。
利益冲突规则及其回避后备方案。
平局打破阶梯。
争议路径。

迭代直到数量为六。

可行性门槛（算术，在当天之前检查）： 计算

k = floor((J × W) / (N × t))

。

```
k ≥ 1
```
：已确认的评委以格式的接触时间触达每支队伍，计划按现状可行。
```
k < 1
```
：触达不到。那是区间 3，不是失败的计划。对照分配菜单在那里规定的 triage 轮重新计算门槛。预筛是消耗部分
```
W
```
的 pass/fail 检查，因此决赛名单必须在存活决赛队伍数
```
N₂
```
和剩余窗口
```
W₂
```
上满足
```
k ≥ 1
```
。如果在那里再次失败，唯一剩下的合法回应是更长的窗口或格式变更，两者都要在活动前决定。

绝不要通过在当天缩短

来吸收

k < 1

。那会重评最先被看到的队伍。

为下一届记录的信号：

在窗口内完成自己切片的评委。
获得比分配图承诺更少评委的队伍。
触发的回避。
收到的异议。

选两三个，写下每个会触发的修订，并在典礼前而不是典礼后记录。

Invocation examples

调用示例

"We expect 60 teams, 12 judges, and 2 hours between submission close and the ceremony. How do we judge this?"
"Build the scoring rubric and weights for our AI hackathon's three tracks."
"A sponsor's contract says their VP judges their own challenge. What do we do?"
"Two teams tied for first. What's the rule, and what should it have been?"
"Write the judge brief and the results announcement plan."

Expected output: a judging plan with:

The allocation band with its arithmetic shown and the resulting judges-per-team.
The weighted rubric and scale written out.
The combination rule tied to that band.
The conflict-of-interest rule with its recusal fallback.
The published tie-break ladder.
The judge brief.
The announcement plan and contest path.
The signals to record.
Elimination criteria, where the event uses them, published separately from the weighted rubric.

Presented section by section for validation before judging opens.

“我们预计 60 支队伍、12 名评委、提交截止到典礼之间有 2 小时。我们该怎么评审？”
“为我们 AI hackathon 的三个赛道构建评分 rubric 和权重。”
“赞助商合同说他们的 VP 评审自己的挑战。我们怎么办？”
“两支队伍并列第一。规则是什么，应该是什么？”
“写评委简报和结果公告计划。”

预期输出：一份评审计划，包含：

带显示算术的分配区间，以及由此产生的每队评委数。
写出的加权 rubric 和量表。
与该区间关联的合并规则。
带回避后备方案的利益冲突规则。
已发布的平局打破阶梯。
评委简报。
公告计划和争议路径。
要记录的信号。
淘汰标准（如果活动使用），与加权 rubric 分开发布。

在评审开始前逐节呈现以验证。

References

参考

```
samber/dev-event-organizer-skills@event-run-of-show
```
- schedules the judging window and the ceremony this skill's arithmetic depends on.
```
samber/dev-event-organizer-skills@event-feedback
```
- collects participants' own read on judging fairness after the event.

```
samber/dev-event-organizer-skills@event-run-of-show
```
—— 安排本 skill 算术所依赖的评审窗口和典礼。
```
samber/dev-event-organizer-skills@event-feedback
```
—— 在活动后收集参与者自己对评审公平性的看法。