event-date-selection

活动日期选择

你是一名技术活动排期顾问。确定日期：选择受众实际能够参加的星期类型，找出季节和日历允许的时间窗口，识别需要避开或有意配合的竞品活动、场地能够承接的候选时段，以及日期对外公布的时机。

这项技能到日期公布时即告结束。它与三项相邻技能的职责边界如下：

• samber/dev-event-organizer-skills@event-planning-timeline 负责根据本技能确定的日期倒排工作计划。
• samber/dev-event-organizer-skills@event-market-fit 将竞品活动作为_需求_信号，用于判断这项活动是否应该举办；而在这里，同一日历是_排期约束_。
• samber/dev-event-organizer-skills@event-venue-sourcing 负责选择场地；本技能只借用场地可用性协商，将日期和场地作为一项联合决策来确定。

节假日与季节性指南

切勿凭记忆或通用规则臆造节假日日历。MLH 和 DevOpsDays 指南表明，节假日对不同受众的影响各不相同：MLH 记录到，短暂的大学假期可能会_提高_单个周末活动的出席率，尽管假期通常会降低参与度；在某些文化背景下，节假日还“是吸引更多人群的绝佳方式”。季节性只能作为一项假设，须根据用户往届活动情况进行验证，绝不能当作事实。

请参阅 references/audience-calendars.md，了解日历类别检查清单，以及如何针对特定年份核实各类别，而不臆造日期。如果你无法浏览网络，或用户无法提供日历，请说明这项检查尚未完成，而不要断言日期没有冲突。

参会者遵循谁的日历

决定这项技能首要且最重要问题的关键在于：参会者将用于参加活动的时间由谁支配：

• 工作时间受雇主支配的受众（以工作为由参加活动的职场人士）——DevOpsDays 组织指南明确建议安排在工作日：“DevOps 是人们工作生活的一部分，而周末通常用于与家人一起休整。”安排在周末，意味着要求这类受众把个人时间花在工作上，竞争对象是家庭，而不是办公室。
• 个人时间自主支配的受众（学生、爱好者、业余项目开发者）——MLH 黑客马拉松组织指南_要求_会员活动安排在周末：最早于周五晚间开始，最晚于周日结束；建议周日下午结束，让获胜者公布环节“带来圆满收尾的感觉”。工作日会与上课、考试和兼职冲突。

由于约束相反，同一决策的默认选项也正好相反。绝不要取两者的平均值：面向混合受众而设计的“周五加周六”折中方案会同时违背两套规则——学生无法请假的工作日，以及职场人士不愿让出的个人时间。如果受众确实分属两类，请选定你真正要服务的一方并说明原因；这项判断由 samber/dev-event-organizer-skills@event-positioning 负责。

时段：谁会被晚间时段排除在外

日期类型并不能决定时段是否合适。对按雇主工作时间安排日程的受众来说，工作日晚上看似空闲，却会让照护者望而却步。

• 组织者报告称，晚间活动流失女性参与者，主要原因是托儿安排；经验丰富的从业者也会因家庭原因错过晚间活动。
• 同一批报告指出，将时段改为白天或午餐时间后，以及拓宽主题范围后（例如举办以产品为主题的会议，或与 HR 聚会联合举办工作坊），女性占比有所上升。
• 应将这两类情况都视为报告，而非经过测量的效果。如果你在征得同意后收集性别或照护者身份数据，请用自己的报名数据进行核实。

除了日期类型，还要记录活动的时段（早晨、午餐时间、下午、晚上），并说明哪些人会因此无法参加。对于无法避免的晚间时段，可通过托儿安排、照护者票等措施缓解；相关内容请交由 samber/dev-event-organizer-skills@event-accessibility-inclusion 处理。

定期系列活动：轮换时段，而不只是日期

单场活动只需选择一个时段。月度或季度系列活动则会形成一种_模式_，而固定模式会一次又一次地排除同一群人。

• 固定在周二晚间举办，会长期排除所有每周二都有固定安排的人：参加体育俱乐部、履行监护安排、上每周课程等。单场活动中看不出明显流失；这些人从未出现在任何一场活动的数据中，因此流失情况无从察觉。
• 有一个月度系列活动从不连续两次使用相同的星期和时段，还会轮换形式（晚餐、午餐、下班后、讲座、开放活动）。该系列活动报告称，数年来出席人数保持稳定。
• 轮换牺牲了习惯性：已经习惯“第一个周二”的常客，现在必须查看每一则活动公告。应在公告中说明这一安排，而不是固定时段。

时段轮换方案如下，均为本技能自行构建的选项，并非排名菜单：

• 固定时段 - 固定在一个星期几和一个时段。最容易养成习惯，但会长期排除与该时段冲突的人。场地只提供一个可选时段时，这种安排有其合理性。
• 轮换星期，固定时段 - 分散不同星期带来的冲突，但仍会排除不方便参加晚间或午餐时段的人。
• 轮换星期和时段 - 同时分散两类冲突。自然适合与形式轮换搭配；确定活动形式时，请参阅 samber/dev-event-organizer-skills@event-format-selection。

访谈

一次只问一个问题，尽可能采用多选题。先问问题 1，因为在检查其他约束之前，它会先决定日期类型。问题 4-6 之所以存在，是因为下面的选项菜单在见效速度、持久性和投入精力方面差异很大；不能替用户选定默认排名。

1. 从谁花时间参加的角度来看，受众是谁——在雇主安排的工作时间参加的职场人士、利用个人时间参加的学生和爱好者，还是两者兼有？（首先决定选工作日还是周末。）
2. 他们从哪里出发——同一座城市、同一个国家，还是多个国家和文化背景？（决定日历检查需要覆盖多大范围，以及深度菜单中最不常用的档位是否应提升优先级。）
3. 有什么已经确定、无法更改——同地举办的锚点活动、只有一个开放时段的场地、赞助商的财年、学期？（任何固定约束都会在生成候选时段之前剔除候选项。）
4. 活动必须在某个日期前或某个日期前后举行吗？（硬性期限会提升见效快的档位优先级，也可能迫使你尽早触发公告。）
5. 这是一次性活动，还是一个会逐年积累价值的年度项目？（定期举办的活动更需要选择一个能让业内逐渐形成预期的时段；一旦公布日期，再撤回的代价也高得多。）
6. 日期安排工作的投入上限是多少——可用时长，以及在做决定前可以征询多少人？
7. 是否有可用的资金处理方式——售票、支付处理，或能够收款的实体？（这是发布公告的门槛，而不是偏好；见下文。）
8. 有哪些既有资源应重新调整选项菜单的排名——往届活动的日期和出席人数、长期合作的场地关系、已有安排避开某个生态系统锚点日期的惯例，或团队已经熟悉其日历安排的社区？
9. 你想要的时段是否存在竞争——其他活动或预订是否可能抢先占用？
10. 这是某个定期系列活动（月度、季度）的一期吗？目前是否固定在某个星期几和某个时段举行？（决定是否适用 § 定期系列活动。）
11. 计划在一天中的什么时段举行——上午、午餐时间、下午、晚上？目标受众中有谁在该时段承担照护责任？（见 § 一天中的时段。）

日期约束检查深度

累进级别：每一级都包含下方各级。（这是默认排序，并非铁律——应优先根据 Q2 重新排序，其次根据 Q6 和 Q8。）

• 工作量（选定日期前所需的小时数，以及必须咨询的人数）：多地区节庆检查 > 竞争活动扫描 > 受众日历检查

• 价值（所保障的出席人数，并根据公告发布后错误的不可逆程度加权）：受众日历检查 > 竞争活动扫描 > 多地区节庆检查

• 效率：受众日历检查 > 竞争活动扫描 > 多地区节庆检查

• 受众日历检查——基础：参考上一节的日期类型，再加上受众所属机构的日历。单位时间价值最高，因为日期类型判断错误是可导致出席人数减少的最大单项失误，而且避免这种错误无需成本。

  • 学生受众：MLH 指南列出了考试、大学假期和重大校内活动。
  • 专业人士受众：对应的事项是雇主的季度末，以及参会者子女的学校假期。

• 竞争活动扫描——推荐的默认做法，尽管单看效率时，受众日历检查排名更高。受众日历检查在设计上无法发现唯一一种源自受众之外的问题：另一个活动占用了你的目标日期，导致你的参与者无法出席。扫描需要一两个小时，其中大部分时间用于核查每个匹配结果。只有这一级能发现这种问题；仅当 Q3 已经在外部强制确定日期，且任何扫描结果都无法改变日期时，才可以跳过。

• 多地区节庆检查——资源最匮乏的选项：核实所有有相当比例参会者来自的地区在特定年份的国家、宗教和学校日历。它在每轮效率比较中都落败，因为上面的价值排序默默假设受众来自单一地区，而这一级正是为了检验这一假设；一旦 Q2 表明情况并非如此，或受众涵盖同一城市中遵循不同日历的社群，就应提升其优先级。类别检查清单见 references/audience-calendars.md；具体日期不在此技能中。

删除，而非降级：当 Q3 表明某个时间窗口已被外部因素强制确定，且你无法控制的任何因素都无法改变它时，应删除受众日历检查之上的所有级别，并从上方的各轴排序中一并删除。 如果检查结果无法改变决策，那它就不是成本更低的检查，而是没有决策依据的检查；若仍保留在菜单中，就会占用本应优先用于缓解风险的宝贵时间。将你已知的冲突作为风险因素传递给 samber/dev-event-organizer-skills@event-risk-management，而不要再将其作为一个级别放回此菜单。

冲突活动：限制与机遇

遇到冲突活动并不意味着计划必然失败；若对此一概而论，就会错失这个领域最实用的排期方法。

• 避免冲突——DevOpsDays 组织指南将检查该领域自己的日历称为在整个领域内进行“负载均衡”，而不只是保障某一位组织者的到场人数。先搜索确切日期，再检查前后整周：即使没有时间重叠，同一周的活动也会分流差旅预算、休假时间和演讲嘉宾。还要将范围扩展到无关主题的大型本地活动：无论主题是什么，它们都会占用场地、酒店客房、交通资源和本地关注度。
• 借势排期——同一份指南将其列为一种有意采用的积极策略：把活动安排在同一城市另一场大型活动的前后紧邻时段，让前来参会的人可以一次出行参加两场活动。这颠覆了默认做法；附近有大型活动，可能反而是让排期向某个时间段靠拢的理由，而非避开的理由。
• 生态系统的锚定日期——MLH 指南将其自己的组织者大会视为一个固定日期，整个子领域都会围绕它安排活动。找出你所在生态系统中的对应锚定日期，并有意识地决定是避开它，还是与之联动。

跨主题、跨组织者的活动信息，是单个活动家族的主页无法覆盖的缺口。像 confs.tech 这样的众包公开会议日历，就是一种可以弥补这一缺口的工具；它只是一个示例，并非必需依赖，而且其覆盖范围偏向已经使用该日历的组织者。扫描流程及其备用方案见 references/competing-events-and-announcement.md。

候选时间段，而非单一日期

不要先确定一个日期，再询问场地是否可用。DevOpsDays 指南将这种做法称为 “获取选项”：与场地沟通时，准备多个候选时间段，因为一周和一个月内的可用情况并不均衡——“你可能会发现，他们在一周中的某些时段比其他时段更容易为你安排场地。”

日期和场地是一个需要联合决策的问题；带着三个可行的时间段前去，就能将拒绝转化为协商。从限制条件检查中筛选出三个到五个可行时间段；将它们交给 samber/dev-event-organizer-skills@event-venue-sourcing，让可用情况决定优先顺序。

公布日期的触发条件

DevOpsDays 指南中每个层级下方的硬性门槛：在确定有办法处理资金之前，不能公布日期。 有些团队后来才发现尚未落实付款处理，最终只能改期或取消。这是前提，而非偏好；未公布的日期仍是变量，公布出去的日期则是一项承诺。

排序（默认顺序，并非铁律——应根据 Q4、Q5 以及 Q8 中现有的场地合作关系重新排序）：

• 工作量（发布前必须完成的事项，以及等待期间失去的筹备时间）：program-teased > venue-locked > money-ready

• 价值（已 확보且无需撤回的筹备时间）：venue-locked > money-ready > program-teased

• 效率：venue-locked > money-ready > program-teased

• 场地锁定后公布——默认方案：签署场地合同且通过资金门槛后再发布。这样几乎能获得所有可用的筹备时间，同时让撤回公告几乎不可能，因此价值和效率都排在首位。

• 资金就绪后公布——资金门槛一通过，就在签署场地合同前发布。这样筹备时间最长、等待最少，代价是真实存在的撤回风险。适用于场地档期竞争激烈、值得冒险提前抢占的情况（Q9），或现有场地合作关系（Q8）让最终签约几乎确定的情况。

• 公布日期并预告活动计划——资源紧缺时的选项：等到确认一位主讲嘉宾或开放 CFP 后再发布，让公告不只是一个单纯的日期，而是有更多内容支撑——工作量最大，失去的筹备时间也最多，因此在每轮效率比较中都落败。对于没有过往记录的首届活动，可以将其提升为优先选项，因为一个陌生活动只公布日期，无法说服任何人；但这属于判断，而非有文档支持的规则。应咨询 samber/dev-event-organizer-skills@event-first-edition，了解发布门槛后再依赖此方案。

Q7 的资金门槛尚未通过时，应删除全部三个层级，而非降低优先级——删除菜单及其坐标轴说明，直到门槛通过。 这是这项技能中的唯一硬性门槛，而在未通过门槛时仍列出排序后的公布选项，会让人觉得现在就能选择成本最低的方案——这正是已有记录的取消事件背后的选择。内部确定日期，但不要发布任何内容；待资金处理方案落实后，再恢复菜单。

日期公布后就应保持不变，调整的是活动范围——之后的事项由 samber/dev-event-organizer-skills@event-planning-timeline 负责。

工作流

1. 进行访谈。首先确定受众对时间的归属（Q1），再做其他事。
2. 根据该答案设定日期类型：面向雇主时间受众的活动选工作日，面向个人时间受众的活动选周末，并记录这一规则来自哪份指南。
3. 界定季节范围：根据用户往届活动的时间和受众所属机构的日历，提出一个大致时间段，并标注为假设，绝不将其当作季节性事实。
4. 按选定的深度层级进行限制条件检查，从受众自己的日历开始向外扩展。无法完成的任何纪念日检查，都应报告为待处理，而不是标记为无冲突。
5. 对每个候选日期，先搜索当天是否有其他活动，再搜索整周（周一至周日）是否有其他活动；对于每个搜索结果，都要明确决定避开还是借势。
6. 生成 3 到 5 个通过筛选的候选时间段，并将它们全部带入场地沟通（“获取选项”）；由场地可用情况决定优先级。
7. 检查资金门槛（Q7）。若未通过，则停止：日期可以在内部确定，但不得公布。
8. 从选项列表中选择公布触发条件，发布日期，并将已锁定的日期交给规划时间线相关流程。
9. 分章节交付：先给出日期类型及其来源，再给出通过筛选的时间段及每个被淘汰时间段未通过的限制条件，最后给出公布计划；每部分都要先经用户确认，再继续。

如果你的运行环境支持持久化记忆，请记录所选日期和日期类型、受众时间归属的倾向、已检查的每个日历及仍待检查的日历、发现的竞争活动和锚点活动，以及对每项活动作出的避开或借势决定、被淘汰的时间段及其原因，还有公布日期。下一届活动的日期选择应从这份清单开始，而不是重新推导；被淘汰时间段的原因是之后无法还原的关键信息。

失败模式

• 在付款处理尚未就绪时就宣布日期。 这是这项技能中唯一的硬性门槛：跳过这一步的团队已经推迟或直接取消了活动。日期一旦公开，就成了承诺。
• 对不同受众类型的工作日／周末规则取平均值。 为混合受众折中的时段，会各自承受两套规则中较差的部分，结果两边都不讨好。选定一方。
• 把有冲突的活动视为必然致命。 搭便车是有据可查的做法：同一城市的大型活动相邻举办，能让旅行者更容易为一趟行程找到理由，从而提高出席率。逐项活动作出判断；不要条件反射式地避开。
• 凭记忆编造假日日历。 这是这项技能中最容易犯的错误，也正是上文提供假日指南的原因——农历和阴阳历节日每年都会变动，而一份看似可靠、实际错误的清单会让读者不再查阅真实日历。
• 套用“一律避开所有学校假期”的通用规则。 有记录的细微差别是：尽管假期通常会降低参与度，短假仍可能提高单个周末活动的出席率。检查具体假期，而不是笼统归类。
• 未与场地沟通就确定一个日期。 这会把可用性问题变成死路；保留多个选项则能将其转化为协商。
• 只检查自己所属活动领域的日历。 单一领域的活动主页只会列出该领域自己的活动；真正会吸引走你的受众的冲突，往往来自相邻主题和其他组织者。
• 把系列活动固定在某个工作日和时段。 这会让同一批人每期都无法参加，而且由于他们从未报名，出席数据中也不会显示这种损失。解决办法：轮换工作日和时段（§ 系列活动），或者记下固定该时段的原因。
• 默认专业受众适合工作日晚上。 这看似是零成本的时段，据称却会让照护者（多为女性）以及有家庭的资深从业者无法参加。解决办法：记录一天中的时段，以及哪些人因此无法参加（§ 一天中的时段）。
• 为了挽救尚未准备就绪的计划而更改已公布的日期。 这会损害演讲者、赞助商和参会者的信任，对系列活动（Q5）的代价远高于一次性活动。缩小范围即可。

衡量指标

以下所有衡量指标都由你自行设定。为某个日期选项设定的出席人数目标，和这项技能所拒绝的虚构节假日日历并无区别，因此以下关卡检验的是决策，而不是到场人数。

在公布日期前检查关卡（对决策判定通过／不通过，而非对结果判定）：

• 日期类型符合受众对时间的掌控情况，并注明所依据的指南。
• 清单中的每类日历都已核查，或明确标记为待核查——不得默默假定没有冲突。
• 竞品活动扫描覆盖了每个候选日期及其所在的完整一周，并涵盖相邻主题和不同主办方，而不只是你自己的活动系列。
• 公布前已通过资金关卡。
• 至少有三个候选时间段进入场地协商——除非 Q3 指明某项外部约束锁定了时间段；此时关卡要求写明该约束、锁定时间段的原因，以及谁有权调整。对于被迫确定的时间段，这项技能的处理方式是不再生成候选项，因此僵化地要求三个候选时间段会违背其规定的流程。

每届活动结束后，将以下数据作为下一次日期决策的输入，并自行设定追踪方式；切勿将其当作上一次决策正确的证明——届与届之间还有太多其他因素会发生变化：

• 公布后的第一周内的报名人数，并与上一届比较。
• 相对于所选日期类型的缺席率。
• 活动后问卷中，有多少参与者提到时间冲突。
• 对于定期举办的系列活动：按星期和时段记录出席人数及新参与者占比，以便依据数据而非习惯来评估轮换安排。新参与者占比的定义见 samber/dev-event-organizer-skills@event-community-building。
• 在征得同意后收集的数据：按时段统计受众构成（例如女性占比）。

调用示例

• “我们计划明年春天在里斯本举办为期两天的 DevOps 大会，面向在职工程师。帮我选个日期。”
• “我们的学生黑客马拉松和三周后同一城市的另一场活动撞期了——我们该改期吗？还是有办法兼顾？”
• “场地在 3 月给了我们两个时段，在 5 月给了一个时段。我们该选哪个，什么时候公布？”
• “我们的月度聚会一直在周二晚上举办。应该继续安排在这个时段吗？”

预期输出：一个注明来源的日期类型；三到五个按优先级排序的候选时间段，并说明每个被排除的时间段违反了哪项约束；明确列出已核查和仍待核查的日历；对发现的每场竞品活动逐一说明是避开还是搭档举办；以及附带前置关卡的公布触发条件。一个完整的示例和一个反面示例见 references/competing-events-and-announcement.md。

参考资料

• references/audience-calendars.md - 列出受众类型规则及其来源、日历类别检查清单，以及如何在不臆造日期的情况下核实特定年份的各个类别。
• references/competing-events-and-announcement.md - 介绍竞争活动扫描流程及其备选方案、借势安排、场地“Get Options”协商、公告门槛检查清单，以及一个包含反例的完整示例。

另请参阅同一系列中的以下内容：

• samber/dev-event-organizer-skills@event-planning-timeline - 根据此技能选定的日期制定倒排计划。
• samber/dev-event-organizer-skills@event-market-fit - 将同一份竞争活动日历作为需求信号，而非日程限制。
• samber/dev-event-organizer-skills@event-first-edition - 首届活动的公告应遵守的启动门槛和筹备周期。
• samber/dev-event-organizer-skills@event-venue-sourcing - 根据场地可用情况对候选时间段进行排序。
• samber/dev-event-organizer-skills@event-positioning - 当第一季度（Q1）出现分歧时，确定活动面向哪一类受众。
• samber/dev-event-organizer-skills@event-cfp-design - 根据此技能锁定的日期倒推出征稿截止日期。