¿Para qué contribuir?

Contribuir en proyectos de código abierto puede ser una provechosa manera de aprender, enseñar, y conseguir experiencia en cualquier habilidad que puedas imaginar.

¿Para qué contribuye la gente en proyectos de código abierto? ¡Por muchas razones!

Mejora tus habilidades existentes

Ya sea codificación, diseño de interfaces de usuario, diseño gráfico, redacción u organización, si lo que estás buscando es práctica, hay una tarea esperándote en un proyecto de código abierto.

Conoce personas que están interesadas en temas similares

Los proyectos de código abierto con comunidades cálidas y acogedoras hacen que la gente regrese a través de los años. Muchas personas forman amistades de por vida a través de su participación en el código abierto, ya sea para presenciar exposiciones en conferencias entre pares o largas conversaciones nocturnas sobre burritos.

Encuentra mentores y enseña a otros

Trabajar con otros en un proyecto compartido significa que tendrás que explicar cómo haces las cosas, así como pedir ayuda. Los momentos de aprendizaje y enseñanza pueden ser actividades satisfactorias para todos los involucrados.

Construye artefactos públicos que te ayudarán a construir una reputación (y una carrera)

Por definición, todo tu código abierto es público, lo que significa que consigues ejemplos de manera gratuita para llevar a cualquier lugar como una demostración de lo que haces.

Conoce las habilidades de las personas

El código abierto ofrece oportunidades para practicar habilidades de liderazgo y gestión, a resolver conflictos, organizar equipos y a priorizar el trabajo.

Es poderoso ser capaz de hacer cambios, incluso pequeños

No necesitas convertirte en un colaborador de toda la vida para disfrutar la participación con el código abierto. ¿Alguna vez viste un error de tipografía, y deseaste que alguien pudiera corregirlo? En un proyecto de código abierto, es justamente lo que puedes hacer. El código abierto ayuda a las personas a sentir acción en sus vidas, en la forma en que experimentan al mundo y eso en si mismo es gratificante.

Qué significa contribuir

Si eres un colaborador de código abierto nuevo, el proceso puede ser intimidatorio. ¿Cómo encontrar el proyecto adecuado? ¿Qué hacer si no sabes cómo codificar? ¿Qué pasa si algo sale mal?

¡No debes preocuparte! Hay todo tipo de formas de involucrarse con un proyecto de código abierto, y unos pocos consejos te ayudarán a sacar el máximo provecho de tu experiencia.

No necesitas contribuir con código

Un error conceptual común acerca de contribuir con el código abierto es que debes contribuir con código. De hecho, son a menudo las otras partes de un proyecto las más descuidadas o pasadas por alto. ¡Le harás un enorme favor al proyecto si te ofreces a trabajar en este tipo de contribuciones!

Incluso si te gusta codificar, otro tipo de contribuciones son una gran manera de involucrarse con un proyecto y conocer a otros miembros de la comunidad. Construir esas relaciones te dará oportunidades de trabajar en otras partes del proyecto.

¿Te gusta planificar eventos?

  • Organiza workshops o reuniones acerca del proyecto, como hizo @fzamperin para NodeSchool
  • Organiza la conferencia del proyecto (si es que tienen una)
  • Ayuda a la comunidad de miembros a encontrar las conferencias apropiadas y a presentar propuestas para disertar

¿Te gusta diseñar?

  • Reestructura los diseños para mejorar la usabilidad del proyecto
  • Dirige la investigación de los usuarios para reorganizar y refinar la navegación del proyecto o sus menús, como lo sugiere Drupal
  • Reúne una guía de estilos para ayudar al proyecto a tener un diseño con consistencia visual
  • Crea diseños para las remeras o un nuevo logo, como hicieron los colaboradores de hapi.js’s

¿Te gusta escribir?

  • Escribe y mejora la documentación del proyecto
  • Sanea la carpeta de ejemplos para mostrar cómo se usa el proyecto
  • Inicia el boletín informativo para el proyecto, o aspectos más destacados a enviar a la lista de correos
  • Escribe tutoriales para el proyecto, como hicieron los colaboradores de pypa’s
  • Escribe una traducción de la documentación del proyecto

¿Te gusta organizar?

  • Vincula los problemas duplicados, y sugiere nuevas etiquetas para los problemas, para mantener todo organizado
  • Recorre los problemas abiertos y sugiere cerrar los más antiguos, como hizo @nzakas para eslint
  • Realiza preguntas clarificadoras en los problemas recientemente abiertos para hacer que la discusión avance

¿Te gusta programar?

  • Encuentra un problema abierto para entrar, como lo hizo @dianjin para Leaflet
  • Pregunta si puedes ayudar a escribir alguna nueva funcionalidad
  • Automatiza la configuración del proyecto
  • Mejora las herramientas y las pruebas

¿Te gusta ayudar a las personas?

  • Responde las preguntas acerca del proyecto en, por ejemplo, Stack Overflow (como este ejemplo Postgres) o en reddit
  • Responde preguntas a las personas en los problemas abiertos
  • Ayuda a moderar los foros de discusión o canales de conversación

¿Te gusta ayudar a otros a programar?

¡No tienes que trabajar solamente en proyectos de software!

Mientras que el “código abierto” a menudo se refiere a software, puedes colaborar en casi cualquier cosa. Existen libros, recetas, listas y clases que se desarrollan como proyectos de código abierto.

Por ejemplo:

Incluso si no eres un desarrollador de software, trabajar en la documentación de un proyecto puede ayudar a comenzar en el código abierto. Es con frecuencia menos intimidante trabajar en proyectos que no involucran código, y ese proceso de colaboración te dará confianza y experiencia.

Orientándote a un nuevo proyecto

Para cualquier otra cosa distinta de una corrección de error tipográfico, contribuir con el código abierto es como caminar hacia un grupo de extraños en una fiesta. Si comienzas a hablar sobre las llamas, mientras ellos están muy involucrados en una discusión sobre el pez dorado, es probable que te miren de manera un poco extraña.

Antes de lanzarte con los ojos cerrados con tus propias sugerencias, comienza aprendiendo cómo leer a la sala. Si lo haces, aumentan las probabilidades de que tus ideas se noten y sean escuchadas.

Anatomía de un proyecto de código abierto

Todas las comunidades de código abierto son diferentes.

Luego de pasar años en un proyecto de código abierto significa que aprendiste a conocer un proyecto de código abierto. Si te mueves a un proyecto diferente encontrarás que el vocabulario, las normas, y los estilos de comunicación son completamente diferentes.

Dicho esto, muchos proyectos de código abierto siguen una estructura organizacional similar. Entender los roles de las diferentes comunidades y el proceso en general te ayudará a estar rapidamente orientado para cualquier proyecto nuevo.

Un proyecto de código abierto tiene los siguientes tipos de personas:

  • Autor: La/s persona/s u organización que creó/crearon el proyecto.
  • Dueño: La/s persona/s que tiene/n la propiedad administrativa sobre la organización o el repositorio (no siempre es la misma que el autor original)
  • Encargados: Colaboradores que son responsables de dirigir la visión y de administrar aspectos organizacionales del proyecto. (Pueden también ser autores o dueños del proyecto.)
  • Colaboradores: Cualquiera que haya contribuido con algo al proyecto.
  • Miembros de la comunidad: Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opinión sobre la dirección que toma el proyecto.

Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del “equipo”, o en su repositorio para encontrar la documentación política de gobierno, para encontrar esta documentación.

Un proyecto también tiene documentación. Estos archivos están normalmente listados en un nivel alto del repositorio.

  • LICENSE: Por definición, cada proyecto de código abierto debe tener una licencia open source. Si el proyecto no tiene una licencia, entonces no es de código abierto.
  • README: El archivo README es un manual de instrucción que da la bienvenida al proyecto a los nuevos miembros de la comunidad. Explica por qué el proyecto es útil y cómo comenzar.
  • CONTRIBUTING: Mientras que el archivo README ayuda a las personas a usar el proyecto, el archivo CONTRIBUTING ayuda a las personas a contribuir con el proyecto. Explica qué tipo de contribuciones son necesarias y cómo llevar adelante el trabajo. Si bien no todos los proyectos tienen un archivo CONTRIBUTING, su presencia señala que se trata de un buen proyecto para contribuir.
  • CODE_OF_CONDUCT: Sienta sólidas reglas sobre la conducta de los participantes asociados y ayuda a facilitar un entorno acogedor y amistoso. Si bien no todos los proyectos tienen un archivo CODE_OF_CONDUCT, su presencia señala que se trata de un buen proyecto para contribuir.
  • Otra documentación: Puede haber documentación adicional, como tutoriales, recorridos o políticas de gobierno, especialmente en proyectos de mayor envergadura.

Finalmente, los proyectos de código abierto utilizan las siguientes herramientas para organizar la discusión. La lectura de estos archivos te darán una buena imagen de cómo piensa y trabaja la comunidad.

  • Seguidor de problemas (Issue tracker): Es donde las personas discuten los problemas relacionados con el proyecto.
  • Pull requests: Es donde las personas discuten y revisan los cambios que están en progreso.
  • Foros de discusión o lista de correos electrónicos: Algunos proyectos pueden utilizar estos canales de conversación para tópicos de conversación (por ejemplo “Cómo hago para… o “Qué piensas sobre…“ en luga de reportes de errores o pedido de requerimientos). Otros utilizan un rastreador de problemas para todas las conversaciones.
  • Canal de chat síncrono: Algunos proyectos utilizan canales de chat (como Slack o IRC) para conversaciones casuales, colaboración e intercambios rápidos.

Encontrando un proyecto donde contribuir

¡Ahora que ya has descubierto cómo funcionan los proyectos de código abierto, es tiempo de encontrar un proyecto con el que contribuir!

Si nunca antes contribuiste al código abierto, acepta algunos consejos del presidente de los Estados Unidos, John F. Kennedy, quien una vez dijo, “No preguntes qué es lo que tu país puede hacer por ti; pregúntate qué es lo que tú puedes hacer por él”

Las contribuciones al código abierto ocurren en todos los niveles a lo largo de los proyectos. No necesitas pensar demasiado cuál será tu primera colaboración, o cómo se verá.

En su lugar, comienza pensando sobre el proyecto que ya estás utilizando o que quisieras utilizar. Los proyectos con los que contribuirás activamente son aquellos a los que volverás.

En esos proyectos, cuando te encuentres pensando que algo podría hacerse mejor o diferente, actúa siguiendo tu instinto.

El código abierto no es un club exclusivo; está hecho de personas igual a tí. El término de fantasía “Código abierto” es solo un nombre para tratar a los problemas del mundo como resolubles.

Puedes recorrer un archivo README y encontrar un vínculo roto o un error tipográfico. O tal vez eres un nuevo usuario y te diste cuenta de que algo está roto, o hay un problema que crees que realmente debería estar en la documentación. En lugar de ignorarlo y continuar, o solicitar que alguien lo solucione, observa si puedes ayudar lanzándote sobre él. ¡De eso se trata el código abierto!

El 28% de las contribuciones casuales a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción.

Puedes también utilizar algunos de los siguientes recursos para ayudarte a descubrir nuevos proyectos:

Una lista de verificación antes de que contribuyas

Una vez que hayas encontrado un proyecto con el que quisieras contribuir, realiza un recorrido rápido para asegurarte de que el proyecto es adecuado para aceptar contribuciones. De otra manera, tu duro trabajo puede no tener nunca una respuesta.

Aquí tienes una lista práctica para evaluar si un proyecto es conveniente para nuevos colaboradores.

Satisface la definición de código abierto

El proyecto acepta contribuciones activamente

Observa la actividad de los commit en la rama principal. En GitHub, puedes ver esta información en la página del repositorio.

Luego, busca en los problemas del proyecto.

Ahora haz lo mismo para los pull requests del proyecto.

El proyecto es acogedor

Un proyecto que es amigable y acogedor indica que será receptivo de nuevos colaboradores.

Cómo enviar una contribución

Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación te mostramos cómo hacer que tu contribución siga por el buen camino.

Comunicándote de manera efectiva

Sin importar si eres un colaborador para una sola vez o estás intentando unirte a una comunidad, trabajar con otras personas es una de las habilidades más importantes que desarrollarás en un proyecto de código abierto.

Antes de abrir un problema o un pull request, o de hacer una pregunta en un chat, ten en cuenta los siguientes puntos para ayudar a que tus ideas lleguen a buen puerto de manera efectiva.

Da contexto. Ayuda a los demás a ponerse al día rápidamente. Si tienes un error, explica lo que estás tratando de hacer y cómo reproducirlo. Si estás sugiriendo una nueva idea, explica por qué crees que sería útil para el proyecto (¡no solamente para tí¡).

😇 “No ocurre X cuando yo hago Y”

😢 “¡X se ha roto! Por favor repárenlo.”

Haz tu tarea de antemano. Está bien desconocer cosas, pero mostrando que lo intentaste. Antes de solicitar ayuda, asegúrate de comprobar el README, la documentación, los problemas (abiertos o cerrados), la lista de correos, y de buscar en internet por una respuesta. Las personas agradecerán cuando demuestres que estás tratando de aprender.

😇 “No estoy seguro de cómo implementar X. Verifiqué en los documentos de ayuda y no encontré ninguna mención.”

😢 “¿Cómo soluciono X?”

Mantén tus solicitudes cortas y directas. Al igual que el envío de un correo, cualquier contribución, sin importar lo simple o útil que sea, requiere la revisión de parte de otra persona. Muchos proyectos tienen más solicitudes de entrada que personas disponibles para ayudar. Sé conciso. Aumentarás las probabilidades de que alguien pueda ayudarte.

😇 “Me gustaría escribir un tutorial para una API.”

😢 “Días atrás estaba manejando por la autopista y me detuve para cargar combustible, y entonces tuve la gran idea de algo que deberíamos estar haciendo pero antes de explicarlo, permítanme mostrarles…“

Mantén todas las comunicaciones públicas. Pese a que es tentador, no te dirijas a los responsables de manera privada a menos que necesites compartir información sensible (como un problema de seguridad o violaciones a la conducta serias). Cuando mantienes las conversaciones públicas, más personas pueden aprender y verse beneficiadas de tu intercambio. La discusión puede ser, en sí misma, una contribución.

😇 (como un comentario) “@-responsable ¡Qué tal! ¿Cómo deberíamos proceder con este PR?”

😢 (como un correo electrónico) “Que tal, disculpa que te moleste con un correo electrónico, pero me estaba preguntando si tendrás la oportunidad de revisar mi PR”

Está bien hacer preguntas (¡pero sé paciente!). Todos fueron nuevos en el proyecto en algún momento, e incluso los colaboradores experimentados necesitan ponerse al día cuando miran un nuevo proyecto. Por lo mismo, incluso responsables de mucha antigüedad no están siempre familiarizados con todas las partes del proyecto. Muéstrales la misma paciencia que quieres que ellos tengan contigo.

😇 “Gracias por estudiar éste error. Seguí tus sugerencias. Esta es la salida.”

😢 “¿Por qué no pueden solucionar mi problema? ¿No es este acaso su proyecto?”

Respeta las decisiones de la comunidad. Tus ideas pueden ser diferentes a las prioridades de la comunidad o a la visión. Pueden devolverte alguna retroalimentación o decidir no continuar con tu idea. Mientras que tu buscas atención y compromiso, los responsables deben convivir con tu decisión por más tiempo que tú. Si no estás de acuerdo con la dirección tomada, siempre puedes trabajar en tu propio fork o comenzar tu propio proyecto.

😇 “Lamento que no puedan dar soporte a mi situación, pero como lo explicas solo afecta a una minoría de usuarios, y lo entiendo. Gracias por escuchar.”

😢 “¿Por qué no dan soporte a mi situación? ¡Es inaceptable!”

Por encima de todo mantenlo con clase. El código abierto está formado por colaboradores de todo el mundo. El contexto se pierde a través de idiomas, culturas, geografías y zonas horarias. Además, la comunicación escrita hace más difícil transmitir un tono o estado de ánimo. Asume buenas intenciones en esas conversaciones. Está bien, tratando de volver a una idea, solicitar más contexto, o aclarar más tu posición. Trata de dejar a Internet como un lugar mejor del que tú lo encontraste.

Dando contexto

Antes de hacer nada, haz una rápida verificación para asegurarte que tu idea no se haya discutido anteriormente. Navega por el README del proyecto, los problemas (abiertos y cerrados), lista de correos electrónicos, y en Stack Overflow. No necesitas dedicar horas para todo esto, pero una mirada rápida buscando algunas palabras clave resolverá gran parte de la tarea.

Si no puedes encontrar tu idea en ningún otro lado, estás listo para dar el paso. Si el proyecto está en GitHub, es probable que lo comuniques abriendo un problema o un pull request:

  • Problemas (Issues) son como comenzar una conversación o discusión.
  • Pull requests son para comenzar a trabajar en una solución.
  • Para una comunicación ligera, como una explicación o una pregunta de “cómo”, trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno.

Antes de abrir un problema o un pull request, verifica los documentos de verificación del proyecto (comúnmente es un archivo que se llama CONTRIBUTING), para ver si se necesitan incluir algo específico, puede ser que soliciten que respetes un modelo, o requerir que utilices pruebas.

Si quieres hacer una contribución sustancial, abre un problema para preguntar antes de ponerte a trabajar en ello. Es de gran ayuda observar el proyecto por un tiempo (en GitHub, puedes hacer click en “Watch” para ser notificado de todas las conversaciones), y conocer a los miembros de la comunidad, antes de realizar trabajo alguno que pueda no ser aceptado.

Abriendo un problema

Frecuentemente deberías abrir un problema en las siguientes situaciones:

  • Reportar un error que tú no puedes resolver.
  • Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas).
  • Proponer una nueva característica u otra idea del proyecto.

Consejos para comunicar los problemas:

  • Si ves un problema abierto en el que quieres entrar, coméntalo en el problema, para permitir que las personas sepan que te preocupa. De esa manera, es menos probable que se duplique el trabajo en la comunidad.
  • Si un problema fue abierto hace mucho tiempo, es posible que se esté tratando en otro lugar o que ya haya sido resuelto, de modo que primero pregunta por una confirmación antes de ponerte a trabajar.
  • Si abriste un problema, pero más tarde descubriste que estaba resuelto, comenta en tu propio problema, para que las personas lo sepan, y luego cierra el problema. Incluso documentar ese resultado es una contribución al proyecto.

Abriendo un pull request

Usualmente deberías abrir un pull request en las siguientes situaciones:

  • Enviar arreglos triviales (por ejemplo una corrección tipográfica, un enlace caído o un error obvio).
  • Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema.

Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentación a tu progreso. Solo márcalo como “trabajo en proceso” (WIP por sus siglas en inglés, work in progress) en la línea del tema. Siempre puedes agregar más commits después.

Si el proyecto está alojado en GITHUB, acá te explicamos los pasos para enviar un pull request:

  • Abre un fork del repositorio y haz un clon local. Conecta tu repositorio local con el repositorio “superior” original agregándolo como remoto. Descarga los cambios desde el repositorio superior con frecuencia de manera que puedas mantener al día, de forma que cuando tu envíes tu pull request, sea menos probable que haya conflictos. (ver más instrucciones detalladas aquí.)
  • Crea una rama para tus ediciones.
  • Haz referencia a cualquier problema relevante o documentación de soporte en tu PR (por ejemplo “Cierra #37.”)
  • Incluye capturas de pantalla del antes y del después si tus cambios incluyen diferencias en el HTML o CSS. Arrastra y suelta las imágenes en el cuerpo de tu pull request.
  • ¡Haz pruebas de tus cambios! Corre tus cambios contra las pruebas existentes si realmente existen, y crea nuevas pruebas si es necesario. Sin importar que existan o no las pruebas, asegúrate que tus cambios no produzcan roturas del proyecto existente.
  • Contribuye con el estilo del proyecto con el máximo de tus capacidades. Esto significa utilizar indentación, punto y comas o comentarios de manera diferente a lo que harías en tu repositorio, pero que hacen más sencillo para los responsables combinar y para otros de entender y mantener el proyecto en el futuro.

Si se trata de tu primer pull request, verifica Haz un Pull Request, que fue creado por @kentcdodds como un recurso de recorrido gratuito.

Qué pasa luego de que enviaste una contribución

¡Lo hiciste! Felicitaciones por convertirte en un colaborador open source. Esperamos que ésta sea la primera de muchas.

Luego de que enviaste tu contribución, una de las siguientes situaciones puede ocurrir:

😭 No tienes una respuesta.

Ojalá que hayas verificado el proyecto buscando signos de actividad antes de hacer cualquier contribución. Incluso en proyectos activos, de cualquier manera, es posible que tu contribución no tenga una respuesta.

Si no tuviste una respuesta en más de una semana, es justo responder en el mismo hilo, preguntando a alguien por una revisión. Si conoces el nombre de la persona correcta para que revise tu contribución, puedes hacer una @-mención en ese hilo.

No contactes a esa persona de manera privada; recuerda que las comunicaciones públicas son vitales para los proyectos de código abierto.

Si haces una llamada educada y todavía nadie responde, es posible que nadie te responda jamás. No es un sentimiento agradable, pero no dejes que te desanime. ¡Les pasa a todos! Existen muchas razones posibles por las que no tuviste tu respuesta, incluyendo circunstancias personales que pueden estar fuera de control. Trata de encontrar otro proyecto u otra forma de contribuir. En todo caso, ésta es una buena razón para no invertir mucho tiempo en hacer contribuciones antes de ver que existen otros miembros en la comunidad que están comprometidos y responden.

🚧 Alguien pide cambios a tu colaboración.

Es común que te pidan hacer cambios a tu contribución, ya sea una retroalimentación sobre el alcance de tu idea, o cambios en tu código.

Cuando alguien te pide cambios, compórtate de manera sensible, se tomaron el tiempo necesario para revisar tu contribución. Abrir un pull request y luego alejarse es de malos modales. Si no sabes cómo hacer los cambios, investiga el problema, y luego pregunta por ayuda si la necesitas.

Si no tienes el tiempo para volver a trabajar en ese problema (por ejemplo, si la conversación tuvo lugar durante meses, y tus circunstancias cambiaron), permite que el responsable lo sepa, de manera que no quede a la espera de una respuesta. Alguien puede sentirse complacido de hacerse cargo.

👎 Tu contribución no es aceptada.

Al final tu contribución puede o no ser aceptada. Con suerte, no hayas necesitado poner demasiado esfuerzo en ella. Si no estás seguro de por qué no fue aceptada, es completamente razonable preguntar al responsable por retroalimentación y esclarecimiento. De cualquier manera, al final debes aceptar que se trata de su decisión. No discutas ni adoptes una postura hostil. ¡Siempre serás bienvenido a hacer un fork y trabajar en tu propia versión si no estás de acuerdo!

🎉 Tu contribución es aceptada.

¡Hurra! ¡Hiciste una contribución al código abierto exitosamente!

¡Lo hiciste!

Si acabas de hacer tu primera contribución al código abierto, o si estás buscando nuevas formas de contribuir, esperamos que esté inspirado para continuar la acción. Si tu contribución no fue aceptada, no te olvides de dar las gracias cuando un responsable puso esfuerzo en ayudarte. El código abierto es llevado adelante por personas como tu: un problema, un pull request, un comentario o choca esos cinco por vez.