Back to Details

hackathon-cash-prize

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Hackathon Cash Prize

黑客松现金奖金

You decide what a hackathon gives its winners: the medium, the pool size, the split, who may receive an award, and how the handover happens without creating an obligation nobody checked.
Organizers ask about cash first. Cash is not the recommended answer, and the one organizer guide that takes a position takes the opposite one. Read the medium menu before assuming the user needs a number.
你决定黑客松给获胜者什么：媒介、奖金池大小、分配方式、谁可以获奖，以及如何交接，而不会产生无人核查的义务。
组织者首先问现金。现金不是推荐答案，而唯一有立场的组织者指南采取了相反的立场。在假设用户需要数字之前，先阅读媒介菜单。

What you own, and what is already decided

你拥有什么，什么已经决定

You own the prize: medium, total pool, split shape, eligibility to receive, and the payout mechanic.
  • The rank is not yours. 
    samber/dev-event-organizer-skills@hackathon-judging
    produces the ranked outcome per track and hands it to you. Turn a rank into an award. Never re-open a placement, and never let the size of a prize influence who won it.
  • The rules document is not yours. 
    samber/dev-event-organizer-skills@hackathon-brief-design
    owns the published brief, including eligibility to compete: who may enter, at what age, from where, in what employment. You own the narrower question of who may legally receive an award once a rules-eligible team has won. Hand that text to the brief rather than drafting a rules document yourself.
    • Neither skill drew this split before this one existed. State it plainly when you present it, because a reader who has used the brief skill expects eligibility to live there.
  • The ceiling is not yours. 
    samber/dev-event-organizer-skills@event-budget
    sets the Prizes line inside the overall P&L. Propose a pool and a split that fit inside whatever that line carries.
    • Never invent a pool size independent of it. If that line does not exist yet, say so rather than sizing against nothing.
    • That skill names this one and describes the hand-off the same way, so you consume an agreed boundary rather than assert one.
  • A sponsor-funded prize is sold elsewhere and delivered elsewhere. 
    samber/dev-event-organizer-skills@event-sponsor-pricing
    prices the add-on that funds it; 
    samber/dev-event-organizer-skills@event-sponsor-fulfillment
    delivers it as a tracked perk. You decide its shape - medium, split, eligibility - once the sponsorship is signed.
    • Neither of those skills names this one, and neither says anything about a competition prize: the fulfillment skill's only prize rung is the booth raffle below.
    • So you assert this boundary into empty space rather than repeat an agreement. Say so.
  • A raffle prize is not a competition prize. A booth raffle is an attendee incentive open to any attendee, and it belongs to 
    samber/dev-event-organizer-skills@event-sponsor-fulfillment
    . A competition prize is awarded on a judged rank. Both are sponsor-funded and both are called "prize", but the mechanics differ and so do the eligibility questions.
Every ranking below is a default, not a law. After the interview, re-rank each menu against what you know: a sponsor's credits already in hand, an organizer with no legal entity, a hardware event whose participants want components, a returning event whose last edition already published a prize structure.
你拥有奖项：媒介、总奖金池、分配模式、接收资格，以及支付机制。
  • 排名不是你的。 
    samber/dev-event-organizer-skills@hackathon-judging
    生成每个赛道的排名结果并交给你。将排名转化为奖项。绝不重新打开排名，绝不让奖金大小影响谁获胜。
  • 规则文档不是你的。 
    samber/dev-event-organizer-skills@hackathon-brief-design
    拥有已发布的简要，包括参赛资格：谁可以参加，年龄限制，从哪里，处于什么雇佣关系。你拥有更窄的问题：一旦规则合格的团队获胜，谁可以合法接收奖项。将该文本交给简要，而不是自己起草规则文档。
    • 在本文档存在之前，这两个skill都没有划分这个界限。在呈现时明确说明，因为使用过简要skill的读者会期望资格归属在那里。
  • 上限不是你的。 
    samber/dev-event-organizer-skills@event-budget
    在整体损益表中设置奖金行。提出适合该行所承载的奖金池和分配方案。
    • 绝不独立于它发明奖金池大小。如果该行尚不存在，说出来，而不是凭空设定大小。
    • 该skill命名了本skill，并以相同方式描述了交接，因此你消费的是已商定的边界，而不是主张一个。
  • 赞助商资助的奖金在其他地方出售并在其他地方交付。 
    samber/dev-event-organizer-skills@event-sponsor-pricing
    为资助它的附加项目定价；
    samber/dev-event-organizer-skills@event-sponsor-fulfillment
    将其作为跟踪的福利交付。一旦赞助签署，你决定其形状 - 媒介、分配、资格。
    • 这两个skill都没有命名本skill，也没有提到竞赛奖金：履约skill的唯一奖金梯队是下面的展台抽奖。
    • 因此你将这个边界断言到空空间中，而不是重复协议。说出来。
  • 抽奖奖品不是竞赛奖金。 展台抽奖是对任何参与者开放的参与者激励，属于 
    samber/dev-event-organizer-skills@event-sponsor-fulfillment
    。竞赛奖金是根据评判排名授予的。两者都是赞助商资助的，都称为“奖品”，但机制不同，资格问题也不同。
下面的每个排名都是默认值，不是法律。在访谈之后，根据你所知重新排序每个菜单：已到手的赞助商积分、没有法律实体的组织者、参与者想要组件的硬件活动、上一版已发布奖品结构的回归活动。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 4-9 exist because the menus turn on them and no other question surfaces the facts they carry.
  1. What does the Prizes line in the event budget carry, and has it been set at all? (Fixed input - you size inside it, you do not raise it.)
  2. What track and place structure did the brief already publish, and did any of it promise a prize? Read the published rules before designing anything; a prize promised in writing is a commitment, not an option.
  3. Which sponsors fund a prize, what did they buy, and is the funding cash, product credits, hardware, or an opportunity their own company controls?
  4. Could any winner be a minor, and could any winner be outside the organizer's own country? Ask both explicitly - these two facts delete rungs from two menus and no other question surfaces them.
  5. Does the organizing team have its own legal entity, or does it run under a school, a company, or a fiscal host? This decides who can even sign a payout, and how long money takes to move.
  6. Are organizers, volunteers, mentors, judges or sponsor employees allowed to compete, and if so, may they win? These are two different permissions and most events conflate them.
  7. Do you want the prize to buy attention before the event, or to reward the winners after it? A prize sized for marketing and a prize sized for the winners are different decisions with different failure modes.
  8. What is the effort ceiling: organizer hours before the event, whether anyone will chase a winner for paperwork afterwards, and how reversible a mistake can afford to be?
  9. By what date must the prize structure be published, and is this a one-off edition or a recurring event whose structure should still hold next year?
Q7 through Q9 move specific rungs. Name which as you re-rank.
  • A near publication date (Q9) promotes the media that need no procurement lead time: recognition and credits first, cash only where the medium menu's delete conditions do not fire. It demotes gear, which the same menu's backorder warning puts furthest out.
  • An attention-before-the-event intent (Q7) is the only thing that promotes a flagship pool. A reward-the-winners intent leaves it starved.
  • A one-off edition (Q9) promotes the sponsor-funded pool, whose fundraising is already being done elsewhere. A recurring mandate promotes what is written once and reused, the standard-form payout text and the published eligibility paragraph, and it is what makes a counsel review worth its cost across editions rather than once.
  • A low effort ceiling (Q8) deletes the flat-across-many-tracks split, whose entire cost is the per-winner check repeated.
一次问一个问题，尽可能采用多项选择。问题4-9存在是因为菜单取决于它们，没有其他问题能揭示它们所携带的事实。
  1. 活动预算中的奖金行承载什么？是否已经设置？(固定输入 - 你在其中调整大小，而不是提高它。)
  2. 简要已经发布了什么赛道和名次结构？其中任何部分是否承诺了奖金？在设计任何内容之前阅读已发布的规则；书面承诺的奖金是承诺，不是选项。
  3. 哪些赞助商资助奖金？他们购买了什么？资金是现金、产品积分、硬件，还是其自有公司控制的机会？
  4. 任何获胜者可能是未成年人吗？任何获胜者可能在组织者所在国家之外吗？明确询问这两个 - 这两个事实从两个菜单中删除梯队，没有其他问题能揭示它们。
  5. 组织团队有自己的法律实体，还是在学校、公司或财务托管下运营？这决定了谁能够签署支付，以及资金转移需要多长时间。
  6. 组织者、志愿者、导师、评委或赞助商员工可以参赛吗？如果可以，他们可以赢吗？这是两个不同的权限，大多数活动混淆了它们。
  7. 你希望奖金在活动前购买注意力，还是在活动后奖励获胜者？为营销而设的奖金和为获胜者而设的奖金是不同的决策，具有不同的失败模式。
  8. 努力上限是什么：活动前的组织者小时数，之后是否会有人追逐获胜者处理文书工作，以及错误可以承受的可逆程度？
  9. 奖品结构必须在什么日期之前发布？这是一次性版本还是定期活动，其结构明年应该仍然有效？
Q7到Q9移动特定的梯队。在重新排序时说出哪些。
  • 接近发布日期（Q9） 提升不需要采购提前期的媒介：首先认可和积分，只有在媒介菜单的删除条件不触发时才现金。它降级了设备，同一个菜单的缺货警告将其排在最后。
  • 活动前吸引注意力的意图（Q7） 是唯一提升旗舰奖金池的因素。奖励获胜者的意图则让它匮乏。
  • 一次性版本（Q9） 提升赞助商资助的奖金池，其筹款已经在其他地方进行。定期任务提升了一次编写、重复使用的内容，标准格式支付文本和已发布的资格段落，并且它使法律顾问审查在多个版本中值得其成本，而不仅仅是一次。
  • 低努力上限（Q8） 删除跨多个赛道的平均分配，其全部成本是重复的每个获胜者检查。

Workflow

工作流

  1. Run the interview. Read the budget's Prizes line (Q1) and the published brief (Q2) first.
  2. Answer the medium question before the size question. The medium decides which legal categories are even live, and half the sizing conversation disappears once the prize is not money. Load references/prize-medium-catalog.md.
  3. Size the pool inside the Prizes line, and separate the organizer's own baseline from the sponsor-funded part. They have different ceilings and different owners.
  4. Choose the split shape against the track structure the brief already published, not against a blank page.
  5. Write the eligibility-to-receive text and hand it to 
    samber/dev-event-organizer-skills@hackathon-brief-design
    for the rules document. Load references/eligibility-to-receive-text.md.
  6. Pick the payout rigor rung, and name every exposure category the chosen medium and winner pool trigger. Route each one - never answer it. Load references/payout-exposure-categories.md.
  7. Publish the prize structure in the brief before submissions close. A prize announced after teams have chosen what to build has already failed at motivating anything.
  8. On the day, take the ranked outcome from 
    samber/dev-event-organizer-skills@hackathon-judging
    and award against the published structure. Record what was actually handed over, to whom, and what remains outstanding.
Present the structure section by section for validation - medium, pool, split, eligibility, payout mechanic - before any of it reaches the published brief. Publication is the point of no return, because a published prize is a promise.
If your harness has persistent memory, record:
  • the medium and why
  • the pool and the ceiling it fit inside
  • the split shape
  • the eligibility carve-outs
  • which exposure categories were routed to whom
  1. 运行访谈。首先阅读预算的奖金行（Q1）和已发布的简要（Q2）。
  2. 在回答大小问题之前回答媒介问题。 媒介决定哪些法律类别存在，一旦奖金不是钱，一半的规模对话就消失了。加载 references/prize-medium-catalog.md。
  3. 在奖金行内调整奖金池大小，并将组织者自己的基线从赞助商资助部分中分离出来。它们有不同的上限和不同的所有者。
  4. 根据简要已经发布的赛道结构选择分配形状，而不是在白纸上选择。
  5. 编写接收资格文本并将其交给 
    samber/dev-event-organizer-skills@hackathon-brief-design
    用于规则文档。加载 references/eligibility-to-receive-text.md。
  6. 选择支付严格度梯队，并命名所选媒介和获胜者群体触发的每个风险类别。每条都引导 - 绝不回答。加载 references/payout-exposure-categories.md。
  7. 在提交截止前将奖品结构发布在简要中。在团队选择构建什么之后宣布的奖金已经无法激励任何东西。
  8. 活动当天，从 
    samber/dev-event-organizer-skills@hackathon-judging
    获取排名结果，并根据已发布的结构颁奖。记录实际交接了什么，给谁，以及还有什么未完成。
逐节呈现结构以供验证 - 媒介、奖金池、分配、资格、支付机制 - 然后才进入已发布的简要。发布是无可返回点，因为已发布的奖金是承诺。
如果你的harness有持久记忆，记录：
  • 媒介及其原因
  • 奖金池及其所适配的上限
  • 分配形状
  • 资格除外
  • 哪些风险类别被引导给了谁

Prize medium

奖品媒介

Five rungs:
  1. Cash
  2. Gear: hardware, components, tools a participant keeps.
  3. Credits and vouchers: cloud or SaaS credits, gift cards, makerspace credit.
  4. Opportunity: a conference ticket, a mentorship slot, an interview or investor introduction.
  5. Recognition only: a trophy, a title, a public write-up, no transferable value.
The value axis here is counterintuitive. MLH's organizer guide frames the prize decision as behavioural rather than monetary: prizes "say a lot about who you are as a community, why you are there in the first place, and they influence the vibe of your event - big time." MLH states its own position on cash: "While cash prizes are easy for events, we do not recommend them. The perceived value of a cash prize is much lower than traditional prizes."
That claim's direction shifts the default order. It is one organizer's stated position, not a measured comparison of outcomes.
  • value (what the winner perceives and what behaviour the prize rewards, per the framing above): 
    opportunity > gear > credits > cash > recognition only
  • effort (sourcing hours, procurement, coordination with a third party, chasing a winner afterwards): 
    opportunity > gear > credits > cash > recognition only
  • compliance cost, as the review each rung triggers and the reversibility it costs: 
    cash > credits > gear > opportunity > recognition only
  • efficiency: 
    gear > recognition only > credits > cash > opportunity
Value and effort run in the same order across all five rungs. So no pair exists where one rung has value greater than or equal to another's and every cost less than or equal. Resist the temptation to manufacture a disagreement by calling cash the cheapest rung outright: cash is cheapest to procure and dearest to hand over, which is why that cost sits on the compliance axis rather than the effort axis.
The compliance axis is what re-orders this menu, and it is why the default is neither the most valued rung nor the cheapest. Cash moves through a payment rail to a named individual, and that rail pulls in the tax, cross-border and minor-payout categories; a keyboard handed over at a table does not. Credits sit beside cash because a redeemable, resellable code carries monetary value without ever touching a bank.
That payment rail is documented practice, not a hypothesis. Devpost's own prize-claim process requires a cash winner to submit a tax-identification form before funds release, with a separate form for an international individual and another for an organization, and the platform states plainly that working out which one applies is each winner's own responsibility. General tax-compliance practice treats a gift card or voucher the same way it treats cash for reporting purposes, and values physical merchandise through a fair-market-value mechanism instead: the sourced reason credits sit beside cash on this axis rather than beside gear.
The opportunity rung's place on this axis rests on reasoning alone. It stays the menu's least confident cell, so name it as an open question when you present the ordering.
  • Gear - the default. MLH's own recommended direction, and the one rung that pairs high perceived value with no payment rail. It costs real procurement hours and carries a known constraint: many items will be backordered, so order prizes early to have them in time. It also carries a unit-count consequence the other rungs do not, covered on the split menu.
  • Recognition only. Neither a fallback nor a demotion. hackathon.guide's author runs events on this rung deliberately: "don't make winners and losers. Just don't. There has never been beer, competitions, or time pressure at my hackathons." That is a civic-tech organizer's own practice, so the rung is genuinely chosen, though it does not necessarily fit a competitive student event.
    • Support from a different angle: MLH, PennApps, Papers We Love and NASA Space Apps all lead their public positioning with learning, building and sharing rather than prize size. An event positioned that way and awarding recognition only reads as consistent, not cheap.
    • Promotion condition, keyed to Q7: the prize rewards the winners rather than buys attention, or Q5 says the team has no legal entity and no fiscal host, in which case this is the only rung that needs neither.
    • Favour a form that outlives the ceremony. A trophy passed from cohort to cohort, or a public acknowledgement from someone the winners will recognise, holds value longer than a certificate nobody keeps.
  • Credits and vouchers. Cheap when a sponsor already holds them (Q3) and near-free to that sponsor, which is why they appear in sponsor-funded tracks more than anywhere else. They carry expiry dates, redemption regions and account requirements a winner can fail to satisfy months later. State the expiry in the published prize structure or you will hear about it.
  • Cash. Cheapest to procure and top of the compliance axis, which is why efficiency ranks it fourth rather than first. Delete it, from this menu and from the axis lines above, when Q4 says a winner could be a minor or outside the organizer's country, or Q5 says there is no legal entity and no fiscal host. The machinery to pay it correctly does not exist yet in those cases, and a cash prize parked at the bottom of a menu quietly becomes the plan at the ceremony.
  • Opportunity - the starved option: top of value, top of effort, so efficiency never picks it. MLH names this rung in its own catalogues: conference tickets, "Lunch with your hero", a company visit, and an introduction to present to a seed funder in its hardware guide.
    • Its legal treatment is unsettled: an award that functions as a job or investment introduction plausibly intersects employment or securities rules in some jurisdictions. Name that as an open question when you offer it.
    • Promotion condition, keyed to Q3: an external party - a sponsor's hiring team, a conference, an investor - has committed in writing.
    • Delete it, from this menu and from the axis lines above, when no such commitment exists: an opportunity the organizer cannot actually deliver is the one prize that fails publicly, after the winner has been announced.
The full medium catalogue, the receipt-and-return practice, and the unit-count arithmetic are in references/prize-medium-catalog.md.
五个梯队：
  1. 现金
  2. 设备：硬件、组件、参与者保留的工具。
  3. 积分和代金券：云或SaaS积分、礼品卡、创客空间积分。
  4. 机会：会议门票、导师席位、面试或投资者介绍。
  5. 仅认可：奖杯、头衔、公开报道，没有可转移价值。
这里的价值轴是反直觉的。MLH的组织者指南将奖品决策框定为行为而非金钱：奖品“说明了你作为社区是谁，你最初为什么在那里，它们影响你活动的氛围 - 非常重要。”MLH对现金的立场：“虽然现金奖品对活动来说很容易，但我们不建议。现金奖品的感知价值远低于传统奖品。”
该主张的方向改变了默认顺序。这是一个组织者陈述的立场，不是对结果的测量比较。
  • 价值（获胜者感知到什么以及奖品奖励什么行为，根据上述框架）：
    机会 > 设备 > 积分 > 现金 > 仅认可
  • 努力（采购小时数、采购、与第三方的协调、之后追逐获胜者）：
    机会 > 设备 > 积分 > 现金 > 仅认可
  • 合规成本，作为每个梯队触发的审查及其可逆性成本：
    现金 > 积分 > 设备 > 机会 > 仅认可
  • 效率：
    设备 > 仅认可 > 积分 > 现金 > 机会
价值和努力在所有五个梯队中按相同顺序运行。因此不存在一个梯队价值大于或等于另一个且每个成本小于或等于的情况。抵制通过称现金为最便宜的梯队来制造分歧的诱惑：现金采购最便宜，交接最贵，这就是为什么该成本位于合规轴上而不是努力轴上。
合规轴是重新排序此菜单的原因，也是默认值既不是最有价值的梯队也不是最便宜的原因。现金通过支付轨道流向指定个人，该轨道引入税务、跨境和未成年人支付类别；在桌子上递出的键盘则不会。积分与现金相邻，因为可兑换、可转售的代码带有货币价值，而无需接触银行。
该支付轨道是有记录的做法，而不是假设。Devpost自己的奖品领取流程要求现金获胜者在资金释放前提交税务身份表格，国际个人和组织的表格不同，平台明确表示确定适用哪一个是每个获胜者自己的责任。一般税务合规实践将礼品卡或代金券视同为现金进行报告，并通过公平市场价值机制评估实物商品：这是积分在此轴上而非设备旁边的来源原因。
机会梯队在此轴上的位置仅基于推理。它仍然是菜单上最不自信的单元格，因此在呈现顺序时将其作为开放问题说明。
  • 设备 - 默认。 MLH自己推荐的方向，也是将高感知价值与无支付轨道配对的唯一梯队。它花费真正的采购时间，并带有一个已知约束：许多物品将缺货，所以尽早订购奖品以便及时到达。它还有一个单位数量的后果，其他梯队没有，在分配菜单中涉及。
  • 仅认可。 既不是后备也不是降级。hackathon.guide的作者故意运行此梯队：“不要制造赢家和输家。就是不要。我的黑客松从来没有啤酒、比赛或时间压力。”这是公民科技组织者自己的实践，所以该梯队是真正被选择的，尽管它不一定适合竞争性的学生活动。
    • 从不同角度支持：MLH、PennApps、Papers We Love和NASA Space Apps都以学习、构建和分享作为公开定位，而不是奖金大小。以这种方式定位且仅授予认可的活动读起来是一致的，而不是廉价。
    • 提升条件，与Q7相关：奖品奖励获胜者，而不是购买注意力，或 Q5说团队没有法律实体且没有财务托管，在这种情况下这是唯一不需要两者的梯队。
    • 支持一种超越仪式的形式。从一届传给下一届的奖杯，或获胜者会认可的公众感谢，比没人保留的证书更有持久价值。
  • 积分和代金券。 当赞助商已经拥有它们时（Q3）便宜，对该赞助商几乎免费，这就是为什么它们出现在赞助商资助的赛道中多于其他地方。它们带有到期日期、兑换区域和账户要求，获胜者可能在几个月后无法满足。在已发布的奖品结构中说明到期日期，否则你会听到它。
  • 现金。 采购最便宜，合规轴最高，这就是为什么效率将其排在第四而不是第一。当Q4说获胜者可能是未成年人或在组织者国家之外，或Q5说没有法律实体且没有财务托管时，将其从本菜单和上述轴线上删除。 在这些情况下，正确支付它的机制尚不存在，而停在菜单底部的现金奖品会在仪式上悄悄成为计划。
  • 机会 - 被忽视的选项：价值第一，努力第一，所以效率永远不会选择它。MLH在自己的目录中命名此梯队：会议门票、“与你的英雄共进午餐”、公司参观，以及在其硬件指南中介绍给种子基金的机会。
    • 其法律待遇未定：作为工作或投资介绍的奖项可能在某些司法管辖区涉及就业或证券规则。在提供时将其作为开放问题说明。
    • 提升条件，与Q3相关：外部方 - 赞助商的招聘团队、会议、投资者 - 已书面承诺。
    • 当没有这样的承诺时，将其从本菜单和上述轴线上删除：组织者实际上无法交付的机会是唯一在获胜者宣布后公开失败的奖品。
完整的媒介目录、接收和退货实践，以及单位数量计算在 references/prize-medium-catalog.md。

Total pool size

总奖金池大小

Four rungs:
  1. No monetary pool
  2. Modest pool: sized to the Prizes line.
  3. Sponsor-funded pool: the organizer's own baseline is nothing and the pool scales only with signed commitments.
  4. Flagship pool: deliberately sized to be the event's headline.
  • value (submissions drawn and turnout - argued, not measured): 
    flagship > sponsor-funded > modest > no monetary pool
  • effort (fundraising, budget negotiation, and the procurement or payout volume that follows): 
    flagship > sponsor-funded > modest > no monetary pool
  • compliance cost: 
    flagship > sponsor-funded > modest > no monetary pool
  • efficiency: 
    sponsor-funded > modest > no monetary pool > flagship
All three axes run in the same order. In every one of the six pairs the higher-value rung is strictly worse on effort and on compliance cost, so no rung wins any axis for free and no pair can satisfy "value greater than or equal, every cost less than or equal". The ordering below rests on the argument, not on the check.
The payout-rigor menu is vacuous too, for its own separate reason, stated there.
Two things argue against the naive value line. Put both to the user rather than resolving either one.
The value axis rests on an assumption, not a measurement. "Flagship draws more submissions" is untested. Present it to the user as the assumption it is, because the published material cuts both ways and settles nothing.
  • Against sizing for headline value. Devpost's own organizer guidance states that a very low prize can suppress participation, that a modest, well-distributed pool performs as well as a much larger one in its own stated experience, and that more prize money is no guarantee of stronger submissions. Participant engagement, technical support, promotion and simple requirements carry equal weight.
  • For it, as a single-edition illustration rather than a controlled measurement. ETHGlobal Bangkok drew 713 project submissions from roughly 1,950 hackers in the same edition it ran its largest-ever prize pool, a record on both counts. HackYeah's most recent public figures pair nearly 3,000 attendees with over 300 submitted projects against a prize pool the organizers do not break out by placement.
Neither event controls for its own year-over-year growth or publishes a same-edition comparison against a smaller pool. Read both as texture, not as evidence for the axis either way.
A counterweight points the other way regardless of participation counts. The four organizations above lead with learn, build and share rather than prize size. Leading with a headline pool therefore competes on ground the credible large events deliberately vacate, and it selects for the participants who came for the money.
  • Sponsor-funded - the default where any sponsor is in play (Q3). The sponsorship skills already do the fundraising, the pool scales with what actually got signed rather than with hope, and it draws nothing from the organizer's own Prizes line. Its failure mode is a pool announced before the money lands.
  • Modest, sized to the Prizes line - the default where no sponsor funds a prize. A real ceiling bounds it, which is what makes it safe.
  • No monetary pool. Near-zero on every axis, and a legitimate structure rather than a failure. It ranks third rather than first only because it forgoes the sponsor inventory a funded prize creates.
  • Flagship - the starved option: top of every axis, so efficiency never picks it. Promotion condition, keyed to Q1 and Q7: the Prizes line is genuinely large enough that the pool fits inside it without moving another line, and the user's stated intent is attention before the event rather than reward after it. Delete it, from this menu and from the axis lines above, when Q1 says the Prizes line has not been set - a headline pool sized against no ceiling is a commitment made on behalf of a budget nobody has written.
四个梯队：
  1. 无金钱奖金池
  2. 适度奖金池：按奖金行调整大小。
  3. 赞助商资助的奖金池：组织者自己的基线为零，奖金池仅随已签署的承诺缩放。
  4. 旗舰奖金池：故意设定为活动的头条。
  • 价值（吸引的提交数和出席率 - 论证的，而非测量的）：
    旗舰 > 赞助商资助 > 适度 > 无金钱奖金池
  • 努力（筹款、预算谈判以及随之而来的采购或支付量）：
    旗舰 > 赞助商资助 > 适度 > 无金钱奖金池
  • 合规成本：
    旗舰 > 赞助商资助 > 适度 > 无金钱奖金池
  • 效率：
    赞助商资助 > 适度 > 无金钱奖金池 > 旗舰
所有三个轴都以相同顺序运行。在六对中的每一对中，更高价值的梯队严格地在努力和合规成本上更差，所以没有梯队免费赢得任何轴，也没有对可以满足“价值大于或等于，每个成本小于或等于”。下面的排序基于论证，而不是检查。
支付严格度菜单也是空的，出于它自己单独的原因，在那里陈述。
有两件事反对朴素的价值线。两者都交给用户，而不是解决任何一个。
价值轴基于假设，而非测量。 “旗舰吸引更多提交”未经测试。将其作为假设呈现给用户，因为已发布的材料双方都有，没有定论。
  • 反对以头条价值设定规模。 Devpost自己的组织者指南指出，非常低的奖品会抑制参与，适度的、分布良好的奖金池在其自身陈述的经验中与更大的奖金池表现相同，更多的奖金并不能保证更强的提交。参与者参与、技术支持、宣传和简单需求具有同等权重。
  • 支持它，作为单版插图而非受控测量。 ETHGlobal曼谷在运行其有史以来最大奖金池的同一版中吸引了来自大约1,950名黑客的713个项目提交，两项都是记录。HackYeah最近的公开数字将近3,000名与会者与超过300个提交项目配对，奖品池组织者没有按名次细分。
两个事件都没有控制自己的逐年增长，也没有发布与较小奖金池的同版比较。将两者视为纹理，而不是轴线的证据。
无论参与人数如何，一个反作用力指向另一方向。 上述四个组织以学习、构建和分享领先，而不是奖金大小。因此，以头条奖金池领先是在可信大活动故意放弃的领域竞争，并且它选择了那些为钱而来的参与者。
  • 赞助商资助 - 在任何赞助商参与的默认（Q3）。 赞助技能已经做了筹款，奖金池随实际签署的内容缩放，而不是希望，并且不从组织者自己的奖金行中提取。其失败模式是在资金到位之前宣布奖金池。
  • 适度，按奖金行调整 - 没有赞助商资助奖金时的默认。 真实的上限约束它，这就是使它安全的原因。
  • 无金钱奖金池。 每个轴几乎为零，是合法的结构而不是失败。它排名第三而不是第一，只是因为它放弃了资金化奖金池创造的赞助商库存。
  • 旗舰 - 被忽视的选项：每个轴顶部，所以效率永远不会选择它。提升条件，与Q1和Q7相关：奖金行真正足够大，奖金池可以装入而不移动另一行，且用户陈述的意图是活动前的注意力而不是活动后的奖励。当Q1说奖金行尚未设置时，将其从本菜单和上述轴线上删除 - 针对没有上限设定的头条奖金池是代表尚未编写的预算做出的承诺。

Split shape

分配形状

Four rungs:
  1. Winner take most: one large award, thin or no runner-up.
  2. Graduated podium: first, second, third, descending.
  3. Track only: no overall award; every prize belongs to a challenge track.
  4. Flat across many tracks: many comparable awards, no headline.
  • value (teams with something reachable to aim at, sponsor-track completion, a beginner's chance of placing): 
    flat across many tracks > graduated podium > track only > winner take most
  • effort (award count, per-winner eligibility check repeated, and per-unit procurement): 
    flat across many tracks > track only > graduated podium > winner take most
  • compliance cost, as the number of times an exposure category has to be re-checked against a different recipient: 
    flat across many tracks > track only > graduated podium > winner take most
  • efficiency: 
    graduated podium > winner take most > track only > flat across many tracks
The efficiency line ranks graduated podium above track only because graduated podium has higher value than track only, lower effort, and lower compliance cost.
Devpost's own organizer guidance backs the value axis directly: splitting a pool into many chances to win is, in the platform's stated experience, the most effective structure, because participants want a reasonable chance of placing before they commit the hours to build.
Dominance check:
  • Flat never dominates (top of every cost axis).
  • Winner take most never dominates (bottom of value).
  • Track only dominates nothing.
Track only sits below graduated podium on value for a specific reason. With no overall award, a team that used no sponsor's product has nothing at all to aim at, and those are frequently the teams the event most wants to keep.
One mechanic makes this menu concrete and is routinely missed: a non-cash prize is counted in units per person, and cash is not. MLH raises it as one of the rules an organizer must decide - "Can the teams be as large as they want, and you might just have only 4 prizes?"
MLH gives the matching practice on the procurement side: "Save the receipts for any prizes. If a winning team has 3 members instead of 4 you can return the prize to add to the next year's budget." So plan a gear or credits split in whole units against the team-size cap, with a stated rule for the leftover unit. A cash split divides arbitrarily instead, which is why the medium comes first.
  • Graduated podium - the default. One extra award and one extra eligibility check beyond the cheapest rung, and it buys a second and third team something real to finish for. One published shape: PennApps split its top-three pool 50/30/20 across grand prize, second and third, so grand prize ran two and a half times third place and second ran one and a half times.
  • Winner take most. Cheapest on every axis, and it motivates only the teams who already think they can win. Delete it, from this menu and from the axis lines above, as soon as any sponsor funds a track (Q3): that sponsor bought a named award and this shape has nowhere to put it.
  • Track only. Correct when the brief published tracks and no overall category, which is a decision made in the brief, not here. Where an overall category exists in the published brief, this rung contradicts it.
  • Flat across many tracks - the starved option: top of every cost axis, and every extra award repeats the whole eligibility and payout check against a new recipient. Promotion condition, keyed to Q2 and Q3: several sponsor tracks are already published and the medium is non-cash, so the repeated per-winner check is a handover rather than a payment.
    A flat structure commonly layers distinct award types rather than repeating one shape:
    • a ranked podium
    • an audience-choice award decided by attendee vote rather than by judges
    • one horizontal prize per sponsor technology or approach, so each sponsor owns a named award without diluting the podium
    • where a parallel non-judged activity runs alongside the main competition, its own small prize, kept clearly apart from anything judged
    Each layer is still one award on this menu's own terms. Repeat the eligibility and payout check for every one.
四个梯队：
  1. 赢家通吃大部分：一个大奖项，稀薄或没有亚军。
  2. 逐步领奖台：第一、第二、第三，递减。
  3. 仅赛道：没有整体奖项；每个奖品都属于挑战赛道。
  4. 跨多个赛道平均：许多相当的奖项，没有头条。
  • 价值（有东西可争取的团队、赞助商赛道完成、初学者有机会获奖）：
    跨多个赛道平均 > 逐步领奖台 > 仅赛道 > 赢家通吃大部分
  • 努力（奖项数量、每个获胜者资格检查重复、每单位采购）：
    跨多个赛道平均 > 仅赛道 > 逐步领奖台 > 赢家通吃大部分
  • 合规成本，作为风险类别必须针对不同接收者重新检查的次数：
    跨多个赛道平均 > 仅赛道 > 逐步领奖台 > 赢家通吃大部分
  • 效率：
    逐步领奖台 > 赢家通吃大部分 > 仅赛道 > 跨多个赛道平均
效率线将逐步领奖台排在仅赛道之上，因为逐步领奖台比仅赛道有更高的价值、更低的努力和更低的合规成本。
Devpost自己的组织者指南直接支持价值轴：将奖金池分成许多获胜机会，在该平台陈述的经验中，是最有效的结构，因为参与者在投入时间构建之前想要一个合理的获奖机会。
优势检查：
  • 平均从不占优势（每个成本轴顶部）。
  • 赢家通吃大部分从不占优势（价值底部）。
  • 仅赛道不支配任何东西。
仅赛道在价值上低于逐步领奖台有一个具体原因。如果没有整体奖项，未使用任何赞助商产品的团队完全没有目标，而这些往往是活动最想保留的团队。
一个机制使这个菜单具体且经常被错过：非现金奖品按每人单位计数，现金则不然。 MLH将其作为组织者必须决定的规则之一提出：“团队可以任意大，而且你可能只有4个奖品？”
MLH给出了采购方面的匹配实践：“保存任何奖品的收据。如果获胜团队有3名成员而不是4名，你可以退回奖品以添加到下一年的预算。”因此，根据团队规模上限，以整数单位规划设备或积分分配，并为剩余单位制定明确的规则。现金分配则可以任意分割，这就是为什么媒介优先。
  • 逐步领奖台 - 默认。 比最便宜的梯队多一个额外奖项和一次额外资格检查，它为第二和第三团队购买了一些真正的东西去完成。一个已发布的形状：PennApps将其前三名奖金池按50/30/20分配为大奖、第二和第三，所以大奖是第三名的两倍半，第二是一点五倍。
  • 赢家通吃大部分。 每个轴最便宜，它只激励那些已经认为自己能赢的团队。一旦任何赞助商资助赛道（Q3），就将其从本菜单和上述轴线上删除：该赞助商购买了一个命名奖项，而此形状没有地方放置它。
  • 仅赛道。 当简要发布了赛道而没有整体类别时正确，这是简要中的决定，不是这里。如果已发布的简要中存在整体类别，此梯队与之矛盾。
  • 跨多个赛道平均 - 被忽视的选项：每个成本轴顶部，每个额外奖项都对新的接收者重复整个资格和支付检查。提升条件，与Q2和Q3相关：多个赞助商赛道已发布且媒介是非现金，因此重复的每个获胜者检查是交接而不是支付。
    平均结构通常分层不同的奖项类型，而不是重复一种形状：
    • 排名领奖台
    • 由与会者投票而非评委决定的观众选择奖
    • 每个赞助商技术或方法的一个横向奖项，因此每个赞助商拥有一个命名奖项而不稀释领奖台
    • 当并行非评判活动与主要竞赛同时运行时，其自己的小奖项，与任何被评判的东西明确分开
    每层仍然是此菜单自身术语上的一个奖项。对每个奖项重复资格和支付检查。

Eligibility to receive, and payout rigor

接收资格和支付严格度

Eligibility to receive is not eligibility to compete, and there is published practice for the distinction. MLH's copy-paste rule set states: "This event is limited to students. No volunteers, organizers, or mentors are eligible to win any prizes, though they can work on projects for their portfolio if they wish."
That sentence permits the same people to build and forbids them to win, which is exactly the split. The same source flags age range as a field the copy-paste set deliberately leaves blank for the organizer to fill.
samber/dev-event-organizer-skills@event-volunteer-experience
reaches the same place from the volunteering side, deleting any volunteer reward with real cash value on the grounds that a reward reading as wages stops being volunteering. Treat both as one principle: anyone working the event is out of the receiving pool, whatever they are allowed to build.
Four rungs for the payout mechanic itself:
  1. Informal handover: the prize changes hands on the spot, nothing recorded.
  2. Standard-form payout: published eligibility-to-receive text, a claim step, and identity or status collection appropriate to the medium.
  3. Administered payout: the fiscal host or the funding sponsor runs the payout under its own process and the organizer only facilitates.
  4. Counsel-reviewed payout: a legal review before any prize is announced.
  • value (defensibility if an award is challenged, and exposure actually avoided): 
    counsel-reviewed > administered > standard-form > informal handover
  • effort (hours, coordination with a host or sponsor, and the cost of engaging counsel): 
    counsel-reviewed > administered > standard-form > informal handover
  • compliance cost, as the review each rung triggers and the reversibility it costs: 
    counsel-reviewed > informal handover > administered > standard-form
  • efficiency: 
    standard-form > administered > informal handover > counsel-reviewed
Value and effort run in the same order, exactly as on the pool-size menu. The compliance axis creates no dominance pair either: the rung it re-orders, informal handover, is also the cheapest on effort, so no pair clears every axis at once. The ordering rests on the argument below.
The compliance axis is deliberately non-monotone, and the argument is specific to payouts rather than borrowed from 
samber/dev-event-organizer-skills@hackathon-judging
's conflict menu. Informal handover triggers no review before the event. It defers the whole review to the least reversible moment there is, after money or goods have reached a stranger.
A misjudged rank can be re-announced. A payment cannot be un-made, and a prize handed to the wrong recipient comes back only by asking them to give it back. That asymmetry is why the default is not the cheapest rung.
  • Standard-form payout - the default. One published paragraph and one claim step, both written before the event while they are still cheap. It is the lowest rung on the compliance axis because the review it triggers happens at the only moment a mistake is free.
  • Administered payout. Promotion condition, keyed to Q3 and Q5: a fiscal host holds the money, or the funding sponsor prefers to pay its own track winner directly. Get the division of responsibility in writing before announcing, because "the sponsor is handling it" is not a payout plan.
  • Informal handover. Delete it, from this menu and from the axis lines above, when the prize is cash or a cash equivalent, or when Q4 says any winner could be a minor or outside the organizer's country. It survives only for a handover of goods to an adult recipient at the venue.
  • Counsel-reviewed - the starved option: top of value, effort and compliance cost. Promotion condition, keyed to Q1: a pool large enough that a losing team would ask who decided and on what basis. Promote it by routing to actual counsel or to the fiscal host, never by writing legal-sounding sentences yourself.
Three of Q4-Q6's answers are gates, not menu choices, and the ratio gets no vote on them. A minor in the winner pool, a winner outside the organizer's country, and a sponsor's own employee eligible to win that sponsor's own track each carry a legal obligation. An obligation determines the response instead of being weighed against effort.
When any of the three is live, counsel or the fiscal host reviews the payout before the prize is announced, whatever rung the efficiency line landed on. Efficiency then orders only what is left: how the surviving mechanic is administered, never whether the review happens.
One published mechanic belongs in whatever rung you pick. A prize can be conditional on something the winner must keep doing, and MLH's published rules make prize eligibility depend on the submitted code and video staying public afterwards: "If your repo and video are not public, new winners may be selected." Where you adopt a continuing condition, state in the published structure when the award becomes final, because until then it is revocable and everyone should know it.
The publishable eligibility text, the carve-out list, and the wording to hand to the brief are in references/eligibility-to-receive-text.md.
接收资格不是参赛资格，并且有已发布的实践用于区分。MLH的复制粘贴规则集规定：“此活动仅限于学生。志愿者、组织者或导师没有资格赢得任何奖品，尽管如果他们愿意，他们可以为自己的作品集处理项目。”
这句话允许同一个人构建但禁止他们获胜，这正是分割。同一来源将年龄范围标记为复制粘贴集故意留空以供组织者填写的字段。
samber/dev-event-organizer-skills@event-volunteer-experience
从志愿服务方面到达同一地点，删除任何有真实货币价值的志愿者奖励，理由是读起来像工资的奖励不再是志愿服务。将两者视为一个原则：任何参与活动工作的人都离开接收池，无论他们被允许构建什么。
支付机制本身有四个梯队：
  1. 非正式交接：奖品当场易手，没有记录。
  2. 标准格式支付：已发布的接收资格文本、领取步骤以及适合媒介的身份或状态收集。
  3. 管理支付：财务托管或资助赞助商根据自己的流程运行支付，组织者仅促进。
  4. 顾问审查支付：在宣布任何奖品之前进行法律审查。
  • 价值（如果奖项受到质疑时的可辩护性，以及实际避免的风险）：
    顾问审查 > 管理 > 标准格式 > 非正式交接
  • 努力（小时数、与托管或赞助商的协调以及聘请顾问的成本）：
    顾问审查 > 管理 > 标准格式 > 非正式交接
  • 合规成本，作为每个梯队触发的审查及其可逆性成本：
    顾问审查 > 非正式交接 > 管理 > 标准格式
  • 效率：
    标准格式 > 管理 > 非正式交接 > 顾问审查
价值和努力按相同顺序运行，与奖金池大小菜单完全相同。合规轴也不产生主导对：它重新排序的梯队，非正式交接，也是努力上最便宜的，所以没有对同时清除所有轴。排序基于下面的论证。
合规轴故意非单调，论证特定于支付，而不是从 
samber/dev-event-organizer-skills@hackathon-judging
的冲突菜单借来的。非正式交接在活动前不触发审查。它将整个审查推迟到最不可逆的时刻，即金钱或货物到达陌生人之后。
错误判断的排名可以重新宣布。付款无法撤销，发给错误接收者的奖品只能通过要求他们归还才能回来。这种不对称是为什么默认不是最便宜的梯队。
  • 标准格式支付 - 默认。 一个已发布的段落和一个领取步骤，都在活动之前编写，当时它们还很便宜。它是合规轴上的最低梯队，因为它触发的审查发生在错误是免费的唯一个时刻。
  • 管理支付。 提升条件，与Q3和Q5相关：财务托管持有资金，或资助赞助商更愿意直接支付其赛道的获胜者。在宣布之前以书面形式获得责任分工，因为“赞助商在处理”不是支付计划。
  • 非正式交接。 当奖品是现金或现金等价物，或当Q4说任何获胜者可能是未成年人或在组织者国家之外时，将其从本菜单和上述轴线上删除。 它仅在场馆向成年接收者交接货物时生存。
  • 顾问审查 - 被忽视的选项：价值、努力和合规成本顶部。提升条件，与Q1相关：奖金池足够大，以至于失败团队会问谁决定以及基于什么。通过路由到实际顾问或财务托管来提升它，绝不要自己写听起来像法律的句子。
Q4-Q6中的三个答案是门，而不是菜单选择，比例对它们没有投票权。 获胜者中的未成年人、组织者国家之外的获胜者以及赞助商自己的员工有资格赢得该赞助商自己的赛道，每个都带有法律义务。义务决定响应，而不是与努力权衡。
当三个中的任何一个活跃时，顾问或财务托管在奖品宣布之前审查支付，无论效率线落在哪个梯队。效率然后只排序剩下的：幸存机制如何管理，而不是审查是否进行。
一个已发布的机制属于你选择的任何梯队。奖品可以有条件于获胜者必须继续做某事，MLH已发布的规则使奖品资格取决于提交的代码和视频之后保持公开：“如果您的仓库和视频不公开，可能选择新的获胜者。”在采用持续条件的地方，在已发布的结构中说明奖项何时成为最终，因为在此之前它是可撤销的，每个人都应该知道。
可发布的资格文本、例外列表以及交给简要的措辞在 references/eligibility-to-receive-text.md。

What this skill will never state

此skill永远不会陈述的内容

Contest-law classification, tax withholding and reporting, cross-border payment and the treatment of minors are jurisdiction-specific, and they change. This skill states no numeric threshold, no tax-form name, and no currency amount. Ever. A plausible-sounding threshold in a document telling an organizer how to hand money to a stranger is worse than no guidance at all.
Name the exposure category instead, say every time that the specific threshold or form is jurisdiction-specific, and route it.
  • Contest-law classification - whether a prize competition counts as a skill-based contest or a game of chance in a given jurisdiction, which changes the regulatory regime that applies to it. This is why 
    samber/dev-event-organizer-skills@hackathon-judging
    avoids a coin flip as a tie-break: the tie-break method is one of the few organizer decisions that could move an event across that line.
  • Payer-side tax reporting and withholding on an award with monetary value, which typically attaches to the organizer rather than the winner.
  • Cross-border payment - the payment rail itself, plus whatever local rules and treaty questions apply to a winner in another country.
  • Minors receiving an award, where a guardian may need to receive or countersign it. This is a different question from the one MLH's checklist covers, which is a waiver for a minor to stay at a venue overnight.
  • Sponsor employees receiving that sponsor's own track prize - a live conflict, and a different one from the judging conflict of interest 
    samber/dev-event-organizer-skills@hackathon-judging
    already handles for the rank.
  • Organizers, volunteers, mentors and judges receiving anything, the one category with published practice (see above).
Route each live category to counsel, to the fiscal host, or to the funding sponsor's own legal team.
MLH's organizer guide gives the routing shape rather than the answers, as a pre-flight checklist:
  • nonprofit status
  • insurance
  • who holds signing authority and how long their review takes
  • where funds are held and how quickly they can actually be spent
  • in the source's own words: "Are there any tax requirements we should be aware of? Do we need to keep our receipts?"
For an organizer with no legal entity of its own, the same source names fiscal sponsorship as the standard route, listing Hack Club and Hack+ as hackathon-specific fiscal sponsors. The categories and the routing ladder are set out in references/payout-exposure-categories.md.
竞赛法分类、税务代扣和报告、跨境支付以及未成年人的处理因司法管辖区而异，并且会变化。此skill从不陈述数字阈值、税务表格名称或货币金额。永远。 一份告诉组织者如何向陌生人移交金钱的文档中看似合理的阈值比没有指导更糟。
相反，命名风险类别，每次说具体阈值或形式因司法管辖区而异，并引导它。
  • 竞赛法分类 - 奖品竞赛在给定司法管辖区是否算作基于技能的竞赛或机会游戏，这改变了适用于它的监管制度。这就是为什么 
    samber/dev-event-organizer-skills@hackathon-judging
    避免硬币翻转作为打破平局的方法：打破平局的方法是少数几个可能使活动跨越那条线的组织者决定之一。
  • 付款方税务报告和代扣 对具有货币价值的奖项，通常归属于组织者而不是获胜者。
  • 跨境支付 - 支付轨道本身，加上适用于其他国家获胜者的任何当地规则和条约问题。
  • 未成年人接收奖项，监护人可能需要接收或会签。这与MLH清单涵盖的问题不同，后者是未成年人通宵留在场馆的豁免。
  • 赞助商员工接收该赞助商自己的赛道奖品 - 一个活跃的冲突，与 
    samber/dev-event-organizer-skills@hackathon-judging
    已经处理的排名评判利益冲突不同。
  • 组织者、志愿者、导师和评委接收任何东西，唯一有已发布实践的类别（见上文）。
将每个活跃类别引导给顾问、财务托管或资助赞助商自己的法律团队。
MLH的组织者指南给出了路由形状而不是答案，作为飞行前检查表：
  • 非营利身份
  • 保险
  • 谁拥有签署权以及他们的审查需要多长时间
  • 资金存放在哪里以及实际上多快可以使用
  • 用来源自己的话：“是否有我们应该注意的税务要求？我们需要保留收据吗？”
对于没有自己法律实体的组织者，同一来源将财务赞助命名为标准路线，列出Hack Club和Hack+作为黑客松特定的财务赞助商。类别和路由阶梯在 references/payout-exposure-categories.md 中列出。

Failure modes

失败模式

  • Deciding the size before the medium. Half the sizing conversation concerns money a non-cash prize never involves. Medium first, always.
  • Sizing a pool against no ceiling. A prize announced before the budget's Prizes line exists commits someone else's money on their behalf.
  • Announcing a sponsor-funded prize before the money lands. The award is published, the sponsorship falls through, and the organizer owns the gap personally.
  • Splitting gear as if it divided like cash. A four-unit prize meeting a three-person winning team is a decision you make in advance or improvise at the podium.
  • Letting the prize influence the rank. 
    samber/dev-event-organizer-skills@hackathon-judging
    hands you a ranked outcome. Reshaping the split so a favoured team lands better is re-judging with extra steps.
  • Treating eligibility to compete as eligibility to receive. A volunteer who may build a project for their portfolio is not thereby someone who may take home the award.
  • Answering a tax question. The question feels small every time, and the correct answer is a routing every time.
  • Assuming a sponsor's in-kind prize is worth its retail price. 
    samber/dev-event-organizer-skills@event-sponsor-pricing
    values in-kind at the budget line it displaces. Check that the method transfers before applying it to a prize, because a prize displaces a Prizes-line spend the organizer might never have made.
  • Assuming the podium order matches perceived value for in-kind prizes. Credit or product prizes from different sponsors carry different real utility, so a third-place in-kind prize can be worth more to its winner than a first-place one from a less useful sponsor. Check what each item is actually worth to a recipient before setting tier expectations with the sponsor providing it.
  • 在媒介之前决定大小。 一半的规模对话涉及非现金奖品从未涉及的金钱。媒介第一，永远。
  • 针对没有上限设定规模。 在预算的奖金行存在之前宣布的奖品代表他人承诺了他们的钱。
  • 在资金到位之前宣布赞助商资助的奖品。 奖项已发布，赞助落空，组织者个人承担缺口。
  • 像分割现金一样分割设备。 一个四单位奖品遇到一个三人获胜团队是你提前做出的决定，或在领奖台上即兴发挥。
  • 让奖品影响排名。 
    samber/dev-event-organizer-skills@hackathon-judging
    将排名结果递给你。重塑分配以使受青睐的团队更好地落在那里是用额外步骤重新评判。
  • 将参赛资格视为接收资格。 可以为其作品集构建项目的志愿者并不因此可以带回家奖品。
  • 回答税务问题。 问题每次都感觉很小，正确答案每次都是路由。
  • 假设赞助商的实物奖品值得其零售价。 
    samber/dev-event-organizer-skills@event-sponsor-pricing
    以它取代的预算行估价实物。在应用于奖品之前检查该方法是否转移，因为奖品取代了组织者可能从未做出的奖金行支出。
  • 假设领奖台顺序与实物奖品的感知价值匹配。 来自不同赞助商的积分或产品奖品携带不同的实际效用，因此第三名的实物奖品可能比来自不太有用的赞助商的第一名更有价值。在向提供它的赞助商设定等级期望之前，检查每个项目对接收者的实际价值。

Measurement

测量

Everything below is a self-set gate rather than an industry standard; say so when presenting it. Pool sizes and splits are not comparable across events, so do not borrow another event's number as a target.
Pass threshold (structural, one only): before the brief is published, all six of these exist in writing with zero blanks.
  • The medium.
  • The total pool with the budget line it fits inside.
  • The split with an award count.
  • The eligibility-to-receive text.
  • The payout mechanic naming who hands over what.
  • The list of exposure categories with the person each was routed to.
Iterate until the count is six.
Signals worth recording afterwards (self-set):
  • awards actually handed over versus announced
  • winners who never claimed
  • prize units left over against the team-size rule
  • any eligibility question that came up on the day and had no published answer
Pick two or three and write down the revision each would trigger.
以下所有内容都是自设的门，而不是行业标准；在呈现时说明。奖金池大小和分配在事件之间不可比较，所以不要借用其他事件的数字作为目标。
通过阈值（结构性，仅一个）：在简要发布之前，所有六项都以书面形式存在且零空白。
  • 媒介。
  • 总奖金池及其适配的预算行。
  • 带有奖项数量的分配。
  • 接收资格文本。
  • 支付机制命名谁交接什么。
  • 风险类别列表以及每个被引导给谁。
迭代直到计数为六。
之后值得记录的信号（自设）：
  • 实际交接的奖项与宣布的奖项
  • 从未领取的获胜者
  • 根据团队规模规则剩余的奖品单位
  • 当天出现的任何没有已发布答案的资格问题
选择两到三个并写下每个将触发的修订。

Invocation examples

调用示例

  • "We have three sponsor tracks and a general prize. How should we split the pool?"
  • "Should we give cash or hardware? The budget is fixed either way."
  • "One winner is a minor and another is in a different country. What do we need to sort out?"
  • "Our sponsor wants to fund a prize for their own API track. Can their engineers win it?"
  • "Write the prize section for our published rules."
Expected output: a prize structure with:
  1. The medium with its reasoning and its compliance consequences.
  2. The total pool and the budget line it fits inside, separating the organizer's baseline from sponsor-funded amounts.
  3. The split shape with an award count and a leftover-unit rule where the medium is counted in units.
  4. The eligibility-to-receive text ready to hand to the brief.
  5. The payout mechanic with who does what.
  6. The exposure categories that are live and who each was routed to.
Presented section by section for validation before publication.
  • “我们有三个赞助商赛道和一个通用奖项。我们应该如何分配奖金池？”
  • “我们应该给现金还是硬件？预算无论如何都是固定的。”
  • “一个获胜者是未成年人，另一个在不同国家。我们需要解决什么？”
  • “我们的赞助商想为他们的API赛道资助一个奖项。他们的工程师能赢得吗？”
  • “为我们的已发布规则编写奖项部分。”
预期输出：奖品结构包含：
  1. 媒介及其理由和合规后果。
  2. 总奖金池及其适配的预算行，将组织者基线从赞助商资助金额中分离。
  3. 分配形状，带有奖项数量和剩余单位规则（如果媒介按单位计数）。
  4. 准备交给简要的接收资格文本。
  5. 支付机制，谁做什么。
  6. 活跃的风险类别以及每个被引导给谁。
在发布前逐节呈现以进行验证。

References

参考

  • references/prize-medium-catalog.md
  • references/eligibility-to-receive-text.md
  • references/payout-exposure-categories.md
See also, same collection:
  • samber/dev-event-organizer-skills@event-vendor-sourcing
    - procures the physical goods a gear prize needs, on the lead times the medium menu warns about.
  • references/prize-medium-catalog.md
  • references/eligibility-to-receive-text.md
  • references/payout-exposure-categories.md
另见，同一集合：
  • samber/dev-event-organizer-skills@event-vendor-sourcing
    - 采购设备奖品所需的实物商品，在媒介菜单警告的提前期上。