Electron 再次被接受为 2025 年 Google 编程之夏 (GSoC) 的指导组织！Google 编程之夏是一项全球性计划，旨在吸引新贡献者参与开源软件开发。

有关该计划的更多详细信息，请访问 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 贡献者，你将有机会在 github.com/electron 旗下的众多项目之一上与 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 常见问题。请在发送电子邮件前阅读我们的贡献者指南。

资源​

• 2025 年 Electron Google 编程之夏想法列表
• 2025 年 Electron Google 编程之夏贡献者指南
• Google 编程之夏学生/贡献者指南

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 的生态系统工作组决定在某个版本达到 LTS 日期之后，将所有软件包升级到支持同步 ESM 图的 require() 的最早 Node 版本（参见 nodejs/node#51977 和 nodejs/node#53500）。

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

我需要采取什么行动？​

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

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

下一步​

如果您有任何问题或疑虑，请随时通过电子邮件联系我们： info@electronjs.org 。您也可以在我们的官方 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. 熟悉你的应用使用 BrowserViews 的位置​

一种方法是搜索你的代码库查找 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 已被接受为第 20 届 Google 编程之夏 (GSoC) 2024 的指导组织！Google 编程之夏是一项全球性计划，旨在吸引新贡献者参与开源软件开发。

有关该计划的更多详细信息，请查看 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）。

作为编程之夏贡献者，你将在 github.com/electron 旗下的众多项目之一上与 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 常见问题！

资源​

• 2024 年 Electron Google 编程之夏想法列表
• 2024 年 Electron Google 编程之夏贡献者指南
• Google 编程之夏学生/贡献者指南

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 的 Preload Realm

致谢​

Electron 的 RFC 流程借鉴了许多已建立的开源 RFC 流程。许多想法和主要文案的灵感来自

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

首次提交到 electron/electron 仓库是在 2013 年 3 月 13 日¹。

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

如果没有所有为项目贡献时间与精力的人们，我们今天就不会站在这里。虽然源代码提交总是最引人注目的贡献，但我们也要感谢那些报告 bug、维护用户态模块、提供文档和翻译以及在网络空间中参与 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 courtesy of npmtrends.com 提供的每周下载量随时间变化的情况：

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

到 Electron v6 时，我们转向了每 12 周一个主要版本的固定发布周期，以匹配 Chromium。这一决定改变了项目的思维方式，将“拥有最新的 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）

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

虽然这种模式并非完美，但它在全球大流行和持续宏观经济逆风中对我们很有帮助。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

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

我们一直在做些什么来发展我们的社区影响力？

构建虚拟社区​

• 2020 年，我们启动了社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定建立一个更非正式的消息传递平台，以便维护者和 Electron 开发者之间进行讨论，并提供一般的调试帮助。
• 2021 年，在 @BlackHole1 的帮助下，我们建立了 Electron 中国 用户组。这个用户组对于 Electron 在中国蓬勃发展的科技界的增长起到了重要作用，为他们提供了一个在我们英语空间之外协作想法和讨论 Electron 的空间。我们还要感谢 cnpm 在其中国镜像中支持 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++ 代码库，构建时间一直是限制我们发布 bug 修复和新特性速度的因素。2020 年，我们部署了 Not Goma，这是一个 Electron 特有的后端，用于 Google 的 Goma 分布式编译器服务。Not Goma 处理来自授权用户机器的编译请求，并将进程分布到后端的数百个核心上。它还缓存编译结果，这样其他人编译相同文件时只需要下载预编译的结果。

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

持续因子认证 (Continuous Factor Authentication)​

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

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

我们构建了 CFA，以向任意 CI 作业提供用于 npm 2FA 的基于时间的一次性密码 (TOTP)，使我们能够利用 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 编程之夏学生/贡献者指南

加入我们，进行社区交流和为期一个月的开源庆典。

Electron 社区 Discord 启动

Electron 的 Outreach 工作组很高兴宣布，我们的官方社区 Discord 服务器启动了！

为什么需要一个新的 Discord 服务器？​

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

直到现在，我们仍然将更广泛的社区重定向到 Atom Slack 工作区，尽管我们收到了许多用户报告称难以收到邀请，而且我们核心维护者中很少有人经常访问该频道。

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

进来吧！​

目前，服务器成员包括一些一直合作搭建服务器的维护者，但我们非常激动能与大家聊天！过来寻求帮助，及时了解 Electron 发布，或者只是与其他开发者交流。我们为您准备了一个方便的邀请链接，让您可以访问服务器！

Hacktoberfest 2020

作为一个大型的、长期运行的开源项目，没有来自社区的所有贡献——从代码提交到 bug 报告，再到文档更改等等——Electron 不会取得如此巨大的成功。这就是为什么我们相信参与 Hacktoberfest 将更广泛的、不同技能水平的开发者社区引入项目的重要性。

零星事项​

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

请在我们的各个仓库中寻找标记有 hacktoberfest 的 issue，包括主仓库 electron/electron、electron/electronjs.org 网站、electron/fiddle 和 electron-userland/electron-forge！

附注：如果你觉得特别有挑战欲，我们还有一些标记为 help wanted 的积压 issue，如果你正在寻找更大的挑战。

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

此外，我们的 Discord 服务器盛大开幕与一年中规模最大的开源软件庆典同时举行并非巧合。请查看 #hacktoberfest 频道，以获取关于您的 Hacktoberfest PR 的帮助。如果您错过了，这里再次提供邀请链接！

Electron 很荣幸能参加第二届 Google Season of Docs 活动，该活动旨在将开源组织的导师与技术文档作者配对，以改进项目文档。

什么是 Season of Docs？

Season of Docs 是一项旨在促进技术文档作者和开源社区之间互利的协作计划。开源维护者利用作者的技术写作专业知识来改进文档的结构和内容，而技术文档作者则在导师的指导下加入开源社区。您可以在 Google 的 Season of Docs 网站上了解更多信息。

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

如何报名？

您有兴趣作为技术文档作者与我们合作吗？首先，请熟悉 Google 针对今年计划的 技术文档作者指南，并查看我们准备的两个项目想法草稿。

为了被选为 Season of Docs 的 Electron 技术文档作者，候选人需要在技术文档作者申请阶段（6 月 8 日至 7 月 9 日）在 Google Season of Docs 网站上申请。

您的申请应包括一份提案，这是一份书面文件，详细描述了您计划在三个月内完成的 Electron 文档工作。该提案可以基于我们项目想法文档中提到的起点进行深入，也可以是全新的内容。不知道从何入手？您可以查看去年的已接受提案列表获取灵感。

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

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

参考资料

• Electron 文档
• 项目想法文档
• Season of Docs 技术文档作者指南