在 2025 年初，Electron 的 npm 生态系统仓库（在 @electron/ 和 @electron-forge/ 命名空间下）将把 Node.js 22 作为最低支持版本。

这意味着什么？​

过去，Electron npm 生态系统（Forge、Packager 等）中的软件包尽可能长时间地支持 Node 版本，即使在版本达到其生命周期结束 (EOL) 日期之后也是如此。这样做是为了确保我们不会使生态系统碎片化——我们理解许多项目依赖于旧版本的 Node，我们不想冒险让这些项目陷入困境，除非有迫切的升级理由。

随着时间的推移，由于以下几个原因，使用 Node.js 14 作为最低版本变得越来越困难

• 缺乏官方的 Node.js 14 macOS ARM64 构建，这需要我们维护 CI 基础设施的解决方法以提供完整的测试覆盖率。
• 上游软件包依赖项的 engines 要求已经向前发展，使得解决依赖项升级的供应链安全问题变得越来越困难。

此外，较新版本的 Node.js 包含了许多我们想要利用的改进，例如运行时原生的常用实用程序（例如 fs.glob 和 util.parseArgs）以及全新的内置模块（例如 node:test、node:sqlite）。

为什么要现在升级？​

在 2024 年 7 月，Electron 的生态系统工作组决定将所有软件包升级到支持同步 ESM 图的 require() 的最早 Node 版本（请参阅 nodejs/node#51977 和 nodejs/node#53500），在该版本达到其 LTS 日期之后的未来某个时间点。

我们已决定将该更新时间设置为 2025 年 1 月/2 月。在此升级发生后，Node 22 将是现有生态系统软件包中支持的最低版本。

我需要采取什么措施？​

我们将尽力保持尽可能多的兼容性。但是，为了确保最佳支持，我们鼓励您将您的应用升级到 Node 22 或更高版本。

请注意，您的项目中运行的 Node 版本与嵌入到当前 Electron 版本中的 Node 版本无关。

下一步是什么​

如果您有任何问题或疑虑，请随时通过 [email protected] 写信给我们。您还可以在我们的官方 Electron Discord 中找到社区支持。

BrowserView 自 Electron 30 以来已被弃用，并由 WebContentView 取代。值得庆幸的是，迁移相当简单。

Electron 正在从 BrowserView 迁移到 WebContentsView，以与 Chromium 的 UI 框架 Views API 对齐。WebContentsView 提供了一个可重用的视图，直接与 Chromium 的渲染管道相关联，简化了未来的升级，并为开发人员提供了将非 Web UI 元素集成到其 Electron 应用的可能性。通过采用 WebContentsView，应用程序不仅为即将到来的更新做好了准备，而且从长远来看，还可以受益于降低的代码复杂性和更少的潜在错误。

熟悉 BrowserWindow 和 BrowserView 的开发人员应该注意，BrowserWindow 和 WebContentsView 分别是继承自 BaseWindow 和 View 基类的子类。要完全理解可用的实例变量和方法，请务必查阅这些基类的文档。

迁移步骤​

1. 将 Electron 升级到 30.0.0 或更高版本​

2. 熟悉你的应用程序在哪里使用 BrowserView​

一种方法是在你的代码库中搜索 new BrowserView(。这将让你了解你的应用程序如何使用 BrowserView 以及有多少调用点需要迁移。

3. 迁移 BrowserView 的每个用法​

1. 迁移实例化。这应该相当简单，因为 WebContentsView 和 BrowserView 的构造函数本质上具有相同的形状。两者都通过 webPreferences 参数接受 WebPreferences。

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   
   信息

   默认情况下，WebContentsView 实例化时具有白色背景，而 BrowserView 实例化时具有透明背景。 要在 WebContentsView 中获得透明背景，请将其背景颜色设置为一个 RGBA 十六进制值，并将 alpha（不透明度）通道设置为 00。

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. 迁移将 BrowserView 添加到其父窗口的位置。

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. 迁移父窗口上 BrowserView 实例方法调用。

   旧方法	新方法	注释
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	对现有视图调用 addChildView 会将其重新排序到顶部。
   win.getBrowserViews	win.contentView.children

4. 将 setAutoResize 实例方法迁移到调整大小侦听器。

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   
   提示

   所有现有的 browserView.webContents 以及实例方法 browserView.setBounds，browserView.getBounds 和 browserView.setBackgroundColor 的用法都不需要迁移，并且应该可以直接与 WebContentsView 实例一起使用！

4. 测试并提交你的更改​

遇到问题？请查看 Electron 的问题跟踪器上的 WebContentsView 标签，以查看你遇到的问题是否已被报告。如果你没有在那里看到你的问题，请随时添加新的错误报告。包含测试用例 gist 将有助于我们更好地处理你的问题！

恭喜，你已迁移到 WebContentsViews！🎉

Electron API 的历史更改现在将在文档中详细说明。

你好 👋，我是 Peter，2024 年 Electron 的 Google Summer of Code (GSoC) 贡献者。

在 GSoC 项目期间，我为 Electron 文档及其函数、类等实现了 API 历史功能，其方式与 Node.js 文档类似：通过允许在 API 文档 Markdown 文件中使用简单但功能强大的 YAML 模式，并在 Electron 文档网站上漂亮地显示它。

我们很高兴地宣布，Electron 已被接受为 2024 年 Google Summer of Code (GSoC) 第二十届的指导组织！Google Summer of Code 是一项全球性计划，旨在将新的贡献者引入开源软件开发。

有关更多项目详细信息，请查看 Google 的 Summer of Code 首页。

关于我们​

Electron 是一个 JavaScript 框架，用于使用 Web 技术构建跨平台桌面应用程序。Electron 核心框架是一个使用 Chromium 和 Node.js 构建的编译二进制可执行文件，并且主要用 C++ 编写。

在 Electron 核心之外，我们还致力于各种项目，以帮助维持 Electron 组织，例如

• 最终用户分发工具（例如 Electron Forge 和 update.electronjs.org）。
• Electron 开发人员的学习材料（例如 electronjs.org 和 Electron Fiddle）。
• 简化开发人员生产力的内部工具（例如 Electron Build Tools 和 Sheriff）。

作为 Summer of Code 的贡献者，你将与 Electron 的一些核心贡献者合作，参与 github.com/electron 伞下的众多项目之一。

申请之前​

如果你不太熟悉 Electron，我们建议你首先阅读文档并在 Electron Fiddle 中尝试示例。

要了解有关 Electron 应用程序分发的更多信息，你还可以通过创建示例应用程序来试用 Electron Forge

npm init electron-app@latest my-app

在稍微熟悉代码后，请加入 Electron Discord 服务器上的对话。

起草你的提案​

有兴趣与 Electron 合作吗？首先，请查看我们准备的七个项目想法草案。 所有列出的想法目前都开放征集提案。

你是否有不同的想法想让我们考虑？我们也愿意接受不在拟议项目列表中的新想法，但请确保你的方法已彻底概述和详细说明。如有疑问，我们建议坚持我们列出的想法。

你的申请应包括

• 你的提案：一份书面文件，详细描述你计划在整个夏季实现的目标。
• 你作为开发人员的背景。如果你有简历，请附上副本。否则，请告诉我们你过去的专业技术经验。
  • 在某些领域缺乏经验不会取消你的资格，但这将有助于我们的导师制定最佳支持你的计划，并确保你的夏季项目成功。

此处提供了有关提交 Electron 应用程序的一部分的详细指南。 将提案直接提交到 Google Summer of Code 门户。请注意，发送给 Electron 团队的提案而不是通过申请门户提交的提案将不被视为最终提交。

如果你想获得有关你的提案的更多指导，或者不确定要包含什么，我们还建议你遵循 此处官方的 Google Summer of Code 提案撰写建议。

申请于 2024 年 3 月 18 日开始，并于 2024 年 4 月 2 日结束。

问题？​

如果你有我们在博文中没有解决的问题或针对你的提案草案的疑问，请发送电子邮件至 [email protected]，或查看 GSoC 常见问题解答！

资源​

• Electron Google Summer of Code 2024 项目想法列表
• Electron Google Summer of Code 2024 贡献者指南
• Google Summer of Code 学生/贡献者指南

Electron 的 API 工作组正在采用开放的 请求评论 (RFC) 流程，以帮助引导对 Electron 核心的更大更改。

为什么需要 RFC？​

简而言之，我们希望简化对 Electron 核心进行重大更改的过程。

目前，新的代码更改主要通过 GitHub 上的问题和拉取请求进行讨论。对于 Electron 的大多数更改，这是一个很好的系统。许多错误修复、文档更改，甚至新功能都足够简单，可以通过标准的 GitHub 流程异步审查和合并。

对于更重大的更改——例如，大型 API 表面或会影响大多数 Electron 应用的重大更改——在编写大部分代码之前，在构思阶段进行审查是有意义的。

此过程旨在向公众开放，这也将使整个开源社区更容易在这些更改进入 Electron 之前提供反馈。

它是如何运作的？​

整个 RFC 流程都位于 GitHub 上的 electron/rfcs 存储库中。该步骤在存储库的 README 中详细描述。

简而言之，一旦向 electron/rfcs 存储库提交 PR，则 RFC 即为已提议。当提议的 RFC 变为

• 活动时，PR 被合并到存储库的 main 分支中，这意味着 Electron 维护者赞成在 electron/electron 中实现，或者
• 如果 PR 最终被拒绝，则为已拒绝。

如果实现已合并到 electron/electron 中，则活动的 RFC 为已完成。

谁可以参与？​

Electron 社区中的任何人都可以提交 RFC 或在 electron/rfcs 存储库中留下反馈！

• 要查看活动 RFC 的列表，请参阅存储库中的 text 文件夹。
• 要对提议的 RFC 留下反馈，请查看 打开的 PR 列表。
• 要提交新的 RFC，请查看存储库的 README 和 RFC 模板。

我们希望使这个过程成为双向对话，并鼓励社区参与，以便从未来可能使用这些 API 的 Electron 应用中获得各种意见。如果您有兴趣对当前提议的 RFC 留下反馈，Electron 维护者已经创建了一些

• Electron C API
• Service Workers 的预加载领域

鸣谢​

Electron 的 RFC 流程以许多已建立的开源 RFC 流程为模型。许多想法和大部分文案的灵感来自

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

对 electron/electron 存储库的首次提交是在 2013 年 3 月 13 日¹。

10 年后，来自 1192 位独特贡献者的 27,147 次提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的知识的绝佳机会。

如果没有每位奉献时间和精力为该项目做出贡献的人，我们今天就不会在这里。虽然源代码提交始终是最明显的贡献，但我们也必须承认那些报告错误、维护用户级模块、提供文档和翻译以及参与网络空间中 Electron 社区的人们的努力。作为维护者，每一项贡献对我们来说都非常宝贵。

在我们继续浏览博客文章的其余部分之前：谢谢。 ❤️

我们是如何走到这里的？​

Atom Shell 是作为 GitHub 的 Atom 编辑器 的支柱而构建的，该编辑器于 2014 年 4 月公开发布测试版。它从头开始构建，作为当时可用的基于 Web 的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代品。它有一个杀手级功能：嵌入 Node.js 和 Chromium，为 Web 技术提供强大的桌面运行时。

在一年内，Atom Shell 的功能和受欢迎程度都开始大幅增长。大型公司、初创公司和个人开发者都开始使用它构建应用程序（一些早期的采用者包括 Slack、GitKraken 和 WebTorrent），该项目被恰当地重命名为 Electron。

从那时起，Electron 就一帆风顺，从未停止过。以下是我们每周下载量的长期视图，由 npmtrends.com 提供

Electron v1 于 2016 年发布，承诺提高 API 稳定性和更好的文档和工具。Electron v2 于 2018 年发布，并引入了语义版本控制，使 Electron 开发人员更容易跟踪发布周期。

到 Electron v6，我们转向了与 Chromium 匹配的定期 12 周主要发布节奏。该决定改变了该项目的心态，将“拥有最新的 Chromium 版本”从一个锦上添花的功能提升为优先事项。这减少了升级之间的技术债务，使我们更容易保持 Electron 的更新和安全。

从那时起，我们就像一台运转良好的机器，在每个 Chromium 稳定版发布的同一天发布一个新的 Electron 版本。当 Chromium 在 2021 年将其发布计划加快到 4 周时，我们能够耸耸肩，并将我们的发布节奏相应地提高到 8 周。

我们现在使用的是 Electron v23（并且还在不断增加），并且仍然致力于构建用于构建跨平台桌面应用程序的最佳运行时。即使近年来 JavaScript 开发工具蓬勃发展，Electron 仍然是桌面应用程序框架领域中稳定、经过实战考验的坚定支持者。如今，Electron 应用程序无处不在：您可以使用 Visual Studio Code 进行编程，使用 Figma 进行设计，使用 Slack 进行通信，并使用 Notion 进行笔记（以及许多其他用例）。我们对这一成就感到无比自豪，并感谢每一位使其成为可能的人。

我们一路上学到了什么？​

通往十年里程碑的道路漫长而曲折。以下是一些有助于我们运行可持续大型开源项目的关键事项。

使用治理模型扩展分布式决策制定​

我们必须克服的一个挑战是如何在 Electron 首次流行后处理该项目的长期方向。我们如何处理由分布在公司、国家和时区的几十名工程师组成的团队？

在早期，Electron 的维护者小组依赖于非正式协调，这对于较小的项目来说速度快且轻便，但无法扩展到更广泛的协作。在 2019 年，我们转向了治理模型，其中不同的工作组拥有正式的责任领域。这对于简化流程和将项目所有权的一部分分配给特定的维护者至关重要。如今每个工作组 (WG) 负责什么？

• 发布 Electron 版本（发布 WG）
• 升级 Chromium 和 Node.js（升级 WG）
• 监督公共 API 设计（API WG）
• 保持 Electron 安全（安全 WG）
• 运行网站、文档和工具（生态系统 WG）
• 社区和企业外展（外展 WG）
• 社区审核（社区与安全 WG）
• 维护我们的构建基础架构、维护者工具和云服务（基础架构 WG）

在我们转向治理模型的同时，我们还将 Electron 的所有权从 GitHub 转移到了 OpenJS 基金会。虽然最初的核心团队今天仍然在微软工作，但他们只是组成 Electron 治理的更大的合作者群体的一部分。²

虽然此模型并非完美无缺，但它在经历全球大流行和持续的宏观经济逆风中很好地适应了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，特别是当您的外展团队是一群穿着印有“社区经理”字样的风衣的工程师时。也就是说，作为一个大型开源项目，意味着我们有很多用户，并且利用他们的能量来让 Electron 构建用户级生态系统是维持项目健康的关键部分。

我们一直在做什么来发展我们的社区形象？

构建虚拟社区​

• 在 2020 年，我们启动了社区 Discord 服务器。我们之前在 Atom 的论坛中有一个部分，但决定建立一个更非正式的消息传递平台，以便在维护者和 Electron 开发人员之间进行讨论，并获得一般调试帮助。
• 在 2021 年，我们在 @BlackHole1 的帮助下成立了 Electron 中国用户组。该小组在 Electron 在中国蓬勃发展的科技界用户增长方面发挥了重要作用，为他们提供了一个在我们的英语空间之外协作想法和讨论 Electron 的空间。我们还要感谢 cnpm 在其中国 npm 镜像中支持 Electron 的每日发布方面所做的工作。

参与高可见性的开源计划​

• 自 2019 年以来，我们每年都会庆祝 Hacktoberfest。Hacktoberfest 是由 DigitalOcean 组织的年度开源庆典，每年都有数十位热情的贡献者希望在开源软件领域留下自己的印记。
• 2020 年，我们参与了 Google Season of Docs 的首轮活动，与 @bandantonio 合作，重构了 Electron 的新用户教程流程。
• 2022 年，我们首次指导了一位 Google Summer of Code 学生。@aryanshridhar 完成了一些出色的工作，重构了 Electron Fiddle 的核心版本加载逻辑，并将其打包器迁移到了 webpack。

自动化一切！​

如今，Electron 管理团队约有 30 名活跃的维护者。其中只有不到一半的人是全职贡献者，这意味着有很多工作需要处理。我们保持一切顺利运转的诀窍是什么？我们的座右铭是：计算机很便宜，而人类时间很昂贵。以典型的工程师方式，我们开发了一套自动化的支持工具，使我们的生活更轻松。

Not Goma​

Electron 的核心代码库是一个 C++ 代码的庞然大物，构建时间一直是限制我们快速发布错误修复和新功能的因素。2020 年，我们部署了 Not Goma，这是 Google 的 Goma 分布式编译器服务的自定义 Electron 特定后端。Not Goma 处理来自授权用户机器的编译请求，并将该过程分布在后端数百个核心上。它还会缓存编译结果，以便其他编译相同文件的人只需要下载预编译的结果即可。

自 Not Goma 启动以来，维护人员的编译时间已从数小时缩短至数分钟。稳定的互联网连接成为贡献者编译 Electron 的最低要求！

持续双因素身份验证​

持续双因素身份验证 (CFA) 是 npm 双因素身份验证 (2FA) 系统周围的自动化层，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全和自动化发布。

虽然 semantic-release 已经自动化了 npm 包的发布过程，但它需要关闭双因素身份验证或传入一个绕过此限制的秘密令牌。

我们构建了 CFA，为 npm 2FA 提供基于时间的一次性密码 (TOTP) 到任意 CI 作业，这使我们能够利用 semantic-release 的自动化，同时保持双因素身份验证的额外安全性。

我们将 CFA 与 Slack 集成前端一起使用，允许维护人员从他们拥有 Slack 的任何设备上验证软件包发布，只要他们手头有 TOTP 生成器即可。

Sheriff​

Sheriff 是我们编写的开源工具，用于自动化跨 GitHub、Slack 和 Google Workspace 的权限管理。

Sheriff 的主要价值主张是，权限管理应该是一个透明的过程。它使用单个 YAML 配置文件来指定上述所有服务中的权限。有了 Sheriff，获得存储库的协作者身份或创建新的邮件列表就像获得 PR 批准并合并一样容易。

Sheriff 还有一个审计日志，会发布到 Slack，在 Electron 组织中任何地方发生可疑活动时警告管理员。

…以及我们所有的 GitHub 机器人​

GitHub 是一个具有丰富 API 可扩展性的平台和一个名为 Probot 的第一方机器人应用程序框架。为了帮助我们专注于工作中更具创造性的部分，我们构建了一套较小的机器人，帮助我们完成繁琐的工作。以下是一些示例

• Sudowoodo 从头到尾自动化 Electron 发布过程，从启动构建到将发布资产上传到 GitHub 和 npm。
• Trop 通过尝试根据 GitHub PR 标签将补丁 cherry-pick 到之前的发布分支来自动化 Electron 的反向移植过程。
• Roller 自动化 Electron 的 Chromium 和 Node.js 依赖项的滚动升级。
• Cation 是我们用于 electron/electron PR 的状态检查机器人。

总而言之，我们的小型机器人家族极大地提高了开发人员的生产力！

下一步是什么？​

当我们作为项目进入第二个十年时，您可能会问：Electron 的下一步是什么？

我们将与 Chromium 的发布节奏保持同步，每 8 周发布 Electron 的新主要版本，使该框架与 Web 平台和 Node.js 的最新和最强大的功能保持同步，同时保持企业级应用程序的稳定性和安全性。

我们通常在即将推出的举措变得具体时宣布相关新闻。如果您想了解未来的版本、功能和一般项目更新，您可以阅读我们的博客并关注我们的社交媒体个人资料（Twitter 和 Mastodon）！

Electron 团队很高兴地宣布，今年我们将首次参加 Google Summer of Code！

什么是 Google Summer of Code？​

Google Summer of Code (GSoC) 是一项年度指导计划，将开源软件项目与潜在的贡献者联系起来。以前仅对学生开放，现在任何 18 岁及以上的人都可以注册 GSoC。

有关更多信息，请查看Summer of Code 主页。

我如何注册？​

您是否有兴趣与 Electron 合作？如果您是新的或初级开源贡献者，我们欢迎您申请！

要被选为 Google Summer of Code 的 Electron 贡献者，您需要提交一份申请。申请将于 2022 年 4 月 4 日开放，并于 2022 年 4 月 19 日关闭。您可以在此处关注 Google: Summer of Code 申请指南的更新。

想申请吗？首先，查看我们准备的五个项目想法草案。所有列出的想法目前都开放征求建议。我们也愿意接受不在拟议项目列表中的新想法。

你的申请应包括

• 您的提案，这是一个书面文件，详细描述了您计划在夏季实现的目标。
• 您作为开发人员的背景。如果您有简历，请附上一份副本，否则请告诉我们您过去的经验，重点介绍相关的技术经验。

此处提供了作为 Electron 申请的一部分提交内容的详细指南。

您还可以阅读官方 GSoC 学生/贡献者指南，了解有关准备提案的重要提示。

如果您想讨论项目提案或有任何疑问，请加入我们的 #gsoc-general Discord 频道！

参考资料​

• Electron 提案指南
• Electron GitHub
• 项目想法文档
• Google Summer of Code 学生/贡献者指南

加入我们，参与社区联系和为期一个月的开源庆典。

Electron 社区 Discord 发布

Electron 的 外展工作组 很高兴地宣布推出我们的官方社区 Discord 服务器！

为什么要新建 Discord 服务器？​

在早期作为 Atom 文本编辑器 的支柱时，关于 Electron 框架的社区讨论仅在 Atom 的 Slack 工作区的一个频道中进行。随着时间的推移，这两个项目日益解耦，Atom 工作区与 Electron 项目的相关性降低，维护者参与 Slack 频道的程度也随之下降。

直到现在，我们仍然将更广泛的社区重定向到 Atom Slack 工作区，即使我们收到许多用户报告称难以收到邀请，并且我们核心维护者也很少光顾该频道。

我们正在建立这个全新的服务器，作为社区的中心讨论中心，您可以在这里获取关于 Electron 的所有最新消息。

快来加入吧！​

目前，服务器的成员由一些共同工作的维护者组成，他们正在设置服务器，但我们非常期待与大家聊天！欢迎来这里寻求帮助、了解 Electron 的最新版本，或者只是与其他开发人员一起闲聊。我们为您准备了一个方便的 邀请链接，让您能够访问服务器！

2020 年 Hacktoberfest

作为一个大型且长期运行的开源项目，如果没有社区的贡献，包括代码提交、错误报告、文档更改等等，Electron 不会取得如此巨大的成功。这就是为什么我们认为参与 Hacktoberfest 非常重要，它可以引导更广泛的、不同技能水平的开发者加入该项目。

零碎事项​

今年，我们没有更广泛的项目让大家参与，但我们希望专注于在 Electron JavaScript 生态系统中提供贡献机会。

请关注我们各个存储库中带有 hacktoberfest 标签的问题，包括主要的 electron/electron 存储库、electron/electronjs.org 网站、electron/fiddle 和 electron-userland/electron-forge！

附注：如果您感觉特别有冒险精神，我们还有一些带有 help wanted 标签的积压问题，如果您正在寻找更大的挑战。

遇到困难？快来和我们聊天吧！​

此外，我们 Discord 服务器的盛大开幕与一年中最大的开源软件庆祝活动同时进行，这并非巧合。请查看 #hacktoberfest 频道，寻求有关您的 Hacktoberfest PR 的帮助。如果您错过了，这是邀请链接！

Electron 很荣幸能参与谷歌的 “文档季” 倡议的第二版，该倡议将来自开源组织的导师与技术作家配对，以改进项目文档。

什么是“文档季”？

“文档季” 是一项旨在促进技术作家和开源社区之间合作的计划，双方都从中受益。开源维护者利用作家的技术写作专业知识来改进其文档的结构和内容，而技术作家则在导师的指导下被引入开源社区。在谷歌的 “文档季” 网站上了解更多信息。

在我们首次参与该计划时，我们将指导一位技术作家，他将与 Electron 的 生态系统工作组一起工作，以重塑我们文档的很大一部分。您可以在 此处了解有关整个项目时间表的更多信息。

如何注册？

您是否有兴趣作为技术作家与我们合作？首先，请熟悉谷歌今年计划的 技术作家指南，并查看我们准备的两个 项目想法草案。

为了被选为 Electron 的 “文档季” 技术作家，候选人需要在 6 月 8 日至 7 月 9 日的技术作家申请阶段在谷歌“文档季”网站上申请。

您的申请应包括一份提案，这是一份书面文件，详细描述您计划在 3 个月内对 Electron 文档实现的目标。此提案可以基于我们在项目想法文档中提到的起点之一进行开发，也可以是全新的内容。不知道从哪里开始？您可以查看去年的 已接受提案列表，以获取灵感。

除了提案之外，我们还会考虑您作为技术作家的背景。请附上您的简历副本，重点介绍相关的写作经验，以及技术写作样本（这些样本可以是现有文档、教程、博客文章等）。

如果您想讨论项目提案，请发送电子邮件至 [email protected]，我们可以从那里开始聊天！

参考

• Electron 文档
• 项目想法文档
• “文档季”技术作家指南

Electron 正在努力使其发布周期更快、更稳定。为了实现这一目标，我们为大型 Electron 应用程序启动了应用程序反馈计划，以测试我们的 beta 版本并将应用程序特定的问题报告给我们。这有助于我们优先处理将应用程序尽快升级到下一个稳定版本的工作。

编辑（2020-05-21）：此计划已停止。

谁可以加入？​

我们的应用程序加入此计划的标准和期望包括以下项目

• 在 beta 期间测试您的应用程序超过 10,000 个用户小时
• 有一个指定联系人每周进行签到，讨论您应用程序的 Electron 错误和应用程序阻塞问题
• 您同意遵守 Electron 的 行为准则
• 您愿意分享下一个问题中列出的以下信息

我的 Electron 应用程序必须分享什么信息？​

• 您的应用程序使用任何 beta 版本运行的总用户小时数
• 您的应用程序正在测试的 Electron 版本（例如，4.0.0-beta.3）
• 任何阻止您的应用程序升级到正在进行 beta 测试的发行版本的错误

用户小时数​

我们理解并非每个人都能分享准确的用户数量，但是更好的数据有助于我们确定特定版本的稳定性。我们要求应用程序承诺测试至少一定数量的用户小时数，目前在 beta 周期中为 10,000 小时。

• 10 个用户小时可以是 10 个人测试一个小时，也可以是一个人测试 10 个小时
• 您可以在 beta 版本之间拆分测试，例如在 3.0.0-beta.2 上测试 5,000 个用户小时，然后在 3.0.0-beta.5 上测试 5,000 个用户小时。越多越好，但是我们理解某些应用程序无法测试每个 beta 版本
• CI 或 QA 小时数不计入总数；但是，内部版本计入

为什么我的 Electron 应用程序应该加入？​

您应用程序的错误将被跟踪，并将在核心 Electron 团队的关注范围之内。您的反馈有助于 Electron 团队了解新的 beta 版本的情况以及需要完成的工作。

我的应用程序信息是否会公开分享？谁可以查看此信息？​

不，您的应用程序信息不会与公众分享。信息保存在一个私有的 GitHub 存储库中，只有应用程序反馈计划的成员和 Electron 管理机构的成员才能查看。所有成员都已同意遵守 Electron 的 行为准则。

注册​

我们目前正在接受有限数量的注册。如果您有兴趣并能够满足上述要求，请填写此 表格。