hackathon-team-formation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Hackathon Team Formation

黑客松团队组建

You decide how people at a hackathon end up building with each other: the team-size rule the brief publishes, the mechanic that runs on the day, what happens to whoever it fails, when membership stops moving, and how all four fit around the opening.

This is the participant-to-participant problem. It is not the participant-to-expert problem, and the two get confused constantly.

你决定黑客松参与者如何最终彼此协作：简报发布的团队规模规则、当天运行的机制、机制失败时会发生什么、成员资格何时停止变动，以及这四者如何围绕开幕式安排。

这是参与者对参与者的问题。不是参与者对专家的问题，而这两者经常被混淆。

What you own, and what is already decided

你负责什么，以及已经决定了什么

You own:

the team-size number and its solo answer
the matchmaking mechanic
the unteamed-participant protocol
the mid-event change policy
any track-conditioned composition rule

Four things arrive from, or leave for, siblings - hand them over rather than re-deciding them:

The published rules text belongs to
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
. Its interview asks this skill for the team-size rule by name, and its pre-publication threshold counts that rule as one of seven items that must exist. You decide the number and the wording intent; that skill prints it.
Matching a stuck team to expertise belongs to
```
samber/dev-event-organizer-skills@hackathon-mentoring
```
. Draw the boundary this way: a participant who cannot find a team is this skill's problem, a team that cannot find help with a technology is that skill's. Never build a mentor request channel here.
The run-of-show slot - where the pitch round or mixer actually sits in the day and what it displaces - belongs to
```
samber/dev-event-organizer-skills@event-run-of-show
```
. You supply the duration and the ordering constraint; it schedules against them.
Prize eligibility and who may receive a payout belong to
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
. A team-size cap changes how a non-cash prize divides; say what the roster is, never what it is worth.

Every menu below, with its rungs and its axis orderings, is this skill's own construction: reasoned from mechanism, not measured against event data. Each ranking is a default, not a law. Re-rank every one after the interview against what you already know about this edition:

last year's registration data
a returning cohort that arrives in formed teams
an organizing team who has run a mixer before
a venue with one room and no second space

你负责：

团队规模数字及其单人参赛的回答
匹配机制
未组队参与者的处理协议
活动中途变更政策
任何按赛道条件的组成规则

有四件事来自或交给兄弟技能——移交它们，而不是重新决定：

已发布的规则文本 属于
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
。它的访谈会按名称向本技能请求团队规模规则，其发布前阈值将该规则视为必须存在的七项之一。你决定数字和措辞意图；那个技能负责打印。
将陷入困境的团队与专家匹配 属于
```
samber/dev-event-organizer-skills@hackathon-mentoring
```
。这样划分边界：找不到团队的参与者是本技能的问题，团队找不到技术帮助是那个技能的问题。永远不要在这里建立导师请求渠道。
活动流程时间槽 —— pitch环节或混场环节在当天实际位置以及它会取代什么——属于
```
samber/dev-event-organizer-skills@event-run-of-show
```
。你提供持续时间和排序约束；它根据这些进行排程。
奖项资格和谁可以获得奖金 属于
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
。团队规模上限会改变非现金奖项的分配方式；说明名单是什么，而不是它的价值。

下面的每个菜单，包括其阶梯和轴排序，都是本技能自己的构建：基于机制推理，而非根据活动数据衡量。每个排名是默认值，不是法规。在访谈后，根据你对这届活动已知的信息重新排名：

去年的注册数据
以已成团队形式到达的回归人群
以前组织过混场活动的组织团队
只有一个房间且没有第二空间的场地

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 2 to 9 each key a rung, a delete condition or a promotion condition; no default below can be picked without those answers.

Is the event themed with organizer-supplied problems, open with participants bringing their own, or both?
How long is the hacking window, and do the opening ceremony and the start of hacking sit in the same block or on different days?
Of the people registered so far, how many registered as an existing team, and how many registered alone? An estimate is a real answer; "we do not collect it" is the most useful answer of all.
What share of the cohort is at their first hackathon, and does registration ask anything about skills, role or what someone wants to work on?
Is a demographic or skill-level track required - a beginners track, a first-timers quota, a student-only category - and does anything in it depend on a fraction of the team rather than the individual?
How many rooms does the event occupy, and is there a second space available for a facilitated session?
Are prizes awarded against a submitted project, and may minors participate?
Is this a one-off edition or a recurring one whose mechanic should still work next year, and when must the rules be published?
What is the effort ceiling: organizer hours before the event, and how many named people are actually free during the hacking window rather than nominally on the schedule?

Q8 and Q9 each move a named rung. Say which as you re-rank.

Q8, near publication date: promotes the adopted size rule over anything drafted, and demotes pre-event matching, whose whole cost is reading registrations that have not arrived yet.
Q8, recurring edition: promotes the rungs written once and reused, the size rule with its carve-out and a pitch-round script, because their cost amortises where a one-off pays it in full.
Q9, effort ceiling in organizer hours: does not touch the safety net.
Q9, effort ceiling in people free during the window: removes the floor sweep and the escalation outright, because both are somebody's attention and nothing else. Say that rather than pretending a rota exists.

一次只问一个问题，尽量用选择题。问题2到9每个都对应一个阶梯、删除条件或提升条件；没有这些答案，下面的默认值都无法选择。

活动是否以组织者提供的问题为主题，还是开放让参与者自带问题，或者两者兼有？
黑客马拉松的开发时间窗口有多长？开幕式和开发开始是在同一时段还是在不同天？
到目前为止注册的人中，有多少人是以现有团队注册的，有多少人独自注册？估计值也是真实答案；“我们不收集这个”是最有用的答案。
参与者中有多大比例是第一次参加黑客松，注册时是否会询问技能、角色或想做什么？
是否需要按人群或技能水平的赛道——新手赛道、首次参与配额、仅限学生的类别——其中是否有任何规则取决于团队的比例而非个人？
活动占用多少个房间？是否有第二个空间可用于主持的环节？
奖项是否根据提交的项目颁发？未成年人可以参加吗？
这是一次性活动还是周期性活动（其机制明年仍然有效）？规则必须在何时发布？
努力的极限是什么：活动前的组织者工时，以及在实际黑客松窗口期内有多少指定人员真正有空，而不是名义上在时间表上？

Q8和Q9各自会移动一个指定的阶梯。重新排名时说明哪个。

Q8，接近发布日期： 将采用的规模规则提升到任何草稿之上，并降低赛前匹配的优先级，因为赛前匹配的全部成本是阅读尚未到达的注册信息。
Q8，周期性活动： 提升那些一次写好可重复使用的阶梯，即带有例外条款的规模规则和pitch环节脚本，因为它们的成本可以摊销，而一次性活动则需全额支付。
Q9，组织者工时的努力上限： 不触及安全网。
Q9，在窗口期内可自由调配人数的努力上限： 直接移除场地巡查和升级机制，因为两者都只是某人的关注，别无其他。直接说明这一点，而不是假装有一个轮值表。

Workflow

工作流程

Run the interview. Read last edition's registration data first if one exists; Q3 and Q4 are the answers it settles.
Fix the team-size rule before the mechanic. The mechanic has to produce teams the rule allows, and a mixer that forms sixes under a cap of four wastes the room. Hand the rule to
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
as soon as it is decided.
Pick the matchmaking mechanic and state its duration and its ordering constraint. Load references/matchmaking-mechanics-and-run-sheets.md.
Decide the unteamed-participant protocol before the day, not during it. Load references/unteamed-participant-protocol.md.
Set the change policy and its cut-off, and check it against step 4 - a freeze that lands before the safety net runs cancels the safety net.
Stock the project backlog if the mechanic or the safety net depends on one, and size it against Q1. Load references/team-size-and-composition-rules.md.
Hand the slot, its duration and its position to
```
samber/dev-event-organizer-skills@event-run-of-show
```
, and the rule text to the brief.
Publish before registration closes. A team-size rule added after people have already agreed to hack together disqualifies teams that already exist.

Present the decision set section by section for validation - size rule, mechanic, safety net, change policy - never as one block. Get explicit approval before the rule goes into the brief; publication is the point of no return.

If your harness has persistent memory, record:

the size rule and whether solo entry was allowed
the mechanic and its measured duration
how many people were still unteamed when the sweep ran
what each of them ended up doing

The last one is the only number that tells you whether any of this worked, and no other event's figure substitutes for it.

进行访谈。如果存在上一届的注册数据，请先阅读；Q3和Q4就是它所确定的答案。
在机制之前确定团队规模规则。 机制必须产生规则允许的团队，而在四人上限下形成六人团队的混场活动会浪费场地。一旦决定，立即将规则交给
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
。
选择匹配机制，并说明其持续时间和排序约束。加载 references/matchmaking-mechanics-and-run-sheets.md。
在活动前，而不是活动期间，决定未组队参与者的处理协议。 加载 references/unteamed-participant-protocol.md。
设置变更政策及其截止时间，并与步骤4核对——如果冻结发生在安全网运行之前，就会取消安全网。
储备项目待办池，如果机制或安全网依赖于它，并根据Q1确定其规模。加载 references/team-size-and-composition-rules.md。
将时间槽、持续时间和位置交给
```
samber/dev-event-organizer-skills@event-run-of-show
```
，将规则文本交给简报。
在注册截止前发布。如果人们已经同意一起组队后才添加团队规模规则，会使已存在的团队失去资格。

逐部分展示决策集以供验证——规模规则、机制、安全网、变更政策——绝不要作为一个整体展示。在规则进入简报之前获得明确批准；发布是不可返回的节点。

如果你的运行环境具有持久记忆，请记录：

规模规则以及是否允许单人参赛
机制及其测得的持续时间
巡查运行时还有多少人未组队
他们每个人最终做了什么

最后一个数字是唯一能告诉你这一切是否奏效的数字，其他任何活动的数据都无法替代它。

Team-size policy

团队规模政策

Four rungs: no stated rule, a stated cap only, a stated range that includes solo, and a range plus a track-conditioned composition rule.

value (disputes prevented at submission, a solo entrant knowing before arriving that they may enter, and a carve-out that is actually enforceable):
```
range plus composition rule > stated range including solo > stated cap only > no stated rule
```

effort (deciding the number, wording it, and checking it against every track):

range plus composition rule > stated range including solo == stated cap only > no stated rule

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

range plus composition rule > no stated rule > stated cap only > stated range including solo

efficiency:

stated range including solo > stated cap only > no stated rule > range plus composition rule

Dominance structure: 6 pairs, exactly one strict-dominance relation. The stated range including solo beats the cap alone on value, ties it on effort, and beats it on compliance cost, so it dominates. The efficiency line honours this by ranking the range first.

None of the other three rungs dominates:

the composition rule (top of every cost axis)
no stated rule (dominates nothing)
the cap (dominates nothing)

A wrong ordering here would have failed the check, so this pass carries information.

The
==
on effort is argued, not a dodge. A cap and a range are the same sentence: deciding a maximum already forces the question of whether one person counts, so the cap does not save the decision; it just declines to write it down. Both land under an hour, and the cap only looks cheaper because its deferral is invisible until someone registers alone.

Stated range including solo - the default, and the strongest single recommendation this skill makes.
- Copy-paste text from a published organizer guide: "Teams can be 1-4 people".
- The same guide's own reason for the cap: "We see hackers have the most success with teams of a maximum size of 4", offered as one organizer network's practitioner observation, with no study cited behind it.
- Take the shape; decide the number for your own event.
Stated cap only - real value for the same minutes, and it leaves the question the source poses explicitly, "Can hackers participate solo?", unanswered until somebody asks at the registration desk.
No stated rule - delete it, from this menu and from the axis lines above, as soon as a brief is published at all (Q8).
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
's own pre-publication threshold counts the team-size rule as one of seven items that must exist with zero blanks; shipping without it leaves that check at six. It also ranks second on compliance because it triggers no review beforehand and defers the whole adjudication to the least reversible moment there is - a prize decision, in public, with a team standing there.
Range plus composition rule - the starved option: top of value, top of effort, top of compliance cost.
- Promotion condition, keyed to Q5 and Q7: a track whose eligibility depends on a fraction of the team rather than on each individual.
- Published example: "Beginners track where at least half the team must have this be their first hackathon".
- The same source's procedural rule: "Make sure to state how many of the team members must fit the category in your rules before the event."
- Treat the fraction as the thing to decide and "half" as one event's number.

Why the composition rule tops the compliance axis. A fraction keyed to "first hackathon" is a skill-level proxy and reviews cheaply. A fraction keyed to age, student status, gender or disability is a carve-out on a protected characteristic: it needs review before publication by whoever owns that exposure for the organizing entity, and it cannot be withdrawn mid-event without re-scoring a whole track. Decide which kind yours is before writing it, and route the second kind rather than wording it yourself.

四个阶梯：无明确规则，仅明确上限，包含单人的明确范围，以及范围加按赛道条件的组成规则。

价值（在提交时防止纠纷，单人参赛者在到达前就知道可以参赛，以及一个实际可执行的例外条款）：
```
范围加组成规则 > 包含单人的明确范围 > 仅明确上限 > 无明确规则
```

工作量（决定数字、措辞，并与每个赛道核对）：

范围加组成规则 > 包含单人的明确范围 == 仅明确上限 > 无明确规则

合规成本，即每个阶梯触发的审查及其可逆性成本：

范围加组成规则 > 无明确规则 > 仅明确上限 > 包含单人的明确范围

效率：

包含单人的明确范围 > 仅明确上限 > 无明确规则 > 范围加组成规则

支配结构：6对，恰好一个严格支配关系。 包含单人的明确范围在价值上胜过仅上限，在工作量上与之持平，在合规成本上胜过它，因此它支配后者。效率线通过将范围排在第一来体现这一点。

其他三个阶梯都不支配：

组成规则（所有成本轴的顶端）
无明确规则（不支配任何东西）
上限（不支配任何东西）

这里的错误排序本会导致检查失败，因此这次通过携带了信息。

在努力上的
==
是有论证的，不是回避。上限和范围是同一个句子：决定最大值已经迫使回答一个人是否算数的问题，所以上限并不节省决策；它只是拒绝把它写下来。两者都在一小时内完成，上限只是看起来更便宜，因为它的推迟在有人独自注册之前是不可见的。

包含单人的明确范围 - 默认选项，也是本技能做出的最强单项建议。
- 从已发布的组织者指南中复制粘贴文本：“团队可以是1-4人”。
- 同一指南对上限的解释：“我们发现黑客在最大规模为4的团队中成功率最高”，这是某个组织者网络的实践观察，背后没有引用研究。
- 采用这种形式；为你的活动决定具体数字。
仅明确上限 - 同样几分钟内获得实际价值，但它把来源明确提出的问题“黑客可以独自参加吗？”留到有人在注册台询问时才回答。
无明确规则 - 一旦简报发布，立即从本菜单和上面的轴线上删除它（Q8）。
```
samber/dev-event-organizer-skills@hackathon-brief-design
```
自己的发布前阈值将团队规模规则视为必须存在的七项之一，不能有空白；没有它发布会使该检查停留在六项。它还在合规性上排名第二，因为它事先不触发审查，并将整个裁决推迟到最不可逆的时刻——公开的奖项决定，团队站在那里。
范围加组成规则 - 资源匮乏的选项：价值最高、工作量最高、合规成本最高。
- 提升条件，与Q5和Q7相关：一个赛道的资格取决于团队的比例而非每个个人。
- 已发布示例：“新手赛道要求团队中至少一半的人必须是第一次参加黑客松”。
- 同一来源的程序规则：“确保在活动前在规则中说明团队中有多少成员必须符合该类别。”
- 将比例作为需要决定的事情，将“一半”视为一个活动的数字。

为什么组成规则在合规轴线上排第一。 基于“第一次黑客松”的比例是技能水平的代理，审查成本低。基于年龄、学生身份、性别或残疾的比例是对受保护特征的例外条款：它需要在发布前由负责该组织实体风险的人审查，并且不能在活动中途撤回，否则需要重新评分整个赛道。在写之前决定你的属于哪种类型，如果是第二种，应将其转交给相应部门，而不是自己措辞。

Matchmaking mechanic

匹配机制

Five rungs: no formal matchmaking at all, a pitch-and-join round, a persistent project board, a facilitated mixer, and pre-event matching from registration data. Two value axes, because they genuinely disagree.

value, coverage (share of participants who end the mechanic in a team of their choosing):

pre-event matching > facilitated mixer > pitch-and-join round > persistent project board > no formal matchmaking

value, project fit (the team that forms has a buildable thing to build and the skills to build it):

pitch-and-join round > pre-event matching > persistent project board > facilitated mixer > no formal matchmaking

effort (organizer setup, run-of-show minutes, and coordination during the window):

pre-event matching > facilitated mixer > persistent project board > pitch-and-join round > no formal matchmaking

efficiency:

pitch-and-join round > persistent project board > no formal matchmaking > facilitated mixer > pre-event matching

Dominance structure: 10 pairs, exactly one strict-dominance relation. The pitch-and-join round beats the persistent board on coverage, on project fit, and on effort simultaneously, so it dominates. The board reaches only whoever walks past it, carries a project statement with nobody standing next to it to answer questions, and still costs a surface plus somebody maintaining it all day. The efficiency line honours that by ranking the round above the board.

None of the other three rungs dominates:

pre-event matching (top of the effort axis)
the mixer (loses project fit to both the round and the board)
no formal matchmaking (bottom of both value axes)

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

Why the two value axes split. A pitch round forms teams around a project somebody has already articulated and committed to building. A mixer forms social groups that then have to invent a project, which is the slowest possible route to a first commit. Coverage and fit are not the same quantity, and a mechanic that maximises one can starve the other.

Pitch-and-join round - the default, and the only mechanic with a published run sheet behind it.
- "Hacking begins with project introductions. Participants that bring projects to the event have an opportunity to briefly (1 minute max) explain what they are working on at the very start of the event so that other participants can join that project".
- The same source names the anti-pattern that ruins it: "Do not allow anyone to pitch an idea that they will not be working on at the event, unless there really are not enough ideas to go around."
- Groups formed this way are described as "about 2-5 individuals", a range observed at that author's civic-tech events, not a target to enforce; it sits alongside rather than inside the 1-4 cap above.
- Two aids scale the round past a small room. Both are this skill's own suggestions, not published practice:
  - a marker per pitcher, readable across the space and tied to their spot, so a crowd finds a project without queuing
  - a skill-coded wristband issued at check-in, so the room self-balances by discipline
Persistent project board - the rung the dominance check rules out, kept on the page because it is what an organizer reaches for when the pitch round runs late and gets cut. Naming it is how you notice that happened.
No formal matchmaking at all - a real rung, and correct at an event where the cohort registers as formed teams: its coverage equals any other mechanic's for zero cost, because everyone already has a team. Delete it, from this menu and from the axis lines above, as soon as Q3 shows anyone registering without a team. From that moment silence is not a light-touch choice; it is a decision to leave those people to the room.
Facilitated mixer - a starved option: second on coverage, second on effort, and fourth on project fit. Promotion condition, keyed to Q4 and Q6: a cohort mostly at its first hackathon, where too few people brought projects for a pitch round to absorb the room, and a second space exists to run it in. Never promote it on the first condition alone - a mixer in the hacking room displaces the hacking.
Pre-event matching from registration data - the other starved option: top of coverage, top of effort, and the only rung that works before anyone is in the building.
- Published as a practice rather than a mechanic: the same guide's registration form asks "What kind of hacker are they?" with the examples "Developer. Designer. Data Scientist. Domain Expert. Government Staff. Communicator. Project Manager. Advocate."
- It also instructs the organizer to "Literally try to imagine how each registered participant will keep occupied at the event based on whatever information you know about them."
- Promotion condition, keyed to Q3 and Q4: registrations are majority solo and registration already collects a role or interest field.
- Without that field the rung is not expensive but impossible: adding the field after registration opens reaches nobody who already signed up.

Every rung above is a mechanic, not a product; a spreadsheet, a wall and a chat channel each implement several of them, and naming a platform dates the skill without settling anything.

五个阶梯：完全不进行正式匹配、pitch-and-join环节、持续项目板、有主持的混场活动，以及基于注册数据的赛前匹配。两个价值轴，因为它们确实相互冲突。

价值，覆盖率（在机制结束时加入自己选择团队中的参与者比例）：

赛前匹配 > 有主持的混场活动 > pitch-and-join环节 > 持续项目板 > 无正式匹配

价值，项目契合度（形成的团队有可构建的东西以及构建它的技能）：

pitch-and-join环节 > 赛前匹配 > 持续项目板 > 有主持的混场活动 > 无正式匹配

工作量（组织者设置、活动流程分钟数、窗口期内的协调）：

赛前匹配 > 有主持的混场活动 > 持续项目板 > pitch-and-join环节 > 无正式匹配

效率：

pitch-and-join环节 > 持续项目板 > 无正式匹配 > 有主持的混场活动 > 赛前匹配

支配结构：10对，恰好一个严格支配关系。 pitch-and-join环节在覆盖率、项目契合度和工作量上同时胜过持续项目板，因此它支配后者。项目板只能触及走过它的人，承载着一个项目陈述，却没有人站在旁边回答问题，并且仍然需要一块场地和有人全天维护。效率线通过将环节排在项目板之上来体现这一点。

其他三个阶梯都不支配：

赛前匹配（工作量轴顶端）
混场活动（在项目契合度上输给环节和项目板）
无正式匹配（两个价值轴底端）

其他九对各自在一个轴与另一个轴之间权衡。检查无法验证它们，所以它们的顺序基于下面的论证。

为什么两个价值轴分裂。 pitch环节围绕某人已经阐述并承诺构建的项目形成团队。混场活动形成社交群体，然后这些群体必须发明一个项目，这是到达首次提交的最慢路径。覆盖率和契合度不是同一个量，最大化一个的机制可能会使另一个匮乏。

Pitch-and-join环节 - 默认选项，也是唯一有已发布运行流程的机制。
- “黑客松以项目介绍开始。带来项目的参与者有机会在活动开始时简要（最多1分钟）解释他们在做什么，以便其他参与者加入该项目。”
- 同一来源指出了破坏它的反面模式：“不要允许任何人推销他们不会在活动中进行的想法，除非确实没有足够的想法可以分享。”
- 以这种方式形成的群体被描述为“约2-5人”，这是在该作者的 civic-tech 活动中观察到的范围，不是要强制执行的目标；它位于上面的1-4上限旁边，而不是在其中。
- 两个辅助手段可以将环节扩展到小房间之外。两者都是本技能自己的建议，不是已发布的实践：
  - 每个演讲者一个标记，在整个空间内可见，并与他们的位置绑定，这样人群无需排队就能找到项目
  - 在签到时发放按技能编码的手环，使房间按学科自我平衡
持续项目板 - 被支配检查排除的阶梯，保留在页面上，因为它是组织者在pitch环节超时被截断时会求助于的东西。命名它就是你注意到发生了那种情况的方式。
完全不进行正式匹配 - 一个真实的阶梯，在参与者以已成团队注册的活动中是正确的：它的覆盖率以零成本等于任何其他机制，因为每个人都已经有团队了。一旦Q3显示有人没有团队注册，立即从本菜单和上面的轴线上删除它。 从那一刻起，沉默不是轻触式选择；而是决定把那些人留在房间里。
有主持的混场活动 - 一个资源匮乏的选项：覆盖率第二，工作量第二，项目契合度第四。提升条件，与Q4和Q6相关：参与者大多是第一次参加黑客松，以至于带来项目的人太少，pitch环节无法吸收所有人，并且存在第二个空间来进行。永远不要仅凭第一个条件提升它——在黑客松房间里的混场活动会取代黑客松本身。
基于注册数据的赛前匹配 - 另一个资源匮乏的选项：覆盖率最高，工作量最高，也是唯一在任何人进入场地之前就起作用的阶梯。
- 作为实践而非机制发布：同一指南的注册表问“他们是什么类型的黑客？”并举例“开发者。设计师。数据科学家。领域专家。政府工作人员。沟通者。项目经理。倡导者。”
- 它还指示组织者“根据你了解到的关于每个注册参与者的任何信息，实际尝试想象他们在活动中将如何保持忙碌。”
- 提升条件，与Q3和Q4相关：注册者大多数是单人并且注册表已经收集了角色或兴趣字段。
- 如果没有该字段，这个阶梯不是昂贵而是不可能：在注册开放后添加该字段无法触及已经报名的人。

上面的每个阶梯都是一种机制，而不是产品；电子表格、一面墙和聊天频道各自可以实现其中几个，而命名一个平台只会让技能过时，什么也解决不了。

The unteamed participant

未组队的参与者

Four rungs: solo normalized only, plus a pre-stocked project backlog, plus a floor sweep by a named person, plus a time-boxed escalation.

value (a participant who wanted a team and did not get one is reached before they leave):
```
time-boxed escalation > floor sweep > pre-stocked backlog > solo normalized only
```

effort (pre-event stocking, and a named person's attention during the window):

time-boxed escalation > pre-stocked backlog > floor sweep > solo normalized only

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

time-boxed escalation > floor sweep > pre-stocked backlog == solo normalized only

efficiency:

floor sweep > pre-stocked backlog > solo normalized only > time-boxed escalation

Dominance structure: 6 pairs, zero strict-dominance relations. Two mechanisms block all six pairs:

The ordinary block (5 pairs): the higher-value rung of the pair costs strictly more effort, more review, or both.
The near-miss (1 pair): the floor sweep genuinely beats the backlog on both value and effort, since one person already walking the room can add a question to a round they were already making, while stocking a backlog is pre-event writing. Only the compliance axis stops it dominating: approaching and identifying an isolated participant costs more review than writing project ideas does.

The check finds nothing here, though one pair came within a single axis of a relation. The efficiency line therefore rests on the arguments below rather than on any verification.

Why compliance is a real axis here and not decoration. A sweep singles out a named person on the basis of an observation about their social situation, and an escalation records it and routes them. Where minors participate (Q7) that is a safeguarding interaction, not a hospitality one, and it needs the same posture

samber/dev-event-organizer-skills@event-accessibility-inclusion

sets for accommodation data: who may hold it, for how long, and what is never written down. The lower two rungs touch nobody's data at all, which is the argued

==

Floor sweep by a named person - the default, and it comes from a published guide: "Have someone managing the hacking room... See if anyone needs anything or can't find something to work on". Its cadence, its owner and what the sweeper offers are yours. Note the coupling before choosing this alone: a sweep's value is capped by where it can route someone, which is either a stocked backlog or a team known to be short-handed.
Pre-stocked project backlog - also published, and the mitigation that reduces how often anyone is unteamed at all: "have ideas for new projects that are especially easy for participants to get started with if they can't join an existing project. Having project ideas ready is especially important if you do not expect many participants to bring projects!" The same source sets the test of whether a project is genuinely joinable rather than merely listed - "ready-to-go tasks for newcomers with a variety of skills and at a variety of skill levels", with a build environment that "can be spun up in less than 20 minutes".
Solo normalized only - published and genuinely valuable. "A project of one, meaning someone working alone, is okay too!" is the plainest statement that solo work is a legitimate outcome rather than a failure, and it should be said out loud at the opening whatever else you do.
- Delete it as the whole answer, from this menu and from the axis lines above, as soon as any matchmaking mechanic above "no formal matchmaking" is published.
- Announcing a mechanic creates an expectation of being teamed. Answering the person it failed with "solo is fine" answers a question they did not ask.
Time-boxed escalation - the starved option, top of all three axes, and this skill's own construction rather than reported practice: nothing published describes an escalation for an unteamed participant. It is a named owner, a moment at which still-looking stops being the participant's problem, and a stated ask. Promotion condition, keyed to Q4 and Q7: a cohort mostly at its first hackathon, or minors participating, where being alone all day is not plausibly a preference.

Do not invent the duration. Nothing published anywhere gives a number of minutes after which an unteamed participant should be escalated, and a plausible-sounding figure here would be fabrication wearing a benchmark's clothes.

Anchor the time-box to a clock the run of show already contains instead, for example:

the end of the pitch round
the first meal service
the first workshop break

Record what it actually took at your event, so the next edition has one real number where the field has none. The protocol, the sweeper's script and what the escalation may and may not offer are in references/unteamed-participant-protocol.md.

四个阶梯：仅将单人正常化，加上预储备的项目待办池，加上指定人员的场地巡查，加上有时间限制的升级机制。

价值（想要团队但没有得到的人在离开前被接触到）：

有时间限制的升级 > 场地巡查 > 预储备待办池 > 仅单人正常化

工作量（赛前储备，以及窗口期内指定人员的关注）：

有时间限制的升级 > 预储备待办池 > 场地巡查 > 仅单人正常化

合规成本，即每个阶梯触发的审查及其可逆性成本：

有时间限制的升级 > 场地巡查 > 预储备待办池 == 仅单人正常化

效率：

场地巡查 > 预储备待办池 > 仅单人正常化 > 有时间限制的升级

支配结构：6对，零严格支配关系。 两种机制阻断了所有六对：

普通阻断（5对）： 该对中价值较高的阶梯会花费严格更多的努力、更多的审查，或两者兼有。
近似错过（1对）： 场地巡查在价值和努力上都真正胜过待办池，因为一个已经在房间里走动的人可以在一轮中增加一个问题，而储备待办池是赛前写作。只有合规轴阻止它支配：接近并识别一个孤立的参与者比写项目想法需要更多审查。

检查在这里什么都找不到，尽管有一对仅差一个轴就形成关系。因此，效率线基于下面的论证，而不是任何验证。

为什么合规在这里是真正的轴而不是装饰。 巡查会基于对其社交状况的观察而单独挑出一个指名的人，升级会记录并引导他们。在未成年人参与的地方（Q7），这是一种保护性互动，而不是好客互动，它需要与

samber/dev-event-organizer-skills@event-accessibility-inclusion

为住宿数据设定的姿态相同：谁可以持有、持有多长时间、以及什么永远不会被写下来。下面两个阶梯完全不接触任何人的数据，这就是所论证的

==

。

指定人员的场地巡查 - 默认选项，来自已发布的指南：“让某个人管理黑客松房间……看看是否有人需要什么或找不到可以做的事情。”其节奏、负责人和巡查者提供什么由你决定。在选择这个之前注意耦合：巡查的价值受限于它可以将某人引导到哪里，这要么是储备好的待办池，要么是已知人手不足的团队。
预储备的项目待办池 - 也是已发布的，并且是减少任何人未组队频率的缓解措施：“准备一些新项目的想法，这些项目特别容易让参与者开始，如果他们无法加入现有项目。如果你不期望很多参与者带来项目，准备好项目想法尤为重要！”同一来源设定了测试项目是否真正可加入而不仅仅是列出的标准——“为具有各种技能和不同技能水平的新手准备可立即开始的任务”，以及一个“在20分钟内即可启动”的构建环境。
仅单人正常化 - 已发布且确实有价值。“一个人的项目，即有人独自工作，也是可以的！”是最直白的陈述，表明单人工作是合法的结果而不是失败，无论你做其他什么，都应在开幕式上大声说出来。
- 一旦发布任何高于“无正式匹配”的匹配机制，立即从本菜单和上面的轴线上删除它作为完整答案。
- 宣布一种机制会制造被组队的期望。用“单人也可以”来回答那个被机制辜负的人，是在回答一个他们没有问的问题。
有时间限制的升级 - 资源匮乏的选项，所有三个轴的顶端，是本技能自己的构建而非报告实践：没有已发布的文献描述对未组队参与者的升级。它包括指定的负责人、一个时间点（在该点之后继续寻找不再是参与者的问题），以及一个明确的请求。提升条件，与Q4和Q7相关：参与者大多是第一次参加黑客松，或有未成年人参与，在这种情况下整天独自一人不太可能是一种偏好。

不要编造持续时间。 没有已发布的文献给出一个分钟数，超过该时间未组队参与者应该被升级，一个听起来合理的数字在这里将是穿着基准外衣的捏造。

相反，将时间框锚定在活动流程中已有的时钟上，例如：

pitch环节结束
第一次用餐服务
第一次工作坊休息

记录你的活动中实际花费的时间，这样下一届就有一个真实数字，而该领域目前没有。协议、巡查者脚本以及升级可以提供和不能提供的内容都在 references/unteamed-participant-protocol.md 中。

Mid-event team changes

活动中途团队变更

Four rungs: no stated policy, membership frozen at a published moment, open until a published cut-off then frozen, and open throughout with an attribution rule. Nothing standard governs a team changing after it forms. Every rung, every axis line and both dominance relations below are this skill's own construction, reasoned from mechanism and never observed at an event.

value (a team that gains or loses someone can still submit, and authorship is not disputed at judging):

open until a cut-off > open throughout with an attribution rule > frozen at a published moment > no stated policy

effort (publishing the rule, and reconciling the roster at submission):

open throughout with an attribution rule > open until a cut-off > frozen at a published moment == no stated policy

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

no stated policy > open throughout with an attribution rule > open until a cut-off > frozen at a published moment

efficiency:

frozen at a published moment > open until a cut-off > open throughout with an attribution rule > no stated policy

Dominance structure: 6 pairs, two strict-dominance relations. Two pairs carry information here, which is the most any menu in this skill gets:

freezing at a published moment beats the no-stated-policy rung on value, ties it on effort, and beats it on compliance, so it dominates
open-until-a-cut-off beats open-throughout on all three axes, so it dominates too

The efficiency line honours both. Neither the cut-off nor open-throughout dominates the freeze, since each buys its value with strictly more effort, and the no-stated-policy rung dominates nothing.

The
==
on effort is argued. Both rungs cost roughly one sentence and roughly nothing at the submission desk. The difference is not size but timing: the freeze spends its hour before the event; the no-stated-policy rung spends the same hour at the desk, under deadline, with no rule to apply. That is why the two rungs separate on the compliance axis rather than this one.

Frozen at a published moment - the efficiency leader and, deliberately, not the recommended default.
- Promotion condition, keyed to Q3 and to your own step-4 decision: as soon as you adopt any safety-net rung above "solo normalized only", move up to the cut-off.
- A freeze set at the pitch round makes the sweep unable to place anybody, because the team with room for them is no longer allowed to take them.
- This is the one place in this skill where the ratio is knowingly overruled, by a decision the skill itself made two menus earlier rather than by taste.
Open until a published cut-off, then frozen - the recommended default for that reason. It keeps the roster movable through the hours the safety net actually operates in and fixes it before judging starts, so the list handed to
```
samber/dev-event-organizer-skills@hackathon-judging
```
and to
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
is the list that gets scored and paid.
Open throughout with an attribution rule - the starved option, and the rung the check rules out. Promotion condition, keyed to Q2: a multi-day or week-long window, where a team losing a member on day three otherwise cannot submit at all and a freeze is the harsher rule.
No stated policy - delete it, from this menu and from the axis lines above, as soon as prizes are awarded against a submission (Q7). Without a rule, the question of who is on the team is settled at the moment it is worth the most money and can be reversed the least.

Where a composition rule and a change policy collide. If a track-conditioned fraction was published on the first menu, say what happens to a team that stops satisfying it after someone leaves.

Deciding it in advance costs a clause.
Deciding it at judging costs a track.

四个阶梯：无明确政策、在已发布的时刻冻结成员资格、在已发布的截止时间前开放然后冻结、以及始终开放并附带归属规则。没有标准规范团队形成后的变更。下面的每个阶梯、每条轴线和两个支配关系都是本技能自己的构建，基于机制推理，从未在活动中观察到。

价值（增加或失去成员的团队仍然可以提交，并且在评审时作者身份没有争议）：
```
截止前开放 > 始终开放并附带归属规则 > 在已发布时刻冻结 > 无明确政策
```

工作量（发布规则，并在提交时核对名单）：

始终开放并附带归属规则 > 截止前开放 > 在已发布时刻冻结 == 无明确政策

合规成本，即每个阶梯触发的审查及其可逆性成本：

无明确政策 > 始终开放并附带归属规则 > 截止前开放 > 在已发布时刻冻结

效率：

在已发布时刻冻结 > 截止前开放 > 始终开放并附带归属规则 > 无明确政策

支配结构：6对，两个严格支配关系。 这里有两对携带信息，这是本技能任何菜单中最多的情况：

在已发布时刻冻结在价值上胜过无明确政策阶梯，在工作量上与之持平，在合规上胜过它，因此它支配后者
截止前开放在所有三个轴上都胜过始终开放，因此它也支配后者

效率线体现了这两者。截止前开放和始终开放都不支配冻结，因为每个都用严格更多的努力换取其价值，而无明确政策阶梯不支配任何东西。

在努力上的
==
是有论证的。两个阶梯在提交台都大约花费一句话，几乎什么都不花。区别不在于大小而在于时机：冻结在活动前花费它的那一小时；无明确政策阶梯在截止时间压力下，在提交台花费同样的一小时，却没有规则可应用。这就是为什么这两个阶梯在合规轴而不是这个轴上分开。

在已发布时刻冻结 - 效率领先者，并且有意不是推荐的默认值。
- 提升条件，与Q3和你自己的步骤4决定相关：一旦你采用任何高于“仅单人正常化”的安全网阶梯，就升级到截止前开放。
- 在pitch环节设置的冻结会使巡查无法安置任何人，因为有空位的团队不再被允许接收他们。
- 这是本技能中唯一一处明知比率被推翻的地方，是由技能自己在两个菜单前做出的决定，而不是凭喜好。
在已发布的截止时间前开放，然后冻结 - 因此是推荐的默认值。它使名单在安全网实际运作的时段内保持可变动，并在评审开始前固定下来，因此交给
```
samber/dev-event-organizer-skills@hackathon-judging
```
和
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
的名单就是被打分和支付的名单。
始终开放并附带归属规则 - 资源匮乏的选项，也是检查排除的阶梯。提升条件，与Q2相关：多天或一周的窗口期，否则在第三天失去成员的团队根本无法提交，冻结是更严苛的规则。
无明确政策 - 一旦奖项根据提交的成果颁发，立即从本菜单和上面的轴线上删除它（Q7）。没有规则，谁在团队中的问题会在它价值最高且最不可逆的时刻被决定。

组成规则与变更政策冲突的地方。 如果在第一个菜单上发布了按赛道条件的比例，说明当有人离开后不再满足该比例的团队会怎样。

提前决定成本是一个条款。
在评审时决定成本是一条赛道。

Timing against the opening

相对于开幕的时间安排

Three pieces of timing are published:

Placement, and it is worth copying. The pitch round runs immediately after the welcoming session, not as a separate slot later. The same guide's day-of agenda puts the welcome first - organizers, sponsors, history, code of conduct, logistics - and then: "Anyone who has brought a project to work on should then introduce the project to everyone."
The mechanic that keeps the round inside its budget. "Project leaders tend to talk for as long as they can, so you may need to cut them off after one minute". It is framed for the pitcher as "not as recruiting but as boasting how awesome their day is going to be".
A scale marker, easy to misread. "In a small event (up to about 30 people), you can have all of the participants introduce themselves". That threshold governs everyone introducing themselves, not the pitch round, which happens either way.

Everything else about timing is this skill's own construction. Nothing published says:

how long before hacking a size rule should be announced
whether pre-event matching should run at registration or a week out
how a two-day event's second morning handles arrivals

Derive those from the ordering constraint instead:

the size rule is published with the brief
the mechanic runs before the first line of code
the change cut-off lands before judging opens
the safety net operates in the gap between the mechanic and the cut-off

Hand the durations to

samber/dev-event-organizer-skills@event-run-of-show

and let it place them.

有三项时间安排是已发布的：

位置，值得复制。 pitch环节在欢迎环节之后立即进行，而不是稍后的单独时段。同一指南的当天议程将欢迎放在第一位——组织者、赞助商、历史、行为准则、后勤——然后：“任何带来项目的人随后应该向所有人介绍这个项目。”
让环节保持在预算内的机制。 “项目负责人往往会尽可能长时间地说话，所以你可能需要在一分钟后打断他们”。对演讲者来说，它的定位是“不是为了招募，而是为了炫耀他们的一天会有多棒”。
一个容易误读的规模标记。 “在小型活动（约30人以内）中，你可以让所有参与者自我介绍”。这个阈值管理的是_每个人自我介绍_，而不是pitch环节，后者无论如何都会进行。

关于时间安排的其他一切都是本技能自己的构建。没有已发布的文献说明：

在黑客松开始前多久应该宣布规模规则
赛前匹配应该在注册时还是提前一周进行
两天活动的第二天早上如何处理到达者

而是从排序约束中推导这些：

规模规则与简报一起发布
机制在第一行代码之前运行
变更截止时间在评审开始之前
安全网在机制和截止时间之间的间隙运行

将持续时间交给

samber/dev-event-organizer-skills@event-run-of-show

，让它安排它们。

Role coverage instead of headcount

角色覆盖而非人数

When a team asks what it is missing, answer in functions rather than in people. One published role model exists, from a hardware-hackathon guide, naming four core roles for a "strong" multidisciplinary team:

programmer
fabricator
designer
visionary, named explicitly as project management

Plus one duty tied to no headcount: "Someone on the team should also be focused on quality assurance and debugging". The full scope of each role is in the sizing reference.

A software-only event has no fabricator, and the roles listed are that build's physical dependencies. The structure carries over, the list does not: name three or four functions a team needs covered, keep them separate from headcount so a four-person cap and a five-function list stay compatible, and let the mechanic surface who fills which. That carry-over is this skill's own reasoning, not a published software-event role model.

The same source's recruiting rationale is the part most often skipped: it asks organizers to invite people who "may not self-identify as 'hackers'", because a coder-only applicant pool makes skill balance impossible at matchmaking time whatever mechanic you picked. Your equivalent function split is yours to write; the guide supplies the shape, not the list.

One published figure covers project supply. At themed hackathons: "ensure that there is at least one subject matter expert + workable project for about every four non-expert participants".

Carry all four of its bounds on every use:

it is themed events only, where projects are confined to one problem domain
it counts non-expert participants, not teams and not registrations
its expert is a domain expert embedded in one project, not a floating mentor
it is a project-supply target, whose purpose is to stop the room splitting off a third group of "participants struggling to find something relevant to work on" rather than to staff anything

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

carries the fuller scoping and the standing warning never to convert it into mentors per participant. Read it there before reusing the number anywhere else.

当团队询问缺少什么时，用职能而不是人来回答。存在一个已发布的角色模型，来自硬件黑客松指南，为一个“强大”的多学科团队命名了四个核心角色：

程序员
制造者
设计师
愿景者，明确命名为项目管理

加上一个与人数无关的职责：“团队中还应该有人专注于质量保证和调试”。每个角色的完整范围在规模参考中。

纯软件活动没有制造者，列出的角色是那种构建的身体依赖。结构延续，列表不延续：命名团队需要覆盖的三四个职能，将它们与人数分开，以便四人上限和五个职能列表保持兼容，并让机制揭示谁填补哪个。这种延续是本技能自己的推理，不是已发布的软件活动角色模型。

同一来源的招募理由是最常被跳过的部分：它要求组织者邀请那些“可能不自认为是‘黑客’”的人，因为只有编码者的申请池会使匹配时的技能平衡变得不可能，无论你选择什么机制。你的等效职能拆分由你书写；指南提供形式，而不是清单。

一个已发布的数据覆盖了项目供应。在主题黑客松中：“确保每约四名非专家参与者至少有一个领域专家+可行的项目。”

每次使用都携带其四个边界：

仅适用于主题活动，其中项目被限制在一个问题领域
它计算非专家参与者，不是团队也不是注册数
它的专家是嵌入到一个项目中的领域专家，而不是流动导师
它是一个项目供应目标，其目的是阻止房间分裂出第三组“努力寻找相关工作做的参与者”，而不是为任何东西配备人员

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

承载了更完整的范围界定和常设警告，绝不要将其转换为每个参与者的导师数量。在别处重用该数字之前，请在那里阅读它。

Failure modes

失败模式

Freezing membership before the safety net has run. The ordering mistake this skill exists to prevent: the mechanic identifies someone unteamed, a short-handed team wants them, and the published rule forbids it. Fix: set the change cut-off after the sweep, not at the pitch round.
Answering the unpicked participant with "solo is fine". It is the right thing to say at the opening and the wrong thing to say to the one person it failed. Fix: route to a short-handed team or a stocked project first, and offer solo as a choice rather than as the outcome.
A mixer with nothing stocked behind it. Social groups form, then discover they have no project and no leader, and dissolve by lunch. Fix: never run a people-first mechanic without a backlog.
A pitch from someone who will not build it. It consumes the round's minutes and leaves joiners attached to a project with no author. Fix: state the rule before the round opens and enforce the cut-off.
A team-size cap that contradicts the prize. A non-cash prize counted per person against a cap of four is a different promise from cash divided arbitrarily. Fix: check the roster rule against
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
before publishing either.
A composition fraction adjudicated after teams form. A first-timer quota discovered at submission excludes teams that already exist and had no way to know. Fix: publish the fraction with the brief.
Treating a matchmaking format as universally accessible. A room-wide pitch round and a facilitated mixer both assume comfort with speaking to strangers at volume, which is an access question independent of the unteamed-outcome one. Fix: offer a non-verbal route to the same mechanic and take the design question to
```
samber/dev-event-organizer-skills@event-accessibility-inclusion
```
.
Collecting registration signals nobody uses. A skills field on the form buys nothing unless a named person reads it before the day. Fix: only add the field if pre-event matching is actually the chosen rung.

在安全网运行之前冻结成员资格。 本技能存在的意义就是防止这种顺序错误：机制识别出未组队的人，一个缺少人手的团队想要他们，但已发布的规则禁止。修复：将变更截止时间设置在巡查之后，而不是在pitch环节。
用“单人也可以”回答未被选中的参与者。 这是在开幕式上正确的话，但对被机制辜负的那一个人来说是错误的。修复：先引导到缺少人手的团队或储备好的项目，并将单人作为选择而不是结果提供。
背后没有储备的混场活动。 社交群体形成，然后发现他们没有项目和领导者，在午餐时解散。修复：绝不要在没有待办池的情况下运行以人为先的机制。
来自不会构建它的人的pitch。 它消耗环节的分钟数，并让加入者依附于一个没有作者的项目。修复：在环节开始前说明规则并执行截止时间。
与奖项矛盾的团队规模上限。 按每人计算的非现金奖项与四人上限是不同于任意分配现金的承诺。修复：在发布任何一个之前，对照
```
samber/dev-event-organizer-skills@hackathon-cash-prize
```
检查名单规则。
在团队形成后裁决组成比例。 在提交时发现的首次参与配额会排除已经存在且无法知道的团队。修复：将比例与简报一起发布。
将匹配格式视为普遍可访问。 全房间的pitch环节和有主持的混场活动都假设参与者能自在地大声与陌生人说话，这是一个与未组队结果无关的可访问性问题。修复：为同一机制提供非语言途径，并将设计问题带到
```
samber/dev-event-organizer-skills@event-accessibility-inclusion
```
。
收集没有人使用的注册信号。 表单上的技能字段什么也买不到，除非指定的人在活动前阅读它。修复：只有当赛前匹配确实是选择的阶梯时才添加该字段。

Measurement

测量

Every gate below is self-set rather than an industry standard; say so when presenting it. Teams-formed rate, solo-entry share, time-to-team and unteamed count are not comparable across events, so do not borrow another event's figure as a target.

Pass threshold (structural, one only): before the brief is published, all five of these exist in writing with zero blanks:

the team-size rule with its solo answer
the composition fraction, if any track needs one
the named mechanic with its duration
the named owner of the safety net
the change cut-off expressed as a wall-clock time

Iterate until the count is five.

Coverage gate (on the day): after the mechanic ends, the number of participants not yet on a team is a known number, not an impression. If nobody can state it, the sweep has no target and the escalation has no trigger.

Signals to record for next edition (self-set):

how many registered alone versus as a team
how many were still unteamed when the sweep ran
what each of them did next
how long the pitch round actually took against its budget
how many teams changed membership after the cut-off would have fallen

The field publishes none of these, so your own second edition is the only comparison you will ever have.

下面的每个门限都是自设的，而不是行业标准；展示时说明这一点。团队形成率、单人参赛比例、组队时间和未组队人数在不同活动间不可比较，所以不要借用其他活动的数据作为目标。

通过阈值（结构性，仅一个）： 在简报发布之前，以下五项都以书面形式存在，零空白：

团队规模规则及其单人参赛答案
组成比例，如果有赛道需要
指定的机制及其持续时间
安全网的指定负责人
以具体时间表达的变更截止时间

迭代直到数量为五。

覆盖率门限（当天）： 机制结束后，尚未进入团队的参与者数量是一个已知数字，而不是印象。如果没有人能说出它，巡查就没有目标，升级就没有触发条件。

为下一届记录的信号（自设）：

有多少人独自注册与以团队注册
巡查运行时还有多少人未组队
他们每个人接下来做了什么
pitch环节实际花费的时间与预算相比
在截止时间过后会有多少团队变更成员

该领域没有发布这些数据，所以你自己的第二届活动是你唯一拥有的比较。

Invocation examples

调用示例

"What team size should our 200-person hackathon allow, and do we let people compete solo?"
"How do we run team formation on the day? Most of our registrations are individuals."
"Somebody didn't get picked by any team and doesn't want to work alone. What do we actually do?"
"Can a team add a member on Saturday afternoon? Where do we draw the line?"
"Our beginners track needs half the team to be first-timers - how do we word and enforce that?"

Expected output: a team-formation decision set with:

the team-size rule with its solo answer and any composition fraction, handed to the brief
the chosen mechanic at a named rung with its duration and its ordering constraint, handed to the run of show
the unteamed-participant protocol with a named owner and a time-box anchored to the day's own clock
the change policy with its cut-off as a wall-clock time
the signals to record

Presented section by section for validation before anything reaches the brief.

“我们200人的黑客松应该允许多大的团队规模？我们允许人们独自参赛吗？”
“我们当天如何运行团队组建？我们的大部分注册都是个人。”
“有人没有被任何团队选中，也不想独自工作。我们实际该怎么做？”
“团队可以在周六下午增加成员吗？我们在哪里划清界线？”
“我们的新手赛道需要一半团队是首次参加——我们如何措辞和执行？”

预期输出：一个团队组建决策集，包括：

团队规模规则及其单人参赛答案和任何组成比例，交给简报
在指定阶梯上选择的机制及其持续时间和排序约束，交给活动流程
未组队参与者协议，包括指定负责人和锚定到当天时钟的时间框
变更政策及其作为具体时间的截止时间
要记录的信号

逐部分展示以供验证，然后才进入简报。

References

参考资料

references/team-size-and-composition-rules.md - the adoptable size-rule wording, the composition-rule mechanics and the protected-characteristic split, role coverage written out, project-backlog sizing, and the registration fields each mechanic needs.
references/matchmaking-mechanics-and-run-sheets.md - the five mechanics as run sheets, the pitch-round script and cut-off enforcement, board and mixer design, pre-event matching from registration data, and a positive and negative worked pair.
references/unteamed-participant-protocol.md - the sweep and the escalation written out with what each may offer, the accessibility and safeguarding overlays, and what never gets written down.