Electron 再次被接纳为 Google Summer of Code (GSoC) 2025 的指导组织！Google Summer of Code 是一个全球性项目，旨在吸引新的贡献者加入开源软件开发。

有关该计划的更多详细信息，请访问 Google 的 夏季编程活动主页。

关于我们​

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

除了 Electron 核心仓库之外，我们还维护了几个项目来支持 Electron 生态系统，包括：

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

作为 GSoC 的贡献者，您将有机会与 Electron 的核心贡献者合作，在 github.com/electron 伞下的众多项目上开展工作。

申请前​

如果您不熟悉 Electron，我们建议您首先阅读 文档 并尝试 Electron Fiddle 中的一些示例。

要了解有关分发 Electron 应用程序的更多信息，请尝试使用 Electron Forge 创建一个示例应用程序。

npm init electron-app@latest my-app

在熟悉代码之后，请加入 Electron Discord 服务器 进行讨论。

项目贡献​

我们鼓励你查看与你感兴趣的项目想法相关的任何存储库。进行研究的一种方法是通过报告错误、分类现有问题或提交拉取请求来做出贡献。这样做是掌握我们代码库的有效方法，但并非提交提案的强制要求。一份精心制作的提案应该能够证明你对代码的理解，而无需提及过去的贡献。

如果您想在提交提案之前为 Electron 做出贡献，这里有一些提示：

1. 提交贡献时，请提供描述性的问题或 PR 描述。无论代码本身如何，在贡献的书面部分下功夫都向我们表明您可以在协作环境中成为一名有效的沟通者。
2. 我们随时欢迎针对未解决问题的 PR。你无需在问题下评论询问维护者是否可以分配给你。请注意，如果你需要完善解决方案的想法，我们仍然鼓励你在问题下讨论潜在的解决方案，但严格询问是否可以处理某事的评论是多余的，会给问题跟踪器增加噪音。
3. 低投入的项目贡献（例如无效的问题报告、仓库 README 中微不足道的措辞更改或前端代码中微小的样式更改）将对你的最终提案产生负面影响，因为它们会占用有限的维护者时间，并且对 Electron 项目没有任何净收益。
4. 虽然 AI 编码助手可以作为调试和理解新概念的有效工具，但我们强烈不鼓励直接从 AI 生成的输出复制/粘贴的贡献。这些贡献通常质量低下，维护者清理 LLM 生成的代码通常比我们直接拒绝 PR 更费力。

撰写提案​

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

如果您有一个列表中没有的独特想法，我们愿意考虑，但请确保您的提案详细且彻底地概述。如有疑问，我们建议您坚持我们列出的想法。

您的申请应包括：

• 一份详细的提案，概述您计划在夏季实现的目标。
• 您作为开发者的背景。如果您有简历，请附上一份副本。否则，请告诉我们您过去的技术经验。
  • 在某些领域缺乏经验不会使您失去资格，但这将有助于我们的导师制定计划，以最好地支持您，并确保您的暑期项目取得成功。

关于如何提交 Electron 申请的详细指南在此。请直接通过 Google 夏季编程活动门户网站提交提案。发送给 Electron 团队的提案将不被视为最终提交。

为了更好地指导您的提案，我们建议您遵循 此处提供的官方 Google 夏季编程活动提案撰写建议。

申请于 2025年3月24日 开放，并于 2025年4月8日 截止。

问题？​

如果您对本文档中未解决的问题或关于您的提案草案的疑问，请发送电子邮件至 summer-of-code@electronjs.org 或查看 GSoC 常见问题解答。请在发送电子邮件前阅读 我们的贡献者指南。

资源​

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

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 生态系统工作组决定将所有包升级到最早支持 require() 同步 ESM 图的版本（请参阅 nodejs/node#51977 和 nodejs/node#53500），在该版本达到其 LTS 日期之后的一个未来时间点。

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

我需要采取什么行动？​

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

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

接下来会发生什么​

如果您有任何问题或疑虑，请随时通过 info@electronjs.org 与我们联系。您还可以在我们的官方 Electron Discord 中找到社区支持。

BrowserView 自 Electron 30 起已被弃用，并由 WebContentsView 取代。幸运的是，迁移过程相当简单。

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(。这应该能让您了解您的应用程序是如何使用 BrowserViews 的，以及有多少调用点需要迁移。

3. 迁移 BrowserView 的每个用法​

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

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

   信息

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

   + 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 实例方法迁移到一个 resize 监听器。

   - 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 年的 Google 暑期代码项目 (GSoC) 的 Electron 贡献者。

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

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

有关更多项目详情，请查看 Google 的 暑期代码项目主页。

关于我们​

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

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

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

作为暑期代码项目贡献者，您将与 Electron 的核心贡献者合作，在 github.com/electron 伞下的众多项目之一上工作。

申请前​

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

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

npm init electron-app@latest my-app

在熟悉代码之后，请加入 Electron Discord 服务器 进行讨论。

撰写您的提案​

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

您有希望我们考虑的其他想法吗？我们也接受不在拟议项目列表中的新想法，但请确保您的方法有详尽的概述和细节。如果不确定，我们建议您选择我们列出的想法。

您的申请应包括：

• 您的提案：一份书面文件，详细描述您计划在暑期实现的目标。
• 您作为开发者的背景。如果您有简历，请附上一份副本。否则，请告诉我们您过去的技术经验。
  • 在某些领域缺乏经验不会使您失去资格，但这将有助于我们的导师制定计划，以最好地支持您，并确保您的暑期项目取得成功。

关于作为 Electron 申请提交的内容的详细指南在这里。 请直接通过 Google 暑期代码项目门户提交提案。请注意，通过申请门户提交的提案才会被视为最终提交，而通过电子邮件发送给 Electron 团队的提案将不被考虑。

如果您想获得有关提案的更多指导或不确定包含哪些内容，我们还建议您阅读 此处提供的官方 Google 暑期代码项目提案撰写建议。

申请于 2024 年 3 月 18 日 开放，并于 2024 年 4 月 2 日 截止。

问题？​

如果您有我们未在博客文章中解决的问题或提案草案的咨询，请通过 summer-of-code@electronjs.org 向我们发送电子邮件，或查看 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 就进入了提案（Proposed）阶段。一个提案中的 RFC 会进入

• 激活（Active）状态，当该 PR 被合并到仓库的 main 分支时，这意味着 Electron 维护者们同意在 electron/electron 中实现该提案，或者
• 拒绝（Declined）状态，如果该 PR 最终被拒绝。

一个激活状态的 RFC 在其实现被合并到 electron/electron 后，将进入完成（Completed）状态。

谁可以参与？​

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

• 要查看活动RFC列表，请参考 仓库中的text文件夹。
• 要对拟议的RFC提供反馈，请查看 开放的PR列表。
• 要提交新的RFC，请查看仓库的 README 和 RFC模板。

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

• Electron C API
• 用于 Service Worker 的 Preload Realm

鸣谢​

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 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的经验的绝佳机会。

如果没有各位投入时间和精力为项目做出贡献，我们今天就不会取得如此成就。尽管源代码提交始终是最显而易见的贡献，但我们也必须感谢那些报告 Bug、维护用户态模块、提供文档和翻译，以及在网络空间中参与 Electron 社区的人们所付出的努力。对于我们这些维护者来说，每一次贡献都弥足珍贵。

在继续阅读这篇博客文章之前：谢谢你。❤️

我们是如何走到这一步的？​

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

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

从那时起，Electron 一帆风顺，从未停止。以下是 npmtrends.com 提供的随时间推移的每周下载量统计：npmtrends.com

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

到 Electron v6 版本，我们转向了与 Chromium 匹配的每 12 周发布一个主要版本的节奏。这个决定改变了项目的理念，将“拥有最新的 Chromium 版本”从一个不错的选择提升为优先事项。这减少了升级之间的技术债务量，使我们更容易保持 Electron 的更新和安全。

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

我们现在正使用 Electron v23（且仍在继续增长），并且仍然致力于为构建跨平台桌面应用程序提供最佳运行时。尽管近年来 JavaScript 开发工具蓬勃发展，但 Electron 仍然是桌面应用程序框架领域稳定、久经考验的中坚力量。Electron 应用程序如今无处不在：你可以使用 Visual Studio Code 编程，使用 Figma 进行设计，使用 Slack 进行交流，并使用 Notion 记笔记（以及许多其他用例）。我们为这一成就感到无比自豪，并感谢所有促成此事的人。

我们一路学到了什么？​

通往十周年的道路漫长而曲折。以下是一些帮助我们运营一个可持续的大型开源项目的关键经验。

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

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

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

• 负责发布 Electron 版本（Releases WG）
• 升级 Chromium 和 Node.js（Upgrades WG）
• 监督公共 API 设计（API WG）
• 维护 Electron 的安全（Security WG）
• 运营网站、文档和工具（Ecosystem WG）
• 社区和企业推广（Outreach WG）
• 社区管理（Community & Safety WG）
• 维护我们的构建基础设施、维护者工具和云服务（Infrastructure WG）

与我们转向治理模式的同时，我们也将其所有权从 GitHub 转移到 OpenJS Foundation。虽然最初的核心团队今天仍在 Microsoft 工作，但他们只是构成 Electron 治理的更大合作者群体的一部分。²

虽然这个模式并非完美，但它在全球疫情和持续的宏观经济逆风中很好地支持了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，特别是当你的外展团队是穿着风衣的十几名工程师，上面写着“社区经理”时。话虽如此，作为一个大型开源项目意味着我们拥有大量用户，利用他们的精力为 Electron 构建用户态生态系统是维持项目健康的关键部分。

我们为发展我们的社区做了些什么？

构建虚拟社区​

• 2020 年，我们启动了社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定使用一个更非正式的消息平台，为维护者和 Electron 开发者之间的讨论以及一般的调试帮助提供一个空间。
• 2021 年，我们借助 @BlackHole1 的帮助，建立了 Electron China 用户组。该小组对于 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 名活跃的维护者。我们中只有不到一半是全职贡献者，这意味着有很多工作要做。我们保持一切顺利运行的秘诀是什么？我们的座右铭是：计算机很便宜，而人的时间很宝贵。本着典型的工程师精神，我们开发了一套自动化支持工具，让我们的生活更轻松。

不是 Goma​

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

自从推出 Not Goma 以来，维护者的编译时间从几小时缩短到了几分钟。稳定的网络连接成为贡献者编译 Electron 的最低要求！

持续因素身份验证​

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

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

我们构建了 CFA，以便为任意的 CI 作业提供基于时间的一次性密码 (TOTP) 用于 npm 2FA，这使我们能够利用 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 标签将补丁移植到以前的版本分支来自动化 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 的发布信息，或者只是与其他开发者一起闲聊。 我们有一个方便的 邀请链接，可以让你访问服务器！

Hacktoberfest 2020

作为一个大型且历史悠久的开源项目，Electron 的成功离不开社区的各种贡献，从代码提交到错误报告再到文档修改，以及更多。因此，我们深信参与 Hacktoberfest 的重要性，以吸引更广泛的、各种技能水平的开发者社区加入本项目。

其他事项​

今年，我们没有更广泛的项目可以供大家完成，但我们希望专注于为整个 Electron JavaScript 生态系统贡献机会。

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

顺便说一句，如果您感觉特别有冒险精神，我们还有一个标记为 help wanted 的 issue backlog，如果您正在寻找更大的挑战，可以尝试一下。

卡住了？快来和我们聊聊！​

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

Electron 很荣幸能参与第二届 Google 文档季活动。该活动旨在让开源项目的技术作者与导师进行合作，以改善项目文档。

什么是文档季？

文档季节 (Season of Docs) 是一个促进技术作家与开源社区合作的计划，双方都从中受益。开源维护者利用作家的技术写作专业知识来改进其文档的结构和内容，而技术作家则在导师的指导下被引入一个开源社区。请在 Google 的 文档季节网站 上了解更多信息。

作为我们首次参与该计划，我们将指导一位技术作家，他将与 Electron 的 生态系统工作组 合作，重塑我们文档的大部分内容。您可以在 此处 了解整个项目的完整时间表。

我该如何报名？

如果您有兴趣与我们合作作为技术作家，首先请熟悉 Google 的 技术作家指南，并查看我们准备的两个 项目想法草案。

为了被选为 Electron 文档季的技术作者，候选人需要在 6 月 8 日至 7 月 9 日期间的技术作者申请阶段，在 Google 文档季网站上进行申请。

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

除了提案，我们还将关注您作为技术写作者的背景。请附上一份简历副本，重点突出相关的写作经验，以及技术写作范例（这些范例可以是现有文档、教程、博客文章等）。

如果您想讨论项目提案，请通过 season-of-docs@electronjs.org 向我们发送电子邮件，我们可以从那里开始讨论！

参考

• Electron 文档
• 项目创意文档
• 文档季技术作者指南