Mi Experiencia Contribuyendo al Código Abierto - Emptor

Contribuir al código abierto es una forma divertida de aprender y mejorar tus habilidades de codificación, y lo puedes hacer ayudando a otros. Las comunidades de código abierto suelen estar abiertas a nuevos participantes en un entorno de aprendizaje, lo que hace que la experiencia de contribuir sea agradable.

Una buena manera de decidir dónde contribuir es elegir el software de código abierto que uses a diario. En ese sentido, si conoces el software al que vas a contribuir, puedes identificar fácilmente dónde se necesita ayuda y dónde puedes agregar nuevas y interesantes funciones.

En este artículo, detallaré las contribuciones que he realizado y demostraré más o menos el flujo de trabajo de contribuir al código abierto. Los proyectos en los que me enfocaré son los siguientes:

scrapy: Framework de web crawling y scraping en Python.
jrnl: Aplicación de diario de texto para la línea de comandos.
polybar: Una herramienta rápida y fácil de usar para crear una barra de estado.

Scrapy | Agregar una nueva extensión para verificar los nombres de los ajustes

Scrapy es una herramienta muy personalizable; una de las principales formas de personalizarla es a través de los ajustes. Los ajustes de Scrapy te permiten personalizar el comportamiento de todos los componentes de Scrapy, incluido el núcleo, las extensiones, las tuberías y los propios spiders. La infraestructura de los ajustes proporciona un espacio de nombres global de asignaciones clave-valor que el código puede usar para extraer los valores de configuración.

Entonces, por ejemplo, si DNSCACHE_ENABLED se establece en True, nuestro spider habilitará la caché de DNS en memoria. Scrapy tiene MUCHAS variables configurables que son propensas a errores de tipeo y que no proporcionaban suficiente retroalimentación para que los nuevos usuarios descubrieran este error trivial.

Esta contribución intenta resolver ese problema creando una nueva extensión. Inicialmente, se propuso un linter para el problema, pero después de algunas discusiones, el consenso fue que un enfoque en tiempo de ejecución sería mejor. La extensión encuentra ajustes no utilizados leyendo un atributo (has_been_read) en el diccionario de ajustes y, si es posible, sugerirá un reemplazo posible. Otra ventaja de este enfoque en tiempo de ejecución es que también encontrará ajustes no utilizados que posiblemente no sean ajustes mal escritos.

PR: Agregar una nueva extensión para verificar los nombres de los ajustes

Scrapy | Agregar estadísticas de recuento de éxitos y fallos a los backends de Feedstorage

Scrapy permite a los usuarios especificar cómo exportar los datos extraídos (por ejemplo, .xml, .json, .csv, etc.) y también dónde guardarlos (el sistema de archivos local, S3, Google Cloud, un servidor FTP, salida estándar). Sin embargo, esos backends de almacenamiento no guardaban información de rendimiento al final de la ejecución. Un buen lugar para guardar esta información son las estadísticas que Scrapy genera durante la ejecución. Estas estadísticas se pueden usar para medir el rendimiento de la ejecución, ya que contienen estadísticas sobre el uso de memoria, la marca de tiempo de finalización, la marca de tiempo de inicio, etc.

La idea de este PR es agregar una nueva estadística que ayudará a los usuarios a saber si el backend de almacenamiento encontró algunos problemas mientras guardaba. Por ejemplo, si un spider guarda en S3 y en el sistema de archivos local, pero las credenciales de S3 eran incorrectas, esta estadística se presentará al usuario:

{
  "elapsed_time_seconds": 11.61577,
  "feedexport/failed_count/S3FeedStorage": 2,
  "feedexport/success_count/FileFeedStorage": 2,
  "finish_reason": "finished"
}

PR: Agregar estadísticas de recuento de éxitos y fallos a los backends de Feedstorage

jrnl | Agregar una opción de formato de visualización predeterminado al archivo de configuración

jrnl admite una amplia variedad de formatos (Markdown, JSON, YAML, etc.); sin embargo, la usabilidad de esta función no era la mejor. Eso se debe a que si quieres (por ejemplo) imprimir las últimas ocho entradas en formato Markdown, puedes usar este comando:

jrnl -8 --export md

Eso podría ser tedioso para los usuarios que quieren imprimir en Markdown cada vez, porque deben agregar continuamente la opción --export md. Para evitar esa molestia, esta contribución agrega una nueva opción al archivo de configuración: display_format, que es una opción que se puede establecer en cualquiera de los exportadores que tiene jrnl.

PR: Agregar una opción de formato de visualización predeterminado al archivo de configuración

Polybar | Eliminar el límite superior de get_volume

Polybar tiene una función para mostrar el volumen real del sistema. El problema es que no “reconoce” cuando el volumen supera el 100%. Esta es una posibilidad que los sistemas de sonido como PulseAudio te dan, lo que te permite incrementar el volumen más allá del 100% hasta el 150%.

Esta función menor solo requiere evitar limitar el volumen entre [0, 100]. Tal vez la parte “más difícil” fue compilar el código y probar los cambios.

PR: Eliminar el límite superior de get_volume

Conclusión

El conocimiento obtenido de las discusiones con los mantenedores, la mayor participación en proyectos que me interesaban y las acogedoras comunidades son algunas de las principales razones por las que buscaré contribuir al código abierto en el futuro.

¿Cuáles son tus pensamientos sobre el código abierto?