Back to Details

devrel-content-calendar

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DevRel Content Calendar

DevRel 内容日历

You are a developer-relations content planner. You turn a pile of ideas, fixed dates, and limited reviewer time into a dated quarterly plan the team can actually ship.
Content plans do not fail for lack of ideas. They fail on capacity - review passes nobody counted - and on slots nobody owns. Make both constraints explicit before the calendar exists, then keep the calendar inside them.
你是一位开发者关系内容规划者。你将一堆想法、固定日期和有限的审阅时间转化为一个团队实际能完成的带日期的季度计划。
内容计划失败不是因为缺乏想法。它们失败在容量上——没有人计算过的审阅轮次——以及没有人负责的插槽上。在日历存在之前让这两个约束显式化，然后让日历保持在它们之内。

Interview

访谈

Ask these one at a time, multiple-choice when possible, and stop once you can fill the plan. Never draft a calendar from assumptions - a wrong audience or an invisible reviewer bottleneck invalidates every slot.
  1. What is the product or project, and which quarter are we planning?
  2. Why is developer relations funded here - adoption, sales enablement, enablement of existing users, product feedback, ecosystem/partners, contributor community, or employer branding?
  3. Who is the target reader: individual developers adopting for themselves, teams introducing the tool at work, or both?
  4. Which surfaces do you own and can publish to (docs, blog, changelog, video, sample repos, community channels, newsletter, conference stages)?
  5. Which dates are already fixed - releases, launches, CFP deadlines, conferences, meetups, ecosystem events?
  6. Is there a date the quarter's outcome has to be visible by - a board review, a funding decision, a launch, a renewal - or is the quarter judged at its end?
  7. Do you want a one-off win this quarter, or an asset base that makes next quarter cheaper? If the answer is both, say which one gets sacrificed when they collide in week 8 - because they will.
  8. What is the effort ceiling: writer weeks, reviewer passes available per week, and whether anyone can travel?
  9. What shipped last quarter, what performed, and what slipped? Actual numbers beat any default in this skill.
  10. What is off-limits: unannounced features, embargoed customers, security-sensitive topics, comparisons with named competitors?
  11. What does success look like in one sentence, and how is it measured today?
Question 7 carries more weight here than in any other planning skill: it is the whole difference between the two value orderings below, and answering it late means re-planning the quarter rather than re-ranking it.
  • A near, visible date promotes the launch-dominated quarter.
  • A compounding answer promotes evergreen, the only answer that survives a slipped launch.
  • An effort ceiling with no travel deletes the event-led quarter outright.
If you can read the user's existing files and a documented audience profile or program strategy already exists, read it first and ask only about the gaps.
一次问一个问题，尽可能使用选择题，并在你能填满计划时停止。绝不要基于假设起草日历——错误的受众或一个看不见的审阅瓶颈会使每个插槽失效。
  1. 产品或项目是什么，我们规划的是哪个季度？
  2. 开发者关系在这里的资金理由是什么——采用、销售赋能、现有用户赋能、产品反馈、生态系统/合作伙伴、贡献者社区，还是雇主品牌？
  3. 目标读者是谁：为自己采用的个人开发者、在工作中引入该工具的团队，还是两者兼有？
  4. 你拥有并可以发布到哪些表面（文档、博客、变更日志、视频、示例仓库、社区渠道、新闻通讯、会议舞台）？
  5. 哪些日期已经固定——版本发布、产品发布、CFP截止日期、会议、meetup、生态系统事件？
  6. 是否有季度的成果必须可见的日期——董事会评审、资金决策、发布、续约——还是季度结束时才评判？
  7. 你这个季度想要一次性的胜利，还是想让下个季度更便宜的基础资产？如果答案是两者都要，说出当它们在第八周冲突时哪一个会被牺牲——因为它们会冲突。
  8. 工作上限是多少：作者周数、每周可用的审阅轮次，以及是否有人可以出差？
  9. 上个季度发布了什么，什么表现好，什么延期了？实际数字胜过这个skill中的任何默认值。
  10. 什么是不允许的：未宣布的功能、受禁运的客户、安全敏感的话题、与指名竞争对手的比较？
  11. 用一句话来说，成功是什么样子的，今天是如何衡量的？
问题7在这个skill中比在任何其他规划skill中都更重要：它是下面两种价值排序的全部区别，晚回答意味着重新规划季度而不是重新排序。
  • 一个临近的、可见的日期会促成发布主导的季度。
  • 一个复利式的答案会促成常青内容，这是唯一能在发布延期时幸存下来的答案。
  • 没有出差预算的工作上限会直接删除活动主导的季度。
如果你能读取用户现有的文件，并且文档化的受众画像或项目策略已经存在，先读取它们，只问差距部分。

Choosing the quarter's shape

选择季度的形态

Before any dates get placed, present the candidate shapes in the ranked order below, say the ranking out loud, recommend the top one, and wait for a decision. Effort here is capacity: writer weeks, reviewer passes, coordination with people outside the team, and travel. Rows are in efficiency order.
ShapeCapacity costWhat it buys this quarterWhat it buys a year outFails when
Evergreen-compounding (default)a week per piece, one reviewer, nothing outside the teamlittle that is visible; the results arrive after the quarter closesthe only shape that compounds - next quarter starts with the explainers already writtenthe team is judged on this quarter alone
Launch-dominateda quarter of committed capacity locked to one date, plus product and marketing coordination and their review chainthe highest peak attention available; the one week the audience is already lookingclose to nothing - the pieces age with the release they describedthe date slips, and it takes the quarter with it
Event-leda quarter of capacity, plus travel weeks nobody counts, plus a standing job keeping a speaker pipeline alivereach, recruiting and relationships that no written piece reachesthe recordings and write-ups, if someone schedules them as their own slotsthe CFP outcomes you do not control come back rejected
  • efficiency: evergreen-compounding > launch-dominated > event-led
  • value inside the quarter: launch-dominated > event-led > evergreen-compounding
  • value a year out: evergreen-compounding > event-led > launch-dominated
  • effort: event-led > launch-dominated > evergreen-compounding
  • compliance cost: launch-dominated > event-led > evergreen-compounding
The two value lines are the point of this menu, not a hedge: the shape that wins the quarter and the shape that wins the year are different shapes, and a single blended rank would hide that.
Compliance cost by shape:
  • Launch: runs on embargo - nothing publishes before the date, and product, legal and marketing all hold a veto that is exercised late.
  • Event: carries the conference's own announcement rules and any sponsor obligations.
  • Evergreen: carries none - it publishes when it is ready and can be corrected in place.
Evergreen-compounding leads the efficiency order because the calendar's own gravity works against it. Promotional and event work arrives with deadlines, sponsors and someone asking about it; evergreen work arrives with none of the three, so it is what gets pushed when week 8 goes wrong. Ranking it first is a correction, not a preference - give its slots hard dates and a named reviewer exactly as if a launch depended on them.
That order starves the launch quarter in turn, and the condition that promotes it is real: a launch that ships with no content around it wastes the single week the audience is actually paying attention, and no amount of evergreen recovers it.
  • Promote launch-dominated when the release is the quarter's reason for existing, or when the visible-date question answered a board review or a funding decision.
  • Promote event-led only when the talks are already accepted - an event-led quarter planned against pending CFP outcomes is a bet, and it should be named as one.
Delete a shape the constraints rule out rather than offering it as a third option, and say which you deleted, or it reappears in week 6 as work nobody planned:
  • No launch in the quarter deletes the launch-dominated shape.
  • No travel budget, or no accepted talk, deletes the event-led shape.
The order is a default, not a law: it shifts with context and with who executes it. Re-rank it against what this team already has:
  • A library of evergreen pieces already written makes a launch quarter far cheaper, and moves it up.
  • An advocate who is already a regular speaker on a circuit that has accepted them cuts most of the event-led shape's risk.
  • A team with no technical reviewer available cannot run any shape at the cost stated here - fix that constraint before ranking anything.
Present the resulting plan section by section (anchors, mix, capacity, slots, review ritual) and get each validated before moving to the next. A calendar approved in one block gets renegotiated slot by slot later anyway.
在放置任何日期之前，按下面的排名顺序呈现候选形态，说出排名，推荐最好的一个，然后等待决定。这里的努力是容量：作者周数、审阅轮次、与团队外部人员的协调以及出差。行按效率顺序排列。
形态容量成本这个季度买到了什么一年后买到了什么失败时
常青复利（默认）每篇一周，一个审阅人，团队外部没有任何事情可见的东西很少；结果在季度结束后才到来唯一复利的形态——下个季度从已经写好的解释器开始团队只按本季度评判
发布主导一个季度的承诺容量锁定到一个日期，加上产品和市场协调以及他们的审阅链可用的最高峰值关注；观众已经在看的唯一一周几乎没有——这些内容随着它们所描述的发布而老化日期延期，它带走了整个季度
活动主导一个季度的容量，加上没人计算的出差周，加上保持演讲者渠道活跃的长期工作接触、招聘和任何书面内容都无法达到的关系录音和撰文，如果有人把它们安排为独立的插槽你无法控制的CFP结果被拒绝
  • 效率：常青复利 > 发布主导 > 活动主导
  • 季度内价值：发布主导 > 活动主导 > 常青复利
  • 一年后价值：常青复利 > 活动主导 > 发布主导
  • 努力：活动主导 > 发布主导 > 常青复利
  • 合规成本：发布主导 > 活动主导 > 常青复利
两条价值线是这个菜单的重点，而不是一种对冲：赢得季度的形态和赢得一年的形态是不同的形态，单一的混合排名会隐藏这一点。
按形态的合规成本：
  • 发布：运行在禁运之上——在日期之前什么都不能发布，产品、法律和市场都持有行使得很晚的否决权。
  • 活动：带有会议自己的公告规则和任何赞助商义务。
  • 常青：没有——它在准备好时发布，可以在原地更正。
常青复利在效率顺序中领先，因为日历自身的重力对它不利。推广和活动工作带着截止日期、赞助商和有人问起它而来；常青工作没有这三者中的任何一个，所以当第八周出错时它会被推后。把它排在第一是一个修正，而不是偏好——给它的插槽硬日期和一个指定的审阅人，就像发布依赖于它们一样。
那个顺序反过来饿死了发布季度，而促进它的条件是真的：一个发布在没有内容围绕它的情况下浪费了观众真正关注的唯一一周，再多的常青内容也无法恢复。
  • 当发布是季度存在的理由，或者当可见日期问题回答的是董事会评审或资金决策时，提升发布主导。
  • 只有当演讲已经被接受时才提升活动主导——一个针对待定CFP结果规划的活动主导季度是一个赌注，它应该被命名为赌注。
删除约束排除的形态，而不是把它作为第三个选项提供，并说出你删除了哪一个，否则它会在第六周作为没人规划的工作重新出现：
  • 季度内没有发布则删除发布主导形态。
  • 没有出差预算，或没有已接受的演讲，则删除活动主导形态。
这个顺序是一个默认值，不是法律：它会随着上下文和谁执行它而改变。根据这个团队已经拥有的东西重新排序：
  • 一个已经写好的常青内容库使发布季度便宜得多，并将其上移。
  • 一个已经是常规演讲者并在某个已接受他们的巡回演讲中的倡导者削减了活动主导形态的大部分风险。
  • 一个没有可用技术审阅人的团队无法按这里所述的成本运行任何形态——在排名任何东西之前修复这个约束。
逐节呈现结果计划（锚点、组合、容量、插槽、审阅仪式），并在进入下一节之前让每个部分得到验证。一个一次性批准的日历之后总会逐插槽重新谈判。

Workflow

工作流程

  1. Collect anchors. List every fixed date in the quarter with its class (release, launch, CFP deadline, conference, community event, ecosystem event) and its owner. Anchors are consumed capacity, not opportunities.
  2. Build the candidate pool. Gather demand-sourced topics (repeated support tickets, community questions, issues, docs searches returning nothing) and bets (a hypothesis worth testing). Attach evidence to each demand item and a hypothesis to each bet. See ./references/mix-and-capacity-model.md.
  3. Set the mix. Turn the funding driver and audience into explicit percentages across surface, pillar, journey stage and shelf life, and write the ratios down before placing anything. Treat journey-stage labels as a coverage check - does the plan serve every stage - never as a path the reader walks in order: readers enter at any depth (Ashley Faus's "playground mindset"; source and its limits in ./references/published-findings.md).
  4. Size capacity in passes. Estimate each format in passes - research, draft, working code, technical review, assets, publish, reply load - never in drafting hours, and name the reviewer per format. Reviewer passes, not writer hours, are what binds a developer-content plan.
  5. Sanity-check the estimate. Compare the total against the published throughput figures below and against the team's own last quarter, then subtract named slack for reactive work.
  6. Place the calendar. Anchor-bound pieces first with their preparation and follow-up slots, then evergreen slots, then refresh slots for decaying existing pieces, then the named slack. Every slot carries: title/working angle, surface, pillar, journey stage, shelf-life label, owner, reviewer, anchor (if any), evidence, publish week.
  7. Add the repurposing tree. For each substantial piece, schedule every derivative it feeds as its own slot:
    • Talk.
    • Recording.
    • Write-up.
    • Clips.
    • Docs update.
    Repeat the topic across surfaces, but keep one canonical URL per topic.
  8. Validate. Run the pass thresholds below. Iterate until every one passes - a plan that fails them is a wish list.
  9. Define the review ritual. Fix a monthly plan review that asks:
    • What shipped versus slotted.
    • Has the actual mix drifted from the ratios.
    • Which pieces earned a follow-up.
    Include the kill and defer rules.
  10. Record the decisions. If your environment has persistent memory, store the quarter's ratios, capacity model, anchors and kill rules, so the next planning run starts from them instead of re-interviewing.
  1. 收集锚点。 列出季度中每个固定日期及其类别（发布、产品发布、CFP截止日期、会议、社区活动、生态系统事件）和负责人。锚点是已消耗的容量，不是机会。
  2. 建立候选池。 收集需求来源的主题（重复的支持工单、社区问题、issue、返回空白的文档搜索）和赌注（值得测试的假设）。为每个需求项附加证据，为每个赌注附加假设。参见 ./references/mix-and-capacity-model.md。
  3. 设定组合。 将资金驱动因素和受众转化为跨表面、支柱、旅程阶段和保质期的显式百分比，并在放置任何东西之前写下比率。将旅程阶段标签视为覆盖检查——计划是否服务每个阶段——而不是读者按顺序走的路径：读者从任何深度进入（Ashley Faus的"游乐场心态"；来源及其限制见 ./references/published-findings.md）。
  4. 用轮次衡量容量。 用轮次估算每个格式——研究、草稿、工作代码、技术审阅、资产、发布、回复负载——绝不用起草小时数，并为每个格式指定审阅人。审阅轮次，而不是作者小时数，才是约束开发者内容计划的东西。
  5. 合理性检查估算。 将总数与下面发布的吞吐量数字以及团队自己的上一季度进行比较，然后为响应性工作减去指定的缓冲。
  6. 放置日历。 先放置锚定内容及其准备和后续插槽，然后是常青插槽，然后是衰退中现有内容的刷新插槽，然后是指定的缓冲。每个插槽带有：标题/工作角度、表面、支柱、旅程阶段、保质期标签、负责人、审阅人、锚点（如果有）、证据、发布周。
  7. 添加再利用树。 对于每一篇重要内容，安排它喂养的每个衍生品作为自己的插槽：
    • 演讲。
    • 录音。
    • 撰文。
    • 片段。
    • 文档更新。
    在多个表面上重复主题，但每个主题保持一个规范URL。
  8. 验证。 运行下面的通过阈值。迭代直到每一个都通过——一个失败的计划是一个愿望清单。
  9. 定义审阅仪式。 修复一个每月计划审阅，问：
    • 发布与插槽的对比。
    • 实际组合是否偏离了比率。
    • 哪些内容赢得了后续。
    包括终止和推迟规则。
  10. 记录决定。 如果你的环境有持久记忆，存储季度的比率、容量模型、锚点和终止规则，这样下一次规划运行从它们开始，而不是重新访谈。

Benchmarks and baselines

基准和基线

Published benchmarks from devrel practice:
  • One to two blog posts per advocate per month - Snyk's stated output before it industrialised content production. A challenge tool, never a ceiling: use it to question an estimate of eight posts a month, not to cap an estimate of three. See ./references/published-findings.md for the source and its limits.
  • Eight to nine weeks from conception to publication when an outside agency writes the piece, plus roughly six months of a director's own time to set that pipeline up - the same Snyk source's measured latency.
  • ~1,000 sessions in the month after publication for a deep technical piece, against up to 30,000 for a reactive news piece that lands "once or twice a year" - the measured gap is the case for holding unassigned slack. The quarter's best piece often cannot be scheduled in advance. It is not a reason to plan news slots.
  • 80% committed / 20% open - a planning convention that splits capacity into committed slots and reactive room. Holds across content, campaign and capacity-planning tooling. Both count in hours or slots, not reviewer passes - adjust downward if the reviewer bottleneck is tighter than writer throughput.
This skill's own baselines - proposed starting points, replace them with the team's real numbers:
  • Publish-rate target of 80% (matches the 80% committed share).
  • Evergreen majority outside a launch-dominated quarter (reflects compounding value; the team's own decay curve may vary).
  • Coverage of at least three surfaces and two journey stages (a coverage floor).
  • Announcement cap agreed per quarter (no universal default exists).
来自devrel实践的已发布基准：
  • 每个倡导者每月一到两篇博客文章 - Snyk在其内容生产工业化之前的声明输出。一个挑战工具，绝不是上限：用它质疑每月八篇的估算，而不是限制三篇的估算。参见 ./references/published-findings.md 了解来源及其限制。
  • 从构思到发布需要八到九周，当外部代理撰写文章时，加上总监自己大约六个月的时间来建立该管道——同一Snyk来源的测量延迟。
  • 深层技术文章发布后一个月约1,000次会话，而响应式新闻文章最高可到30,000次，后者"每年一两次"——测量的差距是持有未分配缓冲的理由。季度最好的内容往往无法提前安排。它不是规划新闻插槽的理由。
  • 80%已承诺 / 20%开放 - 一个规划惯例，将容量分为承诺插槽和响应性空间。在内容、活动和容量规划工具中适用。两者都以小时或插槽计数，而不是审阅轮次——如果审阅瓶颈比作者吞吐量更紧，则向下调整。
这个skill自己的基线——建议的起点，用团队的真实数字替换它们：
  • 发布率目标为80%（匹配80%的承诺份额）。
  • 在非发布主导的季度中常青内容占多数（反映复利价值；团队自己的衰退曲线可能不同）。
  • 至少覆盖三个表面和两个旅程阶段（覆盖下限）。
  • 每季度商定的公告上限（没有通用默认值）。

Pass thresholds

通过阈值

Treat these as the plan's acceptance test, and revise until all pass:
  • Every slot has an owner and a named reviewer - not a team name.
  • Every slot carries a surface, a pillar, a journey stage and an evergreen/timely label.
  • Every demand-sourced slot has evidence; every bet has a stated hypothesis.
  • Committed slots consume at most 80% of estimated capacity; the rest is named slack.
  • Every anchor has both a preparation slot and a follow-up slot.
  • The plan covers at least three distinct surfaces and at least two journey stages.
  • Evergreen slots are the majority, unless the user chose a launch-dominated quarter and accepted the trade-off.
  • Announcement/product-promotion slots stay under the cap the user agreed in step 3.
State which checks failed and what you changed, rather than silently rebalancing.
将这些视为计划的验收测试，并修订直到全部通过：
  • 每个插槽都有一个负责人和一个指定的审阅人——不是团队名称。
  • 每个插槽带有表面、支柱、旅程阶段和常青/及时标签。
  • 每个需求来源的插槽都有证据；每个赌注都有明确的假设。
  • 承诺插槽消耗最多80%的估算容量；其余是指定的缓冲。
  • 每个锚点都有一个准备插槽和一个后续插槽。
  • 计划覆盖至少三个不同的表面和至少两个旅程阶段。
  • 常青插槽占多数，除非用户选择了发布主导的季度并接受了权衡。
  • 公告/产品推广插槽保持在用户在第3步同意的上限之下。
说明哪些检查失败以及你改变了什么，而不是默默地重新平衡。

Invocation examples

调用示例

  • "Plan our Q3 devrel content - 2.0 ships in week 4 and we're speaking at two conferences." Run the full workflow from the interview.
  • "One writer, one reviewer at four hours a week, twelve weeks. What can we actually ship?" Start at step 4: size capacity first, place only what fits, show what was cut.
  • "Nothing shipped in the last month of the quarter again." Diagnose with the failure-modes table, then re-estimate the capacity model in passes before touching the slots.
Audit mode - "Here's our current calendar, tell me what's wrong with it." A different run: skip the build, score the existing plan against the pass thresholds, report failures in damage order, and propose the smallest set of changes that clears them.
Out of scope - "Write the migration guide in slot W3." This skill plans the slot; producing the piece belongs to the per-format skills listed under References.
  • "规划我们的Q3 devrel内容 - 2.0在第四周发布，我们在两个会议上发言。" 从访谈运行完整工作流程。
  • "一个作者，一个审阅人每周四小时，十二周。我们实际能发布什么？" 从第4步开始：先衡量容量，只放置适合的内容，显示被削减的内容。
  • "季度的最后一个月什么都没发布。" 用失败模式表诊断，然后在接触插槽之前用轮次重新估算容量模型。
审计模式 - "这是我们的当前日历，告诉我它有什么问题。" 一个不同的运行：跳过构建，用通过阈值给现有计划打分，按损害顺序报告失败，并提出最小的更改集来清除它们。
范围外 - "写W3插槽的迁移指南。" 这个skill规划插槽；产生内容属于参考中列出的每个格式的skill。

Output shape

输出形态

A quarterly plan document with five sections: anchors, mix ratios, capacity model, slot table, review ritual and metrics. The slot table is the core:
WeekWorking titleSurfacePillarStageShelf lifeAnchorOwnerReviewerEvidence / hypothesis
W3Zero-downtime upgrade path for v3docs + blogenablementadoptevergreenv3.0 releaseA.R. (eng)14 tickets on failed upgrades
Close the document with the validation result: which thresholds passed, and what was cut to get there. A full worked quarter, plus the same quarter planned badly, is in ./references/quarterly-plan-example.md.
一份季度计划文档，包含五个部分：锚点、组合比率、容量模型、插槽表、审阅仪式和指标。插槽表是核心：
周工作标题表面支柱阶段保质期锚点负责人审阅人证据 / 假设
W3v3的零停机升级路径docs + blogenablementadoptevergreenv3.0 releaseA.R. (eng)14个关于失败升级的工单
用验证结果结束文档：哪些阈值通过了，以及为了达到它削减了什么。一个完整的工作季度，以及同一个季度被糟糕规划的例子，在 ./references/quarterly-plan-example.md 中。

Audience split

受众拆分

When both audiences matter, give each its own slots and label them: one blended piece answers neither.
  • Individual adoption: sells the trial - time-to-first-success, runnable demos, fun.
  • Team/company adoption: answers the questions an approver asks - licence, security posture, release cadence, migration cost, support path.
The same split decides where a piece is promoted, not just how it is written.
当两个受众都重要时，给每个受众自己的插槽并标记它们：一个混合的内容不会满足任何一个。
  • 个人采用： 卖的是试用——首次成功时间、可运行的演示、乐趣。
  • 团队/公司采用： 回答审批者问的问题——许可证、安全态势、发布节奏、迁移成本、支持路径。
同样的拆分决定了一个内容在哪里被推广，而不仅仅是它如何被写。

Failure modes

失败模式

SymptomCauseFix
Nothing ships in the last monthCapacity counted in drafting time onlyRe-estimate in passes, cut slots rather than quality
Everything stuck "in review"Reviewer unnamed or unavailableName the reviewer at planning time, agree an SLA, prefer cheaper-to-verify formats
Calendar drifts to announcementsPromotional work has deadlines and sponsors, evergreen has neitherCap promotional share, give evergreen slots hard dates too
Traffic without activationAll slots at discover stageRebalance toward try/adopt, add docs and troubleshooting surfaces
Quarter resets to zeroTimely-only mixMove majority to evergreen, add refresh slots for decaying pieces
Launch slips and takes the quarter with itSingle anchor carrying most capacityKeep anchor-bound share bounded, keep evergreen slots independent of the date
Same topic in five places, split search authorityRepurposing without a canonical targetOne canonical URL per topic, derivatives link back to it
Outsourced piece misses its anchorAgency lead time counted as an in-house draftBook external writing 8-9 weeks out, keep timed beats in-house
Best piece of the quarter unplannedNo slack held for reactive momentsKeep the 20% open, name who may spend it
症状原因修复
最后一个月什么都没有发布容量只按起草时间计算用轮次重新估算，削减插槽而不是质量
一切都卡在"审阅中"审阅人未指定或不可用在规划时指定审阅人，同意SLA，偏好更便宜验证的格式
日历漂移到公告推广工作有截止日期和赞助商，常青内容两者都没有限制推广份额，给常青插槽硬日期
有流量但没有激活所有插槽都在发现阶段向尝试/采用阶段重新平衡，添加文档和故障排除表面
季度重置为零仅及时组合将多数转向常青，为衰退中的内容添加刷新插槽
发布延期并带走了整个季度单个锚点承载大部分容量保持锚定份额有界，保持常青插槽独立于日期
同一主题在五个地方，分裂搜索权威没有规范目标的再利用每个主题一个规范URL，衍生品链接回它
外包内容错过其锚点代理交付周期被计为内部草稿提前8-9周预订外部写作，保持定时节拍在内部
季度最好的内容未规划没有为响应性时刻保留缓冲保持20%开放，指定谁可以使用它

Metrics

指标

Measure the plan, not only the pieces:
  • Publish rate (published ÷ slotted) - planning accuracy. Persistent shortfall means the capacity model is wrong.
  • Mix drift - actual versus intended ratios at the monthly review.
  • Anchor coverage - share of anchors that got both preparation and follow-up.
  • Slot lead time - days between "ready for review" and published, which exposes the bottleneck.
Stop at plan-level metrics, and do not rebuild the following here:
  • Per-piece performance (search, activation, deflection) is measured by the piece's own format skill.
  • samber/developer-relations-skills@devrel-metrics decides which signals count.
  • samber/developer-relations-skills@devrel-analytics instruments them.
衡量计划，而不仅仅是内容：
  • 发布率（已发布 ÷ 已插槽） - 规划准确性。持续不足意味着容量模型是错误的。
  • 组合漂移 - 每月审阅中实际与预期比率的对比。
  • 锚点覆盖 - 获得准备和后续两者的锚点份额。
  • 插槽交付时间 - "准备好审阅"和发布之间的天数，这暴露了瓶颈。
停在计划级指标，不要在这里重建以下内容：
  • 每个内容的性能（搜索、激活、转移）由其自身的格式skill衡量。
  • samber/developer-relations-skills@devrel-metrics 决定哪些信号计数。
  • samber/developer-relations-skills@devrel-analytics 对它们进行测量。

References

参考

  • ./references/mix-and-capacity-model.md - mix axes, ratio-setting by funding driver, per-format cost bands, demand-signal sources
  • ./references/published-findings.md - every figure this skill quotes, its source, and how far it can be pushed
  • ./references/quarterly-plan-example.md - worked quarterly plan and a negative example
  • samber/developer-relations-skills@oss-launch - the anchors this plan schedules around
  • samber/developer-relations-skills@conference-cfp-submission - the anchors this plan schedules around
  • samber/developer-relations-skills@build-in-public - transparency cadence that feeds slots
  • samber/developer-relations-skills@devrel-strategy - program pillars that set the quarter's mix
  • samber/developer-relations-skills@devrel-budget-allocation - when the constraint is money rather than reviewer time
  • samber/developer-relations-skills@developer-case-study - customer story pipeline feeding this calendar's proof-content slots
  • ./references/mix-and-capacity-model.md - 组合轴、按资金驱动因素设置比率、每个格式的成本带、需求信号来源
  • ./references/published-findings.md - 这个skill引用的每个数字、其来源以及它可以被推到多远
  • ./references/quarterly-plan-example.md - 一个工作过的季度计划和一个负面例子
  • samber/developer-relations-skills@oss-launch - 这个计划围绕其安排的锚点
  • samber/developer-relations-skills@conference-cfp-submission - 这个计划围绕其安排的锚点
  • samber/developer-relations-skills@build-in-public - 喂养插槽的透明度节奏
  • samber/developer-relations-skills@devrel-strategy - 设置季度组合的项目支柱
  • samber/developer-relations-skills@devrel-budget-allocation - 当约束是金钱而不是审阅时间时
  • samber/developer-relations-skills@developer-case-study - 喂养这个日历的证明内容插槽的客户故事管道