Ama a tus Mantenedores

♪♪♪ Hola. Bienvenidos a Ama a tus Mantenedores. En primer lugar, permítanme presentar mi empresa, que es Platformatic, la mejor manera de construir tu API de Node y construir tu backend de Node. Ofrecemos una solución automatizada integral para API, GraphQL, y servidores y servicios integrados. Échale un vistazo.

Ahora, el secreto está en las formas. Es cómo le pides a la gente que haga cosas. Permíteme demostrarte cómo. En primer lugar, me gustaría presentarme. Soy Paolo. Soy miembro del TSC de Node y también ingeniero principal en Platformatic. Puedes encontrar todos mis contactos allí abajo, especialmente mi sitio web, que acabo de rediseñar. Así que te animo a echar un vistazo y darme tu opinión, por favor. De acuerdo. Ahora, sigamos adelante.

¿Qué esperas, finges, del código abierto? ¿Cuál es el verbo correcto a usar? En primer lugar, aclaremos qué es en realidad el código abierto. El código abierto es un modelo de desarrollo de software descentralizado que fomenta la colaboración abierta y está impulsado, y aquí está la clave, por la pasión de las personas. Ahora, está funcionando y definitivamente está funcionando. El código abierto ha demostrado ser realmente efectivo cuando se trata de mejorar la calidad del software, los servicios, y en cierta medida, la vida de las personas.

Todo comenzó en los años setenta, en el movimiento del software libre que desafió el desarrollo tradicional basado en lucro como de costumbre. El problema es que en inglés, como te podrás imaginar, free significa demasiado. Significa tanto gratis como en no pagado como libre como en libertad. Es ambiguo. No pagado era el significado más entendido de la palabra. Por lo tanto, se cambió a código abierto, que es una rama del movimiento del software libre, para tener una comprensión clara de lo que significa. El código abierto es un software que se puede utilizar con fines comerciales sin renunciar, perdón, sin renunciar a la libertad. La libertad se mantiene. Ahora, ¿por qué alguien querría ir al código abierto? Porque, y permíteme citar aquí, puedes obtener lo mejor de lo mejor de lo mejor. Puedes acceder a una base de desarrolladores que ni siquiera está remotamente cerca físicamente de ti, y puedes acceder a diferentes culturas, antecedentes y capacidades, lo que significa diferentes puntos de vista. En todos los aspectos de la vida humana, esto ha demostrado ser un aumento en la calidad.

Además, tienes bajos costos de mantenimiento porque el software de código abierto es mantenido por otras personas para ti, por lo que no necesitas una oficina, y si adoptas el código abierto, solo necesitas un servidor de control de versiones. Ahora, no necesitas una oficina, ¿verdad? Esto es presumible, entonces, ¿algo, ¿verdad? ¿Te suena? Bueno, el código abierto es similar al trabajo remoto, pero no lo es. Ten cuidado con esto, y esta es la clave del resto de esta charla completa. La gran diferencia es que las personas en el código abierto están motivadas por la pasión, no por el dinero, y además, no eres su jefe. Recuerda eso. No eres su jefe, por lo que no puedes exigir nada. Puedes pedir, pero no puedes exigir. No puedes dar órdenes. No puedes dar ninguna orden, pero en general, todos son amables si las personas son amables.

Ahora, recuerda, las personas en el código abierto están motivadas por la pasión. A los mantenedores les encanta, simplemente les encanta que uses su software. De lo contrario, nunca lo habrían abierto, pero debemos dar respeto a todos. Los mantenedores no te deben nada. Están dedicando su tiempo, su tiempo libre, su tiempo personal, su tiempo de hobby de forma gratuita por la pasión, pero no les estás pagando a menos que los patrocines, pero ese es un tema diferente. Recuerda que las acciones tienen consecuencias, como siempre. Si pretendes correcciones, si pretendes características, o si simplemente exiges atención de manera incorrecta, alejarás a las personas, como siempre sucede en cualquier otro aspecto social en el mundo. No es solo el código abierto. Esto se aplica a todo. Esta es una lección de vida general, si me permites darte una lección.

Además, lo que quieres hacer es evitar el agotamiento. No quieres que las personas simplemente se agoten. Recuerda que al otro lado de la pantalla hay otras personas. Hay personas que, como tú, tienen sentimientos, tienen necesidades y tienen trabajo en tiempo real. Tienen una vida real, tienen pasatiempos, tienen familia, tienen hijos a los que cuidar, y así sucesivamente. Incluso un pequeño acto de rudeza puede agotar a las personas. No lo olvides. Lo que crees que puede ser solo un pequeño acto de rudeza puede ser el enésimo que el mantenedor ha visto en estos días, y las personas se agotarán, y eventualmente abandonarán el software. Como puedes ver en la captura de pantalla, hice una captura de la página de GitHub del proyecto LWJS, que fue gestionado por James Sumner, que recibió un mensaje desagradable, desagradable, desagradable, y honestamente, completamente sin sentido por parte de una persona que fue capaz de poner una gran cantidad de palabras malsonantes, ofensas y rudeza en solo seis líneas de texto. James se agotó y dijo, sabes qué, ya terminé. Nadie está pagando por esto, por lo tanto, estoy retirando el proyecto.

El proyecto está desactivado, y ahora nadie puede beneficiarse realmente de mi trabajo en eso. Aún puedes bifurcarlo, obviamente, porque James era una buena persona, podría haber eliminado este proyecto por completo, pero era una buena persona. Decidió simplemente decir que el proyecto ahora está archivado. Si quieres bifurcarlo, ahora es tuyo. Ya no voy a dedicar mi tiempo a esto. Entonces, ¿esa rudeza inútil no llegó a ninguna parte, verdad? Por favor, evítalo. Sé amable con las personas. Sé muy amable con las personas. El lado humano es lo que más me importa hoy en día. Debemos ser amables con las personas con las que nos relacionamos en el código abierto y en general. En realidad, nunca es un problema.

Ahora, supongamos que somos amables, que finalmente podemos comportarnos de la manera correcta. ¿Cómo se pide ayuda en un proyecto de código abierto? Bueno, en primer lugar, y te sorprenderá, tienes que buscar. Comienza con una búsqueda muy detallada. Esta es mi lista de prioridades cuando realmente tengo que buscar cosas, porque, por supuesto, uso software de código abierto, que no he escrito, así que eventualmente tengo que buscar problemas, ¿verdad? Perdón, para resolver problemas. Y en este caso, esta es mi lista de tareas pendientes cuando tengo que hacer una búsqueda.

Primero, comienzo con los problemas. Veamos si tengo un problema que alguien ya ha encontrado. Cuanto más fácil sea reproducir este problema, mayor será la probabilidad de que alguien ya lo haya informado y también de que ya esté solucionado, pero eso es otro tema. Ahora, si no encuentro nada en los problemas, paso a las solicitudes de extracción. Tal vez alguien haya notado que en lugar de presentar un problema directamente, propuso una solución para él. Así que las solicitudes de extracción son las siguientes. Luego está el code. Intenta sumergirte en la base de code si es posible y busca si ya hay alguna pista sobre cómo solucionar tu problema. Tal vez estés usando el software de manera incorrecta. La documentación actualizada, esa es la última opción. Tal vez haya una página muy ingeniosa en la documentación que tenga una solución no convencional para el problema o que especifique que este problema no se cubrirá porque podría serlo. Por supuesto, esta lista es después de que ya hayas leído la documentación sobre cómo usar el software porque asumo que ya lo hiciste. En otras palabras, por favor, no hagas que alguien te responda sin leer el maldito manual, ¿de acuerdo? Pero de todos modos, esa es mi lista.

Ahora, también tenía una nota al margen para hacer. Si tienes un problema realmente trivial para reproducir y nadie lo ha informado nunca y nadie ha enviado una solicitud de extracción para eso, amigo, lo estás usando de manera incorrecta. Te lo digo porque me ha pasado muchas veces. No pude encontrar ninguna solución. No pude explicar por qué nadie ha encontrado mi estúpido problema y luego me di cuenta de que el estúpido en todo este panorama era yo mismo. Así que ya sabes, verifica dos veces de todos modos. Otra cosa muy importante. Vivimos en un mundo distribuido. Vivimos en un mundo donde estamos distribuidos por todo el mundo, donde las personas provienen de diferentes culturas, por lo que tienen diferentes expectativas y conocimientos y experiencia. No solo hablo de código abierto. Hablo en general. Así que nunca te preocupes por comunicarte demasiado.

Proporciona tantos detalles como desees, tantos. Volveré sobre esto más adelante. Y no temas molestar a las personas con una comunicación excesiva. Cuantos más detalles, detalles importantes puedas dar, mejor será, porque piensa en esto, los mantenedores tienen su propia vida, por lo que es posible que no tengan tiempo para solicitar información adicional y probablemente, por lo tanto, no procesarán tu informe si les faltan información crucial. Así que no temas comunicarte en exceso. Y olvida, y esto te sorprenderá, trabajar en código abierto e informar problemas e investigar problemas es como ser un periodista. ¿Recuerdas las reglas de los cinco W? Quién, dónde, qué, cuándo, por qué y cómo. Es lo mismo. Comenzamos con quién y dónde. Por lo general, si estás informando un problema con un software, el quién es el propio software, ¿verdad? Pero no siempre es el caso porque podría ser solo una parte del software. Así que trata de ser explícito si puedes. Por supuesto, no proporciones información inútil, pero puedes.

Luego, y esto es lo más importante, qué y cuándo. Explica qué sucedió, qué no sucedió, y qué esperamos que el software haga realmente. Y cuándo sucedió, qué estábamos haciendo cuando eso sucedió, trata de proporcionar el contexto más completo que puedas. Luego está el cómo. Y recuerda, esto volverá. ¿Cuál es la forma más simple de reproducir el problema? No importa, quiero decir, tienes una aplicación increíble, tal vez solo estés usando un paquete. No creo que la authentication de tu aplicación importe para este paquete si el paquete no es el paquete de authentication. Así que no nos importa. Trata de reducir el problema. Esto volverá en un momento.

Ahora, un lector muy atento podría decir, amigo, olvidaste mencionar el por qué en la lista de los cinco W, ¿verdad? No lo he olvidado. Por qué algo sucede es controvertido porque si conoces el por qué, como reportero, significa que ya sabes cómo solucionar el problema. En ese caso, por favor proporciona una solicitud de extracción, o al menos proporciona una explicación detallada o un problema sobre cómo eventualmente resolver la solución. Tal vez no tengas la experiencia para tocar el código base, pero entiendes lo que está sucediendo. Pero por lo general no conoces el por qué, excepto en algunos casos. Así que no lo he olvidado realmente. Es importante, pero no es parte del resumen de esto. Lo siento, me salté una diapositiva. Ahora, estaba hablando de comunicarse en exceso, pero asegúrate de no abrumar a los mantenedores con información inútil.

No tienes que preocuparte por comunicarte en exceso, pero tampoco puedes, por supuesto, excederte. Como dicen en latín, in metastat virtus, así que la virtud se encuentra en el medio. No puedes enviar toneladas de salida o tal vez gigabytes de salida en un problema porque nadie lo leerá. Además, los informes con mucha información probablemente distraerán a los mantenedores, lo cual hará que pierdan interés y ni siquiera miren el problema, incluso si están dispuestos a ayudar.

Además, esto es una consecuencia directa de todo esto, es por tu propio bien. Cuanta más información superflua proporciones, menos probabilidades hay de que se solucione tu problema, porque si pierdes la atención del mantenedor, estás acabado. Si el mantenedor ve mucha salida sin información interesante, no solucionará tu problema y te dejará solo.

Trata de encontrar un buen compromiso entre lo que necesita ser comunicado y todo lo que puedes comunicar. Luego llegamos al núcleo de la idea. La mejor manera de solicitar un problema, solicitar un informe para solucionarlo o cualquier cosa similar, es crear lo que se llaman repositorios reproducibles. Así que si obtienes un software, lo estás usando, puedes crear un repositorio solo para ese problema que solo contenga los detalles mínimos necesarios para reproducir el problema. Por supuesto, quieres eliminar toda la información sensible o maximizar su obfuscación, y por favor proporciona un repositorio público. De esta manera, los triadores o mantenedores pueden clonar tu repositorio, iniciar el repositorio, ver el problema, aislarlo y solucionarlo. Esa es, con mucho, la mejor manera de obtener una solución, ¿de acuerdo? No te voy a decir cómo crear esto, puedes buscarlo en línea, pero lo importante es que sea mínimo, aislado, público, sin información sensible. Si cumples con eso, estás bien.

Sigamos adelante. El último advice que quiero darte es hacer seguimiento. Es muy molesto si presentas un problema y luego te olvidas de él, y finalmente regresas después de un mes diciendo, oh amigo, ¿se solucionó eso? Probablemente no lo esté. Si el mantenedor te pide inmediatamente más información, y tú nunca respondes, el mantenedor queda estancado. No tenemos una bola mágica, no podemos predecir el futuro, así que debes proporcionar toda la información que te pedimos para poder solucionar el problema.

Además, esta es tu única oportunidad de ser escuchado. Si el problema implica básicamente una funcionalidad que falta o una mejora que se puede hacer, y si quieres opinar y dar tu propia opinión, este es el último momento porque una vez que se resuelva el problema, se fusionará la nueva funcionalidad, se creará un nuevo PR, ya no tendrás voz. Por supuesto, puedes reportar un nuevo problema, pero el mantenedor puede que nunca lo cambie porque en realidad funciona. Y además, también está la versión semántica involucrada en el problema y demás.

Así que mi advice es configurar las notificaciones que leas. Por ejemplo, yo no uso las notificaciones de GitHub, prefiero recibir correos electrónicos de GitHub. Lo que más te convenga, asegúrate de estar al día con las tendencias y seguir la discussion.

Último paso, que es trivial ya que es de código abierto, pero probablemente es mejor decirlo, eres más que bienvenido a participar. Si tienes experiencia y entiendes lo que está sucediendo, proporciona una solución tú mismo. En lugar de presentar un problema, proporciona un PR. O si presentaste un problema y el mantenedor te dijo, oh, sabes que el problema está aquí, se soluciona de esta manera, eres más que bienvenido a proporcionar un PR que siga las indicaciones del mantenedor. No tienes que esperar a que el mantenedor lo solucione. Ahora, si no tienes la experiencia, en lugar de code, también puedes contribuir probando la nueva funcionalidad y el problema que el mantenedor solucionó para ti de inmediato. Así puedes apoyar realmente al mantenedor al decir que el problema ya no es un problema. He solucionado el problema, podemos seguir adelante con nuestras vidas.

Además, proporciona comentarios de inmediato. Simplemente quedarse en silencio y decir, está bien, he terminado. No es suficiente. Tal vez solo un comentario simple en el problema, decir, gracias amigo, lo solucionaste en la versión 1.2.3. Es absolutamente suficiente, pero al menos les haces saber que todo está bien, y luego pasas al siguiente problema. Y un último paso, no olvides agradecerles. De acuerdo, amigos. Una vez más, nosotros somos, y tú también si eres un mantenedor o si serás un mantenedor, seguimos siendo personas. Dependemos de la amabilidad, ¿de acuerdo? No olvides agradecer a las personas por el tiempo que te brindan. No es que el mantenedor te agradezca por el problema que presentaste, y tú les agradecerás por el problema que solucionaron.

Funciona así. Como normalmente agradeces a las personas cuando te pasan la sal, o algo así cuando estás almorzando, ¿de acuerdo? No lo olvides. Eso es muy importante.

Entonces, esa fue una breve descripción general de cómo puedes apoyar a tus mantenedores. Permíteme resumirlo para ti. Amabilidad, primero. Siempre. No te deben nada, y siempre es bueno ser amable cuando les pides a las personas que te ayuden. Apóyalos, estate disponible, contribuye si puedes. Participa y, una vez más, cortesía y amabilidad, y agradéceles. Una vez más, la amabilidad es la palabra clave.

Y por eso, como suelo hacer en mis charlas, me gusta terminar mis charlas con una cita famosa de alguien mucho, mucho, mucho más sabio que yo. Y hoy, elijo a Esopo, el escritor griego que dijo hace mucho tiempo, hablo de hace unos 2.600 años, o algo así. Ningún acto de amabilidad, por pequeño que sea, se desperdicia nunca. Siempre recordamos la amabilidad recibida, ¿de acuerdo? Recuerda eso. Eso es todo, he terminado por hoy. Muchas gracias, una vez más. Soy Paolo, NodeTSC e ingeniero principal en Platformatic, y fue un placer tenerte aquí hoy, escuchándome. Muchas gracias y adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.