BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.

Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps​

1. Upgrade Electron to 30.0.0 or higher​

2. Familiarize yourself with where your application uses BrowserViews​

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

3. Migrate each usage of BrowserView​

1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

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

   By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

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

2. Migrate where the BrowserView gets added to its parent window.

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

3. Migrate BrowserView instance method calls on the parent window.

   Old Method	New Method	Hinweise:
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.contentView.children

4. Migrate the setAutoResize instance method to a resize listener.

   - 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,
   +    });
   +  });
   
   tipp

   All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes​

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

Historical changes to Electron APIs will now be detailed in the docs.

Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.

We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more program details, check out Google’s Summer of Code homepage.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

• End-user distribution tooling (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to streamline developer productivity (e.g. Electron Build Tools and Sheriff).

As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out examples in Electron Fiddle.

To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

Drafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. Alle aufgeführten Ideen sind derzeit offen für Vorschläge.

Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

Ihre Bewerbung sollte beinhalten:

• Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
• Dein Hintergrund als Entwickler. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Note that proposals emailed to the Electron team rather than submitted through the application portal will not be considered as a final submission.

If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 18th, 2024 and close on April 2nd, 2024.

Fragen?​

If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

Ressourcen​

• Electron Google Summer of Code 2024 Ideas List
• Electron Google Summer of Code 2024 Contributor Guidance
• Google Summer of Code Student/Contributor Guide

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?​

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

Wie funktioniert das?​

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

• Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
• Declined if the PR is ultimately rejected.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?​

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

• Electron C APIs
• Preload Realm for Service Workers

Credits​

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

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

Der erste Commit in das electron/electron Repository war am 13. März 2013¹.

10 Jahre und 27.147 weitere Commits von 1192 individuellen Mitwirkenden später, Electron ist heute zu einem der beliebtesten Frameworks für das Erstellen von Desktop-Anwendungen geworden. Dieser Meilenstein ist die perfekte Gelegenheit, um unsere bisherige Reise zu feiern und zu reflektieren, und mitzuteilen, was wir auf dem Weg gelernt haben.

Wir wären heute nicht hier ohne alle, die ihre Zeit und Mühe geopfert haben, um das Projekt zu unterstützen. Obwohl Quellcode-Commits immer die sichtbarsten Beiträge sind, müssen wir auch die Anstrengungen der Leute anerkennen, die Fehler melden, userland-Module warten, Dokumentation und Übersetzungen bereitstellen und an der Electron Community im gesamten Cyberspace teilnehmen. Jeder Beitrag ist für uns als Betreiber von unschätzbarem Wert.

Bevor wir mit dem Rest des Blog-Beitrags fortfahren: Vielen Dank. ❤️

Wie sind wir zu diesem Punkt gekommen?​

Atom Shell wurde als Gerüst für GitHubs Atom-Editorgebaut, der im April 2014 in die öffentliche Beta startete. Es wurde von Grund auf als Alternative zu den webbasierten Desktop-Frameworks gebaut, die zu dieser Zeit verfügbar waren (node-webkit und Chromium Embedded Framework). Es hatte eine Killer-Funktion: Einbetten von Node.js und Chromium, um eine leistungsfähige Desktop-Laufzeit für Web- Technologien zu bieten.

Innerhalb eines Jahres begann Atom Shell ein immenses Wachstum der Fähigkeiten und Popularität zu sehen. Große Firmen, Startups und einzelne Entwickler hatten gleichermaßen damit begonnen, Apps damit zu bauen (einige frühe Anwender waren Slack, GitKraken, und WebTorrent), und das Projekt wurde treffend in Electron umbenannt.

Von da an startete Electron voll durch und hielt nie auf. Hier ist ein Blick auf unsere wöchentliche Download-Anzahl über die Zeit, dank npmtrends.com:

Electron v1 wurde 2016 veröffentlicht und versprach eine höhere API-Stabilität und bessere Dokumentation und Werkzeuge. Electron v2 wurde 2018 veröffentlicht und führte semantische Versionierung ein, was es den Entwicklern von Electron einfacher macht, den Release-Zyklus zu verfolgen.

Mit Electron v6 haben wir auf eine reguläre 12-wöchige große Release-Kadenz umgeschaltet, um der Chromium-Kadenz zu folgen. Diese Entscheidung war ein Mentalitätswandel für das Projekt und hat "die aktuellste Chromium-Version zu haben" von einem Nice-to-have zu einer Priorität gemacht. Dies hat die Menge an technischer Schulden zwischen den Upgrades reduziert und macht es uns einfacher, Electron aktualisiert und sicher zu halten.

Seitdem sind wir eine gut geölte Maschine und veröffentlichen eine neue Elektro-Version am selben Tag wie jede stabile Version von Chromium. Als Chromium 2021 seinen Veröffentlichungszyklus auf 4 Wochen beschleunigte, konnten wir entspannt darauf reagieren und unseren Veröffentlichungsrhythmus entsprechend auf 8 Wochen erhöhen.

Wir sind nun bei Electron v23 (und es geht weiter) und sind weiterhin bestrebt, die beste Laufzeitumgebung für die Erstellung plattformübergreifender Desktop-Anwendungen zu entwickeln. Trotz des Booms von JavaScript-Entwicklerwerkzeugen in den letzten Jahren ist Electron ein stabiler und erprobter Eckpfeiler im Bereich der Desktop-Anwendungs-Frameworks geblieben. Heutzutage sind Electron-Apps allgegenwärtig: Du kannst mit Visual Studio Code programmieren, mit Figma designen, mit Slack kommunizieren und mit Notion Notizen machen (unter vielen anderen Anwendungsfällen). Wir sind unglaublich stolz auf diese Leistung und dankbar für alle, die dies möglich gemacht haben.

Was haben wir auf dem Weg gelernt?​

Der Weg zur Dekaden-Marke war lang und gewunden. Hier sind ein Paar der Kernelemente, die uns geholfen haben, ein solch großes Open-Source Projekt am Leben zu erhalten.

Skalierung verteilter Entscheidungsfindung mit einem Governance-Modell​

Eine Herausforderung, die wir bewältigen mussten, war, die langfristige Richtung des Projekts zu bewältigen, nachdem Electron zum ersten Mal in der Popularität explodierte. Wie gehen wir damit um, ein Team von ein paar Dutzend Ingenieuren zu sein, die über Firmen, Länder und Zeitzonen verteilt arbeiten?

In den Anfangstagen verließ sich die Gruppe der Electron-Maintainer auf informelle Koordination, die für kleinere Projekte schnell und unkompliziert ist, aber nicht auf breitere Zusammenarbeit skaliert. 2019 wechselten wir zu einem Governance-Modell, bei dem verschiedene Arbeitsgruppen formelle Verantwortungsbereiche haben. Dies war entscheidend, um Prozesse zu optimieren und Projektanteile spezifischen Maintainers zuzuweisen. Wofür ist jede Arbeitsgruppe (WG) heutzutage verantwortlich?

• Electron-Versionen herausbringen (Releases WG)
• Upgrade von Chromium und Node.js (Upgrades WG)
• Überwachung des öffentlichen API-Designs (API WG)
• Electron sicher halten (Sicherheit WG)
• Die Webseite am Laufen halten, Dokumentation und Bereitstellung von Werkzeugen (Ecosystem WG)
• Community und Firmenreichweite (Outreach WG)
• Community-Moderation (Community & Safety WG)
• Wartung unserer Build-Infrastruktur, Maintainer-Tools und Cloud-Services (Infrastructure WG)

Etwa zur gleichen Zeit, als wir zum Governance-Modell wechselten, übertrugen wir auch das Eigentum von Electron von GitHub zur OpenJS Foundation. Obwohl das ursprüngliche Kernteam heute noch bei Microsoft arbeitet, sind sie nur ein Teil einer größeren Gruppe von Mitwirkenden, die die Electron-Governance bilden.²

Obwohl dieses Modell nicht perfekt ist, hat es uns gut durch eine globale Pandemie und anhaltende makroökonomische Gegenwinde gebracht. Für die Zukunft planen wir, die Governance-Charta zu überarbeiten, um uns durch das zweite Jahrzehnt von Electron zu führen.

Community​

Der Community-Teil von Open Source ist schwierig, besonders wenn dein Outreach-Team aus einem Dutzend Ingenieuren in einem Trenchcoat besteht, auf dem "Community Manager" steht. Das bedeutet jedoch, dass wir als großes Open-Source-Projekt viele Nutzer haben, und ihre Energie für Electron zu nutzen, um ein Userland-Ökosystem aufzubauen, ist ein entscheidender Teil, um die Gesundheit des Projekts zu erhalten.

Was haben wir unternommen, um unsere Präsenz in der Community zu entwickeln?

Virtuelle Community aufbauen​

• Im Jahr 2020 starteten wir unseren Community-Discord-Server. Zuvor hatten wir einen Bereich im Forum von Atom, aber wir entschieden uns für eine informellere Messaging-Plattform, um einen Raum für Diskussionen zwischen Maintainern und Electron-Entwicklern sowie für allgemeine Debugging-Hilfe zu schaffen.
• This group has been instrumental in Electron growth in users from China’s booming tech scene, providing a space for them to collaborate on ideas and discuss Electron outside of our English-language spaces. We’d also like to thank cnpm for their work in supporting Electron’s nightly releases in their Chinese mirror for npm.

Participating in high-visibility open source programs​

• We have been celebrating Hacktoberfest every year since 2019. Hacktoberfest is yearly celebration of open source organized by DigitalOcean, and we get dozens of enthusiastic contributors every year looking to make their mark on open source software.
• In 2020, we participated in the initial iteration of Google Season of Docs, where we worked with @bandantonio to rework Electron’s new user tutorial flow.
• In 2022, we mentored a Google Summer of Code student for the first time. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

Automatisieren Sie all die Dinge!​

Today, Electron governance has about 30 active maintainers. Less than half of us are full-time contributors, which means that there’s a lot of work to go around. What’s our trick to keeping everything running smoothly? Our motto is that computers are cheap, and human time is expensive. In typical engineer fashion, we’ve developed a suite of automated support tooling to make our lives easier.

Nicht Goma​

The core Electron codebase is a behemoth of C++ code, and build times have always been a limiting factor in how fast we can ship bug fixes and new features. In 2020, we deployed Not Goma, a custom Electron-specific backend for Google’s Goma distributed compiler service. Not Goma processes compilation requests from authorized user’s machines and distributes the process across hundreds of cores in the backend. It also caches the compilation result so that someone else compiling the same files will only need to download the pre-compiled result.

Since launching Not Goma, compilation times for maintainers have decreased from the scale of hours to minutes. A stable internet connection became the minimum requirement for contributors to compile Electron!

Kontinuierliche Faktor-Authentifizierung​

Continuous Factor Authentication (CFA) is a layer of automation around npm’s two-factor authentication (2FA) system that we combine with semantic-release to manage secure and automated releases of our various @electron/ npm packages.

While semantic-release already automates the npm package publishing process, it requires turning off two-factor authentication or passing in a secret token that bypasses this restriction.

We built CFA to deliver a time-based one-time password (TOTP) for npm 2FA to arbitrary CI jobs, allowing us to harness the automation of semantic-release while keeping the additional security of two-factor authentication.

We use CFA with a Slack integration front-end, allowing maintainers to validate package publishing from any device they have Slack on, as long as they have their TOTP generator handy.

Sheriff​

Sheriff ist ein Open-Source-Werkzeug, das wir geschrieben haben, um die Verwaltung von Berechtigungen in GitHub, Slack und Google Workspace zu automatisieren.

Sheriff’s key value proposition is that permission management should be a transparent process. It uses a single YAML config file that designates permissions across all the above listed services. With Sheriff, getting collaborator status on a repo or creating a new mailing list is as easy as getting a PR approved and merged.

Sheriff also has an audit log that posts to Slack, warning admins when suspicious activity occurs anywhere in the Electron organization.

…und alle unsere GitHub Bots​

GitHub is a platform with rich API extensibility and a first-party bot application framework called Probot. To help us focus on the more creative parts of our job, we built out a suite of smaller bots that help do the dirty work for us. Here are a few examples:

• Sudowoodo automates the Electron release process from start to finish, from kicking off builds to uploading the release assets to GitHub and npm.
• Trop automates the backporting process for Electron by attempting to cherry-pick patches to previous release branches based on GitHub PR labels.
• Roller automates rolling upgrades of Electron’s Chromium and Node.js dependencies.
• Cation ist unser Statusprüfbot für electron/electron PRs.

Insgesamt hat uns unsere kleine Bot-Familie einen enormen Schub in der Entwicklungsproduktivität gebracht!

Was kommt als Nächstes?​

Wenn wir in unser zweites Jahrzehnt als ein Projekt kommen, könnten Sie fragen: Was ist das nächste für Electron?

We’re going to stay in sync with Chromium's release cadence, releasing new major versions of Electron every 8 weeks, keeping the framework updated with the latest and greatest from the web platform and Node.js while maintaining stability and security for enterprise-grade applications.

We generally announce news on upcoming initiatives when they become concrete. If you want to keep up with future releases, features, and general project updates, you can read our blog and follow our social media profiles (Twitter and Mastodon)!

Das Elektron Team freut sich mitteilen zu können, dass wir dieses Jahr zum ersten Mal am Google Summer of Code teilnehmen werden!

Was ist Google Summer of Code?​

Google Summer of Code (GSoC) ist ein jährliches Mentoring-Programm, das Open-Source-Software-Projekte mit potenziellen Mitwirkenden verbindet. Früher nur für Studierende geöffnet, können sich jetzt alle ab 18 Jahren bei GSoC registrieren.

Weitere Informationen finden Sie auf der Summer of Code Homepage.

How do I sign up?​

Sind Sie an einer Zusammenarbeit mit Electronic interessiert? Wenn Sie ein neuer oder Anfänger von Open-Source-Mitwirkender sind, freuen wir uns über Ihre Bewerbung!

Um als Electron-Beitragender für Google Summer of Code ausgewählt zu werden, müssen Sie eine Bewerbung einreichen. Anwendungen werden am 4. April 2022 geöffnet und schließen am 19. April 2022. Du kannst den Updates für Google folgen: Summer of Code Anwendungsrichtlinien hier.

Möchtest du dich bewerben? Schauen Sie sich zuerst die fünf Projektideen an, die wir vorbereitet haben. Alle aufgeführten Ideen sind derzeit offen für Vorschläge. Wir sind auch bereit, neue Ideen zu akzeptieren, die nicht auf der vorgeschlagenen Projektliste stehen.

Ihre Bewerbung sollte beinhalten:

• Ihr Vorschlag, das ist ein schriftliches Dokument, das genau beschreibt, was Sie im Laufe des Sommers zu erreichen gedenken.
• Dein Hintergrund als Entwickler. Wenn Sie einen Lebenslauf haben, geben Sie bitte ein Exemplar an, sonst teilen Sie uns Ihre Erfahrungen mit einem Schwerpunkt auf relevante technische Erfahrung mit.

Hier finden Sie eine detaillierte Anleitung zum Einreichen im Rahmen Ihrer Electron-Anwendung.

Sie können auch den -offiziellen GSoC-Studenten/Mitwirkenden Leitfaden für wichtige Tipps zur Vorbereitung Ihres Vorschlags lesen.

Wenn du über Projektvorschläge diskutieren oder Fragen haben möchtest, schaue in unserem #gsoc-General Discord Channel aus!

References​

• Electron Vorschlag Leitfaden
• Elektron GitHub
• Projektideendokument
• Google Summer of Code Student/Mitwirkender Guide

Join us for community bonding and a month-long celebration of open-source.

Electron Community Discord Launch

Electron’s Outreach Working Group is excited to announce the launch of our official community Discord server!

Warum ein neuer Discord Server?​

In its early days as the backbone of the Atom text editor, community discussion on the Electron framework occurred in a single channel in Atom’s Slack workspace. As time passed and the two projects were increasingly decoupled, the relevance of the Atom workspace to the Electron project decreased, and maintainer participation in the Slack channel declined in the same manner.

Up until now, we had still been redirecting our broader community to the Atom Slack workspace, even though we’ve had many reports from folks who have had trouble receiving invitations, and few of our core maintainers were frequenting the channel.

We’re setting up this shiny new server to be a central discussion hub for the community where you can get the latest news on all things Electron.

Get in here!​

So far, the server’s membership consists of a few maintainers who have been working together to set it up, but we’re so excited to chat with you all! Come ask for help, keep up to date with Electron releases, or just hang out with other developers. We’ve got a handy invite for you that’ll give you access to the server!

Hacktoberfest 2020

As a large and long-running open-source project, Electron wouldn’t have been nearly as successful without all the contributions from its community, from code submissions to bug reports to documentation changes, and much more. That’s why we believe in the importance of participating in Hacktoberfest to usher in a wider community of developers of all skill levels into the project.

Odds and ends​

This year, we don’t have a wider project to give you all to work on, but we’d like to focus on opportunities to contribute across the Electron JavaScript ecosystem.

Look out for issues tagged hacktoberfest across our various repositories, including the main electron/electron repository, the electron/electronjs.org website, electron/fiddle, and electron-userland/electron-forge!

P.S. If you're feeling particularly adventurous, we also have a backlog of issues marked with help wanted tags if you're looking for more of a challenge.

Stuck? Komm mit uns chatten!​

Moreover, it’s also no coincidence that the grand opening of our Discord server coincides with the largest celebration of open-source software of the year. Check out the #hacktoberfest channel to ask for help on your Hacktoberfest PR. In case you missed it, here's the invite link again!

Electron ist stolz darauf, an der zweiten Auflage der Initiative "Season of Docs" von Google teilzunehmen die Mentoren von Open-Source-Organisationen mit technischen Autoren kombiniert, um die Projektdokumentation zu verbessern.

What is Season of Docs?

Season of Docs is a program that fosters collaboration between technical writers and open source communities to the benefit of both parties. Open source maintainers utilize the writer's technical writing expertise to improve the structure and content of their documentation, while the technical writer is introduced to an open-source community under the guidance of its mentors. Learn more about it on the Google's Season of Docs website.

For our first time participating in the program, we'll be mentoring a single technical writer who will be working alongside Electron's Ecosystem Working Group to reshape large parts of our documentation. You can learn more about the timeline of the whole project here.

How do I sign up?

Are you interested in collaborating with us as a technical writer? First, get familiar with Google's tech writer guide for this year's program, and check out the two project idea drafts that we have prepared.

In order to be selected as Electron's technical writer for Season of Docs, candidates will need to apply on the Google Season of Docs website during the Technical Writer Application phase that is running from June 8 to July 9..

Your application should include a proposal, which is a written document that describes in detail what you plan to achieve on the Electron docs over the course of 3 months. This proposal can either develop on one of the starting points mentioned in our Project Idea doc, or can be something entirely new. Don't know where to start? You can check out last year's list of accepted proposals for inspiration.

Aside from the proposal, we'll also be looking at your background as a technical writer. Please include a copy of your resume with an emphasis on relevant writing experience, as well as technical writing samples (these samples could be existing documentation, tutorial, blog posts, etc.)

If you want to discuss project proposals, shoot us an email at season-of-docs@electronjs.org and we can chat from there!

References

• Electron documentation
• Project ideas document
• Season of Docs tech writer guide

Electron is working on making its release cycles faster and more stable. To make that possible, we've started the App Feedback Program for large-scale Electron apps to test our beta releases and report app-specific issues to us. This helps us to prioritize work that will get applications upgraded to our next stable release sooner.

Edit (2020-05-21): This program has been retired.

Who can join?​

Our criteria and expectations for apps joining this program include the following items:

• Test your app during the beta period for 10,000+ user-hours
• Have a single point-person who will check in weekly to discuss your app's Electron bugs and app blockers
• You agree to abide by Electron's Code of Conduct
• You are willing to share the following information listed in the next question

What info does my Electron app have to share?​

• Total user-hours your app has been running with any beta release
• Version of Electron that your app is testing with (e.g., 4.0.0-beta.3)
• Any bugs preventing your application from upgrading to the release line being beta tested

User-hours​

We understand not everyone can share exact user numbers, however better data helps us decide how stable a particular release is. We ask that apps commit to testing a minimum number of user-hours, currently 10,000 across the beta cycle.

• 10 user-hours could be 10 people testing for one hour, or one person testing for 10 hours
• Sie können das Testen auf Beta-Versionen aufteilen, zum Beispiel auf 3.0.0-Beta für 5.000 User-Stunden. und dann 5.000 Userstunden auf 3.0.0-beta.5 testen. Mehr ist besser, aber wir verstehen, dass einige Anwendungen nicht jede Beta-Version testen können
• CI or QA hours do not count towards the total; however, internal releases do count

Why should my Electron app join?​

Your app's bugs will be tracked and be on the core Electron team's radar. Your feedback helps the Electron team to see how the new betas are doing and what work needs to be done.

Will my application's info be shared publicly? Who gets to see this info?​

No, your application's information will not be shared with the general public. Information is kept in a private GitHub repo that is only viewable to members of the App Feedback Program and Electron Governance. All members have agreed to follow Electron's Code of Conduct.

Registrieren​

We are currently accepting a limited number of signups. If you are interested and are able to fulfill the above requirements, please fill out this form.

Diese Woche haben wir den Ersteller von Jasperinterviewt, einem Electron-basierten Werkzeug für die Verwaltung von GitHub Benachrichtigungen.

Hallo! Wer bist du?​

Ich bin Ryo Maruyama, ein Softwareentwickler in Japan. Ich entwickle Jasper und ESDoc.

Was ist Jasper?​

Jasper ist ein flexibler und mächtiger Issue-Reader für GitHub. Es unterstützt Issues und Pull-Requests auf github.com und GitHub Enterprise.

Warum hast du es gemacht?​

Wenn Menschen GitHub in ihren Job- oder OSS-Aktivitäten verwenden, neigen sie dazu, täglich viele Benachrichtigungen zu erhalten. Um die Benachrichtigungen zu abonnieren, bietet GitHub E-Mail und Web-Benachrichtigungen. Ich habe diese für ein paar Jahre verwendet, aber ich bin auf folgende Probleme gestoßen:

• It's easy to overlook issues where I was mentioned, I commented, or I am watching.
• I put some issues in a corner of my head to check later, but I sometimes forget about them.
• To not forget issues, I keep many tabs open in my browser.
• It's hard to check all issues that are related to me.
• It's hard to grasp all of my team's activity.

I was spending a lot of time and energy trying to prevent those problems, so I decided to make an issue reader for GitHub to solve these problems efficiently, and started developing Jasper.

Wer benutzt Jasper?​

Jasper is used by developers, designers, and managers in several companies that are using GitHub. Of course, some OSS developers also are using it. And it is also used by some people at GitHub!

Wie funktioniert Jasper?​

Sobald Jasper konfiguriert ist, erscheint der folgende Bildschirm. Von links nach rechts können Sie "Streams List", "Issue List" und "Issue Body" sehen.

Dieser "Stream" ist die Kernfunktion von Jasper. Wenn Sie zum Beispiel "Issues, die @zeke im electron/electron Repository zugewiesen sind" sehen wollen, erstellen Sie den folgenden Stream:

repo:electron/electron assignee:zeke is:issue

After creating the stream and waiting for a few seconds, you can see the issues that meet the conditions.

Was können wir mit Streams tun?​

I will introduce what kind of conditions can be used for stream.

Benutzer und Teams​

involves means mention, author, assignee or commenter

Respositories und Organisationen​

org is same as user

Attribute​

Prüfstatus​

As you may have noticed by looking at these, streams can use GitHub's search queries. For details on how to use streams and search queries, see the following URLs.

• jasperapp.io/doc.html#stream
• help.github.com/articles/searching-issues
• help.github.com/articles/search-syntax

Jasper also has features for unread issue management, unread comment management, marking stars, notification updating, filtering issues, keyboard shortcuts, etc.

Ist Jasper ein bezahltes Produkt? Wie viel kostet es?​

Jasper kostet $12. However you can use the free trial edition for 30 days.

Warum haben Sie Jasper auf Electron gebaut?​

Ich mag die folgenden Aspekte von Elektron:

• Apps können mit JavaScript/CSS/HTML entwickelt werden.
• Apps können für Windows, Mac und Linux-Plattformen gebaut werden.
• Electron wird aktiv entwickelt und hat eine große Community.

These features enable rapid and simple desktop application development. It is awesome! If you have any product idea, you should consider using Electron by all means.

Was sind einige Herausforderungen, denen Sie bei der Entwicklung von Jasper gegenüberstanden?​

I had a hard time figuring out the "stream" concept. Zuerst habe ich über die Verwendung von GitHubs Benachrichtigungs-API nachgedacht. Ich habe jedoch festgestellt, dass sie bestimmte Anwendungsfälle nicht unterstützt. Danach habe ich die Issues API und Pull-Requests APIzusätzlich zur Benachrichtigungs-API in Erwägung gezogen. Aber es wurde nie das, was ich wollte. Während ich über verschiedene Methoden nachdachte, erkannte ich, dass das Umfragen von GitHubs Such-API die größte Flexibilität bieten würde. It took about a month of experimentation to get to this point, then I implemented a prototype of Jasper with the stream concept in two days.

Note: The polling is limited to once every 10 seconds at most. This is acceptable enough for the restriction of GitHub API.

Was kommt als Nächstes?​

Ich habe einen Plan, die folgenden Funktionen zu entwickeln:

• Ein gefilterter Stream: Ein Stream hat einige gefilterte Streams, die Probleme im Stream filtern. Es ist wie eine Ansicht von SQL.
• Mehrere Konten: Sie werden in der Lage sein, github.com und GHE zu verwenden
• Leistung verbessern: Im Moment ist das Laden eines Problems in WebView in niedriger Geschwindigkeit als der normale Browser.

Folgen Sie @jasperappio auf Twitter für Updates.