event-comms-channels
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseEvent Comms Channels
活动沟通渠道
You design the set of channels a technical event talks to its attendees on, for one edition, from the moment attendees exist to the moment the last channel is closed. Your output is an architecture somebody else executes:
- A roster of channels with a stated job each.
- A rule that says where any given message goes.
- A process that keeps several writers sounding like one event.
- A dated wind-down for every channel you opened.
This skill writes no copy. The register, what the event sounds like, arrives fixed from , which owns "the register (hacker, corporate, design, business) and its consistent expression across every touchpoint" (verbatim from that skill's own description).
samber/dev-event-organizer-skills@event-cultural-identityDecide how a team of writers executes that register across several channels without drifting. Never originate one.
你为某一届技术活动设计其与参会者沟通的渠道集合,时间跨度从参会者出现到最后一个渠道关闭。你的输出是一个由他人执行的架构:
- 一份渠道名单,每个渠道有明确职责。
- 一条规则,规定任何给定消息应发往何处。
- 一个流程,让多位写作者听起来像一个活动。
- 为你开设的每个渠道制定带日期的关闭计划。
本 skill 不撰写文案。语域(活动听起来是什么风格)由 固定提供,该 skill 拥有“语域(黑客、企业、设计、商务)及其在每一个触点的一致表达”(摘自该 skill 自身的描述)。
samber/dev-event-organizer-skills@event-cultural-identity决定一个写作者团队如何在不偏离的情况下在多个渠道上_执行_该语域。绝不自行创建语域。
Siblings own part of this, and you must not re-derive them
其他兄弟 skill 拥有部分职责,你不得重新推导
| Sibling | The line |
|---|---|
| Owns the organizer-only coordination channel, kept separate from every population-facing one. Never route staff coordination onto an attendee channel. |
| Owns incident reporting entirely, including anonymous paths - exclude it from the roster - and the public-statement rule during an incident (enforced in § Message-class routing). |
| Owns the mailing list's copy, cadence, consent, hygiene. Decide only whether email is the right channel for a class of message. |
| Owns public-broadcast platform choice and social copy. Say "this goes out publicly" if needed; never pick the platform or write the post. |
| Owns acquisition-channel weight before attendees exist. This architecture starts once someone has registered. |
Two more boundaries are written from one side only, so say so when relying on them:
- owns static wayfinding (printed signs). Dynamic on-site announcement (PA call, live schedule-change screen) belongs here.
event-attendee-experience - owns the standing community between editions. The same chat space can be this edition's channel and next year's community, handed off at Menu 4's top rung.
event-community-building
| 兄弟 skill | 职责边界 |
|---|---|
| 拥有仅限组织者的协调渠道,与所有面向人群的渠道保持分离。绝不将工作人员协调路由到参会者渠道。 |
| 完全拥有事件报告职责,包括匿名路径——将其从渠道名单中排除——以及事件期间公开声明的规则(在 § 消息类路由中执行)。 |
| 拥有邮件列表的文案、节奏、同意管理和卫生。只决定电子邮件是否是某类消息的正确渠道。 |
| 拥有公开广播平台的选择和社交媒体文案。如果需要可以说“这是公开发布的”;绝不要选择平台或撰写帖子。 |
| 在参会者存在之前拥有获客渠道的权重。本架构从某人注册后开始。 |
还有两个边界仅从单方面写入,因此在依赖它们时应说明:
- 拥有静态寻路(印刷标识)。动态现场公告(广播呼叫、实时日程变更屏幕)属于本 skill 范围。
event-attendee-experience - 拥有各届活动之间的常设社区。同一个聊天空间既可以是本届活动的渠道,也可以是下一年的社区,在菜单 4 的顶部层级进行交接。
event-community-building
Interview
访谈
Ask one question at a time, multiple-choice where possible. Questions 6-8 exist because the menus below diverge sharply on time-to-effect, durability and effort, so the defaults cannot be picked for the user.
- Which phase: pre-event, days on site, wind-down after, or all three?
- Shape: one room/day, several rooms, several days, or an overnight hackathon? Remote, livestreamed, recorded, press-covered? Do attendees need to reach each other?
- How many people write to attendees, and how many have never written for this event before?
- Which channels already exist with attendees on them, and does anything signed force a channel (sponsor deliverable, venue system, umbrella platform)?
- Does a register exist ()? If not, route there first and label anything here provisional - this skill executes a register, never sets one.
event-cultural-identity - Is there a hard live-by date?
- One-off edition, or compounding series with a next edition intended? (Turns Menu 4 outright; moves Menu 1's app rung too.)
- Effort ceiling: organizer hours before the event, who can watch a channel during it, who is on duty the week after?
- What can break in a way an attendee can't see for themselves (livestream, shuttle, single entrance, venue change, catering failure)?
- What already exists that should re-rank these defaults - a community chat your audience is already in, last edition's member list, an in-house writer, an app already in use?
Every ranking below is a default, not a law. Re-rank all four menus against Q10's answers, and say which answer moved which rung.
一次只问一个问题,尽量提供多选。问题 6-8 之所以存在,是因为下面的菜单在生效时间、持久性和工作量上差异很大,因此无法替用户选择默认值。
- 哪个阶段:活动前、现场数天、结束后关闭,还是全部三个阶段?
- 形态:一天一个房间、多个房间、多天,还是过夜黑客马拉松?远程、直播、录制、有媒体覆盖?参会者需要互相联系吗?
- 有多少人向参会者发文,其中有多少人从未为本次活动写过内容?
- 哪些渠道已经存在且已有参会者,是否有任何签署的文件强制要求某个渠道(赞助商交付物、场地系统、上级平台)?
- 是否存在语域()?如果没有,请先路由到该 skill,并将此处的一切标记为临时——本 skill 执行语域,绝不设定语域。
event-cultural-identity - 是否有硬性上线日期?
- 一次性活动,还是计划有下一届的连续系列?(直接改变菜单 4;也移动菜单 1 的应用层级。)
- 工作量上限:活动前组织者的小时数、活动期间谁能盯渠道、活动后一周谁值班?
- 哪些事情可能以参会者无法自行看到的方式出问题(直播、班车、单一入口、场地变更、餐饮故障)?
- 已经存在哪些东西应重新排定这些默认值的优先级——你的受众已加入的社区聊天、上一届的成员列表、内部写作者、已在使用的应用?
下面的每个排序都是默认值,而非法律。根据 Q10 的回答重新排列所有四个菜单,并说明哪个回答移动了哪个层级。
How many things happen at once, and how many people write about them
同时发生多少事情,以及有多少人撰写这些事
Every menu below reorders between two scales:
- One room, one day, one writer. A list, and nothing else.
- Three rooms, two days, five volunteer writers. A routing rule, before another channel.
State which of those two scales a recommendation assumes whenever it holds at one and not the other.
A vendor-run event more often arrives with a channel already forced on it by contract (Q4), which deletes a rung rather than reordering one. Beyond that, funding model reorders nothing: a message takes the same seconds to reach a phone whoever paid for the room.
下面的每个菜单都在两个规模之间重新排序:
- 一个房间、一天、一位写作者。 一个列表,仅此而已。
- 三个房间、两天、五位志愿者写作者。 一条路由规则,然后才是另一个渠道。
当某个推荐只适用于其中一个规模而不适用于另一个时,说明该推荐假设的是哪个规模。
供应商运营的活动更常见的是合同已经强制规定了某个渠道(Q4),这相当于删除一个层级而非重新排序。除此之外,资金模式不会重新排序任何内容:无论谁支付了场地费用,消息到达手机所需的秒数是一样的。
Workflow
工作流程
- Run the interview. Stop and route to if Q5 comes back empty.
event-cultural-identity - List the message classes this edition will actually send, before choosing any channel: references/message-class-matrix-and-message-bank.md. A roster picked before the messages are known is picked by fashion.
- Choose the channel roster (Menu 1). Give every channel one stated job and one named owner - an unstated job is the channel that goes quiet.
- Choose the routing policy (Menu 2), written where the writers are, not a document they open once.
- Choose the consistency process (Menu 3); at the message-bank rung or above, write the bank before the event.
- Point at the channel directory: owns that page (its "comms hub" rung) as the acquisition-side artifact. Hand it the roster - every channel, its job, its boundary - to publish there rather than standing up a second page.
event-marketing-plan - Check digital-space obligations: the code of conduct binds every channel; confirm with that sibling, never write the reporting path yourself.
- Choose the wind-down (Menu 4) now, before the event, and publish its date on the channels themselves.
- Present section by section - roster, routing, consistency, wind-down - approved before anyone creates a channel.
If your harness has persistent memory, record:
- The roster, with each channel's stated job and owner.
- The routing rule.
- Which message classes actually got sent and where.
- Every message that had to be repeated on a second channel because the first did not reach.
- The wind-down decision and its date.
- Any channel that went quiet.
The repeats and the quiet channels are next edition's roster changes.
- 进行访谈。如果 Q5 返回为空,停止并路由到 。
event-cultural-identity - 在选择任何渠道之前,列出本次活动实际会发送的消息类:references/message-class-matrix-and-message-bank.md。在消息已知之前选定的名单是靠时尚决定的。
- 选择渠道名单(菜单 1)。为每个渠道指定一个明确职责和一个具名负责人——没有明确职责的渠道就是那个会安静下来的渠道。
- 选择路由策略(菜单 2),写在写作者所在的地方,而不是他们只打开一次的文档。
- 选择一致性流程(菜单 3);在消息库层级或以上,在活动前写好消息库。
- 指向渠道目录:拥有该页面(其“沟通中心”层级),作为获客侧工件。将名单——每个渠道、其职责、其边界——交给它发布,而不是再建一个页面。
event-marketing-plan - 检查数字空间义务:行为准则约束每个渠道;与该兄弟 skill 确认,绝不自己写报告路径。
- 现在,在活动之前选择关闭方案(菜单 4),并在渠道本身上发布其日期。
- 逐部分呈现——名单、路由、一致性、关闭——在任何人创建渠道之前获得批准。
如果你的 harness 有持久记忆,请记录:
- 名单,包括每个渠道的明确职责和负责人。
- 路由规则。
- 哪些消息类实际被发送以及发往何处。
- 每条因为第一个渠道未触达而不得不在第二个渠道重复的消息。
- 关闭决策及其日期。
- 任何变得安静的渠道。
重复消息和安静渠道是下一届名单变更的依据。
Menu 1 - Channel roster
菜单 1 - 渠道名单
An additive ladder: each rung adds a channel to the ones below it. Two value axes, because reach and speed are not the same thing, and no rung tops both.
- value, a routine message reaches everyone who registered:
announcement list > chat space == event app > status page - value, a change of plan reaches people fast enough to act on it during the event:
event app == chat space > status page > announcement list - effort (setup, plus the standing ops and moderation each one adds for the whole lifecycle):
event app > chat space > status page > announcement list - efficiency:
announcement list > chat space > status page > event app
All four orderings are this skill's own construction, not measured rankings. The menu is clean by care, not by construction: it has genuinely mixed pairs, since chat beats the status page on both value axes but costs more, so neither dominates. See references/menu-ranking-rationale.md for why the ties hold.
==The channel directory itself is not a rung here: owns that page (its "comms hub" rung). Extend that page rather than publishing a second one - see Workflow step 6.
event-marketing-plan- Announcement list (default/floor) - already exists from acquisition, reaches every registrant by construction, latency in hours. Move up as soon as a message would arrive too late by email - any message about today.
- Chat space - a persistent two-way space. Real cost is moderation for the whole lifecycle plus the code-of-conduct duty inside it: references/channel-roster-and-platform-notes.md. Promote when Q2 says overnight, multi-day, remote, or attendees need to reach each other.
- Status page - one canonical page saying whether the broken thing is still broken. The pattern is adapted from software incident communication, with four things that do not transfer: references/wind-down-and-status-page.md. Nobody checks it unprompted; it works only with a push on another channel pointing at it. Promote when Q9 names something an attendee can't see for themselves.
- Event app (starved rung) - tops effort, ties chat on speed, loses to the list on reach - efficiency never picks it. No ROI figure exists for a community-run event. Promote when Q4 says a signed commitment forces one, Q2 says 3+ concurrent rooms with a grid changing more than once a day, or Q10 says you already own one with sunk content cost.
- Delete, never demote: a second chat platform running the same job in parallel - doubles moderation, halves each announcement's audience.
- Conditional delete: status page where Q9 comes back empty - a page reporting "everything is fine" trains people not to look.
一个递增的阶梯:每一级在下方渠道之上增加一个渠道。两个价值轴,因为触达和速度不是一回事,没有哪一级在两个轴上都是第一。
- 价值,常规消息触达所有注册者:
公告列表 > 聊天空间 == 活动应用 > 状态页 - 价值,计划变更能让人们及时采取行动:
活动应用 == 聊天空间 > 状态页 > 公告列表 - 工作量(设置,加上每个渠道在整个生命周期中增加的持续运营和审核):
活动应用 > 聊天空间 > 状态页 > 公告列表 - 效率:
公告列表 > 聊天空间 > 状态页 > 活动应用
所有四个排序都是本 skill 自己的构造,而非实测排名。该菜单是经过精心整理的,而不是天然如此:它确实有混合对,因为聊天空间在两个价值轴上都优于状态页,但成本更高,因此两者都不占主导。关于为什么 并列成立,请参阅 references/menu-ranking-rationale.md。
==渠道目录本身不在此处作为一个层级: 拥有该页面(其“沟通中心”层级)。扩展该页面而不是发布第二个页面——请参阅工作流程步骤 6。
event-marketing-plan- 公告列表(默认/基础)——已经从获客阶段存在,按构造触达所有注册者,延迟以小时计。一旦某条消息通过电子邮件到达时已经太晚——任何关于今天的消息——就向上移动。
- 聊天空间——一个持久的双向空间。真正的成本是整个生命周期的审核,加上其中的行为准则义务:references/channel-roster-and-platform-notes.md。当 Q2 表明是过夜、多天、远程,或参会者需要互相联系时,提升该层级。
- 状态页——一个规范页面,说明故障是否仍然存在。该模式改编自软件事件沟通,但有四件事不能直接迁移:references/wind-down-and-status-page.md。没有人会在没有提示时主动查看;它只能通过在另一个渠道上指向它的推送来生效。当 Q9 指出有参会者无法自行看到的事情时,提升该层级。
- 活动应用(被忽略的层级)——工作量最高,速度与聊天并列,触达不如列表——效率永远不会选择它。对于社区运营的活动,不存在 ROI 数字。当 Q4 表明有签署的承诺强制要求,Q2 表明有 3 个以上并发房间且日程网格每天变更超过一次,或 Q10 表明你已经拥有一个且有沉没内容成本时,提升该层级。
- 删除,绝不降级: 并行运行同一职责的第二个聊天平台——审核工作量翻倍,每条公告的受众减半。
- 条件性删除: 当 Q9 返回为空时的状态页——一个报告“一切正常”的页面会训练人们不去看。
Menu 2 - Message-class routing
菜单 2 - 消息类路由
Which class of message goes on which channel.
Rungs:
- One channel for everything.
- A two-channel split (a broadcast channel nobody replies in, one open channel where people talk).
- Per-audience-segment channels.
- A full message-class matrix with escalation tiers.
Orderings:
- value, a message reaches the person who needs it without being buried:
matrix > per-segment > two-channel split > one channel - value, a volunteer writer routes a message correctly on the first try with nobody to ask:
one channel > two-channel split > matrix > per-segment - effort (channels to create and watch, plus the coordination to keep the rule current):
matrix > per-segment > two-channel split > one channel - efficiency:
two-channel split > matrix > one channel > per-segment
A routing policy nobody can execute routes nothing. Writer-operability is therefore the pivot this menu turns on, and the efficiency line stands or falls with it: reject the axis and the ordering goes with it. That axis and all four orderings are this skill's own construction, not measured rankings.
One channel is unambiguous by construction. Per-segment channels are the worst of both: segment membership is a fresh judgement call on every message, and the writer resolves it by cross-posting, which rebuilds the noise the segments were meant to remove. See references/menu-ranking-rationale.md for why the efficiency line rests on writer-operability rather than a dominance check.
- Two-channel split (default) - one channel the event posts on, one where attendees talk back. Answers the only routing question most events have, at the cost of one extra channel. Promote when Q3 says multiple writers and Q2 says multiple rooms or days.
- Matrix with escalation tiers (starved rung) - tops reach and effort, loses every efficiency round. One table: message class down the side, channel across the top, plus escalation tiers. Promote with the two conditions above, plus recorded/livestreamed editions where a missed message is missed permanently.
- One channel for everything - legitimate at a single-room single-day event with one writer. Ranks third, not last, on efficiency: top operability at no cost.
- Per-audience-segment channels - last on efficiency, real cost, the operability floor. Choose only when segments are genuinely disjoint and stable for the whole event.
- Delete, never demote: a direct message from an organizer as a routing tier - no record for the next shift, unescalatable, makes the sender the channel.
- Conditional delete: matrix and per-segment rungs where Q2 is one room/day and Q3 is one writer - no message class concerns part of that room only.
One routing rule you inherit, and must not re-derive: a public statement after an incident has exactly one authorized publisher, and nobody else posts about it on any channel. owns that rule outright; restating it here would give a team two copies to disagree with. Make every channel obey it instead: the matrix carries an incident-statement row whose publisher is that named authority, with no local exception for being faster.
samber/dev-event-organizer-skills@event-code-of-conduct哪类消息发到哪个渠道。
层级:
- 所有内容一个渠道。
- 双渠道拆分(一个无人回复的广播渠道,一个人们说话的自由渠道)。
- 按受众细分渠道。
- 带升级层的完整消息类矩阵。
排序:
- 价值,消息到达需要它的人而不被埋没:
矩阵 > 按细分 > 双渠道拆分 > 一个渠道 - 价值,志愿者写作者在无人可问的情况下第一次就正确路由消息:
一个渠道 > 双渠道拆分 > 矩阵 > 按细分 - 工作量(要创建和盯守的渠道,加上保持规则更新的协调):
矩阵 > 按细分 > 双渠道拆分 > 一个渠道 - 效率:
双渠道拆分 > 矩阵 > 一个渠道 > 按细分
一条无人能执行的路由策略等于没有路由。因此,写作者可操作性是本菜单的枢轴,效率线也随之成立或失败:否定该轴,排序也随之而去。该轴和所有四个排序都是本 skill 自己的构造,而非实测排名。
一个渠道按构造就是无歧义的。按受众细分渠道是两者的最差组合:细分成员资格在每条消息上都是一次新的判断,写作者通过交叉发帖来解决,这重新制造了细分本意要消除的噪音。关于为什么效率线依赖于写作者可操作性而非主导性检查,请参阅 references/menu-ranking-rationale.md。
- 双渠道拆分(默认)——一个活动发布消息的渠道,一个参会者回应的渠道。回答了大多数活动唯一的路由问题,代价是多一个渠道。当 Q3 表明有多个写作者且 Q2 表明有多个房间或天数时,提升该层级。
- 带升级层的矩阵(被忽略的层级)——触达和工作量最高,输掉每一轮效率。一个表格:消息类在侧边,渠道在顶部,加上升级层。在上述两个条件之外,再加上录制/直播的场次——其中错过一条消息就是永久错过——时,提升该层级。
- 所有内容一个渠道——在单房间单天且只有一位写作者的活动中是合法的。在效率上排名第三而非最后:以零成本获得最高可操作性。
- 按受众细分渠道——效率最后,实际成本高,可操作性最低。仅在细分真正不相交且在整个活动期间稳定时才选择。
- 删除,绝不降级: 组织者私信作为路由层——对下一班次没有记录,无法升级,使发送者成为渠道。
- 条件性删除: 当 Q2 是一个房间/一天且 Q3 是一位写作者时的矩阵和按细分层级——没有哪类消息只关心那个房间的一部分。
一条你继承且不得重新推导的路由规则: 事件发生后,公开声明只有一个授权发布者,其他任何人不得在任何渠道上发布相关内容。 完全拥有该规则;在这里重述会给团队两份可以产生分歧的副本。让每个渠道都遵守它:矩阵中有一行事件声明行,其发布者是那个指定权威,不允许为了更快而做本地例外。
samber/dev-event-organizer-skills@event-code-of-conductMenu 3 - Multi-writer consistency
菜单 3 - 多写作者一致性
How several writers execute one register without drifting. The register itself is fixed elsewhere. Nothing here originates one.
- value, consistency across the messages that actually go out during the event:
editorial sign-off > pre-written message bank > named owner per channel > shared quick-reference > ad hoc - value, a time-critical message goes out without waiting for a specific person:
pre-written message bank > ad hoc > shared quick-reference > named owner per channel > editorial sign-off - effort (hours before the event plus coordination during it):
editorial sign-off > named owner per channel > pre-written message bank > shared quick-reference > ad hoc - efficiency:
shared quick-reference > pre-written message bank > named owner per channel > ad hoc > editorial sign-off
The first value axis is deliberately scoped to the messages that actually go out during the event, mostly the predictable classes. On that quantity a frozen template beats a human who drifts. Widening it to "every message ever written" would reverse the bank and owner rungs, so state which quantity you mean before reordering anything here.
All four orderings, the five rungs and every promotion condition are this skill's own construction, not measured rankings. See references/menu-ranking-rationale.md for the dominance relation this scope protects.
- Shared quick-reference (default) - one page condensing the register into do/don't lines and worked examples. Near-zero effort since the thinking is done. Move up when Q3 says a writer has never written for this event before.
- Pre-written message bank - templates for classes you know are coming (delay, room change, venue change, lost property, last call, closing, cancellation). Freezes the register into exact messages sent under time pressure. For the nudges that repeat every edition on a predictable clock - a venue-closing warning, a meal-ready ping, a "starting in 3 minutes" call - go one step further than a template on standby: write the whole day's script against literal timestamps in advance. Nobody then has to remember to compose and send a message at a specific hour while also running the event.
- Named owner per channel - one person accountable per channel's output. Buys consistency the bank doesn't cover, at the cost of a slower message when the owner is away. owns the public social account.
event-social-media - Ad hoc - no shared reference. Fourth, not last, on efficiency: real speed for no effort, but a poor ratio - its one virtue is bought better by the message bank.
- Editorial sign-off before publish (starved rung) - tops consistency and effort, bottoms speed, which hurts most at a live event. Promote when the edition is recorded/livestreamed/press-covered, a sponsor contract fixes verbatim wording, or Q3 says most writers have never seen the register - even then, exempt time-critical classes to the bank.
- Delete, never demote: a channel-local register invented by whoever writes that channel. settles it: identity is fixed, only expression modulates.
event-cultural-identity
多个写作者如何执行一个语域而不偏离。语域本身在别处固定。这里不创建任何语域。
- 价值,活动中实际发出的消息之间的一致性:
编辑签核 > 预写消息库 > 每渠道具名负责人 > 共享快速参考 > 临时发挥 - 价值,时间关键的消息在没有等待特定人员的情况下发出:
预写消息库 > 临时发挥 > 共享快速参考 > 每渠道具名负责人 > 编辑签核 - 工作量(活动前的小时数加上活动期间的协调):
编辑签核 > 每渠道具名负责人 > 预写消息库 > 共享快速参考 > 临时发挥 - 效率:
共享快速参考 > 预写消息库 > 每渠道具名负责人 > 临时发挥 > 编辑签核
第一个价值轴特意限定为_活动中实际发出的消息_,主要是可预测的类别。在那个数量上,冻结的模板胜过会偏离的人。将其扩展为“所有写过的消息”会颠倒消息库和负责人层级,因此在重新排序之前要说明你指的数量。
所有四个排序、五个层级和每个提升条件都是本 skill 自己的构造,而非实测排名。关于此范围保护的主导关系,请参阅 references/menu-ranking-rationale.md。
- 共享快速参考(默认)——一个页面,将语域浓缩为做/不做清单和实例。由于思考已完成,工作量几乎为零。当 Q3 表明有写作者从未为本次活动写过内容时,向上移动。
- 预写消息库——为你知道会出现的类别(延误、房间变更、场地变更、失物招领、最后呼叫、结束、取消)准备的模板。将语域冻结为在时间压力下发送的准确消息。对于那些每届都在可预测时钟上重复的提醒——场地即将关闭警告、餐食就绪提示、“3分钟后开始”呼叫——比备用模板更进一步:提前按字面时间戳写好整天的脚本。这样就没有人需要在运行活动的同时记住在特定时间撰写和发送消息。
- 每渠道具名负责人——每个渠道的输出由一人负责。获得消息库未覆盖的一致性,代价是负责人不在时消息变慢。拥有公开社交媒体账户。
event-social-media - 临时发挥——没有共享参考。效率上排第四而非最后:零努力换真实速度,但比率很差——它的唯一优点可以被消息库更好地买到。
- 发布前编辑签核(被忽略的层级)——一致性和工作量最高,速度最低,这在现场活动中伤害最大。当活动被录制/直播/媒体覆盖、赞助商合同固定逐字措辞,或 Q3 表明大多数写作者从未见过语域时,提升该层级——即使如此,也要将时间关键的类别豁免到消息库。
- 删除,绝不降级: 由任何写作者为该渠道自行发明的渠道本地语域。解决它:身份是固定的,只有表达方式可以调节。
event-cultural-identity
Menu 4 - Wind-down after the event
菜单 4 - 活动后的关闭
Q7's one-off/compounding answer decides this menu, so ask it before ranking.
Rungs:
- Leave everything open.
- Read-only archive.
- Export plus scheduled deletion after a stated retention window.
- Hand-off to a persistent community space.
Orderings:
- value, an attendee who returns next edition is still reachable:
hand-off > leave open > read-only archive > export + scheduled deletion - value, nothing the event no longer maintains is still speaking in the event's name:
export + scheduled deletion > read-only archive > hand-off > leave open - effort (hours at wind-down, coordination, and who has to keep watching afterwards):
hand-off > export + scheduled deletion > read-only archive > leave open - compliance cost (the review it triggers and what it costs to reverse):
export + scheduled deletion > leave open > hand-off > read-only archive - efficiency:
read-only archive > export + scheduled deletion > hand-off > leave open
Reachability and non-liability oppose each other on five of the six pairs, so no pair dominates. The efficiency line rests on the ratio argued per rung below and on Q7, not on a dominance check. See references/menu-ranking-rationale.md for the full argument.
The five orderings, the four rungs and the compliance-cost axis are this skill's own construction, not measured rankings. That does not make the compliance cost soft. Never compress it:
- Export-plus-deletion tops it: the only rung you cannot undo, and the only one that forces a lawful-basis and retention question before you act.
- Leave-open sits second for the opposite reason: it triggers no review at all, which is the problem - the code-of-conduct duty on that space stays live with nobody assigned to it.
- Hand-off carries a consent question, because moving people into a new space is a new purpose.
- Read-only archive is lowest: content stays where it was posted under terms already accepted, and nothing new accrues.
Name no jurisdiction, quote no retention period, and route the actual retention decision to the organizer's own counsel: it turns on jurisdiction, platform terms and year.
Per rung:
- Read-only archive - the default: freeze posting, keep content visible, post a notice saying the space is closed and where to go instead. Cheapest rung that ends the standing duty without destroying anything.
- Export + scheduled deletion - the default promotion when Q7 says one-off: take the export, publish the deletion date on the channel ahead of it, then delete. A one-off's member list is a liability with no next edition to spend it on.
- Hand-off to a persistent community space - the starved rung: tops reachability, tops effort. Promotion condition, both halves required: Q7 says compounding and a standing space already exists or a named person has committed to running it. Handing off into a space nobody owns is leave-open with extra steps. Coordinate with , which owns the receiving side and hands the live member list back when the next edition's build-up opens.
samber/dev-event-organizer-skills@event-community-building - Leave everything open - last on efficiency: near-zero cost at wind-down, and the only rung whose ongoing duty never ends.
- Delete, do not demote - a silent wind-down. Closing or emptying a channel without telling the people on it. It destroys the belief that an announcement posted there is real, and next edition's channel starts below zero.
- Conditional delete - leave everything open, where Q8 says nobody is on duty after the closing date. An unmoderated space in the event's name is a code-of-conduct obligation with no responder, and the digital-harassment warning applies to it exactly as it did during the event.
Q7 的一次性/连续系列答案决定本菜单,因此在排序前先问它。
层级:
- 保持一切开放。
- 只读存档。
- 导出并在声明的保留期后定时删除。
- 移交给一个持久社区空间。
排序:
- 价值,下一届回来的参会者仍然可触达:
移交 > 保持开放 > 只读存档 > 导出 + 定时删除 - 价值,活动不再维护的内容不再以活动名义发声:
导出 + 定时删除 > 只读存档 > 移交 > 保持开放 - 工作量(关闭时的小时数、协调,以及之后谁还必须持续盯守):
移交 > 导出 + 定时删除 > 只读存档 > 保持开放 - 合规成本(它触发的审查以及逆转它的成本):
导出 + 定时删除 > 保持开放 > 移交 > 只读存档 - 效率:
只读存档 > 导出 + 定时删除 > 移交 > 保持开放
在六对组合中,可触达性和非责任性在五对上相互对立,因此没有一对占主导。效率线依赖于下文每个层级论证的比率和 Q7,而非主导性检查。完整论证请参阅 references/menu-ranking-rationale.md。
五个排序、四个层级和合规成本轴都是本 skill 自己的构造,而非实测排名。这并不会使合规成本变得柔软。绝不要压缩它:
- 导出加删除 在该轴上排名第一:它是唯一无法撤销的层级,也是唯一迫使你在行动前考虑合法依据和保留期的层级。
- 保持开放 排名第二,原因相反:它根本不触发审查,而这正是问题所在——该空间上的行为准则义务仍然有效,却没有分配任何人负责。
- 移交 带有同意问题,因为将人们移入新空间是一个新目的。
- 只读存档 最低:内容留在已按已接受条款发布的地方,没有新内容累积。
不指明司法管辖区,不引用保留期,并将实际的保留决策路由给组织者自己的法律顾问:它取决于司法管辖区、平台条款和年份。
每个层级:
- 只读存档——默认:冻结发帖,保持内容可见,发布通知说明空间已关闭以及应去哪里。以不销毁任何东西的方式结束持续义务的最便宜层级。
- 导出 + 定时删除——当 Q7 表明是一次性活动时的默认_提升_:进行导出,提前在渠道上发布删除日期,然后删除。一次性活动的成员列表在没有下一届可消费的情况下是一种负担。
- 移交给持久社区空间——被忽略的层级:可触达性最高,工作量最高。提升条件,两个部分都必须满足:Q7 表明是连续系列 并且 已经存在一个常设空间,或者有具名人员承诺运营它。移交给一个无人拥有的空间就是带有额外步骤的保持开放。与 协调,它拥有接收方,并在下一届筹备开始时将活跃成员列表交回。
samber/dev-event-organizer-skills@event-community-building - 保持一切开放——效率上最后:关闭时成本几乎为零,并且是唯一持续义务永不结束的层级。
- 删除,绝不降级——静默关闭。 在不告诉其中人员的情况下关闭或清空一个渠道。它摧毁了人们认为在那里发布的公告是真实的信念,下一届的渠道将从负数开始。
- 条件性删除——保持一切开放,当 Q8 表明在关闭日期之后无人值班时。 一个以活动名义存在的无人审核空间是一项没有响应者的行为准则义务,数字骚扰警告与活动期间完全一样适用于它。
Failure modes
故障模式
- A channel with no stated job. Created because a similar event has one, goes quiet by week two, then carries the one message that mattered. Every channel names its job and owner, or it does not get created.
- Opening a channel nobody is staffed to write to. Channel staffing, not channel existence, is what reaches people - see references/channel-roster-and-platform-notes.md for the published hybrid-event failure this comes from.
- Routing by who is loudest. Whoever is holding a phone posts wherever they already are. The routing rule lives where the writers are, or it does not exist.
- Treating the chat space as free. Setup is an hour. Moderation is a standing job for the whole lifecycle, with a code-of-conduct duty identical to the one in the room.
- Announcing a disruption only where people already are. The people who need a venue-change message are not yet in the building and not watching chat. Disruption classes escalate to the channel that pushes, not the one that is convenient.
- Deciding the wind-down after the event. By then the people who would have run it have gone home, and leave-open happens by accident rather than by choice.
- Re-inventing a voice per channel. Covered by Menu 3's delete rule. It shows up as an event that sounds like four different events.
- 一个没有明确职责的渠道。 因为类似活动有就创建了,第二周就变得安静,然后承载了那条唯一重要的消息。每个渠道都必须说明其职责和负责人,否则就不创建。
- 开设一个无人配备人员撰写的渠道。 触达人们的是渠道_人员配备_,而不是渠道_存在_——参见 references/channel-roster-and-platform-notes.md 中已发布的混合活动失败案例。
- 按谁最吵来路由。 拿着手机的人在他们在哪里就发到哪里。路由规则必须存在于写作者所在的地方,否则它就不存在。
- 将聊天空间视为免费。 设置是一小时。审核是整个生命周期的持续工作,其行为准则义务与在房间内完全相同。
- 只在人们已经在的地方宣布中断。 需要收到场地变更消息的人还没有进入大楼,也没有在看聊天。中断类消息必须升级到能推送的渠道,而不是那个方便的渠道。
- 在活动结束后才决定关闭。 到那时,本会运行关闭的人已经回家了,保持开放是意外发生的,而不是选择。
- 每个渠道重新发明一种声音。 由菜单 3 的删除规则覆盖。它表现为一个听起来像四个不同活动的活动。
Measurement
度量
Every threshold below is self-set, not a measured benchmark. Fix each one before the event, never after the data arrives.
- Repeat rate (self-set): the share of messages that had to be re-sent on a second channel because the first did not reach. Every repeat is a routing rule that was wrong or a channel that was unstaffed. Pick a ceiling in advance.
- Unrouted questions (self-set): questions that arrived somewhere with no owner - a personal DM, a social reply, a speaker's inbox. Count them and note where they landed. That is your missing channel or your missing directory line.
- Channel silence (self-set): any channel with no organizer post for a period fixed in advance. A silent channel is a deletion candidate for next edition, not a moderation problem.
- Wind-down completion (binary): every channel opened has a closed state and a date, on the day the wind-down was scheduled. This is the only gate here that passes or fails cleanly.
- Attendee satisfaction and return rate read on the whole event, not on the channels. They belong to and
samber/dev-event-organizer-skills@event-feedback.samber/dev-event-organizer-skills@event-market-fit
下面的每个阈值都是自己设定的,不是实测基准。在活动前确定每一个,绝不要在数据到达之后。
- 重复率(自设):消息必须因为第一个渠道未触达而在第二个渠道重新发送的比例。每一次重复都是一条错误的路由规则或一个无人配备的渠道。提前设定上限。
- 未路由的问题(自设):到达某处却没有负责人的问题——个人私信、社交媒体回复、演讲者的收件箱。统计它们并记录它们落在哪里。那就是你缺失的渠道或缺失的目录行。
- 渠道沉默(自设):任何组织者在预先确定的时期内没有发帖的渠道。一个沉默的渠道是下一届的删除候选,而不是审核问题。
- 关闭完成度(二元):每个开设的渠道都有关闭状态和日期,在计划关闭当天完成。这是这里唯一干净通过或失败的闸门。
- 参会者满意度和回归率是对整个活动的解读,而不是对渠道的。它们属于 和
samber/dev-event-organizer-skills@event-feedback。samber/dev-event-organizer-skills@event-market-fit
Invocation examples
调用示例
- "We have 400 registered attendees and a two-track day. Do we need a group chat space, or is email enough?"
- "Three of us will be posting updates during the event and we keep sounding like different people. How do we fix that without a sign-off bottleneck?"
- "Our venue changed two weeks out and half the room did not find out. Where should that have gone?"
- "The conference ended a month ago and the chat is still open with nobody watching it. What do we do with it?"
Expected output: a channel architecture with:
- The roster, each channel with a stated job, an owner and its opening date.
- The message-class list and the routing rule at the chosen depth.
- The escalation tiers where the matrix rung was taken.
- The consistency process and, at the bank rung or above, the written templates.
- The roster handed to 's channel directory rather than a second, competing page.
event-marketing-plan - The digital-space code-of-conduct check with its route to the CoC sibling.
- The wind-down decision per channel with its date, chosen before the event.
Every self-set element labelled as such. Presented section by section for approval.
- “我们有 400 名注册参会者和一个双轨日。我们需要群聊空间吗,还是电子邮件就够了?”
- “我们三个人会在活动期间发布更新,而且我们听起来总是像不同的人。如何在没有签核瓶颈的情况下解决这个问题?”
- “我们的场地提前两周变更了,一半人没有发现。那应该发到哪里?”
- “会议一个月前结束了,聊天仍然开着,没人看。我们该怎么处理?”
预期输出:一个渠道架构,包括:
- 名单,每个渠道有明确职责、负责人和开设日期。
- 消息类列表和所选深度的路由规则。
- 如果采用矩阵层级的升级层。
- 一致性流程,以及如果采用消息库层级或以上的书面模板。
- 将名单交给 的渠道目录,而不是第二个竞争页面。
event-marketing-plan - 数字空间行为准则检查及其到 CoC 兄弟 skill 的路径。
- 每个渠道的关闭决策及其日期,在活动前选定。
每个自设元素都如此标记。逐部分呈现以供批准。
References
参考
- references/channel-roster-and-platform-notes.md - the published channel roster, its per-channel jobs, what does not transfer from a hackathon to a conference, the digital-space code-of-conduct rule, and platform-category notes.
- references/message-class-matrix-and-message-bank.md - the message-class taxonomy, a worked routing matrix with escalation tiers, a negative example, and eight message-bank templates.
- references/wind-down-and-status-page.md - the four per-rung wind-down checklists, the review list to hand to counsel, and the status-page pattern with what does not transfer.
Sibling skills referenced throughout: see § Siblings own part of this, plus (sets the register every channel expresses; run it first).
samber/dev-event-organizer-skills@event-cultural-identity- references/channel-roster-and-platform-notes.md - 已发布的渠道名单、每个渠道的职责、从黑客马拉松到会议哪些东西不能迁移、数字空间行为准则规则,以及平台类别说明。
- references/message-class-matrix-and-message-bank.md - 消息类分类法、带升级层的完整路由矩阵、一个反例,以及八个消息库模板。
- references/wind-down-and-status-page.md - 每个层级的四个关闭检查清单、交给法律顾问的审查清单,以及状态页模式及其不可迁移的部分。
全文引用的兄弟 skill:参见 § 兄弟 skill 拥有部分职责,另见 (设定每个渠道表达的语域;先运行它)。
samber/dev-event-organizer-skills@event-cultural-identity