在 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 版本無關。

下一步​

如果您有任何問題或疑慮，請隨時寫信給我們：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. 熟悉您的應用程式使用 BrowserView 的位置​

其中一種方法是在你的程式碼庫中搜尋 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 標籤，看看你遇到的問題是否已被回報。如果你沒有在那裡看到你的問題，請隨時新增錯誤回報。包含測試案例要點將有助於我們更好地分類你的問題！

恭喜，你已遷移到 WebContentsViews！ 🎉

Electron API 的歷史變更現在將在文件中詳細說明。

嗨 👋，我是 Peter，Electron 的 2024 年 Google Summer of Code (GSoC) 貢獻者。

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

我們很高興宣布 Electron 已被接受為 2024 年 Google Summer of Code (GSoC) 第 20 屆的指導組織！Google Summer of Code 是一項全球計畫，專注於將新的貢獻者帶入開源軟體開發。

如需更多計畫詳細資訊，請查看 Google 的 Summer of Code 首頁。

關於我們​

Electron 是一個 JavaScript 框架，用於使用網頁技術建置跨平台桌面應用程式。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 常見問題！

資源​

• 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 社群的成員都可以在 electron/rfcs 儲存庫中提交 RFC（請求評論）或留下意見回饋！

• 若要查看目前進行中的 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 月推出公開測試版。它是從頭開始建立的，作為當時可用的基於網頁的桌面框架（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，我們改為採用符合 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 版本（發布工作組）
• 升級 Chromium 和 Node.js（升級工作組）
• 監督公開 API 設計（API 工作組）
• 保持 Electron 安全（安全工作組）
• 運行網站、文件和工具（生態系統工作組）
• 社群和企業外展（外展工作組）
• 社群管理（社群和安全工作組）
• 維護我們的建置基礎設施、維護者工具和雲端服務（基礎設施工作組）

在大約我們轉向治理模型的同時，我們也將 Electron 的所有權從 GitHub 轉移到 OpenJS 基金會。儘管最初的核心團隊今天仍然在 Microsoft 工作，但他們只是組成 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 位活躍的維護者。我們中只有不到一半是全職貢獻者，這意味著有很多工作需要處理。我們保持一切順利運轉的訣竅是什麼？我們的座右銘是電腦很便宜，而人類的時間很昂貴。以典型的工程師方式，我們開發了一套自動化支援工具，讓我們的生活更輕鬆。

不是 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 是為了為任意 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 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 標籤的待處理問題，可以讓您挑戰一下。

遇到困難了嗎？來和我們聊聊吧！​

此外，我們的 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 技術寫作者指南

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 個人測試 1 小時，或 1 個人測試 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 的 行為準則。

報名​

我們目前接受有限數量的報名。如果您有興趣並且能夠滿足上述要求，請填寫此表單。