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

   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! 🎉

L'historique des changements des différentes API Electron sera maintenant détaillé dans la documentation.

Bonjour 👋, je suis Peter, le contributeur Electron pour le Google Summer of Code (GSoC).

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.

Nous sommes heureux d'annoncer qu'Electron a été accepté en tant qu'organisation de mentorat pour la 20e édition du Google Summer of Code (GSoC) 2024 ! Le Google Summer of Code est un programme mondial visant à amener de nouveaux contributeurs à participer au développement de logiciels libres.

Pour plus de détails sur le programme, consultez la page d'accueil de Google Summer of Code.

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. Toutes les idées listées sont actuellement ouvertes aux propositions.

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.

Votre candidature devra inclure :

• Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
• Votre expérience en tant que développeur. 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.

Questions?​

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!

Ressources​

• 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.

Comment ça marche ?​

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

Le premier commit dans le dépôt electron/electron date du 13 mars 2013¹.

10 ans et 27 147 commits supplémentaires de 1192 contributeurs uniques plus tard, Electron est devenu l'un des frameworks les plus populaires pour la construction d'applications de bureau aujourd'hui. Ce étape importante est l'occasion parfaite de célébrer et de réfléchir au parcours effectué jusqu’à maintenant, et de partager ce que nous avons appris au fil du temps.

Nous ne serions pas ici aujourd’hui sans tous ceux qui ont consacré leur temps et leurs efforts à ce projet. Bien que les commits de code source soient toujours les contributions les plus visibles, nous devons également saluer les efforts des personnes qui signalent les bogues, tiennent à jour les modules d’utilisateur, fournissent de la documentation et des traductions, et participent à la communauté Electron à travers le cyberespace. Chaque contribution est inestimable pour nous en tant que responsables.

Avant de continuer avec le reste du billet : un grand merci. ❤️

Comment en sommes-nous arrivés là?​

Atom Shell a été construit pour être la colonne vertébrale de l’éditeur Atom de GitHub, présenté au public en version bêta en avril 2014. Construit en partant de zéro comme une alternative aux framework de bureau basé sur le web disponibles à l’époque (node-webkit et Chrome Embedded Framework). Son aspect le plus remarquable etait d' intégrer Node.js et Chromium pour fournir un environnement d’exécution de bureau puissant aux technologies web.

En moins d’un an, Atom Shell a commencé à voir une croissance très importante en terme de capacités et de popularité. Les grandes entreprises, les startups et les développeurs individuels ont commencé à l'utiliser pour construire des applications (parmi les premiers utilisateurs figurent Slack, GitKraken et WebTorrent), et le projet a été renommé judicieusement Electron.

A partir de ce moment, Electron a démarré sur les chapeaux de roue et ne s'est jamais arrêté. Voici un aperçu de notre decompte hebdomadaire de téléchargements au fil du temps, c'est une gracieuseté de npmtrends.com :

Electron v1 a été publié en 2016, promettant une meilleure stabilité de l'API et de meilleurs outils et documentation. Electron v2 a été publié en 2018 et a introduit le versionnage sémantique, ce qui permet aux développeurs d'Electron de garder une trace du cycle de publication.

Avec Electron v6, nous sommes passés à une cadence régulière de 12 semaines pour s'aligner sur celle de Chromium. Cette décision a été un changement de mentalité pour le projet, le fait d'avoir la version Chromium la plus à jour passant d'un souhait à une priorité. Cela a réduit la dette technologique entre les mises à niveau, ce qui nous a permis de garder Electron à jour et sécurisé.

Depuis lors, la machine tourne bien avec une nouvelle version Electron publiée le même jour que Chromium pour chaque version stable. Lorsque Chromium a accéléré sa cadence de libération en passant à 4 semaines en 2021, nous avons modifié sans problème la notre en conséquence.

Nous sommes maintenant à Electron v23 et nous sommes toujours dédiés à construire le meilleur runtime pour créer des applications de bureau multiplateformes. Même avec l'explosion du nombre d'outils de développement JavaScript ces dernières années, Electron est resté un pilier stable et éprouvé de la conception d'application pour bureau. Les applications Electron sont omniprésentes de nos jours : vous pouvez programmer avec Visual Studio Code, concevoir avec Figma, communiquez avec Slack, et prendre des notes avec Notion (entre autres choses). Nous sommes incroyablement fiers de ce résultat et nous sommes reconnaissants envers tous ceux qui ont rendus ce projet possible.

Qu’avons-nous appris en cours de route?​

Le chemin pour atteindre cette décennie a été long et sinueux. Voici quelques éléments clés qui nous ont aidés à gérer ce grand projet open source de façon durable.

Redimensionnement de la prise de décision répartie avec un modèle de gouvernance​

Un des défis que nous avons dû surmonter était de gérer la direction à long terme du projet lorsque la popularité d'Electron a explosé. Comment gérer le projet avec une équipe de quelques dizaines d’ingénieurs répartis dans différentes entreprises, dans différents pays et sous différents fuseaux horaires?

Dans les premiers temps, le groupe de mainteneurs d’Electron s'est fié à une coordination informelle, qui était rapide et légere pour les petits projets, mais ne pouvait pas s'adapter à une collaboration plus large. En 2019, nous sommes passés à un modèle de gouvernance avec différents groupes de travail ayant des domaines de responsabilité officiels. Cela a été déterminant pour la rationalisation des processus et l’attribution de de certaines parties du projet à des responsables spécifiques. Voici, de nos jours, la répartition des responsabilités des groupes de travail (GT):

• Assurer la publication des versions d'Electron (Releases WG)
• Mettre à jour Chromium et Node.js (Upgrades WG)
• Surveiller la conception de l'API publique (API WG)
• Garder Electron sécurisé (Security WG)
• Gérer le site Web, la documentation et l'outillage (Ecosystem WG)
• Sensibiliser les communautés et les entreprises (Outreach WG)
• Effectuer la modération de la communauté (Community & Safety WG)
• Maintenir notre infrastructure de compilation, nos outils pour les mainteneurs et nos services de cloud (Infrastructure WG)

À peu près en même temps que nous adoptions le modèle de gouvernance, nous avons également transféré la propriété d’Electron de GitHub à la Fondation OpenJS. Bien que l'équipe de base initiale travaille toujours chez Microsoft aujourd'hui, elle ne représente qu'une partie d'un groupe plus large de collaborateurs qui forment la gouvernance d'Electron.²

Bien que ce modèle ne soit pas parfait, il nous a convenu même pendant la traversée d'une pandémie mondiale et de vents macroéconomiques contraires . Pour le futur, nous prévoyons de réorganiser la charte de gouvernance pour qu'elle nous guide tout au long de la deuxième décennie d'Electron.

Communauté​

La partie communautaire d'un projet open source est un peu compliquée à gérer, surtout lorsque votre équipe de sensibilisation est composée d’une douzaine d’ingénieurs en trench indiquant « community manager ». Cela dit, étant un grand projet open source signifie d'avoir un gran nombre d'utilisateurs, et l'exploitation de leur énergie disponible pour Electron pour construise un écosystème utilisateur est un élément crucial pour le maintien de la santé du projet.

Qu’avons-nous fait pour renforcer notre présence communautaire?

Construction de communautés virtuelles​

• En 2020, nous avons lancé notre serveur communautaire Discord. Nous avions auparavant une section dans le forum d’Atom, mais avons décidé d’avoir une plateforme de messagerie plus informelle pour avoir un espace de discussion entre responsables et développeurs Electron ainsi que pour l’aide générale au débogage.
• En 2021, nous avons créé le groupe d'utilisateurs Electron China avec l'aide de @BlackHole1. Ce groupe a contribué à la croissance du nombre d'utilsateurs d’Electron de la scène technologique qui est en plein essor en Chine, leur offrant un espace pour collaborer sur des idées et discuter d’électron en dehors des espaces de langue anglaise. Nous aimerions également remercier cnpm pour leur travail de support des publications nocturnes d'Electron dans leur miroir chinois de npm.

Participation à des programmes open source à haute visibilité​

• Nous célébrons Hacktoberfest chaque année depuis 2019. Hacktoberfest est une célébration annuelle de l'open source organisée par DigitalOcean, et nous recevons chaque année des dizaines de contributeurs enthousiastes cherchant à se démarquer dans le domaine du logiciel libre.
• En 2020, nous avons participé à la première de Google Season of Docs, où nous avons travaillé avec @bandantonio pour retravailler le nouveau flux de tutoriels utilisateur d'Electron.
• En 2022, pour la première fois, nous avons encadré un étudiant pour son Google Summer of Code . @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

Automatisation maximale!​

Aujourd'hui, la gouvernance d'Electron compte environ 30 responsables actifs. Moins de la moitié d'entre nous sont des contributeurs à temps plein, ce qui implique beaucoup de travail. Quelle est notre astuce pour que tout fonctionne sans heurts ?: Notre devise est que les ordinateurs sont bon marché, et que le temps humain coûte cher. En tant qu’ingénieurs typiques, nous avons développé une suite d’outils de soutien automatisés pour nous rendre la vie plus facile.

Not Goma​

Le cœur de la base de code Electron est un mastodonte de code C++, et les temps de compilation ont toujours été un facteur limitant pour la rapidité avec laquelle nous pouvons livrer des corrections de bugs et de nouvelles fonctionnalités. En 2020, nous avons déployé Not Goma, un backend personnalisé spécifique à Electron pour le service de compilation distribué Goma de Google. Ne pas Goma traite les demandes de compilation des machines de l'utilisateur autorisé et distribue le processus sur des centaines de cœurs dans le backend. Il met également en cache le résultat de la compilation de sorte que quelqu'un d'autre compilant les mêmes fichiers n'aura besoin que de télécharger le résultat pré-compilé.

Depuis le lancement de Not Goma, les temps de compilation pour les responsables sont passés de plusieurs heures à quelques minutes. Une connexion internet stable est devenue la condition minimale pour que les contributeurs compilent Electron!

Authentification continue​

L'authentification continue à plusieurs facteurs(CFA) est une couche d'automatisation autour du système d'authentification à deux facteurs (2FA) de npm que nous avons combinée combinons avec semantic release afin de gérer les publications sécurisées et automatisées de nos différents paquets @electron/ npm.

Alors que le versionnage sémantique automatise déjà le processus de publication des paquets npm, il faut désactiver authentification à deux facteurs ou passage d’un jeton secret qui contourne cette restriction.

Nous avons conçu le CFA pour fournir un mot de passe à usage unique (TOTP) pour les tâches de CI arbitraires, nous permettant ainsi d’exploiter l’automatisation du versionage sémantique tout en conservant la sécurité supplémentaire de l'authentification à deux facteurs.

Nous utilisons CFA avec une intégration frontale Slack, permettant aux responsables de valider la publication des paquets de n’importe quel appareil qu’ils ont Slack, tant qu’ils ont leur générateur TOTP à portée de main.

Sheriff​

Sheriff est un outil open source que nous avons écrit pour automatiser la gestion des permissions à travers GitHub, Slack et Google Workspace.

L'apport de sheriff vient du fait que la gestion des autorisations devrait être un processus transparent. Il utilise un seul fichier de configuration YAML désignant les autorisations pour tous les services énumérés ci-dessus. Avec Sheriff, obtenir le statut de collaborateur sur un dépôt ou créer une nouvelle liste de diffusion est aussi simple que faire approuver et fusionner un Push request.

Sheriff a également un journal d'audit publie vers Slack, avertissant les administrateurs lorsque des activités suspectes se produisent n'importe où dans l'organisation Electron.

… et tous nos robots de GitHub​

GitHub est une plate-forme avec une extensibilité API riche et un robot de framework d'application appelé Probot. Pour nous aider à nous concentrer sur les parties les plus créatives de notre travail, nous avons construit une suite de robots moins conséquents nous aidant à faire le sale boulot pour nous. Voici quelques exemples :

• Sudowoodo automatise le processus de publication da A à Z, du lancement des compilations au téléchargement des ressources de publication sur GitHub et npm.
• Trop automatise le processus de rétroportage d' Electron en essayantr de choisir des correctifs sur mesure pour les branches de diffusion précédentes en fonction des étiquettes PR de GitHub.
• Rouleau automatise les mises à jour en cours des dépendances Chromium et Node.js d'Electron.
• Cation est notre robot de vérification de l’état des Pull Request.

Dans l'ensemble, notre petite famille de bots nous a donné un énorme coup de pouce pour améliorer la productivité des développeurs!

Et ensuite ?​

Alors que nous entrons dans la deuxième décennie de notre projet, vous vous demanderez peut-être : que va t-il se passer maintenant pour Electron?

Nous allons demeurer en phase avec la cadence de sortie de Chromium, libérant de nouvelles versions majeures d'Electron toutes les 8 semaines en conservant les mises à jour relatives aux nouvautés les plus importants du web et de Node.js tout en maintenant la stabilité et la sécurité pour les applications de niveau entreprise.

Nous présentons généralement les initiatives à venir quand elles deviennent concrètes. Si vous voulez rester au courant des versions, des fonctionnalités et des mises à jour générales du projet, vous pouvez lire notre blog et nous suivre sur les médias sociaux (Twitter et Mastodon ) !

L'équipe d'Electron est excitée de vous annoncer que nous allons participer au Google Summer of Code pour la première fois cette année!

Qu'est ce que le Google Summer of Code?​

Le Google Summer of Code (GSoC) est un programme de mentorat annuel qui rassemble plusieurs projets de logiciel open source avec des contributeurs potentiels. Récemment ouvert seulement pour les étudiants, n'importe qui ayant 18 ans et plus peut désormais s'inscrire pour le GSoC.

Pour plus d'informations, rendez-vous sur la page d'accueil du Summer of Code.

Comment s'inscrire ?​

Êtes-vous intéressé à collaborer avec Electron? Si vous êtes nouveau ou débutant dans la contribution de l'open source, nous vous invitons à postuler !

Dans le but d'être sélectionné comme contributeur Electron pour le Google Summer of Code, vous allez devoir soumettre une candidature. Les candidatures ouvriront le 4 avril 2002 et s'arrêterons le 19 avril 2022. Vous pouvez suivre les actualités et directives pour les candidatures du Google Summer of Code ici.

Envie de postuler ? Premièrement, regardez les cinq idées brouillons de projets que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions. Nous acceptons également de nouvelles idées que nous n'avons pas proposées dans la liste des projets.

Votre candidature devra inclure :

• Votre proposition, avec un document écrit qui décrit en détail votre plan de ce que vous comptez achever au cours de cet été.
• Votre expérience en tant que développeur. Si vous avez un C.V, merci de l'inclure une copie, par ailleurs, parlez-nous de vos expériences passées en mettant l'accent sur vos expériences techniques pertinentes.

Un guide détaillé de ce qu'il faut soumettre dans le cadre de votre candidature Electron est ici.

Vous pouvez également lire le guide officiel pour les étudiants et contributeurs du GSoC afin d'obtenir de précieux conseils sur la préparation de votre candidature.

Si vous souhaitez discuter de proposition de projet ou si vous avez des questions, visitez notre canal Discord #gsoc-general !

Références​

• Guide de propositions d'Electron
• GitHub d'Electron
• Documents des idées de projet
• Guide pour les étudiants et contributeurs du GsoC

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!

Pourquoi un nouveau serveur Discord ?​

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.

Faites Attention aux problèmes marqués hacktoberfest sur nos différents référentiels, y compris le principal electron/electron, le site electron/electronjs.org , electron/fiddle, et electron-userland/electron-forge !

P.S. Si vous vous sentez particulièrement aventureux et à la recherche de défis., nous avons également un arriéré de problèmes marqués par les tags help wanted.

Bloqué ? Come chat with us!​

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. Au cas où vous l’auriez manqué, voici le lien d’invitation à nouveau!

Electron est fier de participer à la deuxième édition de l'initiative de Google Season of Docs, qui associe des mentors d'organisations open source avec des rédacteurs techniques pour améliorer la documentation du projet.

Qu'est-ce que Season of Docs ?

Season of Docs est un programme qui favorise la collaboration entre les rédacteurs techniques et les communautés open source au profit des deux parties. Les responsables de l’open source utilisent l’expertise technique de rédaction de l’auteur pour améliorer la structure et le contenu de leur documentation, tandis que le rédacteur technique est présenté à une communauté open source sous la direction de ses mentors. En savoir plus à ce sujet sur le site Web de google Season of Docs.

Pour la première fois que nous participerons au programme, nous encadrerons un seul rédacteur technique qui travaillera aux côtés du groupe de travail sur l’écosystème d’Electron pour remodeler de grandes parties de notre documentation. Vous pouvez en savoir plus sur la chronologie de l’ensemble du projet ici.

Comment s'inscrire ?

Êtes-vous intéressé à collaborer avec nous en tant que rédacteur technique ? Tout d’abord, familiarisez-vous avec le guide du rédacteur technique de Google pour le programme de cette année et consultez les deux ébauches d’idées de projet que nous avons préparées.

Afin d’être sélectionnés en tant que rédacteur technique d’Electron pour Season of Docs, les candidats devront postuler sur le site Web google Season of Docs pendant la phase de candidature rédatcteur technique qui se déroule du 8 juin au 9 juillet..

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!

Références

• Documentation d'Electron
• Document d’idées de projet
• Guide du rédacteur technique de Season of Docs

Electron travaille à rendre ses cycles de publication plus rapides et plus stables. Pour rendre cela possible, nous avons lancé le programme de rétroaction pour les applications Electron à grande échelle pour tester nos versions bêta et nous signaler les problèmes spécifiques à l'application. Cela nous aide à prioriser le travail qui fera passer les applications à notre prochaine version stable plus tôt.

Modification (21/05/2020): Ce programme a été retiré.

Qui peut rejoindre ?​

Nos critères et attentes pour les applications qui rejoignent ce programme incluent les éléments suivants :

• Testez votre application pendant la période bêta pour plus de 10 000 heures-utilisateurs
• Avoir une personne-ressource qui vérifiera chaque semaine pour discuter des bogues d'Electron de votre application et des bloqueurs d'applications
• Vous avez accepté de vous conformer au Code de conduite d'Electron
• Vous êtes prêt à partager les informations énumérées dans la question suivante

Quelles informations mon application Electron a-t-elle à partager ?​

• Total des heures d'utilisation de votre application avec n'importe quelle version bêta
• Version d'Electron avec laquelle votre application teste (par exemple, 4.0.0-beta.3)
• Tout bug empêchant votre application de passer à la ligne de publication en cours de test bêta

Heures-utilisateurs​

Nous comprenons que tout le monde ne peut pas partager des nombres d'utilisateurs exacts, mais de meilleures données nous aident à décider de la stabilité d'une version en particulier. Nous demandons que les applications s'engagent à tester un nombre minimum d'heures-utilisateurs, actuellement 10 000 pour tout le cycle bêta.

• 10 heures-utilisateurs peuvent être de 10 personnes testant pendant une heure ou une personne testant pendant 10 heures
• Vous pouvez diviser les tests entre des versions bêta, par exemple ceux pour 5 000 heures d'utilisateurs sur la version 3.0.0-beta et ensuite ceux pour 5 000 heures sur 3.0.0-beta.5. Plus on fait, mieux c'est, mais nous comprenons que certaines applications ne peuvent pas tester chaque version bêta
• Les heures d'intégration continue ou d'assurance qualité ne sont pas prises en compte dans le total, cependant, les versions internes comptent

Pourquoi mon application Electron devrait-elle rejoindre ?​

Les bogues de votre application seront suivis et seront sur le radar de l'équipe d'Electron. Vos commentaires aident l'équipe d'Electron à voir comment les nouvelles bêta font et ce qui doit être fait.

Les informations de mon application seront-elles partagées publiquement? Qui peut voir cette information?​

Non, les renseignements de votre application ne seront pas partagés publiquement. Les informations sont conservées dans un dépôt GitHub privé qui n'est visible que par les membres du programme de rétroaction de l'application et Electron Governance. Tous les membres ont accepté de suivre le Code de conduite d'Electron.

S'inscrire​

Nous acceptons actuellement un nombre limité d'inscriptions. Si vous êtes intéressé et êtes en mesure de remplir les conditions ci-dessus, veuillez remplir ce formulaire.

Cette semaine, nous avons interviewé le créateur de Jasper, un outil basé sur Electron pour gérer les notifications GitHub.

Hello! Qui es-tu ?​

I'm Ryo Maruyama, a software developer in Japan. I am developing Jasper and ESDoc.

What is Jasper?​

Jasper est un lecteur de tickets flexible et puissant pour GitHub. It supports issues and pull requests on github.com and GitHub Enterprise.

Why did you make it?​

When people use GitHub in their job or OSS activities, they tend to receive many notifications on a daily basis. As a way to subscribe to the notifications, GitHub provides email and web notifications. I used these for a couple of years, but I faced the following problems:

• 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.

Who's using 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!

How does Jasper work?​

Once Jasper is configured, the following screen appears. From left to right, you can see "streams list", "issues list" and "issue body".

This "stream" is the core feature of Jasper. For example, if you want to see "issues that are assigned to @zeke in the electron/electron repository", you create the following 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.

What can we do with streams?​

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

Users and Teams​

involves means mention, author, assignee or commenter

Repositories and Organizations​

org is same as user

Attributs​

Review Status​

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.

Is Jasper a paid product? How much does it cost?​

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

Why did you choose to build Jasper on Electron?​

I like the following aspects of Electron:

• Apps can be developed with JavaScript/CSS/HTML.
• Apps can be built for Windows, Mac, and Linux platforms.
• Electron is actively developed and has a large 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.

What are some challenges you've faced while developing Jasper?​

I had a hard time figuring out the "stream" concept. Au début, j'ai envisagé d'utiliser l'API Notifications de GitHub. However I noticed that it does not support certain use cases. Après cela, j'ai envisagé d'utiliser l'API Issues API et Pull Requests API, en plus de l'API de notification. But it never became what I wanted. Puis en pensant à diverses méthodes, j'ai réalisé que le sondage de l'API de recherche de GitHub offrirait la plus grande flexibilité. 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.

What's coming next?​

I have a plan to develop the following features:

• A filtered stream: A stream has some filtered stream that filter issues in the stream. It is like as view of SQL.
• Multiple accounts: you will be able to use both github.com and GHE
• Improve performance: For now the loading a issue in WebView is low speed than normal browser.

Follow @jasperappio on Twitter for updates.