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

   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.

¡Estamos encantados de anunciar que Electron ha sido aceptado como una organización mentora para la vigésima edición de Google Summer of Code (GSoC) 2024! Google Summer of Code es un programa global centrado en traer nuevos colaboradores al desarrollo de software de código abierto.

Para obtener más detalles del programa, consulta la página de inicio de Summer of Code.

Sobre nosotros​

Electron es un framework JavaScript para construir aplicaciones multiplataforma de escritorio usando tecnologías web. El framework central de Electron es un ejecutable binario compilado construido con Chromium y Node.js, y está escrito principalmente en C++.

Fuera del núcleo de Electron, también trabajamos en una variedad de proyectos para ayudar a sostener la organización de Electron como:

• Herramientas de distribución del usuario final (por ejemplo, Electron Forge y update.electronjs.org).
• Material de aprendizaje para desarrolladores de Electron (por ejemplo, electronjs.org y Electron Fiddle).
• Herramientas internas para optimizar la productividad del desarrollador (por ejemplo, Electron Build Tools y Sheriff).

Como colaborador de Summer of Code, estarías colaborando con algunos de los principales colaboradores de Electron en uno de los muchos proyectos bajo el paraguas github.com/electron.

Antes de aplicar​

Si no estás muy familiarizado con Electron, te recomendamos que comiences leyendo la documentación y probando ejemplos en Electron Fiddle.

Para obtener más información sobre la distribución de aplicaciones Electron también puede jugar con Electron Forge creando una aplicación de muestra:

npm init electron-app@latest my-app

Después de familiarizarte un poco con el código, ven a unirte a la conversación en el Servidor de Discord de Electron.

Elaborando su propuesta​

¿Estás interesado en colaborar con Electron? Primero, revisa los siete borradores de ideas del proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas.

¿Tienes una idea diferente que te gustaría tener en cuenta? También estamos abiertos a aceptar nuevas ideas que no están en la lista de proyectos propuestos. pero asegúrese de que su enfoque está completamente esbozado y detallado. En caso de duda, le recomendamos que se aferre a nuestras ideas listadas.

Su solicitud debe incluir:

• Tu propuesta: un documento escrito que describe en detalle lo que planeas lograr durante el curso del verano.
• Su experiencia como desarrollador. Si tiene un currículum, por favor incluya una copia. De lo contrario, cuéntanos tu experiencia técnica pasada.
  • La falta de experiencia en ciertas áreas no te descalificará, pero ayudará a nuestros mentores a elaborar un plan para ayudarte mejor y asegurarte de que tu proyecto de verano sea un éxito.

[Aquí está una guía detallada de qué enviar como parte de tu aplicación Electron.](https://electronhq.notion. ite/Electron-GSoC-2024-Contributor-Guidance-f1f4de7a0d9a4664a96c8d4dd70cb208?pvs=4) Enviar propuestas directamente al portal de Google Summer of Code. Tenga en cuenta que las propuestas enviadas por correo electrónico al equipo Electron en lugar de enviarlas a través del portal de la aplicación no serán consideradas como un envío final.

Si desea más orientación sobre su propuesta o no está seguro de qué incluir, también recomendamos que sigas [la propuesta oficial de Google Summer of Code escribiendo consejos aquí](https://google. ithub.io/gsocguides/student/writing-a-proposal).

Aplicaciones abiertas el 18 de marzo de 2024 y cierran el 2 de abril de 2024.

¿Preguntas?​

Si tienes preguntas que no enviamos en las publicaciones del blog o consultas para tu borrador de propuestas, por favor envíanos un correo electrónico a Summer-of-code@electronjs. rg o revisa GSoC FAQ!

Recursos​

• Electron Google Summer of Code 2024 Lista de ideas
• Electron Google Summer of Code 2024 Orientación para contribuyentes
• Guía para estudiantes/colaboradores de Google Summer of Code

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.

¿Cómo funciona?​

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

El primer commit en el repositorio electron/electron fue el 13 de marzo de 2013¹.

10 años y 27.147 commits más de 1192 colaboradores únicos después, Electron se ha convertido en uno de los frameworks más populares para crear aplicaciones de escritorio hoy en día. Este hito es la oportunidad perfecta para celebrar y reflexionar sobre nuestro viaje hasta ahora, y para compartir lo que hemos aprendido en el camino.

No estaríamos aquí hoy sin todos los que han dedicado su tiempo y esfuerzo a contribuir al proyecto. Aunque los commits del código fuente son siempre las contribuciones más visibles, también tenemos que reconocer el esfuerzo de la gente que informa de errores, mantiene módulos de usuario, proporciona documentación y traducciones, y participa en la comunidad Electron a través del ciberespacio. Cada contribución tiene un valor incalculable para nosotros como mantenedores.

Antes de continuar con el resto de la entrada del blog: gracias. ❤️

¿Cómo hemos llegado hasta aquí?​

Atom Shell se construyó como la columna vertebral para el editor Atomde GitHub, que se lanzó en beta pública en abril de 2014. Se construyó desde cero como alternativa a los frameworks de escritorio basados en web disponibles en ese momento (node-webkit y Chromium Embedded Framework). Tenía una característica estrella: contiene Node.js y Chromium para proporcionar un potente tiempo de ejecución de escritorio para tecnologías web.

Al cabo de un año, Atom Shell empezó a crecer enormemente en capacidades y popularidad. Grandes compañías, startups y desarrolladores individuales habían empezado a construir aplicaciones con él (algunos de los primeros adoptores incluyen Slack, GitKraken, y WebTorrent), y el proyecto fue renombrado correctamente a Electron.

Desde entonces, Electron no ha parado de crecer. Aquí tienes un vistazo a nuestro recuento semanal de descargas con el tiempo, cortesía de npmtrends.com:

Electron v1 se lanzó en 2016, prometiendo una mayor estabilidad de la API y mejores documentos y herramientas. Electron v2 se lanzó en 2018 e introdujo el versionado semántico, lo que facilita a los desarrolladores de Electron a los desarrolladores hacer un seguimiento del ciclo de lanzamiento.

En Electron v6, cambiamos a una cadencia regular de lanzamientos principales de 12 semanas para ajustarnos a la de Chromium. Esta decisión supuso un cambio de mentalidad para el proyecto, haciendo que "tener la versión más actualizada de Chromium" pasara de ser un "nice-to-have" a una prioridad. Esto ha reducido la cantidad de deuda técnica entre actualizaciones, lo que nos facilita mantener Electron actualizado y seguro.

Desde entonces, hemos sido una máquina bien engrasada, lanzando una nueva versión de Electron el mismo día que cada versión estable de Chromium. Cuando Chromium aceleró su calendario de lanzamientos a 4 semanas en 2021, pudimos encogernos de hombros y aumentar nuestra cadencia de lanzamiento a 8 semanas.

Ahora estamos en Electron v23 (y contando), y seguimos dedicados a construir el mejor tiempo de ejecución para aplicaciones de escritorio multiplataforma. Incluso con el auge de las herramientas para desarrolladores de JavaScript en desarrolladores de JavaScript en los últimos años, Electron se ha mantenido estable y ha de escritorio. Las aplicaciones de Electron son omnipresentes hoy en día: puedes programar con Visual Studio Code, diseñar con Figma, comunicarte con Slack y tomar notas con Notion (entre muchos otros casos de uso). Estamos increíblemente orgullosos de este logro y agradecidos con todos aquellos que lo hicieron posible.

¿Qué aprendimos en el camino?​

El camino hacia la marca de la década ha sido largo y sinuoso. Aquí hay algunas claves que nos han ayudado a mantener un proyecto de código abierto grande y sostenible.

Escalando la toma de decisiones distribuida con un modelo de gobernanza​

Uno de los desafíos que tuvimos que superar fue manejar la dirección a largo plazo del proyecto una vez que Electron explotó en popularidad. ¿Cómo manejamos ser un equipo de varias docenas de ingenieros distribuidos en diferentes empresas, países y zonas horarias?

En los primeros días, el grupo de mantenimiento de Electron dependía de la coordinación informal, lo que es rápido y ligero para proyectos más pequeños, pero no es escalable para una colaboración más amplia. En 2019, cambiamos a un modelo de gobernanza donde diferentes grupos de trabajo tienen áreas formales de responsabilidad. Esto ha sido fundamental para optimizar los procesos y asignar porciones de propiedad del proyecto a mantenedores específicos. ¿De qué es responsable cada Grupo de Trabajo (WG) en la actualidad?

• Sacar las versiones de Electron (Releases WG)
• Actualizar Chromium y Node.js (Upgrades WG)
• Supervisar el diseño de la API pública (API WG)
• Mantener Electron seguro (Security WG)
• Administrar el sitio web, documentación y herramientas (Ecosystem WG)
• Alcanzar a la comunidad y a las empresas (Outreach WG)
• Moderación de la comunidad (Community & Safety WG)
• Mantener nuestra infraestructura de compilación, herramientas de mantenedor y servicios en la nube (Infrastructure WG)

Alrededor de la misma época en que cambiamos al modelo de gobernanza, también trasladamos la propiedad de Electron de GitHub a la OpenJS Foundation. Aunque el equipo central original todavía funciona en Microsoft hoy, son sólo parte de un grupo de colaboradores más grande que forman la gobernanza de Electron.²

Si bien este modelo no es perfecto, nos ha funcionado bien a través de una pandemia global y vientos macroeconómicos en curso. En el futuro, planeamos renovar la carta de gobernanza para guiarnos a través de la segunda década de Electron.

Comunidad​

La parte de la comunidad de código abierto es difícil, especialmente cuando tu equipo de divulgación está compuesto por una docena de ingenieros disfrazados con una gabardina que dice "gerente de comunidad". Dicho esto, ser un proyecto de código abierto grande significa que tenemos muchos usuarios, y aprovechar su energía para construir un ecosistema de usuarios para Electron es una parte crucial para mantener la salud del proyecto.

¿Qué hemos estado haciendo para desarrollar nuestra presencia en la comunidad?

Construyendo comunidades​

• En 2020, lanzamos nuestro servidor de Discord. Anteriormente teníamos una sección en el foro de Atom, pero decidimos tener una plataforma de mensajería más informal para tener un espacio para discusiones entre mantenedores y desarrolladores de Electron, así como para obtener ayuda general de depuración.
• En 2021, establecimos el grupo de usuarios de Electron China con la ayuda de @BlackHole1. Este grupo ha sido fundamental para el crecimiento de Electron en usuarios de la floreciente escena tecnológica de China, proporcionando un espacio para que colaboren en ideas y discutan sobre Electron fuera de nuestros espacios en inglés. También nos gustaría agradecer a cnpm por su trabajo en apoyar las versiones nocturnas de Electron en su espejo chino para npm.

Participar en programas de código abierto de alta visibilidad​

• Desde 2019 hemos estado celebrando el Hacktoberfest cada año. Hacktoberfest es una celebración anual de código abierto organizada por DigitalOcean, y desde 2019 hemos estado participando en ella. Cada año recibimos docenas de entusiastas contribuyentes que buscan dejar su huella en el software de código abierto.
• En 2020, participamos en la primera iteración de Google Season of Docs, donde trabajamos con @bandantonio para reorganizar el flujo del tutorial de usuario nuevo de Electron.
• En 2022, mentorizamos a un estudiante en el programa Google Summer of Code por primera vez. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

¡Automatiza todas las cosas!​

Hoy en día, la gobernanza de Electron cuenta con alrededor de 30 mantenedores activos. Menos de la mitad de nosotros somos contribuidores a tiempo completo, lo que significa que hay mucho trabajo para compartir. ¿Cuál es nuestro truco para mantener todo funcionando sin problemas? Nuestro lema es que las computadoras son baratas y el tiempo humano es caro. Al estilo típico de los ingenieros, hemos desarrollado una serie de herramientas de soporte automatizadas para facilitar nuestras vidas.

Not Goma​

La base de código principal de Electron es un gigante de código en C++, y los tiempos de compilación siempre han sido un factor limitante en la velocidad con la que podemos implementar correcciones de errores y nuevas funcionalidades. En 2020, implementamos Not Goma, una plataforma personalizada específica para Electron para el servicio de compilador distribuido de Google llamado Goma. Not Goma procesa las solicitudes de compilación de las máquinas autorizadas de los usuarios y distribuye el proceso en cientos de núcleos en el backend. Además, Not Goma también almacena en caché el resultado de la compilación para que alguien más que compile los mismos archivos solo necesite descargar el resultado precompilado.

Desde que lanzamos Not Goma, los tiempos de compilación para los mantenedores han disminuido de varias horas a unos pocos minutos. ¡Una conexión estable a internet se convirtió en el requisito mínimo para que los contribuyentes pudieran compilar Electron!

Autenticación de Factor Continuo​

Autenticación de Factor Continuo (CFA) es una capa de automatización en torno al sistema de autenticación de dos factores (2FA) de npm que combinamos con semantic-release para gestionar lanzamientos seguros y automatizados de nuestros diversos paquetes npm de @electron/.

Mientras que semantic-release ya automatiza el proceso de publicación de paquetes de npm, requiere desactivar la autenticación de dos factores o pasar un token secreto que evita esta restricción.

Construimos CFA para entregar una contraseña de un solo uso basada en el tiempo (TOTP) para el 2FA de npm a trabajos de integración continua (CI) arbitrarios, lo que nos permite aprovechar la automatización de semantic-release manteniendo la seguridad adicional de la autenticación de dos factores.

Usamos CFA con una interfaz integrada en Slack, lo que permite a los mantenedores validar la publicación de paquetes desde cualquier dispositivo en el que tengan Slack, siempre y cuando tengan su generador de TOTP a mano.

Sheriff​

Sheriff es una herramienta de código abierto que escribimos para automatizar la gestión de permisos en GitHub, Slack y Google Workspace.

La propuesta de valor clave de Sheriff es que la gestión de permisos debe ser un proceso transparente. Utiliza un único archivo de configuración YAML que designa los permisos en todos los servicios mencionados anteriormente. Con Sheriff, obtener el estado de colaborador en un repositorio o crear una nueva lista de correo es tan fácil como obtener la aprobación y la fusión de una PR.

Sheriff también cuenta con un registro de auditoría que se publica en Slack, alertando a los administradores cuando ocurre actividad sospechosa en cualquier lugar de la organización Electron.

... y todos nuestros bots de GitHub​

GitHub es una plataforma con una amplia extensibilidad de API y un marco de aplicación de bot de "first-party" llamado Probot. Para ayudarnos a enfocarnos en las partes más creativas de nuestro trabajo, creamos una suite de bots más pequeños que nos ayudan a realizar el trabajo sucio. Aquí hay algunos ejemplos:

• Sudowoodo automatiza el proceso de lanzamiento de Electron de principio a fin, desde el inicio de compilaciones hasta la carga de activos de lanzamiento en GitHub y npm.
• Trop automatiza el proceso de retroportar para Electron al intentar seleccionar parches a ramas de lanzamiento anteriores basadas en las etiquetas de PR de GitHub.
• Roller automatiza las actualizaciones rodantes de las dependencias de Chromium y Node.js de Electron.
• Cation es nuestro bot de verificación de estado para las PR de electron/electron.

¡En conjunto, nuestra pequeña familia de bots nos ha dado un gran impulso en la productividad de los desarrolladores!

¿Qué sigue?​

Al entrar en nuestra segunda década como proyecto, es posible que te preguntes: ¿qué sigue para Electron?

Vamos a mantenernos en sincronía con el ritmo de lanzamiento de Chromium, publicando nuevas versiones principales de Electron cada 8 semanas, manteniendo el framework actualizado con lo último y lo mejor de la plataforma web y Node.js mientras mantenemos la estabilidad y seguridad para aplicaciones de calidad empresarial.

Generalmente anunciamos noticias sobre próximas iniciativas cuando se vuelven concretas. ¡Si quieres estar al tanto de futuros lanzamientos, funciones y actualizaciones generales del proyecto, puedes leer nuestro blog y seguir nuestros perfiles en redes sociales (Twitter y Mastodon)!

¡El equipo de Electrón está encantado de anunciarles que por primera vez en este año estaremos en el Google Summer of Code!

¿Qué es Google Summer of Code?​

Google Summer of Code (GSoC) celebrado cada año, es un programa de mentorías que busca conectar proyectos de código abierto con futuros posibles colaborares. Anteriormente solo era abierto para estudiantes, ahora cualquier persona mayor de 18 años puede registrarse en Google Summer of Code.

Para obtener más información, consulte Summer of Code.

¿Cómo me registro?​

¿Estás interesado en colaborar con Electrón? ¡Si eres un colaborador novato o principiante en el código abierto, le damos la bienvenida a su solicitud!

Para ser seleccionado como colaborador de Electron para Google Summer of Code, deberá enviar una solicitud. Las solicitudes se abrirán el 4 de abril de 2022 y se cerrarán el 19 de abril de 2022. Puedes seguir las actualizaciones de Google: las directrices de aplicación de verano de código aquí.

¿Quieres presentar tu candidatura? Primero, revisa los cinco borradores de ideas de proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas. También estamos abiertos a aceptar nuevas ideas que no estén en la lista de proyectos propuestos.

Su solicitud debe incluir:

• Tu propuesta, que es un documento escrito que describe en detalle lo que planeas conseguir en el transcurso del verano.
• Su experiencia como desarrollador. Si tiene un currículum vitae, incluya una copia; de lo contrario, háblenos de su experiencia anterior haciendo hincapié en la experiencia técnica relevante.

Aquí encontrará una guía detallada de lo que debe presentar como parte de su solicitud Electron.

También puedes leer la guía oficial de estudiantes/colaboradores de GSoC para obtener consejos importantes sobre cómo preparar tu propuesta.

Si quieres hablar sobre propuestas de proyectos o tienes alguna pregunta, ¡ven a nuestro canal de Discord #gsoc-general!

Referencias​

• Guía de propuesta de Electron
• Electron GitHub
• Documento de ideas del proyecto
• Google Summer of Code Student/Contributor Guide

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

Lanzamiento de la comunidad de Electron en Discord

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

¿Por qué un nuevo servidor de 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.

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? 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. In case you missed it, here's the invite link again!

Electron se enorgullece de estar participando en la segunda edición de la iniciativa de la Temporada de Documentación de Google (Google Season of Docs Initiative) que combina mentores de organizaciones de código abierto con escritores técnicos para mejorar la documentación del proyecto.

¿Qué es la Season of Docs?

Season of Docs es un programa que promueve la colaboración entre escritores técnicos y comunidades de código abierto en beneficio de ambas partes. Los mantenedores de código abierto utilizan la experiencia de escritura técnica del escritor para mejorar la estructura y el contenido de su documentación, mientras que el escritor técnico es presentado a una comunidad de código abierto bajo la guía de sus mentores. Obtenga más información sobre ello en el sitio web Season of Docs de Google.

Por primera vez participando en este programa, estaremos orientando a un solo escritor técnico que estará trabajando junto al Grupo de trabajo del ecosistema de Electron para remodelar partes de nuestra documentación. Puedes aprender más sobre la línea temporal de todo el proyecto aquí.

¿Cómo me registro?

¿Está interesado en colaborar con nosotros como escritor técnico? En primer lugar, familiarízate con la guía de escritura técnica de Google para el programa de este año y revisa los dos borradores de ideas del proyecto que hemos preparado.

Para ser seleccionado como escritor técnico de Electron para Season of Docs, los candidatos tendrán que solicitar en el sitio web de Google Season of Docs durante la fase de Solicitud de Escritor Técnico que se está ejecutando del 8 de junio al 9 de julio..

Tu solicitud debe incluir una propuesta, que es un documento escrito que describe en detalle lo que planeas lograr en los documentos de electrones durante el transcurso de 3 meses. Esta propuesta puede desarrollarse en uno de los puntos de partida mencionados en nuestro proyecto de idea doc, o puede ser algo completamente nuevo. ¿No sabes por dónde empezar? Puedes revisar la lista de propuestas aceptadas del año pasado para inspirarte.

Aparte de la propuesta, también estudiaremos sus antecedentes como escritor técnico. Por favor incluya una copia de su currículum con énfasis en la experiencia de escritura relevante, así como muestras técnicas de escritura (estas muestras podrían ser documentación existente, tutorial, artículos de blog, etc.)

Si quieres discutir las propuestas de proyecto, ¡envíanos un correo electrónico a season-of-docs@electronjs.org y podemos chatear desde ahí!

Referencias

• Documentación de Electron
• Documento de ideas del proyecto
• Temporada de la guía de escritor de tecnología de Docs

Estamos trabajando en hacer el ciclo de desarrollo de Electrón más rápido y estable. Para hacerlo posible, hemos iniciado el Programa de Comentarios de Aplicaciones para aplicaciones Electron a gran escala para probar nuestras versiones beta y reportarnos problemas específicos de la aplicación. Esto nos ayuda a priorizar el trabajo que hará que las aplicaciones se actualicen antes a nuestra próxima versión estable.

Edición (2020-05-21): Este programa ha sido retirado.

¿Quién puede unirse?​

Nuestros criterios y expectativas para que las aplicaciones se unan a este programa incluyen los siguientes elementos:

• Prueba tu aplicación durante el periodo beta durante más de 10.000 horas
• Tener una persona de un solo punto que chequee semanalmente para discutir los errores de su aplicación Electron y bloqueadores de aplicaciones
• Aceptas acatar el Código de Conducta de Electron
• Está dispuesto a compartir la siguiente información listada en la siguiente pregunta

¿Qué información debe compartir mi aplicación Electron?​

• Total de horas de funcionamiento de su aplicación con cualquier versión beta
• Versión de Electron con la que está probando su aplicación (por ejemplo, 4.0.0-beta.3)
• Cualquier error que impida que su aplicación de actualizar a la línea de publicación sea probado

Usuario / Horas​

Entendemos que no todos pueden compartir números de usuario exactos, sin embargo mejores datos nos ayudan a decidir cuán estable es una versión en particular. Pedimos que las aplicaciones se comprometan a probar un número mínimo de horas de usuario, actualmente 10.000 en todo el ciclo beta.

• 10 horas de usuario podrían ser 10 personas probando por una hora, o una persona probando por 10 horas
• Puede dividir la prueba entre versiones beta, por ejemplo prueba de 5.000 horas de usuario en 3.0.0-beta. y luego pruebe por 5.000 horas de usuario en 3.0.0-beta.5. Más es mejor, pero entendemos que algunas aplicaciones no pueden probar cada versión beta
• Las horas CI o QA no cuentan para el total; sin embargo, las versiones internas cuentan

¿Por qué debería unirse mi aplicación Electron?​

Los errores de tu aplicación serán rastreados y estarán en el radar del núcleo del equipo de Electron. Sus comentarios ayudan al equipo de Electron a ver cómo están haciendo las nuevas betas y qué trabajo hay que hacer.

¿Se compartirá la información de mi aplicación públicamente? ¿Quién puede ver esta información?​

No, la información de su aplicación no se compartirá con el público en general. La información se mantiene en un repositorio privado de GitHub que sólo es visible para los miembros del Programa de Comentarios de la aplicación y Gobernanza Electron. Todos los miembros han aceptado seguir el Código de Conducta de Electron.

Registrarse​

Actualmente estamos aceptando un número limitado de registros. Si está interesado y puede cumplir con los requisitos anteriores, por favor rellene este formulario.

Esta semana hemos entrevistado al creador de Jasper, una herramienta basada en Electron para administrar las notificaciones de GitHub.

¡Hola! ¿Quién eres?​

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

¿Qué es Jasper?​

Jasper es un lector de problemas flexible y potente para 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

Atributos​

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. Al principio consideré usar la API de Notificaciones de GitHub. However I noticed that it does not support certain use cases. Después de eso consideré usar la API de problemas y API de Pull Requests, además de la API de Notificación. But it never became what I wanted. Entonces mientras pensaba en varios métodos, me di cuenta de que el sondeo de la API de búsqueda de GitHub ofrecería la mayor flexibilidad. 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.