Tres Factores Que Están Bloqueando las Contribuciones a Tu Proyecto de Código Abierto

Buenos días, buenas tardes y buenas noches y bienvenidos a la mejor charla de React Summit USA. Y como pueden ver, esta charla va a tratar sobre tres factores que están bloqueando las contribuciones a sus proyectos de código abierto. Todos tenemos un proyecto secundario en el que queremos trabajar, y puede que queramos hacerlo de código abierto. Estamos trabajando en empresas que tienen productos o proyectos de código abierto que queremos hacer crecer, y la parte más importante de hacer crecer un proyecto de código abierto es el apoyo de la comunidad. Queremos contribuciones valiosas de la comunidad a nuestros proyectos de código abierto. Queremos que tantos contribuyentes como sea posible contribuyan a nuestro proyecto y lo mejoren. Hay muchas cosas que bloquean su camino para contribuir por primera vez a sus proyectos. Y esta charla va a tratar sobre esos tres bloqueos y cómo hacer que su proyecto sea un mejor camino para ellos la primera vez.

Así que, como nota al margen, si quieren conectarse conmigo, aquí tienen un código QR. Pueden escanearlo y simplemente conectarse conmigo. Me encantaría conectarme con ustedes. ¿Y quién soy yo? Hola a todos, soy Saurav Jain. Soy de la capital de India, Nueva Delhi. He estado trabajando como gerente de comunidad durante los últimos dos años en una startup de DevTools de código abierto llamada Amplication. Les contaré un poco más sobre Amplication en la próxima diapositiva. Me considero un evangelista del código abierto. Estoy en este campo desde hace cinco años y he ayudado a cientos de desarrolladores a contribuir al mundo del código abierto por primera vez. Y esto es algo que me hace feliz. Visito todas las partes del mundo, hablo sobre código abierto, ayudo a los contribuyentes a contribuir a proyectos de código abierto. Y también estoy muy activo en los canales de redes sociales. Así que si no me sigues, te estás perdiendo algo. Estos son mis nombres de usuario, S-A-U-A-I-N, tanto en LinkedIn como en Twitter, pueden seguirme allí. Me encanta viajar. Me encanta programar. Me encanta publicar contenido en Twitter. Así que suelo publicar contenido relacionado con el código abierto y las comunidades en Twitter. Así que si están interesados, por favor, échenle un vistazo. Y sí, aplicación. Así que esta diapositiva no es para dar una introducción sobre la aplicación, pero quiero que sepan cómo empecé cuando empecé a trabajar en una empresa de código abierto y lo pequeña que era. Así que solo una pequeña introducción.

y la community que puedes ver allí. Así que crecemos exponencialmente y tú también puedes hacerlo. En esta charla voy a hablar principalmente sobre las partes del contribuyente, no todo porque es una charla relámpago. ¡Así que empecemos! Así que empezaré esta charla contándote sobre el punto de vista de un contribuyente por primera vez. Así que ya sea un contribuyente que ha contribuido por primera vez es un principiante en el mundo de la tecnología o en el mundo del código abierto o ellos están visitando el repositorio de tu proyecto por primera vez. Y en ambos casos es difícil entender el código. Es difícil para ellos entender qué está pasando, intentan leer la documentation, se unen a una community, hacen preguntas a la community, interactúan con ellos y usan el producto. Y cuando lo usan, tienen algún bloqueador. Así que por ejemplo Harji Forever estaba intentando contribuir a un problema en Amplication y se encontró con algún bloqueador. Entonces, ¿cuáles son exactamente esos bloqueadores que impiden a estos contribuyentes por primera vez contribuir a tu proyecto? Así que el primero es sentirse abrumado por el código. Sí, como esto. Así que todo el mundo se sentirá identificado con esto cuando contribuya por primera vez a cualquier proyecto de código abierto, la base de código es muy abrumadora. Así que personalmente no sé qué archivo está haciendo qué cosa. Hay docenas de paquetes, cientos de archivos y no sé cuál está haciendo qué. Así que por ejemplo si vas a github.com slash amplication slash amplication verás toda la base de código cómo estamos generando el backend. Y estoy trabajando en amplication y es difícil para mí incluso si estoy pensando desde un punto de vista muy principiante entender qué paquete está haciendo qué. Hay docenas de paquetes, cada paquete tiene cientos de archivos y no sé qué es, qué cosa está haciendo qué. Así que como, como primer paso, como mantenedor, necesitas entender cómo superar esto y la mejor manera de superar este bloqueador son los buenos primeros problemas. Sí, así que te recomiendo que deberías tener tantos buenos primeros problemas abiertos en tu repositorio como puedas. Así que lo que considero un buen primer problema es un problema de código que puede ser resuelto sólo en un archivo. Así que estoy de acuerdo hay docenas de, docenas de paquetes. No puedes enseñar todo al principio. Así que empecemos con un paquete y un archivo y un problema de código que puede ser resuelto sólo en ese archivo. Así que si un contribuyente intenta contribuir, intenta elegir ese problema, irán a ese problema en particular, lo resolverán y aprenderán sobre un paquete particular de tu repositorio y entenderán qué está pasando en ese paquete y será un hueco. Añadirá como un catalizador. Será el comienzo de muchas de sus contribuciones a tu proyecto porque entienden una cosa. Luego elegirán otro problema que les hará entender sobre el otro paquete y entenderán sobre eso. Así que de esta manera, entenderán más y más paquetes y eventualmente serán un contribuyente muy activo en tu repositorio. Otros problemas que considero buen primer problema son UI. Problemas de UX, problemas de documentation, pequeñas correcciones de errores, errores tipográficos y hacer el Read Me mejor siempre es bienvenido para los mantenedores. En el problema de documentation, digo que tengo experiencia personal que cuando hay un problema en la documentation, pides a la community que lo arregle, leen documentos, leen qué está pasando con tu producto, cómo usarlo y aprenden sobre tu producto y se convierten en un usuario. Así que los problemas de documentation son muy útiles para las primeras contribuciones

y los buenos primeros problemas ayudan a contribuir. Sí, es tan simple como eso. Así que si vas a github.com slash Amplication slash Amplication y vas a la sección de problemas, verás que en cualquier momento, tenemos de 20 a 30 buenos primeros problemas abiertos en nuestro repositorio para el contribuyente que quiera contribuir a nuestro repositorio en cualquier momento. Así que si quieres contribuir por primera vez, te damos la bienvenida. Así que por favor ven y contribuye a nuestro repositorio. Eres más que bienvenido. Después de la segunda cosa, que es un problema muy grande es por ejemplo, sí, el meme es muy divertido. Por ejemplo, supongamos que tienes algún contribuyente de un repositorio que elige un buen primer problema para empezar a trabajar en él y tienen algún error. Las instalaciones no son fáciles. Tal vez algún error de git o tal vez algún error con tu producto. No lo sabemos. Y estos simplemente dejaron de trabajar en ello porque no saben qué hacer. Y como mantenedor, tienes que ser proactivo. Tienes que mantener actualizaciones de estado de los contribuyentes que trabajan en tus problemas. Si ellos están teniendo algún problema o no, cómo puedes ayudarles. Tienes que preguntarles de vez en cuando a un cierto período de tiempo. No sé, después de una semana, después de dos semanas. Según el problema. Y si están teniendo algún problema, tienes que ayudarles incluso si es un buen problema porque están contribuyendo por primera vez. Tienes que alimentarles. Tienes que hacerles aprender sobre tu proyecto y si es necesario, también puedes programar una reunión con tu equipo de ingeniería y aprenderán del propio equipo de ingeniería. Así que nunca hace daño y crea confianza en la community y más y más miembros de la community contribuyen a tu proyecto. Y así es como funciona. Por ejemplo, un contribuyente llamado Hajj. Me pidió que le asignara un problema. Le asigné un problema hace tres semanas y suelo mantener las actualizaciones de estado muy proactivamente. Olvidó que tenía que trabajar en este problema. Mantengo la actualización de estado y pregunto si hay alguna actualización en la tarea en la que está trabajando. Y en un día, hizo un PR porque así es como consigues un nuevo contribuyente siendo simplemente proactivo. Y por otro lado, en el lado derecho de la pantalla, puedes ver que Sameet tuvo un error mientras trabajaba en un problema y pedí a uno de los ingenieros de Amplication que le ayudara. Y después de pedirles que le ayudaran, programaron una reunión y fue, el

el problema fue resuelto. Y ahora Sameet y Harsh son contribuyentes muy activos de Amplication. Así que simplemente siendo proactivo y preguntando a la community, puedes ganar contribuyentes que son activos durante mucho tiempo. Y lo último pero no menos importante es la recompensa y el reconocimiento. Así que yo personalmente creo que y siempre digo esto, que cada contribución de código abierto debería ser celebrada. Alguien está dedicando su tiempo a tu proyecto, alguien está trabajando para tu proyecto sin pedir nada. Así que si son tan amables de contribuir a tu proyecto, tienes que ser lo suficientemente amable para darles un pequeño cupón de agradecimiento. Si puedes permitírtelo, siempre preferiré que puedas dar alguna hoja de pegatinas, puedes dar alguna insignia, puedes darles una camiseta o gorra, según lo que puedas permitirte y tu empresa pueda dar. De lo contrario, si es un proyecto paralelo, no tienes presupuesto, siempre puedes darles algún reconocimiento en los canales de redes sociales. Así que una publicación que mencione que este contribuyente nos ayudó a aportar este valor a nuestro proyecto y ayudó mucho al proyecto de código abierto. Crecimos y la community está disfrutando de la nueva característica, el nuevo valor que el contribuyente proporcionó. Significa mucho para la community. Entonces la community sabe que los mantenedores de este proyecto valoran la contribución de la community, son lo suficientemente amables, son lo suficientemente amables para expresar su gratitud hacia la community y más y más miembros de la community se motivan a través de esto. Esperan que nosotros también obtendremos estas cosas, también obtendremos estas recompensas o reconocimientos en los canales de redes sociales. Significa mucho. Y funciona. Funciona. Así que cada vez que invito a los primerizos al repositorio de Amplication, siempre hago una publicación de agradecimiento. Les doy una camiseta y una hoja de pegatinas que aprecian mucho. Y esto nos ayuda a traer más y más contribuyentes a nuestro proyecto. Así que en un año, puedes ver de cero a más de 200 y si cuento todos los repositorios, son más de 350 contribuyentes en este momento en Amplication, lo cual es muy grande. Así que esto funciona. Sí. Si quieres contribuir al mundo del open-source por primera vez, te invito a unirte a nuestra community de discordia y si te gustó mi charla y si quieres darle una oportunidad a Amplication, puedes darnos una estrella en GitHub, puedes ver todo el código basado en VR y puedes contribuir a nuestro repositorio. Eres más que bienvenido. Y eso es todo. Muchas gracias. Te veré a todos en el canal de discordia y diré hola allí.