摘要

  • 2026 年 8 月 12 日的征求建议书准备把一天的线下新参与者课程改造成可独立使用的短视频模块，明确不需要直播主持、固定班级或同步环节。公开采购表目前仍显示项目开放，不能据此声称已有中标方、成品或学习效果。
  • 文件同时要求所有内容使用英语，并要求采用公认的无障碍做法、提供字幕以及在可行时提供文稿。字幕让口语英语更容易辨认和检索，却不会自动生成另一种语言，也不能证明制度含义已被理解。
  • RFC 7154 把英语称为 IETF 事实上的语言，同时提醒参与者许多人并非英语母语者。共同工作语言能降低规范协商成本，但不会自动提供术语解释、情境辅导、工作组导航和意见反馈。
  • 可以建立一份保护隐私的“接入与进展凭据”：分别记录模块版本、语言、格式、修订、可选的人类转接、贡献及其处置。没有同意或无法可靠关联的数据必须保持未知；播放、学完、发帖和提交草案都不能被写成共识或授权。

采购文件真正拆掉的是日程依赖

IETF 新参与者在线培训征求建议书没有把入门描述成一次简单的产品教学。它承认，理解标准制定流程并掌握有效参与所需的技能，可能需要数月乃至数年。项目希望把原来一天的现场课程内容改造成在线课程，而不是声称用几段视频消灭这段学习时间。

规定的主题包括为什么参与、IETF 是什么、怎样参与、标准如何形成、Hackathon 的作用、Internet-Draft 和 RFC。各大部分既要组成连贯路径，也要能够独立取用；适合拆开的长讲座可以变成一组短视频。这种模块化对一个长期运行的机构尤其重要，因为新人很少按照课程设计者预想的顺序遇到问题。

更重要的要求是，课程不得依赖任何同步条件。没有讲师必须同时在线，没有一批学习者必须共同开课，也没有某个日期之前错过就只能再等一轮。北京的运维人员可以在故障窗口结束后学习；圣保罗的工程师不必为欧洲白天调整睡眠；只想读懂一份 RFC 的实现者可以直接查看相应模块，而不必假装要参加整套社群活动。

这并非象征性改进。它把基础知识的供应从会议旅行、主持人档期和时区重叠中分离出来。录播还能重复、搜索和回看：一个人在第一次看到 “Last Call” 时可能只有模糊印象，数月后真正进入流程时可以再次打开对应说明。

但是，采购日程不能被写成已经交付的事实。IETF 的 RFP 与合同页面目前仍把该项目列为开放。文件列出的节点是 8 月 26 日前提交问题、9 月 1 日公布答复或更新版本、9 月 11 日提交方案、9 月 21 日选择优先投标者、9 月 28 日预计签约。这些日期只证明机构的预定程序，不证明谁会承制、最终合同保留哪些条款、何时上线，更不证明新人会因此有效参与。

字幕解决辨认问题，不能替代语言转换

征求建议书对无障碍并不敷衍。它要求遵循 WCAG 2.1 AA 或同等的公认实践，要求封闭字幕，并在可行时提供文稿。交付物还包括可编辑的源视频、脚本、幻灯片、测验内容和模板。单个模块应能随工具与流程变化而单独更新，成果所有权归 IETF LLC，并应避免让后续维护被特定供应商或专有格式锁住。

这些要求分别处理真实风险。听不清的专有名词可以从字幕确认；文稿可以全文搜索；某一步骤失效时，可编辑源文件让团队不必重拍整门课；所有权和可移植性使更换维护者成为可能；独立更新则缩小修订范围。

但“所有材料使用英语”也是明确要求。英语字幕仍然是英语，英语文稿也仍然携带英语的句法和机构习惯。它们可以让学习者放慢阅读、复制术语去查词，却不会把 adoption、rough consensus、stream 或 Area Director 背后的制度关系自然解释成中文、阿拉伯语或日语。更不能因为一个人看完字幕，就断言其理解了“采纳为工作起点”与“最终批准标准”之间的差别。

这不是指控 IETF 违反自己的规则。RFC 7154明确说英语是 IETF 事实上的语言，同时要求大家记得，现场很多人并非英语母语者。全球标准机构需要一块共同、可核对的协商表面，尤其是规范性措辞不能因为看似相近的翻译而产生两种约束。

正因为共同语言有其合理功能，接入层才更需要准确记录边界。英语课程可以如实解释一个以英语工作的流程；它没有因此证明所有人获得了同样的理解条件。部分新人要同时学习机构地图与表达这张地图的语言快捷方式。只记录“已打开”或“已完成”，会把两种认知负担一起抹掉。

一张地图不会替新人选择入口

IETF 的入门页面并未设计唯一的参与路线。想阅读或实现 RFC、加入既有工作、带来新议题、参加会议、从邮件列表开始的人，会看到不同指引。更宽泛的参与页面则把日常工作放在 Working Group、列表、文档和实现经验之中。

因此，培训处于若干选择之前。知道什么是 Working Group，不等于知道自己的问题属于哪个组；找到组页，不等于知道应该发到列表、问题跟踪器、Internet-Draft 审阅，还是先私下请人澄清背景；有价值的技术反例，也可能因为提交时间、上下文或用词不合适而没有被正确辨认。

这些摩擦不全是应当清除的障碍，其中一些是权限边界。完成测验不赋予提案被接纳的权利。视频制作商不能认证 rough consensus。IETF LLC 可以采购行政教育服务，却不会因此取得某个工作组对文档的技术权力。主席也不能把课程完成率当作支持某个方案的人数。

边界同样要保护表达较慢的人。英语不流利并不会降低技术证据的质量。RFC 7282强调发现并处理技术异议，而不是简单数手或追求无人出声。异议的工程内容与表达者是否熟悉主流语气，必须分开评价。

至少可以区分六个状态：

  1. 内容已经公开存在；
  2. 学习者能够使用其所需格式；
  3. 学习者愿意报告说明是否可理解；
  4. 学习者找到适当的人或工作渠道；
  5. 一项贡献进入该渠道并得到可归属的处置；
  6. 相关群体依照自身程序形成可以声称的共识。

任何一项都不会自动证明下一项。只想实现现有 RFC 的人可能停在第二项。有人会在几年后才贡献。有人通过文档和同事就能有效参与，从未打开课程。也有人完成所有模块后决定不进入讨论，这同样是正当选择。

录播拿走的现场问答，需要一个可见出口

“不需要现场引导”使产品容易扩展，也刻意拿掉了一个功能：学习者不能当场追问“这句话是不是已经关闭议题”或“我的问题到底应该去哪条列表”。答案不应是暗中把强制网络研讨会塞回课程，而应是让可选的人类转接变得明显。

现有的 IETF Guides Program承担另一类工作。它由有经验的参与者向新人提供建议、辅导和实践知识，申请时可以填写偏好语言。这个关系依赖志愿者，通常与会议参与相关，也受个人时间限制，不能被包装成面向全球、无限容量的服务保证。

课程与 Guide 恰好因为不同才可能互补。课程提供稳定的共同底稿；Guide 解读具体情境、介绍联系人、说明未写进流程图的惯例；公开列表让技术主张接受挑战；工作组主席管理讨论秩序。任何一方都不应吞并其他角色。Guide 不能替工作组批准提案，课程也不能替 Guide 判断某位新人的具体困难。

IETF 126 会后调查提到，在作答的新参与者中有 36% 不知道 Guides Program。这个数字必须带着范围使用：分母是调查受访者，不是所有新注册者，也不能告诉我们“不知道”的原因。它仍揭示了一件事——网页上存在链接，不等于转接真正完成。

每个模块结束时可以提供多个自愿出口：申请 Guide、查看工作组说明、加入列表、练习 Datatracker，或者到此为止。学习者作出选择。系统最多可以确认所选目的地已经提供；除非有另一份经过同意的证据，否则不能声称对方已经加入、理解或获得成功。

用“接入与进展凭据”代替学习者画像

IETF LLC 不需要为新人建立持续监控档案。它需要的是一份结构小、语义窄的凭据，使容易获取的指标不能冒充完整参与过程。

内容层可以记录模块标识、权威源版本、发布日期、替代日期、语言、字幕与文稿格式、低带宽选项、无障碍审查依据、术语表和修订历史。英语源发生变化时，每个衍生版本都应表明已经对齐、仍在旧版，还是因为什么原因暂时未知。

转接层只记录经过选择的动作：请求 Guide、打开工作组页、获取列表订阅地址或不继续。系统可以写“目的地已送达”，不能偷偷扩写成“已经参加”“已经理解”“已经融入”。后面的陈述需要独立、窄范围且得到同意的证据。

汇总层可能需要模块开始数、完成数、字幕启用、文稿访问、Guide 转介、首次公开发言或首次审阅。每个数字都必须带分母、观察期和系统关联限制。第一条公开消息是贡献事件，不是正确性证明；Internet-Draft 是提交审阅的工作，不是被采纳的证书；持续参与不是共识，共识也不代表所有受协议影响的人授权。

空值尤其重要。若分析功能被关闭、学习者拒绝回答，或两个系统无法可靠连接，结果就是未知。把未知填成零，会惩罚选择隐私的人；把未知填成成功，则把服务可用性变成宣传材料。

公开评估不需要保留口音、私人提问、未提交草稿、雇主、国籍或推测出的英语水平。真正值得公开的是接入系统本身的表现：某个版本是否存在、有哪些格式和语言、提供何种可选交接、保存多久、怎样纠错。

可编辑文件还应带走可验证的含义

源文件和反锁定条款是这份采购文件的强项。关于一个不断变化机构的课程不能被困在供应商播放器或无法打开的工程文件中。YouTube、IETF 网站、Cloudflare Stream 或其他有理由的方案都可能合适，前提是内容权威不会随运营者更换而消失。

可移植的不只应是像素。Last Call、adoption、consensus、stream、Area Director 和 liaison 都在描述制度关系。未来的另一语言版本即使句子流畅，只要改变了其中一个关系，也会给新人一张制作精良的错误地图。

因此，权威英语模块应附带版本化术语与决策关系图。后续版本可以声明自己对应哪一个源哈希、由谁核查机构含义、哪些词保留英语以及修正如何传播。这不要求第一天就交付所有语言，而是避免未来的语言改进成为找不到源头的孤本。

同样，英语本身也会过时。工具会迁移，角色会调整，流程会修订。模块可独立更新只解决制作成本；公开的替代关系才让读者知道某段曾经正确的解释已经失效。

清楚承认课程止步在哪里

这项采购最有力的理由很朴素：把稀缺讲师反复讲解的时间变成持久资源，让不同地区的人按自己的节奏接触基础知识；保存可编辑源，提供无障碍格式，尽量少收数据，并由熟悉 IETF 的人员审查技术内容。

它的限制也很朴素。录播看不见学习者正在形成的问题，不知道一个习语是否遮住了规则，不知道对方是否找到了正确工作组，也不知道第一封没有回复的邮件是否让潜在贡献者离开。英语字幕减轻一个困难，并不等于全部入口已经平等。

治理上的答案不是简单宣布课程“包容”或“不包容”，而是把责任分配清楚。发布者证明可用性；格式和审查证明无障碍状态；理解只能由学习者自愿报告；辅导属于具体的人际关系；贡献属于作者；处置属于接收论坛；共识属于检验技术异议的程序。

这些状态保持分离，在线入门培训就能在不制造结果的前提下扩大入口。它取消的是时钟限制，并诚实留下语言边界。下一步无论是增加术语支持、其他语言版本还是更可靠的人类交接，都将建立在可核查事实之上，而不是建立在一条把“完成”误写成“已经有声音”的进度条上。

来源

  1. IETF New Participants Online Training 征求建议书
  2. IETF RFP 与合同
  3. RFC 7154 — IETF Guidelines for Conduct
  4. IETF Guides Program
  5. IETF 会议新参与者页面
  6. 参与 IETF
  7. IETF 入门指引
  8. 新参与者计划：回顾 IETF 122、展望 IETF 123
  9. IETF 126 会后调查
  10. RFC 7282 — On Consensus and Humming in the IETF