我的🔥首次参加 TC39 的经历

几周前，我有幸首次参加了 TC39，即定义 ECMAScript 规范的 ECMA 技术委员会。作为初次参加者，这次体验与我的预期有所不同，我想分享一下参加的感受。我想和大家分享这段经历 💖

TC39 到底是什么

TC39 是ECMA International旗下的一个技术委员会（简称 TC），负责定义 ECMAScript 标准（也就是 JavaScript）。FreeCodeCamp上有一篇很棒的文章，概述了两者之间的区别。

tl;dr：TC39 构建了浏览器引擎实现的规范，允许您运行 JavaScript。

术语

我想建立一个简短的术语列表，因为会议中有很多常用词汇。试图解读这些术语，同时又能跟上讨论的节奏，这对我来说是一个挑战。开会之前，我完全不懂这些术语。三天后，我终于明白了。在本文的其余部分，我会用到其中一些术语——我想把它们放在前面，以便大家参考。

• 提案：提案是对 ECMAScript 的建议补充。例如，import()和都是提案。您可以在 GitHub 上BigInt找到完整的提案列表。
• 阶段：TC39 用于推进提案的机制。我认为这是一种共识机制，尽管其他人可能不同意。您可以在流程文档中找到完整的阶段流程。
• 全体会议：会议中讨论提案的部分。实际上，每个人都在会议室里讨论提案。
• 规范性：通常在“规范性变更”的语境中提及，当某些内容是规范性变更时，它指的是规范中未正确反映的要求。“规范性变更”是指旨在解决此类问题的变更。基本上，它们是规范中的错误。更多背景信息，请参阅@allenwb对本文的评论！
• 代表：代表 ECMA International 会员（会员为法人实体）的个人。
• 特邀专家：受秘书处（目前由Istvan Sebestyen担任——您可以在此处查看职位描述）或 TC39 成员（据我所知？）邀请的领域专家。他们本身不属于代表。

期望与现实

我的期望是什么？

在全体会议上，我预料到对计算机科学教育背景以及理解规范工作原理的门槛会非常高。这并非我的背景，所以我……对这种预期感到紧张。

作为这种期望的延伸，我确信我根本不可能为会议做出太多贡献——我希望观察会议以确定是否有一条途径可以让我做出有意义的贡献。

我的期望与现实如何？

事实上，技术门槛比我预期的要低得多。有很多东西我不明白，但这似乎主要源于我不熟悉规范以及某些部分的工作原理——与其说是“你不是计算机科学背景”，不如说是“你不熟悉这个特定的环境”。我知道我可以理解环境，但我觉得自己不可能凭借计算机科学学位就完全理解。

这并不是说计算机科学背景没用（它绝对有用），但我不会因为没有计算机科学背景而感到被冷落。其他技能可以完成很多工作。技术写作、评审、贡献者入职培训，甚至作为任何级别的 JavaScript 开发人员的经验，都是在 GitHub 会议和工作中受到重视的特质。

此外，令我惊讶的是，除了技术贡献之外，还有多种途径可以做出非平凡的贡献。就像任何优秀的开源项目一样，TC39 似乎也重视非代码贡献。现在我意识到……我之前认为自己无法做出贡献的想法是多么愚蠢，因为 TC39 的绝大部分工作实际上与编写代码无关。当然，代码确实有编写（例如，参见Realms 提案，其中包含一个 shim、示例和其他一些代码），但大量的工作似乎都在编写文档、建立共识以及其他一些工作，以帮助阐明规范及其构建流程。

我非常高兴能够协助编写会议记录——三天里，每天大约写了二十几页。作为一名注意力缺陷多动症患者，能够通过打字记录我所听到的内容来跟上讨论（这对我来说更有助于我记忆信息），并且能够与一两个人一起，作为一个团队，将内容添加到会议记录中，这真是太棒了。此外，有几次我完全无法集中注意力在讨论上，这时我就能抽离出来，专注于其他事情。每个参与编写会议记录的人都非常友好，我觉得我的贡献非常有价值——这是我在第一次会议中完全没有想到的。

时间线

TC39 会议为期三天。我不确定通常的安排是怎样的，但这次会议是在周二、周三和周四。我猜他们故意把它安排在周中，这样代表们就可以在工作日出行参加会议，而不是强迫他们在周末出行。

让我们深入了解一下全体会议和计划活动每天的进展情况。

第一天：

• 全会：
  • 在我看来，这是一些样板启动演示（一些关于规范的指标报告）
  • 一些高水平的“规范性”演示
  • 一些无争议的提案正在分阶段推进
• 全体会议结束后，举行了首次聚会，由TC39 联合主席之一 Aki Rose Braun主持。
  • 我发现识别还有谁也是第一次参加会议很有帮助（来自 Netflix、IBM、GitHub 的几个人，当然还有来自微软的我自己）。
  • 这次聚会为我提供了一个可以解答绝大多数问题的空间！

第二天：

• 全会：
  • 关于更有实质内容/争议性的提案的讨论开始了。
    • 很多人告诉我第一天的情况就是这样。
    • 所讨论的提案均处于不同阶段 — — 1、2 和 3。
    • 我并没有想到每个提案的成熟度水平会有如此大的差异，但看到每个阶段的对话略有不同还是令人兴奋的。
    • 这次经历最大的收获之一是，某些类型的问题只会在特定阶段出现，而有些问题可以被忽略，直到提案达到特定阶段。
    • 有一两次讨论进入了加班阶段，之后我们又分配了额外的时间，以便我们能够继续处理其他提案。
• 最后，TC39 全体与会会员（以及受邀专家）共进晚餐。

第三天：

• 全会：
  • 结构几乎与第二天相同。
  • 我在这次会议上注意到的主要区别是——不确定这是否是标准做法——那些通常会引起更广泛的 JavaScript 生态系统广泛关注的功能的提案是在第 3 天提出的，而那些不太受关注的功能则在第 3 天提出。
• 以Myles Borins组织的现代 JavaScript：/runtimes/聚会结束。

在这些日子里，有一些事情是不变的：

• 场地每天提供早餐和午餐。
• 午餐时间大约为一小时，全天有几次 5-15 分钟的休息时间。
• 包括我自己在内的一些人经常会请假去参加会议或完成日常工作。有很多空间可以做这些事情，而且完全不会受到歧视。
• 每天晚上，不管是否有正式的计划，总有一些与会者会一起出去吃晚饭。

完全出乎我意料的是走廊的布置——午餐、休息以及我参加的晚宴上，我和许多从未谋面的人进行了精彩的讨论。每个人都异常热情友好——或许是因为我是第一次参加，所以更加如此。

还值得注意的是，感谢Myles Borins和纽约 JavaScript Google 员工，本次会议在 Google 纽约办公室隆重举办。

总结

尽管我来的时候并没有抱什么期望，但整个经历却打破了我原先认为的模式。

与我交流的每一位代表都对新参与者给予了极大的鼓励，他们完全遵循了我所期望的开源项目的结构和实践——这与我之前设想的标准机构的普遍运作方式截然不同。我独特的个人背景得到了重视。他们热情地欢迎我，并温和地鼓励我以任何我感到舒适的方式做出贡献。我最终从事的非技术性工作——文档编写、新成员入职培训和环境构建——正是该小组希望更多地开展的工作。

每天都会以各种方式被提及的话题之一是与更广泛的 JavaScript 社区互动——这与其说是一个问题，不如说是一种价值观。尽管我对标准机构的假设受到了一些已经完成的鼓励新代表及其参与的工作的挑战，但我非常高兴地看到，代表 TC39 成员的个人也非常重视这一点，并且更多地将其视为一种核心价值观，而不是像我想象的那样，只是“我们应该做的事情”。

总的来说，这次经历与我以往在技术和社区方面所做的任何事都不同。我很有信心继续以代表的身份参与其中，并看看自己如何为流程、社区以及规范本身做出有意义的贡献。