10 puntos por GN⁺ 2024-02-15 | 6 comentarios | Compartir por WhatsApp

Las contribuciones sin código son la clave del éxito del código abierto

  • Sarah Rainsberger, profesora de matemáticas, no tenía la intención de convertirse voluntariamente en colaboradora de código abierto, pero comenzó a aprender JavaScript y desarrollo web mientras reconstruía el sitio web de su coro.
  • Al usar Astro, un framework de frontend, terminó contribuyendo al proyecto con una pequeña pieza de código, un archivo de configuración, y al participar en la comunidad asumió el rol de apoyar a nuevos usuarios de Astro.
  • Actualmente, Rainsberger forma parte del grupo principal de mantenedores de Astro, pero no participa demasiado en la base de código; se enfoca sobre todo en la documentación y en ayudar a otras personas a aprender Astro.

Trabajo importante sin código en los proyectos de código abierto

  • Los proyectos de código abierto necesitan, además de escribir código, documentación, localización, marketing, diseño gráfico, pruebas, gestión de comunidad y gestión de lanzamientos.
  • La importancia de las contribuciones sin código es enorme, y cuanto más complejo es el proyecto, más documentación, tutoriales y soporte se necesitan para que el código sea útil.
  • El diseño gráfico, el branding y la divulgación funcionan como señales de la salud y la seriedad del proyecto, lo que permite que otros proyectos o empresas lo adopten como dependencia.

Por qué deberías empezar a contribuir sin código

  • Las contribuciones sin código ofrecen a quienes están interesados en roles que no incluyen programación, como comunicación técnica, diseño gráfico o diseño de experiencia de usuario, una oportunidad para construir un portafolio.
  • Incluso los programadores se benefician al pulir sus habilidades de escritura y comunicación, y esto puede ayudarles a dar el salto a roles como developer relations o gestión de producto.
  • En los proyectos de código abierto hay oportunidades para personas de todos los niveles de habilidad, y sin una comprensión profunda del proyecto es difícil hacer contribuciones de código realmente significativas.

Cómo encontrar contribuyentes sin código y expresar agradecimiento

  • Para los mantenedores, la mejor forma de encontrar colaboradores es pedir tareas específicas; también ayuda construir comunidad y abrir issues etiquetados como "help wanted" y "good first issue".
  • La mentoría es una de las mejores formas de guiar a los colaboradores hacia el éxito, y valorar y reconocer a quienes contribuyen sin código ayuda a motivar a los actuales y a atraer a nuevos.

La opinión de GN⁺

  • Es importante entender que el éxito de un proyecto de código abierto requiere diversos tipos de aportes que van mucho más allá de simplemente escribir código. Esto es esencial para la sostenibilidad y el crecimiento del proyecto.
  • Las contribuciones sin código también brindan a las personas no técnicas una oportunidad de participar en el código abierto, y además pueden ayudarles a desarrollar capacidades técnicas.
  • Este artículo puede inspirar a quienes tienen interés en la comunidad de código abierto y ayudarles a encontrar maneras de aportar a la comunidad aprovechando sus propias habilidades.

6 comentarios

 
secret3056 2024-02-15

Aunque es una historia un poco distinta, hace poco alguien publicó un tutorial sobre cómo hacer un PR al archivo README de Express.js, y eso hizo que se enviaran cientos de PR sin sentido.

Pull requests · expressjs/express

 
mdisprgm 2024-02-16

Una molestia... T_T

 
edunga1 2024-02-15

Son más de 100 PR, vaya vaya.

 
sagee 2024-02-15

Por un momento me confundí sobre cómo participar con “bar-code”, jaja...
Supongo que una documentación demasiado detallada también puede ser un arma de doble filo.
Incluso podrían darse casos en los que la documentación y las capturas se vuelvan tan detalladas que al desarrollador le dé miedo actualizar la documentación y termine abandonando el desarrollo de mejoras...

 
cosine20 2024-02-16

("no") es código)

 
GN⁺ 2024-02-15
Opiniones de Hacker News
  • Como autor/mantenedor de una librería pequeña, puedo confirmar que sin contribuciones externas el manual no sería tan bueno como es ahora. El manual contribuye enormemente a la usabilidad del proyecto.

    • Como nuevo usuario de libcurl, gracias al tutorial y a la documentación de la API pude implementar rápidamente una subida por FTP y adaptarla a un caso de uso específico.
    • Gracias a la documentación pude darme cuenta de la falta de seguridad de hilos en versiones antiguas y advertirle al equipo que debía actualizar.
    • La documentación es tan importante como el código y la suite de pruebas.
  • Lo que se desea de un proyecto open source:

    • muchas capturas de pantalla
    • un README.md muy largo y detallado
    • tutoriales, documentación de referencia, documentos de diseño y diagramas de arquitectura
    • un documento de modelo mental que explique la forma de pensar del autor
  • La documentación, los recursos y demás son importantes en el open source, pero también pueden darle poder a personas no desarrolladoras para arruinar el proyecto.

    • Puede perjudicar la estabilidad, la funcionalidad y la adopción, como cuando se rehace la UX en cada release.
    • Tiende a atraer a personas muy interesadas en la política, y es fácil que aparezca el bikeshedding en áreas donde todos creen que pueden opinar.
  • Es bueno usar plataformas de chat como Discord, Gitter y Slack para construir comunidad.

    • Hace que la gente no dude en hacer preguntas en el repositorio.
    • Hacer preguntas en GitHub o crear un pull request para resolver un problema a menudo se siente inútilmente pesado.
    • Entre quienes crean proyectos en GitHub está muy extendida la actitud de “ya publiqué el código, no le debo nada más a nadie”.
  • Con base en la experiencia participando en la comunidad de WordPress, se piensa que la documentación inicial y la sólida documentación del Codex contribuyeron enormemente al crecimiento de WordPress.

    • En la época en que Joomla, Drupal y WordPress tenían bases de instalación similares, WordPress era más fácil de empezar a usar gracias a su abundante documentación.
  • El mayor deseo para un proyecto open source es que la gente lo use y deje algún tipo de registro de cómo lo usó.

    • Dejar un mensaje en el canal de Discord del proyecto, o un tuit, un mensaje corto, una captura de pantalla, un gist, un repositorio público de GitHub, un video de YouTube o TikTok: todo eso es una contribución muy valiosa para el proyecto.
  • No está claro si las contribuciones no relacionadas con código son la clave del éxito de un proyecto, pero sí se está de acuerdo en que son muy importantes.

    • Por ejemplo, la Eclipse Foundation les recuerda a los usuarios que incluso los reportes de bugs son contribuciones valiosas.
  • Al iniciar un proyecto open source, se espera que haya 10 veces más ingenieros usando el software que ingenieros escribiendo código para él.

    • Los usuarios deberían poder contribuir mejorando la documentación.
    • Cuando se usa un generador de sitios estáticos como Hugo para crear la documentación (manual de usuario), se necesita una forma de que los usuarios puedan enviar correcciones/actualizaciones a la documentación sin tener que crear un issue en GitHub.
  • Si personas no técnicas pueden entender el proyecto y encontrarle valor, es una buena señal de que el proyecto puede tener éxito.

  • La documentación se vuelve importante cuando el producto pasa de ser usado por fans mientras aún es desconocido a una etapa en la que busca más usuarios.

    • Sin una buena documentación, es difícil superar esa etapa.
    • Esto recuerda que hay que escribir la guía de usuario de Neural Amp Modeller.