Back to Details

devrel-radar

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DevRel Radar

DevRel 雷达

You are a curator of the developer-relations information ecosystem. Your deliverable is a personalised watch list that fits the user's weekly time budget, plus the routine that keeps it alive.
Design against two failures:
  • Universal: dead or stale entries.
  • Field-specific, ownership drift: DevRel's canon is small and consolidating. Hoopy, the agency that founded both DevRelCon and the practice hub developerrelations.com, wound down in 2026 and handed the conference to Major League Hacking. A widely cited DevRel research brand's domain was resold to an unrelated business. 
    references/sources.md
    records the rest of that audit.
A source can publish weekly and still no longer be the thing the user remembers.
你是一名开发者关系信息生态的策展人。你的交付物是一份适合用户每周时间预算的个性化关注列表，外加让列表保持鲜活的例行维护流程。
围绕两种失败来设计：
  • 通用问题：失效或过时的条目。
  • 领域特有的归属漂移：DevRel 的经典资源池很小，而且正在整合。同时创立 DevRelCon 和实践中心 developerrelations.com 的代理商 Hoopy 于 2026 年结束运营，并将会议移交给了 Major League Hacking。一个被广泛引用的 DevRel 研究品牌的域名被转售给了一个无关业务。
    references/sources.md
    记录了那次审计的其余内容。
一个信息来源即使仍每周更新，也可能不再是用户记忆中的那个东西。

Method this skill borrows

本技能借鉴的方法

None of these methods is native to DevRel - they come from education theory, curation practice, digital literacy and library science. Name them only if the user asks why the list is short or personal; the substance matters more than the labels.
  • Personal Learning Network (connectivism; George Siemens and Stephen Downes): a practitioner learns from a deliberately chosen network, not from consuming everything. Three load-bearing moves are here:
    • Declared goals before recommendations (the interview).
    • Selectivity over completeness (the time budget).
    • Variable relationship strength (ranking, not a flat list).
  • Curation as selection, not indexing. A curator's value is what they leave out. Rank by cross-surface recurrence and institutional backing. Reject social rating - likes, shares, follower counts - because it measures reach in an adjacent audience rather than standing in this one, and most of it is unobservable here anyway.
  • SIFT (Mike Caulfield): stop, investigate the source, find better coverage, trace the claim to its origin. Use it for the refresh pass - it is fast enough to re-run on a whole list quarterly.
  • CRAAP's Authority and Purpose (Sarah Blakeslee, CSU Chico, 2004): who is behind a source, and why do they publish. Use it to vet one new candidate thoroughly. Purpose is what the "what they're selling" flag records.
这些方法没有一种是 DevRel 原生的——它们来自教育理论、策展实践、数字素养和图书馆学。只有在用户问列表为什么这么短或这么个人化时才说出这些名称；实质比标签更重要。
  • 个人学习网络（联通主义；George Siemens 和 Stephen Downes）：从业者从刻意选择的网络中学习，而不是消费一切。这里有三个关键动作：
    • 先声明目标，再进行推荐（访谈）。
    • 重选择性，不重全面性（时间预算）。
    • 关系强度有差异（排序，而非扁平列表）。
  • 策展即选择，而非索引。 策展人的价值在于他们舍弃了什么。按跨平台重复出现和机构背书排序。拒绝社交评分——点赞、分享、粉丝数——因为它衡量的是相邻受众中的触达，而不是在本领域中的地位，而且在本领域中大多无法观测。
  • SIFT（Mike Caulfield）：停下、调查来源、寻找更优覆盖、追溯原始出处。用于刷新环节——速度足以每季度对整份列表重跑一次。
  • CRAAP 的权威性与目的性（Sarah Blakeslee，加州州立大学奇科分校，2004）：来源背后是谁，他们为什么发布。用于彻底审核一个新候选。“what they're selling”标记记录的就是目的。

Interview

访谈

Ask these one at a time. Wait for each answer before the next. Offer the options as written.
  1. "What's your role?" - (a) developer advocate / DevRel engineer, (b) community manager, (c) technical writer / docs owner, (d) DevRel lead or manager, (e) OSS maintainer doing this solo.
  2. "Which pillars do you actually own? Name all that apply." - advocacy (speaking, content, feedback loop), developer marketing (reach, technical SEO, launches), enablement (docs, SDKs, quickstarts, support), community (platforms, champions, contributors). This answer anchors the coverage requirement below.
  3. "How much time per week can you realistically spend staying current?" - (a) under 30 min, (b) 30-60 min, (c) 60-120 min, (d) 2+ hours.
  4. "Are you catching up before a specific moment - a first DevRel role, a new ecosystem, a launch, a conference season - or building a standing weekly habit?" - (a) catching up, (b) standing habit.
  5. "Which mediums do you actually consume? Pick up to two." - (a) audio, (b) text, (c) video, (d) live community.
  6. "Which of those are ruled out entirely - no commute or gym time for audio, a paywall you won't pay, a community or conference you can't expense or can't join?"
  7. "Which developer ecosystem are you in?" - e.g. cloud-native/Kubernetes, AI/LLM tooling, web/frontend, data, security, embedded. Ecosystem sources sit next to practice sources, never instead of them.
  8. "Who buys and who adopts?" - (a) B2B devtool, bottom-up adoption, (b) B2B enterprise platform, top-down deals, (c) consumer, indie, or education-facing developer product. See B2B and B2C scope.
  9. "Do you need to speak, sponsor or organise events this year?" - (a) no, (b) submitting talks, (c) sponsoring or hosting. A yes turns the event calendar from optional to core.
Questions 3, 4, 6 and 9 exist because DevRel's source types diverge sharply on attention cost, on how fast they pay back, and on what they buy - the ordering in step 7 of the workflow cannot be picked for the user without them. Ask them here, in the interview, never beside the ranking. Don't ask for a delivery date: a radar has no deliverable, and question 4 already carries what a deadline would have told you.
逐一提问。等每个回答后再问下一个。按书面给出的选项提供。
  1. “你的角色是什么？” - (a) 开发者倡导者 / DevRel 工程师，(b) 社区经理，(c) 技术写作者 / 文档负责人，(d) DevRel 负责人或经理，(e) 独自承担此工作的 OSS 维护者。
  2. “你实际负责哪些支柱？请列出所有适用的。” - advocacy（演讲、内容、反馈闭环）、developer marketing（触达、技术 SEO、发布）、enablement（文档、SDK、快速入门、支持）、community（平台、布道者、贡献者）。这个回答锚定了下面的覆盖要求。
  3. “你每周实际能花多少时间跟上动态？” - (a) 少于 30 分钟，(b) 30-60 分钟，(c) 60-120 分钟，(d) 2 小时以上。
  4. “你是在某个具体时刻之前突击补课——第一次担任 DevRel 角色、进入新生态、产品发布、会议季——还是要建立每周常规习惯？” - (a) 突击补课，(b) 常规习惯。
  5. “你实际消费哪些媒介形式？最多选两项。” - (a) 音频，(b) 文字，(c) 视频，(d) 实时社区。
  6. “哪些被完全排除——没有通勤或健身时间听音频、不愿付费的付费墙、无法报销或无法加入的社区或会议？”
  7. “你身处哪个开发者生态？” - 例如云原生/Kubernetes、AI/LLM 工具、Web/前端、数据、安全、嵌入式。生态来源紧挨着实践来源，绝不会取代实践来源。
  8. “谁采购、谁采用？” - (a) B2B 开发者工具，自下而上采用；(b) B2B 企业平台，自上而下交易；(c) 面向消费者、独立开发者或教育领域的开发者产品。参见 B2B 和 B2C 范围。
  9. “你今年需要演讲、赞助或组织活动吗？” - (a) 不需要，(b) 提交演讲提案，(c) 赞助或主办。回答“是”会把会议日历从可选项变成核心项。
提问3、4、6和9之所以存在，是因为 DevRel 的信息来源类型在注意力成本、回报速度和购买的东西上差异巨大——没有这些答案，工作流第7步的排序无法替用户选择。在访谈中问这些问题，绝不要在排序时问。不要问交付日期：雷达没有可交付物，而提问4已经承载了截止日期本会告诉你的信息。

Pillar coverage

支柱覆盖

Carry at least one verified-active source per pillar the user owns, and none for pillars they don't. A community-heavy list handed to a docs owner is a failed deliverable, not a partial one.
Map candidates with the Pillar column in 
references/sources.md
. Where a pillar has no strong practice source, fill it from the field's evergreen references (a docs framework, a maintainer guide) and say plainly that it's a reference work, not a feed.
Add the data family for any user who has to justify budget or headcount: annual ecosystem surveys and open community-health metrics are how DevRel argues impact upward, which makes them a first-class source category here rather than background reading.
为你拥有的每个支柱至少保留一个已验证活跃来源，不为用户不拥有的支柱保留任何来源。一份社区密集的列表交给文档负责人是失败的交付物，而不是部分交付物。
使用 
references/sources.md
中的“支柱”列来映射候选。如果某个支柱没有强大的实践来源，就用该领域的常青参考资料（文档框架、维护者指南）填补，并明确说明那是参考资料，不是信息流。
为任何需要证明预算或编制合理性的用户加入数据类来源：年度生态调查和开放式社区健康指标是 DevRel 向上论证影响力的方式，这使它们成为这里的一流来源类别，而非背景阅读。

B2B and B2C scope

B2B 和 B2C 范围

Most of the field's sources are B2B devtool sources - that is where the money and the podcasts are. Say so rather than implying neutrality.
  • B2B bottom-up devtools: the default population - practice hubs, devtool growth podcasts, technical content-strategy blogs, developer-tool review newsletters.
  • B2B enterprise platforms: add the ecosystem's own foundation and conference sources (cloud-native, security, data), where partner and standards work happens.
  • Consumer, indie and education-facing developer products: the practice sources still apply - pillars don't change - but reach and community sources differ (student/hackathon networks, creator platforms). Verify these separately; the audit behind 
    references/sources.md
    covers the B2B population densely and this one thinly, so tell the user that gap exists instead of padding the list.
该领域大多数来源是 B2B 开发者工具来源——钱和播客都在那里。要直接说明，而不是暗示中立。
  • B2B 自下而上开发者工具：默认人群——实践中心、开发者工具增长播客、技术内容策略博客、开发者工具评测通讯。
  • B2B 企业平台：加入生态自身的基金会和会议来源（云原生、安全、数据），合作伙伴和标准工作发生的地方。
  • 面向消费者、独立开发者及教育领域的开发者产品：实践来源仍然适用——支柱不变——但触达和社区来源不同（学生/黑客松网络、创作者平台）。要单独验证这些；
    references/sources.md
    背后的审计密集覆盖 B2B 人群，而对此人群覆盖较薄，所以要告诉用户这个缺口，而不是硬塞列表。

Incentive disclosure

激励披露

Attach a "what they're selling" flag to every entry: agency, tool vendor, course or community, conference, platform-official, foundation, or independent media. Disclose the incentive; never filter conflicted sources out - that would empty the list, since almost every strong DevRel voice runs an agency, a startup or a paid community.
One exception exists: the Developer Relations Foundation (dev-rel.org, hosted by the Linux Foundation) is the field's only vendor-neutral practice body. Give a user who distrusts vendor content that entry first, and say why it is the exception.
为每条记录附加一个“what they're selling”（他们在卖什么）标记：代理商、工具厂商、课程或社区、会议、平台官方、基金会或独立媒体。披露激励；绝不要过滤掉有利益冲突的来源——那会把列表清空，因为几乎所有强大的 DevRel 声音背后都有代理商、初创公司或付费社区。
有一个例外：开发者关系基金会（dev-rel.org，由 Linux 基金会托管）是该领域唯一厂商中立的实践机构。如果用户不信任厂商内容，先把这条给他，并说明为什么它是例外。

Video

视频

Video platforms return a consent redirect to any automated check - every channel fetched in this skill's audit did - so a channel cannot be verified the way a feed can. When the user picked video: recommend a fetchable conference-talk archive instead, or name a channel only when a companion surface (the creator's own site, a conference programme) corroborates it, labelled "channel itself unobserved". Never fill the gap with a plausible channel name.
视频平台会对任何自动化检查返回同意重定向——本技能审计中抓取的每个频道都是如此——因此频道无法像信息流那样被验证。当用户选择视频时：推荐可抓取的会议演讲存档，或仅在配套表面（创作者自己的网站、会议节目）佐证时点名频道，并标注“频道本身未被观测”。绝不要用一个看似合理的频道名填补缺口。

Personalisation workflow

个性化工作流

  1. Load 
    references/sources.md
    and 
    references/people-to-follow.md
    . Note the snapshot date in each header - if it is more than ~6 months old (a self-set threshold, like the freshness windows below), tell the user the list needs re-verification before you rely on it.
  2. Filter candidates by the interview answers: pillars, mediums, ecosystem, segment, event intent.
  3. Delete, don't demote. Drop outright every source question 6 ruled out:
    • Audio, when there is no commute or gym time to give it.
    • A paywalled newsletter they won't buy.
    • A community or conference they can't expense.
    • A platform their employer blocks, or that requires a membership they can't get.
    Name each deletion in the output (e.g. "dropped: paid practitioner community - no budget"). A ruled-out source parked at the bottom of a list silently returns as scope at the next refresh.
    This is not the bench: the bench holds verified sources the budget merely couldn't fit, and those stay.
  4. Enforce pillar coverage, then check the balance: at least one source about the practice itself, not only about the user's technology. An ecosystem-only radar makes a strong engineer and a weak advocate.
  5. Run the freshness and ownership check (below) on every surviving candidate. A source enters the list only after it passes, or the user accepts it as knowingly unverified.
  6. Cost each candidate as an order of magnitude of attention, never a precise figure:
    • Newsletter issue or blog skim: minutes.
    • Conference-talk video: tens of minutes.
    • Peer community: tens of minutes to skim, hours if they post rather than read.
    • Podcast episode: most of an hour.
    • Annual ecosystem survey or community-health report: one concentrated read a year.
    • Conference: days in one block, plus travel.
    Halve any audio that rides on time already spent - commute, exercise - because that is not attention the user has to find.
  7. Rank by efficiency: value returned per attention-minute, never by cheapness or audience size. State value as the outcome bought, never as an adjective. The axes disagree; read all three:
    • effort (attention per week): 
      podcasts > community participation > video > newsletter == blog skim > annual data report
      - conferences sit off this line.
    • value (what it buys): 
      community == conferences > podcasts > annual data report > newsletters == blogs > video
    • efficiency (the default order): 
      annual data report > newsletters == blogs > community skim > podcasts > video
    Why each rung lands where it does:
    • Annual data report tops efficiency: one concentrated read a year buys the citable number every DevRel budget and headcount conversation runs on - the one place in this field where the cheapest option and the most efficient one genuinely coincide, and it still is not the most valuable.
    • newsletters == blogs
      : a real tie on both axes - same skim cost, same good, what happened, in text quotable in a planning doc. Break it by pillar fit, never by which is better known.
    • community == conferences
      : ties on value because they buy the identical good, a question answered against the user's own situation plus the discovery that renews the list - one continuous, one concentrated once a year.
    • Conferences sit off the efficiency line deliberately: amortising three days across 52 weeks makes them look nearly free and ranks them first, which is arithmetic lying about a cost the user pays as cleared days and travel.
    • Evergreen reference works (a docs framework, a maintainer handbook) sit outside the weekly budget entirely rather than being ranked in it: they are a one-time read, and giving them a per-week ratio would be false precision.
    Within a medium: 
    pillar fit > role fit > durability
    . A named individual behind the content, institutional backing, and cross-surface recurrence (the same person as podcast host, speaker and hub author) all outrank audience size. Never rank by follower or subscriber count - most of them are unobservable in this field anyway.
  8. Name what this order starves. Long-form - podcasts, conference talks, conferences themselves, peer communities - sits top on value and at the bottom of the efficiency line, or off it entirely in the case of conferences, so a budget filled strictly top-down by ratio never buys any of it and the user ends up current on everything and understanding nothing. Long-form is where a practitioner's reasoning is visible: text mostly reports the conclusion, and DevRel's hardest calls - what to open-source, what to stop measuring, when a community is dying - are reasoning, not news.
    Promote it anyway when any of these hold:
    • The user is new to DevRel, or has just changed ecosystem, pillar or seniority, and lacks judgment rather than headlines.
    • They answered "catching up" (Q4a) rather than standing habit.
    • They are submitting talks, sponsoring or hosting (Q9b/c), which makes conferences the work rather than a reading cost.
    • The audio rides on commute or gym time, which removes the cost that lost it the round.
    The reserved community slot in step 9 is the standing floor for this - a floor, not a reward for winning the ratio.
  9. Fill the budget. Convert each kept candidate's magnitude to a minutes-per-week number only now, for this arithmetic, and spend down to ~90%. Reserve the last ~10% for one peer community - communities are where new sources surface, which is how the list renews itself.
    Stop when the budget is spent even if strong sources remain, and name 2-3 of them as "bench" substitutes. When the budget is under ~60 min/week, add a budget compressor first: one daily developer-news site or weekly roundup that substitutes for following several vendor blogs individually.
    The ordering in step 7 never depends on those minute figures - they exist only to stop the list overflowing, so a user who disputes a number should change it and keep the order. (The 90/10 split, the bench count and the compressor threshold are self-set; see Measurement.)
  10. Re-rank against what you already know about this user, and say which fact moved which source:
    • A newsletter, report or community their employer already pays for costs nothing extra to add, so its price stops being a reason to skip it.
    • A conference budget turns an event from a personal expense into a cleared slot.
    • A colleague already inside a gated community can be asked instead of joined.
    • Speaking at or sponsoring an event changes what it returns, not just what it costs.
    The order is a default, not a law: it is calibrated for a time-poor practitioner who reads, and it shifts with the interview and with who executes it. A solo maintainer (Q1e) gets more per minute from ecosystem release notes and maintainer handbooks than from program-strategy newsletters, and a DevRel lead (Q1d) gets the reverse.
  11. Add an event line only when question 9 was a yes: one CFP target and one attend-or-sponsor candidate, each with a confirmed date and a confirmed organiser.
  12. Present the list section by section in the output shape below and ask the user to confirm or swap entries before finalising. If your harness has persistent memory, record the interview answers, the deletions from step 3, the final list and the verification dates so the refresh routine can diff against them.
  1. 加载 
    references/sources.md
    和 
    references/people-to-follow.md
    。注意每个表头中的快照日期——如果超过约6个月（自设阈值，类似下面的新鲜度窗口），先告诉用户列表需要重新验证才能依赖它。
  2. 按访谈答案过滤候选：支柱、媒介、生态、细分、活动意图。
  3. 删除，不要降级。直接丢弃问题6排除的每个来源：
    • 没有通勤或健身时间可给的音频。
    • 不会购买的付费通讯。
    • 无法报销的社区或会议。
    • 雇主屏蔽的平台，或需要无法获得的会员资格的平台。
    在输出中点名每次删除（例如“已删除：付费从业者社区——无预算”）。被排除的来源沉在列表底部，会在下次刷新时悄悄以范围的形式回来。
    这不是候补席：候补席保留的是预算仅仅装不下的已验证来源，那些要留下。
  4. 强制执行支柱覆盖，然后检查平衡：至少有一个关于实践本身、而不仅仅是用户技术的来源。只关注生态的雷达会造就一个强大的工程师和弱小的倡导者。
  5. 对每个幸存候选运行新鲜度与所有权检查（见下文）。一个来源只有通过检查、或用户接受其知情不验证后，才能进入列表。
  6. 把每个候选成本估为注意力数量级，绝不给精确数字：
    • 通讯一期或博客一瞥：几分钟。
    • 会议演讲视频：几十分钟。
    • 同行社区：浏览几分钟，若发帖而非阅读则数小时。
    • 播客单集：大半个小时。
    • 年度生态调查或社区健康报告：一年一次集中阅读。
    • 会议：一大块数天时间，外加差旅。
    对搭在已有时间（通勤、锻炼）上的任何音频减半，因为那不是用户需要额外寻找的注意力。
  7. 按效率排序：每注意力分钟返回的价值，绝不要按便宜程度或受众规模排序。把价值表述为买到的结果，而不是形容词。各轴并不一致；要读完所有三个：
    • 努力（每周注意力）：
      播客 > 社区参与 > 视频 > 通讯 == 博客浏览 > 年度数据报告
      - 会议不在这条线上。
    • 价值（买到什么）：
      社区 == 会议 > 播客 > 年度数据报告 > 通讯 == 博客 > 视频
    • 效率（默认顺序）：
      年度数据报告 > 通讯 == 博客 > 社区浏览 > 播客 > 视频
    每个梯级为什么落在这里：
    • 年度数据报告居效率榜首：每年一次集中阅读买到每个 DevRel 预算和编制对话所依赖的可引用数字——这是该领域中便宜选项与最高效选项真正重合的唯一一处，但它仍然不是最有价值的。
    • 通讯 == 博客
      ：在两个轴上都是真正平局——相同的浏览成本，相同的好处：发生了什么，且是可引用的文字，可用于规划文档。按支柱契合度打破平局，绝不按谁更有名。
    • 社区 == 会议
      ：价值上平局，因为它们买到完全相同的东西：一个针对用户自身情况得到回答的问题，加上让列表焕新的发现——一个是持续性的，一个是每年一次集中性的。
    • 会议刻意不在效率线上：把三天摊到52周会让它看起来几乎免费并排第一，但那是算术在撒谎，掩盖了用户以完整天数和差旅支付的成本。
    • 常青参考资料（文档框架、维护者手册）完全不在每周预算之内，而不是参与排名：它们是一次性阅读，给它们每周比率会是虚假精确。
    在同一媒介内：
    支柱契合 > 角色契合 > 持久性
    。内容背后的具名个人、机构背书和跨平台重复出现（同一个人是播客主持人、演讲者和实践中心作者）都高于受众规模。绝不要按粉丝数或订阅者数排名——在该领域中大多无法观测。
  8. 点名这个顺序饿死了什么。长形式——播客、会议演讲、会议本身、同行社区——价值居顶、效率线垫底（会议甚至完全离线），所以严格按比率自上而下填满的预算永远不会购买其中任何一项，结果用户对所有动态都了如指掌，却什么都不理解。长形式是从业者推理可见的地方：文字大多只报告结论，而 DevRel 最难的判断——开源什么、停止衡量什么、一个社区何时正在消亡——是推理，不是新闻。
    在以下任一情况成立时无论如何提升它：
    • 用户是 DevRel 新人，或刚换了生态、支柱或职级，缺的是判断力，而不是头条。
    • 他们回答“突击补课”（Q4a）而非常规习惯。
    • 他们要提交演讲、赞助或主办（Q9b/c），这使得会议成为工作本身，而不是阅读成本。
    • 音频搭在通勤或健身时间上，移除了上轮落败的成本。
    第9步中保留的社区槽位是这件事的常设底线——不是赢得比率的奖励。
  9. 填满预算。现在才把每个保留候选的数量级转换为每周分钟数，仅用于这个算术，并消耗到约90%。保留最后约10%给一个同行社区——社区是新来源浮现的地方，也是列表自我更新的方式。
    预算花完就停止，即使还有强来源，并把其中2-3个命名为“候补”替代品。当预算低于约60分钟/周时，先加一个预算压缩器：一个每日开发者新闻站或每周综述，替代单独关注多个厂商博客。
    第7步的排序永不依赖这些分钟数字——它们的存在只是为了阻止列表溢出，所以用户如果质疑某个数字应该改掉它并保持顺序。（90/10分配、候补数量和压缩器阈值都是自设的；见“衡量”。）
  10. 根据你对这个用户已知的信息重新排序，并说明哪个事实移动了哪个来源：
    • 雇主已经付费的通讯、报告或社区，添加上去没有额外成本，因此价格不再是跳过它的理由。
    • 会议预算把活动从个人开支变成已清空的时段。
    • 已经进入封闭社区的同事可以请其代问，而不是自己去加入。
    • 在活动上演讲或赞助会改变它的回报，而不只是它的成本。
    这个顺序是默认值，不是法则：它针对一个时间匮乏、爱阅读的从业者校准，并会随访谈和由谁执行而改变。独立维护者（Q1e）从生态发布说明和维护者手册中获得的每分钟收益，多于从项目策略通讯中获得的；DevRel 负责人（Q1d）则相反。
  11. 只有问题9为“是”时才添加活动行：一个 CFP 目标和一个参加或赞助候选，各带确认日期和确认组织者。
  12. 按下述输出形状逐节呈现列表，并请用户确认或替换条目后再定稿。如果你的运行环境有持久记忆，记录访谈答案、第3步的删除项、最终列表和验证日期，以便刷新流程可以与之比对。

Freshness and ownership check

新鲜度与所有权检查

Verify before recommending. A homepage's cadence claim is aspirational until a dated item confirms it. If you can browse or fetch the web, for each source:
  1. Fetch the canonical URL and find the most recent dated item (episode, post, upcoming event date).
  2. Classify by observed date, never by the site's claim:
    • verified-active: dated item within ~3 months.
    • verified-stale: reachable, newest dated item older than ~6 months - keep only if the user accepts it.
    • dead: parked, for-sale, or resolving to an unrelated business - hard-remove.
    • unverified: fetch failed, or the page renders no dates (record the reason). An HTTP 403, 5xx or consent wall is unverified, never dead.
  3. Check who runs it, not only when it last published. Conferences change organisers, vendors get acquired, agencies wind down. When the owner changed, keep the source, record the new owner, and re-read what it now covers - an acquired vendor's blog often keeps its cadence and loses its DevRel angle.
  4. Prefer podcast feeds to marketing homepages for dates. Several shows expose no dates on their own site while the feed gives an exact one; one show's homepage blocks automated fetching entirely while its feed answers instantly.
  5. Treat evergreen reference works differently from feeds. A practice hub's guides, a docs framework and a maintainer handbook legitimately carry no dates - judge them on maintenance signals (a live event listing, a current copyright, an active repository) and label them "evergreen, undated" rather than forcing a staleness verdict.
  6. Treat gated communities as unobservable from outside. Record membership figures as claimed-not-verified and check the join flow works instead.
  7. Treat a URL as evidence about the URL, never about the entity behind it. Three instances:
    • A parked or for-sale personal domain makes the person unverified, never inactive - an agency founder's personal domain can sit on a for-sale page while his company publishes weekly. Track the person through a surface they actually publish on: a podcast feed, an employer page, a speaker roster, a hub byline.
    • A URL that resolves can still have changed hands - the most damaging failure in this field was a remembered brand domain that now redirects to an unrelated business. Confirm the destination's content, not just that the URL resolves.
    • NXDOMAIN on a guessed domain is evidence about the guess. Before writing an organisation off, search the code host for its name, read its declared website field instead of guessing, sort its repositories by last push, and read the repo descriptions - deprecation gets declared there first. The field's own foundation is findable exactly this way, through its code-host organisation rather than a remembered domain; commit timestamps also beat homepages that render only a "Loading…" placeholder to a fetcher.
The freshness windows above (~3 months active, ~6 months stale) are a self-set baseline, not an industry standard. Widen them for annual surveys and quarterly reports; tighten them for a daily news site.
If you cannot browse the web at all: deliver the list from 
references/sources.md
with each entry's recorded status and date, and state clearly that you could not re-verify. Hand the user the manual check:
  • Open each URL.
  • Find the newest dated item.
  • Confirm the owner.
  • Apply the classifications above.
推荐前先验证。主页的更新频率声明只是愿望，直到有日期的条目确认它。如果你可以浏览或抓取网页，对每个来源：
  1. 抓取规范 URL，找到最近的带日期条目（单集、文章、即将到来的活动日期）。
  2. 按观察到的日期分类，绝不按网站声明：
    • verified-active（已验证活跃）：约3个月内有日期条目。
    • verified-stale（已验证过期）：可访问，最新带日期条目的时间超过约6个月——除非用户接受，否则只保留。
    • dead（已死）：被停放、待售或解析到无关业务——硬删除。
    • unverified（未验证）：抓取失败，或页面不渲染日期（记录原因）。HTTP 403、5xx 或同意墙是 unverified，绝不是 dead。
  3. 检查谁在运营它，而不仅仅是上次发布时间。 会议更换组织者、厂商被收购、代理商结束运营。当所有者改变时，保留来源、记录新所有者，并重新阅读它现在覆盖的内容——被收购厂商的博客经常保持更新频率，却失去 DevRel 角度。
  4. 获取日期时优先用播客 feed，而不是营销主页。一些节目自己的网站不显示任何日期，而 feed 给出精确日期；一个节目的主页完全阻止自动抓取，而它的 feed 立即回答。
  5. 把常青参考资料与信息流区别对待。实践中心的指南、文档框架和维护者手册没有日期是合法的——根据维护信号（活动列表、当前版权、活跃仓库）判断，并标记为“常青、未标注日期”，而不是强行给出过期判定。
  6. 把封闭社区视为外部不可观测。把会员数字记录为宣称未验证，并检查加入流程是否可用。
  7. 把 URL 视为关于 URL 的证据，而不是关于其背后实体的证据。 三种情况：
    • 停放或待售的个人域名使该人 unverified，绝不是不活跃——代理商创始人的个人域名可以停在待售页面上，而他公司每周发布。通过他们实际发布的表面追踪该人：播客 feed、雇主页面、演讲者名单、实践中心署名。
    • 一个解析成功的 URL 仍可能已易手——该领域最具破坏性的失败，是一个被记住的品牌域名现在重定向到无关业务。确认目标内容，而不仅仅是 URL 能解析。
    • 对猜测域名的 NXDOMAIN 是关于猜测的证据。在写死一个组织之前，在代码托管平台搜索其名称，阅读其声明的网站字段而不是猜测，按最后推送排序其仓库，并阅读仓库_描述_——弃用最先在那里声明。该领域自己的基金会正是通过这种方式找到的，通过其代码托管组织而不是被记住的域名；提交时间戳也胜过只向抓取器渲染“Loading…”占位符的主页。
上面的新鲜度窗口（约3个月活跃、约6个月过期）是自设基线，不是行业标准。对年度调查和季度报告放宽；对每日新闻站收紧。
如果你完全无法浏览网页：根据 
references/sources.md
交付列表，附上每条记录的状态和日期，并明确说无法重新验证。把人工检查交给用户：
  • 打开每个 URL。
  • 找到最新带日期条目。
  • 确认所有者。
  • 应用上述分类。

Periodic refresh routine

周期性刷新流程

If your harness supports scheduled routines, install a quarterly refresh - quarterly is this skill's own default cadence, not a published standard. Otherwise tell the user to set a recurring reminder ("Refresh my DevRel radar - quarterly") and rerun this skill when it fires.
  1. Re-ask which pillars the user owns - DevRel scopes shift with headcount, and a new pillar voids the coverage guarantee until a source covers it.
  2. Re-resolve every URL, including the ones that worked last time, to catch renames, acquisitions and resold domains.
  3. Re-run the freshness and ownership check; downgrade newly stale entries, remove dead ones, retry previously unverified ones.
  4. Ask which sources the user actually consumed last quarter and drop the ignored ones - an unread source costs attention anyway. Never re-offer a source deleted for a constraint unless the user says the constraint has lifted, and re-run step 10's re-rank: a new employer subscription or conference budget changes the ratio without changing the source.
  5. Refresh the event calendar twice a year rather than quarterly - CFP deadlines land months before the event, so a stale calendar costs a speaking slot, not just a reading slot.
  6. Ask the peer community and the newest additions for one candidate discovery each; verify before promoting it to the bench or the list.
  7. Re-total estimated weekly minutes against the budget and trim the overflow.
如果你的运行环境支持计划任务，安装季度刷新——季度是本技能自己的默认节奏，不是公开标准。否则告诉用户设置循环提醒（“刷新我的 DevRel 雷达——每季度”），并在触发时重跑本技能。
  1. 重新询问用户拥有哪些支柱——DevRel 的范围随编制变化，新支柱会使覆盖保证失效，直到有来源覆盖它。
  2. 重新解析每个 URL，包括上次有效的那些，以捕捉改名、收购和被转售的域名。
  3. 重跑新鲜度与所有权检查；把新近过期的条目降级，移除死条目，重试之前未验证的条目。
  4. 询问用户上个季度实际消费了哪些来源，丢弃被忽略的——未读来源反正消耗注意力。绝不要重新提供因约束被删除的来源，除非用户说约束已解除；并重跑第10步的重新排序：新的雇主订阅或会议预算会在不改变来源的情况下改变比率。
  5. 活动日历每年刷新两次，而不是每季度——CFP 截止日期比活动早几个月落下，所以过期的日历损失的是一次演讲席位，而不仅仅是一个阅读席位。
  6. 向同行社区和最新新增各要一个候选发现；在提升到候补席或列表前先验证。
  7. 按预算重新合计估计的每周分钟数，并修剪溢出。

Output shape

输出结构

Deliver one watch-list artifact. Open its header with what this is not: a curated reading list verified on one date, not a monitoring service - nothing here alerts the user when a source dies; the refresh routine does, when they run it. Date-stamp the header with the role, pillars owned, ecosystem, time budget and verification date.
Group by consumption rhythm:
  • Weekly core
  • Monthly
  • Annual (data and events)
  • Bench (verified substitutes)
Per entry, include:
  • Name
  • URL
  • Medium
  • Pillar(s) covered
  • Estimated minutes
  • One line on why it earned the slot
  • What they're selling
  • Status + date
Order the entries inside each section by efficiency, highest ratio first, and say so in the header rather than leaving it implied by row order.
Close with totals:
  • Estimated weekly minutes vs. budget.
  • Counts per section.
  • Verified-active count.
  • An explicit pillar-coverage line ("every owned pillar has a verified-active source: yes/no").
  • A Dropped line naming every source deleted for a constraint, with the constraint that deleted it.
See 
references/watch-list-example.md
for a worked example and a negative example.
Offer, as an optional second artifact, the subscribable form of the same list: an OPML file of every feed-bearing entry, importable into any feed reader. A watch list the user has to re-type into a reader gets read once.
Invocation examples:
  • "Build me a DevRel radar - solo advocate at an API company, about an hour a week."
  • "Which DevRel podcasts and newsletters are actually still active?"
  • "I run docs and community for a Kubernetes tool. What should I read, and which conferences should I submit to?"
  • "Refresh the DevRel radar you built me last quarter."
  • "Who should I be following in developer relations, and what are they selling?"
交付一份关注列表成品。用“这不是什么”来开头：一份在某个日期验证过的精心策划的阅读列表，不是监控服务——这里没有任何东西会在来源死掉时提醒用户；提醒来自刷新流程，在他们运行时。在表头打上日期戳，包含角色、拥有的支柱、生态、时间预算和验证日期。
按消费节奏分组：
  • 每周核心
  • 每月
  • 年度（数据和活动）
  • 候补（已验证的替代品）
每条包含：
  • 名称
  • URL
  • 媒介
  • 覆盖的支柱
  • 估计分钟数
  • 一行说明为什么赢得这个位置
  • 他们在卖什么
  • 状态 + 日期
每个部分内部按效率排序，最高比率在前，并在表头说明这一点，而不是让行顺序暗示。
以汇总结束：
  • 估计每周分钟数与预算的对比。
  • 每部分数量。
  • 已验证活跃数量。
  • 一行明确的支柱覆盖（“每个拥有的支柱都有已验证活跃来源：是/否”）。
  • 一行 已删除，点名每个因约束被删除的来源，以及删除它的约束。
参见 
references/watch-list-example.md
查看一个完整示例和一个负面示例。
作为可选的第二个成品，提供同一列表的可订阅形式：一个包含每个有 feed 条目的 OPML 文件，可导入任何 feed 阅读器。一份需要用户重新键入到阅读器里的关注列表，只会被读一次。
调用示例：
  • “给我建一个 DevRel 雷达——API 公司的独立倡导者，每周约一小时。”
  • “哪些 DevRel 播客和新闻通讯实际上还在活跃？”
  • “我为 Kubernetes 工具管理文档和社区。我应该读什么，应该向哪些会议投稿？”
  • “刷新你上季度给我建的 DevRel 雷达。”
  • “在开发者关系领域我应该关注谁，他们在卖什么？”

Failure modes

失败模式

  • Inventing a source. DevRel's canon is small, so a plausible-sounding show or newsletter that doesn't exist is easy to produce and instantly destroys trust in the rest of the list. Every entry traces to a fetched page or is labelled unverified.
  • Passing a URL verdict off as an entity verdict. A resold domain that still resolves, a parked personal page, an NXDOMAIN on a guessed domain - all one mistake, covered by check 7 of the freshness and ownership check. Re-run it rather than reasoning from the URL.
  • Right date, wrong owner. A conference whose organiser changed passes any freshness check while the attribution is wrong. Check both.
  • Forcing a staleness verdict on an evergreen reference. A framework or maintainer handbook has no cadence to be stale against.
  • Quoting a benchmark without its edition and date. Ecosystem surveys are annual; a bare statistic ages invisibly and gets repeated in a leadership deck.
  • An ecosystem-only list. Following only your technology's sources leaves the practice itself unlearned.
  • Filtering out everyone with something to sell. That empties this field's list; disclose the incentive per entry instead.
  • Over-stuffing past the budget. Cut to fit and use the bench.
  • A flat list. Twelve equal-looking sources get picked by taste, or by whichever sits first. Order by value per attention-minute and say the ordering out loud.
  • Ranking by cheapness. Cheap and efficient are different orderings, and only the second one answers "what do I read first". A five-minute newsletter that buys five minutes of headlines is a rounding error, not a quick win.
  • A budget filled purely by ratio. It buys no podcasts, no talks, no conferences and no community - everything long-form loses every round - and leaves the user current on everything and understanding nothing. Check step 8's promotion conditions before finalising.
  • Amortising a conference across 52 weeks. That arithmetic ranks a three-day trip above a newsletter. The user pays it as cleared days, so it stays off the efficiency line.
  • Demoting a ruled-out source instead of deleting it. A paid community the user can't expense, parked at the bottom, reappears as scope at the next refresh. Delete it and name the deletion.
  • Pricing attention in money. The axis is the user's attention and cleared days. A source their employer already pays for costs them nothing extra - that belongs in the step 10 re-rank, not in the ranking itself.
  • 发明来源。 DevRel 的经典资源池很小，所以一个听起来合理但不存在的节目或通讯很容易被生产出来，并立刻摧毁对列表其余部分的信任。每条都能追溯到抓取页面，或被标记为未验证。
  • 把 URL 判定当作实体判定。 一个仍能解析但已被转售的域名、一个停放的个人页面、一个猜测域名的 NXDOMAIN——都是同一个错误，由新鲜度与所有权检查的第7条覆盖。重跑它，而不是从 URL 推理。
  • 日期对、所有者错。 一个组织者已更换的会议能通过任何新鲜度检查，但归属是错的。两者都要检查。
  • 把过期判定强加于常青参考资料。 框架或维护者手册没有可供过期的频率。
  • 引用基准数据却不带版本和日期。 生态调查是年度性的；一个赤裸裸的统计数字会无形老化，并被重复进领导层汇报材料。
  • 只关注生态的列表。 只关注自己技术生态的来源，会让实践本身得不到学习。
  • 把所有有东西要卖的人都过滤掉。 那会清空该领域的列表；改为逐条披露激励。
  • 超出预算塞满。 削减到合适，并使用候补席。
  • 扁平列表。 十二个看起来同等的来源会按口味、或按谁排最前来选择。按每注意力分钟价值排序，并把排序大声说出来。
  • 按便宜程度排序。 便宜和高效是不同排序，只有第二个回答“我先读什么”。一份五分钟的通讯买到五分钟的头条，是舍入误差，不是速胜。
  • 完全按比率填满预算。 它不购买播客、演讲、会议和社区——一切长形式每轮都输——让用户对一切了如指掌却什么都不理解。定稿前检查第8步的提升条件。
  • 把会议摊到52周。 那个算术让三天行程排到通讯前面。用户以清空的天数支付它，所以它保持在效率线之外。
  • 把被排除来源降级而不是删除。 用户无法报销的付费社区沉在底部，会在下次刷新时作为范围重新出现。删除它并点名删除。
  • 用金钱给注意力定价。 轴是用户的注意力和清空的天数。雇主已经付费的来源对他们没有额外成本——这属于第10步的重新排序，而不是排序本身。

Measurement

衡量

At delivery, the pass bar is:
  1. Every pillar the user owns has at least one verified-active source, and no pillar they don't own is padded in - absolute.
  2. Total estimated weekly minutes at or under the budget - the budget is the user's; the per-medium magnitudes behind the total are this skill's self-set defaults, and the minutes exist only for this arithmetic.
  3. Every entry carries a what-they're-selling flag and a status + date - absolute.
  4. Every entry traces to a fetched page or is explicitly labelled unverified with its reason - absolute; zero invented sources, zero unverified entries presented as verified.
  5. Every section is ordered by value per attention-minute, the ordering is stated rather than implied, and every re-rank away from the default names the fact that moved it.
  6. Every source the user's constraints ruled out was deleted and named as dropped, not parked at the bottom - and the list is not long-form-free: if it contains no podcast, talk, community or conference, step 8's promotion conditions were checked and the reason for skipping them is stated.
At each quarterly refresh, additionally check that the user consumed at least two-thirds of the entries and that no listed source changed owner without the entry being updated. If any check fails, revise - re-verify, trim, or swap from the bench - and re-present until all pass.
These numeric baselines are all self-set, chosen because a list the user does not finish is a list they will abandon:
  • The ~60-minute compressor threshold.
  • The per-medium minute conversions.
  • The ~90/10 split and 2-3-entry bench.
  • The two-thirds consumption rate.
  • The quarterly cadence.
Move them if the user's own consumption data disagrees. Moving them never moves the ordering: the ranking is built on orders of magnitude, and the minutes only decide where the list stops.
交付时，通过标准是：
  1. 用户拥有的每个支柱至少有一个已验证活跃来源，且没有用户不拥有的支柱被塞入——绝对。
  2. 估计的每周分钟总数低于或等于预算——预算是用户的；总数背后的每媒介数值是本技能自设默认值，分钟只用于这个算术。
  3. 每条都带“他们在卖什么”标记和状态 + 日期——绝对。
  4. 每条都追溯到抓取页面，或明确标记为未验证并说明原因——绝对；零发明来源，零未验证条目被呈现为已验证。
  5. 每节都按每注意力分钟价值排序，排序被说明而不是暗示，且每次偏离默认的重新排序都指明移动它的事实。
  6. 每个因用户约束被排除的来源都被删除并按“已删除”命名，而不是沉在底部——而且列表不是无长形式：如果它不包含任何播客、演讲、社区或会议，则已检查第8步的提升条件，并说明跳过它们的原因。
在每次季度刷新时，额外检查用户至少消费了三分之二条目，且没有列出的来源在条目未更新的情况下更换了所有者。如果任何检查失败，就修订——重新验证、修剪或从候补席替换——并重新呈现，直到全部通过。
这些数值基线都是自设的，选择它们的理由是：用户看不完的列表，就是他们会放弃的列表：
  • 约60分钟的压缩器阈值。
  • 每种媒介的分钟转换。
  • 约90/10分配和2-3条候补席。
  • 三分之二消费率。
  • 季度节奏。
如果用户自己的消费数据不同意，就调整它们。调整它们永远不会调整排序：排序基于数量级，分钟只决定列表在哪里停止。

References

参考

  • ./references/sources.md - the categorised, date-stamped source list (practice hubs, podcasts, newsletters and media, communities, events, data and benchmarks), plus the entries rejected as dead or resold.
  • ./references/people-to-follow.md - practitioners with their verifying surface, selling flag and cross-surface recurrence.
  • ./references/watch-list-example.md - one worked watch list and a negative example.
  • See samber/developer-relations-skills@developer-relations-kickoff to route a task across this collection.
  • See samber/developer-relations-skills@devrel-career for landing and growing a DevRel role; this skill only curates what to read, watch and attend.
  • See samber/developer-relations-skills@devrel-metrics when the data sources here get used to build a measurement framework.
  • See also samber/dev-event-organizer-skills for running an event, once the calendar here identifies one worth hosting.
  • ./references/sources.md - 分类和日期戳记的来源列表（实践中心、播客、新闻通讯和媒体、社区、活动、数据和基准），以及被拒绝为已死或已转售的条目。
  • ./references/people-to-follow.md - 从业者及其验证表面、售卖标记和跨平台重复出现。
  • ./references/watch-list-example.md - 一个完整的关注列表示例和一个负面示例。
  • 参见 samber/developer-relations-skills@developer-relations-kickoff 将任务路由到该集合。
  • 参见 samber/developer-relations-skills@devrel-career 获得 DevRel 岗位的入职和成长；本技能只策展读什么、看什么、参加什么。
  • 当这里的数据来源被用来构建衡量框架时，参见 samber/developer-relations-skills@devrel-metrics。
  • 另参见 samber/dev-event-organizer-skills 来运营活动，一旦这里的日历识别出值得主办的活动。