Electron 再次被接受為 Google Summer of Code (GSoC) 2025 的指導組織！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）。

作為 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 Summer of Code 入口網站提交提案。以電子郵件發送給 Electron 團隊的提案將不被視為最終提交。

如需有關您的提案的更多指導，我們建議您遵循此處提供的官方 Google Summer of Code 提案撰寫建議。

申請於 2025 年 3 月 24 日 開放，並於 2025 年 4 月 8 日 截止。

問題？​

如果您有我們在這篇部落格文章中未解決的問題，或對您的提案草稿有疑問，請發送電子郵件至 summer-of-code@electronjs.org 或查看 GSoC FAQ。在發送電子郵件之前，請閱讀我們的貢獻者指南。

資源​

• 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 的生態系統工作組決定將所有套件升級到最早的 Node 版本，其中將支援同步 ESM 圖形的 require()（請參閱 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 以來已被棄用，並由 WebContentView 取代。值得慶幸的是，遷移相當輕鬆。

Electron 正在從 BrowserView 遷移到 WebContentsView，以與 Chromium 的 UI 框架 Views API 對齊。WebContentsView 提供直接與 Chromium 渲染管道綁定的可重複使用視圖，簡化了未來的升級，並為開發人員開啟了將非 Web UI 元素整合到其 Electron 應用程式的可能性。透過採用 WebContentsView，應用程式不僅為即將到來的更新做好準備，而且從長遠來看，還可以從降低的程式碼複雜性和更少的潛在錯誤中受益。

熟悉 BrowserWindows 和 BrowserViews 的開發人員應注意，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 中取得透明背景，請將其背景顏色設定為 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，Electron 的 2024 年 Google Summer of Code (GSoC) 貢獻者。

在 GSoC 計畫的過程中，我為 Electron 文件及其函數、類別等實作了 API 歷史記錄功能，其方式與 Node.js 文件類似：透過在 API 文件 Markdown 檔案中使用簡單但功能強大的 YAML 結構描述，並在 Electron 文件網站上精美地顯示它。

我們很高興地宣布 Electron 已被接受為第 20 屆 Google Summer of Code (GSoC) 2024 的指導組織！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 日 截止。

問題？​

如果您有我們在部落格文章中未解決的問題，或對您的提案草稿有疑問，請發送電子郵件至 summer-of-code@electronjs.org 或查看 GSoC FAQ！

資源​

• 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 最終被拒絕。

如果實作已合併到 electron/electron 中，則生效的 RFC 會變成完成 (Completed) 狀態。

誰可以參與？​

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 日¹。

經過 10 年和來自 1192 位獨特貢獻者的 27,147 次提交，Electron 已成為當今最受歡迎的桌面應用程式框架之一。這個里程碑是慶祝和反思我們迄今為止的旅程，並分享我們一路走來所學到的知識的絕佳機會。

如果沒有每位奉獻時間和精力為專案做出貢獻的人，我們今天就不會在這裡。儘管原始碼提交始終是最顯著的貢獻，但我們也必須感謝那些回報錯誤、維護 userland 模組、提供文件和翻譯以及參與網路空間中 Electron 社群的人們的努力。每一項貢獻對我們維護者來說都非常寶貴。

在我們繼續這篇部落格文章的其餘部分之前：感謝您。❤️

我們是如何走到這一步的？​

Atom Shell 最初是作為 GitHub Atom 編輯器的骨幹而建構的，該編輯器於 2014 年 4 月推出公開測試版。它從頭開始建構，作為當時可用的基於網頁的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它有一個殺手級功能：嵌入 Node.js 和 Chromium，為網頁技術提供強大的桌面運行時環境。

在一年之內，Atom Shell 的功能和受歡迎程度開始呈現驚人的成長。大型公司、新創公司和個別開發人員都開始使用它來建構應用程式（一些早期採用者包括 Slack、GitKraken 和 WebTorrent），並且該專案被恰如其分地更名為 Electron。

從那時起，Electron 一直快速發展且從未停止。以下是我們隨時間推移的每週下載次數，由 npmtrends.com 提供

Electron v1 於 2016 年發布，承諾提高 API 穩定性以及改進文件和工具。Electron v2 於 2018 年發布，並引入了語意化版本控制，使 Electron 開發人員更容易追蹤發布週期。

到了 Electron v6，我們轉向了常規的 12 週主要版本發布節奏，以配合 Chromium。這個決定是專案心態的轉變，將「擁有最新的 Chromium 版本」從錦上添花變成了優先事項。這減少了升級之間累積的技術債，使我們更容易保持 Electron 的更新和安全。

從那時起，我們一直像一台運轉良好的機器，在每個 Chromium 穩定版發布的同一天發布新的 Electron 版本。當 Chromium 在 2021 年將其發布時程加速到 4 週時，我們能夠聳聳肩，並相應地將我們的發布節奏提高到 8 週。

我們現在正處於 Electron v23（並且還在繼續），並且仍然致力於為建構跨平台桌面應用程式建構最佳的運行時環境。即使近年來 JavaScript 開發人員工具蓬勃發展，Electron 仍然是桌面應用程式框架領域中穩定、經過實戰考驗的中流砥柱。如今，Electron 應用程式無處不在：您可以使用 Visual Studio Code 進行程式設計、使用 Figma 進行設計、使用 Slack 進行溝通，以及使用 Notion 記筆記（以及許多其他用例）。我們為這項成就感到非常自豪，並感謝每一位使其成為可能的人。

我們一路走來學到了什麼？​

邁向十年里程碑的道路漫長而曲折。以下是一些幫助我們運行永續的大型開放原始碼專案的關鍵事項。

透過治理模型擴展分散式決策制定​

我們必須克服的一個挑戰是，一旦 Electron 首次爆紅，如何處理專案的長期方向。我們如何處理成為一個由數十名工程師組成的團隊，這些工程師分佈在不同的公司、國家和時區？

在早期，Electron 的維護者團隊依賴非正式的協調，這對於較小的專案來說快速且輕量，但不適用於更廣泛的協作。在 2019 年，我們轉向治理模型，不同的工作小組 (Working Group, WG) 擁有正式的責任領域。這對於簡化流程以及將專案所有權的部分分配給特定的維護者至關重要。現在每個工作小組負責什麼？

• 發布 Electron 版本 (發布 WG)
• 升級 Chromium 和 Node.js (升級 WG)
• 監督公共 API 設計 (API WG)
• 保持 Electron 安全 (安全 WG)
• 運行網站、文件和工具 (生態系統 WG)
• 社群和企業推廣 (推廣 WG)
• 社群管理 (社群與安全 WG)
• 維護我們的建構基礎設施、維護者工具和雲端服務 (基礎設施 WG)

在大約我們轉向治理模型的同時，我們也將 Electron 的所有權從 GitHub 轉移到 OpenJS Foundation。儘管最初的核心團隊今天仍在 Microsoft 工作，但他們只是構成 Electron 治理的更大協作者群體的一部分。²

雖然這個模型並不完美，但它在全球疫情和持續的總體經濟逆風中非常適合我們。展望未來，我們計劃修訂治理章程，以引導我們走過 Electron 的第二個十年。

社群​

開放原始碼的社群部分很困難，尤其是當您的推廣團隊只是一打穿著寫著「社群經理」風衣的工程師時。話雖如此，作為一個大型開放原始碼專案意味著我們有很多用戶，並且利用他們的能量為 Electron 建構 userland 生態系統是維持專案健康狀況的關鍵部分。

我們一直在做些什麼來發展我們的社群影響力？

建立虛擬社群​

• 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，這是一個針對 Google Goma 分散式編譯器服務的自訂 Electron 特定後端。Not Goma 處理來自授權使用者機器的編譯請求，並將該過程分發到後端數百個核心。它還快取編譯結果，以便其他人編譯相同的文件時只需要下載預先編譯的結果。

自推出 Not Goma 以來，維護者的編譯時間已從數小時縮短到數分鐘。穩定的網路連線成為貢獻者編譯 Electron 的最低要求！

持續雙因素驗證​

持續雙因素驗證 (Continuous Factor Authentication, 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 主要版本，使框架與網頁平台和 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 的 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 的 生態系統工作小組 合作，重塑我們文件的大部分內容。您可以在 此處 了解整個專案的時間表。

我該如何報名？

您是否有興趣作為技術作家與我們合作？首先，熟悉 Google 的 技術作家指南，並查看我們準備的兩個 專案構想草案。

為了被選為 Electron 的 Season of Docs 技術作家，候選人需要在 6 月 8 日至 7 月 9 日運行的技術作家申請階段期間在 Google Season of Docs 網站上申請。

您的申請應包括一份提案，這是一份書面文件，詳細描述了您計劃在 3 個月內在 Electron 文件上實現的目標。此提案可以基於我們的專案構想文件中提到的起點之一進行開發，也可以是全新的內容。不知道從哪裡開始？您可以查看去年的 已接受提案列表 以尋求靈感。

除了提案外，我們還將關注您作為技術作家的背景。請附上您的履歷副本，重點是相關的寫作經驗，以及技術寫作範例（這些範例可以是現有的文件、教學課程、部落格文章等）。

如果您想討論專案提案，請發送電子郵件至 season-of-docs@electronjs.org，我們可以從那裡開始聊天！

參考資料

• Electron 文件
• 專案構想文件
• Season of Docs 技術作家指南