Back to Details

hackathon-brief-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Hackathon Brief Design

黑客松简报设计

You write the document a hackathon hands its teams: what to build, under which rules, who may enter, what to submit, and what "good" will be called. It is the only artifact every participant reads, and every dispute at the ceremony traces back to a sentence it did or did not contain.
你编写黑客松交给其团队的文件：要构建什么、在哪些规则下、谁可以参加、提交什么，以及什么才算“好”。它是每个参与者唯一会阅读的工件，典礼上的每一个争议都可以追溯回其中包含或不包含的某句话。

What "track" means here

这里“track”的含义

A challenge track is a thematic category a team enters its project into: an AI track, a sponsor's API track, a beginners track. It is a content and prize construct.
samber/dev-event-organizer-skills@event-format-selection
uses "track" for parallel session streams, single-track versus multi-track programming. Same word, different concept.
Write challenge track wherever a reader could take the other meaning. A session-track decision settles nothing here.
挑战轨道（challenge track） 是团队将其项目投入的主题类别：AI轨道、赞助商API轨道、初学者轨道。它是一个内容和奖项的构造。
samber/dev-event-organizer-skills@event-format-selection
使用“track”指并行分会场流，单轨与多轨议程。同一个词，不同的概念。
在读者可能产生另一种理解的地方，请写 challenge track。分会场轨道的决策在这里解决不了任何问题。

What you own, and what is already decided

你负责什么，什么已经决定

You own the written brief:
  • problem statements
  • challenge-track content
  • rules and eligibility text
  • the submission checklist
  • sponsor-challenge framing
  • the names of the evaluation categories
Three things arrive already decided. Publish them rather than 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
    . Translate it into the submission checklist and the deadline rather than pick it: a video-only event makes the video the deliverable, an expo event makes it optional. Deliverable format is downstream of that choice, never an independent one you make here.
  • Criteria weights, the scale, judge allocation, tie-breaks and disputes belong to 
    samber/dev-event-organizer-skills@hackathon-judging
    . That skill states the boundary from its own side: the evaluation categories named in the published brief are yours, and it weights them and builds the mechanics on top. Name the categories, and never print a weight, a scale or a points total.
  • Prize amounts, cash-versus-in-kind and payout handling belong to 
    samber/dev-event-organizer-skills@hackathon-cash-prize
    . Write "each challenge track awards a prize"; never write the figure.
Every ranking below is a default, not a law. Re-rank each menu after the interview against what you already know about this event:
  • last edition's published rules
  • a signed sponsorship agreement
  • an organizer who has run this API before
  • a beginner-heavy audience
你负责撰写简报：
  • 问题陈述
  • 挑战轨道内容
  • 规则与资格文本
  • 提交清单
  • 赞助商挑战框架
  • 评估类别的_名称_
三件事已经决定了。发布它们而不是重新讨论。
  • 演示/评审结构（展台、舞台路演、纯视频，或两阶段混合）属于 
    samber/dev-event-organizer-skills@event-format-selection
    。把它转化为提交清单和截止时间，而不是重新选择它：纯视频活动让视频成为交付物，展台活动使其成为可选项。交付物格式是该选择的下游结果，绝不是你这里独立做出的决定。
  • 标准权重、量表、评审分配、平局裁决和争议属于 
    samber/dev-event-organizer-skills@hackathon-judging
    。该skill从自己一侧声明了边界：已发布简报中命名的评估类别是你的，它负责加权并在其上构建机制。命名类别，绝不要打印权重、量表或总分。
  • 奖品金额、现金与实物以及奖金发放处理属于 
    samber/dev-event-organizer-skills@hackathon-cash-prize
    。写“每个挑战轨道颁发一个奖项”；绝不写具体数字。
下面的每个排序都是默认值，不是定律。在访谈之后，根据你对这个活动已有的了解，重新排列每个菜单：
  • 上一届已发布的规则
  • 已签署的赞助协议
  • 以前运行过这个API的组织者
  • 以初学者为主的受众

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 3-5 and 8-9 decide which rung each menu defaults to; the defaults cannot be picked without those answers.
  1. How long is the hacking window in hours, and is the event in person or fully digital?
  2. Which demo/judging structure is already chosen? (Fixed input - do not re-decide it.)
  3. Do participants bring their own problems to work on, or does the organizer supply the problem statements? Both is a real answer.
  4. How many sponsors fund a prize, and does any signed agreement already promise a named challenge track?
  5. Does any sponsor's API, dataset or hardware need keys or accounts - and has anyone on the organizing team actually built something small against it end to end? What happens to those teams if it goes down mid-event?
  6. Who may enter and who is barred: students only, an age minimum, geography or employment exclusions, organizers and volunteers? And what team-size rule has 
    samber/dev-event-organizer-skills@hackathon-team-formation
    already decided - a maximum, a minimum, solo entries allowed or not? (Fixed input you publish, not one you set. The pass threshold below counts it, so get the number before drafting.)
  7. Is a demographic or skill-level carve-out required - a beginners track, a first-timers quota, a student-only category?
  8. Do prizes carry cash value, are minors expected to attend, and is any personal data collected through the submission? (Decides whether the cheapest rules rung survives at all.)
  9. What is the publication timeline and event cadence?
    • When must the brief be published?
    • Is this a one-off, or a recurring edition whose rules should still hold next year?
    • What is the effort ceiling: organizer hours before publication, and whether counsel is available at all?
Q9's three answers each move a named rung. Say which as you re-rank:
  • A near publication date promotes the adopted standard rule set over anything drafted, and demotes the fully specified challenge, whose starter repo and acceptance tests are the longest lead time on any menu here.
  • A recurring edition promotes the rungs written once and reused, the adopted set with its carve-outs and the per-track prompt skeleton, because their cost amortises across editions where a one-off pays it in full.
  • An effort ceiling with no counsel behind it does not demote full legal-grade, it removes the route to it. Say so rather than substituting self-written legal-sounding text.
一次问一个问题，尽可能提供多选题。问题3-5和8-9决定每个菜单默认落到哪一级；没有这些答案就无法选择默认值。
  1. 黑客时间窗口有多长（小时）？活动是线下还是全线上？
  2. 已经选择了哪种演示/评审结构？（固定输入——不要重新决定。）
  3. 参与者自带问题解决，还是组织者提供问题陈述？两者都是真实的答案。
  4. 有多少赞助商资助奖项？是否有任何已签署的协议已经承诺了命名的挑战轨道？
  5. 是否有任何赞助商的API、数据集或硬件需要密钥或账户——组织团队中是否有人真的端到端地针对它构建过一个小东西？如果它在活动进行中宕机，那些团队怎么办？
  6. 谁可以参加，谁被禁止：仅限学生、年龄下限、地理或雇佣排除、组织者和志愿者？
    samber/dev-event-organizer-skills@hackathon-team-formation
    已经决定了什么团队规模规则——上限、下限、是否允许个人参赛？（固定输入，发布而非设定。下面的通过阈值会计算它，所以在起草前获取数字。）
  7. 是否需要人口统计或技能水平的特别条款——初学者轨道、首次参赛者配额、仅限学生的类别？
  8. 奖项是否带有现金价值，是否预计有未成年人参加，是否通过提交收集任何个人数据？（决定最便宜的规则层级是否还能存在。）
  9. 发布的时间线和活动节奏是什么？
    • 简报必须何时发布？
    • 这是一次性活动，还是每年重复的版本，其规则明年仍然有效？
    • 工作量上限是多少：发布前的组织者时间，以及是否有法律顾问可用？
Q9的三个答案各自移动一个指定的层级。重新排序时说明是哪个：
  • 临近发布日期会使“采用的标准规则集”比任何起草的内容更受青睐，并使“完全指定的挑战”降级，因为其starter仓库和验收测试是这里所有菜单中准备时间最长的。
  • 周期性版本会提升一次编写多次复用的层级，即带有特别条款的采用集和每个轨道提示骨架，因为它们的成本在多个版本中摊销，而一次性活动则要全额支付。
  • 没有法律顾问支持的限制不会降低“完整法律级”的排名，而是移除了通往它的路径。要直接说明，而不是用自己写的听起来像法律文本的内容替代。

Workflow

工作流程

  1. Run the interview. Read last edition's published rules first if one exists.
  2. Fix the rules and eligibility text before the problem statements. It deletes rungs from the other menus and it carries the real exposure. Load references/rules-and-eligibility-source-text.md.
  3. Decide the challenge-track structure, then write one problem statement per track. Load references/problem-statement-patterns.md.
  4. Convert each sponsor commitment into a track prompt or a bonus-prize criterion, and write the fallback sentence for a sponsor platform that fails.
  5. Name the evaluation categories. Say plainly in the brief who weights them and when the weights get published, then hand the categories to 
    samber/dev-event-organizer-skills@hackathon-judging
    .
  6. Build the submission checklist from the chosen demo structure, never from a generic template. Load references/submission-checklist-and-categories.md.
  7. Run the ambiguity pass: for every rule, ask what a team arguing the opposite reading would point at.
  8. Publish before registration closes, then freeze. A rule added after teams start building applies to a competition nobody entered.
Present the brief section by section for validation, never as one block:
  • rules
  • eligibility
  • tracks
  • problem statements
  • submission checklist
  • categories
Get explicit approval before publishing; publication is the point of no return.
If your harness has persistent memory, record:
  • the published rule set and which fields were edited
  • the specificity rung chosen per track
  • the sponsor fallback sentences
  • every question a participant actually asked during the event, the most useful of the four, since each one names a sentence the next brief needs
  1. 执行访谈。如果存在上一届已发布的规则，先阅读它们。
  2. 在问题陈述之前确定规则和资格文本。它删除了其他菜单中的层级，并承载真正的风险。加载 references/rules-and-eligibility-source-text.md。
  3. 决定挑战轨道的结构，然后为每个轨道写一个问题陈述。加载 references/problem-statement-patterns.md。
  4. 将每个赞助商承诺转化为轨道提示或奖金标准，并为失败的赞助商平台写下备用句子。
  5. 命名评估类别。在简报中明确说明谁对它们加权以及权重何时发布，然后将类别交给 
    samber/dev-event-organizer-skills@hackathon-judging
    。
  6. 根据选定的演示结构构建提交清单，绝不要使用通用模板。加载 references/submission-checklist-and-categories.md。
  7. 执行歧义检查：对每条规则，问一个持相反解读的团队会指向什么。
  8. 在报名结束前发布，然后冻结。在团队开始构建后添加的规则适用于一个没有人参加的竞赛。
逐节呈现简报以供验证，绝不要一次性作为整块：
  • 规则
  • 资格
  • 轨道
  • 问题陈述
  • 提交清单
  • 类别
发布前获得明确批准；发布是不可回头的时间点。
如果你的工具具有持久化记忆，请记录：
  • 已发布的规则集以及哪些字段被编辑
  • 每个轨道选择的具体性层级
  • 赞助商备用句子
  • 参与者在活动期间实际问过的每个问题，这四个中最有用的一个，因为每个问题都指出了下一份简报需要的一句话

Problem-statement specificity

问题陈述的具体性

Four rungs, from a bare theme to a fully specified challenge with a starter repo and acceptance tests.
Size the ambition to the time box. One practitioner rule of thumb circulates: "Most projects will accomplish about 25% of what they think they can accomplish in the limited time they have." Read the figure against the right denominator: it is 25% of a team's own pre-hack estimate of its own scope, not of the organizer's prompt, not of any absolute measure, and not a completion rate. It is one organizer's observation, not a measured rate.
The design consequence runs through every rung below: write each prompt so that the quarter a team actually reaches is itself demoable, by naming a minimum viable submission rather than leaving teams to discover one at hour forty.
  • value (a team can self-assess whether it is in scope; judges can compare submissions to each other): 
    fully specified > structured statement > domain-scoped prompt > open theme
  • effort (organizer writing time before publication, plus keeping every prompt consistent with the rules): 
    fully specified > structured statement > domain-scoped prompt > open theme
  • efficiency: 
    structured statement > domain-scoped prompt > open theme > fully specified
Dominance check, re-derived: clean only by construction, and by-construction is never a pass. Both axes run in the same order, so no pair exists where one rung has value greater than or equal to another's and effort less than or equal to it. Zero dominance relations exist, the check can catch no misordering here, and the efficiency line therefore rests entirely on the arguments below rather than on any verification.
  • Structured statement - the default, in five parts: context, the challenge as a question, the constraints, the resources provided, and a stated minimum viable submission. It is the cheapest rung at which a team can answer "are we in scope" without asking an organizer, and the rung the submission checklist and the evaluation categories both derive from without further writing.
    Its project-quality template asks that projects have "a clear question or problem they are trying to solve plus a reasonably specific proposed solution". That template assumes participants pitching their own projects, so when the organizer writes the prompt instead, the burden moves to the organizer.
  • Domain-scoped prompt - one sentence naming a domain and nothing else. Real segmentation value for near-zero cost, but it leaves the in-scope question open, and that question generates the clarification traffic an organizer answers all weekend.
  • Open theme - near-zero cost, and genuinely correct at events where participants bring the problems. Promotion condition, keyed to Q3: participants arrive with their own projects and pitch them, in which case the brief's job is to publish the pitch mechanic rather than the problem.
    Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a prize (Q4). A sponsor prize needs a stated criterion to attach to, and parking the open theme at the bottom quietly leaves that prize with nothing to award against.
    Where the pitch mechanic is chosen, publish one refinement alongside it: require the pitch to state a problem, not a solution. A team pitching "we want to build X" commits to an approach before anyone has tested whether the problem is real; a team pitching "this target group has this problem, here is the evidence" leaves the approach open to whoever joins. Publish two things with it - a short evidence requirement (interviews, numbers, a lived account - whatever counts as evidence here) and a stated minimum before a team may move to building - and hand both to 
    samber/dev-event-organizer-skills@hackathon-team-formation
    as content the pitch mechanic runs.
  • Fully specified challenge - the starved option: top of value, top of effort, so efficiency never picks it. Building a starter repo, a dataset and acceptance tests is organizer engineering work measured in days.
    Promotion condition, keyed to Q1 and Q5: a time box of a week or longer, or a sponsor whose own integration tests already exist and can be handed over as-is. Below roughly a weekend it also changes what the event is, turning a build into a graded exercise.
    No source publishes a formula converting a specificity rung to an hour count. A second, independent source agrees on the direction and nothing more: guidance for writing AI/ML challenge prompts tiers them by complexity, and states plainly that its hardest tier - real-world systems, unpredictable data, enterprise-grade reliability - "often exceed[s] the standard 24-72 hour window and may be better suited to extended formats," while its lower tiers fit inside it. Never read it as a second data point for the same quantity as the 25% figure above; they measure different things.
四个层级，从裸主题到带有starter仓库和验收测试的完全指定的挑战。
根据时间盒调整雄心。 流传着一个实践者的经验法则：“大多数项目在有限时间内只能完成他们认为自己能完成的约25%。” 要对照正确的分母来解读这个数字：它是团队自己在hackathon前对其自身范围估计的25%，不是组织者提示的25%，不是任何绝对衡量标准的25%，也不是完成率。这是一位组织者的观察，不是测量出的比率。
设计后果贯穿下面每个层级：编写每个提示时，要让团队实际达到的四分之一本身是可演示的，通过命名一个最小可行提交（minimum viable submission），而不是让团队在第40小时才发现一个。
  • 价值（团队可以自我评估是否在范围内；评审可以相互比较提交）：
    完全指定 > 结构化陈述 > 领域限定提示 > 开放主题
  • 工作量（发布前组织者的编写时间，加上保持每个提示与规则一致）：
    完全指定 > 结构化陈述 > 领域限定提示 > 开放主题
  • 效率：
    结构化陈述 > 领域限定提示 > 开放主题 > 完全指定
支配检查，重新推导：只在构造上是干净的，而构造上的干净永远不是通过。 两个轴以相同的顺序运行，因此不存在一对层级，其中一个层级的值大于或等于另一个，且工作量小于或等于另一个。存在零个支配关系，此检查无法发现任何排序错误，因此效率排序完全取决于下面的论证，而不是任何验证。
  • 结构化陈述 —— 默认选项，包含五个部分：背景、作为问题的挑战、约束条件、提供的资源，以及说明的最小可行提交。这是团队无需询问组织者就能回答“我们是否在范围内”的最便宜的层级，也是提交清单和评估类别无需进一步编写即可推导出的层级。
    其项目质量模板要求项目拥有“他们试图解决的清晰问题或难题，加上一个合理具体的提议解决方案”。该模板假设参与者推销自己的项目，因此当组织者代为编写提示时，负担转移到了组织者身上。
  • 领域限定提示 —— 一句话命名一个领域，仅此而已。以接近零的成本获得真正的细分价值，但它让“是否在范围内”的问题悬而未决，而这个问题会产生组织者整个周末都要回答的澄清流量。
  • 开放主题 —— 接近零成本，在参与者自带问题的活动中真正正确。提升条件，对应Q3：参与者带着自己的项目来并推销它们，在这种情况下简报的工作是发布推销机制而不是问题。
    只要有赞助商资助奖项（Q4），就把它从这个菜单和上面的轴线上删除。赞助商奖项需要有一个声明的标准来依附，而把开放主题放在底部会悄悄地让该奖项没有任何可依据的授予对象。
    在选择了推销机制的情况下，随其发布一个细化要求：要求推销陈述一个问题，而不是一个解决方案。一个团队推销“我们想构建X”在任何人测试问题是否真实之前就承诺了一种方法；一个团队推销“这个目标群体有这个问题，这里是证据”则让方法对任何加入的人开放。随它一起发布两件事——一个简短的证据要求（访谈、数字、亲身经历——任何在这里算作证据的东西）和一个团队可以进入构建之前需满足的明确最低要求——并将两者交给 
    samber/dev-event-organizer-skills@hackathon-team-formation
    作为推销机制运行的内容。
  • 完全指定的挑战 —— 被饿死的选项：价值最高，工作量最高，所以效率永远不会选择它。构建starter仓库、数据集和验收测试是组织者的工程工作，以天计。
    提升条件，对应Q1和Q5：时间盒为一周或更长，或者赞助商已有自己的集成测试并且可以原样移交。在大约一个周末以下，它还会改变活动的性质，把构建变成一次评分练习。
    没有来源发布将具体性层级转换为小时数的公式。第二个独立来源只在方向上一致，仅此而已：编写AI/ML挑战提示的指南按复杂度对它们进行分层，并明确说明其最难层——真实世界系统、不可预测数据、企业级可靠性——“经常超出标准的24-72小时窗口，可能更适合扩展格式”，而其较低层则适合其中。绝不要把它当作与上述25%数字相同的量的第二个数据点；它们衡量的是不同的东西。

Challenge-track structure

挑战轨道结构

Four rungs: one unified challenge, general plus one sponsor track, general plus several sponsor tracks, fully partitioned (every sponsor, every demographic, plus an open track).
Adding a challenge track does not split the field. A team submits one project, and that one project may enter several challenge tracks; the standard rule set publishes both halves as adjacent text, "You may not submit multiple projects" and "You may submit to multiple challenges". Every team stays eligible for the general prize while entering the sponsor track too, so the marginal cost of a track is rules-consistency work, not lost submission density. This lever is routinely missed, and it is what makes every rung below affordable.
  • value (sponsor satisfaction, audience segmentation, prize flexibility, a beginner's chance of placing): 
    fully partitioned > general plus several sponsor tracks > general plus one sponsor track > one unified challenge
  • effort (writing each prompt, keeping eligibility carve-outs consistent, and the cross-track submission rule): 
    fully partitioned > general plus several sponsor tracks > general plus one sponsor track > one unified challenge
  • efficiency: 
    general plus one sponsor track > general plus several sponsor tracks > one unified challenge > fully partitioned
Dominance check, re-derived: clean only by construction, and by-construction is never a pass. Value and effort run in the same order across all four rungs, so no strict-dominance pair exists and nothing here was verified by the check. The argument above is the whole basis for the ordering.
  • General plus one sponsor track - the default. The first sponsor track costs one prompt and one prize line, and it converts a sponsor from a logo into a challenge owner. It is also where the cross-track rule gets written once, which is the real cost.
  • General plus several sponsor tracks - marginal effort per additional track falls, because the second track copies a pattern the first one paid for, while value keeps rising. Total effort still rises, which is why it sits below the default; the falling margin is why it sits above one unified challenge.
  • One unified challenge - cheapest, and it leaves prize flexibility and sponsor value on the table. Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a prize (Q4): with no named track the sponsor's prize has no published criterion, and awarding it becomes an improvisation at the ceremony.
  • Fully partitioned - the starved option, top of both axes. Promotion condition, keyed to Q4 and Q7: enough sponsors that each funds its own prize and a demographic carve-out is already required, so the per-track eligibility wording has to be written anyway. Absent both, partitioning buys empty tracks and a prize nobody competed for.
No published ratio scales track count to participant headcount. The one sourced ceiling scales it to judging capacity instead: MLH's own guide says to aim for 3 tracks absent sponsor tracks and without an overall 1st/2nd/3rd placement, never 20 or more, and to raise the count only as far as the judges running deliberations can absorb without the panel turning chaotic. Treat sponsor and judge headcount, not participant headcount, as the variable this ceiling actually tracks.
Demographic carve-outs are their own wording problem. State the required fraction of the team before the event, and never adjudicate it after teams have formed. A published example is "Beginners track where at least half the team must have this be their first hackathon". Treat the fraction as the thing to decide; treat "half" as one event's number.
四个层级：一个统一挑战、通用加一个赞助商轨道、通用加多个赞助商轨道、完全分区（每个赞助商、每个人群，加上一个开放轨道）。
添加挑战轨道并不会分割参赛群体。 一个团队提交一个项目，而这个项目可以参加多个挑战轨道；标准规则集将两句话作为相邻文本发布：“您不得提交多个项目”和“您可以提交到多个挑战”。每个团队在进入赞助商轨道的同时仍然有资格获得通用奖项，因此一个轨道的边际成本是规则一致性工作，而不是失去提交密度。这个杠杆经常被忽略，而正是它使下面的每个层级都变得可负担。
  • 价值（赞助商满意度、受众细分、奖项灵活性、初学者获奖机会）：
    完全分区 > 通用加多个赞助商轨道 > 通用加一个赞助商轨道 > 一个统一挑战
  • 工作量（编写每个提示、保持资格特别条款一致，以及跨轨道提交规则）：
    完全分区 > 通用加多个赞助商轨道 > 通用加一个赞助商轨道 > 一个统一挑战
  • 效率：
    通用加一个赞助商轨道 > 通用加多个赞助商轨道 > 一个统一挑战 > 完全分区
支配检查，重新推导：只在构造上是干净的，而构造上的干净永远不是通过。 价值和工作量在所有四个层级中以相同的顺序运行，因此不存在严格支配对，这里没有任何东西被该检查验证。上面的论证是排序的全部基础。
  • 通用加一个赞助商轨道 —— 默认选项。第一个赞助商轨道花费一个提示和一行奖项，它将赞助商从logo转变为挑战所有者。这也是跨轨道规则一次性写入的地方，这才是真正的成本。
  • 通用加多个赞助商轨道 —— 每个额外轨道的边际工作量_下降_，因为第二个轨道复制了第一个轨道已经付费的模式，而价值持续上升。总工作量仍然上升，这就是为什么它位于默认之下；边际下降是为什么它位于一个统一挑战之上。
  • 一个统一挑战 —— 最便宜，但它把奖项灵活性和赞助商价值留在了桌面上。只要有赞助商资助奖项（Q4），就把它从这个菜单和上面的轴线上删除：没有命名的轨道，赞助商的奖项就没有发布的标准，颁发它就变成了典礼上的即兴发挥。
  • 完全分区 —— 被饿死的选项，两个轴的顶端。提升条件，对应Q4和Q7：有足够的赞助商，每个资助自己的奖项并且已经需要人口统计特别条款，所以每个轨道的资格措辞无论如何都必须编写。两者都缺失时，分区只会买到空轨道和一个无人竞争的奖项。
没有已发布的比率将轨道数量与参与人数挂钩。 唯一有来源的上限是将其与评审能力挂钩：MLH自己的指南说，在没有赞助商轨道且没有整体第1/2/3名的情况下，目标是3个轨道，绝不要20个或更多，并且只有在主持评议的评审能够承受、不会导致评审团混乱的情况下才提高数量。把赞助商和评审人数，而不是参与人数，视为这个上限实际跟踪的变量。
人口统计特别条款是它们自己的措辞问题。 在活动前声明团队所需的比例，绝不要在团队形成后再裁定。一个已发布的例子是“初学者轨道，团队中至少一半人的这次经历必须是他们的第一次黑客松”。把比例当作需要决定的东西；把“一半”当作一个活动的数字。

Rules and eligibility rigor

规则与资格严谨性

Four rungs: minimal (a team-size cap plus a code-of-conduct pointer), an adopted standard rule set, adopted plus carve-outs, and full legal-grade text reviewed by counsel.
  • value (disputes prevented, defensibility of a disqualification, sponsor and participant confidence): 
    full legal-grade > adopted plus carve-outs > adopted standard set > minimal
  • effort (drafting and review hours before publication): 
    full legal-grade > adopted plus carve-outs > adopted standard set == minimal
  • compliance cost, as the review each rung triggers and the reversibility it costs: 
    full legal-grade > minimal > adopted plus carve-outs > adopted standard set
  • efficiency: 
    adopted standard set > adopted plus carve-outs > minimal > full legal-grade
The 
==
on effort is argued, not a dodge. The minimal rung is not free: somebody still decides the team-size number, writes the sentence and links the code of conduct. Adopting a published set replaces that drafting with a handful of edits, because the source is explicitly offered for forking - "Organizers can use these rules exactly or fork them and edit them to suit their needs".
Both land in the same order of magnitude: under an hour. That equality is the only real bend on any menu in this skill, and it is what the check below runs on.
Dominance check, re-derived: clean by care. Exactly one strict-dominance relation exists: the adopted standard set has strictly higher value than minimal, equal effort, and strictly lower compliance cost, and the efficiency line honours it by ranking the adopted set first.
  • Full legal-grade never dominates (top of every cost axis).
  • Adopted-plus-carve-outs never dominates the adopted set (higher value but strictly higher effort).
  • Minimal dominates nothing.
A wrong ordering here would have failed the check, so this pass carries information the other three menus' passes do not.
  • Adopted standard rule set - the default, and the strongest single recommendation this skill makes. A published, forkable set already covers:
    • team size
    • crossposting
    • one-project-many-tracks
    • work-during-the-window
    • pre-existing code and open-source use
    • AI-tool disclosure
    • public-code requirements
    • who may compete
    • disqualification grounds
    Clear rules let an organizer "easily be able to point to specific rules if you have to disqualify hackers for cheating". references/rules-and-eligibility-source-text.md names the fields you must still edit; adopting the set without editing them is the common failure.
  • Adopted plus carve-outs - promotion condition, keyed to Q6 and Q7: a demographic or skill-level track, an age minimum, or a geographic or employment restriction. Each carve-out is per-track wording that has to compose with the base rules without contradicting them, which is where the extra hours go.
  • Minimal - delete it, from this menu and from the axis lines above, as soon as any prize carries cash value or any sponsor funds one (Q8, Q4). A prize with value turns a dispute into a claim, and nothing is then published to point at. It ranks second on compliance cost for the same reason: it triggers no review before the event and defers the whole review to the least reversible moment there is, the disqualification itself, in public, with prizes on the table.
  • Full legal-grade - the starved option: top of value, top of effort, top of compliance cost. Promotion condition, keyed to Q8 and Q9: a prize pool large enough that a losing team retains counsel, or a sponsorship agreement imposing IP terms. Promote it by routing to actual counsel, never by writing legal-sounding sentences yourself.
Two of Q8's answers are gates, not menu choices. Minors expected to participate, and personal data collected through the submission, each carry an obligation the efficiency line has no vote on: the review happens before publication, by counsel or by whoever owns data protection for the organizing entity, whatever rung the ratio landed on.
An obligation determines the response; efficiency only orders the options that remain. The same holds for the code of conduct every rung points at: 
samber/dev-event-organizer-skills@event-code-of-conduct
owns it, the brief links it, and it is never a rung to be traded against effort.
On intellectual property, this skill states no clause and recommends none. The MLH rule set carries no IP-ownership term and no originality warranty at all; its only ownership-adjacent requirement is that submitted code be public and stay public to remain prize-eligible.
Whether a team, an organizer, or a sponsor owns submitted work is a jurisdictional legal question. Route it to counsel through 
samber/dev-event-organizer-skills@event-sponsor-agreement
when a sponsor asks for it, and never let a plausible-sounding sentence stand in for the answer.
四个层级：最低限度（团队规模上限加上行为准则链接）、采用的标准规则集、采用加特别条款、以及经过法律顾问审查的完整法律级文本。
  • 价值（预防争议、取消资格的可辩护性、赞助商和参与者的信心）：
    完整法律级 > 采用加特别条款 > 采用标准集 > 最低限度
  • 工作量（发布前的起草和审查时间）：
    完整法律级 > 采用加特别条款 > 采用标准集 == 最低限度
  • 合规成本，即每个层级触发的审查及其付出的可逆性：
    完整法律级 > 最低限度 > 采用加特别条款 > 采用标准集
  • 效率：
    采用标准集 > 采用加特别条款 > 最低限度 > 完整法律级
工作量上的
==
是有论证的，不是回避。 最低限度层级并不是免费的：仍然有人决定团队规模数字、写下句子并链接行为准则。采用已发布的规则集用少量编辑取代了起草，因为来源明确提供用于fork——“组织者可以完全使用这些规则，或者fork它们并根据需要编辑”。
两者都在同一数量级：不到一小时。这种相等是这个skill中任何菜单上唯一的真实弯曲，也是下面检查运行的基础。
支配检查，重新推导：因谨慎而干净。 恰好存在一个严格支配关系：采用标准集的价值严格高于最低限度，工作量相等，合规成本严格更低，效率排序通过将采用集排在第一位来尊重它。
  • 完整法律级从不支配（每个成本轴的顶端）。
  • 采用加特别条款从不支配采用集（价值更高但工作量严格更高）。
  • 最低限度不支配任何东西。
这里的错误排序会通过检查失败，所以这一遍携带了其他三个菜单的检查所没有的信息。
  • 采用标准规则集 —— 默认选项，也是这个skill做出的最强单一推荐。一个已发布、可fork的规则集已经覆盖：
    • 团队规模
    • 跨站发布
    • 一个项目多个轨道
    • 时间窗口内的工作
    • 既有代码和开源使用
    • AI工具披露
    • 公开代码要求
    • 谁可以参赛
    • 取消资格的理由
    清晰的规则让组织者“如果需要因作弊取消黑客的资格，能够轻松指向具体规则”。references/rules-and-eligibility-source-text.md 列出了你仍然必须编辑的字段；采用该规则集但不编辑这些字段是常见的失败。
  • 采用加特别条款 —— 提升条件，对应Q6和Q7：人口统计或技能水平轨道、年龄下限、或地理或雇佣限制。每个特别条款都是针对每个轨道的措辞，必须与基础规则组合而不矛盾，这就是额外时间花在哪里。
  • 最低限度 —— 一旦任何奖项带有现金价值或任何赞助商资助奖项（Q8、Q4），就把它从这个菜单和上面的轴线上删除。有价值的奖项把争议变成索赔，然后没有任何已发布的东西可以指向。出于同样的原因，它在合规成本上排名第二：它在活动前不触发任何审查，把整个审查推迟到最不可逆的时刻——取消资格本身，在公开场合，在奖项摆在桌面上时。
  • 完整法律级 —— 被饿死的选项：价值最高，工作量最高，合规成本最高。提升条件，对应Q8和Q9：奖品池足够大以至于失败团队会聘请律师，或者赞助协议施加知识产权条款。通过转给真正的法律顾问来提升它，绝不要自己写听起来像法律的句子。
Q8的两个答案是闸门，不是菜单选择。 预计有未成年人参加，以及通过提交收集个人数据，每个都带有一种效率排序无权投票的义务：审查发生在发布前，由法律顾问或组织实体的数据保护负责人进行，无论比例落在哪个层级。
义务决定回应；效率只对剩余的选项进行排序。每个层级都指向的行为准则也是如此：
samber/dev-event-organizer-skills@event-code-of-conduct
拥有它，简报链接它，它永远不是可以用来交换工作量的层级。
关于知识产权，这个skill不声明任何条款，也不推荐任何条款。 MLH规则集完全没有知识产权所有权条款，也没有原创性保证；它唯一与所有权相关的要求是提交的代码必须公开并保持公开才能保持获奖资格。
团队、组织者或赞助商是否拥有提交的作品是一个司法管辖法律问题。当赞助商提出要求时，通过 
samber/dev-event-organizer-skills@event-sponsor-agreement
将其转给法律顾问，绝不要让一个听起来合理的句子代替答案。

Sponsor-challenge integration depth

赞助商挑战集成深度

Four rungs: the sponsor named as prize funder only, an optional bonus challenge using its product, its technology required for one track, and its technology as the event's sole substrate.
The axes here agree, and the disagreement cannot be manufactured. The tempting counter-argument: a sole substrate costs less prompt-writing than a required track, since there is no general track to stay consistent with. That is true, and it does not flip the axis - provisioning keys and mentors for every participant rather than for one track's entrants outweighs it. Say so rather than invent divergence.
  • value (sponsor return and renewal likelihood - argued, not measured): 
    sole substrate > required for one track > optional bonus challenge > named funder only
  • effort (vetting the sponsor's docs, provisioning keys and accounts, coordinating mentors, writing a prompt inside the constraint): 
    sole substrate > required for one track > optional bonus challenge > named funder only
  • dependency risk (what breaks in the brief if the platform, keys, docs or rate limits fail mid-event): 
    sole substrate > required for one track > optional bonus challenge > named funder only
  • compliance cost, as the review each rung triggers and the reversibility it costs: 
    sole substrate > required for one track > optional bonus challenge > named funder only
  • efficiency: 
    optional bonus challenge > required for one track > named funder only > sole substrate
All four axes run in the same order, so there is no pair with value greater than or equal and any cost less than or equal. The check catches nothing here, and the ordering rests entirely on the argument above.
The dependency-risk axis is why this menu has four cost lines and not two. Effort is what an organizer spends before the event; dependency risk is what the event loses if something outside the organizer's control fails during it. They move together here but they are not the same quantity, and only the second one can delete a rung on the day.
  • Optional bonus challenge - the default: the sponsor's product is one path to a bonus prize, never the only path. Teams who cannot get a key still compete, so a platform outage costs one prize rather than the event.
  • Required for one track - promotion condition, keyed to Q4 and Q5: the signed agreement already commits to a named challenge track, and somebody on the organizing team has built something small end to end against the sponsor's API before publication. Never promote on the sponsor's own claim that the docs are good.
  • Named funder only - cheap and safe, and the rung that most often breaks a sponsorship promise. Delete it, from this menu and from the axis lines above, when the signed agreement already promises a named challenge track (Q4) - at that point it is a contract term, not a menu choice.
  • Sole substrate - the starved option on efficiency, and the one rung a different axis can remove outright. Promotion condition, keyed to Q4 and Q5: a single sponsor funds the whole prize pool and the event is billed as its event, and every Q5 confirmation is already in writing.
    Delete it, from this menu and from the axis lines above, when the sponsor cannot confirm in writing both a sandbox or offline fallback and rate-limit headroom for the expected team count (Q5). Efficiency merely ranks it last; dependency risk is what makes it unshippable, and the two are separate findings - promotion never overrides the delete.
Every sponsor-dependent prompt needs a published fallback sentence. State in the brief what happens to a team whose sponsor integration is unavailable through no fault of its own: judged on its design and integration plan rather than on a working call. Written before the event it is a rule; improvised during the outage it is a favour, and every team that already finished will say so.
四个层级：赞助商仅被命名为奖项资助者、使用其产品的可选奖金挑战、其技术被一个轨道强制要求、以及其技术作为活动的唯一基础。
这里的各轴是一致的，分歧无法被制造出来。 诱人的反方论点：唯一基础比强制轨道花费的提示编写_更少_，因为没有需要保持一致的通用轨道。这是真的，但它不会翻转轴——为每个参与者而不是一个轨道的参赛者配置密钥和导师，超过了它。要这样说，而不是发明分歧。
  • 价值（赞助商回报和续约可能性——论证而非测量）：
    唯一基础 > 一个轨道强制要求 > 可选奖金挑战 > 仅命名资助者
  • 工作量（审查赞助商文档、配置密钥和账户、协调导师、在约束内编写提示）：
    唯一基础 > 一个轨道强制要求 > 可选奖金挑战 > 仅命名资助者
  • 依赖风险（如果平台、密钥、文档或速率限制在活动中失败，简报中什么会破裂）：
    唯一基础 > 一个轨道强制要求 > 可选奖金挑战 > 仅命名资助者
  • 合规成本，即每个层级触发的审查及其付出的可逆性：
    唯一基础 > 一个轨道强制要求 > 可选奖金挑战 > 仅命名资助者
  • 效率：
    可选奖金挑战 > 一个轨道强制要求 > 仅命名资助者 > 唯一基础
所有四个轴以相同的顺序运行，因此不存在价值大于或等于而任何成本小于或等于的对。检查在这里什么都抓不到，排序完全取决于上面的论证。
依赖风险轴是这个菜单有四个成本线而不是两个的原因。 工作量是组织者在活动前花费的；依赖风险是如果组织者控制之外的东西在活动期间失败，活动会失去的。它们在这里一起移动，但它们不是同一个量，而且只有第二个才能在当天删除一个层级。
  • 可选奖金挑战 —— 默认选项：赞助商的产品是获得奖金的一条路径，绝不是唯一路径。无法获得密钥的团队仍然可以竞争，因此平台宕机只会让一个奖项受损，而不是整个活动。
  • 一个轨道强制要求 —— 提升条件，对应Q4和Q5：已签署的协议已经承诺了一个命名的挑战轨道，并且组织团队中有人在发布前已经端到端地针对赞助商的API构建了一个小东西。绝不要根据赞助商自己声称文档很好来提升。
  • 仅命名资助者 —— 便宜且安全，也是最常破坏赞助承诺的层级。当已签署的协议已经承诺了一个命名的挑战轨道时（Q4），就把它从这个菜单和上面的轴线上删除——这时它是一个合同条款，而不是菜单选择。
  • 唯一基础 —— 效率上被饿死的选项，也是可能被_不同_轴直接移除的一个层级。提升条件，对应Q4和Q5：单个赞助商资助整个奖品池，活动被宣传为其活动，并且所有Q5的确认都已书面化。
    当赞助商无法书面确认沙盒或离线回退方案以及预期团队数量的速率限制余量时（Q5），就把它从这个菜单和上面的轴线上删除。效率只是把它排在最后；依赖风险才是使它无法发布的原因，这两者是独立的发现——提升永远不会覆盖删除。
每个依赖赞助商的提示都需要一个已发布的备用句子。 在简报中说明，一个团队如果因其自身无过错而无法使用赞助商集成，会发生什么：根据其设计和集成计划来评审，而不是根据一次成功的调用。在活动前写下它是规则；在宕机期间即兴发挥它是恩惠，每个已经完成的团队都会这么说。

Evaluation categories in the brief

简报中的评估类别

Name the categories. Never weight them, scale them or total them: that is 
samber/dev-event-organizer-skills@hackathon-judging
, and publishing a weight here creates a promise that skill then has to honour or contradict.
Print the elimination criteria alongside them. A binary knockout list disqualifies a submission outright, so it belongs next to the category names rather than inside the weighted rubric. Print it in full; 
samber/dev-event-organizer-skills@hackathon-judging
decides its content.
One published category set is worth starting from, each category with a written description of what a judge is looking for:
  • technology
  • design
  • completion
  • learning
That set carries its own default weighting. Keep the weighting out of the brief and hand it to the judging skill as an input instead.
Publishing what is not judged is the underused half, each exclusion carrying its reason:
  • how good the code is
  • how well the team pitches
  • how good the idea is
  • how well the project solves a real problem
Teams optimize for whatever the brief names, so an exclusion list is the cheapest way to stop forty teams polishing slides. Copy the shape, and decide the content for your own event: a corporate hackathon judging commercial viability would exclude a different list.
命名类别。绝不要加权、量化或汇总它们：那是 
samber/dev-event-organizer-skills@hackathon-judging
的工作，在这里发布权重会创造一个该skill之后必须兑现或矛盾的承诺。
把淘汰标准与它们一起打印出来。一个二元的淘汰列表会直接取消提交的资格，所以它应该紧挨着类别名称，而不是放在加权评分标准里面。完整打印它；
samber/dev-event-organizer-skills@hackathon-judging
决定其内容。
有一套已发布的类别集值得作为起点，每个类别都带有对评审在寻找什么的书面描述：
  • 技术
  • 设计
  • 完成度
  • 学习
该集合带有自己的默认权重。把权重排除在简报之外，并将其作为输入交给评审skill。
发布什么不被评审是被低估的另一半，每个排除都带有理由：
  • 代码有多好
  • 团队推销得有多好
  • 想法有多好
  • 项目在多大程度上解决了真实问题
团队会针对简报中提到的任何内容进行优化，所以排除列表是阻止四十个团队打磨幻灯片的最便宜方式。复制形状，并为自己的活动决定内容：一个评审商业可行性的企业黑客松会排除不同的列表。

Submission guidelines

提交指南

Derive the checklist from the demo structure chosen upstream, never from a template. A video-only event makes the video the deliverable and its constraints binding; an expo or stage event makes the video optional and the live demo carry the weight. Getting this backwards is how a brief requires a video nobody will watch, or omits the one artifact judging depends on.
Requirements worth adopting from MLH's published rules, all stated there as absolute rather than as suggestions:
  • submitted code is publicly available, ideally in a git repository, and stays public after the event to remain prize-eligible
  • API keys are removed before sharing
  • libraries and frameworks used are listed in a readme
  • AI-tool use is disclosed in the submission
For fully digital events the same source requires a demo video of two minutes or less, created during the event, naming the hackathon at the start, and remaining public afterwards.
The public-code requirement does not transfer without thought. It assumes an event whose culture is open by default, and a corporate or client-data hackathon may not be able to honour it at all. Decide that before copying the sentence.
Set the submission deadline as a wall-clock time in a named time zone, and say what happens to a late submission before anyone is late. references/submission-checklist-and-categories.md carries the full checklist per demo format, the deadline mechanics and the artifact-by-artifact wording.
从上游选定的演示结构推导清单，绝不要从模板。纯视频活动使视频成为交付物，其约束具有约束力；展台或舞台活动使视频成为可选项，现场演示承担重量。把这个搞反了，简报就会要求一个没人会看的视频，或者漏掉评审所依赖的那一个工件。
值得从MLH已发布规则中采用的要求，所有这些在那里都被陈述为绝对要求而非建议：
  • 提交的代码是公开可用的，理想情况下在git仓库中，并在活动后保持公开以保持获奖资格
  • API密钥在共享前移除
  • 使用的库和框架在readme中列出
  • AI工具的使用在提交中披露
对于全线上活动，同一来源要求一个两分钟或更短的演示视频，在活动期间创建，开头点名黑客松，并在此后保持公开。
公开代码要求不会不经思考就转移。 它假设一个默认开放文化的活动，而企业或客户数据的黑客松可能根本无法履行它。在复制这句话之前做出决定。
将提交截止时间设置为指定时区中的墙钟时间，并在任何人迟到之前说明迟交的后果。references/submission-checklist-and-categories.md 包含每种演示格式的完整清单、截止时间机制和逐工件的措辞。

Failure modes

失败模式

  • Weighting the categories in the brief. Naming them is your job; weighting them is not, and a weight published here binds a sibling skill that has not yet done its arithmetic.
  • Picking the deliverable format. Video-versus-live was settled by the format skill. You translate it. Choosing it again produces a checklist the judging plan cannot execute.
  • Confusing challenge tracks with session tracks. They are different decisions owned by different skills, and a brief that borrows the session-track count as its challenge-track count invents categories nobody sponsored.
  • A rule added after building starts. Teams built against the published text. A new rule mid-event re-scores whoever already finished.
  • A prompt with no minimum viable submission. A team reaching a quarter of its own plan has nothing demoable, and the brief is what decided that.
  • A sponsor track written from the sponsor's marketing copy. Marketing copy names benefits, not buildable constraints. Rewrite it as a problem, then have the sponsor confirm the rewrite.
  • Carve-out fractions adjudicated after teams form. A required fraction - "at least half the team" - has to be published before people choose teammates, or the rule quietly excludes teams that already exist.
  • Adopting a published rule set without editing its event-specific fields. The set arrives with somebody else's hacking hours, eligibility scope and judging mode in it.
  • 在简报中对类别加权。 命名它们是你的工作；加权不是，而且这里发布的权重会约束一个尚未完成其计算的兄弟skill。
  • 选择交付物格式。 视频与现场由格式skill解决。你只是转化它。再次选择会产生一个评审计划无法执行的清单。
  • 混淆挑战轨道与分会场轨道。 它们是由不同skill拥有的不同决策，一份借用分会场轨道数量作为挑战轨道数量的简报会发明出没有人赞助的类别。
  • 在构建开始后添加规则。 团队是根据已发布的文本构建的。活动中的新规则会重新评分已经完成的人。
  • 没有最小可行提交的提示。 一个达到自己计划四分之一的团队没有任何可演示的东西，而简报正是决定这一点的东西。
  • 根据赞助商营销文案编写的赞助商轨道。 营销文案命名的是好处，不是可构建的约束。把它改写为一个问题，然后让赞助商确认改写。
  • 在团队形成后裁定特别条款比例。 一个要求的比例——“至少一半团队”——必须在人们选择队友之前发布，否则该规则会悄悄排除已经存在的团队。
  • 采用已发布的规则集但不编辑其特定活动字段。 该规则集带有别人的黑客时间、资格范围和评审模式。

Measurement

衡量

Every gate below is self-set rather than an industry standard; say so when presenting it. Do not borrow a disqualification, invalid-submission, rule-dispute or completion rate from another event as a target: the numbers are not comparable across formats, sizes and audiences.
No platform or academic survey of the field publishes an aggregate disqualification or rule-dispute rate at all. The closest a named event gets is one organizer's own post-hoc count, posted publicly mid-controversy, of roughly a quarter of its submissions arriving as an idea with nothing built. That is one event, self-reported, defending one judging dispute, and not a figure to import anywhere else.
Pass threshold (structural, one only): before publication, all seven exist in writing with zero blanks.
  1. the hacking window as start and end wall-clock times
  2. the eligibility statement
  3. the team-size rule
  4. the per-track problem statement with its minimum viable submission
  5. the submission checklist matching the chosen demo format
  6. the named evaluation categories
  7. the submission deadline with its late policy
Iterate until the count is seven.
Ambiguity gate (before publication): for each rule, name the reading a team arguing the opposite would use. A rule with a second plausible reading is not yet written.
Signals to record for the next edition (self-set):
  • every clarification question asked during the event
  • submissions rejected as invalid and why
  • challenge tracks that drew no entries
Each one names a sentence the next brief needs, or a track that should not exist.
下面的每个门槛都是自定义的，而不是行业标准；在呈现时请说明。不要借用另一个活动的取消资格率、无效提交率、规则争议率或完成率作为目标：这些数字在不同格式、规模和受众之间不可比。
没有任何平台或学术调查发布该领域的总体取消资格率或规则争议率。命名活动最接近的是某位组织者自己的事后计数，在争议中公开发布，其大约四分之一的提交是只有一个想法而没有任何构建。那是一个活动，自我报告，为一次评审争议辩护，不是可以导入任何其他地方的数字。
通过门槛（结构性，仅一个）： 发布前，所有七项都以书面形式存在，零空白。
  1. 黑客时间窗口的起止墙钟时间
  2. 资格声明
  3. 团队规模规则
  4. 每个轨道的含最小可行提交的问题陈述
  5. 与选定的演示格式匹配的提交清单
  6. 命名的评估类别
  7. 带逾期政策的提交截止时间
迭代直到计数为七。
歧义门槛（发布前）： 对每条规则，说出持相反意见的团队会使用的解读。一个存在第二种合理解读的规则还没有写好。
为下一版记录的信号（自定义）：
  • 活动期间提出的每个澄清问题
  • 被拒绝为无效的提交及其原因
  • 没有吸引任何参赛的挑战轨道
每一个都指出了下一份简报需要的一句话，或一个不应该存在的轨道。

Invocation examples

调用示例

  • "Write the challenge brief for our 36-hour AI hackathon - two sponsor tracks and a beginners track."
  • "Our sponsor wants their API used. How do we word that without breaking the event if it goes down?"
  • "What rules and eligibility text do we publish, and what do we not write ourselves?"
  • "Turn our chosen expo-table judging into a submission checklist and deadline."
  • "We have a theme but no problem statements. How specific should they be for one weekend?"
Expected output: a publishable brief carrying
  1. the rules and eligibility text with its edited fields listed
  2. the challenge-track structure with the cross-track submission rule
  3. one problem statement per track at a stated specificity rung, each with a minimum viable submission
  4. sponsor framing with its fallback sentence
  5. the named evaluation categories and the exclusion list
  6. the submission checklist derived from the demo format, with deadline and late policy
Present it section by section for validation before publication.
  • “为我们的36小时AI黑客松编写挑战简报——两个赞助商轨道和一个初学者轨道。”
  • “我们的赞助商希望他们的API被使用。我们如何措辞，才能在其宕机时不破坏活动？”
  • “我们应该发布什么规则和资格文本，什么不自己写？”
  • “把我们选定的展台评审转化为提交清单和截止时间。”
  • “我们有一个主题但没有问题陈述。对于一个周末，它们应该具体到什么程度？”
预期输出：一份可发布的简报，包含
  1. 规则和资格文本，列出其编辑过的字段
  2. 挑战轨道结构，包含跨轨道提交规则
  3. 每个轨道一个问题陈述，处于声明的具体性层级，每个都带有最小可行提交
  4. 赞助商框架及其备用句子
  5. 命名的评估类别和排除列表
  6. 从演示格式推导的提交清单，包含截止时间和逾期政策
发布前逐节呈现以供验证。

References

参考文献

  • references/rules-and-eligibility-source-text.md
  • references/problem-statement-patterns.md
  • references/submission-checklist-and-categories.md
  • references/rules-and-eligibility-source-text.md
  • references/problem-statement-patterns.md
  • references/submission-checklist-and-categories.md